1. 18 10月, 2010 2 次提交
  2. 17 10月, 2010 1 次提交
  3. 16 10月, 2010 12 次提交
  4. 15 10月, 2010 6 次提交
    • T
      ubd: fix incorrect sector handling during request restart · 47526903
      Tejun Heo 提交于
      Commit f81f2f7c (ubd: drop unnecessary rq->sector manipulation)
      dropped request->sector manipulation in preparation for global request
      handling cleanup; unfortunately, it incorrectly assumed that the
      updated sector wasn't being used.
      
      ubd tries to issue as many requests as possible to io_thread.  When
      issuing fails due to memory pressure or other reasons, the device is
      put on the restart list and issuing stops.  On IO completion, devices
      on the restart list are scanned and IO issuing is restarted.
      
      ubd issues IOs sg-by-sg and issuing can be stopped in the middle of a
      request, so each device on the restart queue needs to remember where
      to restart in its current request.  ubd needs to keep track of the
      issue position itself because,
      
      * blk_rq_pos(req) is now updated by the block layer to keep track of
        _completion_ position.
      
      * Multiple io_req's for the current request may be in flight, so it's
        difficult to tell where blk_rq_pos(req) currently is.
      
      Add ubd->rq_pos to keep track of the issue position and use it to
      correctly restart io_req issue.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NRichard Weinberger <richard@nod.at>
      Tested-by: NRichard Weinberger <richard@nod.at>
      Tested-by: NChris Frey <cdfrey@foursquare.net>
      Cc: stable@kernel.org
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      47526903
    • L
      Export dump_{write,seek} to binary loader modules · 8fd01d6c
      Linus Torvalds 提交于
      If you build aout support as a module, you'll want these exported.
      Reported-by: NTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8fd01d6c
    • L
      Linux 2.6.36-rc8 · cd07202c
      Linus Torvalds 提交于
      cd07202c
    • L
      Un-inline the core-dump helper functions · 3aa0ce82
      Linus Torvalds 提交于
      Tony Luck reports that the addition of the access_ok() check in commit
      0eead9ab ("Don't dump task struct in a.out core-dumps") broke the
      ia64 compile due to missing the necessary header file includes.
      
      Rather than add yet another include (<asm/unistd.h>) to make everything
      happy, just uninline the silly core dump helper functions and move the
      bodies to fs/exec.c where they make a lot more sense.
      
      dump_seek() in particular was too big to be an inline function anyway,
      and none of them are in any way performance-critical.  And we really
      don't need to mess up our include file headers more than they already
      are.
      Reported-and-tested-by: NTony Luck <tony.luck@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3aa0ce82
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 · ae42d8d4
      Linus Torvalds 提交于
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
        ehea: Fix a checksum issue on the receive path
        net: allow FEC driver to use fixed PHY support
        tg3: restore rx_dropped accounting
        b44: fix carrier detection on bind
        net: clear heap allocations for privileged ethtool actions
        NET: wimax, fix use after free
        ATM: iphase, remove sleep-inside-atomic
        ATM: mpc, fix use after free
        ATM: solos-pci, remove use after free
        net/fec: carrier off initially to avoid root mount failure
        r8169: use device model DMA API
        r8169: allocate with GFP_KERNEL flag when able to sleep
      ae42d8d4
    • L
      Don't dump task struct in a.out core-dumps · 0eead9ab
      Linus Torvalds 提交于
      akiphie points out that a.out core-dumps have that odd task struct
      dumping that was never used and was never really a good idea (it goes
      back into the mists of history, probably the original core-dumping
      code).  Just remove it.
      
      Also do the access_ok() check on dump_write().  It probably doesn't
      matter (since normal filesystems all seem to do it anyway), but he
      points out that it's normally done by the VFS layer, so ...
      
      [ I suspect that we should possibly do "vfs_write()" instead of
        calling ->write directly.  That also does the whole fsnotify and write
        statistics thing, which may or may not be a good idea. ]
      
      And just to be anal, do this all for the x86-64 32-bit a.out emulation
      code too, even though it's not enabled (and won't currently even
      compile)
      Reported-by: Nakiphie <akiphie@lavabit.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0eead9ab
  5. 14 10月, 2010 12 次提交
  6. 13 10月, 2010 7 次提交
    • F
      HID: Add Cando touch screen 15.6-inch product id · 272036ed
      François Jaouen 提交于
      This add the product id of the touch screen found on ACER Aspire 5738PZ.  Works
      with hid-cando driver.
      
      Signed-off-by: Francois Jaouen<francois.jaouen@laposte.net>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      272036ed
    • R
      ARM: relax ioremap prohibition (309caa9c) for -final and -stable · 06c10884
      Russell King 提交于
      ... but produce a big warning about the problem as encouragement
      for people to fix their drivers.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      06c10884
    • R
    • M
      ARM: 6440/1: ep93xx: DMA: fix channel_disable · 10d48b39
      Mika Westerberg 提交于
      When channel_disable() is called, it disables per channel interrupts and
      waits until channels state becomes STATE_STALL, and then disables the
      channel. Now, if the DMA transfer is disabled while the channel is in
      STATE_NEXT we will not wait anything and disable the channel immediately.
      This seems to cause weird data corruption for example in audio transfers.
      
      Fix is to wait while we are in STATE_NEXT or STATE_ON and only then
      disable the channel.
      Signed-off-by: NMika Westerberg <mika.westerberg@iki.fi>
      Acked-by: NRyan Mallon <ryan@bluewatersys.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      10d48b39
    • D
      ps3disk: passing wrong variable to bvec_kunmap_irq() · 93055c31
      Dan Carpenter 提交于
      This should pass "buf" to bvec_kunmap_irq() instead of "bv".  The api is
      like kmap_atomic() instead of kmap().
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Acked-by: NGeoff Levand <geoff@infradead.org>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      93055c31
    • L
      Merge branch 'kvm-updates/2.6.36' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 0acc1b2a
      Linus Torvalds 提交于
      * 'kvm-updates/2.6.36' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        KVM: x86: Move TSC reset out of vmcb_init
        KVM: x86: Fix SVM VMCB reset
      0acc1b2a
    • S
      ring-buffer: Fix typo of time extends per page · d0134324
      Steven Rostedt 提交于
      Time stamps for the ring buffer are created by the difference between
      two events. Each page of the ring buffer holds a full 64 bit timestamp.
      Each event has a 27 bit delta stamp from the last event. The unit of time
      is nanoseconds, so 27 bits can hold ~134 milliseconds. If two events
      happen more than 134 milliseconds apart, a time extend is inserted
      to add more bits for the delta. The time extend has 59 bits, which
      is good for ~18 years.
      
      Currently the time extend is committed separately from the event.
      If an event is discarded before it is committed, due to filtering,
      the time extend still exists. If all events are being filtered, then
      after ~134 milliseconds a new time extend will be added to the buffer.
      
      This can only happen till the end of the page. Since each page holds
      a full timestamp, there is no reason to add a time extend to the
      beginning of a page. Time extends can only fill a page that has actual
      data at the beginning, so there is no fear that time extends will fill
      more than a page without any data.
      
      When reading an event, a loop is made to skip over time extends
      since they are only used to maintain the time stamp and are never
      given to the caller. As a paranoid check to prevent the loop running
      forever, with the knowledge that time extends may only fill a page,
      a check is made that tests the iteration of the loop, and if the
      iteration is more than the number of time extends that can fit in a page
      a warning is printed and the ring buffer is disabled (all of ftrace
      is also disabled with it).
      
      There is another event type that is called a TIMESTAMP which can
      hold 64 bits of data in the theoretical case that two events happen
      18 years apart. This code has not been implemented, but the name
      of this event exists, as well as the structure for it. The
      size of a TIMESTAMP is 16 bytes, where as a time extend is only
      8 bytes. The macro used to calculate how many time extends can fit on
      a page used the TIMESTAMP size instead of the time extend size
      cutting the amount in half.
      
      The following test case can easily trigger the warning since we only
      need to have half the page filled with time extends to trigger the
      warning:
      
       # cd /sys/kernel/debug/tracing/
       # echo function > current_tracer
       # echo 'common_pid < 0' > events/ftrace/function/filter
       # echo > trace
       # echo 1 > trace_marker
       # sleep 120
       # cat trace
      
      Enabling the function tracer and then setting the filter to only trace
      functions where the process id is negative (no events), then clearing
      the trace buffer to ensure that we have nothing in the buffer,
      then write to trace_marker to add an event to the beginning of a page,
      sleep for 2 minutes (only 35 seconds is probably needed, but this
      guarantees the bug), and then finally reading the trace which will
      trigger the bug.
      
      This patch fixes the typo and prevents the false positive of that warning.
      Reported-by: NHans J. Koch <hjk@linutronix.de>
      Tested-by: NHans J. Koch <hjk@linutronix.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Stable Kernel <stable@kernel.org>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      d0134324