From: Greg KH <gregkh@linuxfoundation.org>
To: Steven French <Steven.French@microsoft.com>
Cc: "paul.gortmaker@windriver.com" <paul.gortmaker@windriver.com>,
Namjae Jeon <linkinjeon@kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [EXTERNAL] Re: [PATCH 0/1] RFC: linux-5.15.y ksmbd backport for CVE-2023-38431
Date: Wed, 13 Dec 2023 15:36:01 +0100 [thread overview]
Message-ID: <2023121350-spearmint-manned-b7b1@gregkh> (raw)
In-Reply-To: <DM4PR21MB34417B034A9637445C598675E48EA@DM4PR21MB3441.namprd21.prod.outlook.com>
On Tue, Dec 12, 2023 at 08:13:37PM +0000, Steven French wrote:
> Out of curiosity, has there been an alternative approach for some
> backports, where someone backports most fixes and features (and safe
> cleanup) but does not backport any of the changesets which have
> dependencies outside the module (e.g. VFS changes, netfs or mm changes
> etc.) to reduce patch dependency risk (ie 70-80% backport instead of
> the typical 10-20% that are picked up by stable)?
>
> For example, we (on the client) ran into issues with 5.15 kernel (for
> the client) missing so many important fixes and features (and
> sometimes hard to distinguish when a new feature is also a 'fix') that
> I did a "full backport" for cifs.ko again a few months ago for 5.15
> (leaving out about 10% of the patches, those with dependencies or that
> would be risky).
We did take a "big backport/sync" for io_uring in 5.15.y a while ago, so
there is precident for this.
But really, is anyone even using this feature in 5.15.y anyway? I don't
know of any major distro using 5.15.y any more, and Android systems
based on 5.15.y don't use this specific filesystem, so what is left?
Can we just mark it broken and be done with it?
thanks,
greg k-h
next prev parent reply other threads:[~2023-12-13 14:36 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-12 18:47 [PATCH 0/1] RFC: linux-5.15.y ksmbd backport for CVE-2023-38431 paul.gortmaker
2023-12-12 18:47 ` [PATCH 1/1] ksmbd: check the validation of pdu_size in ksmbd_conn_handler_loop paul.gortmaker
2023-12-13 4:59 ` Namjae Jeon
2023-12-18 10:38 ` Greg KH
2023-12-18 11:28 ` Namjae Jeon
2023-12-18 11:38 ` Greg KH
2023-12-12 20:04 ` [PATCH 0/1] RFC: linux-5.15.y ksmbd backport for CVE-2023-38431 Greg KH
2023-12-12 20:13 ` [EXTERNAL] " Steven French
2023-12-12 20:52 ` Paul Gortmaker
2023-12-12 21:15 ` Steven French
2023-12-13 14:36 ` Greg KH [this message]
2023-12-13 23:31 ` Namjae Jeon
2023-12-14 8:05 ` Greg KH
2023-12-14 11:33 ` Namjae Jeon
2023-12-14 11:58 ` Greg KH
2023-12-14 13:58 ` Namjae Jeon
2023-12-12 20:45 ` Paul Gortmaker
2023-12-13 14:34 ` Greg KH
2023-12-14 3:28 ` Paul Gortmaker
2023-12-14 8:20 ` Greg KH
2023-12-15 4:18 ` Paul Gortmaker
2023-12-13 5:13 ` Namjae Jeon
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=2023121350-spearmint-manned-b7b1@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=Steven.French@microsoft.com \
--cc=linkinjeon@kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=stable@vger.kernel.org \
/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