Re: unveil in process accounting and lastcomm

On Thu, Jul 18, 2019 at 11:46:46AM -0400, Bryan Steele wrote: > On Thu, Jul 18, 2019 at 04:13:10PM +0200, Alexander Bluhm wrote: > > Hi, > > > > Can we track unveil(2) violators in process accounting lastcomm(1)? > > This makes it easier to find them. > > > > $ lastcomm | grep -e '-[A-Z]U' > >

Re: follow up to 'once rule' expiration

On Thu, Jul 18, 2019 at 09:46:58AM +0200, Alexandr Nedvedicky wrote: > Hello, > > I've just realized my suggestion [1] to lteo@ was not complete. The single > atomic_cas() used as I've suggested is not sufficient measure. The code > should also do a non-atomic test to check, whether the rule is

Re: taking kernel config into consideration when reorder

On 2019/07/18 19:15, Gregory Edigarov wrote: > Hello, > > Just tired a of rebooting into UKC a bit. > > diff --git a/libexec/reorder_kernel/reorder_kernel.sh > b/libexec/reorder_kernel/reorder_kernel.sh > index ecd8d8fc563..7354350505a 100644 > --- a/libexec/reorder_kernel/reorder_kernel.sh >

Re: taking kernel config into consideration when reorder

On Thu, Jul 18, 2019 at 07:15:50PM +0300, Gregory Edigarov wrote: > Hello, > > Just tired a of rebooting into UKC a bit. > > diff --git a/libexec/reorder_kernel/reorder_kernel.sh > b/libexec/reorder_kernel/reorder_kernel.sh > index ecd8d8fc563..7354350505a 100644 > ---

taking kernel config into consideration when reorder

Hello, Just tired a of rebooting into UKC a bit. diff --git a/libexec/reorder_kernel/reorder_kernel.sh b/libexec/reorder_kernel/reorder_kernel.sh index ecd8d8fc563..7354350505a 100644 --- a/libexec/reorder_kernel/reorder_kernel.sh +++ b/libexec/reorder_kernel/reorder_kernel.sh @@ -66,5 +66,9

Re: unveil in process accounting and lastcomm

On Thu, Jul 18, 2019 at 04:13:10PM +0200, Alexander Bluhm wrote: > Hi, > > Can we track unveil(2) violators in process accounting lastcomm(1)? > This makes it easier to find them. > > $ lastcomm | grep -e '-[A-Z]U' > pflogd -FU root__ 0.00 secs Thu Jul 18 14:19 (2:33:22.00) >

Re: vxlan(4) regression

On 2019-07-17 11:41, Martin Pieuchot wrote: Hello Michael, On 17/07/19(Wed) 08:59, Michael Graves wrote: I think I have found a possible regression introduced in if_bridge.c at version 1.323. So the bug is not present at revision 1.322? I still have the problem with revision 1.322 so I

unveil in process accounting and lastcomm

Hi, Can we track unveil(2) violators in process accounting lastcomm(1)? This makes it easier to find them. $ lastcomm | grep -e '-[A-Z]U' pflogd -FU root__ 0.00 secs Thu Jul 18 14:19 (2:33:22.00) Seems that pflogd(8) has to be investigated. Also we keep record about

Re: mbuf cluster limit pool wakeup

> On 18 Jul 2019, at 7:44 am, Alexander Bluhm wrote: > > On Tue, Jul 16, 2019 at 08:58:43PM -0300, Martin Pieuchot wrote: >> On 16/07/19(Tue) 21:35, Alexander Bluhm wrote: >>> Hi, >>> >>> When the kernel reaches the sysclt kern.maxclusters limit, operations >>> get stuck while holding the

Re: make msgsnd(2) more posix

Hi Moritz, Moritz Buhl wrote on Thu, Jul 18, 2019 at 01:38:49PM +0200: > bluhm@ wrote: >> Moritz, can you create a man page ERRORS diff? > Is the attached diff ok? Yes, committed with some additional tweaks. Thank you, Ingo CVSROOT:/cvs Module name:src Changes by:

Re: make msgsnd(2) more posix

> Moritz, can you create a man page ERRORS diff? Is the attached diff ok? mbuhl Index: lib/libc/sys/msgsnd.2 === RCS file: /cvs/src/lib/libc/sys/msgsnd.2,v retrieving revision 1.19 diff -u -p -r1.19 msgsnd.2 ---

follow up to 'once rule' expiration

Hello, I've just realized my suggestion [1] to lteo@ was not complete. The single atomic_cas() used as I've suggested is not sufficient measure. The code should also do a non-atomic test to check, whether the rule is not expired yet. the non-atomic check deals with scenario, where competing