linux-kernel - Re: [PATCH v2] seqlock: <linux/seqlock.h>: fix multiple kernel-doc warnings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 19 Aug 2020 09:52:28 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     peterz@...radead.org
Cc:     linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
        kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v2] seqlock: <linux/seqlock.h>: fix multiple kernel-doc
 warnings

On 8/19/20 2:25 AM, peterz@...radead.org wrote:
> On Sun, Aug 16, 2020 at 05:02:00PM -0700, Randy Dunlap wrote:
> 
>> --- lnx-59-rc1.orig/include/linux/seqlock.h
>> +++ lnx-59-rc1/include/linux/seqlock.h
> 
>> @@ -173,7 +173,6 @@ seqcount_##lockname##_init(seqcount_##lo
>>  	seqcount_init(&s->seqcount);					\
>>  	__SEQ_LOCK(s->lock = lock);					\
>>  }									\
>> -									\
>>  static __always_inline seqcount_t *					\
>>  __seqcount_##lockname##_ptr(seqcount_##lockname##_t *s)			\
>>  {									\
> 
> I think I'd rather like that empty line there..
> 
>> @@ -218,9 +217,9 @@ SEQCOUNT_LOCKTYPE(struct mutex,		mutex,
>>  SEQCOUNT_LOCKTYPE(struct ww_mutex,	ww_mutex,	true,	&s->lock->base)
>>  
>>  /**
>> - * SEQCNT_LOCKNAME_ZERO - static initializer for seqcount_LOCKNAME_t
>> - * @name:	Name of the seqcount_LOCKNAME_t instance
>> - * @lock:	Pointer to the associated LOCKTYPE
>> + * SEQCOUNT_LOCKTYPE_ZERO - static initializer for seqcount_LOCKNAME_t
>> + * @seq_name:	Name of the seqcount_LOCKNAME_t instance
>> + * @assoc_lock:	Pointer to the associated LOCKTYPE
>>   */
>>  
>>  #define SEQCOUNT_LOCKTYPE_ZERO(seq_name, assoc_lock) {			\
> 
> And this hunk seems wrong, SEQCOUNT_LOCKTYPE_ZERO() is not the intended
> API, SEQCNT_*_ZERO() are.
> 
> 
> I've edited the patch like below, is that OK with you?

Hi Peter,
Yes, this looks good. Thanks for your help.


> ---
> Subject: seqlock: Fix multiple kernel-doc warnings
> From: Randy Dunlap <rdunlap@...radead.org>
> Date: Sun, 16 Aug 2020 17:02:00 -0700
> 
> From: Randy Dunlap <rdunlap@...radead.org>
> 
> Fix kernel-doc warnings in <linux/seqlock.h>.
> 
> ../include/linux/seqlock.h:152: warning: Incorrect use of kernel-doc format:  * seqcount_LOCKNAME_init() - runtime initializer for seqcount_LOCKNAME_t
> ../include/linux/seqlock.h:164: warning: Incorrect use of kernel-doc format:  * SEQCOUNT_LOCKTYPE() - Instantiate seqcount_LOCKNAME_t and helpers
> ../include/linux/seqlock.h:229: warning: Function parameter or member 'seq_name' not described in 'SEQCOUNT_LOCKTYPE_ZERO'
> ../include/linux/seqlock.h:229: warning: Function parameter or member 'assoc_lock' not described in 'SEQCOUNT_LOCKTYPE_ZERO'
> ../include/linux/seqlock.h:229: warning: Excess function parameter 'name' description in 'SEQCOUNT_LOCKTYPE_ZERO'
> ../include/linux/seqlock.h:229: warning: Excess function parameter 'lock' description in 'SEQCOUNT_LOCKTYPE_ZERO'
> ../include/linux/seqlock.h:695: warning: duplicate section name 'NOTE'
> 
> Demote kernel-doc notation for the macros "seqcount_LOCKNAME_init()" and
> "SEQCOUNT_LOCKTYPE()"; scripts/kernel-doc does not handle them correctly.
> 
> Rename function parameters in SEQCNT_LOCKNAME_ZERO() documentation
> to match the macro's argument names. Change the macro name in the
> documentation to SEQCOUNT_LOCKTYPE_ZERO() to match the macro's name.
> 
> For raw_write_seqcount_latch(), rename the second NOTE: to NOTE2:
> to prevent a kernel-doc warning. However, the generated output is not
> quite as nice as it could be for this.
> 
> Fix a typo: s/LOCKTYPR/LOCKTYPE/
> 
> Fixes: 0efc94c5d15c ("seqcount: Compress SEQCNT_LOCKNAME_ZERO()")
> Fixes: e4e9ab3f9f91 ("seqlock: Fold seqcount_LOCKNAME_init() definition")
> Fixes: a8772dccb2ec ("seqlock: Fold seqcount_LOCKNAME_t definition")
> Reported-by: kernel test robot <lkp@...el.com>
> Signed-off-by: Randy Dunlap <rdunlap@...radead.org>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> Link: https://lkml.kernel.org/r/20200817000200.20993-1-rdunlap@infradead.org
> ---
> v2: do not move the definition of seqcount_LOCKNAME_init().
> Fix build errors reported by kernel test robot.
> Actually build a kernel with these changes.
> 
>  include/linux/seqlock.h |    8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> --- a/include/linux/seqlock.h
> +++ b/include/linux/seqlock.h
> @@ -138,7 +138,7 @@ static inline void seqcount_lockdep_read
>  #endif
>  
>  /**
> - * typedef seqcount_LOCKNAME_t - sequence counter with LOCKTYPR associated
> + * typedef seqcount_LOCKNAME_t - sequence counter with LOCKTYPE associated
>   * @seqcount:	The real sequence counter
>   * @lock:	Pointer to the associated spinlock
>   *
> @@ -148,7 +148,7 @@ static inline void seqcount_lockdep_read
>   * that the write side critical section is properly serialized.
>   */
>  
> -/**
> +/*
>   * seqcount_LOCKNAME_init() - runtime initializer for seqcount_LOCKNAME_t
>   * @s:		Pointer to the seqcount_LOCKNAME_t instance
>   * @lock:	Pointer to the associated LOCKTYPE
> @@ -217,7 +217,7 @@ SEQCOUNT_LOCKTYPE(rwlock_t,		rwlock,		fa
>  SEQCOUNT_LOCKTYPE(struct mutex,		mutex,		true,	s->lock)
>  SEQCOUNT_LOCKTYPE(struct ww_mutex,	ww_mutex,	true,	&s->lock->base)
>  
> -/**
> +/*
>   * SEQCNT_LOCKNAME_ZERO - static initializer for seqcount_LOCKNAME_t
>   * @name:	Name of the seqcount_LOCKNAME_t instance
>   * @lock:	Pointer to the associated LOCKTYPE
> @@ -688,7 +688,7 @@ static inline int raw_read_seqcount_t_la
>   *	to miss an entire modification sequence, once it resumes it might
>   *	observe the new entry.
>   *
> - * NOTE:
> + * NOTE2:
>   *
>   *	When data is a dynamic data structure; one should use regular RCU
>   *	patterns to manage the lifetimes of the objects within.
> 


-- 
~Randy
Reported-by: Randy Dunlap <rdunlap@...radead.org>