linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve French <smfrench@gmail.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	hch@infradead.org
Subject: Re: [PATCH] fix offset checks in do_sendfile to use unsigned values
Date: Wed, 22 Jul 2009 10:28:12 -0500	[thread overview]
Message-ID: <524f69650907220828r25321e4ej6364213a97f7b63b@mail.gmail.com> (raw)
In-Reply-To: <1248272032.4534.27.camel@tlielax.poochiereds.net>

On Wed, Jul 22, 2009 at 9:13 AM, Jeff Layton<jlayton@redhat.com> wrote:
> On Wed, 2009-07-22 at 15:51 +0200, Johannes Weiner wrote:
>
>> > Any of these patches will fix the immediate problem, but I think this
>> > code in do_sendfile should still account for the possibility that
>> > someone can set the value larger than MAX_LFS_FILESIZE. An alternative
>> > is to consider a WARN at mount time when filesystems set s_maxbytes
>> > larger than that value (that might help catch out of tree filesystems
>> > that get this wrong and prevent this sort of silent bug in the future).
>>
>> Isn't MAX_LFS_FILESIZE by definition the maximum sensible value for
>> s_maxbytes?
>>
>
> Pretty much, but nothing seems to enforce it or let you know when you've
> exceeded it. It sort of seems like s_maxbytes ought to be loff_t or
> something instead of an unsigned long long. A negative value there
> wouldn't make much sense, but no one would be as tempted to set it
> higher than MAX_LFS_FILESIZE.
>
>> > Either way, the patch I posted for this isn't sufficient since there are
>> > some checks that need to be done against the signed values (the
>> > (pos < 0) check, for instance). I'll post a respun patch in a bit that
>> > should fix up those problems.
>>
>> That is already handled in rw_verify_area(), I think, so we should be
>> able to drop it completely.
>
> If we get rid of those checks altogether, then "max" will become unused.
> Is that really OK here?
>
> For discussion purposes, I've attached a replacement patch that I'm
> working with now.

Looks fine to me


-- 
Thanks,

Steve

  reply	other threads:[~2009-07-22 15:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-22 11:28 [PATCH] libfs: make get_sb_pseudo set s_maxbytes to value that can be cast to signed Jeff Layton
2009-07-22 11:28 ` [PATCH] fix offset checks in do_sendfile to use unsigned values Jeff Layton
2009-07-22 12:59   ` Johannes Weiner
2009-07-22 13:37     ` Jeff Layton
2009-07-22 13:51       ` Johannes Weiner
2009-07-22 14:13         ` Jeff Layton
2009-07-22 15:28           ` Steve French [this message]
2009-07-22 15:37           ` Johannes Weiner
2009-07-22 15:16 ` [PATCH] libfs: make get_sb_pseudo set s_maxbytes to value that can be cast to signed Steve French

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=524f69650907220828r25321e4ej6364213a97f7b63b@mail.gmail.com \
    --to=smfrench@gmail.com \
    --cc=hannes@cmpxchg.org \
    --cc=hch@infradead.org \
    --cc=jlayton@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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).