linux-toradex.git/kernel/notifier.c, branch v5.17-rc4

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

treewide: Add SPDX license identifier for missed files

2019-05-21T08:50:45+00:00

Add SPDX license identifiers to all files which:

 - Have no license information of any form

 - Have EXPORT_.*_SYMBOL_GPL inside which was used in the
   initial scan/conversion to ignore the file

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

  GPL-2.0-only

Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

kernel/notifier.c: double register detection

2019-05-15T02:52:49+00:00

By design notifiers can be registerd once only, 2nd register attempt
called by mistake silently corrupts notifiers list.

A few years ago I investigated described problem, the host was power
cycled because of notifier list corruption.  I've prepared this patch
and applied it to the OpenVZ kernel and sent this patch but nobody
commented on it.  Later it helped us to detect a similar problem in the
OpenVz kernel.

Mistakes with notifier registration can happen for example during
subsystem initialization from different namespaces, or because of a lost
unregister in the roll-back path on initialization failures.

The proposed check cannot prevent the described problem, however it
allows us to detect its reason quickly without coredump analysis.

Link: http://lkml.kernel.org/r/04127e71-4782-9bbb-fe5a-7c01e93a99b0@virtuozzo.com
Signed-off-by: Vasily Averin 
Reviewed-by: Andrew Morton 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds