25 Oct, 2014

1 commit


17 Oct, 2014

1 commit

  • zatimend has reported that in his environment (3.16/gcc4.8.3/corei7)
    memset() calls which clear out sensitive data in extract_{buf,entropy,
    entropy_user}() in random driver are being optimized away by gcc.

    Add a helper memzero_explicit() (similarly as explicit_bzero() variants)
    that can be used in such cases where a variable with sensitive data is
    being cleared out in the end. Other use cases might also be in crypto
    code. [ I have put this into lib/string.c though, as it's always built-in
    and doesn't need any dependencies then. ]

    Fixes kernel bugzilla: 82041

    Reported-by: zatimend@hotmail.co.uk
    Signed-off-by: Daniel Borkmann
    Acked-by: Hannes Frederic Sowa
    Cc: Alexey Dobriyan
    Signed-off-by: Theodore Ts'o
    Cc: stable@vger.kernel.org

    Daniel Borkmann
     

14 Oct, 2014

2 commits

  • The previous patch made strnicmp into a wrapper for strncasecmp.

    This patch makes all in-tree users of strnicmp call strncasecmp
    directly, while still making sure that the strnicmp symbol can be used
    by out-of-tree modules. It should be considered a temporary hack until
    all in-tree callers have been converted.

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

    Rasmus Villemoes
     
  • lib/string.c contains two functions, strnicmp and strncasecmp, which do
    roughly the same thing, namely compare two strings case-insensitively up
    to a given bound. They have slightly different implementations, but the
    only important difference is that strncasecmp doesn't handle len==0
    appropriately; it effectively becomes strcasecmp in that case. strnicmp
    correctly says that two strings are always equal in their first 0
    characters.

    strncasecmp is the POSIX name for this functionality. So rename the
    non-broken function to the standard name. To minimize the impact on the
    rest of the kernel (and since both are exported to modules), make strnicmp
    a wrapper for strncasecmp.

    Signed-off-by: Rasmus Villemoes
    Cc: Grant Likely
    Cc: Andi Kleen
    Cc: Dan Carpenter
    Cc: "H. Peter Anvin"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rasmus Villemoes
     

14 Sep, 2014

1 commit

  • It used to be an ad-hoc hack defined by the x86 version of
    that enabled a couple of library routines to know whether
    an integer multiply is faster than repeated shifts and additions.

    This just makes it use the real Kconfig system instead, and makes x86
    (which was the only architecture that did this) select the option.

    NOTE! Even for x86, this really is kind of wrong. If we cared, we would
    probably not enable this for builds optimized for netburst (P4), where
    shifts-and-adds are generally faster than multiplies. This patch does
    *not* change that kind of logic, though, it is purely a syntactic change
    with no code changes.

    This was triggered by the fact that we have other places that really
    want to know "do I want to expand multiples by constants by hand or
    not", particularly the hash generation code.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

05 Jun, 2014

1 commit

  • For strncpy() and friends the source string may or may not have an actual
    NUL character at the end. The documentation is confusing in this because
    it specifically mentions that you are passing a "NUL-terminated" string.
    Wikipedia says that "C-string" is an alternative name we can use instead.

    http://en.wikipedia.org/wiki/Null-terminated_string

    Signed-off-by: Dan Carpenter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dan Carpenter
     

23 May, 2014

1 commit

  • The strchrnul() variant helpfully returns a the end of the string
    instead of a NULL if the requested character is not found. This can
    simplify string parsing code since it doesn't need to expicitly check
    for a NULL return. If a valid string pointer is passed in, then a valid
    null terminated string will always come back out.

    Signed-off-by: Grant Likely

    Grant Likely
     

14 Feb, 2014

1 commit

  • In LTO symbols implicitely referenced by the compiler need
    to be visible. Earlier these symbols were visible implicitely
    from being exported, but we disabled implicit visibility fo
    EXPORTs when modules are disabled to improve code size. So
    now these symbols have to be marked visible explicitely.

    Do this for __stack_chk_fail (with stack protector)
    and memcmp.

    Signed-off-by: Andi Kleen
    Link: http://lkml.kernel.org/r/1391845930-28580-10-git-send-email-ak@linux.intel.com
    Signed-off-by: H. Peter Anvin

    Andi Kleen
     

25 Mar, 2012

2 commits

  • Pull cleanup of fs/ and lib/ users of module.h from Paul Gortmaker:
    "Fix up files in fs/ and lib/ dirs to only use module.h if they really
    need it.

    These are trivial in scope vs the work done previously. We now have
    things where any few remaining cleanups can be farmed out to arch or
    subsystem maintainers, and I have done so when possible. What is
    remaining here represents the bits that don't clearly lie within a
    single arch/subsystem boundary, like the fs dir and the lib dir.

    Some duplicate includes arising from overlapping fixes from
    independent subsystem maintainer submissions are also quashed."

    Fix up trivial conflicts due to clashes with other include file cleanups
    (including some due to the previous bug.h cleanup pull).

    * tag 'module-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
    lib: reduce the use of module.h wherever possible
    fs: reduce the use of module.h wherever possible
    includecheck: delete any duplicate instances of module.h

    Linus Torvalds
     
  • Pull cleanup from Paul Gortmaker:
    "The changes shown here are to unify linux's BUG support under the one
    file. Due to historical reasons, we have some BUG code
    in bug.h and some in kernel.h -- i.e. the support for BUILD_BUG in
    linux/kernel.h predates the addition of linux/bug.h, but old code in
    kernel.h wasn't moved to bug.h at that time. As a band-aid, kernel.h
    was including to pseudo link them.

    This has caused confusion[1] and general yuck/WTF[2] reactions. Here
    is an example that violates the principle of least surprise:

    CC lib/string.o
    lib/string.c: In function 'strlcat':
    lib/string.c:225:2: error: implicit declaration of function 'BUILD_BUG_ON'
    make[2]: *** [lib/string.o] Error 1
    $
    $ grep linux/bug.h lib/string.c
    #include
    $

    We've included for the BUG infrastructure and yet we
    still get a compile fail! [We've not kernel.h for BUILD_BUG_ON.] Ugh -
    very confusing for someone who is new to kernel development.

    With the above in mind, the goals of this changeset are:

    1) find and fix any include/*.h files that were relying on the
    implicit presence of BUG code.
    2) find and fix any C files that were consuming kernel.h and hence
    relying on implicitly getting some/all BUG code.
    3) Move the BUG related code living in kernel.h to
    4) remove the asm/bug.h from kernel.h to finally break the chain.

    During development, the order was more like 3-4, build-test, 1-2. But
    to ensure that git history for bisect doesn't get needless build
    failures introduced, the commits have been reorderd to fix the problem
    areas in advance.

    [1] https://lkml.org/lkml/2012/1/3/90
    [2] https://lkml.org/lkml/2012/1/17/414"

    Fix up conflicts (new radeon file, reiserfs header cleanups) as per Paul
    and linux-next.

    * tag 'bug-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
    kernel.h: doesn't explicitly use bug.h, so don't include it.
    bug: consolidate BUILD_BUG_ON with other bug code
    BUG: headers with BUG/BUG_ON etc. need linux/bug.h
    bug.h: add include of it to various implicit C users
    lib: fix implicit users of kernel.h for TAINT_WARN
    spinlock: macroize assert_spin_locked to avoid bug.h dependency
    x86: relocate get/set debugreg fcns to include/asm/debugreg.

    Linus Torvalds
     

24 Mar, 2012

1 commit

  • - Generate a 64-bit pattern more efficiently

    memchr_inv needs to generate a 64-bit pattern filled with a target
    character. The operation can be done by more efficient way.

    - Don't call the slow check_bytes() if the memory area is 64-bit aligned

    memchr_inv compares contiguous 64-bit words with the 64-bit pattern as
    much as possible. The outside of the region is checked by check_bytes()
    that scans for each byte. Unfortunately, the first 64-bit word is
    unexpectedly scanned by check_bytes() even if the memory area is aligned
    to a 64-bit boundary.

    Both changes were originally suggested by Eric Dumazet.

    Signed-off-by: Akinobu Mita
    Suggested-by: Eric Dumazet
    Cc: Brian Norris
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

08 Mar, 2012

1 commit


01 Mar, 2012

1 commit


01 Nov, 2011

2 commits

  • Commit 84c95c9acf0 ("string: on strstrip(), first remove leading spaces
    before running over str") improved the performance of the strim()
    function.

    Unfortunately this changed the semantics of strim() and broke my code.
    Before the patch it was possible to use strim() without using the return
    value for removing trailing spaces from strings that had either only
    blanks or only trailing blanks.

    Now this does not work any longer for strings that *only* have blanks.

    Before patch: " " -> "" (empty string)
    After patch: " " -> " " (no change)

    I think we should remove your patch to restore the old behavior.

    The description (lib/string.c):

    * Note that the first trailing whitespace is replaced with a %NUL-terminator

    => The first trailing whitespace of a string that only has whitespace
    characters is the first whitespace

    The patch restores the old strim() semantics.

    Signed-off-by: Michael Holzheu
    Cc: Andre Goddard Rosa
    Cc: Martin Schwidefsky
    Cc: Heiko Carstens
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Holzheu
     
  • memchr_inv() is mainly used to check whether the whole buffer is filled
    with just a specified byte.

    The function name and prototype are stolen from logfs and the
    implementation is from SLUB.

    Signed-off-by: Akinobu Mita
    Acked-by: Christoph Lameter
    Acked-by: Pekka Enberg
    Cc: Matt Mackall
    Acked-by: Joern Engel
    Cc: Marcin Slusarz
    Cc: Eric Dumazet
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

19 May, 2011

1 commit


07 Mar, 2010

2 commits


15 Jan, 2010

1 commit

  • It differs strstr() in that it limits the length to be searched
    in the first string.

    Signed-off-by: Li Zefan
    LKML-Reference:
    Acked-by: Frederic Weisbecker
    Signed-off-by: Steven Rostedt

    Li Zefan
     

23 Dec, 2009

1 commit

  • Fix kernel-doc warnings (@arg name) in string.c::skip_spaces().

    Warning(lib/string.c:347): No description found for parameter 'str'
    Warning(lib/string.c:347): Excess function parameter 's' description in 'skip_spaces'

    Signed-off-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

16 Dec, 2009

3 commits

  • Recently, We marked strstrip() as must_check. because it was frequently
    misused and it should be checked. However, we found one exception.
    scsi/ipr.c intentionally ignore return value of strstrip. Because it
    wishes to keep the whitespace at the beginning.

    Thus we need to keep with and without checked whitespace trim function.
    This patch adds a new strim() and changes ipr.c to use it.

    [akpm@linux-foundation.org: coding-style fixes]
    Suggested-by: Alan Cox
    Signed-off-by: KOSAKI Motohiro
    Cc: James Bottomley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KOSAKI Motohiro
     
  • ... so that strlen() iterates over a smaller string comprising of the
    remaining characters only.

    Signed-off-by: André Goddard Rosa
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    André Goddard Rosa
     
  • On the following sentence:
    while (*s && isspace(*s))
    s++;

    If *s == 0, isspace() evaluates to ((_ctype[*s] & 0x20) != 0), which
    evaluates to ((0x08 & 0x20) != 0) which equals to 0 as well.
    If *s == 1, we depend on isspace() result anyway. In other words,
    "a char equals zero is never a space", so remove this check.

    Also, *s != 0 is most common case (non-null string).

    Fixed const return as noticed by Jan Engelhardt and James Bottomley.
    Fixed unnecessary extra cast on strstrip() as noticed by Jan Engelhardt.

    Signed-off-by: André Goddard Rosa
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    André Goddard Rosa
     

19 Nov, 2009

1 commit

  • Doing the strcmp return value as

    signed char __res = *cs - *ct;

    is wrong for two reasons. The subtraction can overflow because __res
    doesn't use a type big enough. Moreover the compared bytes should be
    interpreted as unsigned char as specified by POSIX.

    The same problem is fixed in strncmp.

    Signed-off-by: Uwe Kleine-König
    Cc: Michael Buesch
    Cc: Andreas Schwab
    Cc: Andrew Morton
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

01 May, 2008

1 commit

  • Add a new sysfs_streq() string comparison function, which ignores
    the trailing newlines found in sysfs inputs. By example:

    sysfs_streq("a", "b") ==> false
    sysfs_streq("a", "a") ==> true
    sysfs_streq("a", "a\n") ==> true
    sysfs_streq("a\n", "a") ==> true

    This is intended to simplify parsing of sysfs inputs, letting them
    avoid the need to manually strip off newlines from inputs.

    Signed-off-by: David Brownell
    Acked-by: Greg KH
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Brownell
     

26 Apr, 2007

1 commit


12 Feb, 2007

1 commit

  • A variety of (mostly) innocuous fixes to the embedded kernel-doc content in
    source files, including:

    * make multi-line initial descriptions single line
    * denote some function names, constants and structs as such
    * change erroneous opening '/*' to '/**' in a few places
    * reword some text for clarity

    Signed-off-by: Robert P. J. Day
    Cc: "Randy.Dunlap"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Robert P. J. Day
     

29 Oct, 2006

1 commit

  • strstrip() does not remove the last blank from strings which only consist
    of blanks.

    Example:
    char string[] = " ";
    strstrip(string);

    results in " ", but should produce an empty string!

    The following patch solves this problem:

    Acked-by: Martin Schwidefsky
    Signed-off-by: Michael Holzheu
    Acked-by: Pekka Enberg
    Acked-by Joern Engel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Holzheu
     

23 Jun, 2006

1 commit

  • Add a new strstrip() function to lib/string.c for removing leading and
    trailing whitespace from a string.

    Cc: Michael Holzheu
    Acked-by: Ingo Oeser
    Acked-by: Joern Engel
    Cc: Corey Minyard
    Signed-off-by: Pekka Enberg
    Acked-by: Michael Holzheu
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pekka Enberg
     

11 Apr, 2006

3 commits

  • lib/string.c: In function 'memcpy':
    lib/string.c:470: warning: initialization discards qualifiers from pointer =
    target type

    Signed-off-by: Jan-Benedict Glaw
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan-Benedict Glaw
     
  • Some string functions were safely overrideable in lib/string.c, but their
    corresponding declarations in linux/string.h were not. Correct this, and
    make strcspn overrideable.

    Odds of someone wanting to do optimized assembly of these are small, but
    for the sake of cleanliness, might as well bring them into line with the
    rest of the file.

    Signed-off-by: Kyle McMartin
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kyle McMartin
     
  • While cleaning up parisc_ksyms.c earlier, I noticed that strpbrk wasn't
    being exported from lib/string.c. Investigating further, I noticed a
    changeset that removed its export and added it to _ksyms.c on a few more
    architectures. The justification was that "other arches do it."

    I think this is wrong, since no architecture currently defines
    __HAVE_ARCH_STRPBRK, there's no reason for any of them to be exporting it
    themselves. Therefore, consolidate the export to lib/string.c.

    Signed-off-by: Kyle McMartin
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kyle McMartin
     

22 Mar, 2006

1 commit

  • Sam's tree includes a new check, which found that we're exporting strpbrk()
    multiple times.

    It seems that the convention is that this is exported from the arch files, so
    reove the lib/string.c export.

    Cc: Sam Ravnborg
    Cc: Yoshinori Sato
    Cc: David Howells
    Cc: Greg Ungerer
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

31 Oct, 2005

4 commits

  • A couple of (char *) casts removed in a previous cleanup patch in
    lib/string.c:memmove() were actually useful, as they suppressed a couple of
    warnings:

    assignment discards qualifiers from pointer target type

    Fix by declaring the local variable const in the first place, so casts
    aren't needed to strip the const qualifier.

    Signed-off-by: Paul Jackson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Jackson
     
  • The first two hunks of the patch really belongs in patch 1, but I missed
    them on the first pass and instead of redoing all 3 patches I stuck them in
    this one.

    Signed-off-by: Jesper Juhl
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jesper Juhl
     
  • Removes a few pointless register keywords. register is merely a compiler
    hint that access to the variable should be optimized, but gcc (3.3.6 in my
    case) generates the exact same code with and without the keyword, and even
    if gcc did something different with register present I think it is doubtful
    we would want to optimize access to these variables - especially since this
    is generic library code and there are supposed to be optimized versions in
    asm/ for anything that really matters speed wise.

    (akpm: iirc, keyword register is a gcc no-op unless using -O0)

    Signed-off-by: Jesper Juhl
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jesper Juhl
     
  • Removes some blank lines, removes some trailing whitespace, adds spaces
    after commas and a few similar changes.

    Signed-off-by: Jesper Juhl
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jesper Juhl
     

06 May, 2005

2 commits

  • this clarifies the documentation on the behavier of strncpy().

    Signed-off-by: Domen Puncer
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    walter harms
     
  • In include/asm-x86_64/string.h there are such comments:

    /* Use C out of line version for memcmp */
    #define memcmp __builtin_memcmp
    int memcmp(const void * cs,const void * ct,size_t count);

    This would mean that if the compiler does not decide to use __builtin_memcmp,
    it emits a call to memcmp to be satisfied by the C out-of-line version in
    lib/string.c. What happens is that after preprocessing, in lib/string.i you
    may find the definition of "__builtin_strcmp".

    Actually, by accident, in the object you will find the definition of strcmp
    and such (maybe a trick intended to redirect calls to __builtin_memcmp to the
    default memcmp when the definition is not expanded); however, this particular
    case is not a documented feature as far as I can see.

    Also, the EXPORT_SYMBOL does not work, so it's duplicated in the arch.

    I simply added some #undef to lib/string.c and removed the (now duplicated)
    exports in x86-64 and UML/x86_64 subarchs (the second ones are introduced by
    another patch I just posted for -mm).

    Signed-off-by: Paolo 'Blaisorblade' Giarrusso
    CC: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paolo 'Blaisorblade' Giarrusso
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds