On Fri 24-08-18 15:10:08, Christian KÃnig wrote:
Am 24.08.2018 um 15:01 schrieb Michal Hocko:Can we change it to non-sleepable lock then?
On Fri 24-08-18 14:52:26, Christian KÃnig wrote:With avoiding allocating memory in the write lock path I don't see an issue
Am 24.08.2018 um 14:33 schrieb Michal Hocko:[...]
It would really help to know more about that case and fix it properlyThiking about it some more, I can imagine that a notifier callback whichWell I agree that we should probably fix that, but I have some concerns to
performs an allocation might trigger a memory reclaim and that in turn
might trigger a notifier to be invoked and recurse. But notifier
shouldn't really allocate memory. They are called from deep MM code
paths and this would be extremely deadlock prone. Maybe Jerome can come
up some more realistic scenario. If not then I would propose to simplify
the locking here. We have lockdep to catch self deadlocks and it is
always better to handle a specific issue rather than having a code
without a clear indication how it can recurse.
remove the existing workaround.
See we added that to get rid of a real problem in a customer environment and
I don't want to that to show up again.
rather than workaround it like this. Anyway, let me think how to handle
the non-blocking notifier invocation then. I was not able to come up
with anything remotely sane yet.
any more with that.
All what the write lock path does now is adding items to a linked lists,