1. 04 3月, 2014 1 次提交
    • V
      hfsplus: fix remount issue · bd2c0035
      Vyacheslav Dubeyko 提交于
      Current implementation of HFS+ driver has small issue with remount
      option.  Namely, for example, you are unable to remount from RO mode
      into RW mode by means of command "mount -o remount,rw /dev/loop0
      /mnt/hfsplus".  Trying to execute sequence of commands results in an
      error message:
      
        mount /dev/loop0 /mnt/hfsplus
        mount -o remount,ro /dev/loop0 /mnt/hfsplus
        mount -o remount,rw /dev/loop0 /mnt/hfsplus
      
        mount: you must specify the filesystem type
      
        mount -t hfsplus -o remount,rw /dev/loop0 /mnt/hfsplus
      
        mount: /mnt/hfsplus not mounted or bad option
      
      The reason of such issue is failure of mount syscall:
      
        mount("/dev/loop0", "/mnt/hfsplus", 0x2282a60, MS_MGC_VAL|MS_REMOUNT, NULL) = -1 EINVAL (Invalid argument)
      
      Namely, hfsplus_parse_options_remount() method receives empty "input"
      argument and return false in such case.  As a result, hfsplus_remount()
      returns -EINVAL error code.
      
      This patch fixes the issue by means of return true for the case of empty
      "input" argument in hfsplus_parse_options_remount() method.
      Signed-off-by: NVyacheslav Dubeyko <slava@dubeyko.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bd2c0035
  2. 01 2月, 2014 1 次提交
  3. 26 1月, 2014 4 次提交
  4. 24 1月, 2014 1 次提交
    • S
      hfsplus: remove hfsplus_file_lookup() · d74a054f
      Sougata Santra 提交于
      HFS+ resource fork lookup breaks opendir() library function.  Since
      opendir first calls open() with O_DIRECTORY flag set.  O_DIRECTORY means
      "refuse to open if not a directory".  The open system call in the kernel
      does a check for inode->i_op->lookup and returns -ENOTDIR.  So if
      hfsplus_file_lookup is set it allows opendir() for plain files.
      
      Also resource fork lookup in HFS+ does not work.  Since it is never
      invoked after VFS permission checking.  It will always return with
      -EACCES.
      
      When we call opendir() on a file, it does not return NULL.  opendir()
      library call is based on open with O_DIRECTORY flag passed and then
      layered on top of getdents() system call.  O_DIRECTORY means "refuse to
      open if not a directory".
      
      The open() system call in the kernel does a check for: do_sys_open()
      -->..--> can_lookup() i.e it only checks inode->i_op->lookup and returns
      ENOTDIR if this function pointer is not set.
      
      In OSX, we can open "file/rsrc" to get the resource fork of "file".  This
      behavior is emulated inside hfsplus on Linux, which means that to some
      degree every file acts like a directory.  That is the reason lookup()
      inode operations is supported for files, and it is possible to do a lookup
      on this specific name.  As a result of this open succeeds without
      returning ENOTDIR for HFS+
      
      Please see the LKML discussion thread on this issue:
      http://marc.info/?l=linux-fsdevel&m=122823343730412&w=2
      
      I tried to test file/rsrc lookup in HFS+ driver and the feature does not
      work.  From OSX:
      
      $ touch test
      $ echo "1234" > test/..namedfork/rsrc
      $ ls -l test..namedfork/rsrc
      --rw-r--r-- 1 tuxera staff 5 10 dec 12:59 test/..namedfork/rsrc
      
      [sougata@ultrabook tmp]$ id
      uid=1000(sougata) gid=1000(sougata) groups=1000(sougata),5(tty),18(dialout),1001(vboxusers)
      
      [sougata@ultrabook tmp]$ mount
      /dev/sdb1 on /mnt/tmp type hfsplus (rw,relatime,umask=0,uid=1000,gid=1000,nls=utf8)
      
      [sougata@ultrabook tmp]$ ls -l test/rsrc
      ls: cannot access test/rsrc: Permission denied
      
      According to this LKML thread it is expected behavior.
      
      http://marc.info/?t=121139033800008&r=1&w=4
      
      I guess now that permission checking happens in vfs generic_permission() ?
       So it turns out that even though the lookup() inode_operation exists for
      HFS+ files.  It cannot really get invoked ?.  So if we can disable this
      feature to make opendir() work for HFS+.
      Signed-off-by: NSougata Santra <sougata@tuxera.com>
      Acked-by: NChristoph Hellwig <hch@lst.de>
      Cc: Vyacheslav Dubeyko <slava@dubeyko.com>
      Cc: Anton Altaparmakov <aia21@cam.ac.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d74a054f
  5. 25 11月, 2013 1 次提交
  6. 24 11月, 2013 2 次提交
    • K
      block: Abstract out bvec iterator · 4f024f37
      Kent Overstreet 提交于
      Immutable biovecs are going to require an explicit iterator. To
      implement immutable bvecs, a later patch is going to add a bi_bvec_done
      member to this struct; for now, this patch effectively just renames
      things.
      Signed-off-by: NKent Overstreet <kmo@daterainc.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "Ed L. Cashin" <ecashin@coraid.com>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Lars Ellenberg <drbd-dev@lists.linbit.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Matthew Wilcox <willy@linux.intel.com>
      Cc: Geoff Levand <geoff@infradead.org>
      Cc: Yehuda Sadeh <yehuda@inktank.com>
      Cc: Sage Weil <sage@inktank.com>
      Cc: Alex Elder <elder@inktank.com>
      Cc: ceph-devel@vger.kernel.org
      Cc: Joshua Morris <josh.h.morris@us.ibm.com>
      Cc: Philip Kelleher <pjk1939@linux.vnet.ibm.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Alasdair Kergon <agk@redhat.com>
      Cc: Mike Snitzer <snitzer@redhat.com>
      Cc: dm-devel@redhat.com
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: linux390@de.ibm.com
      Cc: Boaz Harrosh <bharrosh@panasas.com>
      Cc: Benny Halevy <bhalevy@tonian.com>
      Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Chris Mason <chris.mason@fusionio.com>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Andreas Dilger <adilger.kernel@dilger.ca>
      Cc: Jaegeuk Kim <jaegeuk.kim@samsung.com>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Dave Kleikamp <shaggy@kernel.org>
      Cc: Joern Engel <joern@logfs.org>
      Cc: Prasad Joshi <prasadjoshi.linux@gmail.com>
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Cc: KONISHI Ryusuke <konishi.ryusuke@lab.ntt.co.jp>
      Cc: Mark Fasheh <mfasheh@suse.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Ben Myers <bpm@sgi.com>
      Cc: xfs@oss.sgi.com
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Guo Chao <yan@linux.vnet.ibm.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Asai Thambi S P <asamymuthupa@micron.com>
      Cc: Selvan Mani <smani@micron.com>
      Cc: Sam Bradshaw <sbradshaw@micron.com>
      Cc: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
      Cc: "Roger Pau Monné" <roger.pau@citrix.com>
      Cc: Jan Beulich <jbeulich@suse.com>
      Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
      Cc: Ian Campbell <Ian.Campbell@citrix.com>
      Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Jiang Liu <jiang.liu@huawei.com>
      Cc: Nitin Gupta <ngupta@vflare.org>
      Cc: Jerome Marchand <jmarchand@redhat.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Peng Tao <tao.peng@emc.com>
      Cc: Andy Adamson <andros@netapp.com>
      Cc: fanchaoting <fanchaoting@cn.fujitsu.com>
      Cc: Jie Liu <jeff.liu@oracle.com>
      Cc: Sunil Mushran <sunil.mushran@gmail.com>
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
      Cc: Namjae Jeon <namjae.jeon@samsung.com>
      Cc: Pankaj Kumar <pankaj.km@samsung.com>
      Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
      Cc: Mel Gorman <mgorman@suse.de>6
      4f024f37
    • K
      block: submit_bio_wait() conversions · 33879d45
      Kent Overstreet 提交于
      It was being open coded in a few places.
      Signed-off-by: NKent Overstreet <kmo@daterainc.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Joern Engel <joern@logfs.org>
      Cc: Prasad Joshi <prasadjoshi.linux@gmail.com>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Chris Mason <chris.mason@fusionio.com>
      Acked-by: NNeilBrown <neilb@suse.de>
      33879d45
  7. 15 11月, 2013 1 次提交
    • G
      hfsplus: Fix undefined __divdi3 in hfsplus_init_header_node() · a99b7069
      Geert Uytterhoeven 提交于
      ERROR: "__divdi3" [fs/hfsplus/hfsplus.ko] undefined!
      
      Introduced by commit 099e9245 ("hfsplus: implement attributes file's
      header node initialization code").
      
      i_size_read() returns loff_t, which is long long, i.e.  64-bit.  node_size
      is size_t, which is either 32-bit or 64-bit.  Hence
      "i_size_read(attr_file) / node_size" is a 64-by-32 or 64-by-64 division,
      causing (some versions of) gcc to emit a call to __divdi3().
      
      Fortunately node_size is actually 16-bit, as the sole caller of
      hfsplus_init_header_node() passes a u16.  Hence change its type from
      size_t to u16, and use do_div() to perform a 64-by-32 division.
      
      Not seen in m68k/allmodconfig in -next, so it really depends on the
      verion of gcc.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: Vyacheslav Dubeyko <slava@dubeyko.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a99b7069
  8. 13 11月, 2013 4 次提交
  9. 13 9月, 2013 1 次提交
  10. 12 9月, 2013 3 次提交
  11. 29 6月, 2013 2 次提交
  12. 08 5月, 2013 1 次提交
  13. 01 5月, 2013 5 次提交
  14. 18 4月, 2013 1 次提交
  15. 04 3月, 2013 1 次提交
    • E
      fs: Limit sys_mount to only request filesystem modules. · 7f78e035
      Eric W. Biederman 提交于
      Modify the request_module to prefix the file system type with "fs-"
      and add aliases to all of the filesystems that can be built as modules
      to match.
      
      A common practice is to build all of the kernel code and leave code
      that is not commonly needed as modules, with the result that many
      users are exposed to any bug anywhere in the kernel.
      
      Looking for filesystems with a fs- prefix limits the pool of possible
      modules that can be loaded by mount to just filesystems trivially
      making things safer with no real cost.
      
      Using aliases means user space can control the policy of which
      filesystem modules are auto-loaded by editing /etc/modprobe.d/*.conf
      with blacklist and alias directives.  Allowing simple, safe,
      well understood work-arounds to known problematic software.
      
      This also addresses a rare but unfortunate problem where the filesystem
      name is not the same as it's module name and module auto-loading
      would not work.  While writing this patch I saw a handful of such
      cases.  The most significant being autofs that lives in the module
      autofs4.
      
      This is relevant to user namespaces because we can reach the request
      module in get_fs_type() without having any special permissions, and
      people get uncomfortable when a user specified string (in this case
      the filesystem type) goes all of the way to request_module.
      
      After having looked at this issue I don't think there is any
      particular reason to perform any filtering or permission checks beyond
      making it clear in the module request that we want a filesystem
      module.  The common pattern in the kernel is to call request_module()
      without regards to the users permissions.  In general all a filesystem
      module does once loaded is call register_filesystem() and go to sleep.
      Which means there is not much attack surface exposed by loading a
      filesytem module unless the filesystem is mounted.  In a user
      namespace filesystems are not mounted unless .fs_flags = FS_USERNS_MOUNT,
      which most filesystems do not set today.
      Acked-by: NSerge Hallyn <serge.hallyn@canonical.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Reported-by: NKees Cook <keescook@google.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      7f78e035
  16. 28 2月, 2013 5 次提交
  17. 23 2月, 2013 1 次提交
  18. 21 12月, 2012 5 次提交