1. 07 6月, 2014 4 次提交
    • F
    • S
      hfsplus: fix "unused node is not erased" error · 2cd282a1
      Sergei Antonov 提交于
      Zero newly allocated extents in the catalog tree if volume attributes
      tell us to.  Not doing so we risk getting the "unused node is not
      erased" error.  See kHFSUnusedNodeFix flag in Apple's source code for
      reference.
      
      There was a previous commit clearing the node when it is freed: commit
      899bed05 ("hfsplus: fix issue with unzeroed unused b-tree nodes").
      But it did not handle newly allocated extents (this patch fixes it).
      And it zeroed nodes in all trees unconditionally which is an overkill.
      
      This patch adds a condition and also switches to 'tree->node_size' as a
      simpler method of getting the length to zero.
      Signed-off-by: NSergei Antonov <saproj@gmail.com>
      Cc: Anton Altaparmakov <aia21@cam.ac.uk>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Vyacheslav Dubeyko <slava@dubeyko.com>
      Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
      Cc: Kyle Laracey <kalaracey@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2cd282a1
    • H
      hfsplus: correct usage of HFSPLUS_ATTR_MAX_STRLEN for non-English attributes · bf29e886
      Hin-Tak Leung 提交于
      HFSPLUS_ATTR_MAX_STRLEN (=127) is the limit of attribute names for the
      number of unicode character (UTF-16BE) storable in the HFS+ file system.
      Almost all the current usage of it is wrong, in relation to NLS to
      on-disk conversion.
      
      Except for one use calling hfsplus_asc2uni (which should stay the same)
      and its uses in calling hfsplus_uni2asc (which was corrected in the
      earlier patch in this series concerning usage of hfsplus_uni2asc), all
      the other uses are of the forms:
      
      - char buffer[size]
      
      - bound check: "if (namespace_adjusted_input_length > size) return failure;"
      
      Conversion between on-disk unicode representation and NLS char strings
      (in whichever direction) always needs to accommodate the worst-case NLS
      conversion, so all char buffers of that size need to have a
      NLS_MAX_CHARSET_SIZE x .
      
      The bound checks are all wrong, since they compare nls_length derived
      from strlen() to a unicode length limit.
      
      It turns out that all the bound-checks do is to protect
      hfsplus_asc2uni(), which can fail if the input is too large.
      
      There is only one usage of it as far as attributes are concerned, in
      hfsplus_attr_build_key().  It is in turn used by hfsplus_find_attr(),
      hfsplus_create_attr(), hfsplus_delete_attr().  Thus making sure that
      errors from hfsplus_asc2uni() is caught in hfsplus_attr_build_key() and
      propagated is sufficient to replace all the bound checks.
      
      Unpropagated errors from hfsplus_asc2uni() in the file catalog code was
      addressed recently in an independent patch "hfsplus: fix longname
      handling" by Sougata Santra.
      
      Before this patch, trying to set a 55 CJK character (in a UTF-8 locale,
      > 127/3=42) attribute plus user prefix fails with:
      
          $ setfattr -n user.`cat testing-string` -v `cat testing-string` \
              testing-string
          setfattr: testing-string: Operation not supported
      
      and retrieving a stored long attributes is particular ugly(!):
      
          find /mnt/* -type f -exec getfattr -d {} \;
          getfattr: /mnt/testing-string: Input/output error
      
      with console log:
          [268008.389781] hfsplus: unicode conversion failed
      
      After the patch, both of the above works.
      
      FYI, the test attribute string is prepared with:
      
      echo -e -n \
      "\xe9\x80\x99\xe6\x98\xaf\xe4\xb8\x80\xe5\x80\x8b\xe9\x9d\x9e\xe5" \
      "\xb8\xb8\xe6\xbc\xab\xe9\x95\xb7\xe8\x80\x8c\xe6\xa5\xb5\xe5\x85" \
      "\xb6\xe4\xb9\x8f\xe5\x91\xb3\xe5\x92\x8c\xe7\x9b\xb8\xe7\x95\xb6" \
      "\xe7\x84\xa1\xe8\xb6\xa3\xe3\x80\x81\xe4\xbb\xa5\xe5\x8f\x8a\xe7" \
      "\x84\xa1\xe7\x94\xa8\xe7\x9a\x84\xe3\x80\x81\xe5\x86\x8d\xe5\x8a" \
      "\xa0\xe4\xb8\x8a\xe6\xaf\xab\xe7\x84\xa1\xe6\x84\x8f\xe7\xbe\xa9" \
      "\xe7\x9a\x84\xe6\x93\xb4\xe5\xb1\x95\xe5\xb1\xac\xe6\x80\xa7\xef" \
      "\xbc\x8c\xe8\x80\x8c\xe5\x85\xb6\xe5\x94\xaf\xe4\xb8\x80\xe5\x89" \
      "\xb5\xe5\xbb\xba\xe7\x9b\xae\xe7\x9a\x84\xe5\x83\x85\xe6\x98\xaf" \
      "\xe7\x82\xba\xe4\xba\x86\xe6\xb8\xac\xe8\xa9\xa6\xe4\xbd\x9c\xe7" \
      "\x94\xa8\xe3\x80\x82" | tr -d ' '
      
      (= "pointlessly long attribute for testing", elaborate Chinese in
      UTF-8 enoding).
      
      However, it is not possible to set double the size (110 + 5 is still
      under 127) in a UTF-8 locale:
      
          $setfattr -n user.`cat testing-string testing-string` -v \
              `cat testing-string testing-string` testing-string
          setfattr: testing-string: Numerical result out of range
      
      110 CJK char in UTF-8 is 330 bytes - the generic get/set attribute
      system call code in linux/fs/xattr.c imposes a 255 byte limit.  One can
      use a combination of iconv to encode content, changing terminal locale
      for viewing, and an nls=cp932/cp936/cp949/cp950 mount option to fully
      use 127-unicode attribute in a double-byte locale.
      
      Also, as an additional information, it is possible to (mis-)use unicode
      half-width/full-width forms (U+FFxx) to write attributes which looks
      like english but not actually ascii.
      
      Thanks Anton Altaparmakov for reviewing the earlier ideas behind this
      change.
      
      [akpm@linux-foundation.org: fix build]
      [akpm@linux-foundation.org: fix build]
      Signed-off-by: NHin-Tak Leung <htl10@users.sourceforge.net>
      Cc: Anton Altaparmakov <anton@tuxera.com>
      Cc: Vyacheslav Dubeyko <slava@dubeyko.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Sougata Santra <sougata@tuxera.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bf29e886
    • H
      hfsplus: fix worst-case unicode to char conversion of file names and attributes · 017f8da4
      Hin-Tak Leung 提交于
      This is a series of 3 patches which corrects issues in HFS+ concerning
      the use of non-english file names and attributes.  Names and attributes
      are stored internally as UTF-16 units up to a fixed maximum size, and
      convert to and from user-representation by NLS.  The code incorrectly
      assume that NLS string lengths are equal to unicode lengths, which is
      only true for English ascii usage.
      
      This patch (of 3):
      
      The HFS Plus Volume Format specification (TN1150) states that file names
      are stored internally as a maximum of 255 unicode characters, as defined
      by The Unicode Standard, Version 2.0 [Unicode, Inc.  ISBN
      0-201-48345-9].  File names are converted by the NLS system on Linux
      before presented to the user.
      
      255 CJK characters converts to UTF-8 with 1 unicode character to up to 3
      bytes, and to GB18030 with 1 unicode character to up to 4 bytes.  Thus,
      trying in a UTF-8 locale to list files with names of more than 85 CJK
      characters results in:
      
          $ ls /mnt
          ls: reading directory /mnt: File name too long
      
      The receiving buffer to hfsplus_uni2asc() needs to be 255 x
      NLS_MAX_CHARSET_SIZE bytes, not 255 bytes as the code has always been.
      
      Similar consideration applies to attributes, which are stored internally
      as a maximum of 127 UTF-16BE units.  See XNU source for an up-to-date
      reference on attributes.
      
      Strictly speaking, the maximum value of NLS_MAX_CHARSET_SIZE = 6 is not
      attainable in the case of conversion to UTF-8, as going beyond 3 bytes
      requires the use of surrogate pairs, i.e.  consuming two input units.
      
      Thanks Anton Altaparmakov for reviewing an earlier version of this
      change.
      
      This patch fixes all callers of hfsplus_uni2asc(), and also enables the
      use of long non-English file names in HFS+.  The getting and setting,
      and general usage of long non-English attributes requires further
      forthcoming work, in the following patches of this series.
      
      [akpm@linux-foundation.org: fix build]
      Signed-off-by: NHin-Tak Leung <htl10@users.sourceforge.net>
      Reviewed-by: NAnton Altaparmakov <anton@tuxera.com>
      Cc: Vyacheslav Dubeyko <slava@dubeyko.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Sougata Santra <sougata@tuxera.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      017f8da4
  2. 01 2月, 2014 1 次提交
  3. 26 1月, 2014 2 次提交
  4. 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
  5. 13 11月, 2013 2 次提交
  6. 12 9月, 2013 1 次提交
  7. 01 5月, 2013 1 次提交
  8. 28 2月, 2013 1 次提交