From: Andrea Parri <andrea.parri@amarulasolutions.com>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Huang, Ying" <ying.huang@intel.com>,
Daniel Jordan <daniel.m.jordan@oracle.com>,
dan.carpenter@oracle.com, dave.hansen@linux.intel.com,
sfr@canb.auug.org.au, osandov@fb.com, tj@kernel.org,
ak@linux.intel.com, linux-mm@kvack.org,
kernel-janitors@vger.kernel.org, paulmck@linux.ibm.com,
stern@rowland.harvard.edu, peterz@infradead.org,
willy@infradead.org, will.deacon@arm.com
Subject: Re: About swapoff race patch (was Re: [PATCH] mm, swap: bounds check swap_info accesses to avoid NU
Date: Fri, 08 Feb 2019 00:28:29 +0000 [thread overview]
Message-ID: <20190207234244.GA6429@andrea> (raw)
In-Reply-To: <alpine.LSU.2.11.1902041257390.4682@eggly.anvils>
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@intel.com> wrote:
> > > Andrew Morton <akpm@linux-foundation.org> 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@intel.com
"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
next prev parent reply other threads:[~2019-02-08 0:28 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-11 9:59 [PATCH] mm, swap: Potential NULL dereference in get_swap_page_of_type() Dan Carpenter
2019-01-11 17:41 ` Daniel Jordan
2019-01-11 23:20 ` Andrea Parri
2019-01-14 22:25 ` Daniel Jordan
2019-01-15 0:23 ` [PATCH] mm, swap: bounds check swap_info accesses to avoid NULL derefs Daniel Jordan
2019-01-15 1:17 ` Andrea Parri
2019-01-30 6:26 ` Andrew Morton
2019-01-31 1:52 ` Daniel Jordan
2019-01-31 2:44 ` [PATCH v2] mm, swap: bounds check swap_info array " Daniel Jordan
2019-01-31 2:48 ` About swapoff race patch (was Re: [PATCH] mm, swap: bounds check swap_info accesses to avoid NULL d Huang, Ying
2019-01-31 20:46 ` About swapoff race patch (was Re: [PATCH] mm, swap: bounds check swap_info accesses to avoid NU Andrew Morton
2019-02-02 7:14 ` Huang, Ying
2019-02-04 21:37 ` Hugh Dickins
2019-02-04 22:26 ` Matthew Wilcox
2019-02-06 0:14 ` Huang, Ying
2019-02-06 0:36 ` Hugh Dickins
2019-02-06 0:58 ` Huang, Ying
2019-02-08 0:28 ` Andrea Parri [this message]
2019-02-11 1:02 ` Huang, Ying
2019-01-30 7:28 ` [PATCH] mm, swap: bounds check swap_info accesses to avoid NULL derefs Dan Carpenter
2019-01-31 1:55 ` Daniel Jordan
2019-01-30 9:13 ` Peter Zijlstra
2019-01-31 2:00 ` Daniel Jordan
2019-01-15 0:28 ` [PATCH] mm, swap: Potential NULL dereference in get_swap_page_of_type() Andrea Parri
2019-01-14 2:12 ` Huang, Ying
2019-01-14 8:43 ` Dan Carpenter
2019-01-14 23:40 ` Daniel Jordan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190207234244.GA6429@andrea \
--to=andrea.parri@amarulasolutions.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=dan.carpenter@oracle.com \
--cc=daniel.m.jordan@oracle.com \
--cc=dave.hansen@linux.intel.com \
--cc=hughd@google.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=osandov@fb.com \
--cc=paulmck@linux.ibm.com \
--cc=peterz@infradead.org \
--cc=sfr@canb.auug.org.au \
--cc=stern@rowland.harvard.edu \
--cc=tj@kernel.org \
--cc=will.deacon@arm.com \
--cc=willy@infradead.org \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.