Messages in this thread | | | Date | Thu, 29 Feb 2024 21:05:15 +0100 | From | Greg Kroah-Hartman <> | Subject | Re: CVE-2023-52437: Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d" |
| |
On Thu, Feb 29, 2024 at 11:53:56AM +0100, Paolo Bonzini wrote: > On Thu, Feb 29, 2024 at 7:05 AM Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > > > On Thu, Feb 29, 2024 at 06:32:03AM +0100, Greg Kroah-Hartman wrote: > > > On Thu, Feb 22, 2024 at 02:31:06PM +0100, Paolo Bonzini wrote: > > > > So if the reply-to points to LKML + the subsystem mailing > > > > list for the maintainers + a new ML for the security folks (and these three > > > > are also CC'd on the announcements, at least the last two), that would be > > > > nice to have. I can work on patches to vulns.git, for example to integrate > > > > with get_maintainer.pl, if you ack the idea. > > > > > > That might be a bit noisy, for some commits, but sure, I can see the > > > value in being notified about a CVE for my subsystem. If you have a > > > specific 'get_maintainer.pl' command line invocation you think would be > > > good, I can easily add it to the scripts. > > > > Would: > > --no-keywords --no-git --no-git-fallback --norolestats --nol > > > > be a good pattern to follow? > > I would include lists as well. it would be nice to exclude > reviewed-bys but that's not easy to do in get_maintainer.pI
That would hit lkml for everything, which is probably not a good idea :(
I think maintainers for now would be a good start, let me see about adding that the next chance I get.
thanks,
greg k-h
| |