From: Uladzislau Rezki <urezki@gmail.com>
To: "Paul E. McKenney" <paulmck@kernel.org>,
"Theodore Y. Ts'o" <tytso@mit.edu>,
Joel Fernandes <joel@joelfernandes.org>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
Uladzislau Rezki <urezki@gmail.com>,
Joel Fernandes <joel@joelfernandes.org>,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
Suraj Jitindar Singh <surajjs@amazon.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] ext4: fix potential race between online resizing and write operations
Date: Fri, 21 Feb 2020 14:14:55 +0100 [thread overview]
Message-ID: <20200221131455.GA4904@pc636> (raw)
In-Reply-To: <20200221003035.GC2935@paulmck-ThinkPad-P72>
On Thu, Feb 20, 2020 at 04:30:35PM -0800, Paul E. McKenney wrote:
> On Wed, Feb 19, 2020 at 11:52:33PM -0500, Theodore Y. Ts'o wrote:
> > On Tue, Feb 18, 2020 at 06:08:57PM +0100, Uladzislau Rezki wrote:
> > > now it becomes possible to use it like:
> > > ...
> > > void *p = kvmalloc(PAGE_SIZE);
> > > kvfree_rcu(p);
> > > ...
> > > also have a look at the example in the mm/list_lru.c diff.
> >
> > I certainly like the interface, thanks! I'm going to be pushing
> > patches to fix this using ext4_kvfree_array_rcu() since there are a
> > number of bugs in ext4's online resizing which appear to be hitting
> > multiple cloud providers (with reports from both AWS and GCP) and I
> > want something which can be easily backported to stable kernels.
> >
> > But once kvfree_rcu() hits mainline, I'll switch ext4 to use it, since
> > your kvfree_rcu() is definitely more efficient than my expedient
> > jury-rig.
> >
> > I don't feel entirely competent to review the implementation, but I do
> > have one question. It looks like the rcutiny implementation of
> > kfree_call_rcu() isn't going to do the right thing with kvfree_rcu(p).
> > Am I missing something?
>
> Good catch! I believe that rcu_reclaim_tiny() would need to do
> kvfree() instead of its current kfree().
>
> Vlad, anything I am missing here?
>
Yes something like that. There are some open questions about
realization, when it comes to tiny RCU. Since we are talking
about "headless" kvfree_rcu() interface, i mean we can not link
freed "objects" between each other, instead we should place a
pointer directly into array that will be drained later on.
It would be much more easier to achieve that if we were talking
about the interface like: kvfree_rcu(p, rcu), but that is not our
case :)
So, for CONFIG_TINY_RCU we should implement very similar what we
have done for CONFIG_TREE_RCU or just simply do like Ted has done
with his
void ext4_kvfree_array_rcu(void *to_free)
i mean:
local_irq_save(flags);
struct foo *ptr = kzalloc(sizeof(*ptr), GFP_ATOMIC);
if (ptr) {
ptr->ptr = to_free;
call_rcu(&ptr->rcu, kvfree_callback);
}
local_irq_restore(flags);
Also there is one more open question what to do if GFP_ATOMIC
gets failed in case of having low memory condition. Probably
we can make use of "mempool interface" that allows to have
min_nr guaranteed pre-allocated pages.
Thanks!
--
Vlad Rezki
next prev parent reply other threads:[~2020-02-21 13:15 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-15 23:38 [PATCH RFC] ext4: fix potential race between online resizing and write operations Theodore Y. Ts'o
2020-02-16 12:12 ` Paul E. McKenney
2020-02-16 20:32 ` Theodore Y. Ts'o
2020-02-17 16:08 ` Uladzislau Rezki
2020-02-17 19:33 ` Theodore Y. Ts'o
2020-02-18 17:08 ` Uladzislau Rezki
2020-02-20 4:52 ` Theodore Y. Ts'o
2020-02-21 0:30 ` Paul E. McKenney
2020-02-21 13:14 ` Uladzislau Rezki [this message]
2020-02-21 20:22 ` Paul E. McKenney
2020-02-22 22:24 ` Joel Fernandes
2020-02-23 1:10 ` Paul E. McKenney
2020-02-24 17:40 ` Uladzislau Rezki
2020-02-25 2:07 ` Joel Fernandes
2020-02-25 3:55 ` Paul E. McKenney
2020-02-25 14:17 ` Joel Fernandes
2020-02-25 16:38 ` Paul E. McKenney
2020-02-25 17:00 ` Joel Fernandes
2020-02-25 18:54 ` Uladzislau Rezki
2020-02-25 22:47 ` Paul E. McKenney
2020-02-26 13:04 ` Uladzislau Rezki
2020-02-26 15:06 ` Paul E. McKenney
2020-02-26 15:53 ` Uladzislau Rezki
2020-02-27 14:08 ` Joel Fernandes
2020-03-01 11:13 ` Uladzislau Rezki
2020-02-27 13:37 ` Joel Fernandes
2020-03-01 11:08 ` Uladzislau Rezki
2020-03-01 12:07 ` Uladzislau Rezki
2020-02-25 2:11 ` Joel Fernandes
2020-02-21 12:06 ` Joel Fernandes
2020-02-21 13:28 ` Joel Fernandes
2020-02-21 19:21 ` Uladzislau Rezki
2020-02-21 19:25 ` Uladzislau Rezki
2020-02-22 22:12 ` Joel Fernandes
2020-02-24 17:02 ` Uladzislau Rezki
2020-02-24 23:14 ` Paul E. McKenney
2020-02-25 1:48 ` Joel Fernandes
2020-02-19 3:09 ` Jitindar SIngh, Suraj
2020-02-20 4:34 ` Theodore Y. Ts'o
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=20200221131455.GA4904@pc636 \
--to=urezki@gmail.com \
--cc=joel@joelfernandes.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=surajjs@amazon.com \
--cc=tytso@mit.edu \
/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.