Re: rw_lock_held() & friends

2020-12-14 Thread Visa Hankala
On Mon, Dec 14, 2020 at 10:59:05AM -0300, Martin Pieuchot wrote: > On 08/12/20(Tue) 14:39, Visa Hankala wrote: > > On Mon, Dec 07, 2020 at 03:25:00PM -0300, Martin Pieuchot wrote: > > > Simple diff below to add the rw_lock_held() as well as a read & write > > > version. > > > > > > This allows us

Re: rw_lock_held() & friends

2020-12-14 Thread Martin Pieuchot
On 08/12/20(Tue) 14:39, Visa Hankala wrote: > On Mon, Dec 07, 2020 at 03:25:00PM -0300, Martin Pieuchot wrote: > > Simple diff below to add the rw_lock_held() as well as a read & write > > version. > > > > This allows us to reduce the difference with NetBSD in UVM by adding the > > following

Re: rw_lock_held() & friends

2020-12-08 Thread Visa Hankala
On Mon, Dec 07, 2020 at 03:25:00PM -0300, Martin Pieuchot wrote: > Simple diff below to add the rw_lock_held() as well as a read & write > version. > > This allows us to reduce the difference with NetBSD in UVM by adding the > following checks: > > KASSERT(rw_write_held(amap->am_lock)); >

Re: rw_lock_held() & friends

2020-12-07 Thread Alexandr Nedvedicky
On Mon, Dec 07, 2020 at 10:18:04PM +0100, Alexandr Nedvedicky wrote: > On Mon, Dec 07, 2020 at 12:22:22PM -0800, Philip Guenther wrote: > > On Mon, Dec 7, 2020 at 11:16 AM Alexandr Nedvedicky < > > alexandr.nedvedi...@oracle.com> wrote: > > > > > What's the plan for rw_write_held()? Currently

Re: rw_lock_held() & friends

2020-12-07 Thread Alexandr Nedvedicky
On Mon, Dec 07, 2020 at 12:22:22PM -0800, Philip Guenther wrote: > On Mon, Dec 7, 2020 at 11:16 AM Alexandr Nedvedicky < > alexandr.nedvedi...@oracle.com> wrote: > > > What's the plan for rw_write_held()? Currently macro is true, if whoever > > holds > > the lock. > > > > > > > > +#define

Re: rw_lock_held() & friends

2020-12-07 Thread Philip Guenther
On Mon, Dec 7, 2020 at 11:16 AM Alexandr Nedvedicky < alexandr.nedvedi...@oracle.com> wrote: > What's the plan for rw_write_held()? Currently macro is true, if whoever > holds > the lock. > > > > > +#define rw_write_held(rwl) (rw_status(rwl) == RW_WRITE) > Nope. rw_status() returns

Re: rw_lock_held() & friends

2020-12-07 Thread Alexandr Nedvedicky
Hello, What's the plan for rw_write_held()? Currently macro is true, if whoever holds the lock. > > +#define rw_write_held(rwl) (rw_status(rwl) == RW_WRITE) I would expect something like instead: #define rw_write_held(rwl) (RWLOCK_OWNER(rwl) == curproc)

Re: rw_lock_held() & friends

2020-12-07 Thread Theo de Raadt
That's all fine, until someone uses this not for KASSERT, but as part of their logic. while(!rw_read_held(lock)) { do something; } I think this kind of thing fleads to people building "try" APIs. Martin Pieuchot wrote: > Simple diff below to add the

rw_lock_held() & friends

2020-12-07 Thread Martin Pieuchot
Simple diff below to add the rw_lock_held() as well as a read & write version. This allows us to reduce the difference with NetBSD in UVM by adding the following checks: KASSERT(rw_write_held(amap->am_lock)); ok? Index: sys/rwlock.h