1. 05 10月, 2017 5 次提交
  2. 14 9月, 2017 1 次提交
    • M
      mm: treewide: remove GFP_TEMPORARY allocation flag · 0ee931c4
      Michal Hocko 提交于
      GFP_TEMPORARY was introduced by commit e12ba74d ("Group short-lived
      and reclaimable kernel allocations") along with __GFP_RECLAIMABLE.  It's
      primary motivation was to allow users to tell that an allocation is
      short lived and so the allocator can try to place such allocations close
      together and prevent long term fragmentation.  As much as this sounds
      like a reasonable semantic it becomes much less clear when to use the
      highlevel GFP_TEMPORARY allocation flag.  How long is temporary? Can the
      context holding that memory sleep? Can it take locks? It seems there is
      no good answer for those questions.
      
      The current implementation of GFP_TEMPORARY is basically GFP_KERNEL |
      __GFP_RECLAIMABLE which in itself is tricky because basically none of
      the existing caller provide a way to reclaim the allocated memory.  So
      this is rather misleading and hard to evaluate for any benefits.
      
      I have checked some random users and none of them has added the flag
      with a specific justification.  I suspect most of them just copied from
      other existing users and others just thought it might be a good idea to
      use without any measuring.  This suggests that GFP_TEMPORARY just
      motivates for cargo cult usage without any reasoning.
      
      I believe that our gfp flags are quite complex already and especially
      those with highlevel semantic should be clearly defined to prevent from
      confusion and abuse.  Therefore I propose dropping GFP_TEMPORARY and
      replace all existing users to simply use GFP_KERNEL.  Please note that
      SLAB users with shrinkers will still get __GFP_RECLAIMABLE heuristic and
      so they will be placed properly for memory fragmentation prevention.
      
      I can see reasons we might want some gfp flag to reflect shorterm
      allocations but I propose starting from a clear semantic definition and
      only then add users with proper justification.
      
      This was been brought up before LSF this year by Matthew [1] and it
      turned out that GFP_TEMPORARY really doesn't have a clear semantic.  It
      seems to be a heuristic without any measured advantage for most (if not
      all) its current users.  The follow up discussion has revealed that
      opinions on what might be temporary allocation differ a lot between
      developers.  So rather than trying to tweak existing users into a
      semantic which they haven't expected I propose to simply remove the flag
      and start from scratch if we really need a semantic for short term
      allocations.
      
      [1] http://lkml.kernel.org/r/20170118054945.GD18349@bombadil.infradead.org
      
      [akpm@linux-foundation.org: fix typo]
      [akpm@linux-foundation.org: coding-style fixes]
      [sfr@canb.auug.org.au: drm/i915: fix up]
        Link: http://lkml.kernel.org/r/20170816144703.378d4f4d@canb.auug.org.au
      Link: http://lkml.kernel.org/r/20170728091904.14627-1-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Acked-by: NMel Gorman <mgorman@suse.de>
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Neil Brown <neilb@suse.de>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0ee931c4
  3. 12 9月, 2017 1 次提交
    • A
      ovl: fix false positive ESTALE on lookup · 939ae4ef
      Amir Goldstein 提交于
      Commit b9ac5c27 ("ovl: hash overlay non-dir inodes by copy up origin")
      verifies that the origin lower inode stored in the overlayfs inode matched
      the inode of a copy up origin dentry found by lookup.
      
      There is a false positive result in that check when lower fs does not
      support file handles and copy up origin cannot be followed by file handle
      at lookup time.
      
      The false negative happens when finding an overlay inode in cache on a
      copied up overlay dentry lookup. The overlay inode still 'remembers' the
      copy up origin inode, but the copy up origin dentry is not available for
      verification.
      
      Relax the check in case copy up origin dentry is not available.
      
      Fixes: b9ac5c27 ("ovl: hash overlay non-dir inodes by copy up...")
      Cc: <stable@vger.kernel.org> # v4.13
      Reported-by: NJordi Pujol <jordipujolp@gmail.com>
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      939ae4ef
  4. 05 9月, 2017 2 次提交
  5. 04 9月, 2017 1 次提交
  6. 10 8月, 2017 1 次提交
  7. 28 7月, 2017 4 次提交
    • M
      ovl: constant d_ino for non-merge dirs · 4edb83bb
      Miklos Szeredi 提交于
      Impure directories are ones which contain objects with origins (i.e. those
      that have been copied up).  These are relevant to readdir operation only
      because of the d_ino field, no other transformation is necessary.  Also a
      directory can become impure between two getdents(2) calls.
      
      This patch creates a cache for impure directories.  Unlike the cache for
      merged directories, this one only contains entries with origin and is not
      refcounted but has a its lifetime tied to that of the dentry.
      
      Similarly to the merged cache, the impure cache is invalidated based on a
      version number.  This version number is incremented when an entry with
      origin is added or removed from the directory.
      
      If the cache is empty, then the impure xattr is removed from the directory.
      
      This patch also fixes up handling of d_ino for the ".." entry if the parent
      directory is merged.
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      4edb83bb
    • A
      ovl: constant d_ino across copy up · b5efccbe
      Amir Goldstein 提交于
      When all layers are on the same fs, and iterating a directory which may
      contain copy up entries, call vfs_getattr() on the overlay entries to make
      sure that d_ino will be consistent with st_ino from stat(2).
      
      There is an overhead of lookup per upper entry in readdir.
      
      The overhead is minimal if the iterated entries are already in dcache.  It
      is also quite useful for the common case of 'ls -l' that readdir() pre
      populates the dcache with the listed entries, making the following stat()
      calls faster.
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      b5efccbe
    • M
      ovl: fix readdir error value · 31e8ccea
      Miklos Szeredi 提交于
      actor's return value is taken as a bool (filled/not filled) so we need to
      return the error in the context.
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      31e8ccea
    • M
      ovl: check snprintf return · 6787341a
      Miklos Szeredi 提交于
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      6787341a
  8. 20 7月, 2017 3 次提交
  9. 17 7月, 2017 1 次提交
    • D
      VFS: Convert sb->s_flags & MS_RDONLY to sb_rdonly(sb) · bc98a42c
      David Howells 提交于
      Firstly by applying the following with coccinelle's spatch:
      
      	@@ expression SB; @@
      	-SB->s_flags & MS_RDONLY
      	+sb_rdonly(SB)
      
      to effect the conversion to sb_rdonly(sb), then by applying:
      
      	@@ expression A, SB; @@
      	(
      	-(!sb_rdonly(SB)) && A
      	+!sb_rdonly(SB) && A
      	|
      	-A != (sb_rdonly(SB))
      	+A != sb_rdonly(SB)
      	|
      	-A == (sb_rdonly(SB))
      	+A == sb_rdonly(SB)
      	|
      	-!(sb_rdonly(SB))
      	+!sb_rdonly(SB)
      	|
      	-A && (sb_rdonly(SB))
      	+A && sb_rdonly(SB)
      	|
      	-A || (sb_rdonly(SB))
      	+A || sb_rdonly(SB)
      	|
      	-(sb_rdonly(SB)) != A
      	+sb_rdonly(SB) != A
      	|
      	-(sb_rdonly(SB)) == A
      	+sb_rdonly(SB) == A
      	|
      	-(sb_rdonly(SB)) && A
      	+sb_rdonly(SB) && A
      	|
      	-(sb_rdonly(SB)) || A
      	+sb_rdonly(SB) || A
      	)
      
      	@@ expression A, B, SB; @@
      	(
      	-(sb_rdonly(SB)) ? 1 : 0
      	+sb_rdonly(SB)
      	|
      	-(sb_rdonly(SB)) ? A : B
      	+sb_rdonly(SB) ? A : B
      	)
      
      to remove left over excess bracketage and finally by applying:
      
      	@@ expression A, SB; @@
      	(
      	-(A & MS_RDONLY) != sb_rdonly(SB)
      	+(bool)(A & MS_RDONLY) != sb_rdonly(SB)
      	|
      	-(A & MS_RDONLY) == sb_rdonly(SB)
      	+(bool)(A & MS_RDONLY) == sb_rdonly(SB)
      	)
      
      to make comparisons against the result of sb_rdonly() (which is a bool)
      work correctly.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      bc98a42c
  10. 14 7月, 2017 4 次提交
  11. 05 7月, 2017 17 次提交