1. 18 7月, 2018 1 次提交
    • M
      vfs: make open_with_fake_path() not contribute to nr_files · d3b1084d
      Miklos Szeredi 提交于
      Stacking file operations in overlay will store an extra open file for each
      overlay file opened.
      
      The overhead is just that of "struct file" which is about 256bytes, because
      overlay already pins an extra dentry and inode when the file is open, which
      add up to a much larger overhead.
      
      For fear of breaking working setups, don't start accounting the extra file.
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      d3b1084d
  2. 17 7月, 2018 1 次提交
  3. 12 7月, 2018 10 次提交
  4. 11 7月, 2018 5 次提交
  5. 07 7月, 2018 4 次提交
  6. 28 6月, 2018 1 次提交
    • C
      proc: add proc_seq_release · 877f919e
      Chunyu Hu 提交于
      kmemleak reported some memory leak on reading proc files. After adding
      some debug lines, find that proc_seq_fops is using seq_release as
      release handler, which won't handle the free of 'private' field of
      seq_file, while in fact the open handler proc_seq_open could create
      the private data with __seq_open_private when state_size is greater
      than zero. So after reading files created with proc_create_seq_private,
      such as /proc/timer_list and /proc/vmallocinfo, the private mem of a
      seq_file is not freed. Fix it by adding the paired proc_seq_release
      as the default release handler of proc_seq_ops instead of seq_release.
      
      Fixes: 44414d82 ("proc: introduce proc_create_seq_private")
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      CC: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NChunyu Hu <chuhu@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      877f919e
  7. 16 6月, 2018 2 次提交
  8. 15 6月, 2018 15 次提交
  9. 14 6月, 2018 1 次提交
    • A
      pstore: Remove bogus format string definition · e264abea
      Arnd Bergmann 提交于
      The pstore conversion to timespec64 introduces its own method of passing
      seconds into sscanf() and sprintf() type functions to work around the
      timespec64 definition on 64-bit systems that redefine it to 'timespec'.
      
      That hack is now finally getting removed, but that means we get a (harmless)
      warning once both patches are merged:
      
      fs/pstore/ram.c: In function 'ramoops_read_kmsg_hdr':
      fs/pstore/ram.c:39:29: error: format '%ld' expects argument of type 'long int *', but argument 3 has type 'time64_t *' {aka 'long long int *'} [-Werror=format=]
       #define RAMOOPS_KERNMSG_HDR "===="
                                   ^~~~~~
      fs/pstore/ram.c:167:21: note: in expansion of macro 'RAMOOPS_KERNMSG_HDR'
      
      This removes the pstore specific workaround and uses the same method that
      we have in place for all other functions that print a timespec64.
      
      Related to this, I found that the kasprintf() output contains an incorrect
      nanosecond values for any number starting with zeroes, and I adapt the
      format string accordingly.
      
      Link: https://lkml.org/lkml/2018/5/19/115
      Link: https://lkml.org/lkml/2018/5/16/1080
      Fixes: 0f0d83b99ef7 ("pstore: Convert internal records to timespec64")
      Acked-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      e264abea