linux.git/fs/ioctl.c, branch v2.6.30

fiemap: fix problem with setting FIEMAP_EXTENT_LAST

2009-05-06T23:36:09+00:00

Fix a problem where the generic block based fiemap stuff would not
properly set FIEMAP_EXTENT_LAST on the last extent.  I've reworked things
to keep track if we go past the EOF, and mark the last extent properly.
The problem was reported by and tested by Eric Sandeen.

Tested-by: Eric Sandeen 
Signed-off-by: Josef Bacik 
Cc: 
Cc: 
Cc: 
Cc: Steven Whitehouse 
Cc: Mark Fasheh 
Cc: Joel Becker 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Rationalize fasync return values

2009-03-16T14:34:35+00:00

Most fasync implementations do something like:

     return fasync_helper(...);

But fasync_helper() will return a positive value at times - a feature used
in at least one place.  Thus, a number of other drivers do:

     err = fasync_helper(...);
     if (err < 0)
             return err;
     return 0;

In the interests of consistency and more concise code, it makes sense to
map positive return values onto zero where ->fasync() is called.

Cc: Al Viro 
Signed-off-by: Jonathan Corbet

Move FASYNC bit handling to f_op->fasync()

2009-03-16T14:32:27+00:00

Removing the BKL from FASYNC handling ran into the challenge of keeping the
setting of the FASYNC bit in filp->f_flags atomic with regard to calls to
the underlying fasync() function.  Andi Kleen suggested moving the handling
of that bit into fasync(); this patch does exactly that.  As a result, we
have a couple of internal API changes: fasync() must now manage the FASYNC
bit, and it will be called without the BKL held.

As it happens, every fasync() implementation in the kernel with one
exception calls fasync_helper().  So, if we make fasync_helper() set the
FASYNC bit, we can avoid making any changes to the other fasync()
functions - as long as those functions, themselves, have proper locking.
Most fasync() implementations do nothing but call fasync_helper() - which
has its own lock - so they are easily verified as correct.  The BKL had
already been pushed down into the rest.

The networking code has its own version of fasync_helper(), so that code
has been augmented with explicit FASYNC bit handling.

Cc: Al Viro 
Cc: David Miller 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jonathan Corbet

Use f_lock to protect f_flags

2009-03-16T14:32:27+00:00

Traditionally, changes to struct file->f_flags have been done under BKL
protection, or with no protection at all.  This patch causes all f_flags
changes after file open/creation time to be done under protection of
f_lock.  This allows the removal of some BKL usage and fixes a number of
longstanding (if microscopic) races.

Reviewed-by: Christoph Hellwig 
Cc: Al Viro 
Signed-off-by: Jonathan Corbet

[CVE-2009-0029] System call wrappers part 15

2009-01-14T13:15:24+00:00

Signed-off-by: Heiko Carstens

filesystem freeze: implement generic freeze feature

2009-01-10T00:54:42+00:00

The ioctls for the generic freeze feature are below.
o Freeze the filesystem
  int ioctl(int fd, int FIFREEZE, arg)
    fd: The file descriptor of the mountpoint
    FIFREEZE: request code for the freeze
    arg: Ignored
    Return value: 0 if the operation succeeds. Otherwise, -1

o Unfreeze the filesystem
  int ioctl(int fd, int FITHAW, arg)
    fd: The file descriptor of the mountpoint
    FITHAW: request code for unfreeze
    arg: Ignored
    Return value: 0 if the operation succeeds. Otherwise, -1
    Error number: If the filesystem has already been unfrozen,
                  errno is set to EINVAL.

[akpm@linux-foundation.org: fix CONFIG_BLOCK=n]
Signed-off-by: Takashi Sato 
Signed-off-by: Masayuki Hamaguchi 
Cc: 
Cc: 
Cc: Christoph Hellwig 
Cc: Dave Kleikamp 
Cc: Dave Chinner 
Cc: Alasdair G Kergon 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

GFS2: Support for FIEMAP ioctl

2009-01-05T07:38:46+00:00

This patch implements the FIEMAP ioctl for GFS2. We can use the generic
code (aside from a lock order issue, solved as per Ted Tso's suggestion)
for which I've introduced a new variant of the generic function. We also
have one exception to deal with, namely stuffed files, so we do that
"by hand", setting all the required flags.

This has been tested with a modified (I could only find an old version) of
Eric's test program, and appears to work correctly.

This patch does not currently support FIEMAP of xattrs, but the plan is to add
that feature at some future point.

Signed-off-by: Steven Whitehouse 
Cc: Theodore Tso 
Cc: Eric Sandeen

Fix a race condition in FASYNC handling

2008-12-05T23:35:10+00:00

Changeset a238b790d5f99c7832f9b73ac8847025815b85f7 (Call fasync()
functions without the BKL) introduced a race which could leave
file->f_flags in a state inconsistent with what the underlying
driver/filesystem believes.  Revert that change, and also fix the same
races in ioctl_fioasync() and ioctl_fionbio().

This is a minimal, short-term fix; the real fix will not involve the
BKL.

Reported-by: Oleg Nesterov 
Cc: Andi Kleen 
Cc: Al Viro 
Cc: stable@kernel.org
Signed-off-by: Jonathan Corbet 
Signed-off-by: Linus Torvalds

provide generic_block_fiemap() only with BLOCK=y

2008-10-12T18:44:37+00:00

This fixes the following compile error with CONFIG_BLOCK=n caused by
commit 68c9d702bb72f367f3b148963ec6cf5e07ff7f65 ("generic block based
fiemap implementation"):

    CC      fs/ioctl.o
  fs/ioctl.c: In function 'generic_block_fiemap':
  fs/ioctl.c:249: error: storage size of 'tmp' isn't known
  fs/ioctl.c:272: error: invalid application of 'sizeof' to incomplete type 'struct buffer_head'
  fs/ioctl.c:280: error: implicit declaration of function 'buffer_mapped'
  fs/ioctl.c:249: warning: unused variable 'tmp'
  make[2]: *** [fs/ioctl.o] Error 1

Signed-off-by: Adrian Bunk 
Acked-by: Josef Bacik 
Signed-off-by: Linus Torvalds

generic block based fiemap implementation

2008-10-03T21:32:43+00:00

Any block based fs (this patch includes ext3) just has to declare its own
fiemap() function and then call this generic function with its own
get_block_t. This works well for block based filesystems that will map
multiple contiguous blocks at one time, but will work for filesystems that
only map one block at a time, you will just end up with an "extent" for each
block. One gotcha is this will not play nicely where there is hole+data
after the EOF. This function will assume its hit the end of the data as soon
as it hits a hole after the EOF, so if there is any data past that it will
not pick that up. AFAIK no block based fs does this anyway, but its in the
comments of the function anyway just in case.

Signed-off-by: Josef Bacik 
Signed-off-by: Mark Fasheh 
Signed-off-by: "Theodore Ts'o" 
Cc: linux-fsdevel@vger.kernel.org