linux-toradex.git/kernel/notifier.c, branch v5.19-rc1

notifier: Add blocking/atomic_notifier_chain_register_unique_prio()

2022-05-19T17:30:30+00:00

Add variant of blocking/atomic_notifier_chain_register() functions that
allow registration of a notifier only if it has unique priority, otherwise
-EBUSY error code is returned by the new functions.

Reviewed-by: Michał Mirosław 
Signed-off-by: Dmitry Osipenko 
Signed-off-by: Rafael J. Wysocki

notifier: Add atomic_notifier_call_chain_is_empty()

2022-05-19T17:25:06+00:00

Add atomic_notifier_call_chain_is_empty() that returns true if given
atomic call chain is empty.

The first user of this new notifier API function will be the kernel
power-off core code that will support power-off call chains. The core
code will need to check whether there is a power-off handler registered
at all in order to decide whether to halt machine or power it off.

Reviewed-by: Michał Mirosław 
Signed-off-by: Dmitry Osipenko 
Signed-off-by: Rafael J. Wysocki

notifier: Return an error when a callback has already been registered

2021-12-29T09:37:33+00:00

Return -EEXIST when a notifier callback has already been registered on a
notifier chain.

This should avoid any homegrown registration tracking at the callsite
like

  https://lore.kernel.org/amd-gfx/20210512013058.6827-1-mukul.joshi@amd.com

for example.

This version is an alternative of

  https://lore.kernel.org/r/20211108101157.15189-1-bp@alien8.de

which needed to touch every caller not checking the registration
routine's return value.

Signed-off-by: Borislav Petkov 
Reviewed-by: Sebastian Andrzej Siewior 
Acked-by: Alan Stern 
Link: https://lore.kernel.org/r/YcSWNdUBS8A2ZB3s@zn.tnic

notifier: Remove atomic_notifier_call_chain_robust()

2021-08-16T16:55:32+00:00

This now has no more users, remove it.

Suggested-by: Sebastian Andrzej Siewior 
Signed-off-by: Valentin Schneider 
Acked-by: Sebastian Andrzej Siewior 
Signed-off-by: Rafael J. Wysocki

notifier: Fix broken error handling pattern

2020-09-01T07:58:03+00:00

The current notifiers have the following error handling pattern all
over the place:

	int err, nr;

	err = __foo_notifier_call_chain(&chain, val_up, v, -1, &nr);
	if (err & NOTIFIER_STOP_MASK)
		__foo_notifier_call_chain(&chain, val_down, v, nr-1, NULL)

And aside from the endless repetition thereof, it is broken. Consider
blocking notifiers; both calls take and drop the rwsem, this means
that the notifier list can change in between the two calls, making @nr
meaningless.

Fix this by replacing all the __foo_notifier_call_chain() functions
with foo_notifier_call_chain_robust() that embeds the above pattern,
but ensures it is inside a single lock region.

Note: I switched atomic_notifier_call_chain_robust() to use
      the spinlock, since RCU cannot provide the guarantee
      required for the recovery.

Note: software_resume() error handling was broken afaict.

Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Ingo Molnar 
Acked-by: Rafael J. Wysocki 
Link: https://lore.kernel.org/r/20200818135804.325626653@infradead.org

mm: remove vmalloc_sync_(un)mappings()

2020-06-02T17:59:12+00:00

These functions are not needed anymore because the vmalloc and ioremap
mappings are now synchronized when they are created or torn down.

Remove all callers and function definitions.

Signed-off-by: Joerg Roedel 
Signed-off-by: Andrew Morton 
Tested-by: Steven Rostedt (VMware) 
Acked-by: Andy Lutomirski 
Acked-by: Peter Zijlstra (Intel) 
Cc: Arnd Bergmann 
Cc: Christoph Hellwig 
Cc: Dave Hansen 
Cc: "H . Peter Anvin" 
Cc: Ingo Molnar 
Cc: Matthew Wilcox (Oracle) 
Cc: Michal Hocko 
Cc: "Rafael J. Wysocki" 
Cc: Thomas Gleixner 
Cc: Vlastimil Babka 
Link: http://lkml.kernel.org/r/20200515140023.25469-7-joro@8bytes.org
Signed-off-by: Linus Torvalds

x86/mm: split vmalloc_sync_all()

2020-03-22T01:56:06+00:00

Commit 3f8fd02b1bf1 ("mm/vmalloc: Sync unmappings in
__purge_vmap_area_lazy()") introduced a call to vmalloc_sync_all() in
the vunmap() code-path.  While this change was necessary to maintain
correctness on x86-32-pae kernels, it also adds additional cycles for
architectures that don't need it.

Specifically on x86-64 with CONFIG_VMAP_STACK=y some people reported
severe performance regressions in micro-benchmarks because it now also
calls the x86-64 implementation of vmalloc_sync_all() on vunmap().  But
the vmalloc_sync_all() implementation on x86-64 is only needed for newly
created mappings.

To avoid the unnecessary work on x86-64 and to gain the performance
back, split up vmalloc_sync_all() into two functions:

	* vmalloc_sync_mappings(), and
	* vmalloc_sync_unmappings()

Most call-sites to vmalloc_sync_all() only care about new mappings being
synchronized.  The only exception is the new call-site added in the
above mentioned commit.

Shile Zhang directed us to a report of an 80% regression in reaim
throughput.

Fixes: 3f8fd02b1bf1 ("mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()")
Reported-by: kernel test robot 
Reported-by: Shile Zhang 
Signed-off-by: Joerg Roedel 
Signed-off-by: Andrew Morton 
Tested-by: Borislav Petkov 
Acked-by: Rafael J. Wysocki 	[GHES]
Cc: Dave Hansen 
Cc: Andy Lutomirski 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: 
Link: http://lkml.kernel.org/r/20191009124418.8286-1-joro@8bytes.org
Link: https://lists.01.org/hyperkitty/list/lkp@lists.01.org/thread/4D3JPPHBNOSPFK2KEPC6KGKS6J25AIDB/
Link: http://lkml.kernel.org/r/20191113095530.228959-1-shile.zhang@linux.alibaba.com
Signed-off-by: Linus Torvalds

kernel/notifier.c: remove blocking_notifier_chain_cond_register()

2019-12-05T03:44:12+00:00

blocking_notifier_chain_cond_register() does not consider system_booting
state, which is the only difference between this function and
blocking_notifier_cain_register().  This can be a bug and is a piece of
duplicate code.

Delete blocking_notifier_chain_cond_register()

Link: http://lkml.kernel.org/r/1568861888-34045-4-git-send-email-nixiaoming@huawei.com
Signed-off-by: Xiaoming Ni 
Reviewed-by: Andrew Morton 
Cc: Alan Stern 
Cc: Alexey Dobriyan 
Cc: Andy Lutomirski 
Cc: Anna Schumaker 
Cc: Arjan van de Ven 
Cc: Chuck Lever 
Cc: David S. Miller 
Cc: Ingo Molnar 
Cc: J. Bruce Fields 
Cc: Jeff Layton 
Cc: Nadia Derbey 
Cc: "Paul E. McKenney" 
Cc: Sam Protsenko 
Cc: Thomas Gleixner 
Cc: Trond Myklebust 
Cc: Vasily Averin 
Cc: Viresh Kumar 
Cc: YueHaibing 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kernel/notifier.c: remove notifier_chain_cond_register()

2019-12-05T03:44:12+00:00

The only difference between notifier_chain_cond_register() and
notifier_chain_register() is the lack of warning hints for duplicate
registrations.  Use notifier_chain_register() instead of
notifier_chain_cond_register() to avoid duplicate code

Link: http://lkml.kernel.org/r/1568861888-34045-3-git-send-email-nixiaoming@huawei.com
Signed-off-by: Xiaoming Ni 
Reviewed-by: Andrew Morton 
Cc: Alan Stern 
Cc: Alexey Dobriyan 
Cc: Andy Lutomirski 
Cc: Anna Schumaker 
Cc: Arjan van de Ven 
Cc: Chuck Lever 
Cc: David S. Miller 
Cc: Ingo Molnar 
Cc: J. Bruce Fields 
Cc: Jeff Layton 
Cc: Nadia Derbey 
Cc: "Paul E. McKenney" 
Cc: Sam Protsenko 
Cc: Thomas Gleixner 
Cc: Trond Myklebust 
Cc: Vasily Averin 
Cc: Viresh Kumar 
Cc: YueHaibing 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kernel/notifier.c: intercept duplicate registrations to avoid infinite loops

2019-12-05T03:44:12+00:00

Registering the same notifier to a hook repeatedly can cause the hook
list to form a ring or lose other members of the list.

  case1: An infinite loop in notifier_chain_register() can cause soft lockup
          atomic_notifier_chain_register(&test_notifier_list, &test1);
          atomic_notifier_chain_register(&test_notifier_list, &test1);
          atomic_notifier_chain_register(&test_notifier_list, &test2);

  case2: An infinite loop in notifier_chain_register() can cause soft lockup
          atomic_notifier_chain_register(&test_notifier_list, &test1);
          atomic_notifier_chain_register(&test_notifier_list, &test1);
          atomic_notifier_call_chain(&test_notifier_list, 0, NULL);

  case3: lose other hook test2
          atomic_notifier_chain_register(&test_notifier_list, &test1);
          atomic_notifier_chain_register(&test_notifier_list, &test2);
          atomic_notifier_chain_register(&test_notifier_list, &test1);

  case4: Unregister returns 0, but the hook is still in the linked list,
         and it is not really registered. If you call
         notifier_call_chain after ko is unloaded, it will trigger oops.

If the system is configured with softlockup_panic and the same hook is
repeatedly registered on the panic_notifier_list, it will cause a loop
panic.

Add a check in notifier_chain_register(), intercepting duplicate
registrations to avoid infinite loops

Link: http://lkml.kernel.org/r/1568861888-34045-2-git-send-email-nixiaoming@huawei.com
Signed-off-by: Xiaoming Ni 
Reviewed-by: Vasily Averin 
Reviewed-by: Andrew Morton 
Cc: Alexey Dobriyan 
Cc: Anna Schumaker 
Cc: Arjan van de Ven 
Cc: J. Bruce Fields 
Cc: Chuck Lever 
Cc: David S. Miller 
Cc: Jeff Layton 
Cc: Andy Lutomirski 
Cc: Ingo Molnar 
Cc: Nadia Derbey 
Cc: "Paul E. McKenney" 
Cc: Sam Protsenko 
Cc: Alan Stern 
Cc: Thomas Gleixner 
Cc: Trond Myklebust 
Cc: Viresh Kumar 
Cc: Xiaoming Ni 
Cc: YueHaibing 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds