Forum | Documentation | Website | Blog

Skip to content
Snippets Groups Projects
  1. Nov 20, 2021
    • Nathan Chancellor's avatar
      hexagon: clean up timer-regs.h · 51f2ec59
      Nathan Chancellor authored
      When building allmodconfig, there is a warning about TIMER_ENABLE being
      redefined:
      
        drivers/clocksource/timer-oxnas-rps.c:39:9: error: 'TIMER_ENABLE' macro redefined [-Werror,-Wmacro-redefined]
        #define TIMER_ENABLE            BIT(7)
                ^
        arch/hexagon/include/asm/timer-regs.h:13:9: note: previous definition is here
        #define TIMER_ENABLE            0
                 ^
        1 error generated.
      
      The values in this header are only used in one file each, if they are
      used at all.  Remove the header and sink all of the constants into their
      respective files.
      
      TCX0_CLK_RATE is only used in arch/hexagon/include/asm/timex.h
      
      TIMER_ENABLE, RTOS_TIMER_INT, RTOS_TIMER_REGS_ADDR are only used in
      arch/hexagon/kernel/time.c.
      
      SLEEP_CLK_RATE and TIMER_CLR_ON_MATCH have both been unused since the
      file's introduction in commit 71e4a47f ("Hexagon: Add time and timer
      functions").
      
      TIMER_ENABLE is redefined as BIT(0) so the shift is moved into the
      definition, rather than its use.
      
      Link: https://lkml.kernel.org/r/20211115174250.1994179-3-nathan@kernel.org
      
      
      Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
      Acked-by: default avatarBrian Cain <bcain@codeaurora.org>
      Cc: Nick Desaulniers <ndesaulniers@google.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>
      51f2ec59
    • Nathan Chancellor's avatar
      hexagon: export raw I/O routines for modules · ffb92ce8
      Nathan Chancellor authored
      Patch series "Fixes for ARCH=hexagon allmodconfig", v2.
      
      This series fixes some issues noticed with ARCH=hexagon allmodconfig.
      
      This patch (of 3):
      
      When building ARCH=hexagon allmodconfig, the following errors occur:
      
        ERROR: modpost: "__raw_readsl" [drivers/i3c/master/svc-i3c-master.ko] undefined!
        ERROR: modpost: "__raw_writesl" [drivers/i3c/master/dw-i3c-master.ko] undefined!
        ERROR: modpost: "__raw_readsl" [drivers/i3c/master/dw-i3c-master.ko] undefined!
        ERROR: modpost: "__raw_writesl" [drivers/i3c/master/i3c-master-cdns.ko] undefined!
        ERROR: modpost: "__raw_readsl" [drivers/i3c/master/i3c-master-cdns.ko] undefined!
      
      Export these symbols so that modules can use them without any errors.
      
      Link: https://lkml.kernel.org/r/20211115174250.1994179-1-nathan@kernel.org
      Link: https://lkml.kernel.org/r/20211115174250.1994179-2-nathan@kernel.org
      Fixes: 013bf24c
      
       ("Hexagon: Provide basic implementation and/or stubs for I/O routines.")
      Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
      Acked-by: default avatarBrian Cain <bcain@codeaurora.org>
      Cc: Nick Desaulniers <ndesaulniers@google.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>
      ffb92ce8
    • Yunfeng Ye's avatar
      mm: emit the "free" trace report before freeing memory in kmem_cache_free() · 9a543f00
      Yunfeng Ye authored
      After the memory is freed, it can be immediately allocated by other
      CPUs, before the "free" trace report has been emitted.  This causes
      inaccurate traces.
      
      For example, if the following sequence of events occurs:
      
          CPU 0                 CPU 1
      
        (1) alloc xxxxxx
        (2) free  xxxxxx
                               (3) alloc xxxxxx
                               (4) free  xxxxxx
      
      Then they will be inaccurately reported via tracing, so that they appear
      to have happened in this order:
      
          CPU 0                 CPU 1
      
        (1) alloc xxxxxx
                               (2) alloc xxxxxx
        (3) free  xxxxxx
                               (4) free  xxxxxx
      
      This makes it look like CPU 1 somehow managed to allocate memory that
      CPU 0 still had allocated for itself.
      
      In order to avoid this, emit the "free xxxxxx" tracing report just
      before the actual call to free the memory, instead of just after it.
      
      Link: https://lkml.kernel.org/r/374eb75d-7404-8721-4e1e-65b0e5b17279@huawei.com
      
      
      Signed-off-by: default avatarYunfeng Ye <yeyunfeng@huawei.com>
      Reviewed-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Reviewed-by: default avatarJohn Hubbard <jhubbard@nvidia.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9a543f00
    • Alexander Mikhalitsyn's avatar
      shm: extend forced shm destroy to support objects from several IPC nses · 85b6d246
      Alexander Mikhalitsyn authored
      Currently, the exit_shm() function not designed to work properly when
      task->sysvshm.shm_clist holds shm objects from different IPC namespaces.
      
      This is a real pain when sysctl kernel.shm_rmid_forced = 1, because it
      leads to use-after-free (reproducer exists).
      
      This is an attempt to fix the problem by extending exit_shm mechanism to
      handle shm's destroy from several IPC ns'es.
      
      To achieve that we do several things:
      
      1. add a namespace (non-refcounted) pointer to the struct shmid_kernel
      
      2. during new shm object creation (newseg()/shmget syscall) we
         initialize this pointer by current task IPC ns
      
      3. exit_shm() fully reworked such that it traverses over all shp's in
         task->sysvshm.shm_clist and gets IPC namespace not from current task
         as it was before but from shp's object itself, then call
         shm_destroy(shp, ns).
      
      Note: We need to be really careful here, because as it was said before
      (1), our pointer to IPC ns non-refcnt'ed.  T...
      85b6d246
    • Alexander Mikhalitsyn's avatar
      ipc: WARN if trying to remove ipc object which is absent · 126e8bee
      Alexander Mikhalitsyn authored
      Patch series "shm: shm_rmid_forced feature fixes".
      
      Some time ago I met kernel crash after CRIU restore procedure,
      fortunately, it was CRIU restore, so, I had dump files and could do
      restore many times and crash reproduced easily.  After some
      investigation I've constructed the minimal reproducer.  It was found
      that it's use-after-free and it happens only if sysctl
      kernel.shm_rmid_forced = 1.
      
      The key of the problem is that the exit_shm() function not handles shp's
      object destroy when task->sysvshm.shm_clist contains items from
      different IPC namespaces.  In most cases this list will contain only
      items from one IPC namespace.
      
      How can this list contain object from different namespaces? The
      exit_shm() function is designed to clean up this list always when
      process leaves IPC namespace.  But we made a mistake a long time ago and
      did not add a exit_shm() call into the setns() syscall procedures.
      
      The first idea was just to add this call to setns() syscall but it
      obviously changes semantics of setns() syscall and that's
      userspace-visible change.  So, I gave up on this idea.
      
      The first real attempt to address the issue was just to omit forced
      destroy if we meet shp object not from current task IPC namespace [1].
      But that was not the best idea because task->sysvshm.shm_clist was
      protected by rwsem which belongs to current task IPC namespace.  It
      means that list corruption may occur.
      
      Second approach is just extend exit_shm() to properly handle shp's from
      different IPC namespaces [2].  This is really non-trivial thing, I've
      put a lot of effort into that but not believed that it's possible to
      make it fully safe, clean and clear.
      
      Thanks to the efforts of Manfred Spraul working an elegant solution was
      designed.  Thanks a lot, Manfred!
      
      Eric also suggested the way to address the issue in ("[RFC][PATCH] shm:
      In shm_exit destroy all created and never attached segments") Eric's
      idea was to maintain a list of shm_clists one per IPC namespace, use
      lock-less lists.  But there is some extra memory consumption-related
      concerns.
      
      An alternative solution which was suggested by me was implemented in
      ("shm: reset shm_clist on setns but omit forced shm destroy").  The idea
      is pretty simple, we add exit_shm() syscall to setns() but DO NOT
      destroy shm segments even if sysctl kernel.shm_rmid_forced = 1, we just
      clean up the task->sysvshm.shm_clist list.
      
      This chages semantics of setns() syscall a little bit but in comparision
      to the "naive" solution when we just add exit_shm() without any special
      exclusions this looks like a safer option.
      
      [1] https://lkml.org/lkml/2021/7/6/1108
      [2] https://lkml.org/lkml/2021/7/14/736
      
      This patch (of 2):
      
      Let's produce a warning if we trying to remove non-existing IPC object
      from IPC namespace kht/idr structures.
      
      This allows us to catch possible bugs when the ipc_rmid() function was
      called with inconsistent struct ipc_ids*, struct kern_ipc_perm*
      arguments.
      
      Link: https://lkml.kernel.org/r/20211027224348.611025-1-alexander.mikhalitsyn@virtuozzo.com
      Link: https://lkml.kernel.org/r/20211027224348.611025-2-alexander.mikhalitsyn@virtuozzo.com
      
      
      Co-developed-by: default avatarManfred Spraul <manfred@colorfullife.com>
      Signed-off-by: default avatarManfred Spraul <manfred@colorfullife.com>
      Signed-off-by: default avatarAlexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Andrei Vagin <avagin@gmail.com>
      Cc: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
      Cc: Vasily Averin <vvs@virtuozzo.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>
      126e8bee
    • Matthew Wilcox's avatar
      mm/swap.c:put_pages_list(): reinitialise the page list · 3cd018b4
      Matthew Wilcox authored
      While free_unref_page_list() puts pages onto the CPU local LRU list, it
      does not remove them from the list they were passed in on.  That makes
      the list_head appear to be non-empty, and would lead to various
      corruption problems if we didn't have an assertion that the list was
      empty.
      
      Reinitialise the list after calling free_unref_page_list() to avoid this
      problem.
      
      Link: https://lkml.kernel.org/r/YYp40A2lNrxaZji8@casper.infradead.org
      Fixes: 988c69f1
      
       ("mm: optimise put_pages_list()")
      Signed-off-by: default avatarMatthew Wilcox (Oracle) <willy@infradead.org>
      Reviewed-by: default avatarSteve French <stfrench@microsoft.com>
      Reported-by: default avatarNamjae Jeon <linkinjeon@kernel.org>
      Tested-by: default avatarSteve French <stfrench@microsoft.com>
      Tested-by: default avatarNamjae Jeon <linkinjeon@kernel.org>
      Cc: Steve French <smfrench@gmail.com>
      Cc: Hyeoncheol Lee <hyc.lee@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3cd018b4
  2. Nov 19, 2021
  3. Nov 18, 2021