From: Mingming Cao <cmm@us.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Theodore Tso <tytso@mit.edu>, Eric Dumazet <dada1@cosmosbay.com>,
linux kernel <linux-kernel@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-ext4@vger.kernel.org, stable@kernel.org
Subject: Re: [PATCH] percpu_counter: Fix __percpu_counter_sum()
Date: Mon, 08 Dec 2008 09:55:23 -0800 [thread overview]
Message-ID: <1228758923.7096.10.camel@mingming-laptop> (raw)
In-Reply-To: <20081207204222.d811c00b.akpm@linux-foundation.org>
在 2008-12-07日的 20:42 -0800,Andrew Morton写道:
> (cc stable)
>
> On Sun, 7 Dec 2008 10:28:21 -0500 Theodore Tso <tytso@mit.edu> wrote:
>
> > On Sat, Dec 06, 2008 at 08:22:33PM -0800, Andrew Morton wrote:
> > >
> > > I suggest that what we do is to revert both those changes. We can
> > > worry about the possibly-unneeded spin_lock later, in a separate patch.
> > >
> > > It should have been a separate patch anyway. It's conceptually
> > > unrelated and is not a bugfix, but it was mixed in with a bugfix.
> > >
> > > Mingming, this needs urgent consideration, please. Note that I had to
> > > make additional changes to ext4 due to the subsequent introduction of
> > > the dirty_blocks counter.
> >
> > I've looked the two patches which you've queued in the -mm branch, and
> > they look correct to me.
> >
> > The bugs fixed by these patches can potentially lead to filesystem
> > corruption, since we ultimately use these fields to set the superblock
> > values. This in my mind makes them stable candidates at the very
> > least, and if we weren't so late in the 2.6.28 cycle, I'd be strongly
> > tempted to push them to Linus as a bugfix before the merge window.
> >
> > Andrew, any strong objections for me to grab them for the ext4 tree?
> > Or would you rather carry them? I would prefer that they get pushed
> > to Linus as soon as the merge window opens, which is one reason why
> > I'd prefer carry them, but we can do this either way.
> >
>
> I'm planning on sending them off to Linus for 2.6.28 this week,
> assuming nobody can think of a plausible reason to not do that.
>
> Now I didn't look _very_ closely at the chronology, but I think that
> revert-percpu-counter-clean-up-percpu_counter_sum_and_set.patch reverts
> a post-2.6.27 change, and is not needed in stable.
>
> revert-percpu_counter-new-function-percpu_counter_sum_and_set.patch
> however reverts a pre-2.6.27 change, and should be merged into 2.6.27.
> This patch reverts the addition and use of
> percpu_counter_sum_and_set(), which is racy and can corrupt the
> counters.
>
> However
> revert-percpu_counter-new-function-percpu_counter_sum_and_set.patch
> won't apply to 2.6.27 because the dirty_blocks stuff was added and
> generates rejects.
>
> So if all the above is correct, I'd propose that if and when
> revert-percpu_counter-new-function-percpu_counter_sum_and_set.patch
> hits mainline, we should ask the -stable guys to directly revert
>
Agreed.
I checked 2.6.27.8, above are correct, the
revert-percpu-counter-clean-up-percpu_counter_sum_and_set.patch is not
needed for 2.6.27.x stable tree.
Thanks again.
Mingming
> commit e8ced39d5e8911c662d4d69a342b9d053eaaac4e
> Author: Mingming Cao <cmm@us.ibm.com>
> Date: Fri Jul 11 19:27:31 2008 -0400
>
> percpu_counter: new function percpu_counter_sum_and_set
>
> which should be all that 2.6.27.x needs.
>
> Agree? If so, can you please take care of getting that patch over to
> stable@kernel.org? (I added the cc:stable to the diff, so there's
> probably nothing which you need to do..)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Mingming Cao <cmm@us.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Theodore Tso <tytso@mit.edu>, Eric Dumazet <dada1@cosmosbay.com>,
linux kernel <linux-kernel@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-ext4@vger.kernel.org, stable@kernel.org
Subject: Re: [PATCH] percpu_counter: Fix __percpu_counter_sum()
Date: Mon, 08 Dec 2008 09:55:23 -0800 [thread overview]
Message-ID: <1228758923.7096.10.camel@mingming-laptop> (raw)
In-Reply-To: <20081207204222.d811c00b.akpm@linux-foundation.org>
在 2008-12-07日的 20:42 -0800,Andrew Morton写道:
> (cc stable)
>
> On Sun, 7 Dec 2008 10:28:21 -0500 Theodore Tso <tytso@mit.edu> wrote:
>
> > On Sat, Dec 06, 2008 at 08:22:33PM -0800, Andrew Morton wrote:
> > >
> > > I suggest that what we do is to revert both those changes. We can
> > > worry about the possibly-unneeded spin_lock later, in a separate patch.
> > >
> > > It should have been a separate patch anyway. It's conceptually
> > > unrelated and is not a bugfix, but it was mixed in with a bugfix.
> > >
> > > Mingming, this needs urgent consideration, please. Note that I had to
> > > make additional changes to ext4 due to the subsequent introduction of
> > > the dirty_blocks counter.
> >
> > I've looked the two patches which you've queued in the -mm branch, and
> > they look correct to me.
> >
> > The bugs fixed by these patches can potentially lead to filesystem
> > corruption, since we ultimately use these fields to set the superblock
> > values. This in my mind makes them stable candidates at the very
> > least, and if we weren't so late in the 2.6.28 cycle, I'd be strongly
> > tempted to push them to Linus as a bugfix before the merge window.
> >
> > Andrew, any strong objections for me to grab them for the ext4 tree?
> > Or would you rather carry them? I would prefer that they get pushed
> > to Linus as soon as the merge window opens, which is one reason why
> > I'd prefer carry them, but we can do this either way.
> >
>
> I'm planning on sending them off to Linus for 2.6.28 this week,
> assuming nobody can think of a plausible reason to not do that.
>
> Now I didn't look _very_ closely at the chronology, but I think that
> revert-percpu-counter-clean-up-percpu_counter_sum_and_set.patch reverts
> a post-2.6.27 change, and is not needed in stable.
>
> revert-percpu_counter-new-function-percpu_counter_sum_and_set.patch
> however reverts a pre-2.6.27 change, and should be merged into 2.6.27.
> This patch reverts the addition and use of
> percpu_counter_sum_and_set(), which is racy and can corrupt the
> counters.
>
> However
> revert-percpu_counter-new-function-percpu_counter_sum_and_set.patch
> won't apply to 2.6.27 because the dirty_blocks stuff was added and
> generates rejects.
>
> So if all the above is correct, I'd propose that if and when
> revert-percpu_counter-new-function-percpu_counter_sum_and_set.patch
> hits mainline, we should ask the -stable guys to directly revert
>
Agreed.
I checked 2.6.27.8, above are correct, the
revert-percpu-counter-clean-up-percpu_counter_sum_and_set.patch is not
needed for 2.6.27.x stable tree.
Thanks again.
Mingming
> commit e8ced39d5e8911c662d4d69a342b9d053eaaac4e
> Author: Mingming Cao <cmm@us.ibm.com>
> Date: Fri Jul 11 19:27:31 2008 -0400
>
> percpu_counter: new function percpu_counter_sum_and_set
>
> which should be all that 2.6.27.x needs.
>
> Agree? If so, can you please take care of getting that patch over to
> stable@kernel.org? (I added the cc:stable to the diff, so there's
> probably nothing which you need to do..)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-12-08 17:55 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-03 18:40 [PATCH] percpu_counter: fix CPU unplug race in percpu_counter_destroy() Eric Dumazet
2008-12-03 20:24 ` [PATCH] percpu_counter: Fix __percpu_counter_sum() Eric Dumazet
2008-12-03 20:45 ` Peter Zijlstra
2008-12-04 6:14 ` David Miller
2008-12-07 4:22 ` Andrew Morton
2008-12-07 4:22 ` Andrew Morton
2008-12-07 10:25 ` Peter Zijlstra
2008-12-07 13:28 ` Eric Dumazet
2008-12-07 13:28 ` Eric Dumazet
2008-12-07 17:28 ` Andrew Morton
2008-12-07 18:00 ` Eric Dumazet
2008-12-07 18:00 ` Eric Dumazet
2008-12-08 4:52 ` Andrew Morton
2008-12-08 22:12 ` Theodore Tso
2008-12-08 22:20 ` Peter Zijlstra
2008-12-08 23:00 ` Theodore Tso
2008-12-08 23:05 ` Peter Zijlstra
2008-12-08 23:08 ` Peter Zijlstra
2008-12-09 8:12 ` Eric Dumazet
2008-12-09 8:12 ` Eric Dumazet
2008-12-09 8:34 ` Peter Zijlstra
2008-12-09 8:34 ` Peter Zijlstra
2008-12-10 5:09 ` Eric Dumazet
2008-12-10 5:49 ` Andrew Morton
2008-12-10 22:56 ` Eric Dumazet
2008-12-10 22:56 ` Eric Dumazet
2008-12-12 8:17 ` Rusty Russell
2008-12-12 8:22 ` Eric Dumazet
2008-12-12 8:22 ` Eric Dumazet
2008-12-12 11:08 ` [PATCH] percpu_counter: use local_t and atomic_long_t if possible Eric Dumazet
2008-12-12 11:08 ` Eric Dumazet
2008-12-12 11:29 ` Peter Zijlstra
2008-12-23 11:43 ` Peter Zijlstra
2008-12-25 13:26 ` Rusty Russell
2008-12-15 12:53 ` [PATCH] percpu_counter: Fix __percpu_counter_sum() Rusty Russell
2008-12-16 20:16 ` Ingo Molnar
2008-12-10 7:12 ` Peter Zijlstra
2008-12-08 23:07 ` Andrew Morton
2008-12-08 23:49 ` Theodore Tso
2008-12-08 22:22 ` Andrew Morton
2008-12-08 22:44 ` Mingming Cao
2008-12-08 22:44 ` Mingming Cao
2008-12-07 22:24 ` [PATCH] atomic: fix a typo in atomic_long_xchg() Eric Dumazet
2008-12-07 22:24 ` Eric Dumazet
2008-12-07 15:28 ` [PATCH] percpu_counter: Fix __percpu_counter_sum() Theodore Tso
2008-12-08 4:42 ` Andrew Morton
2008-12-08 17:55 ` Mingming Cao [this message]
2008-12-08 17:55 ` Mingming Cao
2008-12-11 16:32 ` [stable] " Greg KH
2008-12-08 17:44 ` Mingming Cao
2008-12-08 17:44 ` Mingming Cao
2008-12-04 6:13 ` [PATCH] percpu_counter: fix CPU unplug race in percpu_counter_destroy() David Miller
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=1228758923.7096.10.camel@mingming-laptop \
--to=cmm@us.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=dada1@cosmosbay.com \
--cc=davem@davemloft.net \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@kernel.org \
--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.