1. 09 6月, 2017 1 次提交
  2. 09 5月, 2017 1 次提交
    • M
      mm: introduce kv[mz]alloc helpers · a7c3e901
      Michal Hocko 提交于
      Patch series "kvmalloc", v5.
      
      There are many open coded kmalloc with vmalloc fallback instances in the
      tree.  Most of them are not careful enough or simply do not care about
      the underlying semantic of the kmalloc/page allocator which means that
      a) some vmalloc fallbacks are basically unreachable because the kmalloc
      part will keep retrying until it succeeds b) the page allocator can
      invoke a really disruptive steps like the OOM killer to move forward
      which doesn't sound appropriate when we consider that the vmalloc
      fallback is available.
      
      As it can be seen implementing kvmalloc requires quite an intimate
      knowledge if the page allocator and the memory reclaim internals which
      strongly suggests that a helper should be implemented in the memory
      subsystem proper.
      
      Most callers, I could find, have been converted to use the helper
      instead.  This is patch 6.  There are some more relying on __GFP_REPEAT
      in the networking stack which I have converted as well and Eric Dumazet
      was not opposed [2] to convert them as well.
      
      [1] http://lkml.kernel.org/r/20170130094940.13546-1-mhocko@kernel.org
      [2] http://lkml.kernel.org/r/1485273626.16328.301.camel@edumazet-glaptop3.roam.corp.google.com
      
      This patch (of 9):
      
      Using kmalloc with the vmalloc fallback for larger allocations is a
      common pattern in the kernel code.  Yet we do not have any common helper
      for that and so users have invented their own helpers.  Some of them are
      really creative when doing so.  Let's just add kv[mz]alloc and make sure
      it is implemented properly.  This implementation makes sure to not make
      a large memory pressure for > PAGE_SZE requests (__GFP_NORETRY) and also
      to not warn about allocation failures.  This also rules out the OOM
      killer as the vmalloc is a more approapriate fallback than a disruptive
      user visible action.
      
      This patch also changes some existing users and removes helpers which
      are specific for them.  In some cases this is not possible (e.g.
      ext4_kvmalloc, libcfs_kvzalloc) because those seems to be broken and
      require GFP_NO{FS,IO} context which is not vmalloc compatible in general
      (note that the page table allocation is GFP_KERNEL).  Those need to be
      fixed separately.
      
      While we are at it, document that __vmalloc{_node} about unsupported gfp
      mask because there seems to be a lot of confusion out there.
      kvmalloc_node will warn about GFP_KERNEL incompatible (which are not
      superset) flags to catch new abusers.  Existing ones would have to die
      slowly.
      
      [sfr@canb.auug.org.au: f2fs fixup]
        Link: http://lkml.kernel.org/r/20170320163735.332e64b7@canb.auug.org.au
      Link: http://lkml.kernel.org/r/20170306103032.2540-2-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Reviewed-by: Andreas Dilger <adilger@dilger.ca>	[ext4 part]
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Cc: John Hubbard <jhubbard@nvidia.com>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a7c3e901
  3. 07 4月, 2017 1 次提交
  4. 16 1月, 2017 9 次提交
  5. 07 5月, 2014 1 次提交
  6. 15 8月, 2013 1 次提交
  7. 12 5月, 2013 1 次提交
  8. 28 4月, 2013 2 次提交
  9. 10 4月, 2012 2 次提交
  10. 04 4月, 2012 1 次提交
  11. 10 9月, 2011 1 次提交
    • J
      apparmor: sparse fix: add apparmor.h to lib.c · 32c3df63
      James Morris 提交于
      Fix the following sparse warnings:
      security/apparmor/lib.c:37:6: warning: symbol 'aa_split_fqname' was not declared. Should it be static?
      security/apparmor/lib.c:63:6: warning: symbol 'aa_info_message' was not declared. Should it be static?
      security/apparmor/lib.c:83:6: warning: symbol 'kvmalloc' was not declared. Should it be static?
      security/apparmor/lib.c:123:6: warning: symbol 'kvfree' was not declared. Should it be static?
      Signed-off-by: NJames Morris <jmorris@namei.org>
      32c3df63
  12. 22 6月, 2011 1 次提交
    • A
      net: remove mm.h inclusion from netdevice.h · b7f080cf
      Alexey Dobriyan 提交于
      Remove linux/mm.h inclusion from netdevice.h -- it's unused (I've checked manually).
      
      To prevent mm.h inclusion via other channels also extract "enum dma_data_direction"
      definition into separate header. This tiny piece is what gluing netdevice.h with mm.h
      via "netdevice.h => dmaengine.h => dma-mapping.h => scatterlist.h => mm.h".
      Removal of mm.h from scatterlist.h was tried and was found not feasible
      on most archs, so the link was cutoff earlier.
      
      Hope people are OK with tiny include file.
      
      Note, that mm_types.h is still dragged in, but it is a separate story.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b7f080cf
  13. 08 9月, 2010 1 次提交
    • J
      AppArmor: Fix splitting an fqname into separate namespace and profile names · 04ccd53f
      John Johansen 提交于
      As per Dan Carpenter <error27@gmail.com>
        If we have a ns name without a following profile then in the original
        code it did "*ns_name = &name[1];".  "name" is NULL so "*ns_name" is
        0x1.  That isn't useful and could cause an oops when this function is
        called from aa_remove_profiles().
      
      Beyond this the assignment of the namespace name was wrong in the case
      where the profile name was provided as it was being set to &name[1]
      after name  = skip_spaces(split + 1);
      
      Move the ns_name assignment before updating name for the split and
      also add skip_spaces, making the interface more robust.
      Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      04ccd53f
  14. 02 8月, 2010 1 次提交