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
next prev parent 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).