| Message ID | 20220630223258.4144112-1-vschneid@redhat.com |
|---|---|
| Headers | show |
| Series | kexec, panic: Making crash_kexec() NMI safe | expand |
Hi, On 06/30/22 at 11:32pm, Valentin Schneider wrote: > Hi folks, > > Here's ~v3~ v4 where we now completely get rid of kexec_mutex. > > o Patch 1 makes sure all kexec_mutex acquisitions are trylocks. This prevents > having to add any while(atomic_cmpxchg()) loops which I'd really hate to see > here. If that can't be done then I think we're better off with the combined > mutex+atomic var approach. > o Patch 2 does the mutex -> atomic var switch. This series looks good, has it been taken into any tree? Thanks Baoquan > > Revisions > ========= > > v3 -> v4 > ++++++++ > > o Someone forgot to Cc LKML on v3... > > v2 -> v3 > ++++++++ > > o Dropped kexec_mutex entirely and made the atomic variable the one true lock > for kexec (Eric) > > v1 -> v2 > ++++++++ > > o Changed from Peterson-like synchronization to simpler atomic_cmpxchg > (Petr) > o Slightly reworded changelog > o Added Fixes: tag. Technically should be up to since kexec can happen > in an NMI, but that isn't such a clear target > > Cheers, > Valentin > > Valentin Schneider (2): > kexec: Turn all kexec_mutex acquisitions into trylocks > panic, kexec: Make __crash_kexec() NMI safe > > include/linux/kexec.h | 2 +- > kernel/kexec.c | 11 ++++------- > kernel/kexec_core.c | 28 ++++++++++++++++------------ > kernel/kexec_file.c | 4 ++-- > kernel/kexec_internal.h | 15 ++++++++++++++- > kernel/ksysfs.c | 7 ++++++- > 6 files changed, 43 insertions(+), 24 deletions(-) > > -- > 2.31.1 >
On 12/07/22 10:47, Baoquan He wrote: > Hi, > > On 06/30/22 at 11:32pm, Valentin Schneider wrote: >> Hi folks, >> >> Here's ~v3~ v4 where we now completely get rid of kexec_mutex. >> >> o Patch 1 makes sure all kexec_mutex acquisitions are trylocks. This prevents >> having to add any while(atomic_cmpxchg()) loops which I'd really hate to see >> here. If that can't be done then I think we're better off with the combined >> mutex+atomic var approach. >> o Patch 2 does the mutex -> atomic var switch. > > This series looks good, has it been taken into any tree? > I don't think so, briefly poked around git and haven't seen it anywhere. > Thanks > Baoquan
On Tue, 12 Jul 2022 12:13:03 +0100 Valentin Schneider <vschneid@redhat.com> wrote: > On 12/07/22 10:47, Baoquan He wrote: > > Hi, > > > > On 06/30/22 at 11:32pm, Valentin Schneider wrote: > >> Hi folks, > >> > >> Here's ~v3~ v4 where we now completely get rid of kexec_mutex. > >> > >> o Patch 1 makes sure all kexec_mutex acquisitions are trylocks. This prevents > >> having to add any while(atomic_cmpxchg()) loops which I'd really hate to see > >> here. If that can't be done then I think we're better off with the combined > >> mutex+atomic var approach. > >> o Patch 2 does the mutex -> atomic var switch. > > > > This series looks good, has it been taken into any tree? > > > > I don't think so, briefly poked around git and haven't seen it anywhere. I'll stash it away for consideration after -rc1.
On Thu 2022-06-30 23:32:56, Valentin Schneider wrote: > Valentin Schneider (2): > kexec: Turn all kexec_mutex acquisitions into trylocks > panic, kexec: Make __crash_kexec() NMI safe This version looks good to me. For both patches: Reviewed-by: Petr Mladek <pmladek@suse.com> Best Regards, Petr
Hi, On 13/07/22 10:39, Andrew Morton wrote: > On Tue, 12 Jul 2022 12:13:03 +0100 Valentin Schneider <vschneid@redhat.com> wrote: > >> On 12/07/22 10:47, Baoquan He wrote: >> > Hi, >> > >> > This series looks good, has it been taken into any tree? >> > >> >> I don't think so, briefly poked around git and haven't seen it anywhere. > > I'll stash it away for consideration after -rc1. I've seen them in linux-next for a while, am I right in assuming they'll be part of a 6.1 PR?
On Mon, 03 Oct 2022 14:20:51 +0100 Valentin Schneider <vschneid@redhat.com> wrote: > > I'll stash it away for consideration after -rc1. > > I've seen them in linux-next for a while, am I right in assuming they'll be > part of a 6.1 PR? yup.