19 May, 2021

1 commit

  • The existing code attempted to handle numbers by doing a strto[u]l(),
    ignoring the field width, and then repeatedly dividing to extract the
    field out of the full converted value. If the string contains a run of
    valid digits longer than will fit in a long or long long, this would
    overflow and no amount of dividing can recover the correct value.

    This patch fixes vsscanf() to obey number field widths when parsing
    the number.

    A new _parse_integer_limit() is added that takes a limit for the number
    of characters to parse. The number field conversion in vsscanf is changed
    to use this new function.

    If a number starts with a radix prefix, the field width must be long
    enough for at last one digit after the prefix. If not, it will be handled
    like this:

    sscanf("0x4", "%1i", &i): i=0, scanning continues with the 'x'
    sscanf("0x4", "%2i", &i): i=0, scanning continues with the '4'

    This is consistent with the observed behaviour of userland sscanf.

    Note that this patch does NOT fix the problem of a single field value
    overflowing the target type. So for example:

    sscanf("123456789abcdef", "%x", &i);

    Will not produce the correct result because the value obviously overflows
    INT_MAX. But sscanf will report a successful conversion.

    Note that where a very large number is used to mean "unlimited", the value
    INT_MAX is used for consistency with the behaviour of vsnprintf().

    Signed-off-by: Richard Fitzgerald
    Reviewed-by: Petr Mladek
    Signed-off-by: Petr Mladek
    Link: https://lore.kernel.org/r/20210514161206.30821-2-rf@opensource.cirrus.com

    Richard Fitzgerald
     

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

    Greg Kroah-Hartman
     

01 Nov, 2011

1 commit

  • Currently termination logic (\0 or \n\0) is hardcoded in _kstrtoull(),
    avoid that for code reuse between kstrto*() and simple_strtoull().
    Essentially, make them different only in termination logic.

    simple_strtoull() (and scanf(), BTW) ignores integer overflow, that's a
    bug we currently don't have guts to fix, making KSTRTOX_OVERFLOW hack
    necessary.

    Almost forgot: patch shrinks code size by about ~80 bytes on x86_64.

    Signed-off-by: Alexey Dobriyan
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan