[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201026093821.GG2628@hirez.programming.kicks-ass.net>
Date: Mon, 26 Oct 2020 10:38:21 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc: Jonathan Corbet <corbet@....net>,
Kees Cook <keescook@...omium.org>,
Linux Doc Mailing List <linux-doc@...r.kernel.org>,
Ard Biesheuvel <ardb@...nel.org>,
Ingo Molnar <mingo@...nel.org>, Jann Horn <jannh@...gle.com>,
Will Deacon <will@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 49/56] refcount.h: fix a kernel-doc markup
On Mon, Oct 26, 2020 at 10:16:20AM +0100, Mauro Carvalho Chehab wrote:
> Em Mon, 26 Oct 2020 09:10:59 +0100
> Peter Zijlstra <peterz@...radead.org> escreveu:
>
> > On Sat, Oct 24, 2020 at 08:28:27AM +0200, Mauro Carvalho Chehab wrote:
> > > If the intent is to document the struct and its internal fields,
> > > this kernel-doc should work:
> > >
> > > /**
> > > * struct refcount_struct - variant of atomic_t specialized for reference counts
> > > * @refs: atomic_t counter field
> > > *
> > > * The counter saturates at REFCOUNT_SATURATED and will not move once
> > > * there. This avoids wrapping the counter and causing 'spurious'
> > > * use-after-free bugs.
> > > */
> > >
> > > Which produces this result:
> >
> > Who cares... :-(
>
> Anyone that would need to use refcount_t, instead of atomic_t.
They can read the .h file just fine today.
Powered by blists - more mailing lists