From: Greg KH <gregkh@linuxfoundation.org>
To: Linux regressions mailing list <regressions@lists.linux.dev>
Cc: Jacob Young <jacobly.alt@gmail.com>,
Linux PowerPC <linuxppc-dev@lists.ozlabs.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Memory Management <linux-mm@kvack.org>,
Bagas Sanjaya <bagasdotme@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Laurent Dufour <ldufour@linux.ibm.com>,
Suren Baghdasaryan <surenb@google.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: Fwd: Memory corruption in multithreaded user space program while calling fork
Date: Wed, 5 Jul 2023 10:27:45 +0100 [thread overview]
Message-ID: <2023070544-porous-prenatal-406a@gregkh> (raw)
In-Reply-To: <7668c45a-70b1-dc2f-d0f5-c0e76ec17145@leemhuis.info>
On Wed, Jul 05, 2023 at 10:51:57AM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 05.07.23 09:08, Greg KH wrote:
> > On Tue, Jul 04, 2023 at 01:22:54PM -0700, Suren Baghdasaryan wrote:
> >> On Tue, Jul 4, 2023 at 9:18 AM Andrew Morton <akpm@linux-foundation.org> wrote:
> >>> On Tue, 4 Jul 2023 09:00:19 +0100 Greg KH <gregkh@linuxfoundation.org> wrote:
> >>>>>>>> Thanks! I'll investigate this later today. After discussing with
> >>>>>>>> Andrew, we would like to disable CONFIG_PER_VMA_LOCK by default until
> >>>>>>>> the issue is fixed. I'll post a patch shortly.
> >>>>>>>
> >>>>>>> Posted at: https://lore.kernel.org/all/20230703182150.2193578-1-surenb@google.com/
> >>>>>>
> >>>>>> As that change fixes something in 6.4, why not cc: stable on it as well?
> >>>>>
> >>>>> Sorry, I thought since per-VMA locks were introduced in 6.4 and this
> >>>>> patch is fixing 6.4 I didn't need to send it to stable for older
> >>>>> versions. Did I miss something?
> >>>>
> >>>> 6.4.y is a stable kernel tree right now, so yes, it needs to be included
> >>>> there :)
> >>>
> >>> I'm in wait-a-few-days-mode on this. To see if we have a backportable
> >>> fix rather than disabling the feature in -stable.
>
> Andrew, how long will you remain in "wait-a-few-days-mode"? Given what
> Greg said below and that we already had three reports I know of I'd
> prefer if we could fix this rather sooner than later in mainline --
> especially as Arch Linux and openSUSE Tumbleweed likely have switched to
> 6.4.y already or will do so soon.
Ick, yeah, and Fedora should be switching soon too, and I want to drop
support for 6.3.y "any day now". Is there just a revert we can do now
first to resolve the regression and then work on fixing this up "better"
for 6.6-rc1?
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Linux regressions mailing list <regressions@lists.linux.dev>
Cc: Suren Baghdasaryan <surenb@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Bagas Sanjaya <bagasdotme@gmail.com>,
Jacob Young <jacobly.alt@gmail.com>,
Laurent Dufour <ldufour@linux.ibm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Memory Management <linux-mm@kvack.org>,
Linux PowerPC <linuxppc-dev@lists.ozlabs.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: Fwd: Memory corruption in multithreaded user space program while calling fork
Date: Wed, 5 Jul 2023 10:27:45 +0100 [thread overview]
Message-ID: <2023070544-porous-prenatal-406a@gregkh> (raw)
In-Reply-To: <7668c45a-70b1-dc2f-d0f5-c0e76ec17145@leemhuis.info>
On Wed, Jul 05, 2023 at 10:51:57AM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 05.07.23 09:08, Greg KH wrote:
> > On Tue, Jul 04, 2023 at 01:22:54PM -0700, Suren Baghdasaryan wrote:
> >> On Tue, Jul 4, 2023 at 9:18 AM Andrew Morton <akpm@linux-foundation.org> wrote:
> >>> On Tue, 4 Jul 2023 09:00:19 +0100 Greg KH <gregkh@linuxfoundation.org> wrote:
> >>>>>>>> Thanks! I'll investigate this later today. After discussing with
> >>>>>>>> Andrew, we would like to disable CONFIG_PER_VMA_LOCK by default until
> >>>>>>>> the issue is fixed. I'll post a patch shortly.
> >>>>>>>
> >>>>>>> Posted at: https://lore.kernel.org/all/20230703182150.2193578-1-surenb@google.com/
> >>>>>>
> >>>>>> As that change fixes something in 6.4, why not cc: stable on it as well?
> >>>>>
> >>>>> Sorry, I thought since per-VMA locks were introduced in 6.4 and this
> >>>>> patch is fixing 6.4 I didn't need to send it to stable for older
> >>>>> versions. Did I miss something?
> >>>>
> >>>> 6.4.y is a stable kernel tree right now, so yes, it needs to be included
> >>>> there :)
> >>>
> >>> I'm in wait-a-few-days-mode on this. To see if we have a backportable
> >>> fix rather than disabling the feature in -stable.
>
> Andrew, how long will you remain in "wait-a-few-days-mode"? Given what
> Greg said below and that we already had three reports I know of I'd
> prefer if we could fix this rather sooner than later in mainline --
> especially as Arch Linux and openSUSE Tumbleweed likely have switched to
> 6.4.y already or will do so soon.
Ick, yeah, and Fedora should be switching soon too, and I want to drop
support for 6.3.y "any day now". Is there just a revert we can do now
first to resolve the regression and then work on fixing this up "better"
for 6.6-rc1?
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Linux regressions mailing list <regressions@lists.linux.dev>
Cc: Suren Baghdasaryan <surenb@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Bagas Sanjaya <bagasdotme@gmail.com>,
Jacob Young <jacobly.alt@gmail.com>,
Laurent Dufour <ldufour@linux.ibm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Memory Management <linux-mm@kvack.org>,
Linux PowerPC <linuxppc-dev@lists.ozlabs.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: Fwd: Memory corruption in multithreaded user space program while calling fork
Date: Wed, 5 Jul 2023 10:27:45 +0100 [thread overview]
Message-ID: <2023070544-porous-prenatal-406a@gregkh> (raw)
In-Reply-To: <7668c45a-70b1-dc2f-d0f5-c0e76ec17145@leemhuis.info>
On Wed, Jul 05, 2023 at 10:51:57AM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 05.07.23 09:08, Greg KH wrote:
> > On Tue, Jul 04, 2023 at 01:22:54PM -0700, Suren Baghdasaryan wrote:
> >> On Tue, Jul 4, 2023 at 9:18 AM Andrew Morton <akpm@linux-foundation.org> wrote:
> >>> On Tue, 4 Jul 2023 09:00:19 +0100 Greg KH <gregkh@linuxfoundation.org> wrote:
> >>>>>>>> Thanks! I'll investigate this later today. After discussing with
> >>>>>>>> Andrew, we would like to disable CONFIG_PER_VMA_LOCK by default until
> >>>>>>>> the issue is fixed. I'll post a patch shortly.
> >>>>>>>
> >>>>>>> Posted at: https://lore.kernel.org/all/20230703182150.2193578-1-surenb@google.com/
> >>>>>>
> >>>>>> As that change fixes something in 6.4, why not cc: stable on it as well?
> >>>>>
> >>>>> Sorry, I thought since per-VMA locks were introduced in 6.4 and this
> >>>>> patch is fixing 6.4 I didn't need to send it to stable for older
> >>>>> versions. Did I miss something?
> >>>>
> >>>> 6.4.y is a stable kernel tree right now, so yes, it needs to be included
> >>>> there :)
> >>>
> >>> I'm in wait-a-few-days-mode on this. To see if we have a backportable
> >>> fix rather than disabling the feature in -stable.
>
> Andrew, how long will you remain in "wait-a-few-days-mode"? Given what
> Greg said below and that we already had three reports I know of I'd
> prefer if we could fix this rather sooner than later in mainline --
> especially as Arch Linux and openSUSE Tumbleweed likely have switched to
> 6.4.y already or will do so soon.
Ick, yeah, and Fedora should be switching soon too, and I want to drop
support for 6.3.y "any day now". Is there just a revert we can do now
first to resolve the regression and then work on fixing this up "better"
for 6.6-rc1?
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-07-05 9:28 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-02 12:27 Fwd: Memory corruption in multithreaded user space program while calling fork Bagas Sanjaya
2023-07-02 12:27 ` Bagas Sanjaya
2023-07-02 12:27 ` Bagas Sanjaya
2023-07-02 12:40 ` Jacob Young
2023-07-02 12:40 ` Jacob Young
2023-07-02 14:11 ` Bagas Sanjaya
2023-07-02 14:11 ` Bagas Sanjaya
2023-07-02 14:11 ` Bagas Sanjaya
2023-07-03 9:53 ` Fwd: " Linux regression tracking (Thorsten Leemhuis)
2023-07-03 9:53 ` Linux regression tracking (Thorsten Leemhuis)
2023-07-03 9:53 ` Linux regression tracking (Thorsten Leemhuis)
2023-07-03 18:08 ` Suren Baghdasaryan
2023-07-03 18:08 ` Suren Baghdasaryan
2023-07-03 18:08 ` Suren Baghdasaryan
2023-07-03 18:27 ` Suren Baghdasaryan
2023-07-03 18:27 ` Suren Baghdasaryan
2023-07-03 18:27 ` Suren Baghdasaryan
2023-07-03 18:44 ` Greg KH
2023-07-03 18:44 ` Greg KH
2023-07-03 18:44 ` Greg KH
2023-07-04 7:45 ` Suren Baghdasaryan
2023-07-04 7:45 ` Suren Baghdasaryan
2023-07-04 7:45 ` Suren Baghdasaryan
2023-07-04 8:00 ` Greg KH
2023-07-04 8:00 ` Greg KH
2023-07-04 8:00 ` Greg KH
2023-07-04 16:18 ` Andrew Morton
2023-07-04 16:18 ` Andrew Morton
2023-07-04 16:18 ` Andrew Morton
2023-07-04 20:22 ` Suren Baghdasaryan
2023-07-04 20:22 ` Suren Baghdasaryan
2023-07-04 20:22 ` Suren Baghdasaryan
2023-07-04 21:28 ` Andrew Morton
2023-07-04 21:28 ` Andrew Morton
2023-07-04 21:28 ` Andrew Morton
2023-07-04 22:04 ` Suren Baghdasaryan
2023-07-04 22:04 ` Suren Baghdasaryan
2023-07-04 22:04 ` Suren Baghdasaryan
2023-07-05 6:42 ` Suren Baghdasaryan
2023-07-05 6:42 ` Suren Baghdasaryan
2023-07-05 6:42 ` Suren Baghdasaryan
2023-07-05 7:08 ` Greg KH
2023-07-05 7:08 ` Greg KH
2023-07-05 7:08 ` Greg KH
2023-07-05 8:51 ` Linux regression tracking (Thorsten Leemhuis)
2023-07-05 8:51 ` Linux regression tracking (Thorsten Leemhuis)
2023-07-05 8:51 ` Linux regression tracking (Thorsten Leemhuis)
2023-07-05 9:27 ` Greg KH [this message]
2023-07-05 9:27 ` Greg KH
2023-07-05 9:27 ` Greg KH
2023-07-05 15:49 ` Andrew Morton
2023-07-05 15:49 ` Andrew Morton
2023-07-05 15:49 ` Andrew Morton
2023-07-05 16:14 ` Suren Baghdasaryan
2023-07-05 16:14 ` Suren Baghdasaryan
2023-07-05 16:14 ` Suren Baghdasaryan
2023-07-05 17:17 ` Suren Baghdasaryan
2023-07-05 17:17 ` Suren Baghdasaryan
2023-07-05 17:17 ` Suren Baghdasaryan
2023-07-08 11:35 ` Thorsten Leemhuis
2023-07-08 11:35 ` Thorsten Leemhuis
2023-07-08 11:35 ` Thorsten Leemhuis
2023-07-08 17:29 ` Linus Torvalds
2023-07-08 17:29 ` Linus Torvalds
2023-07-08 17:29 ` Linus Torvalds
2023-07-08 17:39 ` Andrew Morton
2023-07-08 17:39 ` Andrew Morton
2023-07-08 17:39 ` Andrew Morton
2023-07-08 18:04 ` Linus Torvalds
2023-07-08 18:04 ` Linus Torvalds
2023-07-08 18:04 ` Linus Torvalds
2023-07-08 18:40 ` Suren Baghdasaryan
2023-07-08 18:40 ` Suren Baghdasaryan
2023-07-08 18:40 ` Suren Baghdasaryan
2023-07-08 19:05 ` Linus Torvalds
2023-07-08 19:05 ` Linus Torvalds
2023-07-08 19:05 ` Linus Torvalds
2023-07-08 19:17 ` Suren Baghdasaryan
2023-07-08 19:17 ` Suren Baghdasaryan
2023-07-08 19:17 ` Suren Baghdasaryan
2023-07-08 19:22 ` Linus Torvalds
2023-07-08 19:22 ` Linus Torvalds
2023-07-08 19:22 ` Linus Torvalds
2023-07-08 19:41 ` Suren Baghdasaryan
2023-07-08 19:41 ` Suren Baghdasaryan
2023-07-08 19:41 ` Suren Baghdasaryan
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=2023070544-porous-prenatal-406a@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=bagasdotme@gmail.com \
--cc=jacobly.alt@gmail.com \
--cc=ldufour@linux.ibm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=regressions@lists.linux.dev \
--cc=surenb@google.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 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.