Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 20 6月, 2008 3 次提交
    • O
      sched: refactor wait_for_completion_timeout() · ea71a546
      由 Oleg Nesterov 提交于 
      Simplify the code and fix the boundary condition of
wait_for_completion_timeout(,0).

We can kill the first __remove_wait_queue() as well.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      ea71a546
    • R
      sched: fix wait_for_completion_timeout() spurious failure under heavy load · bb10ed09
      由 Roland Dreier 提交于 
      It seems that the current implementaton of wait_for_completion_timeout()
has a small problem under very high load for the common pattern:

	if (!wait_for_completion_timeout(&done, timeout))
		/* handle failure */

because the implementation very roughly does (lots of code deleted to
show the basic flow):

	static inline long __sched
	do_wait_for_common(struct completion *x, long timeout, int state)
	{
		if (x->done)
			return timeout;

		do {
			timeout = schedule_timeout(timeout);

			if (!timeout)
				return timeout;

		} while (!x->done);

		return timeout;
	}

so if the system is very busy and x->done is not set when
do_wait_for_common() is entered, it is possible that the first call to
schedule_timeout() returns 0 because the task doing wait_for_completion
doesn't get rescheduled for a long time, even if it is woken up early
enough.

In this case, wait_for_completion_timeout() returns 0 without even
checking x->done again, and the code above falls into its failure case
purely for scheduler reasons, even if the hardware event or whatever was
being waited for happened early enough.

It would make sense to add an extra test to do_wait_for() in the timeout
case and return 1 if x->done is actually set.

A quick audit (not exhaustive) of wait_for_completion_timeout() callers
seems to indicate that no one actually cares about the return value in
the success case -- they just test for 0 (timed out) versus non-zero
(wait succeeded).
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      bb10ed09
    • P
      sched: rt: dont stop the period timer when there are tasks wanting to run · 8a8cde16
      由 Peter Zijlstra 提交于 
      So if the group ever gets throttled, it will never wake up again.
Reported-by: N"Daniel K." <dk@uw.no>
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Tested-by: NDaniel K. <dk@uw.no>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8a8cde16
  3. 19 6月, 2008 24 次提交
  5. 18 6月, 2008 13 次提交
    • 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
      Merge branch 'davem-fixes' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6 · 4552e119
      由 David S. Miller 提交于
      4552e119
    • 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
    • S
      sky2: 88E8040T pci device id · a3b4fced
      由 Stephen Hemminger 提交于 
      Missed one pci id for 88E8040T.
Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      a3b4fced
    • D
      netxen: download firmware in pci probe · 439b454e
      由 Dhananjay Phadke 提交于 
      Downloading firmware in pci probe allows recovery in case of
firmware failure by reloading the driver.

Also reduced delays in firmware load.
Signed-off-by: NDhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      439b454e
    • D
      netxen: cleanup debug messages · dcd56fdb
      由 Dhananjay Phadke 提交于 
      o Remove unnecessary debug prints and functions.
o Explicitly specify pci class (0x020000) to avoid enabling
  management function.
Signed-off-by: NDhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      dcd56fdb