From: Jason Gunthorpe <jgg@nvidia.com>
To: "Ahmed S. Darwish" <a.darwish@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
"Paul E. McKenney" <paulmck@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Jonathan Corbet <corbet@lwn.net>,
John Hubbard <jhubbard@nvidia.com>,
LKML <linux-kernel@vger.kernel.org>,
"Sebastian A. Siewior" <bigeasy@linutronix.de>
Subject: Re: [PATCH -tip v1 3/3] seqlock: kernel-doc: Specify when preemption is automatically altered
Date: Tue, 8 Dec 2020 11:46:51 -0400 [thread overview]
Message-ID: <20201208154651.GN552508@nvidia.com> (raw)
In-Reply-To: <X8+OS/K0+9ibIEGz@lx-t490>
On Tue, Dec 08, 2020 at 03:31:39PM +0100, Ahmed S. Darwish wrote:
> Hi Jason,
>
> On Mon, Dec 07, 2020 at 04:43:16PM -0400, Jason Gunthorpe wrote:
> ...
> >
> > The thing that was confusing is if it was appropriate to use a
> > seqcount in case where write side preemption was not disabled - which
> > is safe only if the read side doesn't spin.
> >
>
> No, that's not correct.
Well, that is where I started from.. seqcount in normal pre-emption
disabled cases was well understood, I needed a no-pre-emption disable
case.
> For developers who're advanced enough to know the difference, they don't
> need the kernel-doc anyway. And that's why I've kindly asked to add the
> following to your mm/ patch (which you did, thanks):
That is probably over stating things quite a lot. If there are valid
locking patterns then I think we should document them, otherwise
people simply do something crazy and get it wrong.
It was not entirely easy to figure out why preemption disable is
necessary here, though in hindsight it is obvious..
Jason
next prev parent reply other threads:[~2020-12-08 15:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-06 16:21 [PATCH -tip v1 0/3] seqlock: assorted cleanups Ahmed S. Darwish
2020-12-06 16:21 ` [PATCH -tip v1 1/3] Documentation: seqlock: s/LOCKTYPE/LOCKNAME/g Ahmed S. Darwish
2020-12-09 18:38 ` [tip: locking/core] " tip-bot2 for Ahmed S. Darwish
2020-12-06 16:21 ` [PATCH -tip v1 2/3] seqlock: Prefix internal seqcount_t-only macros with a "do_" Ahmed S. Darwish
2020-12-07 20:39 ` Jason Gunthorpe
2020-12-06 16:21 ` [PATCH -tip v1 3/3] seqlock: kernel-doc: Specify when preemption is automatically altered Ahmed S. Darwish
2020-12-07 20:43 ` Jason Gunthorpe
2020-12-08 14:31 ` Ahmed S. Darwish
2020-12-08 15:46 ` Jason Gunthorpe [this message]
2020-12-07 14:07 ` [PATCH -tip v1 0/3] seqlock: assorted cleanups Peter Zijlstra
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=20201208154651.GN552508@nvidia.com \
--to=jgg@nvidia.com \
--cc=a.darwish@linutronix.de \
--cc=bigeasy@linutronix.de \
--cc=corbet@lwn.net \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=will@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;
as well as URLs for NNTP newsgroup(s).