From: Al Viro <viro@ZenIV.linux.org.uk>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Chen Gang <gang.chen@asianux.com>,
Kees Cook <keescook@chromium.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Serge Hallyn <serge.hallyn@canonical.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] fs/befs/linuxvfs.c: need signed cast for variable 'block'
Date: Sat, 2 Nov 2013 16:27:45 +0000 [thread overview]
Message-ID: <20131102162744.GJ13318@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20131102154446.GB23938@kroah.com>
On Sat, Nov 02, 2013 at 08:44:46AM -0700, Greg KH wrote:
> > Oh, for me, it is not suitable to move a file system sub-directory to
> > "drivers/*/" sub-directory. And I can not find any sub-directory like
> > 'staging' under "fs" sub-directory, either.
> >
> > Do we have any sub-directory like "staging" in "fs" sub-directory? if
> > no, do we have to create it or have to use another ways instead of?
>
> Just move the filesystem to drivers/staging/befs.
Actually, having read through that code... It's not too scary; r/w
support would've been much more hairy, but this is just r/o. We
probably don't need to move that sucker at all.
As for befs_get_block(), I'd suggest
* taking the range checks for block number into its ->bmap()
(just check against the file size and return 0 if it doesn't fit)
* turning the check for create != 0 into BUG_ON(create)
* making the befs_fblock2brun() failure quiet - the sucker
will complain itself, just return that -EFBIG and be done with that.
next prev parent reply other threads:[~2013-11-02 16:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-31 2:52 [PATCH] fs/befs/linuxvfs.c: need signed cast for variable 'block' Chen Gang
2013-10-31 16:53 ` Kees Cook
2013-10-31 19:06 ` Al Viro
2013-10-31 19:08 ` Kees Cook
2013-10-31 20:45 ` Greg KH
2013-11-01 2:41 ` Chen Gang
2013-11-02 13:46 ` Chen Gang
2013-11-02 15:44 ` Greg KH
2013-11-02 16:27 ` Al Viro [this message]
2013-11-03 12:41 ` Chen Gang
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=20131102162744.GJ13318@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=ebiederm@xmission.com \
--cc=gang.chen@asianux.com \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=serge.hallyn@canonical.com \
/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.