linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <josef@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	viro@zeniv.linux.org.uk, hch@infradead.org
Subject: Re: [PATCH] fs: kill default_llseek
Date: Mon, 09 May 2011 09:23:35 -0400	[thread overview]
Message-ID: <4DC7EAD7.9070606@redhat.com> (raw)
In-Reply-To: <201105081623.39876.arnd@arndb.de>

On 05/08/2011 10:23 AM, Arnd Bergmann wrote:
> On Thursday 05 May 2011 16:27:57 Josef Bacik wrote:
>> Looking at this llseek stuff I noticed that default_llseek is the exact same as
>> generic_file_llseek, so kill default_llseek.  I patched this using spatch with
>> just a simple
>>
>> @@
>> @@
>>
>> - default_llseek
>> + generic_file_llseek
>>
>> and then I manually removed the default_llseek definitions.  I've built and
>> booted this and it works fine.  Thanks,
>>
>> Signed-off-by: Josef Bacik<josef@redhat.com>
>
> Good idea in principle, but you missed the fact that generic_file_llseek
> checks (offset>  inode->i_sb->s_maxbytes), which default_llseek
> does not.
>

Right, I didn't miss it, I probably should have said this in my commit, 
but anybody who gets a super gets it from sget, which does alloc_super, 
which automatically sets s_maxbytes to MAX_NON_LFS, which is ((1UL<<31) 
- 1), plenty of size.

> This makes a huge difference on file systems that do not initialize
> s_maxbytes, leaving it at zero. In particular, it doesn't work for
> character devices, IIRC they will use whatever s_maxbytes is set for
> the file system that stores the dentry and for debugfs and other
> virtual file systems, it is not set at all.
>
> The proper fix should be to make sure all file systems set an appropriate
> s_maxbytes, and then add a special case for character devices to
> generic_file_llseek. The main reason I didn't do it last year was to
> avoid possible regressions when missing some other special cases, but
> please continue to push this once you are sure to have a correct version
> of the patch.
>

So every sb has s_maxbytes set to something, is this not acceptable for 
character devices?  I guess some can let you seek well past this point 
so we should just do some if (S_ISCHR()) return or whatever?  Thanks,

Josef

  reply	other threads:[~2011-05-09 13:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-05 14:27 [PATCH] fs: kill default_llseek Josef Bacik
2011-05-08 14:23 ` Arnd Bergmann
2011-05-09 13:23   ` Josef Bacik [this message]
2011-05-09 14:06     ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2011-05-09 18:03 Dave Anderson
2011-05-09 18:11 ` Josef Bacik
2011-05-09 18:30   ` Dave Anderson
2011-05-09 18:47     ` Josef Bacik

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=4DC7EAD7.9070606@redhat.com \
    --to=josef@redhat.com \
    --cc=arnd@arndb.de \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).