From: Steven Whitehouse <swhiteho@redhat.com>
To: Rob Jones <rob.jones@codethink.co.uk>,
"Eric W. Biederman" <ebiederm@xmission.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-kernel@lists.codethink.co.uk,
ian.molton@codethink.co.uk
Subject: Re: [PATCH] seq_file: Allow private data to be supplied on seq_open
Date: Thu, 07 Aug 2014 14:32:15 +0100 [thread overview]
Message-ID: <53E37FDF.50102@redhat.com> (raw)
In-Reply-To: <53E37810.1050109@codethink.co.uk>
Hi,
On 07/08/14 13:58, Rob Jones wrote:
[snip]
>
> On a related subject, Having looked at a few uses of seq_file, I must
> say that some users seem to make assumptions about the internal
> workings of the module. Dangerous behaviour as only some behaviours are
> documented.
>
> e.g. The behaviour that "struct seq_file" pointer is stored in
> file->private_data is documented and can therefore be relied upon but
> the fact that the output buffer and its size are only defined at the
> first output (and can therefore be pre-defined and pre-allocated by
> user code) is not documented and could therefore change without warning.
>
> This second behaviour is assumed in, for example, module fs/gfs2/glock.c
> which could, therefore, stop working properly without warning if the
> internal behaviour was changed.
>
While it is undocumented, it is I understand, how this feature was
intended to be used, so I think that it is safe to do this in the GFS2
case. Here is a ref to the thread which explains how it landed up like that:
https://www.redhat.com/archives/cluster-devel/2012-June/msg00000.html
Steve.
next prev parent reply other threads:[~2014-08-07 13:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-29 17:39 [PATCH] seq_file: Allow private data to be supplied on seq_open Rob Jones
2014-08-06 15:56 ` Rob Jones
2014-08-06 16:02 ` Al Viro
2014-08-06 16:16 ` Rob Jones
2014-08-06 19:14 ` Eric W. Biederman
2014-08-07 12:58 ` Rob Jones
2014-08-07 13:32 ` Steven Whitehouse [this message]
2014-08-07 14:09 ` Rob Jones
2014-08-07 14:16 ` [Linux-kernel] " Rob Jones
2014-08-07 14:22 ` Steven Whitehouse
2014-08-07 14:30 ` Rob Jones
2014-08-06 19:53 ` Al Viro
2014-08-07 1:03 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53E37FDF.50102@redhat.com \
--to=swhiteho@redhat.com \
--cc=ebiederm@xmission.com \
--cc=ian.molton@codethink.co.uk \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@lists.codethink.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=rob.jones@codethink.co.uk \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.