1. 08 8月, 2009 4 次提交
    • P
      bzip2/lzma/gzip: fix comments describing decompressor API · daeb6b6f
      Phillip Lougher 提交于
      Fix and improve comments in decompress/generic.h that describe the
      decompressor API.  Also remove an unused definition, and rename INBUF_LEN
      in lib/decompress_inflate.c to conform to bzip2/lzma naming.
      Signed-off-by: NPhillip Lougher <phillip@lougher.demon.co.uk>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      daeb6b6f
    • K
      mm: make set_mempolicy(MPOL_INTERLEAV) N_HIGH_MEMORY aware · 4bfc4495
      KAMEZAWA Hiroyuki 提交于
      At first, init_task's mems_allowed is initialized as this.
       init_task->mems_allowed == node_state[N_POSSIBLE]
      
      And cpuset's top_cpuset mask is initialized as this
       top_cpuset->mems_allowed = node_state[N_HIGH_MEMORY]
      
      Before 2.6.29:
      policy's mems_allowed is initialized as this.
      
        1. update tasks->mems_allowed by its cpuset->mems_allowed.
        2. policy->mems_allowed = nodes_and(tasks->mems_allowed, user's mask)
      
      Updating task's mems_allowed in reference to top_cpuset's one.
      cpuset's mems_allowed is aware of N_HIGH_MEMORY, always.
      
      In 2.6.30: After commit 58568d2a
      ("cpuset,mm: update tasks' mems_allowed in time"), policy's mems_allowed
      is initialized as this.
      
        1. policy->mems_allowd = nodes_and(task->mems_allowed, user's mask)
      
      Here, if task is in top_cpuset, task->mems_allowed is not updated from
      init's one.  Assume user excutes command as #numactrl --interleave=all
      ,....
      
        policy->mems_allowd = nodes_and(N_POSSIBLE, ALL_SET_MASK)
      
      Then, policy's mems_allowd can includes a possible node, which has no pgdat.
      
      MPOL's INTERLEAVE just scans nodemask of task->mems_allowd and access this
      directly.
      
        NODE_DATA(nid)->zonelist even if NODE_DATA(nid)==NULL
      
      Then, what's we need is making policy->mems_allowed be aware of
      N_HIGH_MEMORY.  This patch does that.  But to do so, extra nodemask will
      be on statck.  Because I know cpumask has a new interface of
      CPUMASK_ALLOC(), I added it to node.
      
      This patch stands on old behavior.  But I feel this fix itself is just a
      Band-Aid.  But to do fundametal fix, we have to take care of memory
      hotplug and it takes time.  (task->mems_allowd should be N_HIGH_MEMORY, I
      think.)
      
      mpol_set_nodemask() should be aware of N_HIGH_MEMORY and policy's nodemask
      should be includes only online nodes.
      
      In old behavior, this is guaranteed by frequent reference to cpuset's
      code.  Now, most of them are removed and mempolicy has to check it by
      itself.
      
      To do check, a few nodemask_t will be used for calculating nodemask.  But,
      size of nodemask_t can be big and it's not good to allocate them on stack.
      
      Now, cpumask_t has CPUMASK_ALLOC/FREE an easy code for get scratch area.
      NODEMASK_ALLOC/FREE shoudl be there.
      
      [akpm@linux-foundation.org: cleanups & tweaks]
      Tested-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Miao Xie <miaox@cn.fujitsu.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Paul Menage <menage@google.com>
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Cc: Yasunori Goto <y-goto@jp.fujitsu.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4bfc4495
    • C
      vfs: add __destroy_inode · 2e00c97e
      Christoph Hellwig 提交于
      When we want to tear down an inode that lost the add to the cache race
      in XFS we must not call into ->destroy_inode because that would delete
      the inode that won the race from the inode cache radix tree.
      
      This patch provides the __destroy_inode helper needed to fix this,
      the actual fix will be in th next patch.  As XFS was the only reason
      destroy_inode was exported we shift the export to the new __destroy_inode.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NEric Sandeen <sandeen@sandeen.net>
      2e00c97e
    • C
      vfs: fix inode_init_always calling convention · 54e34621
      Christoph Hellwig 提交于
      Currently inode_init_always calls into ->destroy_inode if the additional
      initialization fails.  That's not only counter-intuitive because
      inode_init_always did not allocate the inode structure, but in case of
      XFS it's actively harmful as ->destroy_inode might delete the inode from
      a radix-tree that has never been added.  This in turn might end up
      deleting the inode for the same inum that has been instanciated by
      another process and cause lots of cause subtile problems.
      
      Also in the case of re-initializing a reclaimable inode in XFS it would
      free an inode we still want to keep alive.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NEric Sandeen <sandeen@sandeen.net>
      54e34621
  2. 06 8月, 2009 2 次提交
  3. 05 8月, 2009 2 次提交
  4. 04 8月, 2009 3 次提交
    • A
      drm/radeon: add some new r7xx pci ids · 7320700d
      Alex Deucher 提交于
      Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      7320700d
    • L
      cfg80211: fix regression on beacon world roaming feature · 37184244
      Luis R. Rodriguez 提交于
      A regression was added through patch a4ed90d6:
      
      "cfg80211: respect API on orig_flags on channel for beacon hint"
      
      We did indeed respect _orig flags but the intention was not clearly
      stated in the commit log. This patch fixes firmware issues picked
      up by iwlwifi when we lift passive scan of beaconing restrictions
      on channels its EEPROM has been configured to always enable.
      
      By doing so though we also disallowed beacon hints on devices
      registering their wiphy with custom world regulatory domains
      enabled, this happens to be currently ath5k, ath9k and ar9170.
      The passive scan and beacon restrictions on those devices would
      never be lifted even if we did find a beacon and the hardware did
      support such enhancements when world roaming.
      
      Since Johannes indicates iwlwifi firmware cannot be changed to
      allow beacon hinting we set up a flag now to specifically allow
      drivers to disable beacon hints for devices which cannot use them.
      
      We enable the flag on iwlwifi to disable beacon hints and by default
      enable it for all other drivers. It should be noted beacon hints lift
      passive scan flags and beacon restrictions when we receive a beacon from
      an AP on any 5 GHz non-DFS channels, and channels 12-14 on the 2.4 GHz
      band. We don't bother with channels 1-11 as those channels are allowed
      world wide.
      
      This should fix world roaming for ath5k, ath9k and ar9170, thereby
      improving scan time when we receive the first beacon from any AP,
      and also enabling beaconing operation (AP/IBSS/Mesh) on cards which
      would otherwise not be allowed to do so. Drivers not using custom
      regulatory stuff (wiphy_apply_custom_regulatory()) were not affected
      by this as the orig_flags for the channels would have been cleared
      upon wiphy registration.
      
      I tested this with a world roaming ath5k card.
      
      Cc: Jouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      37184244
    • D
      bluetooth: rfcomm_init bug fix · af0d3b10
      Dave Young 提交于
      rfcomm tty may be used before rfcomm_tty_driver initilized,
      The problem is that now socket layer init before tty layer, if userspace
      program do socket callback right here then oops will happen.
      
      reporting in:
      http://marc.info/?l=linux-bluetooth&m=124404919324542&w=2
      
      make 3 changes:
      1. remove #ifdef in rfcomm/core.c,
      make it blank function when rfcomm tty not selected in rfcomm.h
      
      2. tune the rfcomm_init error patch to ensure
      tty driver initilized before rfcomm socket usage.
      
      3. remove __exit for rfcomm_cleanup_sockets
      because above change need call it in a __init function.
      Reported-by: NOliver Hartkopp <oliver@hartkopp.net>
      Tested-by: NOliver Hartkopp <oliver@hartkopp.net>
      Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      af0d3b10
  5. 03 8月, 2009 2 次提交
  6. 02 8月, 2009 1 次提交
    • P
      perf_counter: Full task tracing · 9f498cc5
      Peter Zijlstra 提交于
      In order to be able to distinguish between no samples due to
      inactivity and no samples due to task ended, Arjan asked for
      PERF_EVENT_EXIT events. This is useful to the boot delay
      instrumentation (bootchart) app.
      
      This patch changes the PERF_EVENT_FORK to be emitted on every
      clone, and adds PERF_EVENT_EXIT to be emitted on task exit,
      after the task's counters have been closed.
      
      This task tracing is controlled through: attr.comm || attr.mmap
      and through the new attr.task field.
      Suggested-by: NArjan van de Ven <arjan@linux.intel.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Anton Blanchard <anton@samba.org>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      [ cleaned up perf_counter.h a bit ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9f498cc5
  7. 01 8月, 2009 1 次提交
  8. 31 7月, 2009 4 次提交
  9. 30 7月, 2009 9 次提交
  10. 29 7月, 2009 2 次提交
    • D
      drm/radeon/kms: add initial colortiling support. · e024e110
      Dave Airlie 提交于
      This adds new set/get tiling interfaces where the pitch
      and macro/micro tiling enables can be set. Along with
      a flag to decide if this object should have a surface when mapped.
      
      The only thing we need to allocate with a mapped surface should be
      the frontbuffer. Note rotate scanout shouldn't require one, and
      back/depth shouldn't either, though mesa needs some fixes.
      
      It fixes the TTM interfaces along Thomas's suggestions, and I've tested
      the surface stealing code with two X servers and not seen any lockdep issues.
      
      I've stopped tiling the fbcon frontbuffer, as I don't see there being
      any advantage other than testing, I've left the testing commands in there,
      just flip the fb_tiled to true in radeon_fb.c
      
      Open: Can we integrate endian swapping in with this?
      
      Future features:
      texture tiling - need to relocate texture registers TXOFFSET* with tiling info.
      
      This also merges Michel's cleanup surfaces regs at init time patch
      even though it makes sense on its own, this patch really relies on it.
      
      Some PowerMac firmwares set up a tiling surface at the beginning of VRAM
      which messes us up otherwise.
      that patch is:
      Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      e024e110
    • T
      libata: accept late unlocking of HPA · 5920dadf
      Tejun Heo 提交于
      On certain configurations, HPA isn't or can't be unlocked during
      probing but it somehow ends up unlocked afterwards.  In the following
      thread, the problem can be reliably reproduced after resuming from
      STR.  The BIOS turns on HPA during boot but forgets to do it during
      resume.
      
        http://thread.gmane.org/gmane.linux.kernel/858310
      
      This patch updates libata revalidation such that it considers native
      n_sectors.  If the device size has increased to match native
      n_sectors, it's assumed that HPA has been unlocked involuntarily and
      the device is recognized as the same one.  This should be fairly safe
      while nicely working around the problem.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NChristof Warlich <christof@warlich.name>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      5920dadf
  11. 28 7月, 2009 3 次提交
  12. 27 7月, 2009 1 次提交
  13. 25 7月, 2009 1 次提交
  14. 24 7月, 2009 1 次提交
  15. 23 7月, 2009 2 次提交
    • A
      of/mdio: Add support function for Ethernet fixed-link property · 24c30dbb
      Anton Vorontsov 提交于
      Fixed-link support is broken for the ucc_eth, gianfar, and fs_enet
      device drivers.  The "OF MDIO rework" patches removed most of the
      support. Instead of re-adding fixed-link stuff to the drivers, this
      patch adds a support function for parsing the fixed-link property
      and obtaining a dummy phy to match.
      
      Note: the dummy phy handling in arch/powerpc is a bit of a hack and
      needs to be reworked.  This function is being added now to solve the
      regression in the Ethernet drivers, but it should be considered a
      temporary measure until the fixed link handling can be reworked.
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      24c30dbb
    • P
      perf_counter: PERF_SAMPLE_ID and inherited counters · 7f453c24
      Peter Zijlstra 提交于
      Anton noted that for inherited counters the counter-id as provided by
      PERF_SAMPLE_ID isn't mappable to the id found through PERF_RECORD_ID
      because each inherited counter gets its own id.
      
      His suggestion was to always return the parent counter id, since that
      is the primary counter id as exposed. However, these inherited
      counters have a unique identifier so that events like
      PERF_EVENT_PERIOD and PERF_EVENT_THROTTLE can be specific about which
      counter gets modified, which is important when trying to normalize the
      sample streams.
      
      This patch removes PERF_EVENT_PERIOD in favour of PERF_SAMPLE_PERIOD,
      which is more useful anyway, since changing periods became a lot more
      common than initially thought -- rendering PERF_EVENT_PERIOD the less
      useful solution (also, PERF_SAMPLE_PERIOD reports the more accurate
      value, since it reports the value used to trigger the overflow,
      whereas PERF_EVENT_PERIOD simply reports the requested period changed,
      which might only take effect on the next cycle).
      
      This still leaves us PERF_EVENT_THROTTLE to consider, but since that
      _should_ be a rare occurrence, and linking it to a primary id is the
      most useful bit to diagnose the problem, we introduce a
      PERF_SAMPLE_STREAM_ID, for those few cases where the full
      reconstruction is important.
      
      [Does change the ABI a little, but I see no other way out]
      Suggested-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1248095846.15751.8781.camel@twins>
      7f453c24
  16. 22 7月, 2009 2 次提交
    • P
      softirq: introduce tasklet_hrtimer infrastructure · 9ba5f005
      Peter Zijlstra 提交于
      commit ca109491 (hrtimer: removing all ur callback modes) moved all
      hrtimer callbacks into hard interrupt context when high resolution
      timers are active. That breaks code which relied on the assumption
      that the callback happens in softirq context.
      
      Provide a generic infrastructure which combines tasklets and hrtimers
      together to provide an in-softirq hrtimer experience.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: torvalds@linux-foundation.org
      Cc: kaber@trash.net
      Cc: David Miller <davem@davemloft.net>
      LKML-Reference: <1248265724.27058.1366.camel@twins>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      9ba5f005
    • E
      inotify: use GFP_NOFS under potential memory pressure · f44aebcc
      Eric Paris 提交于
      inotify can have a watchs removed under filesystem reclaim.
      
      =================================
      [ INFO: inconsistent lock state ]
      2.6.31-rc2 #16
      ---------------------------------
      inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.
      khubd/217 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (iprune_mutex){+.+.?.}, at: [<c10ba899>] invalidate_inodes+0x20/0xe3
      {IN-RECLAIM_FS-W} state was registered at:
        [<c10536ab>] __lock_acquire+0x2c9/0xac4
        [<c1053f45>] lock_acquire+0x9f/0xc2
        [<c1308872>] __mutex_lock_common+0x2d/0x323
        [<c1308c00>] mutex_lock_nested+0x2e/0x36
        [<c10ba6ff>] shrink_icache_memory+0x38/0x1b2
        [<c108bfb6>] shrink_slab+0xe2/0x13c
        [<c108c3e1>] kswapd+0x3d1/0x55d
        [<c10449b5>] kthread+0x66/0x6b
        [<c1003fdf>] kernel_thread_helper+0x7/0x10
        [<ffffffff>] 0xffffffff
      
      Two things are needed to fix this.  First we need a method to tell
      fsnotify_create_event() to use GFP_NOFS and second we need to stop using
      one global IN_IGNORED event and allocate them one at a time.  This solves
      current issues with multiple IN_IGNORED on a queue having tail drop
      problems and simplifies the allocations since we don't have to worry about
      two tasks opperating on the IGNORED event concurrently.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      f44aebcc