1. 01 Feb, 2019 22 commits
    • Mikhail Zaslonko's avatar
      mm, memory_hotplug: test_pages_in_a_zone do not pass the end of zone · 24feb47c
      Mikhail Zaslonko authored
      If memory end is not aligned with the sparse memory section boundary,
      the mapping of such a section is only partly initialized.  This may lead
      to VM_BUG_ON due to uninitialized struct pages access from
      test_pages_in_a_zone() function triggered by memory_hotplug sysfs
      handlers.
      
      Here are the the panic examples:
       CONFIG_DEBUG_VM_PGFLAGS=y
       kernel parameter mem=2050M
       --------------------------
       page:000003d082008000 is uninitialized and poisoned
       page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
       Call Trace:
         test_pages_in_a_zone+0xde/0x160
         show_valid_zones+0x5c/0x190
         dev_attr_show+0x34/0x70
         sysfs_kf_seq_show+0xc8/0x148
         seq_read+0x204/0x480
         __vfs_read+0x32/0x178
         vfs_read+0x82/0x138
         ksys_read+0x5a/0xb0
         system_call+0xdc/0x2d8
       Last Breaking-Event-Address:
         test_pages_in_a_zone+0xde/0x160
       Kernel panic - not syncing: Fatal exception: panic_on_oops
      
      Fix this by checking whether the pfn to check is within the zone.
      
      [mhocko@suse.com: separated this change from http://lkml.kernel.org/r/20181105150401.97287-2-zaslonko@linux.ibm.com]
      Link: http://lkml.kernel.org/r/20190128144506.15603-3-mhocko@kernel.org
      
      [mhocko@suse.com: separated this change from
      http://lkml.kernel.org/r/20181105150401.97287-2-zaslonko@linux.ibm.com]
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarMikhail Zaslonko <zaslonko@linux.ibm.com>
      Tested-by: default avatarMikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
      Reviewed-by: default avatarOscar Salvador <osalvador@suse.de>
      Tested-by: default avatarGerald Schaefer <gerald.schaefer@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
      Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      24feb47c
    • Michal Hocko's avatar
      mm, memory_hotplug: is_mem_section_removable do not pass the end of a zone · efad4e47
      Michal Hocko authored
      Patch series "mm, memory_hotplug: fix uninitialized pages fallouts", v2.
      
      Mikhail Zaslonko has posted fixes for the two bugs quite some time ago
      [1].  I have pushed back on those fixes because I believed that it is
      much better to plug the problem at the initialization time rather than
      play whack-a-mole all over the hotplug code and find all the places
      which expect the full memory section to be initialized.
      
      We have ended up with commit 2830bf6f ("mm, memory_hotplug:
      initialize struct pages for the full memory section") merged and cause a
      regression [2][3].  The reason is that there might be memory layouts
      when two NUMA nodes share the same memory section so the merged fix is
      simply incorrect.
      
      In order to plug this hole we really have to be zone range aware in
      those handlers.  I have split up the original patch into two.  One is
      unchanged (patch 2) and I took a different approach for `removable'
      crash.
      
      [1] http://lkml.kernel.org/r/20181105150401.97287-2-zaslonko@linux.ibm.com
      [2] https://bugzilla.redhat.com/show_bug.cgi?id=1666948
      [3] http://lkml.kernel.org/r/20190125163938.GA20411@dhcp22.suse.cz
      
      This patch (of 2):
      
      Mikhail has reported the following VM_BUG_ON triggered when reading sysfs
      removable state of a memory block:
      
       page:000003d08300c000 is uninitialized and poisoned
       page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
       Call Trace:
         is_mem_section_removable+0xb4/0x190
         show_mem_removable+0x9a/0xd8
         dev_attr_show+0x34/0x70
         sysfs_kf_seq_show+0xc8/0x148
         seq_read+0x204/0x480
         __vfs_read+0x32/0x178
         vfs_read+0x82/0x138
         ksys_read+0x5a/0xb0
         system_call+0xdc/0x2d8
       Last Breaking-Event-Address:
         is_mem_section_removable+0xb4/0x190
       Kernel panic - not syncing: Fatal exception: panic_on_oops
      
      The reason is that the memory block spans the zone boundary and we are
      stumbling over an unitialized struct page.  Fix this by enforcing zone
      range in is_mem_section_removable so that we never run away from a zone.
      
      Link: http://lkml.kernel.org/r/20190128144506.15603-2-mhocko@kernel.orgSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Reported-by: default avatarMikhail Zaslonko <zaslonko@linux.ibm.com>
      Debugged-by: default avatarMikhail Zaslonko <zaslonko@linux.ibm.com>
      Tested-by: default avatarGerald Schaefer <gerald.schaefer@de.ibm.com>
      Tested-by: default avatarMikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
      Reviewed-by: default avatarOscar Salvador <osalvador@suse.de>
      Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      efad4e47
    • Tetsuo Handa's avatar
      oom, oom_reaper: do not enqueue same task twice · 9bcdeb51
      Tetsuo Handa authored
      Arkadiusz reported that enabling memcg's group oom killing causes
      strange memcg statistics where there is no task in a memcg despite the
      number of tasks in that memcg is not 0.  It turned out that there is a
      bug in wake_oom_reaper() which allows enqueuing same task twice which
      makes impossible to decrease the number of tasks in that memcg due to a
      refcount leak.
      
      This bug existed since the OOM reaper became invokable from
      task_will_free_mem(current) path in out_of_memory() in Linux 4.7,
      
        T1@P1     |T2@P1     |T3@P1     |OOM reaper
        ----------+----------+----------+------------
                                         # Processing an OOM victim in a different memcg domain.
                              try_charge()
                                mem_cgroup_out_of_memory()
                                  mutex_lock(&oom_lock)
                   try_charge()
                     mem_cgroup_out_of_memory()
                       mutex_lock(&oom_lock)
        try_charge()
          mem_cgroup_out_of_memory()
            mutex_lock(&oom_lock)
                                  out_of_memory()
                                    oom_kill_process(P1)
                                      do_send_sig_info(SIGKILL, @P1)
                                      mark_oom_victim(T1@P1)
                                      wake_oom_reaper(T1@P1) # T1@P1 is enqueued.
                                  mutex_unlock(&oom_lock)
                       out_of_memory()
                         mark_oom_victim(T2@P1)
                         wake_oom_reaper(T2@P1) # T2@P1 is enqueued.
                       mutex_unlock(&oom_lock)
            out_of_memory()
              mark_oom_victim(T1@P1)
              wake_oom_reaper(T1@P1) # T1@P1 is enqueued again due to oom_reaper_list == T2@P1 && T1@P1->oom_reaper_list == NULL.
            mutex_unlock(&oom_lock)
                                         # Completed processing an OOM victim in a different memcg domain.
                                         spin_lock(&oom_reaper_lock)
                                         # T1P1 is dequeued.
                                         spin_unlock(&oom_reaper_lock)
      
      but memcg's group oom killing made it easier to trigger this bug by
      calling wake_oom_reaper() on the same task from one out_of_memory()
      request.
      
      Fix this bug using an approach used by commit 855b0183 ("oom,
      oom_reaper: disable oom_reaper for oom_kill_allocating_task").  As a
      side effect of this patch, this patch also avoids enqueuing multiple
      threads sharing memory via task_will_free_mem(current) path.
      
      Link: http://lkml.kernel.org/r/e865a044-2c10-9858-f4ef-254bc71d6cc2@i-love.sakura.ne.jp
      Link: http://lkml.kernel.org/r/5ee34fc6-1485-34f8-8790-903ddabaa809@i-love.sakura.ne.jp
      Fixes: af8e15cc ("oom, oom_reaper: do not enqueue task if it is on the oom_reaper_list head")
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Reported-by: default avatarArkadiusz Miskiewicz <arekm@maven.pl>
      Tested-by: default avatarArkadiusz Miskiewicz <arekm@maven.pl>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarRoman Gushchin <guro@fb.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Aleksa Sarai <asarai@suse.de>
      Cc: Jay Kamat <jgkamat@fb.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9bcdeb51
    • Jan Kara's avatar
      mm: migrate: make buffer_migrate_page_norefs() actually succeed · 80409c65
      Jan Kara authored
      Currently, buffer_migrate_page_norefs() was constantly failing because
      buffer_migrate_lock_buffers() grabbed reference on each buffer.  In
      fact, there's no reason for buffer_migrate_lock_buffers() to grab any
      buffer references as the page is locked during all our operation and
      thus nobody can reclaim buffers from the page.
      
      So remove grabbing of buffer references which also makes
      buffer_migrate_page_norefs() succeed.
      
      Link: http://lkml.kernel.org/r/20190116131217.7226-1-jack@suse.cz
      Fixes: 89cb0888 "mm: migrate: provide buffer_migrate_page_norefs()"
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Zi Yan <zi.yan@cs.rutgers.edu>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      80409c65
    • Andrei Vagin's avatar
      kernel/exit.c: release ptraced tasks before zap_pid_ns_processes · 8fb335e0
      Andrei Vagin authored
      Currently, exit_ptrace() adds all ptraced tasks in a dead list, then
      zap_pid_ns_processes() waits on all tasks in a current pidns, and only
      then are tasks from the dead list released.
      
      zap_pid_ns_processes() can get stuck on waiting tasks from the dead
      list.  In this case, we will have one unkillable process with one or
      more dead children.
      
      Thanks to Oleg for the advice to release tasks in find_child_reaper().
      
      Link: http://lkml.kernel.org/r/20190110175200.12442-1-avagin@gmail.com
      Fixes: 7c8bd232 ("exit: ptrace: shift "reap dead" code from exit_ptrace() to forget_original_parent()")
      Signed-off-by: default avatarAndrei Vagin <avagin@gmail.com>
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8fb335e0
    • Qian Cai's avatar
      x86_64: increase stack size for KASAN_EXTRA · a8e911d1
      Qian Cai authored
      If the kernel is configured with KASAN_EXTRA, the stack size is
      increasted significantly because this option sets "-fstack-reuse" to
      "none" in GCC [1].  As a result, it triggers stack overrun quite often
      with 32k stack size compiled using GCC 8.  For example, this reproducer
      
        https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise06.c
      
      triggers a "corrupted stack end detected inside scheduler" very reliably
      with CONFIG_SCHED_STACK_END_CHECK enabled.
      
      There are just too many functions that could have a large stack with
      KASAN_EXTRA due to large local variables that have been called over and
      over again without being able to reuse the stacks.  Some noticiable ones
      are
      
        size
        7648 shrink_page_list
        3584 xfs_rmap_convert
        3312 migrate_page_move_mapping
        3312 dev_ethtool
        3200 migrate_misplaced_transhuge_page
        3168 copy_process
      
      There are other 49 functions are over 2k in size while compiling kernel
      with "-Wframe-larger-than=" even with a related minimal config on this
      machine.  Hence, it is too much work to change Makefiles for each object
      to compile without "-fsanitize-address-use-after-scope" individually.
      
      [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715#c23
      
      Although there is a patch in GCC 9 to help the situation, GCC 9 probably
      won't be released in a few months and then it probably take another
      6-month to 1-year for all major distros to include it as a default.
      Hence, the stack usage with KASAN_EXTRA can be revisited again in 2020
      when GCC 9 is everywhere.  Until then, this patch will help users avoid
      stack overrun.
      
      This has already been fixed for arm64 for the same reason via
      6e883067 ("arm64: kasan: Increase stack size for KASAN_EXTRA").
      
      Link: http://lkml.kernel.org/r/20190109215209.2903-1-cai@lca.pwSigned-off-by: default avatarQian Cai <cai@lca.pw>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a8e911d1
    • Andrea Arcangeli's avatar
      mm/hugetlb.c: teach follow_hugetlb_page() to handle FOLL_NOWAIT · 1ac25013
      Andrea Arcangeli authored
      hugetlb needs the same fix as faultin_nopage (which was applied in
      commit 96312e61 ("mm/gup.c: teach get_user_pages_unlocked to handle
      FOLL_NOWAIT")) or KVM hangs because it thinks the mmap_sem was already
      released by hugetlb_fault() if it returned VM_FAULT_RETRY, but it wasn't
      in the FOLL_NOWAIT case.
      
      Link: http://lkml.kernel.org/r/20190109020203.26669-2-aarcange@redhat.com
      Fixes: ce53053c ("kvm: switch get_user_page_nowait() to get_user_pages_unlocked()")
      Signed-off-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Tested-by: default avatar"Dr. David Alan Gilbert" <dgilbert@redhat.com>
      Reported-by: default avatar"Dr. David Alan Gilbert" <dgilbert@redhat.com>
      Reviewed-by: default avatarMike Kravetz <mike.kravetz@oracle.com>
      Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1ac25013
    • Masahiro Yamada's avatar
      arch: unexport asm/shmparam.h for all architectures · 36c0f7f0
      Masahiro Yamada authored
      Most architectures do not export shmparam.h to user-space.
      
        $ find arch -name shmparam.h  | sort
        arch/alpha/include/asm/shmparam.h
        arch/arc/include/asm/shmparam.h
        arch/arm64/include/asm/shmparam.h
        arch/arm/include/asm/shmparam.h
        arch/csky/include/asm/shmparam.h
        arch/ia64/include/asm/shmparam.h
        arch/mips/include/asm/shmparam.h
        arch/nds32/include/asm/shmparam.h
        arch/nios2/include/asm/shmparam.h
        arch/parisc/include/asm/shmparam.h
        arch/powerpc/include/asm/shmparam.h
        arch/s390/include/asm/shmparam.h
        arch/sh/include/asm/shmparam.h
        arch/sparc/include/asm/shmparam.h
        arch/x86/include/asm/shmparam.h
        arch/xtensa/include/asm/shmparam.h
      
      Strangely, some users of the asm-generic wrapper export shmparam.h
      
        $ git grep 'generic-y += shmparam.h'
        arch/c6x/include/uapi/asm/Kbuild:generic-y += shmparam.h
        arch/h8300/include/uapi/asm/Kbuild:generic-y += shmparam.h
        arch/hexagon/include/uapi/asm/Kbuild:generic-y += shmparam.h
        arch/m68k/include/uapi/asm/Kbuild:generic-y += shmparam.h
        arch/microblaze/include/uapi/asm/Kbuild:generic-y += shmparam.h
        arch/openrisc/include/uapi/asm/Kbuild:generic-y += shmparam.h
        arch/riscv/include/asm/Kbuild:generic-y += shmparam.h
        arch/unicore32/include/uapi/asm/Kbuild:generic-y += shmparam.h
      
      The newly added riscv correctly creates the asm-generic wrapper
      in the kernel space, but the others (c6x, h8300, hexagon, m68k,
      microblaze, openrisc, unicore32) create the one in the uapi directory.
      
      Digging into the git history, now I guess fcc8487d ("uapi:
      export all headers under uapi directories") was the misconversion.
      Prior to that commit, no architecture exported to shmparam.h
      As its commit description said, that commit exported shmparam.h
      for c6x, h8300, hexagon, m68k, openrisc, unicore32.
      
      83f0124a ("microblaze: remove asm-generic wrapper headers")
      accidentally exported shmparam.h for microblaze.
      
      This commit unexports shmparam.h for those architectures.
      
      There is no more reason to export include/uapi/asm-generic/shmparam.h,
      so it has been moved to include/asm-generic/shmparam.h
      
      Link: http://lkml.kernel.org/r/1546904307-11124-1-git-send-email-yamada.masahiro@socionext.comSigned-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarStafford Horne <shorne@gmail.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Guan Xuetao <gxt@pku.edu.cn>
      Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Aurelien Jacquiot <jacquiot.aurelien@gmail.com>
      Cc: Greentime Hu <green.hu@gmail.com>
      Cc: Guo Ren <guoren@kernel.org>
      Cc: Palmer Dabbelt <palmer@sifive.com>
      Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Vincent Chen <deanbo422@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      36c0f7f0
    • Alexey Dobriyan's avatar
      proc: fix /proc/net/* after setns(2) · 1fde6f21
      Alexey Dobriyan authored
      /proc entries under /proc/net/* can't be cached into dcache because
      setns(2) can change current net namespace.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: avoid vim miscolorization]
      [adobriyan@gmail.com: write test, add dummy ->d_revalidate hook: necessary if /proc/net/* is pinned at setns time]
        Link: http://lkml.kernel.org/r/20190108192350.GA12034@avx2
      Link: http://lkml.kernel.org/r/20190107162336.GA9239@avx2
      Fixes: 1da4d377 ("proc: revalidate misc dentries")
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Reported-by: default avatarMateusz Stępień <mateusz.stepien@netrounds.com>
      Reported-by: default avatarAhmad Fatoum <a.fatoum@pengutronix.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1fde6f21
    • Oscar Salvador's avatar
      mm, memory_hotplug: don't bail out in do_migrate_range() prematurely · 1723058e
      Oscar Salvador authored
      do_migrate_range() takes a memory range and tries to isolate the pages
      to put them into a list.  This list will be later on used in
      migrate_pages() to know the pages we need to migrate.
      
      Currently, if we fail to isolate a single page, we put all already
      isolated pages back to their LRU and we bail out from the function.
      This is quite suboptimal, as this will force us to start over again
      because scan_movable_pages will give us the same range.  If there is no
      chance that we can isolate that page, we will loop here forever.
      
      Issue debugged in [1] has proved that.  During the debugging of that
      issue, it was noticed that if do_migrate_ranges() fails to isolate a
      single page, we will just discard the work we have done so far and bail
      out, which means that scan_movable_pages() will find again the same set
      of pages.
      
      Instead, we can just skip the error, keep isolating as much pages as
      possible and then proceed with the call to migrate_pages().
      
      This will allow us to do as much work as possible at once.
      
      [1] https://lkml.org/lkml/2018/12/6/324
      
      Michal said:
      
      : I still think that this doesn't give us a whole picture.  Looping for
      : ever is a bug.  Failing the isolation is quite possible and it should
      : be a ephemeral condition (e.g.  a race with freeing the page or
      : somebody else isolating the page for whatever reason).  And here comes
      : the disadvantage of the current implementation.  We simply throw
      : everything on the floor just because of a ephemeral condition.  The
      : racy page_count check is quite dubious to prevent from that.
      
      Link: http://lkml.kernel.org/r/20181211135312.27034-1-osalvador@suse.deSigned-off-by: default avatarOscar Salvador <osalvador@suse.de>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: David Hildenbrand <david@redhat.com>
      Cc: Dan Williams <dan.j.williams@gmail.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: William Kucharski <william.kucharski@oracle.com>
      Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1723058e
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma · 5eeb6335
      Linus Torvalds authored
      Pull rdma fixes from Jason Gunthorpe:
       "Still not much going on, the usual set of oops and driver fixes this
        time:
      
         - Fix two uapi breakage regressions in mlx5 drivers
      
         - Various oops fixes in hfi1, mlx4, umem, uverbs, and ipoib
      
         - A protocol bug fix for hfi1 preventing it from implementing the
           verbs API properly, and a compatability fix for EXEC STACK user
           programs
      
         - Fix missed refcounting in the 'advise_mr' patches merged this
           cycle.
      
         - Fix wrong use of the uABI in the hns SRQ patches merged this cycle"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
        IB/uverbs: Fix OOPs in uverbs_user_mmap_disassociate
        IB/ipoib: Fix for use-after-free in ipoib_cm_tx_start
        IB/uverbs: Fix ioctl query port to consider device disassociation
        RDMA/mlx5: Fix flow creation on representors
        IB/uverbs: Fix OOPs upon device disassociation
        RDMA/umem: Add missing initialization of owning_mm
        RDMA/hns: Update the kernel header file of hns
        IB/mlx5: Fix how advise_mr() launches async work
        RDMA/device: Expose ib_device_try_get(()
        IB/hfi1: Add limit test for RC/UC send via loopback
        IB/hfi1: Remove overly conservative VM_EXEC flag check
        IB/{hfi1, qib}: Fix WC.byte_len calculation for UD_SEND_WITH_IMM
        IB/mlx4: Fix using wrong function to destroy sqp AHs under SRIOV
        RDMA/mlx5: Fix check for supported user flags when creating a QP
      5eeb6335
    • Linus Torvalds's avatar
      Merge tag 'iomap-5.0-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux · 9ace868a
      Linus Torvalds authored
      Pull iomap fixes from Darrick Wong:
       "A couple of iomap fixes to eliminate some memory corruption and hang
        problems that were reported:
      
         - fix page migration when using iomap for pagecache management
      
         - fix a use-after-free bug in the directio code"
      
      * tag 'iomap-5.0-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
        iomap: fix a use after free in iomap_dio_rw
        iomap: get/put the page in iomap_page_create/release()
      9ace868a
    • Linus Torvalds's avatar
      Merge tag 'pm-5.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 3325254c
      Linus Torvalds authored
      Pull power management fixes from Rafael Wysocki:
       "These fix a PM-runtime framework regression introduced by the recent
        switch-over of device autosuspend to hrtimers and a mistake in the
        "poll idle state" code introduced by a recent change in it.
      
        Specifics:
      
         - Since ktime_get() turns out to be problematic for device
           autosuspend in the PM-runtime framework, make it use
           ktime_get_mono_fast_ns() instead (Vincent Guittot).
      
         - Fix an initial value of a local variable in the "poll idle state"
           code that makes it behave not exactly as expected when all idle
           states except for the "polling" one are disabled (Doug Smythies)"
      
      * tag 'pm-5.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        cpuidle: poll_state: Fix default time limit
        PM-runtime: Fix deadlock with ktime_get()
      3325254c
    • Linus Torvalds's avatar
      Merge tag 'acpi-5.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 4771eec1
      Linus Torvalds authored
      Pull ACPI Kconfig fixes from Rafael Wysocki:
       "Prevent invalid configurations from being created (e.g. by randconfig)
        due to some ACPI-related Kconfig options' dependencies that are not
        specified directly (Sinan Kaya)"
      
      * tag 'acpi-5.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        platform/x86: Fix unmet dependency warning for SAMSUNG_Q10
        platform/x86: Fix unmet dependency warning for ACPI_CMPC
        mfd: Fix unmet dependency warning for MFD_TPS68470
      4771eec1
    • Linus Torvalds's avatar
      Merge tag 'mmc-v5.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc · cca2e06a
      Linus Torvalds authored
      Pull MMC host fixes from Ulf Hansson:
      
       - mediatek: Fix incorrect register write for tunings
      
       - bcm2835: Fixup leakage of DMA channel on probe errors
      
      * tag 'mmc-v5.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
        mmc: mediatek: fix incorrect register setting of hs400_cmd_int_delay
        mmc: bcm2835: Fix DMA channel leak on probe error
      cca2e06a
    • Linus Torvalds's avatar
      Merge tag 'i3c/fixes-for-5.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux · 520fac05
      Linus Torvalds authored
      Pull i3c fixes from Boris Brezillon:
      
       - Fix a deadlock in the designware driver
      
       - Fix the error path in i3c_master_add_i3c_dev_locked()
      
      * tag 'i3c/fixes-for-5.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux:
        i3c: master: dw: fix deadlock
        i3c: fix missing detach if failed to retrieve i3c dev
      520fac05
    • Linus Torvalds's avatar
      x86: explicitly align IO accesses in memcpy_{to,from}io · c228d294
      Linus Torvalds authored
      In commit 170d13ca ("x86: re-introduce non-generic memcpy_{to,from}io")
      I made our copy from IO space use a separate copy routine rather than
      rely on the generic memcpy.  I did that because our generic memory copy
      isn't actually well-defined when it comes to internal access ordering or
      alignment, and will in fact depend on various CPUID flags.
      
      In particular, the default memcpy() for a modern Intel CPU will
      generally be just a "rep movsb", which works reasonably well for
      medium-sized memory copies of regular RAM, since the CPU will turn it
      into fairly optimized microcode.
      
      However, for non-cached memory and IO, "rep movs" ends up being
      horrendously slow and will just do the architectural "one byte at a
      time" accesses implied by the movsb.
      
      At the other end of the spectrum, if you _don't_ end up using the "rep
      movsb" code, you'd likely fall back to the software copy, which does
      overlapping accesses for the tail, and may copy things backwards.
      Again, for regular memory that's fine, for IO memory not so much.
      
      The thinking was that clearly nobody really cared (because things
      worked), but some people had seen horrible performance due to the byte
      accesses, so let's just revert back to our long ago version that dod
      "rep movsl" for the bulk of the copy, and then fixed up the potentially
      last few bytes of the tail with "movsw/b".
      
      Interestingly (and perhaps not entirely surprisingly), while that was
      our original memory copy implementation, and had been used before for
      IO, in the meantime many new users of memcpy_*io() had come about.  And
      while the access patterns for the memory copy weren't well-defined (so
      arguably _any_ access pattern should work), in practice the "rep movsb"
      case had been very common for the last several years.
      
      In particular Jarkko Sakkinen reported that the memcpy_*io() change
      resuled in weird errors from his Geminilake NUC TPM module.
      
      And it turns out that the TPM TCG accesses according to spec require
      that the accesses be
      
       (a) done strictly sequentially
      
       (b) be naturally aligned
      
      otherwise the TPM chip will abort the PCI transaction.
      
      And, in fact, the tpm_crb.c driver did this:
      
      	memcpy_fromio(buf, priv->rsp, 6);
      	...
      	memcpy_fromio(&buf[6], &priv->rsp[6], expected - 6);
      
      which really should never have worked in the first place, but back
      before commit 170d13ca it *happened* to work, because the
      memcpy_fromio() would be expanded to a regular memcpy, and
      
       (a) gcc would expand the first memcpy in-line, and turn it into a
           4-byte and a 2-byte read, and they happened to be in the right
           order, and the alignment was right.
      
       (b) gcc would call "memcpy()" for the second one, and the machines that
           had this TPM chip also apparently ended up always having ERMS
           ("Enhanced REP MOVSB/STOSB instructions"), so we'd use the "rep
           movbs" for that copy.
      
      In other words, basically by pure luck, the code happened to use the
      right access sizes in the (two different!) memcpy() implementations to
      make it all work.
      
      But after commit 170d13ca, both of the memcpy_fromio() calls
      resulted in a call to the routine with the consistent memory accesses,
      and in both cases it started out transferring with 4-byte accesses.
      Which worked for the first copy, but resulted in the second copy doing a
      32-bit read at an address that was only 2-byte aligned.
      
      Jarkko is actually fixing the fragile code in the TPM driver, but since
      this is an excellent example of why we absolutely must not use a generic
      memcpy for IO accesses, _and_ an IO-specific one really should strive to
      align the IO accesses, let's do exactly that.
      
      Side note: Jarkko also noted that the driver had been used on ARM
      platforms, and had worked.  That was because on 32-bit ARM, memcpy_*io()
      ends up always doing byte accesses, and on 64-bit ARM it first does byte
      accesses to align to 8-byte boundaries, and then does 8-byte accesses
      for the bulk.
      
      So ARM actually worked by design, and the x86 case worked by pure luck.
      
      We *might* want to make x86-64 do the 8-byte case too.  That should be a
      pretty straightforward extension, but let's do one thing at a time.  And
      generally MMIO accesses aren't really all that performance-critical, as
      shown by the fact that for a long time we just did them a byte at a
      time, and very few people ever noticed.
      Reported-and-tested-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Tested-by: default avatarJerry Snitselaar <jsnitsel@redhat.com>
      Cc: David Laight <David.Laight@aculab.com>
      Fixes: 170d13ca ("x86: re-introduce non-generic memcpy_{to,from}io")
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c228d294
    • Rafael J. Wysocki's avatar
      Merge branch 'acpi-misc' · b473406a
      Rafael J. Wysocki authored
      * acpi-misc:
        platform/x86: Fix unmet dependency warning for SAMSUNG_Q10
        platform/x86: Fix unmet dependency warning for ACPI_CMPC
      b473406a
    • Rafael J. Wysocki's avatar
      Merge branch 'pm-cpuidle-fixes' · cbffab68
      Rafael J. Wysocki authored
      * pm-cpuidle-fixes:
        cpuidle: poll_state: Fix default time limit
      cbffab68
    • Linus Torvalds's avatar
      Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux · 5b4746a0
      Linus Torvalds authored
      Pull clk fixes from Stephen Boyd:
       "Mostly driver fixes, but there's a core framework fix in here too:
      
         - Revert the commits that introduce clk management for the SP clk on
           MMP2 SoCs (used for OLPC). Turns out it wasn't a good idea and
           there isn't any need to manage this clk, it just causes more
           headaches.
      
         - A performance regression that went unnoticed for many years where
           we would traverse the entire clk tree looking for a clk by name
           when we already have the pointer to said clk that we're looking for
      
         - A parent linkage fix for the qcom SDM845 clk driver
      
         - An i.MX clk driver rate miscalculation fix where order of
           operations were messed up
      
         - One error handling fix from the static checkers"
      
      * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
        clk: qcom: gcc: Use active only source for CPUSS clocks
        clk: ti: Fix error handling in ti_clk_parse_divider_data()
        clk: imx: Fix fractional clock set rate computation
        clk: Remove global clk traversal on fetch parent index
        Revert "dt-bindings: marvell,mmp2: Add clock id for the SP clock"
        Revert "clk: mmp2: add SP clock"
        Revert "Input: olpc_apsp - enable the SP clock"
      5b4746a0
    • Linus Torvalds's avatar
      Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 · 52107c54
      Linus Torvalds authored
      Pull crypto fix from Herbert Xu:
       "This fixes a bug in cavium/nitrox where the callback is invoked prior
        to the DMA unmap"
      
      * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
        crypto: cavium/nitrox - Invoke callback after DMA unmap
      52107c54
    • Linus Torvalds's avatar
      Merge tag 'pci-v5.0-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci · 44e56f32
      Linus Torvalds authored
      Pull PCI fixes from Bjorn Helgaas:
      
       - Revert armada8k GPIO reset change that broke Macchiatobin booting
         (Baruch Siach)
      
       - Use actual size config reads on ARM cns3xxx (Koen Vandeputte)
      
       - Fix ARM cns3xxx config write alignment issue (Koen Vandeputte)
      
       - Fix imx6 PHY device link error checking (Leonard Crestez)
      
       - Fix imx6 probe failure on chips without separate PCI power domain
         (Leonard Crestez)
      
      * tag 'pci-v5.0-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
        Revert "PCI: armada8k: Add support for gpio controlled reset signal"
        ARM: cns3xxx: Use actual size reads for PCIe
        ARM: cns3xxx: Fix writing to wrong PCI config registers after alignment
        PCI: imx: Fix checking pd_pcie_phy device link addition
        PCI: imx: Fix probe failure without power domain
      44e56f32
  2. 31 Jan, 2019 9 commits
  3. 30 Jan, 2019 8 commits
    • Doug Smythies's avatar
      cpuidle: poll_state: Fix default time limit · 1617971c
      Doug Smythies authored
      The default time is declared in units of microsecnds,
      but is used as nanoseconds, resulting in significant
      accounting errors for idle state 0 time when all idle
      states deeper than 0 are disabled.
      
      Under these unusual conditions, we don't really care
      about the poll time limit anyhow.
      
      Fixes: 800fb34a ("cpuidle: poll_state: Disregard disable idle states")
      Signed-off-by: default avatarDoug Smythies <dsmythies@telus.net>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1617971c
    • Vincent Guittot's avatar
      PM-runtime: Fix deadlock with ktime_get() · 15efb47d
      Vincent Guittot authored
      A deadlock has been seen when swicthing clocksources which use
      PM-runtime.  The call path is:
      
      change_clocksource
          ...
          write_seqcount_begin
          ...
          timekeeping_update
              ...
              sh_cmt_clocksource_enable
                  ...
                  rpm_resume
                      pm_runtime_mark_last_busy
                          ktime_get
                              do
                                  read_seqcount_begin
                              while read_seqcount_retry
          ....
          write_seqcount_end
      
      Although we should be safe because we haven't yet changed the
      clocksource at that time, we can't do that because of seqcount
      protection.
      
      Use ktime_get_mono_fast_ns() instead which is lock safe for such
      cases.
      
      With ktime_get_mono_fast_ns, the timestamp is not guaranteed to be
      monotonic across an update and as a result can goes backward.
      According to update_fast_timekeeper() description: "In the worst
      case, this can result is a slightly wrong timestamp (a few
      nanoseconds)". For PM-runtime autosuspend, this means only that
      the suspend decision may be slightly suboptimal.
      
      Fixes: 8234f673 ("PM-runtime: Switch autosuspend over to using hrtimers")
      Reported-by: default avatarBiju Das <biju.das@bp.renesas.com>
      Signed-off-by: default avatarVincent Guittot <vincent.guittot@linaro.org>
      Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      15efb47d
    • Waiman Long's avatar
      fs/dcache: Track & report number of negative dentries · af0c9af1
      Waiman Long authored
      The current dentry number tracking code doesn't distinguish between
      positive & negative dentries.  It just reports the total number of
      dentries in the LRU lists.
      
      As excessive number of negative dentries can have an impact on system
      performance, it will be wise to track the number of positive and
      negative dentries separately.
      
      This patch adds tracking for the total number of negative dentries in
      the system LRU lists and reports it in the 5th field in the
      /proc/sys/fs/dentry-state file.  The number, however, does not include
      negative dentries that are in flight but not in the LRU yet as well as
      those in the shrinker lists which are on the way out anyway.
      
      The number of positive dentries in the LRU lists can be roughly found by
      subtracting the number of negative dentries from the unused count.
      
      Matthew Wilcox had confirmed that since the introduction of the
      dentry_stat structure in 2.1.60, the dummy array was there, probably for
      future extension.  They were not replacements of pre-existing fields.
      So no sane applications that read the value of /proc/sys/fs/dentry-state
      will do dummy thing if the last 2 fields of the sysctl parameter are not
      zero.  IOW, it will be safe to use one of the dummy array entry for
      negative dentry count.
      Signed-off-by: default avatarWaiman Long <longman@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      af0c9af1
    • Waiman Long's avatar
      fs: Don't need to put list_lru into its own cacheline · 7d10f70f
      Waiman Long authored
      The list_lru structure is essentially just a pointer to a table of
      per-node LRU lists.  Even if CONFIG_MEMCG_KMEM is defined, the list
      field is just used for LRU list registration and shrinker_id is set at
      initialization.  Those fields won't need to be touched that often.
      
      So there is no point to make the list_lru structures to sit in their own
      cachelines.
      Signed-off-by: default avatarWaiman Long <longman@redhat.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7d10f70f
    • Waiman Long's avatar
      fs/dcache: Fix incorrect nr_dentry_unused accounting in shrink_dcache_sb() · 1dbd449c
      Waiman Long authored
      The nr_dentry_unused per-cpu counter tracks dentries in both the LRU
      lists and the shrink lists where the DCACHE_LRU_LIST bit is set.
      
      The shrink_dcache_sb() function moves dentries from the LRU list to a
      shrink list and subtracts the dentry count from nr_dentry_unused.  This
      is incorrect as the nr_dentry_unused count will also be decremented in
      shrink_dentry_list() via d_shrink_del().
      
      To fix this double decrement, the decrement in the shrink_dcache_sb()
      function is taken out.
      
      Fixes: 4e717f5c ("list_lru: remove special case function list_lru_dispose_all."
      Cc: stable@kernel.org
      Signed-off-by: default avatarWaiman Long <longman@redhat.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1dbd449c
    • Linus Torvalds's avatar
      Merge tag 'iommu-fixes-v5.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu · 1c0490ce
      Linus Torvalds authored
      Pull IOMMU fixes from Joerg Roedel:
       "A few more fixes this time:
      
         - Two patches to fix the error path of the map_sg implementation of
           the AMD IOMMU driver.
      
         - Also a missing IOTLB flush is fixed in the AMD IOMMU driver.
      
         - Memory leak fix for the Intel IOMMU driver.
      
         - Fix a regression in the Mediatek IOMMU driver which caused device
           initialization to fail (seen as broken HDMI output)"
      
      * tag 'iommu-fixes-v5.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
        iommu/amd: Fix IOMMU page flush when detach device from a domain
        iommu/mediatek: Use correct fwspec in mtk_iommu_add_device()
        iommu/vt-d: Fix memory leak in intel_iommu_put_resv_regions()
        iommu/amd: Unmap all mapped pages in error path of map_sg
        iommu/amd: Call free_iova_fast with pfn in map_sg
      1c0490ce
    • Linus Torvalds's avatar
      Merge tag 'gpio-v5.0-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio · 877ef51d
      Linus Torvalds authored
      Pull GPIO fixes from Linus Walleij:
       "Here is a bunch of GPIO fixes for the v5.0 series. I was helped out by
        Bartosz in collecting these fixes, for which I am very grateful, the
        biggest achievement in GPIO right now is work distribution.
      
        There is one serious core fix (timestamping) and a bunch of driver
        fixes:
      
         - Fix timestamps on nested IRQs
      
         - Handle IRQs properly in multiple instances of PCF857x
      
         - Use the right data register and IRQ type setting in the Spreadtrum
           GPIO driver
      
         - Let the value argument work properly when setting direction in the
           Altera GPIO driver
      
         - Mask interrupts properly in the vf610 driver"
      
      * tag 'gpio-v5.0-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
        gpio: vf610: Mask all GPIO interrupts
        gpio: altera-a10sr: Set proper output level for direction_output
        gpio: sprd: Fix incorrect irq type setting for the async EIC
        gpio: sprd: Fix the incorrect data register
        gpiolib: fix line event timestamps for nested irqs
        gpio: pcf857x: Fix interrupts on multiple instances
      877ef51d
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 62967898
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Need to save away the IV across tls async operations, from Dave
          Watson.
      
       2) Upon successful packet processing, we should liberate the SKB with
          dev_consume_skb{_irq}(). From Yang Wei.
      
       3) Only apply RX hang workaround on effected macb chips, from Harini
          Katakam.
      
       4) Dummy netdev need a proper namespace assigned to them, from Josh
          Elsasser.
      
       5) Some paths of nft_compat run lockless now, and thus we need to use a
          proper refcnt_t. From Florian Westphal.
      
       6) Avoid deadlock in mlx5 by doing IRQ locking, from Moni Shoua.
      
       7) netrom does not refcount sockets properly wrt. timers, fix that by
          using the sock timer API. From Cong Wang.
      
       8) Fix locking of inexact inserts of xfrm policies, from Florian
          Westphal.
      
       9) Missing xfrm hash generation bump, also from Florian.
      
      10) Missing of_node_put() in hns driver, from Yonglong Liu.
      
      11) Fix DN_IFREQ_SIZE, from Johannes Berg.
      
      12) ip6mr notifier is invoked during traversal of wrong table, from Nir
          Dotan.
      
      13) TX promisc settings not performed correctly in qed, from Manish
          Chopra.
      
      14) Fix OOB access in vhost, from Jason Wang.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (52 commits)
        MAINTAINERS: Add entry for XDP (eXpress Data Path)
        net: set default network namespace in init_dummy_netdev()
        net: b44: replace dev_kfree_skb_xxx by dev_consume_skb_xxx for drop profiles
        net: caif: call dev_consume_skb_any when skb xmit done
        net: 8139cp: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
        net: macb: Apply RXUBR workaround only to versions with errata
        net: ti: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
        net: apple: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
        net: amd8111e: replace dev_kfree_skb_irq by dev_consume_skb_irq
        net: alteon: replace dev_kfree_skb_irq by dev_consume_skb_irq
        net: tls: Fix deadlock in free_resources tx
        net: tls: Save iv in tls_rec for async crypto requests
        vhost: fix OOB in get_rx_bufs()
        qed: Fix stack out of bounds bug
        qed: Fix system crash in ll2 xmit
        qed: Fix VF probe failure while FLR
        qed: Fix LACP pdu drops for VFs
        qed: Fix bug in tx promiscuous mode settings
        net: i825xx: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
        netfilter: ipt_CLUSTERIP: fix warning unused variable cn
        ...
      62967898
  4. 29 Jan, 2019 1 commit