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

Cleanup generic block based fiemap

2010-04-23T17:39:48+00:00

This cleans up a few of the complaints of __generic_block_fiemap.  I've
fixed all the typing stuff, used inline functions instead of macros,
gotten rid of a couple of variables, and made sure the size and block
requests are all block aligned.  It also fixes a problem where sometimes
FIEMAP_EXTENT_LAST wasn't being set properly.

Signed-off-by: Josef Bacik 
Signed-off-by: Linus Torvalds

__generic_block_fiemap(): fix for files bigger than 4GB

2009-11-12T15:26:01+00:00

Because of an integer overflow on start_blk, various kind of wrong results
would be returned by the generic_block_fiemap() handler, such as no
extents when there is a 4GB+ hole at the beginning of the file, or wrong
fe_logical when an extent starts after the first 4GB.

Signed-off-by: Mike Hommey 
Cc: Alexander Viro 
Cc: Steven Whitehouse 
Cc: Theodore Ts'o 
Cc: Eric Sandeen 
Cc: Josef Bacik 
Cc: Mark Fasheh 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

vfs: explicitly cast s_maxbytes in fiemap_check_ranges

2009-09-24T11:47:31+00:00

If fiemap_check_ranges is passed a large enough value, then it's
possible that the value would be cast to a signed value for comparison
against s_maxbytes when we change it to loff_t. Make sure that doesn't
happen by explicitly casting s_maxbytes to an unsigned value for the
purposes of comparison.

Signed-off-by: Jeff Layton 
Cc: Christoph Hellwig 
Cc: Robert Love 
Cc: Al Viro 
Cc: Johannes Weiner 
Cc: Mandeep Singh Baines 
Signed-off-by: Andrew Morton 
Signed-off-by: Al Viro

fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls

2009-06-24T12:15:27+00:00

This patch adds ioctls to vfs for compatibility with legacy XFS
pre-allocation ioctls (XFS_IOC_*RESVP*). The implementation
effectively invokes sys_fallocate for the new ioctls.
Also handles the compat_ioctl case.
Note: These legacy ioctls are also implemented by OCFS2.

[AV: folded fixes from hch]

Signed-off-by: Ankit Jain 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro

No instance of ->bmap() needs BKL

2009-06-17T04:36:35+00:00

Signed-off-by: Al Viro

vfs: Enable FS_IOC_FIEMAP and FIGETBSZ for all filetypes

2009-05-13T22:12:05+00:00

The fiemap and get_blk_size ioctls should be enabled even for
directories.  So move it outisde file_ioctl.

Signed-off-by: Aneesh Kumar K.V 
Signed-off-by: "Theodore Ts'o"

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