11 Aug, 2009

1 commit

  • Commit d945cb9cc ("pty: Rework the pty layer to use the normal buffering
    logic") dropped the test for 'tty->stopped' in pty_write_room(), which
    then causes the n_tty line discipline thing to not throttle the data
    properly when the tty is stopped.

    So instead of pausing the write due to the tty being stopped, the ldisc
    layer would go ahead and push it down to the pty. The pty write()
    routine would then refuse to take the data (because it _did_ check
    'stopped'), and the data wouldn't actually be written.

    This whole stopped test should eventually be moved into the tty ldisc
    layer rather than have low-level tty drivers care about these things,
    but right now the fix is to just re-instate the missing pty 'stopped'
    handling.

    Reported-and-tested-by: Artur Skawina
    Cc: Alan Cox
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

05 Aug, 2009

4 commits

  • * git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6:
    tty-ldisc: be more careful in 'put_ldisc' locking
    tty-ldisc: turn ldisc user count into a proper refcount
    tty-ldisc: make refcount be atomic_t 'users' count

    Linus Torvalds
     
  • Use 'atomic_dec_and_lock()' to make sure that we always hold the
    tty_ldisc_lock when the ldisc count goes to zero. That way we can never
    race against 'tty_ldisc_try()' increasing the count again.

    Reported-by: OGAWA Hirofumi
    Signed-off-by: Linus Torvalds
    Tested-by: Sergey Senozhatsky
    Signed-off-by: Greg Kroah-Hartman

    Linus Torvalds
     
  • By using the user count for the actual lifetime rules, we can get rid of
    the silly "wait_for_idle" logic, because any busy ldisc will
    automatically stay around until the last user releases it. This avoids
    a host of odd issues, and simplifies the code.

    So now, when the last ldisc reference is dropped, we just release the
    ldisc operations struct reference, and free the ldisc.

    It looks obvious enough, and it does work for me, but the counting
    _could_ be off. It probably isn't (bad counting in the new version would
    generally imply that the old code did something really bad, like free an
    ldisc with a non-zero count), but it does need some testing, and
    preferably somebody looking at it.

    With this change, both 'tty_ldisc_put()' and 'tty_ldisc_deref()' are
    just aliases for the new ref-counting 'put_ldisc()'. Both of them
    decrement the ldisc user count and free it if it goes down to zero.
    They're identical functions, in other words.

    But the reason they still exist as sepate functions is that one of them
    was exported (tty_ldisc_deref) and had a stupid name (so I don't want to
    use it as the main name), and the other one was used in multiple places
    (and I didn't want to make the patch larger just to rename the users).

    In addition to the refcounting, I did do some minimal cleanup. For
    example, now "tty_ldisc_try()" actually returns the ldisc it got under
    the lock, rather than returning true/false and then the caller would
    look up the ldisc again (now without the protection of the lock).

    That said, there's tons of dubious use of 'tty->ldisc' without obviously
    proper locking or refcounting left. I expressly did _not_ want to try to
    fix it all, keeping the patch minimal. There may or may not be bugs in
    that kind of code, but they wouldn't be _new_ bugs.

    That said, even if the bugs aren't new, the timing and lifetime will
    change. For example, some silly code may depend on the 'tty->ldisc'
    pointer not changing because they hold a refcount on the 'ldisc'. And
    that's no longer true - if you hold a ref on the ldisc, the 'ldisc'
    itself is safe, but tty->ldisc may change.

    So the proper locking (remains) to hold tty->ldisc_mutex if you expect
    tty->ldisc to be stable. That's not really a _new_ rule, but it's an
    example of something that the old code might have unintentionally
    depended on and hidden bugs.

    Whatever. The patch _looks_ sensible to me. The only users of
    ldisc->users are:
    - get_ldisc() - atomically increment the count

    - put_ldisc() - atomically decrements the count and releases if zero

    - tty_ldisc_try_get() - creates the ldisc, and sets the count to 1.
    The ldisc should then either be released, or be attached to a tty.

    Signed-off-by: Linus Torvalds
    Tested-by: OGAWA Hirofumi
    Tested-by: Sergey Senozhatsky
    Acked-by: Alan Cox
    Signed-off-by: Greg Kroah-Hartman

    Linus Torvalds
     
  • This is pure preparation of changing the ldisc reference counting to be
    a true refcount that defines the lifetime of the ldisc. But this is a
    purely syntactic change for now to make the next steps easier.

    This patch should make no semantic changes at all. But I wanted to make
    the ldisc refcount be an atomic (I will be touching it without locks
    soon enough), and I wanted to rename it so that there isn't quite as
    much confusion between 'ldo->refcount' (ldisk operations refcount) and
    'ld->refcount' (ldisc refcount itself) in the same file.

    So it's now an atomic 'ld->users' count. It still starts at zero,
    despite having a reference from 'tty->ldisc', but that will change once
    we turn it into a _real_ refcount.

    Signed-off-by: Linus Torvalds
    Tested-by: OGAWA Hirofumi
    Tested-by: Sergey Senozhatsky
    Acked-by: Alan Cox
    Signed-off-by: Greg Kroah-Hartman

    Linus Torvalds
     

02 Aug, 2009

1 commit


30 Jul, 2009

3 commits

  • commit d6580a9f15238b87e618310c862231ae3f352d2d ("kexec: sysrq: simplify
    sysrq-c handler") changed the behavior of sysrq-c to unconditional
    dereference of NULL pointer. So in cases with CONFIG_KEXEC, where
    crash_kexec() was directly called from sysrq-c before, now it can be said
    that a step of "real oops" was inserted before starting kdump.

    However, in contrast to oops via SysRq-c from keyboard which results in
    panic due to in_interrupt(), oops via "echo c > /proc/sysrq-trigger" will
    not become panic unless panic_on_oops=1. It means that even if dump is
    properly configured to be taken on panic, the sysrq-c from proc interface
    might not start crashdump while the sysrq-c from keyboard can start
    crashdump. This confuses traditional users of kdump, i.e. people who
    expect sysrq-c to do common behavior in both of the keyboard and proc
    interface.

    This patch brings the keyboard and proc interface behavior of sysrq-c in
    line, by forcing panic_on_oops=1 before oops in sysrq-c handler.

    And some updates in documentation are included, to clarify that there is
    no longer dependency with CONFIG_KEXEC, and that now the system can just
    crash by sysrq-c if no dump mechanism is configured.

    Signed-off-by: Hidetoshi Seto
    Cc: Lai Jiangshan
    Cc: Ken'ichi Ohmichi
    Acked-by: Neil Horman
    Acked-by: Vivek Goyal
    Cc: Brayan Arraes
    Cc: Eric W. Biederman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hidetoshi Seto
     
  • * 'zero-length' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6:
    Remove zero-length file drivers/char/vr41xx_giu.c

    Linus Torvalds
     
  • We really don't want to mark the pty as a low-latency device, because as
    Alan points out, the ->write method can be called from an IRQ (ppp?),
    and that means we can't use ->low_latency=1 as we take mutexes in the
    low_latency case.

    So rather than using low_latency to force the written data to be pushed
    to the ldisc handling at 'write()' time, just make the reader side (or
    the poll function) do the flush when it checks whether there is data to
    be had.

    This also fixes the problem with lost data in an emacs compile buffer
    (bugzilla 13815), and we can thus revert the low_latency pty hack
    (commit 3a54297478e6578f96fd54bf4daa1751130aca86: "pty: quickfix for the
    pty ENXIO timing problems").

    Signed-off-by: OGAWA Hirofumi
    Tested-by: Aneesh Kumar K.V
    [ Modified to do the tty_flush_to_ldisc() inside input_available_p() so
    that it triggers for both read and poll() - Linus]
    Signed-off-by: Linus Torvalds

    OGAWA Hirofumi
     

29 Jul, 2009

1 commit


28 Jul, 2009

1 commit


21 Jul, 2009

3 commits

  • This function does not have an error return and returning an error is
    instead interpreted as having a lot of pending bytes.

    Reported by Jeff Harris who provided a list of some of the remaining
    offenders.

    Signed-off-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Alan Cox
     
  • If spin_lock_irqsave is called twice in a row with the same second
    argument, the interrupt state at the point of the second call overwrites
    the value saved by the first call. Indeed, the second call does not
    need to save the interrupt state, so it is changed to a simple
    spin_lock.

    The semantic match that finds this problem is as follows:
    (http://www.emn.fr/x-info/coccinelle/)

    //
    @@
    expression lock1,lock2;
    expression flags;
    @@

    *spin_lock_irqsave(lock1,flags)
    ... when != flags
    *spin_lock_irqsave(lock2,flags)
    //

    Signed-off-by: Julia Lawall
    Signed-off-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Julia Lawall
     
  • The buffer for the consoles are unconditionally allocated at con_init()
    time, which miss the creation of the vcs(a) devices.

    Since 2.6.30 (commit 4995f8ef9d3aac72745e12419d7fbaa8d01b1d81, 'vcs:
    hook sysfs devices into object lifetime instead of "binding"' to be
    exact) these devices are no longer created at open() and removed on
    close(), but controlled by the lifetime of the buffers.

    Reported-by: Gerardo Exequiel Pozzi
    Tested-by: Gerardo Exequiel Pozzi
    Cc: stable@kernel.org
    Signed-off-by: Kay Sievers
    Signed-off-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Kay Sievers
     

17 Jul, 2009

5 commits

  • Whoops.. fortunately not many people use this yet.

    Signed-off-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Alan Cox
     
  • If a tty in N_TTY mode with echo enabled manages to get itself into a state
    where
    - echo characters are pending
    - FASYNC is enabled
    - tty_write_wakeup is called from either
    - a device write path (pty)
    - an IRQ (serial)

    then it either deadlocks or explodes taking a mutex in the IRQ path.

    On the serial side it is almost impossible to reproduce because you have to
    go from a full serial port to a near empty one with echo characters
    pending. The pty case happens to have become possible to trigger using
    emacs and ptys, the pty changes having created a scenario which shows up
    this bug.

    The code path is

    n_tty:process_echoes() (takes mutex)
    tty_io:tty_put_char()
    pty:pty_write (or serial paths)
    tty_wakeup (from pty_write or serial IRQ)
    n_tty_write_wakeup()
    process_echoes()
    *KABOOM*

    Signed-off-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Alan Cox
     
  • Don't forget to drop a tty refererence on fail paths in
    receive_data().

    Signed-off-by: Jiri Slaby
    Signed-off-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Jiri Slaby
     
  • Bootmem is not used for the vt screen buffer anymore as slab is now
    available at the time the console is initialized.

    Get rid of the now superfluous distinction between slab and bootmem,
    it's always slab.

    This also fixes a kmalloc leak which Catalin described thusly:

    Commit a5f4f52e ("vt: use kzalloc() instead of the bootmem allocator")
    replaced the alloc_bootmem() with kzalloc() but didn't set vc_kmalloced to
    1 and the memory block is later leaked. The corresponding kmemleak trace:

    unreferenced object 0xdf828000 (size 8192):
    comm "swapper", pid 0, jiffies 4294937296
    backtrace:
    [] __save_stack_trace+0x17/0x1c
    [] log_early+0x55/0x84
    [] kmemleak_alloc+0x33/0x3c
    [] __kmalloc+0xd7/0xe4
    [] con_init+0xbf/0x1b8
    [] console_init+0x11/0x20
    [] start_kernel+0x137/0x1e4

    Signed-off-by: Johannes Weiner
    Reviewed-by: Pekka Enberg
    Tested-by: Catalin Marinas
    Signed-off-by: Andrew Morton
    Signed-off-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Johannes Weiner
     
  • We can get a situation where a hangup occurs during or after a close. In
    that case the ldisc gets disposed of by the close and the hangup then
    explodes.

    Signed-off-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Alan Cox
     

13 Jul, 2009

1 commit

  • * Remove smp_lock.h from files which don't need it (including some headers!)
    * Add smp_lock.h to files which do need it
    * Make smp_lock.h include conditional in hardirq.h
    It's needed only for one kernel_locked() usage which is under CONFIG_PREEMPT

    This will make hardirq.h inclusion cheaper for every PREEMPT=n config
    (which includes allmodconfig/allyesconfig, BTW)

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

    Alexey Dobriyan
     

09 Jul, 2009

2 commits

  • Commit 5fd29d6ccbc98884569d6f3105aeca70858b3e0f ("printk: clean up
    handling of log-levels and newlines") changed printk semantics. printk
    lines with multiple KERN_ prefixes are no longer emitted as
    before the patch.

    is now included in the output on each additional use.

    Remove all uses of multiple KERN_s in formats.

    Signed-off-by: Joe Perches
    Signed-off-by: Linus Torvalds

    Joe Perches
     
  • This fixes the ppp problems and various other issues with call locking
    caused by one side of a pty called in one locking context trying to match
    another with differing rules on the other side. We also get a big slack
    space to work with that means we can bury the flow control deadlock case
    for any conceivable real world situation.

    Signed-off-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Alan Cox
     

03 Jul, 2009

2 commits


30 Jun, 2009

1 commit

  • Currently we reinit the ldisc on final tty close which is what the old code
    did to ensure that if the device retained its termios settings then it had the
    right ldisc. tty_ldisc_reinit does that but also leaves us with the reset
    ldisc reference which is then leaked.

    At this point we know the port will be recycled so we can kill the ldisc
    off completely rather than try and add another ldisc free up when the kref
    count hits zero.

    At this point it is safe to keep the ldisc closed as tty_ldisc waiting
    methods are only used from the user side, and as the final close we are
    the last such reference. Interrupt/driver side methods will always use the
    non wait version and get back a NULL.

    Found with kmemleak and investigated/identified by Catalin Marinas.

    Signed-off-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Alan Cox
     

26 Jun, 2009

2 commits

  • On Mon, Nov 17, 2008 at 01:26:13AM -0600, Sonny Rao wrote:
    > On Fri, Nov 07, 2008 at 04:28:29PM +1100, Paul Mackerras wrote:
    > > Sonny Rao writes:
    > >
    > > > Fix the BSR driver to allow small BSR devices, which are limited to a
    > > > single 4k space, on a 64k page kernel. Previously the driver would
    > > > reject the mmap since the size was smaller than PAGESIZE (or because
    > > > the size was greater than the size of the device). Now, we check for
    > > > this case use remap_4k_pfn(). Also, take out code to set vm_flags,
    > > > as the remap_pfn functions will do this for us.
    > >
    > > Thanks.
    > >
    > > Do we know that the BSR size will always be 4k if it's not a multiple
    > > of 64k? Is it possible that we could get 8k, 16k or 32k or BSRs?
    > > If it is possible, what does the user need to be able to do? Do they
    > > just want to map 4k, or might then want to map the whole thing?
    >
    >
    > Hi Paul, I took a look at changing the driver to reject a request for
    > mapping more than a single 4k page, however the only indication we get
    > of the requested size in the mmap function is the vma size, and this
    > is always one page at minimum. So, it's not possible to determine if
    > the user wants one 4k page or more. As I noted in my first response,
    > there is only one case where this is even possible and I don't think
    > it is a significant concern.
    >
    > I did notice that I left out the check to see if the user is trying to
    > map more than the device length, so I fixed that. Here's the revised
    > patch.

    Alright, I've reworked this now so that if we get one of these cases
    where there's a bsr that's > 4k and < 64k on a 64k kernel we'll only
    advertise that it is a 4k BSR to userspace. I think this is the best
    solution since user programs are only supposed to look at sysfs to
    determine how much can be mapped, and libbsr does this as well.

    Please consider for 2.6.31 as a fix, thanks.

    Signed-off-by: Benjamin Herrenschmidt

    Sonny Rao
     
  • Add a 4096 byte BSR size which will be used on new machines. Also, remove
    the warning when we run into an unknown size, as this can spam the kernel
    log excessively.

    Signed-off-by: Sonny Rao
    Signed-off-by: Benjamin Herrenschmidt

    Sonny Rao
     

25 Jun, 2009

3 commits

  • The kernel oopses if this flag is set.

    [and neither driver should set it as they call tty_flip_buffer_push from IRQ
    paths so have always been buggy]

    Signed-off-by: Chuck Ebbert
    Signed-off-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Chuck Ebbert
     
  • Since commit 3e3b5c087799e536871c8261b05bc28e4783c8da ("tty: use
    prepare/finish_wait"), tty_port_block_til_ready() is using
    prepare_to_wait()/finish_wait(). Those functions require that the
    wait_queue_t be initialised with .func=autoremove_wake_function, via
    DEFINE_WAIT().

    But the conversion from DECLARE_WAITQUEUE() to DEFINE_WAIT() was not made,
    so this code will oops in finish_wait().

    Signed-off-by: Jiri Slaby
    Signed-off-by: Andrew Morton
    Signed-off-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Jiri Slaby
     
  • Fix race condition when adding transmit data to active DMA buffer ring
    that can cause transmit stall.

    Update transmit timeout when adding data to active DMA buffer ring.
    Base transmit timeout on amount of buffered data instead of using fixed
    value.

    Signed-off-by: Paul Fulghum
    Signed-off-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Paul Fulghum
     

23 Jun, 2009

6 commits

  • Add flush_buffer tty callback to flush rx buffers.
    Add TCFLSH ioctl processing to flush tx buffers.
    Increase default tx buffers from 1 to 3.
    Remove unneeded flush_buffer call in open callback.
    Remove vendor specific CVS version string.

    Signed-off-by: Paul Fulghum
    Signed-off-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Paul Fulghum
     
  • Don't return from switch/case directly in vt_ioctl. Set ret and break
    instead so that we unlock BKL.

    Signed-off-by: Jiri Slaby
    Signed-off-by: Alan Cox
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds

    Jiri Slaby
     
  • Don't return from switch/case, break instead, so that we unlock BKL.

    Signed-off-by: Jiri Slaby
    Signed-off-by: Alan Cox
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds

    Jiri Slaby
     
  • There is omitted BKunL in r3964_read.

    Centralize the paths to one point with one unlock.

    Signed-off-by: Jiri Slaby
    Signed-off-by: Alan Cox
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds

    Jiri Slaby
     
  • The original patch garned some feedback and a v2 was posted, but that
    version seems to have been missed when merging the driver.

    At any rate, this cleans up the printk usage as suggested by Jiri Slaby.

    Signed-off-by: Mike Frysinger
    Signed-off-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Mike Frysinger
     
  • This reverts commit a90b037583d5f1ae3e54e9c687c79df82d1d34a4, which
    already got fixed as commit f0e8527726b9e56649b9eafde3bc0fbc4dd2dd47:
    the same patch (trivial differences) got applied twice.

    Requested-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

21 Jun, 2009

2 commits

  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (35 commits)
    Input: add driver for Synaptics I2C touchpad
    Input: synaptics - add support for reporting x/y resolution
    Input: ALPS - handle touchpoints buttons correctly
    Input: gpio-keys - change timer to workqueue
    Input: ads7846 - pin change interrupt support
    Input: add support for touchscreen on W90P910 ARM platform
    Input: appletouch - improve finger detection
    Input: wacom - clear Intuos4 wheel data when finger leaves proximity
    Input: ucb1400 - move static function from header into core
    Input: add driver for EETI touchpanels
    Input: ads7846 - more detailed model name in sysfs
    Input: ads7846 - support swapping x and y axes
    Input: ati_remote2 - use non-atomic bitops
    Input: introduce lm8323 keypad driver
    Input: psmouse - ESD workaround fix for OLPC XO touchpad
    Input: tsc2007 - make sure platform provides get_pendown_state()
    Input: uinput - flush all pending ff effects before destroying device
    Input: simplify name handling for certain input handles
    Input: serio - do not use deprecated dev.power.power_state
    Input: wacom - add support for Intuos4 tablets
    ...

    Linus Torvalds
     
  • * 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (24 commits)
    agp/intel: Make intel_i965_mask_memory use dma_addr_t for physical addresses
    agp: add user mapping support to ATI AGP bridge.
    drm/i915: enable GEM on PAE.
    drm/radeon: fix unused variables warning
    agp: switch AGP to use page array instead of unsigned long array
    agpgart: detected ALi M???? chipset with M1621
    drm/radeon: command stream checker for r3xx-r5xx hardware
    drm/radeon: Fully initialize LVDS info also when we can't get it from the ROM.
    radeon: Fix CP byte order on big endian architectures with KMS.
    agp/uninorth: Handle user memory types.
    drm/ttm: Add some powerpc cache flush code.
    radeon: Enable modesetting on non-x86.
    drm/radeon: Respect AGP cant_use_aperture flag.
    drm: EDID endianness fixes.
    drm/radeon: this VRAM vs aperture test is wrong, just remove it.
    drm/ttm: fix an error path to exit function correctly
    drm: Apply "Memory fragmentation from lost alignment blocks"
    ttm: Return -ERESTART when a signal interrupts bo eviction.
    drm: Remove memory debugging infrastructure.
    drm/i915: Clear fence register on tiling stride change.
    ...

    Linus Torvalds
     

20 Jun, 2009

2 commits

  • Otherwise, the high bits to be stuffed in the unused lower bits of the
    page address are lost.

    Signed-off-by: Pierre Willenbrock
    Signed-off-by: Dave Airlie

    Pierre Willenbrock
     
  • * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: (35 commits)
    powerpc/5121: make clock debug output more readable
    powerpc/5xxx: Add common mpc5xxx_get_bus_frequency() function
    powerpc/5200: Update pcm030.dts to add i2c eeprom and delete cruft
    powerpc/5200: convert mpc52xx_psc_spi to use cs_control callback
    fbdev/xilinxfb: Fix improper casting and tighen up probe path
    usb/ps3: Add missing annotations
    powerpc: Add memory clobber to mtspr()
    powerpc: Fix invalid construct in our CPU selection Kconfig
    ps3rom: Use ps3_system_bus_[gs]et_drvdata() instead of direct access
    powerpc: Add configurable -Werror for arch/powerpc
    of_serial: Add UPF_FIXED_TYPE flag
    drivers/hvc: Add missing __devexit_p()
    net/ps3: gelic - Add missing annotations
    powerpc: Introduce macro spin_event_timeout()
    powerpc/warp: Fix ISA_DMA_THRESHOLD default
    powerpc/bootwrapper: Custom build options for XPedite52xx targets
    powerpc/85xx: Add defconfig for X-ES MPC85xx boards
    powerpc/85xx: Add dts files for X-ES MPC85xx boards
    powerpc/85xx: Add platform support for X-ES MPC85xx boards
    83xx: add support for the kmeter1 board.
    ...

    Linus Torvalds