1. 14 11月, 2018 1 次提交
    • J
      fsnotify: Fix busy inodes during unmount · 778af261
      Jan Kara 提交于
      commit 721fb6fbfd2132164c2e8777cc837f9b2c1794dc upstream.
      
      Detaching of mark connector from fsnotify_put_mark() can race with
      unmounting of the filesystem like:
      
        CPU1				CPU2
      fsnotify_put_mark()
        spin_lock(&conn->lock);
        ...
        inode = fsnotify_detach_connector_from_object(conn)
        spin_unlock(&conn->lock);
      				generic_shutdown_super()
      				  fsnotify_unmount_inodes()
      				    sees connector detached for inode
      				      -> nothing to do
      				  evict_inode()
      				    barfs on pending inode reference
        iput(inode);
      
      Resulting in "Busy inodes after unmount" message and possible kernel
      oops. Make fsnotify_unmount_inodes() properly wait for outstanding inode
      references from detached connectors.
      
      Note that the accounting of outstanding inode references in the
      superblock can cause some cacheline contention on the counter. OTOH it
      happens only during deletion of the last notification mark from an inode
      (or during unlinking of watched inode) and that is not too bad. I have
      measured time to create & delete inotify watch 100000 times from 64
      processes in parallel (each process having its own inotify group and its
      own file on a shared superblock) on a 64 CPU machine. Average and
      standard deviation of 15 runs look like:
      
      	Avg		Stddev
      Vanilla	9.817400	0.276165
      Fixed	9.710467	0.228294
      
      So there's no statistically significant difference.
      
      Fixes: 6b3f05d2 ("fsnotify: Detach mark from object list when last reference is dropped")
      CC: stable@vger.kernel.org
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      778af261
  2. 03 9月, 2018 1 次提交
    • A
      fsnotify: fix ignore mask logic in fsnotify() · 9bdda4e9
      Amir Goldstein 提交于
      Commit 92183a42 ("fsnotify: fix ignore mask logic in
      send_to_group()") acknoledges the use case of ignoring an event on
      an inode mark, because of an ignore mask on a mount mark of the same
      group (i.e. I want to get all events on this file, except for the events
      that came from that mount).
      
      This change depends on correctly merging the inode marks and mount marks
      group lists, so that the mount mark ignore mask would be tested in
      send_to_group(). Alas, the merging of the lists did not take into
      account the case where event in question is not in the mask of any of
      the mount marks.
      
      To fix this, completely remove the tests for inode and mount event masks
      from the lists merging code.
      
      Fixes: 92183a42 ("fsnotify: fix ignore mask logic in send_to_group")
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      9bdda4e9
  3. 20 8月, 2018 1 次提交
    • J
      fsnotify: fix false positive warning on inode delete · d3bc0fa8
      Jan Kara 提交于
      When inode is getting deleted and someone else holds reference to a mark
      attached to the inode, we just detach the connector from the inode. In
      that case fsnotify_put_mark() called from fsnotify_destroy_marks() will
      decide to recalculate mask for the inode and __fsnotify_recalc_mask()
      will WARN about invalid connector type:
      
      WARNING: CPU: 1 PID: 12015 at fs/notify/mark.c:139
      __fsnotify_recalc_mask+0x2d7/0x350 fs/notify/mark.c:139
      
      Actually there's no reason to warn about detached connector in
      __fsnotify_recalc_mask() so just silently skip updating the mask in such
      case.
      
      Reported-by: syzbot+c34692a51b9a6ca93540@syzkaller.appspotmail.com
      Fixes: 3ac70bfc ("fsnotify: add helper to get mask from connector")
      Signed-off-by: NJan Kara <jack@suse.cz>
      d3bc0fa8
  4. 18 8月, 2018 1 次提交
    • S
      fs: fsnotify: account fsnotify metadata to kmemcg · d46eb14b
      Shakeel Butt 提交于
      Patch series "Directed kmem charging", v8.
      
      The Linux kernel's memory cgroup allows limiting the memory usage of the
      jobs running on the system to provide isolation between the jobs.  All
      the kernel memory allocated in the context of the job and marked with
      __GFP_ACCOUNT will also be included in the memory usage and be limited
      by the job's limit.
      
      The kernel memory can only be charged to the memcg of the process in
      whose context kernel memory was allocated.  However there are cases
      where the allocated kernel memory should be charged to the memcg
      different from the current processes's memcg.  This patch series
      contains two such concrete use-cases i.e.  fsnotify and buffer_head.
      
      The fsnotify event objects can consume a lot of system memory for large
      or unlimited queues if there is either no or slow listener.  The events
      are allocated in the context of the event producer.  However they should
      be charged to the event consumer.  Similarly the buffer_head objects can
      be allocated in a memcg different from the memcg of the page for which
      buffer_head objects are being allocated.
      
      To solve this issue, this patch series introduces mechanism to charge
      kernel memory to a given memcg.  In case of fsnotify events, the memcg
      of the consumer can be used for charging and for buffer_head, the memcg
      of the page can be charged.  For directed charging, the caller can use
      the scope API memalloc_[un]use_memcg() to specify the memcg to charge
      for all the __GFP_ACCOUNT allocations within the scope.
      
      This patch (of 2):
      
      A lot of memory can be consumed by the events generated for the huge or
      unlimited queues if there is either no or slow listener.  This can cause
      system level memory pressure or OOMs.  So, it's better to account the
      fsnotify kmem caches to the memcg of the listener.
      
      However the listener can be in a different memcg than the memcg of the
      producer and these allocations happen in the context of the event
      producer.  This patch introduces remote memcg charging API which the
      producer can use to charge the allocations to the memcg of the listener.
      
      There are seven fsnotify kmem caches and among them allocations from
      dnotify_struct_cache, dnotify_mark_cache, fanotify_mark_cache and
      inotify_inode_mark_cachep happens in the context of syscall from the
      listener.  So, SLAB_ACCOUNT is enough for these caches.
      
      The objects from fsnotify_mark_connector_cachep are not accounted as
      they are small compared to the notification mark or events and it is
      unclear whom to account connector to since it is shared by all events
      attached to the inode.
      
      The allocations from the event caches happen in the context of the event
      producer.  For such caches we will need to remote charge the allocations
      to the listener's memcg.  Thus we save the memcg reference in the
      fsnotify_group structure of the listener.
      
      This patch has also moved the members of fsnotify_group to keep the size
      same, at least for 64 bit build, even with additional member by filling
      the holes.
      
      [shakeelb@google.com: use GFP_KERNEL_ACCOUNT rather than open-coding it]
        Link: http://lkml.kernel.org/r/20180702215439.211597-1-shakeelb@google.com
      Link: http://lkml.kernel.org/r/20180627191250.209150-2-shakeelb@google.comSigned-off-by: NShakeel Butt <shakeelb@google.com>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Amir Goldstein <amir73il@gmail.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d46eb14b
  5. 21 7月, 2018 2 次提交
  6. 28 6月, 2018 1 次提交
    • H
      inotify: Add flag IN_MASK_CREATE for inotify_add_watch() · 4d97f7d5
      Henry Wilson 提交于
      The flag IN_MASK_CREATE is introduced as a flag for inotiy_add_watch()
      which prevents inotify from modifying any existing watches when invoked.
      If the pathname specified in the call has a watched inode associated
      with it and IN_MASK_CREATE is specified, fail with an errno of EEXIST.
      
      Use of IN_MASK_CREATE with IN_MASK_ADD is reserved for future use and
      will return EINVAL.
      
      RATIONALE
      
      In the current implementation, there is no way to prevent
      inotify_add_watch() from modifying existing watch descriptors. Even if
      the caller keeps a record of all watch descriptors collected, this is
      only sufficient to detect that an existing watch descriptor may have
      been modified.
      
      The assumption that a particular path will map to the same inode over
      multiple calls to inotify_add_watch() cannot be made as files can be
      renamed or deleted.  It is also not possible to assume that two distinct
      paths do no map to the same inode, due to hard-links or a dereferenced
      symbolic link. Further uses of inotify_add_watch() to revert the change
      may cause other watch descriptors to be modified or created, merely
      compunding the problem. There is currently no system call such as
      inotify_modify_watch() to explicity modify a watch descriptor, which
      would be able to revert unwanted changes. Thus the caller cannot
      guarantee to be able to revert any changes to existing watch decriptors.
      
      Additionally the caller cannot assume that the events that are
      associated with a watch descriptor are within the set requested, as any
      future calls to inotify_add_watch() may unintentionally modify a watch
      descriptor's mask. Thus it cannot currently be guaranteed that a watch
      descriptor will only generate events which have been requested. The
      program must filter events which come through its watch descriptor to
      within its expected range.
      Reviewed-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NHenry Wilson <henry.wilson@acentic.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      4d97f7d5
  7. 27 6月, 2018 5 次提交
  8. 18 5月, 2018 7 次提交
  9. 13 4月, 2018 1 次提交
  10. 09 4月, 2018 1 次提交
    • A
      fanotify: fix logic of events on child · 54a307ba
      Amir Goldstein 提交于
      When event on child inodes are sent to the parent inode mark and
      parent inode mark was not marked with FAN_EVENT_ON_CHILD, the event
      will not be delivered to the listener process. However, if the same
      process also has a mount mark, the event to the parent inode will be
      delivered regadless of the mount mark mask.
      
      This behavior is incorrect in the case where the mount mark mask does
      not contain the specific event type. For example, the process adds
      a mark on a directory with mask FAN_MODIFY (without FAN_EVENT_ON_CHILD)
      and a mount mark with mask FAN_CLOSE_NOWRITE (without FAN_ONDIR).
      
      A modify event on a file inside that directory (and inside that mount)
      should not create a FAN_MODIFY event, because neither of the marks
      requested to get that event on the file.
      
      Fixes: 1968f5ee ("fanotify: use both marks when possible")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      54a307ba
  11. 03 4月, 2018 2 次提交
  12. 27 2月, 2018 2 次提交
    • J
      fsnotify: Let userspace know about lost events due to ENOMEM · 7b1f6417
      Jan Kara 提交于
      Currently if notification event is lost due to event allocation failing
      we ENOMEM, we just silently continue (except for fanotify permission
      events where we deny the access). This is undesirable as userspace has
      no way of knowing whether the notifications it got are complete or not.
      Treat lost events due to ENOMEM the same way as lost events due to queue
      overflow so that userspace knows something bad happened and it likely
      needs to rescan the filesystem.
      Reviewed-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      7b1f6417
    • J
      fanotify: Avoid lost events due to ENOMEM for unlimited queues · 1f5eaa90
      Jan Kara 提交于
      Fanotify queues of unlimited length do not expect events can be lost.
      Since these queues are used for system auditing and other security
      related tasks, loosing events can even have security implications.
      Currently, since the allocation is small (32-bytes), it cannot fail
      however when we start accounting events in memcgs, allocation can start
      failing. So avoid loosing events due to failure to allocate memory by
      making event allocation use __GFP_NOFAIL.
      Reviewed-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      1f5eaa90
  13. 14 2月, 2018 1 次提交
    • K
      inotify: Extend ioctl to allow to request id of new watch descriptor · e1603b6e
      Kirill Tkhai 提交于
      Watch descriptor is id of the watch created by inotify_add_watch().
      It is allocated in inotify_add_to_idr(), and takes the numbers
      starting from 1. Every new inotify watch obtains next available
      number (usually, old + 1), as served by idr_alloc_cyclic().
      
      CRIU (Checkpoint/Restore In Userspace) project supports inotify
      files, and restores watched descriptors with the same numbers,
      they had before dump. Since there was no kernel support, we
      had to use cycle to add a watch with specific descriptor id:
      
      	while (1) {
      		int wd;
      
      		wd = inotify_add_watch(inotify_fd, path, mask);
      		if (wd < 0) {
      			break;
      		} else if (wd == desired_wd_id) {
      			ret = 0;
      			break;
      		}
      
      		inotify_rm_watch(inotify_fd, wd);
      	}
      
      (You may find the actual code at the below link:
       https://github.com/checkpoint-restore/criu/blob/v3.7/criu/fsnotify.c#L577)
      
      The cycle is suboptiomal and very expensive, but since there is no better
      kernel support, it was the only way to restore that. Happily, we had met
      mostly descriptors with small id, and this approach had worked somehow.
      
      But recent time containers with inotify with big watch descriptors
      begun to come, and this way stopped to work at all. When descriptor id
      is something about 0x34d71d6, the restoring process spins in busy loop
      for a long time, and the restore hungs and delay of migration from node
      to node could easily be watched.
      
      This patch aims to solve this problem. It introduces new ioctl
      INOTIFY_IOC_SETNEXTWD, which allows to request the number of next created
      watch descriptor from userspace. It simply calls idr_set_cursor() primitive
      to populate idr::idr_next, so that next idr_alloc_cyclic() allocation
      will return this id, if it is not occupied. This is the way which is
      used to restore some other resources from userspace. For example,
      /proc/sys/kernel/ns_last_pid works the same for task pids.
      
      The new code is under CONFIG_CHECKPOINT_RESTORE #define, so small system
      may exclude it.
      
      v2: Use INT_MAX instead of custom definition of max id,
      as IDR subsystem guarantees id is between 0 and INT_MAX.
      
      CC: Jan Kara <jack@suse.cz>
      CC: Matthew Wilcox <willy@infradead.org>
      CC: Andrew Morton <akpm@linux-foundation.org>
      CC: Amir Goldstein <amir73il@gmail.com>
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Reviewed-by: NCyrill Gorcunov <gorcunov@openvz.org>
      Reviewed-by: NMatthew Wilcox <mawilcox@microsoft.com>
      Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJan Kara <jack@suse.cz>
      e1603b6e
  14. 12 2月, 2018 1 次提交
    • L
      vfs: do bulk POLL* -> EPOLL* replacement · a9a08845
      Linus Torvalds 提交于
      This is the mindless scripted replacement of kernel use of POLL*
      variables as described by Al, done by this script:
      
          for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
              L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
              for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
          done
      
      with de-mangling cleanups yet to come.
      
      NOTE! On almost all architectures, the EPOLL* constants have the same
      values as the POLL* constants do.  But they keyword here is "almost".
      For various bad reasons they aren't the same, and epoll() doesn't
      actually work quite correctly in some cases due to this on Sparc et al.
      
      The next patch from Al will sort out the final differences, and we
      should be all done.
      Scripted-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a9a08845
  15. 28 11月, 2017 2 次提交
    • A
      fs: annotate ->poll() instances · 076ccb76
      Al Viro 提交于
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      076ccb76
    • L
      Rename superblock flags (MS_xyz -> SB_xyz) · 1751e8a6
      Linus Torvalds 提交于
      This is a pure automated search-and-replace of the internal kernel
      superblock flags.
      
      The s_flags are now called SB_*, with the names and the values for the
      moment mirroring the MS_* flags that they're equivalent to.
      
      Note how the MS_xyz flags are the ones passed to the mount system call,
      while the SB_xyz flags are what we then use in sb->s_flags.
      
      The script to do this was:
      
          # places to look in; re security/*: it generally should *not* be
          # touched (that stuff parses mount(2) arguments directly), but
          # there are two places where we really deal with superblock flags.
          FILES="drivers/mtd drivers/staging/lustre fs ipc mm \
                  include/linux/fs.h include/uapi/linux/bfs_fs.h \
                  security/apparmor/apparmorfs.c security/apparmor/include/lib.h"
          # the list of MS_... constants
          SYMS="RDONLY NOSUID NODEV NOEXEC SYNCHRONOUS REMOUNT MANDLOCK \
                DIRSYNC NOATIME NODIRATIME BIND MOVE REC VERBOSE SILENT \
                POSIXACL UNBINDABLE PRIVATE SLAVE SHARED RELATIME KERNMOUNT \
                I_VERSION STRICTATIME LAZYTIME SUBMOUNT NOREMOTELOCK NOSEC BORN \
                ACTIVE NOUSER"
      
          SED_PROG=
          for i in $SYMS; do SED_PROG="$SED_PROG -e s/MS_$i/SB_$i/g"; done
      
          # we want files that contain at least one of MS_...,
          # with fs/namespace.c and fs/pnode.c excluded.
          L=$(for i in $SYMS; do git grep -w -l MS_$i $FILES; done| sort|uniq|grep -v '^fs/namespace.c'|grep -v '^fs/pnode.c')
      
          for f in $L; do sed -i $f $SED_PROG; done
      Requested-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1751e8a6
  16. 02 11月, 2017 1 次提交
    • G
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman 提交于
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  17. 01 11月, 2017 10 次提交