1. 18 Feb, 2009 21 commits
    • KAMEZAWA Hiroyuki's avatar
      mm: fix memmap init for handling memory hole · cc2559bc
      KAMEZAWA Hiroyuki authored
      Now, early_pfn_in_nid(PFN, NID) may returns false if PFN is a hole.
      and memmap initialization was not done. This was a trouble for
      sparc boot.
      
      To fix this, the PFN should be initialized and marked as PG_reserved.
      This patch changes early_pfn_in_nid() return true if PFN is a hole.
      Signed-off-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Reported-by: default avatarDavid Miller <davem@davemlloft.net>
      Tested-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x, 2.6.27.x, 2.6.28.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cc2559bc
    • KAMEZAWA Hiroyuki's avatar
      mm: clean up for early_pfn_to_nid() · f2dbcfa7
      KAMEZAWA Hiroyuki authored
      What's happening is that the assertion in mm/page_alloc.c:move_freepages()
      is triggering:
      
      	BUG_ON(page_zone(start_page) != page_zone(end_page));
      
      Once I knew this is what was happening, I added some annotations:
      
      	if (unlikely(page_zone(start_page) != page_zone(end_page))) {
      		printk(KERN_ERR "move_freepages: Bogus zones: "
      		       "start_page[%p] end_page[%p] zone[%p]\n",
      		       start_page, end_page, zone);
      		printk(KERN_ERR "move_freepages: "
      		       "start_zone[%p] end_zone[%p]\n",
      		       page_zone(start_page), page_zone(end_page));
      		printk(KERN_ERR "move_freepages: "
      		       "start_pfn[0x%lx] end_pfn[0x%lx]\n",
      		       page_to_pfn(start_page), page_to_pfn(end_page));
      		printk(KERN_ERR "move_freepages: "
      		       "start_nid[%d] end_nid[%d]\n",
      		       page_to_nid(start_page), page_to_nid(end_page));
       ...
      
      And here's what I got:
      
      	move_freepages: Bogus zones: start_page[2207d0000] end_page[2207dffc0] zone[fffff8103effcb00]
      	move_freepages: start_zone[fffff8103effcb00] end_zone[fffff8003fffeb00]
      	move_freepages: start_pfn[0x81f600] end_pfn[0x81f7ff]
      	move_freepages: start_nid[1] end_nid[0]
      
      My memory layout on this box is:
      
      [    0.000000] Zone PFN ranges:
      [    0.000000]   Normal   0x00000000 -> 0x0081ff5d
      [    0.000000] Movable zone start PFN for each node
      [    0.000000] early_node_map[8] active PFN ranges
      [    0.000000]     0: 0x00000000 -> 0x00020000
      [    0.000000]     1: 0x00800000 -> 0x0081f7ff
      [    0.000000]     1: 0x0081f800 -> 0x0081fe50
      [    0.000000]     1: 0x0081fed1 -> 0x0081fed8
      [    0.000000]     1: 0x0081feda -> 0x0081fedb
      [    0.000000]     1: 0x0081fedd -> 0x0081fee5
      [    0.000000]     1: 0x0081fee7 -> 0x0081ff51
      [    0.000000]     1: 0x0081ff59 -> 0x0081ff5d
      
      So it's a block move in that 0x81f600-->0x81f7ff region which triggers
      the problem.
      
      This patch:
      
      Declaration of early_pfn_to_nid() is scattered over per-arch include
      files, and it seems it's complicated to know when the declaration is used.
       I think it makes fix-for-memmap-init not easy.
      
      This patch moves all declaration to include/linux/mm.h
      
      After this,
        if !CONFIG_NODES_POPULATES_NODE_MAP && !CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
           -> Use static definition in include/linux/mm.h
        else if !CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
           -> Use generic definition in mm/page_alloc.c
        else
           -> per-arch back end function will be called.
      Signed-off-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Tested-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Reported-by: default avatarDavid Miller <davem@davemlloft.net>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x, 2.6.27.x, 2.6.28.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f2dbcfa7
    • Peter Zijlstra's avatar
      fs/super.c: add lockdep annotation to s_umount · ada723dc
      Peter Zijlstra authored
      Li Zefan said:
      
      Thread 1:
        for ((; ;))
        {
            mount -t cpuset xxx /mnt > /dev/null 2>&1
            cat /mnt/cpus > /dev/null 2>&1
            umount /mnt > /dev/null 2>&1
        }
      
      Thread 2:
        for ((; ;))
        {
            mount -t cpuset xxx /mnt > /dev/null 2>&1
            umount /mnt > /dev/null 2>&1
        }
      
      (Note: It is irrelevant which cgroup subsys is used.)
      
      After a while a lockdep warning showed up:
      
      =============================================
      [ INFO: possible recursive locking detected ]
      2.6.28 #479
      ---------------------------------------------
      mount/13554 is trying to acquire lock:
       (&type->s_umount_key#19){--..}, at: [<c049d888>] sget+0x5e/0x321
      
      but task is already holding lock:
       (&type->s_umount_key#19){--..}, at: [<c049da0c>] sget+0x1e2/0x321
      
      other info that might help us debug this:
      1 lock held by mount/13554:
       #0:  (&type->s_umount_key#19){--..}, at: [<c049da0c>] sget+0x1e2/0x321
      
      stack backtrace:
      Pid: 13554, comm: mount Not tainted 2.6.28-mc #479
      Call Trace:
       [<c044ad2e>] validate_chain+0x4c6/0xbbd
       [<c044ba9b>] __lock_acquire+0x676/0x700
       [<c044bb82>] lock_acquire+0x5d/0x7a
       [<c049d888>] ? sget+0x5e/0x321
       [<c061b9b8>] down_write+0x34/0x50
       [<c049d888>] ? sget+0x5e/0x321
       [<c049d888>] sget+0x5e/0x321
       [<c045a2e7>] ? cgroup_set_super+0x0/0x3e
       [<c045959f>] ? cgroup_test_super+0x0/0x2f
       [<c045bcea>] cgroup_get_sb+0x98/0x2e7
       [<c045cfb6>] cpuset_get_sb+0x4a/0x5f
       [<c049dfa4>] vfs_kern_mount+0x40/0x7b
       [<c049e02d>] do_kern_mount+0x37/0xbf
       [<c04af4a0>] do_mount+0x5c3/0x61a
       [<c04addd2>] ? copy_mount_options+0x2c/0x111
       [<c04af560>] sys_mount+0x69/0xa0
       [<c0403251>] sysenter_do_call+0x12/0x31
      
      The cause is after alloc_super() and then retry, an old entry in list
      fs_supers is found, so grab_super(old) is called, but both functions hold
      s_umount lock:
      
      struct super_block *sget(...)
      {
      	...
      retry:
      	spin_lock(&sb_lock);
      	if (test) {
      		list_for_each_entry(old, &type->fs_supers, s_instances) {
      			if (!test(old, data))
      				continue;
      			if (!grab_super(old))  <--- 2nd: down_write(&old->s_umount);
      				goto retry;
      			if (s)
      				destroy_super(s);
      			return old;
      		}
      	}
      	if (!s) {
      		spin_unlock(&sb_lock);
      		s = alloc_super(type);   <--- 1th: down_write(&s->s_umount)
      		if (!s)
      			return ERR_PTR(-ENOMEM);
      		goto retry;
      	}
      	...
      }
      
      It seems like a false positive, and seems like VFS but not cgroup needs to
      be fixed.
      
      Peter said:
      
      We can simply put the new s_umount instance in a but lockdep doesn't
      particularly cares about subclass order.
      
      If there's any issue with the callers of sget() assuming the s_umount lock
      being of sublcass 0, then there is another annotation we can use to fix
      that, but lets not bother with that if this is sufficient.
      
      Addresses http://bugzilla.kernel.org/show_bug.cgi?id=12673Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Tested-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Reported-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Paul Menage <menage@google.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ada723dc
    • Atsushi Nemoto's avatar
      atmel_serial might lose modem status change · 27c0c8e5
      Atsushi Nemoto authored
      I found a problem of handling of modem status of atmel_serial driver.
      
      With the commit 1ecc26 ("atmel_serial: split the interrupt handler"),
      handling of modem status signal was splitted into two parts.  The
      atmel_tasklet_func() compares new status with irq_status_prev, but
      irq_status_prev is not correct if signal status was changed while the port
      is closed.
      
      Here is a sequence to cause problem:
      
      1. Remote side sets CTS (and DSR).
      2. Local side close the port.
      3. Local side clears RTS and DTR.
      4. Remote side clears CTS and DSR.
      5. Local side reopen the port.  hw_stopped becomes 1.
      6. Local side sets RTS and DTR.
      7. Remote side sets CTS and DSR.
      
      Then CTS change interrupt can be received, but since CTS bit in
      irq_status_prev and new status is same, uart_handle_cts_change() will not
      be called (so hw_stopped will not be cleared, i.e.  cannot send any data).
      
      I suppose irq_status_prev should be initialized at somewhere in open
      sequence.
      
      Itai Levi pointed out that we need to initialize atmel_port->irq_status
      as well here. His analysis is as follows:
      
      > Regarding the second part of the patch (which resets irq_status_prev),
      > it turns out that both versions of the patch (mine and Atsushi's)
      > still leave enough room for faulty behavior when opening the port.
      >
      > This is because we are not resetting both irq_status_prev and
      > irq_status in atmel_startup() to CSR, which leads faulty behavior in
      > the following sequences:
      >
      > First case:
      > 1. closing the port while CTS line = 1 (TX not allowed)
      > 2. setting CTS line = 0 (TX allowed)
      > 3. opening the port
      > 4. transmitting one char
      > 5. Cannot transmit more chars, although CTS line is 0
      >
      > Second case:
      > 1. closing the port while CTS line = 0 (TX allowed)
      > 2. setting CTS line = 1 (TX not allowed)
      > 3. opening the port
      > 4. receiving some chars
      > 5. Now we can transmit, although CTS line is 1
      >
      > This reason for this is that the tasklet is scheduled as a result of
      > TX or RX interrupts (not a status change!), in steps 4 above. Inside
      > the tasklet, the atmel_port->irq_status (which holds the value from
      > the previous session) is compared to atmel_port->irq_status_prev.
      > Hence, a status-change of the CTS line is faultily detected.
      >
      > Both cases were verified on 9260 hardware.
      
      [haavard.skinnemoen@atmel.com: folded with patch from Itai Levi]
      Signed-off-by: default avatarAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Signed-off-by: default avatarHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Cc: Remy Bohmer <linux@bohmer.net>
      Cc: Marc Pignat <marc.pignat@hevs.ch>
      Cc: Itai Levi <itai.levi.devel@gmail.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      27c0c8e5
    • Dan Williams's avatar
      atmel-mci: fix initialization of dma slave data · 287d8592
      Dan Williams authored
      The conversion of atmel-mci to dma_request_channel missed the
      initialization of the channel dma_slave information.  The filter_fn passed
      to dma_request_channel is responsible for initializing the channel's
      private data.  This implementation has the additional benefit of enabling
      a generic client-channel data passing mechanism.
      Reviewed-by: default avatarAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Acked-by: default avatarHaavard Skinnemoen <hskinnemoen@atmel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      287d8592
    • Giuseppe Bilotta's avatar
      lis3lv02d: add axes knowledge of HP Pavilion dv5 models · 9ccf3b5e
      Giuseppe Bilotta authored
      Add support for HP Pavilion dv5.
      
      Since Intel-based models have an inverted x axis, while AMD-based models
      have an inverted y axis, we introduce a new macro that special-cases axis
      orientation based on two DMI entries: HP dv5 axis configuration is then
      based on both the PRODUCT and BOARD name.
      Signed-off-by: default avatarGiuseppe Bilotta <giuseppe.bilotta@gmail.com>
      Cc: Eric Piel <Eric.Piel@tremplin-utc.net>
      Cc: Pavel Machek <pavel@suse.cz>
      Tested-by: default avatarPalatis Tseng <palatis@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9ccf3b5e
    • Giuseppe Bilotta's avatar
      lis3lv02d: support both one- and two-byte sensors · 137bad32
      Giuseppe Bilotta authored
      Sensors responding with 0x3B to WHO_AM_I only have one data register per
      direction, thus returning a signed byte from the position which is
      occupied by the MSB in sensors responding with 0x3A.
      
      Since multiple sensors share the reply to WHO_AM_I, we rename the defines
      to better indicate what they identify (family of single and double
      precision sensors).
      
      We support both kind of sensors by checking for the sensor type on init
      and defining appropriate data-access routines and sensor limits (for the
      joystick) depending on what we find.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: default avatarGiuseppe Bilotta <giuseppe.bilotta@gmail.com>
      Acked-by: default avatarEric Piel <Eric.Piel@tremplin-utc.net>
      Cc: Pavel Machek <pavel@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      137bad32
    • Pavel Machek's avatar
      hp accelerometer: add freefall detection · ef2cfc79
      Pavel Machek authored
      This adds freefall handling to hp_accel driver.  According to HP, it
      should just work, without us having to set the chip up by hand.
      
      hpfall.c is example .c program that parks the disk when accelerometer
      detects free fall.  It should work; for now, it uses fixed 20seconds
      protection period.
      Signed-off-by: default avatarPavel Machek <pavel@suse.cz>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Éric Piel <eric.piel@tremplin-utc.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ef2cfc79
    • Alexey Dobriyan's avatar
      eeepc: should depend on INPUT · 3a5093ee
      Alexey Dobriyan authored
      Otherwise with INPUT=m, EEEPC_LAPTOP=y one gets
      
      drivers/built-in.o: In function `input_sync':
      eeepc-laptop.c:(.text+0x18ce51): undefined reference to `input_event'
      drivers/built-in.o: In function `input_report_key':
      eeepc-laptop.c:(.text+0x18ce73): undefined reference to `input_event'
      drivers/built-in.o: In function `eeepc_hotk_check':
      eeepc-laptop.c:(.text+0x18d05f): undefined reference to `input_allocate_device'
      eeepc-laptop.c:(.text+0x18d10f): undefined reference to `input_register_device'
      eeepc-laptop.c:(.text+0x18d131): undefined reference to `input_free_device'
      drivers/built-in.o: In function `eeepc_backlight_exit':
      eeepc-laptop.c:(.text+0x18d546): undefined reference to `input_unregister_device'
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3a5093ee
    • Rafael J. Wysocki's avatar
      pm: fix build for CONFIG_PM unset · 42f5e039
      Rafael J. Wysocki authored
      Compilation of kprobes.c with CONFIG_PM unset is broken due to some broken
      config dependncies.  Fix that.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Reported-by: default avatarIngo Molnar <mingo@elte.hu>
      Tested-by: default avatarMasami Hiramatsu <mhiramat@redhat.com>
      Cc: Len Brown <lenb@kernel.org>
      Acked-by: default avatarPavel Machek <pavel@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      42f5e039
    • Li Zefan's avatar
      cgroups: fix possible use after free · 67e055d1
      Li Zefan authored
      In cgroup_kill_sb(), root is freed before sb is detached from the list, so
      another sget() may find this sb and call cgroup_test_super(), which will
      access the root that has been freed.
      Reported-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Acked-by: default avatarPaul Menage <menage@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      67e055d1
    • Nick Piggin's avatar
      mm: task dirty accounting fix · 1cf6e7d8
      Nick Piggin authored
      YAMAMOTO-san noticed that task_dirty_inc doesn't seem to be called properly for
      cases where set_page_dirty is not used to dirty a page (eg. mark_buffer_dirty).
      
      Additionally, there is some inconsistency about when task_dirty_inc is
      called.  It is used for dirty balancing, however it even gets called for
      __set_page_dirty_no_writeback.
      
      So rather than increment it in a set_page_dirty wrapper, move it down to
      exactly where the dirty page accounting stats are incremented.
      
      Cc: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
      Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1cf6e7d8
    • Davide Libenzi's avatar
      timerfd: add flags check · 610d18f4
      Davide Libenzi authored
      As requested by Michael, add a missing check for valid flags in
      timerfd_settime(), and make it return EINVAL in case some extra bits are
      set.
      
      Michael said:
      If this is to be any use to userland apps that want to check flag
      support (perhaps it is too late already), then the sooner we get it
      into the kernel the better: 2.6.29 would be good; earlier stables as
      well would be even better.
      
      [akpm@linux-foundation.org: remove unused TFD_FLAGS_SET]
      Acked-by: default avatarMichael Kerrisk <mtk.manpages@gmail.com>
      Signed-off-by: default avatarDavide Libenzi <davidel@xmailserver.org>
      Cc: <stable@kernel.org>		[2.6.27.x, 2.6.28.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      610d18f4
    • Pavel Machek's avatar
      Pavel has moved · ef35ce23
      Pavel Machek authored
      My @suse.cz address will stop working some day, so put working one into
      MAINTAINERS/CREDITS.  It would be cool to get this to 2.6.29...  it should
      not really break anything.
      Signed-off-by: default avatarPavel Machek <pavel@ucw.cz>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ef35ce23
    • Eric Biederman's avatar
      seq_file: properly cope with pread · 8f19d472
      Eric Biederman authored
      Currently seq_read assumes that the offset passed to it is always the
      offset it passed to user space.  In the case pread this assumption is
      broken and we do the wrong thing when presented with pread.
      
      To solve this I introduce an offset cache inside of struct seq_file so we
      know where our logical file position is.  Then in seq_read if we try to
      read from another offset we reset our data structures and attempt to go to
      the offset user space wanted.
      
      [akpm@linux-foundation.org: restore FMODE_PWRITE]
      [pjt@google.com: seq_open needs its fmode opened up to take advantage of this]
      Signed-off-by: default avatarEric Biederman <ebiederm@xmission.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Paul Turner <pjt@google.com>
      Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x, 2.6.27.x, 2.6.28.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8f19d472
    • Paul Turner's avatar
      vfs: separate FMODE_PREAD/FMODE_PWRITE into separate flags · 55ec8217
      Paul Turner authored
      Separate FMODE_PREAD and FMODE_PWRITE into separate flags to reflect the
      reality that the read and write paths may have independent restrictions.
      
      A git grep verifies that these flags are always cleared together so this
      new behavior will only apply to interfaces that change to clear flags
      individually.
      
      This is required for "seq_file: properly cope with pread", a post-2.6.25
      regression fix.
      
      [akpm@linux-foundation.org: add comment]
      Signed-off-by: default avatarPaul Turner <pjt@google.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc:  Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x, 2.6.27.x, 2.6.28.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      55ec8217
    • Li Zefan's avatar
      cgroups: update documentation about css_set hash table · b851ee79
      Li Zefan authored
      The css_set hash table was introduced in 2.6.26, so update the
      documentation accordingly.
      Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Acked-by: default avatarPaul Menage <menage@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b851ee79
    • Ed Cashin's avatar
      aoe: ignore vendor extension AoE responses · b6d6c517
      Ed Cashin authored
      The Welland ME-747K-SI AoE target generates unsolicited AoE responses that
      are marked as vendor extensions.  Instead of ignoring these packets, the
      aoe driver was generating kernel messages for each unrecognized response
      received.  This patch corrects the behavior.
      Signed-off-by: default avatarEd Cashin <ecashin@coraid.com>
      Reported-by: <karaluh@karaluh.pl>
      Tested-by: <karaluh@karaluh.pl>
      Cc: <stable@kernel.org>
      Cc: Alex Buell <alex.buell@munted.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b6d6c517
    • Benjamin Herrenschmidt's avatar
      vmalloc: add __get_vm_area_caller() · c2968612
      Benjamin Herrenschmidt authored
      We have get_vm_area_caller() and __get_vm_area() but not
      __get_vm_area_caller()
      
      On powerpc, I use __get_vm_area() to separate the ranges of addresses
      given to vmalloc vs.  ioremap (various good reasons for that) so in order
      to be able to implement the new caller tracking in /proc/vmallocinfo, I
      need a "_caller" variant of it.
      
      (akpm: needed for ongoing powerpc development, so merge it early)
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Reviewed-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c2968612
    • Zlatko Calusic's avatar
    • Rafael J. Wysocki's avatar
      USB/PCI: Fix resume breakage of controllers behind cardbus bridges · 3494252d
      Rafael J. Wysocki authored
      If a USB PCI controller is behind a cardbus bridge, we are trying to
      restore its configuration registers too early, before the cardbus
      bridge is operational.  To fix this, call pci_restore_state() from
      usb_hcd_pci_resume() and remove usb_hcd_pci_resume_early() which is
      no longer necessary (the configuration spaces of USB controllers that
      are not behind cardbus bridges will be restored by the PCI PM core
      with interrupts disabled anyway).
      
      This patch fixes the regression from 2.6.28 tracked as
      http://bugzilla.kernel.org/show_bug.cgi?id=12659
      
      [ Side note: the proper long-term fix is probably to just force the
        unplug event at suspend time instead of doing a plug/unplug at resume
        time, but this patch is fine regardless  - Linus ]
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Reported-by: default avatarMiles Lane <miles.lane@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3494252d
  2. 17 Feb, 2009 19 commits