Skip to content

introduce down_write_killable for rw_semaphore

Michal Hocko linux-alpha linux-arch linux-ia64 linux-s390 linux-sh lkml sparclinux 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest11 patches 14 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/11locking, rwsem: get rid of __down_write_nestedarch/s390/include/asm/rwsem.h arch/sh/include/asm/rwsem.h arch/sparc/include/asm/rwsem.h +4 more+5 -360 replies
2/11locking, rwsem: drop explicit memory barriersarch/sh/include/asm/rwsem.h arch/xtensa/include/asm/rwsem.h+4 -240 replies
3/11locking, rwsem: introduce basis for down_write_killableinclude/asm-generic/rwsem.h include/linux/rwsem-spinlock.h include/linux/rwsem.h +2 more+61 -84 replies
4/11alpha, rwsem: provide __down_write_killablearch/alpha/include/asm/rwsem.h+16 -20 replies
5/11ia64, rwsem: provide __down_write_killablearch/ia64/include/asm/rwsem.h+19 -30 replies
6/11s390, rwsem: provide __down_write_killablearch/s390/include/asm/rwsem.h+17 -20 replies
7/11sh, rwsem: provide __down_write_killablearch/sh/include/asm/rwsem.h+13 -00 replies
8/11sparc, rwsem: provide __down_write_killablearch/sparc/include/asm/rwsem.h+13 -00 replies
9/11xtensa, rwsem: provide __down_write_killablearch/xtensa/include/asm/rwsem.h+13 -00 replies
10/11x86, rwsem: provide __down_write_killablearch/x86/include/asm/rwsem.h arch/x86/lib/rwsem.S+36 -130 replies
11/11locking, rwsem: provide down_write_killableinclude/linux/lockdep.h include/linux/rwsem.h kernel/locking/rwsem.c+35 -00 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 0/11] introduce down_write_killable for rw_semaphore

Hi,
I have posted this series [1] and there didn't seem to be any fundamental objections except for x86 maintainers who preferred the asm __down_write implementation which I have reworked for this series. Apart from that I have refreshed on top of the current linux-next and fixed one unused variable warning which happened to trigger a compilation failure on ppc.

The following patchset implements a killable variant of write lock for rw_semaphore. My usecase is to turn as many mmap_sem write users to use a killable variant which will be helpful for the oom_reaper [2] to asynchronously tear down the oom victim address space which requires mmap_sem for read. This will reduce a likelihood of OOM livelocks caused by oom victim being stuck on a lock or other resource which prevents it to reach its exit path and release the memory. I haven't implemented the killable variant of the read lock because I do not have any usecase for this API.

The patchset is organized as follows.
- Patch 1 is a trivial cleanup
- Patch 2, I belive, shouldn't introduce any functional changes as per Documentation/memory-barriers.txt.
- Patch 3 is the preparatory work and necessary infrastructure for down_write_killable. It implements generic __down_write_killable and prepares the write lock slow path to bail out earlier when told so
- Patch 4-1- are implementing arch specific __down_write_killable. One patch per architecture.
- finally patch 11 implements down_write_killable and ties everything together. I am not really an expert on lockdep so I hope I got it right.

Many of arch specific patches are basically same and I can squash them into one patch if this is preferred but I thought that one patch per arch is preferable.

My patch to change mmap_sem write users to killable form is not part of the series because it is a larger change and I would like to prevent from spamming people too much. I will post the series shortly.

I have tested on x86 with OOM situations with high mmap_sem contention (basically many parallel page faults racing with many parallel mmap/munmap tight loops) so the waiters for the write locks are routinely interrupted by SIGKILL.

Patches should apply cleanly on both Linus and next tree.

[1] http://lkml.kernel.org/r/[email protected]
[2] http://lkml.kernel.org/r/[email protected]

Any feedback is highly appreciated.