Re: [PATCH -tip v1 3/3] seqlock: kernel-doc: Specify when preemption is automatically altered

[Jason Gunthorpe <jgg@nvidia.com>]

On Sun, Dec 06, 2020 at 05:21:43PM +0100, Ahmed S. Darwish wrote:
> @@ -519,11 +524,10 @@ static inline void do_write_seqcount_begin_nested(seqcount_t *s, int subclass)
>   * write_seqcount_begin() - start a seqcount_t write side critical section
>   * @s: Pointer to seqcount_t or any of the seqcount_LOCKNAME_t variants
>   *
> - * write_seqcount_begin opens a write side critical section of the given
> - * seqcount_t.
> - *
> - * Context: seqcount_t write side critical sections must be serialized and
> - * non-preemptible. If readers can be invoked from hardirq or softirq
> + * Context: sequence counter write side sections must be serialized and
> + * non-preemptible. Preemption will be automatically disabled if and
> + * only if the seqcount write serialization lock is associated, and
> + * preemptible.  If readers can be invoked from hardirq or softirq
>   * context, interrupts or bottom halves must be respectively disabled.
>   */

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.

We seem to have only two places that do this, but since this comment
reads like it is absolutely forbidden, it is still confusing..

To make it clear a read side API to work with the seqlock for
non-premption cases would be nice, then the language could be 'must be
non-premeptible if using read_seqcount_retry(), but if using NEWTHING
then it is not required'

Jason