allow multiple aoe devices to have the same mac
Signed-off-by: Ed L. Cashin <ecashin@coraid.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
diff -u b/drivers/block/aoe/aoedev.c b/drivers/block/aoe/aoedev.c
aoe-stat should work for built-in as well as module
Signed-off-by: Ed L. Cashin <ecashin@coraid.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
diff -uprN a/Documentation/aoe/status.sh b/Documentation/aoe/status.sh
Fixed problem where setting or retreiving the serial config would fail
with EPIPE. Removed CRTS toggling so the driver behaves more like other
usbserial adapters. Issued new interval of 1ms instead of the default
bInterval. As a result, transfer speed has been substantially
increased. From avg. 850bps to avg. 3300bps. Also added new module
parameter 'interval' to tweak the interval in case this change causes
problems for someone. Cleaned up code and formatting issues so source
is more readable. Replaced the C++ style comments. Various other code
cleanups.
Signed-off-by: Lonnie Mendez <lmendez19@austin.rr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds an unusual_devs entry for the Minolta Dimage Z10.
Originally reported by Vilisas <vilisas@xxx.lt>
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[ftdi_sio] Replaced redundant INTERFACE_A and INTERFACE_B macros with
the equivalent PIT_SIOA and PIT_SIOB macros.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Some VID/PID updates for the ftdi_sio driver:
* The "Gude Analog- und Digitalsysteme GmbH" entries were missing from
the "combined" table.
* Replaced FTDI_8U232AM_ALT_ALT_PID with 3 PIDs for devices from
4n-galaxy.de.
* Removed redundant FTDI_RM_VID and renamed FTDI_RMCANVIEW_PID to
FTDI_RM_CANVIEW_PID.
* Added VID/PID for serial converter in Mobility Electronics EasiDock
USB 200 (mentioned by Gregory Schmitt).
* Added PID for Active Robots USB comms board (mentioned by John Koch).
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
diff -ur a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
On Thu, Apr 14, 2005 at 11:06:21PM +0400, Sergey Vlasov wrote:
> http://thread.gmane.org/gmane.linux.usb.devel/32977
>
> (see "[PATCH] N/3 cdc acm errors").
>
> You also need this driver core fix:
>
> http://thread.gmane.org/gmane.linux.usb.devel/33132
I reproduced the same oops while trying to execute at+mode=99, it would
be nice to get these fix merged since I believe it's still needed to
connect the laptop over gprs (something I didn't test yet).
This further patch will allow you to connect via usbnet, Greg could you
apply? Thanks!
Signed-off-by: Andrea Arcangeli <andrea@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Miscellaneous updates for EHCI.
- Mostly updates the power switching on EHCI controllers. One routine
centralizes the "power on/off all ports" logic, and the capability to
do that is reported more correctly.
- Courtesy Colin Leroy, a patch to always power up ports after resumes
which didn't keep a USB device suspended. The reset-everything logic
powers down those ports (on some hardware) so something needs to turn
them back on.
- Minor tweaks/bugfixes for the debug port support.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes a compiler error caused by a missing prototype. It should
apply directly to Greg KH's usb-2.6.git tree.
Signed-off-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There is some race whereby IRQs get stuck, the IRQ status
is pending but no processor actually handles the IRQ vector
and thus the interrupt.
This is a temporary workaround.
Signed-off-by: David S. Miller <davem@davemloft.net>
We would never advance the goal_cpu counter like we
should, so all IRQs would go to a single processor.
Signed-off-by: David S. Miller <davem@davemloft.net>
Long standing bug.
Policy to repeat an action never worked.
Signed-off-by: J Hadi Salim <hadi@cyberus.ca>
Signed-off-by: David S. Miller <davem@davemloft.net>
I found a bug that stopped IPsec/IPv6 from working. About
a month ago IPv6 started using rt6i_idev->dev on the cached socket dst
entries. If the cached socket dst entry is IPsec, then rt6i_idev will
be NULL.
Since we want to look at the rt6i_idev of the original route in this
case, the easiest fix is to store rt6i_idev in the IPsec dst entry just
as we do for a number of other IPv6 route attributes. Unfortunately
this means that we need some new code to handle the references to
rt6i_idev. That's why this patch is bigger than it would otherwise be.
I've also done the same thing for IPv4 since it is conceivable that
once these idev attributes start getting used for accounting, we
probably need to dereference them for IPv4 IPsec entries too.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix qlen underrun when doing duplication with netem. If netem is used
as leaf discipline, then the parent needs to be tweaked when packets
are duplicated.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Netem currently dumps packets into the queue when timer expires. This
patch makes work by self-clocking (more like TBF). It fixes a bug
when 0 delay is requested (only doing loss or duplication).
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Due to bugs in netem (fixed by later patches), it is possible to get qdisc
qlen to go negative. If this happens the CPU ends up spinning forever
in qdisc_run(). So add a BUG_ON() to trap it.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some network drivers call netif_stop_queue() when detecting loss of
carrier. This leads to packets being queued up at the qdisc level for
an unbound period of time. In order to prevent this effect, the core
networking stack will now cease to queue packets for any device, that
is operationally down (i.e. the queue is flushed and disabled).
Signed-off-by: Tommy S. Christensen <tommy.christensen@tpack.net>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
If we free up a partially processed packet because it's
skb->len dropped to zero, we need to decrement qlen because
we are dropping out of the top-level loop so it will do
the decrement for us.
Spotted by Herbert Xu.
Signed-off-by: David S. Miller <davem@davemloft.net>
- pfm_context_load(): change return value from EINVAL to EBUSY
when context is already loaded.
- pfm_check_task_state(): pass test if context state is MASKED.
It is safe to give access on PFM_CTX_MASKED because the PMU
state (PMD) is stable and saved in software state.
This helps multiplexing programs such as the example given
in libpfm-3.1.
Signed-off-by: stephane eranian <eranian@hpl.hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
The pmu_active test is based on the values of PSR.up. THIS IS THE PROBLEM as
it does not take into account the lazy restore logic which is as follow (simplified):
context switch out:
save PMDs
clear psr.up
release ownership
context switch in:
if (ctx->last_cpu == smp_processor_id() && ctx->cpu_activation == cpu_activation) {
set psr.up
return
}
restore PMD
restore PMC
ctx->last_cpu = smp_processor_id();
ctx->activation = ++cpu_activation;
set psr.up
The key here is that on context switch out, we clear psr.up and on context switch in
we check if nobody else used the PMU on that processor since last time we came. In
that case, we assume the PMD/PMC are ours and we simply reactivate.
The Caliper problem is that between the moment we context switch out and the moment we
come back, nobody effectively used the PMU BUT the processor went idle. Normally this
would have no incidence but PAL_HALT does alter the PMU registers. In default_idle(),
the test on psr.up is not strong enough to cover this case and we go into PAL which
trashed the PMU resgisters. When we come back we falsely assume that this is our state
yet it is corrupted. Very nasty indeed.
To avoid the problem it is necessary to forbid going to PAL_HALT as soon as perfmon
installs some valid state in the PMU registers. This happens with an application
attaches a context to a thread or CPU. It is not enough to check the psr/dcr bits.
Hence I propose the attached patch. It adds a callback in process.c to modify the
condition to enter PAL on idle. Basically, now it is conditional to pal_halt=1 AND
perfmon saying it is okay.
Signed-off-by: Tony Luck <tony.luck@intel.com>
The qlen should continue to decrement, even if we
pop partially processed SKBs back onto the receive queue.
Signed-off-by: David S. Miller <davem@davemloft.net>
Patch from Sascha Hauer
This patch adds the missing include files for the i.MX framebuffer
driver.
Signed-off-by: Sascha Hauer
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Let's recap the problem. The current asynchronous netlink kernel
message processing is vulnerable to these attacks:
1) Hit and run: Attacker sends one or more messages and then exits
before they're processed. This may confuse/disable the next netlink
user that gets the netlink address of the attacker since it may
receive the responses to the attacker's messages.
Proposed solutions:
a) Synchronous processing.
b) Stream mode socket.
c) Restrict/prohibit binding.
2) Starvation: Because various netlink rcv functions were written
to not return until all messages have been processed on a socket,
it is possible for these functions to execute for an arbitrarily
long period of time. If this is successfully exploited it could
also be used to hold rtnl forever.
Proposed solutions:
a) Synchronous processing.
b) Stream mode socket.
Firstly let's cross off solution c). It only solves the first
problem and it has user-visible impacts. In particular, it'll
break user space applications that expect to bind or communicate
with specific netlink addresses (pid's).
So we're left with a choice of synchronous processing versus
SOCK_STREAM for netlink.
For the moment I'm sticking with the synchronous approach as
suggested by Alexey since it's simpler and I'd rather spend
my time working on other things.
However, it does have a number of deficiencies compared to the
stream mode solution:
1) User-space to user-space netlink communication is still vulnerable.
2) Inefficient use of resources. This is especially true for rtnetlink
since the lock is shared with other users such as networking drivers.
The latter could hold the rtnl while communicating with hardware which
causes the rtnetlink user to wait when it could be doing other things.
3) It is still possible to DoS all netlink users by flooding the kernel
netlink receive queue. The attacker simply fills the receive socket
with a single netlink message that fills up the entire queue. The
attacker then continues to call sendmsg with the same message in a loop.
Point 3) can be countered by retransmissions in user-space code, however
it is pretty messy.
In light of these problems (in particular, point 3), we should implement
stream mode netlink at some point. In the mean time, here is a patch
that implements synchronous processing.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Here is a little optimisation for the cb_lock used by netlink_dump.
While fixing that race earlier, I noticed that the reference count
held by cb_lock is completely useless. The reason is that in order
to obtain the protection of the reference count, you have to take
the cb_lock. But the only way to take the cb_lock is through
dereferencing the socket.
That is, you must already possess a reference count on the socket
before you can take advantage of the reference count held by cb_lock.
As a corollary, we can remve the reference count held by the cb_lock.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
htb_enqueue(): Free skb and return NET_XMIT_DROP if a packet is
destined for the direct_queue but the direct_queue is full. (Before
this: erroneously returned NET_XMIT_SUCCESS even though the packet was
not enqueued)
Signed-off-by: Asim Shankar <asimshankar@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
kfree() and vfree() can both deal with NULL pointers. This patch removes
redundant NULL pointer checks from the ppp code in drivers/net/
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is a trivial fix for a typo on Kconfig, where the Generic Random Early
Detection algorithm is abbreviated as RED instead of GRED.
Signed-off-by: Lucas Correia Villa Real <lucasvr@gobolinux.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
kfree(0) is perfectly valid, checking pointers for NULL before calling
kfree() on them is redundant. The patch below cleans away a few such
redundant checks (and while I was around some of those bits I couldn't
stop myself from making a few tiny whitespace changes as well).
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
Acked-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Converts remaining rtnetlink_link tables to use c99 designated
initializers to make greping a little bit easier.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Converts rtm_min and rtm_max arrays to use c99 designated
initializers for easier insertion of new message families.
RTM_GETMULTICAST and RTM_GETANYCAST did not have the minimal
message size specified which means that the netlink message
was parsed for routing attributes starting from the header.
Adds the proper minimal message sizes for these messages
(netlink header + common rtnetlink header) to fix this issue.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
RTM_MAX is currently set to the maximum reserverd message type plus one
thus being the cause of two bugs for new types being assigned a) given the
new family registers only the NEW command in its reserved block the array
size for per family entries is calculated one entry short and b) given the
new family registers all commands RTM_MAX would point to the first entry
of the block following this one and the rtnetlink receive path would accept
a message type for a nonexisting family.
This patch changes RTM_MAX to point to the maximum valid message type
by aligning it to the start of the next block and subtracting one.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Converts xfrm_msg_min and xfrm_dispatch to use c99 designated
initializers to make greping a little bit easier. Also replaces
two hardcoded message type with meaningful names.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Makes the type > XFRM_MSG_MAX check behave correctly to
protect access to xfrm_dispatch.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ed L Cashin