Re: [PATCH RESUBMIT 0/2] fs/seq_file: Add seq_open_init()
From: Kees Cook
Date: Thu Sep 25 2014 - 12:09:22 EST
On Thu, Sep 25, 2014 at 1:57 AM, Rob Jones <rob.jones@xxxxxxxxxxxxxxx> wrote:
> On 24/09/14 19:06, Kees Cook wrote:
>> On Wed, Sep 24, 2014 at 4:15 AM, Rob Jones <rob.jones@xxxxxxxxxxxxxxx>
>>> Series resubmitted due to a typo in an email address.
>>> This patch series implements and documents a new interface function for
>>> The existing set of open functions: seq_open(), seq_open_private() and
>>> __seq_open_private() satisfy the majority of use cases however there is
>>> one more use case that is also very common that this new function
>>> This case is where the iterator needs information that is available only
>>> the time the seq_file is opened but does not need any space allocated,
>>> access to the inode structure. This type of open occurs, by my best
>>> in well over 40 places.
>>> Using the new function saves at least two lines of boilerplate code per
>>> instance as well as making the code easier to follow. The additional code
>>> in seq_file.c to implement the function is minimal as the first place
>>> code can be removed is within seq_file.c itself.
>>> Once this patch is accepted, the instances of boilerplate code can be
>> Would it be possible to write a coccinelle patch for the replacements?
> I'm afraid I don't know what that means.
It's a very flexible tool that should be able to find all the places
where this pattern is being used, and you can replace it with the new
Chrome OS Security
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/