1. 06 6月, 2009 2 次提交
    • S
      pata_efar: fix PIO2 underclocking · 5f33b3bc
      Sergei Shtylyov 提交于
      Fix the PIO mode 2 using mode 0 timings -- this driver should enable the
      fast timing bank starting with PIO2, just like the PIIX/ICH drivers do.
      Also, fix/rephrase some comments while at it.
      Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      5f33b3bc
    • J
      pata_legacy: wait for async probing · 45bc955b
      James Bottomley 提交于
      The basic problem here that pata_legacy attaches the host, sees if it found
      any devices and detaches it if none were found.  With async probing, it's not
      waiting until discovery is finished before deciding it has no devices and
      trying the detach leading to this warning:
      
      ata1: PATA max PIO4 cmd 0x1f0 ctl 0x3f6 irq 14
      ------------[ cut here ]------------
      WARNING: at drivers/ata/libata-core.c:6222 ata_host_detach+0x75/0x90()
      Modules linked in:
      Pid: 1, comm: swapper Not tainted 2.6.30-rc7 #1
      Call Trace:
       [<c01fbb05>] ? ata_host_detach+0x75/0x90
       [<c01fbb05>] ? ata_host_detach+0x75/0x90
       [<c01139b5>] ? warn_slowpath_common+0x45/0x80
       [<c01139fa>] ? warn_slowpath_null+0xa/0x10
       [<c01fbb05>] ? ata_host_detach+0x75/0x90
       [<c02f40e0>] ? legacy_init+0x44e/0x87f
       [<c02f3c92>] ? legacy_init+0x0/0x87f
       [<c0101021>] ? _stext+0x21/0x140
       [<c01890ff>] ? proc_register+0x2f/0x190
       [<c018938c>] ? create_proc_entry+0x5c/0xc0
       [<c0135ebe>] ? register_irq_proc+0x6e/0x90
       [<c02e6484>] ? kernel_init+0x6e/0xbf
       [<c02e6416>] ? kernel_init+0x0/0xbf
       [<c01031d7>] ? kernel_thread_helper+0x7/0x10
      ---[ end trace ef1ee36e873ae3a0 ]---
      
      Because it detaches before the probe is complete.
      
      One way to fix it would be to put an async_synchronize_full() before looking
      for devices, which this patch does.  A better way might be to separate libata
      into its own domain and only wait for that.
      Reported-by: NMikael Pettersson <mikpe@it.uu.se>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      45bc955b
  2. 05 6月, 2009 1 次提交
    • S
      drivers/char/mem.c: avoid OOM lockup during large reads from /dev/zero · 730c586a
      Salman Qazi 提交于
      While running 20 parallel instances of dd as follows:
      
        #!/bin/bash
        for i in `seq 1 20`; do
                 dd if=/dev/zero of=/export/hda3/dd_$i bs=1073741824 count=1 &
        done
        wait
      
      on a 16G machine, we noticed that rather than just killing the processes,
      the entire kernel went down.  Stracing dd reveals that it first does an
      mmap2, which makes 1GB worth of zero page mappings.  Then it performs a
      read on those pages from /dev/zero, and finally it performs a write.
      
      The machine died during the reads.  Looking at the code, it was noticed
      that /dev/zero's read operation had been changed by
      557ed1fa ("remove ZERO_PAGE") from giving
      zero page mappings to actually zeroing the page.
      
      The zeroing of the pages causes physical pages to be allocated to the
      process.  But, when the process exhausts all the memory that it can, the
      kernel cannot kill it, as it is still in the kernel mode allocating more
      memory.  Consequently, the kernel eventually crashes.
      
      To fix this, I propose that when a fatal signal is pending during
      /dev/zero read operation, we simply return and let the user process die.
      Signed-off-by: NSalman Qazi <sqazi@google.com>
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      [ Modified error return and comment trivially.  - Linus]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      730c586a
  3. 04 6月, 2009 9 次提交
  4. 03 6月, 2009 2 次提交
  5. 02 6月, 2009 2 次提交
    • N
      e1000: add missing length check to e1000 receive routine · ea30e119
      Neil Horman 提交于
      	Patch to fix bad length checking in e1000.  E1000 by default does two
      things:
      
      1) Spans rx descriptors for packets that don't fit into 1 skb on recieve
      2) Strips the crc from a frame by subtracting 4 bytes from the length prior to
      doing an skb_put
      
      Since the e1000 driver isn't written to support receiving packets that span
      multiple rx buffers, it checks the End of Packet bit of every frame, and
      discards it if its not set.  This places us in a situation where, if we have a
      spanning packet, the first part is discarded, but the second part is not (since
      it is the end of packet, and it passes the EOP bit test).  If the second part of
      the frame is small (4 bytes or less), we subtract 4 from it to remove its crc,
      underflow the length, and wind up in skb_over_panic, when we try to skb_put a
      huge number of bytes into the skb.  This amounts to a remote DOS attack through
      careful selection of frame size in relation to interface MTU.  The fix for this
      is already in the e1000e driver, as well as the e1000 sourceforge driver, but no
      one ever pushed it to e1000.  This is lifted straight from e1000e, and prevents
      small frames from causing the underflow described above
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Tested-by: NAndy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ea30e119
    • E
      forcedeth: add phy_power_down parameter, leave phy powered up by default (v2) · 5a9a8e32
      Ed Swierk 提交于
      Add a phy_power_down parameter to forcedeth: set to 1 to power down the
      phy and disable the link when an interface goes down; set to 0 to always
      leave the phy powered up.
      
      The phy power state persists across reboots; Windows, some BIOSes, and
      older versions of Linux don't bother to power up the phy again, forcing
      users to remove all power to get the interface working (see
      http://bugzilla.kernel.org/show_bug.cgi?id=13072).  Leaving the phy
      powered on is the safest default behavior.  Users accustomed to seeing
      the link state reflect the interface state and/or wanting to minimize
      power consumption can set phy_power_down=1 if compatibility with other
      OSes is not an issue.
      Signed-off-by: NEd Swierk <eswierk@aristanetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a9a8e32
  6. 01 6月, 2009 2 次提交
  7. 31 5月, 2009 1 次提交
  8. 30 5月, 2009 8 次提交
  9. 29 5月, 2009 13 次提交