1. 21 6月, 2008 4 次提交
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/blackfin-2.6 · 55017923
      Linus Torvalds 提交于
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/blackfin-2.6:
        Blackfin Serial Driver: Use timer to poll CTS PIN instead of workqueue.
        Blackfin arch: fix typo error in bf548 serial header file
      55017923
    • L
      Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev · b4eea67a
      Linus Torvalds 提交于
      * 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
        ahci: sis can't do PMP
        ata_piix: add TECRA M4 to broken suspend list
        LIBATA: Add HAVE_PATA_PLATFORM to select PATA_PLATFORM driver
        sata_mv: warn on PIO with multiple DRQs
        sata_mv: enable async_notify for 60x1 Rev.C0 and higher
        libata: don't check whether to use DMA or not for no data commands
        ahci: jmb361 has only one port
      b4eea67a
    • L
      [watchdog] hpwdt: fix use of inline assembly · 1f6ef234
      Linus Torvalds 提交于
      The inline assembly in drivers/watchdog/hpwdt.c was incredibly broken,
      and included all the function prologue and epilogue stuff, even though
      it was itself then inside a C function where the compiler would add its
      own prologue and epilogue on top of it all.
      
      This then just _happened_ to work if you had exactly the right compiler
      version and exactly the right compiler flags, so that gcc just happened
      to not create any prologue at all (the gcc-generated epilogue wouldn't
      matter, since it would never be reached).
      
      But the more proper way to fix it is to simply not do this.  Move the
      inline asm to the top level, with no surrounding function at all (the
      better alternative would be to remove the prologue and make it actually
      use proper description of the arguments to the inline asm, but that's a
      bigger change than the one I'm willing to make right now).
      Tested-by: NS.Çağlar Onur <caglar@pardus.org.tr>
      Acked-by: NThomas Mingarelli <Thomas.Mingarelli@hp.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1f6ef234
    • L
      Reinstate ZERO_PAGE optimization in 'get_user_pages()' and fix XIP · 89f5b7da
      Linus Torvalds 提交于
      KAMEZAWA Hiroyuki and Oleg Nesterov point out that since the commit
      557ed1fa ("remove ZERO_PAGE") removed
      the ZERO_PAGE from the VM mappings, any users of get_user_pages() will
      generally now populate the VM with real empty pages needlessly.
      
      We used to get the ZERO_PAGE when we did the "handle_mm_fault()", but
      since fault handling no longer uses ZERO_PAGE for new anonymous pages,
      we now need to handle that special case in follow_page() instead.
      
      In particular, the removal of ZERO_PAGE effectively removed the core
      file writing optimization where we would skip writing pages that had not
      been populated at all, and increased memory pressure a lot by allocating
      all those useless newly zeroed pages.
      
      This reinstates the optimization by making the unmapped PTE case the
      same as for a non-existent page table, which already did this correctly.
      
      While at it, this also fixes the XIP case for follow_page(), where the
      caller could not differentiate between the case of a page that simply
      could not be used (because it had no "struct page" associated with it)
      and a page that just wasn't mapped.
      
      We do that by simply returning an error pointer for pages that could not
      be turned into a "struct page *".  The error is arbitrarily picked to be
      EFAULT, since that was what get_user_pages() already used for the
      equivalent IO-mapped page case.
      
      [ Also removed an impossible test for pte_offset_map_lock() failing:
        that's not how that function works ]
      Acked-by: NOleg Nesterov <oleg@tv-sign.ru>
      Acked-by: NNick Piggin <npiggin@suse.de>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Roland McGrath <roland@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      89f5b7da
  2. 19 6月, 2008 26 次提交
  3. 18 6月, 2008 10 次提交
    • P
      [POWERPC] Clear sub-page HPTE present bits when demoting page size · 65ba6cdc
      Paul Mackerras 提交于
      When we demote a slice from 64k to 4k, and we are about to insert an
      HPTE for a 4k subpage and we notice that there is an existing 64k
      HPTE, we first invalidate that HPTE before inserting the new 4k
      subpage HPTE.  Since the bits that encode which hash bucket the old
      HPTE was in overlap with the bits that encode which of the 16 subpages
      have HPTEs, we need to clear out the subpage HPTE-present bits before
      starting to insert HPTEs for the 4k subpages.  If we don't do that, we
      can erroneously think that a subpage already has an HPTE when it
      doesn't.
      
      That in itself wouldn't be such a problem except that when we go to
      update the HPTE that we think is present on machines with a
      hypervisor, the hypervisor can tell us that the HPTE we think is there
      is actually there even though it isn't, which can lead to a process
      getting stuck in a loop, continually faulting.  The reason for the
      confusion is that the AVPN (abbreviated virtual page number) we are
      looking for in the HPTE for a 4k subpage can actually match the AVPN
      in a stale HPTE for another 64k page.  For example, the HPTE for
      the 4k subpage at 0x84000f000 will be in the same hash bucket and have
      the same AVPN as the HPTE for the 64k page at 0x8400f0000.
      
      This fixes the code to clear out the subpage HPTE-present bits.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      65ba6cdc
    • J
      [POWERPC] 4xx: Clear new TLB cache attribute bits in Data Storage vector · b17879f7
      Josh Boyer 提交于
      A recent commit added support for the new 440x6 and 464 cores that have the
      added WL1, IL1I, IL1D, IL2I, and ILD2 bits for the caching attributes in the
      TLBs.  The new bits were cleared in the finish_tlb_load function, however a
      similar bit of code was missed in the DataStorage interrupt vector.
      Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      b17879f7
    • P
      netlink: genl: fix circular locking · 6d1a3fb5
      Patrick McHardy 提交于
      genetlink has a circular locking dependency when dumping the registered
      families:
      
      - dump start:
      genl_rcv()            : take genl_mutex
      genl_rcv_msg()        : call netlink_dump_start() while holding genl_mutex
      netlink_dump_start(),
      netlink_dump()        : take nlk->cb_mutex
      ctrl_dumpfamily()     : try to detect this case and not take genl_mutex a
                              second time
      
      - dump continuance:
      netlink_rcv()         : call netlink_dump
      netlink_dump          : take nlk->cb_mutex
      ctrl_dumpfamily()     : take genl_mutex
      
      Register genl_lock as callback mutex with netlink to fix this. This slightly
      widens an already existing module unload race, the genl ops used during the
      dump might go away when the module is unloaded. Thomas Graf is working on a
      seperate fix for this.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d1a3fb5
    • D
      Revert "mac80211: Use skb_header_cloned() on TX path." · 3a5be7d4
      David S. Miller 提交于
      This reverts commit 608961a5.
      
      The problem is that the mac80211 stack not only needs to be able to
      muck with the link-level headers, it also might need to mangle all of
      the packet data if doing sw wireless encryption.
      
      This fixes kernel bugzilla #10903.  Thanks to Didier Raboud (for the
      bugzilla report), Andrew Prince (for bisecting), Johannes Berg (for
      bringing this bisection analysis to my attention), and Ilpo (for
      trying to analyze this purely from the TCP side).
      
      In 2.6.27 we can take another stab at this, by using something like
      skb_cow_data() when the TX path of mac80211 ends up with a non-NULL
      tx->key.  The ESP protocol code in the IPSEC stack can be used as a
      model for implementation.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3a5be7d4
    • R
      af_unix: fix 'poll for write'/ connected DGRAM sockets · 3c73419c
      Rainer Weikusat 提交于
      The unix_dgram_sendmsg routine implements a (somewhat crude)
      form of receiver-imposed flow control by comparing the length of the
      receive queue of the 'peer socket' with the max_ack_backlog value
      stored in the corresponding sock structure, either blocking
      the thread which caused the send-routine to be called or returning
      EAGAIN. This routine is used by both SOCK_DGRAM and SOCK_SEQPACKET
      sockets. The poll-implementation for these socket types is
      datagram_poll from core/datagram.c. A socket is deemed to be writeable
      by this routine when the memory presently consumed by datagrams
      owned by it is less than the configured socket send buffer size. This
      is always wrong for connected PF_UNIX non-stream sockets when the
      abovementioned receive queue is currently considered to be full.
      'poll' will then return, indicating that the socket is writeable, but
      a subsequent write result in EAGAIN, effectively causing an
      (usual) application to 'poll for writeability by repeated send request
      with O_NONBLOCK set' until it has consumed its time quantum.
      
      The change below uses a suitably modified variant of the datagram_poll
      routines for both type of PF_UNIX sockets, which tests if the
      recv-queue of the peer a socket is connected to is presently
      considered to be 'full' as part of the 'is this socket
      writeable'-checking code. The socket being polled is additionally
      put onto the peer_wait wait queue associated with its peer, because the
      unix_dgram_sendmsg routine does a wake up on this queue after a
      datagram was received and the 'other wakeup call' is done implicitly
      as part of skb destruction, meaning, a process blocked in poll
      because of a full peer receive queue could otherwise sleep forever
      if no datagram owned by its socket was already sitting on this queue.
      Among this change is a small (inline) helper routine named
      'unix_recvq_full', which consolidates the actual testing code (in three
      different places) into a single location.
      Signed-off-by: NRainer Weikusat <rweikusat@mssgmbh.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3c73419c
    • D
    • A
      tun: Proper handling of IPv6 header in tun driver when TUN_NO_PI is set · f09f7ee2
      Ang Way Chuang 提交于
      By default, tun.c running in TUN_TUN_DEV mode will set the protocol of
      packet to IPv4 if TUN_NO_PI is set. My program failed to work when I
      assumed that the driver will check the first nibble of packet,
      determine IP version and set the appropriate protocol.
      Signed-off-by: NAng Way Chuang <wcang@nav6.org>
      Acked-by: NMax Krasnyansky <maxk@qualcomm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f09f7ee2
    • R
      atl1: relax eeprom mac address error check · 58c7821c
      Radu Cristescu 提交于
      The atl1 driver tries to determine the MAC address thusly:
      
      	- If an EEPROM exists, read the MAC address from EEPROM and
      	  validate it.
      	- If an EEPROM doesn't exist, try to read a MAC address from
      	  SPI flash.
      	- If that fails, try to read a MAC address directly from the
      	  MAC Station Address register.
      	- If that fails, assign a random MAC address provided by the
      	  kernel.
      
      We now have a report of a system fitted with an EEPROM containing all
      zeros where we expect the MAC address to be, and we currently handle
      this as an error condition.  Turns out, on this system the BIOS writes
      a valid MAC address to the NIC's MAC Station Address register, but we
      never try to read it because we return an error when we find the all-
      zeros address in EEPROM.
      
      This patch relaxes the error check and continues looking for a MAC
      address even if it finds an illegal one in EEPROM.
      Signed-off-by: NRadu Cristescu <advantis@gmx.net>
      Signed-off-by: NJay Cliburn <jacliburn@bellsouth.net>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      58c7821c
    • D
      net/enc28j60: low power mode · 7dac6f8d
      David Brownell 提交于
      Keep enc28j60 chips in low-power mode when they're not in use.
      At typically 120 mA, these chips run hot even when idle; this
      low power mode cuts that power usage by a factor of around 100.
      
      This version provides a generic routine to poll a register until
      its masked value equals some value ... e.g. bit set or cleared.
      It's basically what the previous wait_phy_ready() did, but this
      version is generalized to support the handshaking needed to
      enter and exit low power mode.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NClaudio Lanconelli <lanconelli.claudio@eptar.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      7dac6f8d
    • D
      net/enc28j60: section fix · 6fd65882
      David Brownell 提交于
      Minor bugfixes to the enc28j60 driver ... wrong section marking,
      indentation, and bogus use of spi_bus_type.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Acked-by: NClaudio Lanconelli <lanconelli.claudio@eptar.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      6fd65882