Re: NET_LOCK() pr_sysctl

On Mon, Jan 16, 2017 at 07:34:43PM +, Alexander Bluhm wrote: > On Mon, Jan 09, 2017 at 11:55:55PM +0100, Alexander Bluhm wrote: > > On Thu, Dec 22, 2016 at 01:38:17AM +0100, Mateusz Guzik wrote: > > > In this particular case, what happens if the access results in

Re: NET_LOCK() pr_sysctl

ppens if the access results in a page fault and the area comes from a nfs mapped file? If network i/o is done from the same context, this should result in 'locking against myself' assertion failure. That said, I'm not exactly familiar with the area, so maybe that's a false alarm. -- Mateusz Guzik

Re: sendsyslog file race

On Sun, Mar 26, 2017 at 10:04 PM, Alexander Bluhm <alexander.bl...@gmx.net> wrote: > On Sun, Mar 26, 2017 at 05:00:12PM +0200, Mateusz Guzik wrote: > > The patch is somewhat incorrect, although from what I checked it happens > > to generate the expected outcome in terms of

Re: sendsyslog file race

On Mon, Mar 27, 2017 at 6:09 PM, Alexander Bluhm <alexander.bl...@gmx.net> wrote: > On Mon, Mar 27, 2017 at 05:39:27PM +0200, Mateusz Guzik wrote: > > The previous patch replaced multiple reads of the global var with just > > one read and had the result stored in a

Re: sendsyslog file race

On Fri, Mar 24, 2017 at 4:56 PM, Alexander Bluhm wrote: > Hi, > > There is a race in dosendsyslog() which resulted in a crash on a > 5.9 system. sosend(syslogf->f_data, ...) was called with a NULL > pointer. So syslogf is not NULL, f_data is NULL and f_count is 1. > >

Re: "user" chroot (patch)

n now use different places in the tree with directory granulalrity as opposed to having to chroot to the common parent. This poses a problem with confining ".." lookups. There is a hack in FreeBSD to explicitly track them, but perhaps you will be fine enough with disallowing ".."s in the first place. -- Mateusz Guzik

Re: rw locks vs memory barriers and adaptive spinning

On Tue, Oct 10, 2017 at 10:15:48AM +0200, Martin Pieuchot wrote: > Hello Mateusz, > > On 09/10/17(Mon) 21:43, Mateusz Guzik wrote: > > I was looking at rw lock code out of curiosity and noticed you always do > > membar_enter which on MP-enabled amd64 kernel translates to m

rw locks vs memory barriers and adaptive spinning

ontain the necessary crappery to copy-paste including linker script support. Cheers, -- Mateusz Guzik

Re: rw locks vs memory barriers and adaptive spinning

On Wed, Oct 11, 2017 at 03:15:42PM +0200, Martin Pieuchot wrote: > On 10/10/17(Tue) 20:19, Mateusz Guzik wrote: > > On Tue, Oct 10, 2017 at 10:15:48AM +0200, Martin Pieuchot wrote: > > > Hello Mateusz, > > > > > > On 09/10/17(Mon) 21:43, Mateusz Guzik wrote: &

Re: C mutex impl. for x86

e a compiler barrier on amd64/i386. >From what I gather you are trying to mimick illumos nomenclature, but they don't have an equivalent afaics. (perhaps Solaris grew one in the meantime?) In FreeBSD an appropriate routine is named atomic_thread_fence_rel (see amd64/include/atomic.h) and I suggest just borrowing the api. Side note is that you probably can shorten ipl to vars to make the lock smaller. It can be doable to fit it into lock word, but I don't know how much sense would playing with it make. -- Mateusz Guzik

Re: C mutex impl. for x86

On Wed, Dec 20, 2017 at 12:17:27PM +0100, Martin Pieuchot wrote: > On 15/12/17(Fri) 22:03, Mateusz Guzik wrote: > > > +void > > > +__mtx_enter(struct mutex *mtx) > > > +{ > > > +#ifdef MP_LOCKDEBUG > > > + int nticks = __mp_lock_spinout; > >

Re: getentropy does not explicit_bzero if copyout fails

On Wed, Feb 21, 2018 at 10:28 PM, Ted Unangst <t...@tedunangst.com> wrote: > Mateusz Guzik wrote: > > As the subject states. By the time the code gets to copyout, buf is > > already populated. Clearing it only if copyout succeeds looks like a > > braino, thus the

getentropy does not explicit_bzero if copyout fails

= 0) - return (error); + error = copyout(buf, SCARG(uap, buf), SCARG(uap, nbyte)); explicit_bzero(buf, sizeof(buf)); - retval[0] = 0; - return (0); + if (error == 0) + retval[0] = 0; + return (error); } -- Mateusz Guzik

Re: rasops(9): revert changes in rasops32_putchar()?

trimental by now. If it is to be kept, a pagezero variant utilizing non-temporal stores still makes sense but a different function should be created for on-demand zeroing. That said, it should be easy to lift a lot of this code. Could you please benchmark with memcpy as implemented above? Not saying this particular patch is wrong, but that the bigger problem should be addressed first. Cheers, -- Mateusz Guzik

Re: Removing PF

eebsd.org/pipermail/svn-src-projects/2019-April/013336.html -- Mateusz Guzik

Re: Fix use of WITNESS_UNLOCK() in rw_exit_{read,write}()

ock) > +{ > + unsigned long owner, set; > + > do { > owner = rwl->rwl_owner; > if (wrlock) > @@ -337,7 +346,7 @@ rw_exit(struct rwlock *rwl) > else > set = (owner - RWLOCK_READ_INCR) & > ~(RWLOCK_WAIT|RWLOCK_WRWANT); > - } while (rw_cas(>rwl_owner, owner, set)); > + } while (__predict_false(rw_cas(>rwl_owner, owner, set))); > > if (owner & RWLOCK_WAIT) > wakeup(rwl); > > -- Mateusz Guzik

Re: Fix use of WITNESS_UNLOCK() in rw_exit_{read,write}()

Oops, sorry for the mixup below. I got the e-mail bounced from someone and it used their 'From' instead of the original. Regardless, technical contend stands. :) On 3/2/20, Mateusz Guzik wrote: > On 2/29/20, Visa Hankala wrote: >> There is a bug in how rw_exit_read() and rw_exit_wr

Re: incorrect result from getppid for ptraced processes

On 9/5/20, Philip Guenther wrote: > On Fri, Sep 4, 2020 at 2:59 PM Mateusz Guzik wrote: > >> On 9/5/20, Philip Guenther wrote: >> > On Fri, Sep 4, 2020 at 1:06 PM Mateusz Guzik wrote: >> > >> >> On 9/4/20, Vitaliy Makkoveev wrote: >> >&g

incorrect result from getppid for ptraced processes

children on exit), while ptrace will skip that part. Side effect of such a change be that getppid will stop requiring the kernel lock. -- Mateusz Guzik

Re: incorrect result from getppid for ptraced processes

On 9/4/20, Vitaliy Makkoveev wrote: > On Fri, Sep 04, 2020 at 05:24:42PM +0200, Mateusz Guzik wrote: >> getppid blindly follows the parent pointer and reads the pid. >> >> The problem is that ptrace reparents the traced process, so in >> particular if you gdb -p

Re: incorrect result from getppid for ptraced processes

On 9/5/20, Philip Guenther wrote: > On Fri, Sep 4, 2020 at 1:06 PM Mateusz Guzik wrote: > >> On 9/4/20, Vitaliy Makkoveev wrote: >> > On Fri, Sep 04, 2020 at 05:24:42PM +0200, Mateusz Guzik wrote: >> >> getppid blindly follows the parent pointer and reads