Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Aug 20, 2012
  1. @paulgortmaker

    Linux 2.6.34.13

    paulgortmaker authored
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Commits on Aug 17, 2012
  1. @paulgortmaker

    dmi: Feed DMI table to /dev/random driver

    Tony Luck authored paulgortmaker committed
    commit d114a33 upstream.
    
    Send the entire DMI (SMBIOS) table to the /dev/random driver to
    help seed its pools.
    
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  2. @broonie @paulgortmaker

    mfd: wm831x: Feed the device UUID into device_add_randomness()

    broonie authored paulgortmaker committed
    commit 27130f0 upstream.
    
    wm831x devices contain a unique ID value. Feed this into the newly added
    device_add_randomness() to add some per device seed data to the pool.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  3. @broonie @paulgortmaker

    rtc: wm831x: Feed the write counter into device_add_randomness()

    broonie authored paulgortmaker committed
    commit 9dccf55 upstream.
    
    The tamper evident features of the RTC include the "write counter" which
    is a pseudo-random number regenerated whenever we set the RTC. Since this
    value is unpredictable it should provide some useful seeding to the random
    number generator.
    
    Only do this on boot since the goal is to seed the pool rather than add
    useful entropy.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  4. @paulgortmaker

    random: Add comment to random_initialize()

    Tony Luck authored paulgortmaker committed
    commit cbc96b7 upstream.
    
    Many platforms have per-machine instance data (serial numbers,
    asset tags, etc.) squirreled away in areas that are accessed
    during early system bringup. Mixing this data into the random
    pools has a very high value in providing better random data,
    so we should allow (and even encourage) architecture code to
    call add_device_randomness() from the setup_arch() paths.
    
    However, this limits our options for internal structure of
    the random driver since random_initialize() is not called
    until long after setup_arch().
    
    Add a big fat comment to rand_initialize() spelling out
    this requirement.
    
    Suggested-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  5. @tytso @paulgortmaker

    random: remove rand_initialize_irq()

    tytso authored paulgortmaker committed
    commit c5857cc upstream.
    
    With the new interrupt sampling system, we are no longer using the
    timer_rand_state structure in the irq descriptor, so we can stop
    initializing it now.
    
    [ Merged in fixes from Sedat to find some last missing references to
      rand_initialize_irq() ]
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
    [PG: in .34 the irqdesc.h content is in irq.h instead.]
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  6. @tytso @paulgortmaker

    net: feed /dev/random with the MAC address when registering a device

    tytso authored paulgortmaker committed
    commit 7bf2357 upstream.
    
    Cc: David Miller <davem@davemloft.net>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  7. @tytso @paulgortmaker

    usb: feed USB device information to the /dev/random driver

    tytso authored paulgortmaker committed
    commit b04b315 upstream.
    
    Send the USB device's serial, product, and manufacturer strings to the
    /dev/random driver to help seed its pools.
    
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Acked-by: Greg KH <greg@kroah.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  8. @tytso @paulgortmaker

    MAINTAINERS: Theodore Ts'o is taking over the random driver

    tytso authored paulgortmaker committed
    commit 330e0a0 upstream.
    
    Matt Mackall stepped down as the /dev/random driver maintainer last
    year, so Theodore Ts'o is taking back the /dev/random driver.
    
    Cc: Matt Mackall <mpm@selenic.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  9. @paulgortmaker

    random: mix in architectural randomness in extract_buf()

    H. Peter Anvin authored paulgortmaker committed
    commit d2e7c96 upstream.
    
    Mix in any architectural randomness in extract_buf() instead of
    xfer_secondary_buf().  This allows us to mix in more architectural
    randomness, and it also makes xfer_secondary_buf() faster, moving a
    tiny bit of additional CPU overhead to process which is extracting the
    randomness.
    
    [ Commit description modified by tytso to remove an extended
      advertisement for the RDRAND instruction. ]
    
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Acked-by: Ingo Molnar <mingo@kernel.org>
    Cc: DJ Johnston <dj.johnston@intel.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  10. @tytso @paulgortmaker

    random: add tracepoints for easier debugging and verification

    tytso authored paulgortmaker committed
    commit 00ce1db upstream.
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  11. @tytso @paulgortmaker

    random: add new get_random_bytes_arch() function

    tytso authored paulgortmaker committed
    commit c2557a3 upstream.
    
    Create a new function, get_random_bytes_arch() which will use the
    architecture-specific hardware random number generator if it is
    present.  Change get_random_bytes() to not use the HW RNG, even if it
    is avaiable.
    
    The reason for this is that the hw random number generator is fast (if
    it is present), but it requires that we trust the hardware
    manufacturer to have not put in a back door.  (For example, an
    increasing counter encrypted by an AES key known to the NSA.)
    
    It's unlikely that Intel (for example) was paid off by the US
    Government to do this, but it's impossible for them to prove otherwise
     --- especially since Bull Mountain is documented to use AES as a
    whitener.  Hence, the output of an evil, trojan-horse version of
    RDRAND is statistically indistinguishable from an RDRAND implemented
    to the specifications claimed by Intel.  Short of using a tunnelling
    electronic microscope to reverse engineer an Ivy Bridge chip and
    disassembling and analyzing the CPU microcode, there's no way for us
    to tell for sure.
    
    Since users of get_random_bytes() in the Linux kernel need to be able
    to support hardware systems where the HW RNG is not present, most
    time-sensitive users of this interface have already created their own
    cryptographic RNG interface which uses get_random_bytes() as a seed.
    So it's much better to use the HW RNG to improve the existing random
    number generator, by mixing in any entropy returned by the HW RNG into
    /dev/random's entropy pool, but to always _use_ /dev/random's entropy
    pool.
    
    This way we get almost of the benefits of the HW RNG without any
    potential liabilities.  The only benefits we forgo is the
    speed/performance enhancements --- and generic kernel code can't
    depend on depend on get_random_bytes() having the speed of a HW RNG
    anyway.
    
    For those places that really want access to the arch-specific HW RNG,
    if it is available, we provide get_random_bytes_arch().
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  12. @tytso @paulgortmaker

    random: use the arch-specific rng in xfer_secondary_pool

    tytso authored paulgortmaker committed
    commit e6d4947 upstream.
    
    If the CPU supports a hardware random number generator, use it in
    xfer_secondary_pool(), where it will significantly improve things and
    where we can afford it.
    
    Also, remove the use of the arch-specific rng in
    add_timer_randomness(), since the call is significantly slower than
    get_cycles(), and we're much better off using it in
    xfer_secondary_pool() anyway.
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  13. @torvalds @paulgortmaker

    random: create add_device_randomness() interface

    torvalds authored paulgortmaker committed
    commit a2080a6 upstream.
    
    Add a new interface, add_device_randomness() for adding data to the
    random pool that is likely to differ between two devices (or possibly
    even per boot).  This would be things like MAC addresses or serial
    numbers, or the read-out of the RTC. This does *not* add any actual
    entropy to the pool, but it initializes the pool to different values
    for devices that might otherwise be identical and have very little
    entropy available to them (particularly common in the embedded world).
    
    [ Modified by tytso to mix in a timestamp, since there may be some
      variability caused by the time needed to detect/configure the hardware
      in question. ]
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  14. @tytso @paulgortmaker

    random: use lockless techniques in the interrupt path

    tytso authored paulgortmaker committed
    commit 902c098 upstream.
    
    The real-time Linux folks don't like add_interrupt_randomness() taking
    a spinlock since it is called in the low-level interrupt routine.
    This also allows us to reduce the overhead in the fast path, for the
    random driver, which is the interrupt collection path.
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  15. @tytso @paulgortmaker

    random: make 'add_interrupt_randomness()' do something sane

    tytso authored paulgortmaker committed
    commit 775f4b2 upstream.
    
    We've been moving away from add_interrupt_randomness() for various
    reasons: it's too expensive to do on every interrupt, and flooding the
    CPU with interrupts could theoretically cause bogus floods of entropy
    from a somewhat externally controllable source.
    
    This solves both problems by limiting the actual randomness addition
    to just once a second or after 64 interrupts, whicever comes first.
    During that time, the interrupt cycle data is buffered up in a per-cpu
    pool.  Also, we make sure the the nonblocking pool used by urandom is
    initialized before we start feeding the normal input pool.  This
    assures that /dev/urandom is returning unpredictable data as soon as
    possible.
    
    (Based on an original patch by Linus, but significantly modified by
    tytso.)
    
    Tested-by: Eric Wustrow <ewust@umich.edu>
    Reported-by: Eric Wustrow <ewust@umich.edu>
    Reported-by: Nadia Heninger <nadiah@cs.ucsd.edu>
    Reported-by: Zakir Durumeric <zakir@umich.edu>
    Reported-by: J. Alex Halderman <jhalderm@umich.edu>.
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    [PG: minor adjustment required since .34 doesn't have f9e4989
     which renames "status" to "random" in kernel/irq/handle.c ]
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  16. @compudj @paulgortmaker

    drivers/char/random.c: fix boot id uniqueness race

    compudj authored paulgortmaker committed
    commit 44e4360 upstream.
    
    /proc/sys/kernel/random/boot_id can be read concurrently by userspace
    processes.  If two (or more) user-space processes concurrently read
    boot_id when sysctl_bootid is not yet assigned, a race can occur making
    boot_id differ between the reads.  Because the whole point of the boot id
    is to be unique across a kernel execution, fix this by protecting this
    operation with a spinlock.
    
    Given that this operation is not frequently used, hitting the spinlock
    on each call should not be an issue.
    
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Cc: Matt Mackall <mpm@selenic.com>
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Greg Kroah-Hartman <greg@kroah.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  17. @paulgortmaker

    random: Adjust the number of loops when initializing

    H. Peter Anvin authored paulgortmaker committed
    commit 2dac8e5 upstream.
    
    When we are initializing using arch_get_random_long() we only need to
    loop enough times to touch all the bytes in the buffer; using
    poolwords for that does twice the number of operations necessary on a
    64-bit machine, since in the random number generator code "word" means
    32 bits.
    
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Link: http://lkml.kernel.org/r/1324589281-31931-1-git-send-email-tytso@mit.edu
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  18. @tytso @paulgortmaker

    random: Use arch-specific RNG to initialize the entropy store

    tytso authored paulgortmaker committed
    commit 3e88bdf upstream.
    
    If there is an architecture-specific random number generator (such as
    RDRAND for Intel architectures), use it to initialize /dev/random's
    entropy stores.  Even in the worst case, if RDRAND is something like
    AES(NSA_KEY, counter++), it won't hurt, and it will definitely help
    against any other adversaries.
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Link: http://lkml.kernel.org/r/1324589281-31931-1-git-send-email-tytso@mit.edu
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  19. @torvalds @paulgortmaker

    random: Use arch_get_random_int instead of cycle counter if avail

    torvalds authored paulgortmaker committed
    commit cf833d0 upstream.
    
    We still don't use rdrand in /dev/random, which just seems stupid. We
    accept the *cycle*counter* as a random input, but we don't accept
    rdrand? That's just broken.
    
    Sure, people can do things in user space (write to /dev/random, use
    rdrand in addition to /dev/random themselves etc etc), but that
    *still* seems to be a particularly stupid reason for saying "we
    shouldn't bother to try to do better in /dev/random".
    
    And even if somebody really doesn't trust rdrand as a source of random
    bytes, it seems singularly stupid to trust the cycle counter *more*.
    
    So I'd suggest the attached patch. I'm not going to even bother
    arguing that we should add more bits to the entropy estimate, because
    that's not the point - I don't care if /dev/random fills up slowly or
    not, I think it's just stupid to not use the bits we can get from
    rdrand and mix them into the strong randomness pool.
    
    Link: http://lkml.kernel.org/r/CA%2B55aFwn59N1=m651QAyTy-1gO1noGbK18zwKDwvwqnravA84A@mail.gmail.com
    Acked-by: "David S. Miller" <davem@davemloft.net>
    Acked-by: "Theodore Ts'o" <tytso@mit.edu>
    Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Matt Mackall <mpm@selenic.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  20. @paulgortmaker

    fix typo/thinko in get_random_bytes()

    Luck, Tony authored paulgortmaker committed
    commit bd29e56 upstream.
    
    If there is an architecture-specific random number generator we use it
    to acquire randomness one "long" at a time.  We should put these random
    words into consecutive words in the result buffer - not just overwrite
    the first word again and again.
    
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  21. @paulgortmaker

    x86, random: Architectural inlines to get random integers with RDRAND

    H. Peter Anvin authored paulgortmaker committed
    commit 628c624 upstream.
    
    Architectural inlines to get random ints and longs using the RDRAND
    instruction.
    
    Intel has introduced a new RDRAND instruction, a Digital Random Number
    Generator (DRNG), which is functionally an high bandwidth entropy
    source, cryptographic whitener, and integrity monitor all built into
    hardware.  This enables RDRAND to be used directly, bypassing the
    kernel random number pool.
    
    For technical documentation, see:
    
    http://software.intel.com/en-us/articles/download-the-latest-bull-mountain-software-implementation-guide/
    
    In this patch, this is *only* used for the nonblocking random number
    pool.  RDRAND is a nonblocking source, similar to our /dev/urandom,
    and is therefore not a direct replacement for /dev/random.  The
    architectural hooks presented in the previous patch only feed the
    kernel internal users, which only use the nonblocking pool, and so
    this is not a problem.
    
    Since this instruction is available in userspace, there is no reason
    to have a /dev/hw_rng device driver for the purpose of feeding rngd.
    This is especially so since RDRAND is a nonblocking source, and needs
    additional whitening and reduction (see the above technical
    documentation for details) in order to be of "pure entropy source"
    quality.
    
    The CONFIG_EXPERT compile-time option can be used to disable this use
    of RDRAND.
    
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Originally-by: Fenghua Yu <fenghua.yu@intel.com>
    Cc: Matt Mackall <mpm@selenic.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  22. @paulgortmaker

    random: Add support for architectural random hooks

    H. Peter Anvin authored paulgortmaker committed
    commit 63d7717 upstream.
    
    Add support for architecture-specific hooks into the kernel-directed
    random number generator interfaces.  This patchset does not use the
    architecture random number generator interfaces for the
    userspace-directed interfaces (/dev/random and /dev/urandom), thus
    eliminating the need to distinguish between them based on a pool
    pointer.
    
    Changes in version 3:
    - Moved the hooks from extract_entropy() to get_random_bytes().
    - Changes the hooks to inlines.
    
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: Matt Mackall <mpm@selenic.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    [PG: .34 already had "unsigned int ret" in get_random_int, so the
     diffstat here is slightly smaller than that of 63d7717. ]
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  23. @paulgortmaker

    x86, cpufeature: Update CPU feature RDRND to RDRAND

    Kees Cook authored paulgortmaker committed
    commit 7ccafc5 upstream.
    
    The Intel manual changed the name of the CPUID bit to match the
    instruction name. We should follow suit for sanity's sake. (See Intel SDM
    Volume 2, Table 3-20 "Feature Information Returned in the ECX Register".)
    
    [ hpa: we can only do this at this time because there are currently no CPUs
      with this feature on the market, hence this is pre-hardware enabling.
      However, Cc:'ing stable so that stable can present a consistent ABI. ]
    
    Signed-off-by: Kees Cook <kees.cook@canonical.com>
    Link: http://lkml.kernel.org/r/20110524232926.GA27728@outflux.net
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  24. @paulgortmaker

    x86, cpu: Add CPU flags for F16C and RDRND

    H. Peter Anvin authored paulgortmaker committed
    commit 24da9c2 upstream.
    
    Add support for the newly documented F16C (16-bit floating point
    conversions) and RDRND (RDRAND instruction) CPU feature flags.
    
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  25. @paulgortmaker

    random: simplify fips mode

    Matt Mackall authored paulgortmaker committed
    commit e954bc9 upstream.
    
    Rather than dynamically allocate 10 bytes, move it to static allocation.
    This saves space and avoids the need for error checking.
    
    Signed-off-by: Matt Mackall <mpm@selenic.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    [PG: adding this simplifies required updates to random for .34 stable]
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  26. @anbroid @paulgortmaker

    USB: quirks: adding more quirky webcams to avoid squeaky audio

    anbroid authored paulgortmaker committed
    commit 0d145d7 upstream.
    
    The following patch contains additional affected webcam models, on top of the
    patches commited to linux-next 2394d67
    and 5b253d8
    
    Signed-off-by: sordna <sordna@gmail.com>
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  27. @paulgortmaker

    USB: add quirk for Logitech C600 web cam

    Josh Boyer authored paulgortmaker committed
    commit 60c71ca upstream.
    
    We've had another report of the "chipmunk" sound on a Logitech C600 webcam.
    This patch resolves the issue.
    
    Signed-off-by: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  28. @paulgortmaker

    usb-storage: Accept 8020i-protocol commands longer than 12 bytes

    Alan Stern authored paulgortmaker committed
    commit 2f640bf upstream.
    
    The 8020i protocol (also 8070i and QIC-157) uses 12-byte commands;
    shorter commands must be padded.  Simon Detheridge reports that his
    3-TB USB disk drive claims to use the 8020i protocol (which is
    normally meant for ATAPI devices like CD drives), and because of its
    large size, the disk drive requires the use of 16-byte commands.
    However the usb_stor_pad12_command() routine in usb-storage always
    sets the command length to 12, making the drive impossible to use.
    
    Since the SFF-8020i specification allows for 16-byte commands in
    future extensions, we may as well accept them.  This patch (as1490)
    changes usb_stor_pad12_command() to leave commands larger than 12
    bytes alone rather than truncating them.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Tested-by: Simon Detheridge <simon@widgit.com>
    CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  29. @jhovold @paulgortmaker

    USB: ftdi_sio: fix initial baud rate

    jhovold authored paulgortmaker committed
    commit 108e02b upstream.
    
    Fix regression introduced by commit b1ffb4c ("USB: Fix Corruption
    issue in USB ftdi driver ftdi_sio.c") which caused the termios settings
    to no longer be initialised at open. Consequently it was no longer
    possible to set the port to the default speed of 9600 baud without first
    changing to another baud rate and back again.
    
    Reported-by: Roland Ramthun <mail@roland-ramthun.de>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Tested-by: Roland Ramthun <mail@roland-ramthun.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  30. @amworsley @paulgortmaker

    USB: Fix Corruption issue in USB ftdi driver ftdi_sio.c

    amworsley authored paulgortmaker committed
    commit b1ffb4c upstream.
    
    Fix for ftdi_set_termios() glitching output
    
    ftdi_set_termios() is constantly setting the baud rate, data bits and parity
    unnecessarily on every call, . When called while characters are being
    transmitted can cause the FTDI chip to corrupt the serial port bit stream
    output by stalling the output half a bit during the output of a character.
    Simple fix by skipping this setting if the baud rate/data bits/parity are
    unchanged.
    
    Signed-off-by: Andrew Worsley <amworsley@gmail.com>
    ----
    
      I had a brief run with strace on the getty and it was doing ioctl()s on
      each call but it didn't look relavant to the problem. I think the issue is
      that XON/XOFF flow control was being implmented via hardware - for the ixoff
      to allow the user to use XON/XOFF to control output. Unfortunately it would
      send 3 Control URBs updating all of the settings after each piece of input
    
      I am trying to work around the issue of gmail messing with the tab/spacing
      by submitting via SMTP via gmail which I believe should fix the issue.
    
      The patch is against v3.2-rc2 and compiles - but no additional testing in
      this kernel has been done.
    
      Thanks
    
       Andrew
    
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  31. @udknight @paulgortmaker

    USB: serial: pl2303: rm duplicate id

    udknight authored paulgortmaker committed
    commit 0c16595 upstream.
    
    I get report from customer that his usb-serial
    converter doesn't work well,it sometimes work,
    but sometimes it doesn't.
    
    The usb-serial converter's id:
    vendor_id product_id
    0x4348    0x5523
    
    Then I search the usb-serial codes, and there are
    two drivers announce support this device, pl2303
    and ch341, commit 026dfaf cause it. Through many
    times to test, ch341 works well with this device,
    and pl2303 doesn't work quite often(it just work quite little).
    
    ch341 works well with this device, so we doesn't
    need pl2303 to support.I try to revert 026dfaf first,
    but it failed. So I prepare this patch by hand to revert it.
    
    Signed-off-by: Wang YanQing <Udknight@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  32. @michal42 @paulgortmaker

    kbuild: Fix passing -Wno-* options to gcc 4.4+

    michal42 authored paulgortmaker committed
    commit 8417da6 upstream.
    
    Starting with 4.4, gcc will happily accept -Wno-<anything> in the
    cc-option test and complain later when compiling a file that has some
    other warning. This rather unexpected behavior is intentional as per
    http://gcc.gnu.org/PR28322, so work around it by testing for support of
    the opposite option (without the no-). Introduce a new Makefile function
    cc-disable-warning that does this and update two uses of cc-option in
    the toplevel Makefile.
    
    Reported-and-tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  33. @paulgortmaker

    mm: vmalloc: check for page allocation failure before vmlist insertion

    Mel Gorman authored paulgortmaker committed
    commit 1368edf upstream.
    
    Commit f5252e0 ("mm: avoid null pointer access in vm_struct via
    /proc/vmallocinfo") adds newly allocated vm_structs to the vmlist after
    it is fully initialised.  Unfortunately, it did not check that
    __vmalloc_area_node() successfully populated the area.  In the event of
    allocation failure, the vmalloc area is freed but the pointer to freed
    memory is inserted into the vmlist leading to a a crash later in
    get_vmalloc_info().
    
    This patch adds a check for ____vmalloc_area_node() failure within
    __vmalloc_node_range.  It does not use "goto fail" as in the previous
    error path as a warning was already displayed by __vmalloc_area_node()
    before it called vfree in its failure path.
    
    Credit goes to Luciano Chavez for doing all the real work of identifying
    exactly where the problem was.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Reported-by: Luciano Chavez <lnx1138@linux.vnet.ibm.com>
    Tested-by: Luciano Chavez <lnx1138@linux.vnet.ibm.com>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
  34. @paulgortmaker

    mm: avoid null pointer access in vm_struct via /proc/vmallocinfo

    Mitsuo Hayasaka authored paulgortmaker committed
    commit f5252e0 upstream.
    
    The /proc/vmallocinfo shows information about vmalloc allocations in
    vmlist that is a linklist of vm_struct.  It, however, may access pages
    field of vm_struct where a page was not allocated.  This results in a null
    pointer access and leads to a kernel panic.
    
    Why this happens: In __vmalloc_node_range() called from vmalloc(), newly
    allocated vm_struct is added to vmlist at __get_vm_area_node() and then,
    some fields of vm_struct such as nr_pages and pages are set at
    __vmalloc_area_node().  In other words, it is added to vmlist before it is
    fully initialized.  At the same time, when the /proc/vmallocinfo is read,
    it accesses the pages field of vm_struct according to the nr_pages field
    at show_numa_info().  Thus, a null pointer access happens.
    
    The patch adds the newly allocated vm_struct to the vmlist *after* it is
    fully initialized.  So, it can avoid accessing the pages field with
    unallocated page when show_numa_info() is called.
    
    Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Namhyung Kim <namhyung@gmail.com>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [PG: .34 has VMALLOC_START/END vs. start/end in f5252e0]
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Something went wrong with that request. Please try again.