On Mon 03-07-23 09:09:46, Tetsuo Handa wrote:
> Nacked-by: Tetsuo Handa <[email protected]>
>
> because of https://lkml.kernel.org/r/[email protected] .
This is not really productive approach! You are rising non-material
concerns you haven't proven to be real. This is blocking otherwise
useful fix. I am completely fine recording your nack with a reference to
your concern should we ever trip over your concerns and so we can easily
revert and find a different solution but I do not believe this should
stand in the way in the fix.
Now concerning the patch 1 in the series, I do agree this should be
passing through the lockdep maintainers. But this fix is not really
dependent on it.
> On 2023/07/03 8:40, Andrew Morton wrote:
> > The patch titled
> > Subject: mm/page_alloc: use write_seqlock_irqsave() instead write_seqlock() + local_irq_save().
> > has been added to the -mm mm-unstable branch. Its filename is
> > mm-page_alloc-use-write_seqlock_irqsave-instead-write_seqlock-local_irq_save.patch
> >
> > This patch will shortly appear at
> > https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-page_alloc-use-write_seqlock_irqsave-instead-write_seqlock-local_irq_save.patch
> >
> > This patch will later appear in the mm-unstable branch at
> > git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> >
> > Before you just go and hit "reply", please:
> > a) Consider who else should be cc'ed
> > b) Prefer to cc a suitable mailing list as well
> > c) Ideally: find the original patch on the mailing list and do a
> > reply-to-all to that, adding suitable additional cc's
> >
> > *** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
> >
> > The -mm tree is included into linux-next via the mm-everything
> > branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> > and is updated there every 2-3 working days
--
Michal Hocko
SUSE Labs
On 2023-07-03 10:00:47 [+0200], Michal Hocko wrote:
> On Mon 03-07-23 09:09:46, Tetsuo Handa wrote:
> > Nacked-by: Tetsuo Handa <[email protected]>
> >
> > because of https://lkml.kernel.org/r/[email protected] .
>
> This is not really productive approach! You are rising non-material
> concerns you haven't proven to be real. This is blocking otherwise
> useful fix. I am completely fine recording your nack with a reference to
> your concern should we ever trip over your concerns and so we can easily
> revert and find a different solution but I do not believe this should
> stand in the way in the fix.
>
> Now concerning the patch 1 in the series, I do agree this should be
> passing through the lockdep maintainers. But this fix is not really
> dependent on it.
I fully agree here.
Sebastian