From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Peng Tao <tao.peng@linux.alibaba.com>
Cc: alikernel-developer@linux.alibaba.com,
Liu Bo <bo.liu@linux.alibaba.com>,
Ma Jie Yue <majieyue@linux.alibaba.com>,
Joseph Qi <joseph.qi@linux.alibaba.com>,
Eryu Guan <eguan@linux.alibaba.com>,
Miklos Szeredi <mszeredi@redhat.com>,
stable@vger.kernel.org
Subject: Re: [PATCH CK 4.19 1/4] fuse: fix page dereference after free
Date: Mon, 1 Mar 2021 10:04:12 +0100 [thread overview]
Message-ID: <YDyuDFlWKUL8127m@kroah.com> (raw)
In-Reply-To: <c9807ed1-dcaa-4e9f-476e-4bcedf0745c4@linux.alibaba.com>
On Mon, Mar 01, 2021 at 04:52:03PM +0800, Peng Tao wrote:
>
> On 2021/3/1 16:05, Greg Kroah-Hartman wrote:
> > On Mon, Mar 01, 2021 at 11:36:16AM +0800, Peng Tao wrote:
> > > From: Miklos Szeredi <mszeredi@redhat.com>
> > >
> > > commit d78092e4937de9ce55edcb4ee4c5e3c707be0190 upstream.
> > >
> > > fix #32833505
> >
> > What does this mean?
> >
> > And why are you all backporting random stable kernel patches to your
> > tree and not just taking all of them with a simple merge?
> >
> > By selectivly cherry-picking patches like this, you are guaranteed to be
> > doing more work, and have a much more insecure and buggy kernel. The
> > opposite of what your end goal should be, correct?
> >
>
> Hi Greg,
>
> My apology for the noise. It was due to a mistake in my git config. And
> thanks for your suggestions. Our tree is actually a mixture of stable
> backports and feature backports. I guess that's why the cherry-picking
> method was chosen, since a simple merge creates too many conflicts and it is
> error prone to fix them in one shoot.
A "simple merge" will cause initial problems, but after you have
resolved them the first time, all should be good.
As proof that this can work, see the android common kernel trees, which
receive a "simple merge" into all of the different branches within a day
or two of a stable release, with no problems at all.
You need to take all stable patches, doing this cherry-picking will
cause you problems and in the end, takes more time and effort!
good luck,
greg k-h
next prev parent reply other threads:[~2021-03-01 9:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1614569779-12114-1-git-send-email-tao.peng@linux.alibaba.com>
2021-03-01 3:36 ` [PATCH CK 4.19 1/4] fuse: fix page dereference after free Peng Tao
2021-03-01 8:05 ` Greg Kroah-Hartman
2021-03-01 8:52 ` Peng Tao
2021-03-01 9:04 ` Greg Kroah-Hartman [this message]
2021-03-01 3:36 ` [PATCH CK 4.19 4/4] fuse: Fix parameter for FS_IOC_{GET,SET}FLAGS Peng Tao
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=YDyuDFlWKUL8127m@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=alikernel-developer@linux.alibaba.com \
--cc=bo.liu@linux.alibaba.com \
--cc=eguan@linux.alibaba.com \
--cc=joseph.qi@linux.alibaba.com \
--cc=majieyue@linux.alibaba.com \
--cc=mszeredi@redhat.com \
--cc=stable@vger.kernel.org \
--cc=tao.peng@linux.alibaba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox