Messages in this thread | | | Date | Thu, 24 May 2018 20:28:06 +0200 | From | Peter Zijlstra <> | Subject | Re: write_lock_irq(&tasklist_lock) |
| |
On Thu, May 24, 2018 at 10:37:25AM -0700, Sodagudi Prasad wrote: > Kernel version is locked for couple of products and same issue observed on > both 4.14.41 > and 4.9.96 kernels. We can only accept the stable updates from upstream for > these products.
> If QUEUED_RWLOCKS works on above listed kernel versions without any issues, > we can enabled QUEUED_RWLOCKS.
You want:
e0d02285f16e ("locking/qrwlock: Use 'struct qrwlock' instead of 'struct __qrwlock'") 4df714be4dcf ("locking/atomic: Add atomic_cond_read_acquire()") b519b56e378e ("locking/qrwlock: Use atomic_cond_read_acquire() when spinning in qrwlock") 087133ac9076 ("locking/qrwlock, arm64: Move rwlock implementation over to qrwlocks") d13316614633 ("locking/qrwlock: Prevent slowpath writers getting held up by fastpath")
IIRC, enabling QUEUED_RWLOCKS will 'work' but esp. that atomic_cond_read_acquire() one is goodness for ARM64.
> Can we go ahead with Linus suggestion for these kernel version? > So that IRQ wont be disabled for quite a long time. > > static void tasklist_write_lock(void) > { > unsigned long flags; > local_irq_save(flags); > while (!write_trylock(&tasklist_lock)) { > local_irq_restore(flags); > do { cpu_relax(); } while (write_islocked(&tasklist_lock)); > local_irq_disable(); > } > }
First you say you can only take stable updates, then you ask for a gruesome hack that will seriously regress architectures that do use qrwlock which will hence never make it into stable.
Just take the arm64 qrwlock patches and pretend they're from stable.
| |