[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180212113633.GC20737@rapoport-lnx>
Date: Mon, 12 Feb 2018 13:36:33 +0200
From: Mike Rapoport <rppt@...ux.vnet.ibm.com>
To: Igor Stoppa <igor.stoppa@...wei.com>
Cc: willy@...radead.org, rdunlap@...radead.org, corbet@....net,
keescook@...omium.org, mhocko@...nel.org, labbott@...hat.com,
jglisse@...hat.com, hch@...radead.org, cl@...ux.com,
linux-security-module@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH 1/6] genalloc: track beginning of allocations
On Mon, Feb 12, 2018 at 01:17:01PM +0200, Igor Stoppa wrote:
>
>
> On 11/02/18 14:24, Mike Rapoport wrote:
> > On Sun, Feb 11, 2018 at 05:19:15AM +0200, Igor Stoppa wrote:
> [...]
>
> >> +/**
> >> + * mem_to_units - convert references to memory into orders of allocation
> >
> > Documentation/doc-guide/kernel-doc.rst recommends to to include brackets
> > for function comments. I haven't noticed any difference in the resulting
> > html, so I'm not sure if the brackets are actually required.
>
> This is what I see in the example from mailine docs:
>
> /**
> * foobar() - Brief description of foobar.
> * @argument1: Description of parameter argument1 of foobar.
> * @argument2: Description of parameter argument2 of foobar.
> *
> * Longer description of foobar.
> *
> * Return: Description of return value of foobar.
> */
> int foobar(int argument1, char *argument2)
>
>
> What are you referring to?
I'm referring to "foobar() - brief description" vs "foobar - brief
description".
The generated html looks exactly the same in the browser, so I don't know
if the brackets are really required.
> [...]
>
> >> + * @size: amount in bytes
> >> + * @order: power of 2 represented by each entry in the bitmap
> >> + *
> >> + * Returns the number of units representing the size.
> >
> > Please s/Return/Return:/
>
> :-( I thought I had fixed them all. thanks for spotting this.
>
> [...]
>
> >> + * Return: If two users alter the same bit, to one it will return
> >> + * remaining entries, to the other it will return 0.
> >
> > And what if there are three or four concurrent users? ;-)
> >
> > I believe that a more elaborate description about what happens with
> > concurrent attempts to alter the bitmap would be really helpful.
>
> ok
>
> --
> thanks, igor
>
--
Sincerely yours,
Mike.
Powered by blists - more mailing lists