15 Jan, 2021
1 commit
-
Casting the comparison function to a different type trips indirect call
Control-Flow Integrity (CFI) checking. Remove the additional consts from
cmp_func, and the now unneeded casts.Bug: 145210207
Change-Id: Iffe0eeec8e7f65a5937513a4bb87e5107faa004e
Link: https://lore.kernel.org/lkml/20200110225602.91663-1-samitolvanen@google.com/
Fixes: 043b3f7b6388 ("lib/list_sort: simplify and remove MAX_LIST_LENGTH_BITS")
Signed-off-by: Sami Tolvanen
17 Jul, 2020
1 commit
-
This reverts commit 9b177a7d1cea8d43ddec29c85dc997548c1b9dcc as CFI is
being removed from the tree to come back later as a "clean" set of
patches.Bug: 147506196
Cc: Sami Tolvanen
Cc: Todd Kjos
Signed-off-by: Greg Kroah-Hartman
Change-Id: Ie9d1c57c4b1e493aaf1f4654a188c830a414d97f
16 Jan, 2020
1 commit
-
Casting the comparison function to a different type trips indirect call
Control-Flow Integrity (CFI) checking. Remove the additional consts from
cmp_func, and the now unneeded casts.Fixes: 043b3f7b6388 ("lib/list_sort: simplify and remove MAX_LIST_LENGTH_BITS")
(am from https://lore.kernel.org/patchwork/patch/1178059/)
Link: https://lore.kernel.org/lkml/20200110225602.91663-1-samitolvanen@google.com
Bug: 147506196
Change-Id: I329b1a454c30af78f9851db6a38c3f060499ec0d
Signed-off-by: Sami Tolvanen
Signed-off-by: Todd Kjos
21 Jun, 2019
1 commit
-
In order for a list to be recognized as such, blank lines
are required.Solve those Sphinx warnings:
./lib/list_sort.c:162: WARNING: Unexpected indentation.
./lib/list_sort.c:163: WARNING: Block quote ends without a blank line; unexpected unindent.Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Jonathan Corbet
23 May, 2019
1 commit
-
Commit 043b3f7b6388 ("lib/list_sort: simplify and remove
MAX_LIST_LENGTH_BITS") added some useful kerneldoc info, but also broke the
docs build:./lib/list_sort.c:128: WARNING: Definition list ends without a blank line; unexpected unindent.
./lib/list_sort.c:161: WARNING: Unexpected indentation.
./lib/list_sort.c:162: WARNING: Block quote ends without a blank line; unexpected unindent.Fix the offending literal block and make the error go away.
Fixes: 043b3f7b6388 ("lib/list_sort: simplify and remove MAX_LIST_LENGTH_BITS")
Cc: George Spelvin
Signed-off-by: Jonathan Corbet
15 May, 2019
2 commits
-
CONFIG_RETPOLINE has severely degraded indirect function call
performance, so it's worth putting some effort into reducing the number
of times cmp() is called.This patch avoids badly unbalanced merges on unlucky input sizes. It
slightly increases the code size, but saves an average of 0.2*n calls to
cmp().x86-64 code size 739 -> 803 bytes (+64)
Unfortunately, there's not a lot of low-hanging fruit in a merge sort;
it already performs only n*log2(n) - K*n + O(1) compares. The leading
coefficient is already at the theoretical limit (log2(n!) corresponds to
K=1.4427), so we're fighting over the linear term, and the best
mergesort can do is K=1.2645, achieved when n is a power of 2.The differences between mergesort variants appear when n is *not* a
power of 2; K is a function of the fractional part of log2(n). Top-down
mergesort does best of all, achieving a minimum K=1.2408, and an average
(over all sizes) K=1.248. However, that requires knowing the number of
entries to be sorted ahead of time, and making a full pass over the
input to count it conflicts with a second performance goal, which is
cache blocking.Obviously, we have to read the entire list into L1 cache at some point,
and performance is best if it fits. But if it doesn't fit, each full
pass over the input causes a cache miss per element, which is
undesirable.While textbooks explain bottom-up mergesort as a succession of merging
passes, practical implementations do merging in depth-first order: as
soon as two lists of the same size are available, they are merged. This
allows as many merge passes as possible to fit into L1; only the final
few merges force cache misses.This cache-friendly depth-first merge order depends on us merging the
beginning of the input as much as possible before we've even seen the
end of the input (and thus know its size).The simple eager merge pattern causes bad performance when n is just
over a power of 2. If n=1028, the final merge is between 1024- and
4-element lists, which is wasteful of comparisons. (This is actually
worse on average than n=1025, because a 1204:1 merge will, on average,
end after 512 compares, while 1024:4 will walk 4/5 of the list.)Because of this, bottom-up mergesort achieves K < 0.5 for such sizes,
and has an average (over all sizes) K of around 1. (My experiments show
K=1.01, while theory predicts K=0.965.)There are "worst-case optimal" variants of bottom-up mergesort which
avoid this bad performance, but the algorithms given in the literature,
such as queue-mergesort and boustrodephonic mergesort, depend on the
breadth-first multi-pass structure that we are trying to avoid.This implementation is as eager as possible while ensuring that all
merge passes are at worst 1:2 unbalanced. This achieves the same
average K=1.207 as queue-mergesort, which is 0.2*n better then
bottom-up, and only 0.04*n behind top-down mergesort.Specifically, defers merging two lists of size 2^k until it is known
that there are 2^k additional inputs following. This ensures that the
final uneven merges triggered by reaching the end of the input will be
at worst 2:1. This will avoid cache misses as long as 3*2^k elements
fit into the cache.(I confess to being more than a little bit proud of how clean this code
turned out. It took a lot of thinking, but the resultant inner loop is
very simple and efficient.)Refs:
Bottom-up Mergesort: A Detailed Analysis
Wolfgang Panny, Helmut Prodinger
Algorithmica 14(4):340--354, October 1995
https://doi.org/10.1007/BF01294131
https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.6.5260The cost distribution of queue-mergesort, optimal mergesorts, and
power-of-two rules
Wei-Mei Chen, Hsien-Kuei Hwang, Gen-Huey Chen
Journal of Algorithms 30(2); Pages 423--448, February 1999
https://doi.org/10.1006/jagm.1998.0986
https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.4.5380Queue-Mergesort
Mordecai J. Golin, Robert Sedgewick
Information Processing Letters, 48(5):253--259, 10 December 1993
https://doi.org/10.1016/0020-0190(93)90088-q
https://sci-hub.tw/10.1016/0020-0190(93)90088-QFeedback from Rasmus Villemoes .
Link: http://lkml.kernel.org/r/fd560853cc4dca0d0f02184ffa888b4c1be89abc.1552704200.git.lkml@sdf.org
Signed-off-by: George Spelvin
Acked-by: Andrey Abramov
Acked-by: Rasmus Villemoes
Reviewed-by: Andy Shevchenko
Cc: Daniel Wagner
Cc: Dave Chinner
Cc: Don Mullis
Cc: Geert Uytterhoeven
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Rather than a fixed-size array of pending sorted runs, use the ->prev
links to keep track of things. This reduces stack usage, eliminates
some ugly overflow handling, and reduces the code size.Also:
* merge() no longer needs to handle NULL inputs, so simplify.
* The same applies to merge_and_restore_back_links(), which is renamed
to the less ponderous merge_final(). (It's a static helper function,
so we don't need a super-descriptive name; comments will do.)
* Document the actual return value requirements on the (*cmp)()
function; some callers are already using this feature.x86-64 code size 1086 -> 739 bytes (-347)
(Yes, I see checkpatch complaining about no space after comma in
"__attribute__((nonnull(2,3,4,5)))". Checkpatch is wrong.)Feedback from Rasmus Villemoes, Andy Shevchenko and Geert Uytterhoeven.
[akpm@linux-foundation.org: remove __pure usage due to mysterious warning]
Link: http://lkml.kernel.org/r/f63c410e0ff76009c9b58e01027e751ff7fdb749.1552704200.git.lkml@sdf.org
Signed-off-by: George Spelvin
Acked-by: Andrey Abramov
Acked-by: Rasmus Villemoes
Reviewed-by: Andy Shevchenko
Cc: Geert Uytterhoeven
Cc: Daniel Wagner
Cc: Dave Chinner
Cc: Don Mullis
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
02 Nov, 2017
1 commit
-
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
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
09 May, 2017
1 commit
-
Extract the linked list sorting test code into its own source file, to
allow to compile it either to a loadable module, or builtin into the
kernel.Link: http://lkml.kernel.org/r/1488287219-15832-4-git-send-email-geert@linux-m68k.org
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Andy Shevchenko
Cc: Arnd Bergmann
Cc: Paul Gortmaker
Cc: Shuah Khan
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Jun, 2015
1 commit
-
This was using module_init, but there is no way this code can
be modular. In the non-modular case, a module_init becomes a
device_initcall, but this really isn't a device. So we should
choose a more appropriate initcall bucket to put it in.Assuming boot time self tests need to be observed over a console
to be useful, and that the console device could possibly not be
fully functional until after device_initcall, we move this to the
late_initcall bucket, which is immediately after device_initcall.Cc: Andrew Morton
Signed-off-by: Paul Gortmaker
13 Feb, 2015
1 commit
-
Memory allocation only happens in the self test, just as random numbers
are only used there. So move the inclusion of slab.h inside the
CONFIG_TEST_LIST_SORT.We don't need module.h and all of the stuff it carries with it, so replace
with export.h and compiler.h. Unfortunately, the ARRAY_SIZE macro from
kernel.h requires the user to ensure bug.h is also included (for
BUILD_BUG_ON_ZERO, used by __must_be_array). We used to get that through
some maze of nested includes, but just include it explicitly.linux/string.h is then only included implicitly through
kernel.h->printk.h->dynamic_debug.h, but only if !CONFIG_DYNAMIC_DEBUG, so
just include it explicitly (for memset).objdump -d says the generated code is the same, and wc -l says that
lib/.list_sort.o.cmd went from 579 to 165 lines.Signed-off-by: Rasmus Villemoes
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Aug, 2014
5 commits
-
Cc: Rasmus Villemoes
Cc: Artem Bityutskiy
Cc: Don Mullis
Cc: Dave Chinner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The helper merge_and_restore_back_links() makes sure to call the
caller's cmp function during the final ->prev pointer fixup, so that the
cmp function may call cond_resched(). However, if the cmp function does
not call cond_resched() at all, this is entirely redundant. If it does,
doing at least two function calls for every two pointer assignments is a
bit excessive. This patch limits the calls to once for every 256
iterations.Signed-off-by: Rasmus Villemoes
Cc: Artem Bityutskiy
Cc: Don Mullis
Cc: Dave Chinner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
There is no reason to maintain the list structure while freeing the
debug elements. Aside from the redundant pointer manipulations, it is
also inefficient from a locality-of-reference viewpoint, since they are
visited in a random order (wrt. the order they were allocated).
Furthermore, if we jumped to exit: after detecting list corruption, it
is actually dangerous.So just free the elements in the order they were allocated, using the
backing array elts. Allocate that using kcalloc(), so that if
allocation of one of the debug element fails, we just end up calling
kfree(NULL) for the trailing elements.Minor details: Use sizeof(*elts) instead of sizeof(void *), and return
err immediately when allocation of elts fails, to avoid introducing
another label just before the final return statement.Signed-off-by: Rasmus Villemoes
Cc: Artem Bityutskiy
Cc: Don Mullis
Cc: Dave Chinner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Add a check to make sure that the prev pointer of the list head points
to the last element on the list.Signed-off-by: Rasmus Villemoes
Cc: Artem Bityutskiy
Cc: Don Mullis
Cc: Dave Chinner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Signed-off-by: Rasmus Villemoes
Cc: Artem Bityutskiy
Cc: Don Mullis
Cc: Dave Chinner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Apr, 2013
1 commit
-
Use preferable function name which implies using a pseudo-random
number generator.Signed-off-by: Akinobu Mita
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
27 Oct, 2010
6 commits
-
Improve 'lib_sort()' test and check that:
o 'cmp()' is called only for elements which were present in the original list,
i.e., the 'a' and 'b' parameters are valid
o the resulted (sorted) list consists onlly of the original elements
o intdoruce "poison" fields to make sure data around 'struc list_head' field
are not corrupted.Signed-off-by: Artem Bityutskiy
Cc: Don Mullis
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This patch unifies 'list_sort_test()' messages a bit and makes sure all of
them start with the "list_sort_test:" prefix to make it obvious for users
where the messages come from.Signed-off-by: Artem Bityutskiy
Cc: Don Mullis
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The 'lib_sort()' test does not free memory if it fails, and it makes the
kernel panic if it cannot allocate memory. This patch fixes the problem.This patch also changes several small things:
o use 'list_add()' helper instead of adding manually
o introduce temporary 'el1' variable to avoid ugly and unreadalbe
"if" statement
o make 'head' to be stack variable instead of 'kmalloc()'ed, which
simplifies code a bitOverall, this patch is of clean-up type.
Signed-off-by: Artem Bityutskiy
Cc: Don Mullis
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Instead of using own pseudo-random generator, use generic linux
'random32()' function. Presumably, this should improve test coverage.At the same time, do the following changes:
o Use shorter macro name for test list length
o Do not use strange 'l_h' name for 'struct list_head' element,
use 'list', because it is traditional name and thus, makes the
code more obvious and readable.Signed-off-by: Artem Bityutskiy
Cc: Don Mullis
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
I do not see any reason to use KERN_WARN for normal messages and
KERN_EMERG for error messages in the lib_sort testing routine. Let's use
more reasonable KERN_NORM and KERN_ERR levels.Signed-off-by: Artem Bityutskiy
Cc: Don Mullis
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
While hunting a non-existing bug in 'list_sort()', I've improved the
'list_sort_test()' function which tests the 'list_sort()' library call.
Although at the end I found a bug in my code, but not in 'list_sort()', I
think my clean-ups and improvements are worth merging because they make
the test function better.This patch:
Make the self-tests selectable via Kconfig rather than by manual enabling
of DEBUG_LIST_SORT.Signed-off-by: Artem Bityutskiy
Cc: Don Mullis
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
02 Oct, 2010
1 commit
-
If the original list is a POT in length, the first callback from line 73
will pass a==b both pointing to the original list_head. This is dangerous
because the 'list_sort()' user can use 'container_of()' and accesses the
"containing" object, which does not necessary exist for the list head. So
the user can access RAM which does not belong to him. If this is a write
access, we can end up with memory corruption.Signed-off-by: Don Mullis
Tested-by: Artem Bityutskiy
Signed-off-by: Artem Bityutskiy
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Mar, 2010
2 commits
-
Clarify and correct header comment of list_sort().
Signed-off-by: Don Mullis
Cc: Dave Airlie
Cc: Andi Kleen
Cc: Dave Chinner
Cc: Artem Bityutskiy
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
XFS and UBIFS can pass long lists to list_sort(); this alternative
implementation scales better, reaching ~3x performance gain when list
length exceeds the L2 cache size.Stand-alone program timings were run on a Core 2 duo L1=32KB L2=4MB,
gcc-4.4, with flags extracted from an Ubuntu kernel build. Object size is
581 bytes compared to 455 for Mark J. Roberts' code.Worst case for either implementation is a list length just over a power of
two, and to roughly the same degree, so here are timing results for a
range of 2^N+1 lengths. List elements were 16 bytes each including malloc
overhead; initial order was random.time (msec)
Tatham-Roberts
| generic-Mullis-v2
loop_count length | | ratio
4000000 2 206 294 1.427
2000000 3 176 227 1.289
1000000 5 199 172 0.864
500000 9 235 178 0.757
250000 17 243 182 0.748
125000 33 261 196 0.750
62500 65 277 209 0.754
31250 129 292 219 0.75
15625 257 317 235 0.741
7812 513 340 252 0.741
3906 1025 362 267 0.737
1953 2049 388 283 0.729 ~ L1 size
976 4097 556 323 0.580
488 8193 678 361 0.532
244 16385 773 395 0.510
122 32769 844 418 0.495
61 65537 917 454 0.495
30 131073 1128 543 0.481
15 262145 2355 869 0.369 ~ L2 size
7 524289 5597 1714 0.306
3 1048577 6218 2022 0.325Mark's code does not actually implement the usual or generic mergesort,
but rather a variant from Simon Tatham described here:http://www.chiark.greenend.org.uk/~sgtatham/algorithms/listsort.html
Simon's algorithm performs O(log N) passes over the entire input list,
doing merges of sublists that double in size on each pass. The generic
algorithm instead merges pairs of equal length lists as early as possible,
in recursive order. For either algorithm, the elements that extend the
list beyond power-of-two length are a special case, handled as nearly as
possible as a "rounding-up" to a full POT.Some intuition for the locality of reference implications of merge order
may be gotten by watching this animation:http://www.sorting-algorithms.com/merge-sort
Simon's algorithm requires only O(1) extra space rather than the generic
algorithm's O(log N), but in my non-recursive implementation the actual
O(log N) data is merely a vector of ~20 pointers, which I've put on the
stack.Long-running list_sort() calls: If the list passed in may be long, or the
client's cmp() callback function is slow, the client's cmp() may
periodically invoke cond_resched() to voluntarily yield the CPU. All
inner loops of list_sort() call back to cmp().Stability of the sort: distinct elements that compare equal emerge from
the sort in the same order as with Mark's code, for simple test cases. A
boot-time test is provided to verify this and other correctness
requirements.A kernel that uses drm.ko appears to run normally with this change; I have
no suitable hardware to similarly test the use by UBIFS.[akpm@linux-foundation.org: style tweaks, fix comment, make list_sort_test __init]
Signed-off-by: Don Mullis
Cc: Dave Airlie
Cc: Andi Kleen
Cc: Dave Chinner
Cc: Artem Bityutskiy
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Jan, 2010
1 commit
-
There are two copies of list_sort() in the tree already, one in the DRM
code, another in ubifs. Now XFS needs this as well. Create a generic
list_sort() function from the ubifs version and convert existing users
to it so we don't end up with yet another copy in the tree.Signed-off-by: Dave Chinner
Acked-by: Dave Airlie
Acked-by: Artem Bityutskiy
Signed-off-by: Linus Torvalds
