1. 30 7月, 2009 1 次提交
  2. 22 7月, 2009 1 次提交
  3. 18 7月, 2009 1 次提交
  4. 16 7月, 2009 1 次提交
    • E
      netfilter: nf_conntrack: nf_conntrack_alloc() fixes · 941297f4
      Eric Dumazet 提交于
      When a slab cache uses SLAB_DESTROY_BY_RCU, we must be careful when allocating
      objects, since slab allocator could give a freed object still used by lockless
      readers.
      
      In particular, nf_conntrack RCU lookups rely on ct->tuplehash[xxx].hnnode.next
      being always valid (ie containing a valid 'nulls' value, or a valid pointer to next
      object in hash chain.)
      
      kmem_cache_zalloc() setups object with NULL values, but a NULL value is not valid
      for ct->tuplehash[xxx].hnnode.next.
      
      Fix is to call kmem_cache_alloc() and do the zeroing ourself.
      
      As spotted by Patrick, we also need to make sure lookup keys are committed to
      memory before setting refcount to 1, or a lockless reader could get a reference
      on the old version of the object. Its key re-check could then pass the barrier.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      941297f4
  5. 13 7月, 2009 1 次提交
  6. 11 7月, 2009 2 次提交
  7. 10 7月, 2009 1 次提交
  8. 09 7月, 2009 1 次提交
  9. 07 7月, 2009 1 次提交
  10. 06 7月, 2009 3 次提交
  11. 01 7月, 2009 4 次提交
  12. 27 6月, 2009 3 次提交
  13. 25 6月, 2009 2 次提交
  14. 24 6月, 2009 5 次提交
    • C
      update Documentation/filesystems/Locking · 7e325d3a
      Christoph Hellwig 提交于
      The rules for locking in many superblock operations has changed
      significantly, so update the documentation for it.  Also correct some
      older updates and ommissions.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      7e325d3a
    • T
      ALSA: hda - Fix support for Samsung P50 with AD1986A codec · c912e7a5
      Takashi Iwai 提交于
      Samsung P50 requires the HP auto-muting unlike other Samsung models.
      Added a new model=samsung-p50 to support this.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      c912e7a5
    • L
      tracing: Fix trace_buf_size boot option · 9d612bef
      Li Zefan 提交于
      We should be able to specify [KMG] when setting trace_buf_size
      boot option, as documented in kernel-parameters.txt
      Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <4A41F2DB.4020102@cn.fujitsu.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9d612bef
    • T
      leds: Add options to have GPIO LEDs start on or keep their state · ed88bae6
      Trent Piepho 提交于
      There already is a "default-on" trigger but there are problems with it.
      
      For one, it's a inefficient way to do it and requires led trigger support
      to be compiled in.
      
      But the real reason is that is produces a glitch on the LED.  The GPIO is
      allocate with the LED *off*, then *later* when the trigger runs it is
      turned back on.  If the LED was already on via the GPIO's reset default or
      action of the firmware, this produces a glitch where the LED goes from on
      to off to on.  While normally this is fast enough that it wouldn't be
      noticeable to a human observer, there are still serious problems.
      
      One is that there may be something else on the GPIO line, like a hardware
      alarm or watchdog, that is fast enough to notice the glitch.
      
      Another is that the kernel may panic before the LED is turned back on, thus
      hanging with the LED in the wrong state.  This is not just speculation, but
      actually happened to me with an embedded system that has an LED which
      should turn off when the kernel finishes booting, which was left in the
      incorrect state due to a bug in the OF LED binding code.
      
      We also let GPIO LEDs get their initial value from whatever the current
      state of the GPIO line is.  On some systems the LEDs are put into some
      state by the firmware or hardware before Linux boots, and it is desired to
      have them keep this state which is otherwise unknown to Linux.
      
      This requires that the underlying GPIO driver support reading the value of
      output GPIOs.  Some drivers support this and some do not.
      
      The platform device binding gains a field in the platform data
      "default_state" that controls this.  There are three constants defined to
      select from on, off, or keeping the current state.  The OpenFirmware
      binding uses a property named "default-state" that can be set to "on",
      "off", or "keep".  The default if the property isn't present is off.
      Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
      Acked-by: NGrant Likely <grant.likely@secretlab.ca>
      Acked-by: NWolfram Sang <w.sang@pengutronix.de>
      Acked-by: NSean MacLennan <smaclennan@pikatech.com>
      Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
      ed88bae6
    • A
      leds: LED driver for National Semiconductor LP3944 Funlight Chip · 5054d39e
      Antonio Ospite 提交于
      LEDs driver for National Semiconductor LP3944 Funlight Chip
      http://www.national.com/pf/LP/LP3944.html
      
      This helper chip can drive up to 8 leds, with two programmable DIM
      modes; it could even be used as a gpio expander but this driver assumes
      it is used as a led controller.
      
      The DIM modes are used to set _blink_ patterns for leds, the pattern is
      specified supplying two parameters:
        - period: from 0s to 1.6s
        - duty cycle: percentage of the period the led is on, from 0 to 100
      
      LP3944 can be found on Motorola A910 smartphone, where it drives the rgb
      leds, the camera flash light and the displays backlights.
      Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it>
      Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
      5054d39e
  15. 23 6月, 2009 5 次提交
  16. 22 6月, 2009 5 次提交
    • J
      dm raid1: add userspace log · f5db4af4
      Jonthan Brassow 提交于
      This patch contains a device-mapper mirror log module that forwards
      requests to userspace for processing.
      
      The structures used for communication between kernel and userspace are
      located in include/linux/dm-log-userspace.h.  Due to the frequency,
      diversity, and 2-way communication nature of the exchanges between
      kernel and userspace, 'connector' was chosen as the interface for
      communication.
      
      The first log implementations written in userspace - "clustered-disk"
      and "clustered-core" - support clustered shared storage.   A userspace
      daemon (in the LVM2 source code repository) uses openAIS/corosync to
      process requests in an ordered fashion with the rest of the nodes in the
      cluster so as to prevent log state corruption.  Other implementations
      with no association to LVM or openAIS/corosync, are certainly possible.
      
      (Imagine if two machines are writing to the same region of a mirror.
      They would both mark the region dirty, but you need a cluster-aware
      entity that can handle properly marking the region clean when they are
      done.  Otherwise, you might clear the region when the first machine is
      done, not the second.)
      Signed-off-by: NJonathan Brassow <jbrassow@redhat.com>
      Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      f5db4af4
    • K
      dm mpath: add service time load balancer · f392ba88
      Kiyoshi Ueda 提交于
      This patch adds a service time oriented dynamic load balancer,
      dm-service-time, which selects the path with the shortest estimated
      service time for the incoming I/O.
      The service time is estimated by dividing the in-flight I/O size
      by a performance value of each path.
      
      The performance value can be given as a table argument at the table
      loading time.  If no performance value is given, all paths are
      considered equal.
      Signed-off-by: NKiyoshi Ueda <k-ueda@ct.jp.nec.com>
      Signed-off-by: NJun'ichi Nomura <j-nomura@ce.jp.nec.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      f392ba88
    • K
      dm mpath: add queue length load balancer · fd5e0339
      Kiyoshi Ueda 提交于
      This patch adds a dynamic load balancer, dm-queue-length, which
      balances the number of in-flight I/Os across the paths.
      
      The code is based on the patch posted by Stefan Bader:
      https://www.redhat.com/archives/dm-devel/2005-October/msg00050.htmlSigned-off-by: NStefan Bader <stefan.bader@canonical.com>
      Signed-off-by: NKiyoshi Ueda <k-ueda@ct.jp.nec.com>
      Signed-off-by: NJun'ichi Nomura <j-nomura@ce.jp.nec.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      fd5e0339
    • T
      x86: implement percpu_alloc kernel parameter · fa8a7094
      Tejun Heo 提交于
      According to Andi, it isn't clear whether lpage allocator is worth the
      trouble as there are many processors where PMD TLB is far scarcer than
      PTE TLB.  The advantage or disadvantage probably depends on the actual
      size of percpu area and specific processor.  As performance
      degradation due to TLB pressure tends to be highly workload specific
      and subtle, it is difficult to decide which way to go without more
      data.
      
      This patch implements percpu_alloc kernel parameter to allow selecting
      which first chunk allocator to use to ease debugging and testing.
      
      While at it, make sure all the failure paths report why something
      failed to help determining why certain allocator isn't working.  Also,
      kill the "Great future plan" comment which had already been realized
      quite some time ago.
      
      [ Impact: allow explicit percpu first chunk allocator selection ]
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NJan Beulich <JBeulich@novell.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      fa8a7094
    • A
      sdhci: Add support for hosts that are only capable of 1-bit transfers · 5fe23c7f
      Anton Vorontsov 提交于
      Some hosts (hardware configurations, or particular SD/MMC slots) may
      not support 4-bit bus. For example, on MPC8569E-MDS boards we can
      switch between serial (1-bit only) and nibble (4-bit) modes, thought
      we have to disable more peripherals to work in 4-bit mode.
      
      Along with some small core changes, this patch modifies sdhci-of
      driver, so that now it looks for "sdhci,1-bit-only" property in the
      device-tree, and if specified we enable a proper quirk.
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Acked-by: NGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: NPierre Ossman <pierre@ossman.eu>
      5fe23c7f
  17. 21 6月, 2009 2 次提交
  18. 20 6月, 2009 1 次提交