30 Sep, 2020

1 commit


17 Jul, 2019

1 commit

  • Due to some sad limitations in how kerneldoc comments are parsed, the
    documentation in lib/string_helpers.c generates these warnings:

    lib/string_helpers.c:236: WARNING: Unexpected indentation.
    lib/string_helpers.c:241: WARNING: Block quote ends without a blank line; unexpected unindent.
    lib/string_helpers.c:446: WARNING: Unexpected indentation.
    lib/string_helpers.c:451: WARNING: Block quote ends without a blank line; unexpected unindent.
    lib/string_helpers.c:474: WARNING: Unexpected indentation.

    Rework the comments to obtain something like the desired result.

    Link: http://lkml.kernel.org/r/20190607110952.409011ba@lwn.net
    Signed-off-by: Jonathan Corbet
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jonathan Corbet
     

04 Jul, 2019

1 commit

  • I'm exposing some information about NFS clients in pseudofiles. I
    expect to eventually have simple tools to help read those pseudofiles.

    But it's also helpful if the raw files are human-readable to the extent
    possible. It aids debugging and makes them usable on systems that don't
    have the latest nfs-utils.

    A minor challenge there is opaque client-generated protocol objects like
    state owners and client identifiers. Some clients generate those to
    include handy information in plain ascii. But they may also include
    arbitrary byte sequences.

    I think the simplest approach is to limit to isprint(c) && isascii(c)
    and escape everything else.

    That means you can just cat the file and get something that looks OK.
    Also, I'm trying to keep these files legal YAML, which requires them to
    UTF-8, and this is a simple way to guarantee that.

    Acked-by: Kees Cook
    Signed-off-by: J. Bruce Fields

    J. Bruce Fields
     

21 May, 2019

1 commit

  • 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

    Thomas Gleixner
     

14 Sep, 2017

1 commit

  • GFP_TEMPORARY was introduced by commit e12ba74d8ff3 ("Group short-lived
    and reclaimable kernel allocations") along with __GFP_RECLAIMABLE. It's
    primary motivation was to allow users to tell that an allocation is
    short lived and so the allocator can try to place such allocations close
    together and prevent long term fragmentation. As much as this sounds
    like a reasonable semantic it becomes much less clear when to use the
    highlevel GFP_TEMPORARY allocation flag. How long is temporary? Can the
    context holding that memory sleep? Can it take locks? It seems there is
    no good answer for those questions.

    The current implementation of GFP_TEMPORARY is basically GFP_KERNEL |
    __GFP_RECLAIMABLE which in itself is tricky because basically none of
    the existing caller provide a way to reclaim the allocated memory. So
    this is rather misleading and hard to evaluate for any benefits.

    I have checked some random users and none of them has added the flag
    with a specific justification. I suspect most of them just copied from
    other existing users and others just thought it might be a good idea to
    use without any measuring. This suggests that GFP_TEMPORARY just
    motivates for cargo cult usage without any reasoning.

    I believe that our gfp flags are quite complex already and especially
    those with highlevel semantic should be clearly defined to prevent from
    confusion and abuse. Therefore I propose dropping GFP_TEMPORARY and
    replace all existing users to simply use GFP_KERNEL. Please note that
    SLAB users with shrinkers will still get __GFP_RECLAIMABLE heuristic and
    so they will be placed properly for memory fragmentation prevention.

    I can see reasons we might want some gfp flag to reflect shorterm
    allocations but I propose starting from a clear semantic definition and
    only then add users with proper justification.

    This was been brought up before LSF this year by Matthew [1] and it
    turned out that GFP_TEMPORARY really doesn't have a clear semantic. It
    seems to be a heuristic without any measured advantage for most (if not
    all) its current users. The follow up discussion has revealed that
    opinions on what might be temporary allocation differ a lot between
    developers. So rather than trying to tweak existing users into a
    semantic which they haven't expected I propose to simply remove the flag
    and start from scratch if we really need a semantic for short term
    allocations.

    [1] http://lkml.kernel.org/r/20170118054945.GD18349@bombadil.infradead.org

    [akpm@linux-foundation.org: fix typo]
    [akpm@linux-foundation.org: coding-style fixes]
    [sfr@canb.auug.org.au: drm/i915: fix up]
    Link: http://lkml.kernel.org/r/20170816144703.378d4f4d@canb.auug.org.au
    Link: http://lkml.kernel.org/r/20170728091904.14627-1-mhocko@kernel.org
    Signed-off-by: Michal Hocko
    Signed-off-by: Stephen Rothwell
    Acked-by: Mel Gorman
    Acked-by: Vlastimil Babka
    Cc: Matthew Wilcox
    Cc: Neil Brown
    Cc: "Theodore Ts'o"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michal Hocko
     

21 Apr, 2016

3 commits


21 Jan, 2016

1 commit

  • It was noticed that we lose precision in the final calculation for some
    inputs. The most egregious example is size=3000 blk_size=1900 in units
    of 10 should yield 5.70 MB but in fact yields 3.00 MB (oops).

    This is because the current algorithm doesn't correctly account for
    all the remainders in the logarithms. Fix this by doing a correct
    calculation in the remainders based on napier's algorithm.

    Additionally, now we have the correct result, we have to account for
    arithmetic rounding because we're printing 3 digits of precision. This
    means that if the fourth digit is five or greater, we have to round up,
    so add a section to ensure correct rounding. Finally account for all
    possible inputs correctly, including zero for block size.

    Fixes: b9f28d863594c429e1df35a0474d2663ca28b307
    Signed-off-by: James Bottomley
    Reported-by: Vitaly Kuznetsov
    Cc: [delay until after 4.4 release]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    James Bottomley
     

18 Sep, 2015

1 commit

  • Some string_get_size() calls (e.g.:
    string_get_size(1, 512, STRING_UNITS_10, ..., ...)
    string_get_size(15, 64, STRING_UNITS_10, ..., ...)
    ) result in an infinite loop. The problem is that if size is equal to
    divisor[units]/blk_size and is smaller than divisor[units] we'll end
    up with size == 0 when we start doing sf_cap calculations:

    For string_get_size(1, 512, STRING_UNITS_10, ..., ...) case:
    ...
    remainder = do_div(size, divisor[units]); -> size is 0, remainder is 1
    remainder *= blk_size; -> remainder is 512
    ...
    size *= blk_size; -> size is still 0
    size += remainder / divisor[units]; -> size is still 0

    The caller causing the issue is sd_read_capacity(), the problem was
    noticed on Hyper-V, such weird size was reported by host when scanning
    collides with device removal. This is probably a separate issue worth
    fixing, this patch is intended to prevent the library routine from
    infinite looping.

    Signed-off-by: Vitaly Kuznetsov
    Acked-by: James Bottomley
    Cc: Andy Shevchenko
    Cc: Rasmus Villemoes
    Cc: "K. Y. Srinivasan"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vitaly Kuznetsov
     

11 Sep, 2015

2 commits

  • To further clarify the purpose of the "esc" argument, rename it to "only"
    to reflect that it is a limit, not a list of additional characters to
    escape.

    Signed-off-by: Kees Cook
    Suggested-by: Rasmus Villemoes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kees Cook
     
  • The esc argument is used to reduce which characters will be escaped. For
    example, using " " with ESCAPE_SPACE will not produce any escaped spaces.

    Signed-off-by: Kees Cook
    Cc: Andy Shevchenko
    Cc: Rasmus Villemoes
    Cc: Mathias Krause
    Cc: James Bottomley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kees Cook
     

17 Apr, 2015

1 commit

  • Pull SCSI updates from James Bottomley:
    "This is the usual grab bag of driver updates (lpfc, qla2xxx, storvsc,
    aacraid, ipr) plus an assortment of minor updates. There's also a
    major update to aic1542 which moves the driver into this millenium"

    * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (106 commits)
    change SCSI Maintainer email
    sd, mmc, virtio_blk, string_helpers: fix block size units
    ufs: add support to allow non standard behaviours (quirks)
    ufs-qcom: save controller revision info in internal structure
    qla2xxx: Update driver version to 8.07.00.18-k
    qla2xxx: Restore physical port WWPN only, when port down detected for FA-WWPN port.
    qla2xxx: Fix virtual port configuration, when switch port is disabled/enabled.
    qla2xxx: Prevent multiple firmware dump collection for ISP27XX.
    qla2xxx: Disable Interrupt handshake for ISP27XX.
    qla2xxx: Add debugging info for MBX timeout.
    qla2xxx: Add serdes read/write support for ISP27XX
    qla2xxx: Add udev notification to save fw dump for ISP27XX
    qla2xxx: Add message for sucessful FW dump collected for ISP27XX.
    qla2xxx: Add support to load firmware from file for ISP 26XX/27XX.
    qla2xxx: Fix beacon blink for ISP27XX.
    qla2xxx: Increase the wait time for firmware to be ready for P3P.
    qla2xxx: Fix crash due to wrong casting of reg for ISP27XX.
    qla2xxx: Fix warnings reported by static checker.
    lpfc: Update version to 10.5.0.0 for upstream patch set
    lpfc: Update copyright to 2015
    ...

    Linus Torvalds
     

16 Apr, 2015

2 commits

  • The current semantics of string_escape_mem are inadequate for one of its
    current users, vsnprintf(). If that is to honour its contract, it must
    know how much space would be needed for the entire escaped buffer, and
    string_escape_mem provides no way of obtaining that (short of allocating a
    large enough buffer (~4 times input string) to let it play with, and
    that's definitely a big no-no inside vsnprintf).

    So change the semantics for string_escape_mem to be more snprintf-like:
    Return the size of the output that would be generated if the destination
    buffer was big enough, but of course still only write to the part of dst
    it is allowed to, and (contrary to snprintf) don't do '\0'-termination.
    It is then up to the caller to detect whether output was truncated and to
    append a '\0' if desired. Also, we must output partial escape sequences,
    otherwise a call such as snprintf(buf, 3, "%1pE", "\123") would cause
    printf to write a \0 to buf[2] but leaving buf[0] and buf[1] with whatever
    they previously contained.

    This also fixes a bug in the escaped_string() helper function, which used
    to unconditionally pass a length of "end-buf" to string_escape_mem();
    since the latter doesn't check osz for being insanely large, it would
    happily write to dst. For example, kasprintf(GFP_KERNEL, "something and
    then %pE", ...); is an easy way to trigger an oops.

    In test-string_helpers.c, the -ENOMEM test is replaced with testing for
    getting the expected return value even if the buffer is too small. We
    also ensure that nothing is written (by relying on a NULL pointer deref)
    if the output size is 0 by passing NULL - this has to work for
    kasprintf("%pE") to work.

    In net/sunrpc/cache.c, I think qword_add still has the same semantics.
    Someone should definitely double-check this.

    In fs/proc/array.c, I made the minimum possible change, but longer-term it
    should stop poking around in seq_file internals.

    [andriy.shevchenko@linux.intel.com: simplify qword_add]
    [andriy.shevchenko@linux.intel.com: add missed curly braces]
    Signed-off-by: Rasmus Villemoes
    Acked-by: Andy Shevchenko
    Signed-off-by: Andy Shevchenko
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rasmus Villemoes
     
  • When printf is given the format specifier %pE, it needs a way of obtaining
    the total output size that would be generated if the buffer was large
    enough, and string_escape_mem doesn't easily provide that. This is a
    refactorization of string_escape_mem in preparation of changing its
    external API to provide that information.

    The somewhat ugly early returns and subsequent seemingly redundant
    conditionals are to make the following patch touch as little as possible
    in string_helpers.c while still preserving the current behaviour of never
    outputting partial escape sequences. That behaviour must also change for
    %pE to work as one expects from every other printf specifier.

    Signed-off-by: Rasmus Villemoes
    Acked-by: Andy Shevchenko
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rasmus Villemoes
     

11 Apr, 2015

1 commit

  • The current string_get_size() overflows when the device size goes over
    2^64 bytes because the string helper routine computes the suffix from
    the size in bytes. However, the entirety of Linux thinks in terms of
    blocks, not bytes, so this will artificially induce an overflow on very
    large devices. Fix this by making the function string_get_size() take
    blocks and the block size instead of bytes. This should allow us to
    keep working until the current SCSI standard overflows.

    Also fix virtio_blk and mmc (both of which were also artificially
    multiplying by the block size to pass a byte side to string_get_size()).

    The mathematics of this is pretty simple: we're taking a product of
    size in blocks (S) and block size (B) and trying to re-express this in
    exponential form: S*B = R*N^E (where N, the exponent is either 1000 or
    1024) and R < N. Mathematically, S = RS*N^ES and B=RB*N^EB, so if RS*RB
    < N it's easy to see that S*B = RS*RB*N^(ES+EB). However, if RS*BS > N,
    we can see that this can be re-expressed as RS*BS = R*N (where R =
    RS*BS/N < N) so the whole exponent becomes R*N^(ES+EB+1)

    [jejb: fix incorrect 32 bit do_div spotted by kbuild test robot ]
    Acked-by: Ulf Hansson
    Reviewed-by: Andrew Morton
    Signed-off-by: James Bottomley

    James Bottomley
     

13 Feb, 2015

3 commits

  • string_get_size() was documented to return an error, but in fact always
    returned 0. Since the output always fits in 9 bytes, just document that
    and let callers do what they do now: pass a small stack buffer and ignore
    the return value.

    Signed-off-by: Rasmus Villemoes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rasmus Villemoes
     
  • The remainder from do_div is always a u32, and after size has been reduced
    to be below 1000 (or 1024), it certainly fits in u32. So both remainder
    and sf_cap can be made u32s, the format specifiers can be simplified (%lld
    wasn't the right thing to use for _unsigned_ long long anyway), and we can
    replace a do_div with an ordinary 32/32 bit division.

    Signed-off-by: Rasmus Villemoes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rasmus Villemoes
     
  • While commit 3c9f3681d0b4 ("[SCSI] lib: add generic helper to print
    sizes rounded to the correct SI range") says that Z and Y are included
    in preparation for 128 bit computers, they just waste .text currently.
    If and when we get u128, string_get_size needs updating anyway (and ISO
    needs to come up with four more prefixes).

    Also there's no need to include and test for the NULL sentinel; once we
    reach "E" size is at most 18. [The test is also wrong; it should be
    units_str[units][i+1]; if we've reached NULL we're already doomed.]

    Signed-off-by: Rasmus Villemoes
    Cc: James Bottomley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rasmus Villemoes
     

14 Oct, 2014

2 commits

  • This is almost the opposite function to string_unescape(). Nevertheless
    it handles \0 and could be used for any byte buffer.

    The documentation is supplied together with the function prototype.

    The test cases covers most of the scenarios and would be expanded later
    on.

    [akpm@linux-foundation.org: avoid 1k stack consumption]
    Signed-off-by: Andy Shevchenko
    Cc: "John W . Linville"
    Cc: Johannes Berg
    Cc: Greg Kroah-Hartman
    Cc: Joe Perches
    Cc: Wu Fengguang
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andy Shevchenko
     
  • The introduced function string_escape_mem() is a kind of opposite to
    string_unescape. We have several users of such functionality each of
    them created custom implementation. The series contains clean up of
    test suite, adding new call, and switching few users to use it via %*pE
    specifier.

    Test suite covers all of existing and most of potential use cases.

    This patch (of 11):

    The documentation of API belongs to c-file. This patch moves it
    accordingly.

    There is no functional change.

    Signed-off-by: Andy Shevchenko
    Cc: "John W . Linville"
    Cc: Johannes Berg
    Cc: Greg Kroah-Hartman
    Cc: Joe Perches
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andy Shevchenko
     

07 Aug, 2014

1 commit

  • Complement commit 68aecfb97978 ("lib/string_helpers.c: make arrays
    static") by making the arrays const -- not only pointing to const
    strings. This moves them out of the data section to the r/o data
    section:

    text data bss dec hex filename
    1150 176 0 1326 52e lib/string_helpers.old.o
    1326 0 0 1326 52e lib/string_helpers.new.o

    Signed-off-by: Mathias Krause
    Cc: James Bottomley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mathias Krause
     

01 May, 2013

1 commit

  • There are several places in kernel where modules unescapes input to convert
    C-Style Escape Sequences into byte codes.

    The patch provides generic implementation of such approach. Test cases are
    also included into the patch.

    [akpm@linux-foundation.org: clarify comment]
    [akpm@linux-foundation.org: export get_random_int() to modules]
    Signed-off-by: Andy Shevchenko
    Cc: Samuel Thibault
    Cc: Greg Kroah-Hartman
    Cc: Jason Baron
    Cc: Alexander Viro
    Cc: William Hubbs
    Cc: Chris Brannon
    Cc: Kirk Reiser
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andy Shevchenko
     

30 May, 2012

1 commit

  • Moving these arrays into static storage shrinks the kernel a bit:

    text data bss dec hex filename
    723 112 64 899 383 lib/string_helpers.o
    516 272 64 852 354 lib/string_helpers.o

    Cc: James Bottomley
    Cc: "Aneesh Kumar K.V"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

08 Mar, 2012

1 commit


24 Oct, 2008

1 commit

  • We would hang forever when passing a zero to string_get_size().
    Furthermore, string_get_size() would produce decimals on a value small
    enough to be exact. Finally, a few formatting issues are inconsistent
    with standard SI style guidelines.

    - If the value is less than the divisor, skip the entire rounding
    step. This prints out all small values including zero as integers,
    without decimals.
    - Add a space between the value and the symbol for the unit,
    consistent with standard SI practice.
    - Lower case k in kB since we are talking about powers of 10.
    - Finally, change "int" to "unsigned int" in one place to shut up a
    gcc warning when compiling the code out-of-kernel for testing.

    Signed-off-by: H. Peter Anvin
    Signed-off-by: James Bottomley

    H. Peter Anvin
     

04 Oct, 2008

1 commit

  • This patch adds the ability to print sizes in either units of 10^3 (SI)
    or 2^10 (Binary) units. It rounds up to three significant figures and
    can be used for either memory or storage capacities.

    Oh, and I'm fully aware that 64 bits is only 16EiB ... the Zetta and
    Yotta units are added for future proofing against the day we have 128
    bit computers ...

    [fujita.tomonori@lab.ntt.co.jp: fix missed unsigned long long cast]
    Signed-off-by: James Bottomley

    James Bottomley