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. > (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). Andrea > > Hugh
