1. 19 2月, 2009 21 次提交
    • P
      floppy: request and release only the ports we actually use · 5a74db06
      Philippe De Muyter 提交于
      The floppy driver requests an I/O port it doesn't need, and sometimes this
      causes a conflict with a motherboard device reported by PNPBIOS.
      
      This patch makes the floppy driver request and release only the ports it
      actually uses.  It also factors out the request/release stuff and the
      io-ports list so they're all in one place now.
      
      The current floppy driver uses only these ports:
      
          0x3f2 (FD_DOR)
          0x3f4 (FD_STATUS)
          0x3f5 (FD_DATA)
          0x3f7 (FD_DCR/FD_DIR)
      
      but it requests 0x3f2-0x3f5 and 0x3f7, which includes the unused port
      0x3f3.
      
      Some BIOSes report 0x3f3 as a motherboard resource.  The PNP system driver
      reserves that, which causes a conflict when the floppy driver requests
      0x3f2-0x3f5 later.
      
      Philippe reported that this conflict broke the floppy driver between
      2.6.11 and 2.6.22.  His PNPBIOS reports these devices:
      
          $ cat 00:07/id 00:07/resources	# motherboard device
          PNP0c02
          state = active
          io 0x80-0x80
          io 0x10-0x1f
          io 0x22-0x3f
          io 0x44-0x5f
          io 0x90-0x9f
          io 0xa2-0xbf
          io 0x3f0-0x3f1
          io 0x3f3-0x3f3
      
          $ cat 00:03/id 00:03/resources	# floppy device
          PNP0700
          state = active
          io 0x3f4-0x3f5
          io 0x3f2-0x3f2
      
      Reference:
          http://lkml.org/lkml/2009/1/31/162Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NPhilippe De Muyter <phdm@macqel.be>
      Reported-by: NPhilippe De Muyter <phdm@macqel.be>
      Tested-by: NPhilippe De Muyter <phdm@macqel.be>
      Cc: Adam M Belay <abelay@mit.edu>
      Cc: Robert Hancock <hancockrwd@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5a74db06
    • A
      jsm: additional device support · ffa7525c
      Adam Lackorzynski 提交于
      I have a Digi Neo 8 PCI card (114f:00b1) Serial controller: Digi
      International Digi Neo 8 (rev 05)
      
      that works with the jsm driver after using the following patch.
      Signed-off-by: NAdam Lackorzynski <adam@os.inf.tu-dresden.de>
      Cc: Scott H Kilau <Scott_Kilau@digi.com>
      Cc: Wendy Xiong <wendyx@us.ibm.com>
      Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ffa7525c
    • K
      mm: fix memmap init for handling memory hole · cc2559bc
      KAMEZAWA Hiroyuki 提交于
      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: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Reported-by: NDavid Miller <davem@davemlloft.net>
      Tested-by: NKOSAKI 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cc2559bc
    • K
      mm: clean up for early_pfn_to_nid() · f2dbcfa7
      KAMEZAWA Hiroyuki 提交于
      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: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Tested-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Reported-by: NDavid 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f2dbcfa7
    • P
      fs/super.c: add lockdep annotation to s_umount · ada723dc
      Peter Zijlstra 提交于
      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: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Tested-by: NLi Zefan <lizf@cn.fujitsu.com>
      Reported-by: NLi 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ada723dc
    • A
      atmel_serial might lose modem status change · 27c0c8e5
      Atsushi Nemoto 提交于
      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: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Signed-off-by: NHaavard 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      27c0c8e5
    • D
      atmel-mci: fix initialization of dma slave data · 287d8592
      Dan Williams 提交于
      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: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Acked-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      287d8592
    • G
      lis3lv02d: add axes knowledge of HP Pavilion dv5 models · 9ccf3b5e
      Giuseppe Bilotta 提交于
      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: NGiuseppe Bilotta <giuseppe.bilotta@gmail.com>
      Cc: Eric Piel <Eric.Piel@tremplin-utc.net>
      Cc: Pavel Machek <pavel@suse.cz>
      Tested-by: NPalatis Tseng <palatis@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9ccf3b5e
    • G
      lis3lv02d: support both one- and two-byte sensors · 137bad32
      Giuseppe Bilotta 提交于
      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: NGiuseppe Bilotta <giuseppe.bilotta@gmail.com>
      Acked-by: NEric Piel <Eric.Piel@tremplin-utc.net>
      Cc: Pavel Machek <pavel@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      137bad32
    • P
      hp accelerometer: add freefall detection · ef2cfc79
      Pavel Machek 提交于
      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: NPavel Machek <pavel@suse.cz>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Éric Piel <eric.piel@tremplin-utc.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ef2cfc79
    • A
      eeepc: should depend on INPUT · 3a5093ee
      Alexey Dobriyan 提交于
      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: NAlexey Dobriyan <adobriyan@gmail.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3a5093ee
    • R
      pm: fix build for CONFIG_PM unset · 42f5e039
      Rafael J. Wysocki 提交于
      Compilation of kprobes.c with CONFIG_PM unset is broken due to some broken
      config dependncies.  Fix that.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Tested-by: NMasami Hiramatsu <mhiramat@redhat.com>
      Cc: Len Brown <lenb@kernel.org>
      Acked-by: NPavel Machek <pavel@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      42f5e039
    • L
      cgroups: fix possible use after free · 67e055d1
      Li Zefan 提交于
      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: NAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
      Acked-by: NPaul Menage <menage@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      67e055d1
    • N
      mm: task dirty accounting fix · 1cf6e7d8
      Nick Piggin 提交于
      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: NNick Piggin <npiggin@suse.de>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1cf6e7d8
    • D
      timerfd: add flags check · 610d18f4
      Davide Libenzi 提交于
      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: NMichael Kerrisk <mtk.manpages@gmail.com>
      Signed-off-by: NDavide Libenzi <davidel@xmailserver.org>
      Cc: <stable@kernel.org>		[2.6.27.x, 2.6.28.x]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      610d18f4
    • P
      Pavel has moved · ef35ce23
      Pavel Machek 提交于
      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: NPavel Machek <pavel@ucw.cz>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ef35ce23
    • E
      seq_file: properly cope with pread · 8f19d472
      Eric Biederman 提交于
      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: NEric 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8f19d472
    • P
      vfs: separate FMODE_PREAD/FMODE_PWRITE into separate flags · 55ec8217
      Paul Turner 提交于
      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: NPaul 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      55ec8217
    • L
      cgroups: update documentation about css_set hash table · b851ee79
      Li Zefan 提交于
      The css_set hash table was introduced in 2.6.26, so update the
      documentation accordingly.
      Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
      Acked-by: NPaul Menage <menage@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b851ee79
    • E
      aoe: ignore vendor extension AoE responses · b6d6c517
      Ed Cashin 提交于
      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: NEd 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b6d6c517
    • B
      vmalloc: add __get_vm_area_caller() · c2968612
      Benjamin Herrenschmidt 提交于
      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: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Reviewed-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c2968612
  2. 18 2月, 2009 19 次提交