On Tue, May 16, 2023 at 10:40:12PM +0300, Vitaliy Makkoveev wrote:
> We have "error == 0" in assertion, so I used this idiom instead of
> "!error". This is not the fast path, so dropping "maxlen !=
> mq->mq_maxlen" doesn't provide any performance impact.
>
> ok?
OK bluhm@
> Index: sys/kern/uipc_
On Tue, May 16, 2023 at 08:26:37PM +0300, Vitaliy Makkoveev wrote:
> > On 16 May 2023, at 18:35, Alexander Bluhm wrote:
> >
> > I saw one issue in sysctl_niq(). Another CPU could write mq_maxlen
> > and our logic is inconsistent. Below is a fix with read once. Each
> > CPU detects its own chan
> On 16 May 2023, at 18:35, Alexander Bluhm wrote:
>
> I saw one issue in sysctl_niq(). Another CPU could write mq_maxlen
> and our logic is inconsistent. Below is a fix with read once. Each
> CPU detects its own change, last write wins. Or should we protect
> everything with mq_mtx? Then sy
e for pr_input functions in a pending
diff. Could you name your flag PR_MPSYSCTL? Then it is clear what
it is used for.
> Unlock ip_sysctl(). Still take kernel lock within IPCTL_MRTSTATS case.
> ok?
OK bluhm@
> This is not related to (*pr_sysctl)() unlocking, but if there is no
> objectio
Let's start to unlock (*pr_sysctl)() handlers. We have many of them, so
introduce temporary PR_MPSAFE flag to mark MP safe instead of pushing
kernel lock within handlers.
Unlock ip_sysctl(). Still take kernel lock within IPCTL_MRTSTATS case.
It looks like `mrtstat' protection is incons
