Andrea Parri <andrea.parri@xxxxxxxxxxxxxxxxxxxx> writes: > Hi Huang, Ying, > > On Mon, Feb 04, 2019 at 01:37:00PM -0800, Hugh Dickins wrote: >> On Thu, 31 Jan 2019, Andrew Morton wrote: >> > On Thu, 31 Jan 2019 10:48:29 +0800 "Huang\, Ying" <ying.huang@xxxxxxxxx> wrote: >> > > Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes: >> > > > mm-swap-fix-race-between-swapoff-and-some-swap-operations.patch is very >> > > > stuck so can you please redo this against mainline? >> > > >> > > Allow me to be off topic, this patch has been in mm tree for quite some >> > > time, what can I do to help this be merged upstream? > > [...] > > >> >> Wow, yes, it's about a year old. >> >> > >> > I have no evidence that it has been reviewed, for a start. I've asked >> > Hugh to look at it. >> >> I tried at the weekend. Usual story: I don't like it at all, the >> ever-increasing complexity there, but certainly understand the need >> for that fix, and have not managed to think up anything better - >> and now I need to switch away, sorry. > > FWIW, I do agree with Hugh about "the need for that fix": AFAIU, that > (mainline) code is naively buggy _and_ "this patch": > > http://lkml.kernel.org/r/20180223060010.954-1-ying.huang@xxxxxxxxx > > "redone on top of mainline" seems both correct and appropriate to me. Thanks! Because the patch needs to go through -mm tree, so I will rebase the patch on top of the head of -mm tree. > >> (I was originally horrified by the stop_machine() added in swapon and >> swapoff, but perhaps I'm remembering a distant past of really stopping >> the machine: stop_machine() today looked reasonable, something to avoid >> generally like lru_add_drain_all(), but not as shameful as I thought.) > > AFAIC_find_on_LKML, we have three different fixes (at least!): resp., > > 1. refcount(-based), > 2. RCU, > 3. stop_machine(); > > (3) appears to be the less documented/relied-upon/tested among these; > I'm not aware of definitive reasons forcing us to reject (1) and (2). Because swapoff() is a really cold path, while page fault handler is a really hot path. (3) can minimize the overhead of the hot path. Best Regards, Huang, Ying > Andrea > > >> >> Hugh
