06 Jan, 2012

1 commit

  • We're doing some odd things there, which already messes up various users
    (see the net/socket.c code that this removes), and it was going to add
    yet more crud to the block layer because of the incorrect error code
    translation.

    ENOIOCTLCMD is not an error return that should be returned to user mode
    from the "ioctl()" system call, but it should *not* be translated as
    EINVAL ("Invalid argument"). It should be translated as ENOTTY
    ("Inappropriate ioctl for device").

    That EINVAL confusion has apparently so permeated some code that the
    block layer actually checks for it, which is sad. We continue to do so
    for now, but add a big comment about how wrong that is, and we should
    remove it entirely eventually. In the meantime, this tries to keep the
    changes localized to just the EINVAL -> ENOTTY fix, and removing code
    that makes it harder to do the right thing.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

21 Mar, 2011

1 commit

  • Move declaration of 'inode' to beginning of the function. Since it
    is referenced directly or indirectly (in case of FIFREEZE/FITHAW/
    FS_IOC_FIEMAP) it's not harmful IMHO. And remove unnecessary casts
    using 'argp' instead.

    Signed-off-by: Namhyung Kim
    Signed-off-by: Al Viro

    Namhyung Kim
     

03 Feb, 2011

1 commit

  • Some filesystems don't deal well with being asked to map less than
    blocksize blocks (GFS2 for example). Since we are always mapping at least
    blocksize sections anyway, just make sure len is at least as big as a
    blocksize so we don't trip up any filesystems. Thanks,

    Signed-off-by: Josef Bacik
    Cc: Steven Whitehouse
    Cc: Christoph Hellwig
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Josef Bacik
     

17 Jan, 2011

1 commit

  • The fi_extents_start field of struct fiemap_extent_info is a
    user pointer but was not marked as __user. This makes sparse
    emit following warnings:

    CHECK fs/ioctl.c
    fs/ioctl.c:114:26: warning: incorrect type in argument 1 (different address spaces)
    fs/ioctl.c:114:26: expected void [noderef] *dst
    fs/ioctl.c:114:26: got struct fiemap_extent *[assigned] dest
    fs/ioctl.c:202:14: warning: incorrect type in argument 1 (different address spaces)
    fs/ioctl.c:202:14: expected void const volatile [noderef] *
    fs/ioctl.c:202:14: got struct fiemap_extent *[assigned] fi_extents_start
    fs/ioctl.c:212:27: warning: incorrect type in argument 1 (different address spaces)
    fs/ioctl.c:212:27: expected void [noderef] *dst
    fs/ioctl.c:212:27: got char *

    Also add 'ufiemap' variable to eliminate unnecessary casts.

    Signed-off-by: Namhyung Kim
    Signed-off-by: Al Viro

    Namhyung Kim
     

20 Nov, 2010

2 commits

  • * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
    ext4: Add EXT4_IOC_TRIM ioctl to handle batched discard
    fs: Do not dispatch FITRIM through separate super_operation
    ext4: ext4_fill_super shouldn't return 0 on corruption
    jbd2: fix /proc/fs/jbd2/ when using an external journal
    ext4: missing unlock in ext4_clear_request_list()
    ext4: fix setting random pages PageUptodate

    Linus Torvalds
     
  • There was concern that FITRIM ioctl is not common enough to be included
    in core vfs ioctl, as Christoph Hellwig pointed out there's no real point
    in dispatching this out to a separate vector instead of just through
    ->ioctl.

    So this commit removes ioctl_fstrim() from vfs ioctl and trim_fs
    from super_operation structure.

    Signed-off-by: Lukas Czerner
    Signed-off-by: "Theodore Ts'o"

    Lukas Czerner
     

18 Nov, 2010

1 commit


28 Oct, 2010

1 commit

  • Adds an filesystem independent ioctl to allow implementation of file
    system batched discard support. I takes fstrim_range structure as an
    argument. fstrim_range is definec in the include/fs.h and its
    definition is as follows.

    struct fstrim_range {
    start;
    len;
    minlen;
    }

    start - first Byte to trim
    len - number of Bytes to trim from start
    minlen - minimum extent length to trim, free extents shorter than this
    number of Bytes will be ignored. This will be rounded up to fs
    block size.

    It is also possible to specify NULL as an argument. In this case the
    arguments will set itself as follows:

    start = 0;
    len = ULLONG_MAX;
    minlen = 0;

    So it will trim the whole file system at one run.

    After the FITRIM is done, the number of actually discarded Bytes is stored
    in fstrim_range.len to give the user better insight on how much storage
    space has been really released for wear-leveling.

    Signed-off-by: Lukas Czerner
    Reviewed-by: Dmitry Monakhov
    Signed-off-by: "Theodore Ts'o"

    Lukas Czerner
     

14 Aug, 2010

1 commit


22 May, 2010

1 commit

  • Currently the way we do freezing is by passing sb>s_bdev to freeze_bdev and then
    letting it do all the work. But freezing is more of an fs thing, and doesn't
    really have much to do with the bdev at all, all the work gets done with the
    super. In btrfs we do not populate s_bdev, since we can have multiple bdev's
    for one fs and setting s_bdev makes removing devices from a pool kind of tricky.
    This means that freezing a btrfs filesystem fails, which causes us to corrupt
    with things like tux-on-ice which use the fsfreeze mechanism. So instead of
    populating sb->s_bdev with a random bdev in our pool, I've broken the actual fs
    freezing stuff into freeze_super and thaw_super. These just take the
    super_block that we're freezing and does the appropriate work. It's basically
    just copy and pasted from freeze_bdev. I've then converted freeze_bdev over to
    use the new super helpers. I've tested this with ext4 and btrfs and verified
    everything continues to work the same as before.

    The only new gotcha is multiple calls to the fsfreeze ioctl will return EBUSY if
    the fs is already frozen. I thought this was a better solution than adding a
    freeze counter to the super_block, but if everybody hates this idea I'm open to
    suggestions. Thanks,

    Signed-off-by: Josef Bacik
    Signed-off-by: Al Viro

    Josef Bacik
     

24 Apr, 2010

1 commit

  • 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

    Josef Bacik
     

12 Nov, 2009

1 commit

  • 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

    Mike Hommey
     

24 Sep, 2009

1 commit

  • 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

    Jeff Layton
     

24 Jun, 2009

1 commit


17 Jun, 2009

1 commit


14 May, 2009

1 commit


07 May, 2009

1 commit

  • 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

    Josef Bacik
     

16 Mar, 2009

3 commits

  • 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

    Jonathan Corbet
     
  • 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

    Jonathan Corbet
     
  • 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

    Jonathan Corbet
     

14 Jan, 2009

1 commit


10 Jan, 2009

1 commit

  • 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

    Takashi Sato
     

05 Jan, 2009

1 commit

  • 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

    Steven Whitehouse
     

06 Dec, 2008

1 commit

  • 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

    Jonathan Corbet
     

13 Oct, 2008

1 commit

  • 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

    Adrian Bunk
     

09 Oct, 2008

1 commit

  • Basic vfs-level fiemap infrastructure, which sets up a new ->fiemap
    inode operation.

    Userspace can get extent information on a file via fiemap ioctl. As input,
    the fiemap ioctl takes a struct fiemap which includes an array of struct
    fiemap_extent (fm_extents). Size of the extent array is passed as
    fm_extent_count and number of extents returned will be written into
    fm_mapped_extents. Offset and length fields on the fiemap structure
    (fm_start, fm_length) describe a logical range which will be searched for
    extents. All extents returned will at least partially contain this range.
    The actual extent offsets and ranges returned will be unmodified from their
    offset and range on-disk.

    The fiemap ioctl returns '0' on success. On error, -1 is returned and errno
    is set. If errno is equal to EBADR, then fm_flags will contain those flags
    which were passed in which the kernel did not understand. On all other
    errors, the contents of fm_extents is undefined.

    As fiemap evolved, there have been many authors of the vfs patch. As far as
    I can tell, the list includes:
    Kalpak Shah
    Andreas Dilger
    Eric Sandeen
    Mark Fasheh

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

    Mark Fasheh
     

04 Oct, 2008

1 commit

  • 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

    Josef Bacik
     

29 Apr, 2008

1 commit


10 Feb, 2008

1 commit


08 Feb, 2008

3 commits

  • Factor out file-specific ioctl code into smaller helper functions, away from
    file_ioctl(). This helps code readability and also reduces indentation inside
    case statements.

    Signed-off-by: Erez Zadok
    Cc: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Erez Zadok
     
  • Rename old vfs_ioctl to do_ioctl, because the comment above it clearly
    indicates that it is an internal function not to be exported to modules;
    therefore it should have a more traditional do_XXX name. The new do_ioctl
    is exported in fs.h but not to modules.

    Rename the old do_ioctl to vfs_ioctl because the names vfs_XXX should
    preferably be reserved to callable VFS functions which modules may call, as
    many other vfs_XXX functions already do. Export the new vfs_ioctl to GPL
    modules so others can use it (including Unionfs and eCryptfs). Add DocBook
    for new vfs_ioctl.

    [akpm@linux-foundation.org: fix build]
    Signed-off-by: Erez Zadok
    Cc: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Erez Zadok
     
  • Signed-off-by: Erez Zadok
    Cc: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Erez Zadok
     

17 Jul, 2007

2 commits

  • sys_ioctl() was only exported for our first version of compat ioctl
    handling. Now that the whole compat ioctl handling mess is more or less
    sorted out there are no more modular users left and we can kill it.

    There's one exception and that's sparc64's solaris compat module, but
    sparc64 has it's own export predating the generic one by years for that
    which this patch leaves untouched.

    Signed-off-by: Christoph Hellwig
    Acked-by: David S. Miller
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     
  • Revert my do_ioctl() debugging patch: Paul fixed the bug.

    Cc: Paul Fulghum
    Cc: Alan Cox
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

05 Jun, 2007

1 commit

  • We've had several reoprts of the CPU jumping to 0x00000000 is do_ioctl(). I
    assume that there's a race and someone is zeroing out the ioctl handler while
    this CPU waits for the lock_kernel().

    The patch adds code to detect this, then emits stuff which will hopefuly lead
    us to the culprit.

    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

09 May, 2007

1 commit


09 Dec, 2006

1 commit

  • This patch changes struct file to use struct path instead of having
    independent pointers to struct dentry and struct vfsmount, and converts all
    users of f_{dentry,vfsmnt} in fs/ to use f_path.{dentry,mnt}.

    Additionally, it adds two #define's to make the transition easier for users of
    the f_dentry and f_vfsmnt.

    Signed-off-by: Josef "Jeff" Sipek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Josef "Jeff" Sipek
     

01 Jul, 2006

1 commit


12 Jan, 2006

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds