user/sven/linux.git/include/asm-generic/resource.h, branch v5.7

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

2017-11-02T10:10:55Z

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 <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

asm-generic: remove _STK_LIM_MAX

2014-05-14T23:32:09Z

_STK_LIM_MAX could be used to override the RLIMIT_STACK hard limit from an arch's include/uapi/asm-generic/resource.h file, but is no longer used since both parisc and metag removed the override. Therefore remove it entirely, setting the hard RLIMIT_STACK limit to RLIM_INFINITY directly in include/asm-generic/resource.h. Signed-off-by: James Hogan Cc: Arnd Bergmann Cc: linux-arch@vger.kernel.org Cc: Helge Deller Cc: John David Anglin

UAPI: (Scripted) Disintegrate include/asm-generic

2012-10-04T17:20:15Z

Signed-off-by: David Howells Acked-by: Arnd Bergmann Acked-by: Thomas Gleixner Acked-by: Michael Kerrisk Acked-by: Paul E. McKenney Acked-by: Dave Jones

ulimit: raise default hard ulimit on number of files to 4096

2011-05-25T15:39:43Z

Apps are increasingly using more than 1024 file descriptors. See discussion in several distro bug trackers, e.g. BugLink: http://bugs.launchpad.net/bugs/663090 https://issues.rpath.com/browse/RPL-2054 You don't want to raise the default soft limit, since that might break apps that use select(), but it's safe to raise the default hard limit; that way, apps that know they need lots of file descriptors can raise their soft limit without needing root, and without user intervention. Ubuntu is doing this with a kernel change because they have a policy of not changing kernel defaults in userland. While 4096 might not be enough for *all* apps, it seems to be plenty for the apps I've seen lately that are unhappy with 1024. Signed-off-by: Tim Gardner Cc: Dan Kegel Cc: Al Viro Cc: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

sched: SCHED_FIFO/SCHED_RR watchdog timer

2008-01-25T20:08:27Z

Introduce a new rlimit that allows the user to set a runtime timeout on real-time tasks their slice. Once this limit is exceeded the task will receive SIGXCPU. So it measures runtime since the last sleep. Input and ideas by Thomas Gleixner and Lennart Poettering. Signed-off-by: Peter Zijlstra CC: Lennart Poettering CC: Michael Kerrisk CC: Ulrich Drepper Signed-off-by: Ingo Molnar

sched: fix RLIMIT_CPU comment

2007-11-26T20:21:49Z

Devan Lippman noticed that the RLIMIT_CPU comment in resource.h is incorrect: the field is in seconds, not msecs. We used msecs in earlier versions of the patch but that got changed. Found-by: Devan Lippman Signed-off-by: Ingo Molnar

[PATCH] nice and rt-prio rlimits

2005-05-01T15:59:00Z

Add a pair of rlimits for allowing non-root tasks to raise nice and rt priorities. Defaults to traditional behavior. Originally written by Chris Wright. The patch implements a simple rlimit ceiling for the RT (and nice) priorities a task can set. The rlimit defaults to 0, meaning no change in behavior by default. A value of 50 means RT priority levels 1-50 are allowed. A value of 100 means all 99 privilege levels from 1 to 99 are allowed. CAP_SYS_NICE is blanket permission. (akpm: see http://www.uwsg.iu.edu/hypermail/linux/kernel/0503.1/1921.html for tips on integrating this with PAM). Signed-off-by: Matt Mackall Acked-by: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] set RLIMIT_SIGPENDING limit based on RLIMIT_NPROC

2005-03-08T02:18:29Z

While looking into the issues Jeremy had with the RLIMIT_SIGPENDING limit, it occurred to me that the normal setting of this limit is bizarrely low. The initial hard limit setting (MAX_SIGPENDING) was taken from the old max_queued_signals parameter, which was for the entire system in aggregate. But even as a per-user limit, the 1024 value is incongruously low for this. On my machine, RLIMIT_NPROC allows me 8192 processes, but only 1024 queued signals, i.e. fewer even than one pending signal in each process. (To me, this really puts in doubt the sensibility of using a per-user limit for this rather than a per-process one, i.e. counted in sighand_struct or signal_struct, which could have a much smaller reasonable value. I don't recall the rationale for making this new limit per-user in the first place.) This patch sets the default RLIMIT_SIGPENDING limit at boot time, using the calculation that decides the default RLIMIT_NPROC limit. This uses the same value for those two limits, which I think is still pretty conservative on the RLIMIT_SIGPENDING value. Signed-off-by: Roland McGrath Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] clean up and unify asm-*/resource.h files

2005-03-08T01:53:09Z

This patch does the final consolidation of asm-*/resource.h file, without changing any of the rlimit definitions on any architecture. Primarily it removes the __ARCH_RLIMIT_ORDER method and replaces it with a more compact and isolated one that allows architectures to define only the offending rlimits. This method has the positive effect that adding a new rlimit can now be purely done via changing asm-generic/resource.h alone. Previously one would have to patch 4 other (sparc, sparc64, alpha and mips) resource.h files. The patch also does style unification, whitespace cleanups and simplification of resource.h files and cleans up the asm-generic/resource.h file as well. I've added more comments too. This patch should have no effect on any code on any architecture. (i.e. it's a pure identity patch.) Tested on x86 and carefully reviewed to make sure that Sparc, Sparc64, MIPS and Alpha rlimits are still the same as required by the ABI. Signed-off-by: Ingo Molnar Acked-by: Chris Wright Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] consolidate arch specific resource.h headers

2005-01-21T00:07:25Z

Most of the include/asm-*/resource.h headers are the same as one another. This patch makes one generic version, include/asm-generic/resource.h, and uses that when appropriate. The only vaguely interesting things here are that the generic version introduces a new _STK_LIM_MAX macro, which can be populated by an arch (ia64 and parisc needed that). Also, some arches hid RLIM_INFINITY under __KERNEL__, while others did not. The generic version does not, so the following arches will see that change: arm, arm26, mips, ppc, ppc64, sh (and hence sh64) And, finally, some arches maintain their own order for the resource numbers. This is now marked by __ARCH_RLIMIT_ORDER, and is used by the following arches: alpha, mips, sparc, and sparc64. This actually uncovered a mips bug (fix already sent, this patch is relative to that fix), where the default RLIMIT_MEMLOCK was set to RLIM_INFINITY and RLIMIT_NPROC set to MLOCK_LIMIT (the latter is no big deal because RLIMIT_NPROC default is overwritten dynamically during bootup in fork_init()). Also, this change makes alpha's default for RLIMIT_NPROC change from RLIM_INFINITY to 0, but again...no problem as it's dynamically overwritten during bootup. The following arches are left untouched: m68knommu: untouched (uses m68k/resource.h) sh64: untouched (uses asm-sh/resource.h) um: untouched (uses arch code already) Signed-off-by: Chris Wright Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds