* RE: [PATCHv4 NEXT 1/1] net: ethtool support to configure number of channels
From: Amit Salecha @ 2011-04-13 9:45 UTC (permalink / raw)
To: davem@davemloft.net
Cc: netdev@vger.kernel.org, Ameen Rahman, Sucheta Chakraborty,
Anirban Chakraborty
In-Reply-To: <1302177522-17815-1-git-send-email-amit.salecha@qlogic.com>
> Ethtool support to configure RX, TX and other channels. combined field
> in struct ethtool_channels to reflect set of channel (RX, TX or other).
> Other channel can be link interrupts, SR-IOV coordination etc.
>
> ETHTOOL_GCHANNELS will report max and current number of RX channels,
> max and current number of TX channels, max and current number of other
> channel
> or max and current number of combined channel.
>
> Number of channel can be modify upto max number of channel through
> ETHTOOL_SCHANNELS command.
>
> Ben Hutchings:
> o define 'combined' and 'other' types. Most multiqueue drivers pair up
> RX and TX
> queues so that most channels combine RX and TX work.
> o Please could you use a kernel-doc comment to describe the structure.
>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Neither I see this patch in http://patchwork.ozlabs.org/project/netdev/list/ nor any comment.
Just curious, is this patch discarded along with my other garbage patches ?
-Amit
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
^ permalink raw reply
* Re: [PATCH v4] net: bnx2x: convert to hw_features
From: Vladislav Zolotarov @ 2011-04-13 9:36 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev@vger.kernel.org, Eilon Greenstein
In-Reply-To: <20110412144940.GA26043@rere.qmqm.pl>
> Hmm. I thought one, and wrote another.
>
> Since bnx2x_parity_recover() runs with rtnl_lock(), as should
> netdev_update_features(), then in case the recovery is in progress
> it should be enough to not call bnx2x_reload_if_running() then
> and just change the flags --- changes will be picked up on bnx2x_nic_load()
> after recovery is complete. This removes the need for netdev_update_features()
> calls.
>
Ok. I see what u meant in v5... ;)
The patch is great. Thanks for your work. There are some enhancements
following your patch that I have in mind that I'll submit later.
thanks again, Michal.
^ permalink raw reply
* [RFC] [PATCH net-next 1/1] Phonet: convert bound sockets hash list to RCU
From: Rémi Denis-Courmont @ 2011-04-13 9:27 UTC (permalink / raw)
To: netdev
This gets rid of the last spinlock in the Phonet stack proper.
Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
---
net/phonet/socket.c | 45 +++++++++++++++++++++------------------------
1 files changed, 21 insertions(+), 24 deletions(-)
diff --git a/net/phonet/socket.c b/net/phonet/socket.c
index b1adafa..8c5bfce 100644
--- a/net/phonet/socket.c
+++ b/net/phonet/socket.c
@@ -52,7 +52,7 @@ static int pn_socket_release(struct socket *sock)
static struct {
struct hlist_head hlist[PN_HASHSIZE];
- spinlock_t lock;
+ struct mutex lock;
} pnsocks;
void __init pn_sock_init(void)
@@ -61,7 +61,7 @@ void __init pn_sock_init(void)
for (i = 0; i < PN_HASHSIZE; i++)
INIT_HLIST_HEAD(pnsocks.hlist + i);
- spin_lock_init(&pnsocks.lock);
+ mutex_init(&pnsocks.lock);
}
static struct hlist_head *pn_hash_list(u16 obj)
@@ -82,9 +82,8 @@ struct sock *pn_find_sock_by_sa(struct net *net, const struct sockaddr_pn *spn)
u8 res = spn->spn_resource;
struct hlist_head *hlist = pn_hash_list(obj);
- spin_lock_bh(&pnsocks.lock);
-
- sk_for_each(sknode, node, hlist) {
+ rcu_read_lock();
+ sk_for_each_rcu(sknode, node, hlist) {
struct pn_sock *pn = pn_sk(sknode);
BUG_ON(!pn->sobject); /* unbound socket */
@@ -107,8 +106,7 @@ struct sock *pn_find_sock_by_sa(struct net *net, const struct sockaddr_pn *spn)
sock_hold(sknode);
break;
}
-
- spin_unlock_bh(&pnsocks.lock);
+ rcu_read_unlock();
return rval;
}
@@ -119,7 +117,7 @@ void pn_deliver_sock_broadcast(struct net *net, struct sk_buff *skb)
struct hlist_head *hlist = pnsocks.hlist;
unsigned h;
- spin_lock(&pnsocks.lock);
+ rcu_read_lock();
for (h = 0; h < PN_HASHSIZE; h++) {
struct hlist_node *node;
struct sock *sknode;
@@ -140,25 +138,26 @@ void pn_deliver_sock_broadcast(struct net *net, struct sk_buff *skb)
}
hlist++;
}
- spin_unlock(&pnsocks.lock);
+ rcu_read_unlock();
}
void pn_sock_hash(struct sock *sk)
{
struct hlist_head *hlist = pn_hash_list(pn_sk(sk)->sobject);
- spin_lock_bh(&pnsocks.lock);
- sk_add_node(sk, hlist);
- spin_unlock_bh(&pnsocks.lock);
+ mutex_lock(&pnsocks.lock);
+ sk_add_node_rcu(sk, hlist);
+ mutex_unlock(&pnsocks.lock);
}
EXPORT_SYMBOL(pn_sock_hash);
void pn_sock_unhash(struct sock *sk)
{
- spin_lock_bh(&pnsocks.lock);
- sk_del_node_init(sk);
- spin_unlock_bh(&pnsocks.lock);
+ mutex_lock(&pnsocks.lock);
+ sk_del_node_init_rcu(sk);
+ mutex_unlock(&pnsocks.lock);
pn_sock_unbind_all_res(sk);
+ synchronize_rcu();
}
EXPORT_SYMBOL(pn_sock_unhash);
@@ -548,7 +547,7 @@ static struct sock *pn_sock_get_idx(struct seq_file *seq, loff_t pos)
unsigned h;
for (h = 0; h < PN_HASHSIZE; h++) {
- sk_for_each(sknode, node, hlist) {
+ sk_for_each_rcu(sknode, node, hlist) {
if (!net_eq(net, sock_net(sknode)))
continue;
if (!pos)
@@ -572,9 +571,9 @@ static struct sock *pn_sock_get_next(struct seq_file *seq, struct sock *sk)
}
static void *pn_sock_seq_start(struct seq_file *seq, loff_t *pos)
- __acquires(pnsocks.lock)
+ __acquires(rcu)
{
- spin_lock_bh(&pnsocks.lock);
+ rcu_read_lock();
return *pos ? pn_sock_get_idx(seq, *pos - 1) : SEQ_START_TOKEN;
}
@@ -591,9 +590,9 @@ static void *pn_sock_seq_next(struct seq_file *seq, void *v, loff_t *pos)
}
static void pn_sock_seq_stop(struct seq_file *seq, void *v)
- __releases(pnsocks.lock)
+ __releases(rcu)
{
- spin_unlock_bh(&pnsocks.lock);
+ rcu_read_unlock();
}
static int pn_sock_seq_show(struct seq_file *seq, void *v)
@@ -721,13 +720,11 @@ void pn_sock_unbind_all_res(struct sock *sk)
}
mutex_unlock(&resource_mutex);
- if (match == 0)
- return;
- synchronize_rcu();
while (match > 0) {
- sock_put(sk);
+ __sock_put(sk);
match--;
}
+ /* Caller is responsible for RCU sync before final sock_put() */
}
#ifdef CONFIG_PROC_FS
--
1.7.4.1
^ permalink raw reply related
* Re: [Bugme-new] [Bug 32832] New: shutdown(2) does not fully shut down socket any more
From: Eric Dumazet @ 2011-04-13 8:51 UTC (permalink / raw)
To: Cyril Bonté
Cc: David Miller, akpm, netdev, bugzilla-daemon, bugme-daemon, kees
In-Reply-To: <201104130906.19882.cyril.bonte@free.fr>
Le mercredi 13 avril 2011 à 09:06 +0200, Cyril Bonté a écrit :
> Le mercredi 13 avril 2011 04:55:27, Eric Dumazet a écrit :
> > I worked on it this week end to discover FreeBSD 8.1 would not allow
> > several CLOSE sockets bound to same port even with REUSEADDR.
>
> Just to complete the information, yes it does, but only after a shutdown()
> call. And this is the use case of haproxy, amavisd (quoted in the bugzilla bug
> report), and others.
Yes, but after a shutdown(), FreeBSD doesnt allow a reuse of the socket.
listen() is not available anymore. Its a bit like an unbind, or a full
close().
^ permalink raw reply
* [PATCH] stmmac: review Wol and enable the Unicast support
From: Giuseppe CAVALLARO @ 2011-04-13 7:27 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/stmmac/dwmac1000_core.c | 5 +++--
drivers/net/stmmac/stmmac_ethtool.c | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/stmmac/dwmac1000_core.c b/drivers/net/stmmac/dwmac1000_core.c
index 6ae4c3f..f20455c 100644
--- a/drivers/net/stmmac/dwmac1000_core.c
+++ b/drivers/net/stmmac/dwmac1000_core.c
@@ -178,10 +178,11 @@ static void dwmac1000_pmt(void __iomem *ioaddr, unsigned long mode)
{
unsigned int pmt = 0;
- if (mode == WAKE_MAGIC) {
+ if (mode & WAKE_MAGIC) {
CHIP_DBG(KERN_DEBUG "GMAC: WOL Magic frame\n");
pmt |= power_down | magic_pkt_en;
- } else if (mode == WAKE_UCAST) {
+ }
+ if (mode & WAKE_UCAST) {
CHIP_DBG(KERN_DEBUG "GMAC: WOL on global unicast\n");
pmt |= global_unicast;
}
diff --git a/drivers/net/stmmac/stmmac_ethtool.c b/drivers/net/stmmac/stmmac_ethtool.c
index 156a805..0e61ac8 100644
--- a/drivers/net/stmmac/stmmac_ethtool.c
+++ b/drivers/net/stmmac/stmmac_ethtool.c
@@ -308,7 +308,7 @@ static void stmmac_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
spin_lock_irq(&priv->lock);
if (device_can_wakeup(priv->device)) {
- wol->supported = WAKE_MAGIC;
+ wol->supported = WAKE_MAGIC | WAKE_UCAST;
wol->wolopts = priv->wolopts;
}
spin_unlock_irq(&priv->lock);
@@ -317,7 +317,7 @@ static void stmmac_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
static int stmmac_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
{
struct stmmac_priv *priv = netdev_priv(dev);
- u32 support = WAKE_MAGIC;
+ u32 support = WAKE_MAGIC | WAKE_UCAST;
if (!device_can_wakeup(priv->device))
return -EINVAL;
--
1.7.4.2
^ permalink raw reply related
* Re: [Bugme-new] [Bug 32832] New: shutdown(2) does not fully shut down socket any more
From: Cyril Bonté @ 2011-04-13 7:06 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, akpm, netdev, bugzilla-daemon, bugme-daemon, kees
In-Reply-To: <1302663327.2811.55.camel@edumazet-laptop>
Le mercredi 13 avril 2011 04:55:27, Eric Dumazet a écrit :
> I worked on it this week end to discover FreeBSD 8.1 would not allow
> several CLOSE sockets bound to same port even with REUSEADDR.
Just to complete the information, yes it does, but only after a shutdown()
call. And this is the use case of haproxy, amavisd (quoted in the bugzilla bug
report), and others.
> So haproxy claim is a bit wrong (its trick doesnt work on FreeBSD), and
> used an undocumented linux feature.
Both test cases (the one I provided to explain the haproxy issue and the one
provided by Kees) are not about binding 2 sockets at the same time but binding
a new socket after the first one has been shutdown.
Sadly this also looks undocumented on FreeBSD (only saw a reference on it in a
code comment).
> Since SO_REUSEPORT is not a 'stable fix', I suggest we revert the patch,
> and eventually work on SO_REUSEPORT on net-next-2.6
>
> What do you think ?
Agree.
Many thanks for the time you already spent on that.
^ permalink raw reply
* Testing IRDA device driver
From: Amit Virdi @ 2011-04-13 6:40 UTC (permalink / raw)
To: netdev
Hi All,
For the past few days I've been trying to test a driver that I've
written for DICE Fast IrDA controller. As per my requirements, I need to
use IrCOMM as the upper layer.
I'm using the same kernel image on the both the boards. When I run
irattach on either of the boards I can see discovery protocol being
initiated and completing successfully (cat /proc/net/irda/discovery
giving output with other ends's device's MAC address as the daddr) but
I'm struggling to test the driver further.
I've observed that the discovery request/response sequence goes on for 5
minutes. After this, the discovery process stops. On the master side, I
could see no IrLAP frame being sent/received and also the output of cat
/proc/net/irda/discovery is NULL. However, on the slave side, the cat
/proc/net/irda/discovery output shows the master side!!
If I run irattach on the slave side also, no DISCOVERY message is
exchanged and then, the output of slave side also doesn't show anything.
Sometimes, I start getting log "IrLAP, no activity on link!" and then
ircomm_close() API is called from within the stack.
If, I try to run getty on /dev/ircomm0, it does not work!
If I try to transfer data using
echo "1234567890" > /dev/ircomm0
on the master side, and
cat /dev/ircomm0
on the slave side, I can see SNRM command, UA response, RR command,
IrLMP connect/disconnect etc. However, the data transfer actually didn't
happen. I cannot see the string "1234567890" on the slave side.
Please suggest what I'm missing/doing wrong. I need to transfer data
from one device to another to complete the testing. I shall be very much
thankful for suggestions/advice.
Thanks n Regards
Amit Virdi
^ permalink raw reply
* Re: [PATCHv2 net-next-2.6] rndis_host: Poll status before control channel where necessary
From: huajun li @ 2011-04-13 6:04 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, Mark Glassberg, linux-usb
In-Reply-To: <1302670523.5282.610.camel@localhost>
>
> +static const struct driver_info rndis_poll_status_info = {
> + .description = "RNDIS device (poll status before control)",
> + .flags = FLAG_ETHER | FLAG_FRAMING_RN | FLAG_NO_SETINT,
Hi,
How about add FLAG_POINTTOPOINT to flags if the device has no
globally assigned MAC? This new added mask code could make device
interface naming consistent.
Thanks,
--Huajun
^ permalink raw reply
* RE: [stable] [PATCH NET-2.6 1/1] qlcnic: limit skb frags for non tso packet
From: Amit Salecha @ 2011-04-13 5:56 UTC (permalink / raw)
To: Greg KH
Cc: David Miller, netdev@vger.kernel.org, Anirban Chakraborty,
stable@kernel.org, Ameen Rahman
In-Reply-To: <20110413034228.GA852@kroah.com>
> On Tue, Apr 12, 2011 at 09:01:13PM -0500, Amit Salecha wrote:
> >
> > This message and any attached documents contain information from
> QLogic Corporation or its wholly-owned subsidiaries that may be
> confidential. If you are not the intended recipient, you may not read,
> copy, distribute, or use this information. If you have received this
> transmission in error, please notify the sender immediately by reply e-
> mail and then delete this message.
>
> I have received this transmission in error.
>
> Please remove this from your footer, otherwise we can not accept any
> emails sent from you as actually being allowed to contribute to the
> kernel properly :(
>
I have send version two of this patch, that doesn't have this footer.
Please discard this one.
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
^ permalink raw reply
* [PATCHv2 net-next-2.6] rndis_host: Poll status before control channel where necessary
From: Ben Hutchings @ 2011-04-13 4:55 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Mark Glassberg, linux-usb-u79uwXL29TY76Z2rM5mHXA
Some RNDIS devices don't respond on the control channel until polled
on the status channel. In particular, this was reported to be the
case for the 2Wire HomePortal 1000SW and for some Windows Mobile
devices.
This is roughly based on a patch by John Carr <john.carr-3P/l8hQepEe9FHfhHBbuYA@public.gmane.org>
which is currently applied by Mandriva.
Reported-by: Mark Glassberg <vzeeaxwl-ubggFOsnOr3gwBMGfI3FeA@public.gmane.org>
Signed-off-by: Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
---
The first version made this behaviour unconditional and had to be
reverted. This version adds a quirk flag instead.
Ben.
drivers/net/usb/rndis_host.c | 39 ++++++++++++++++++++++++++++++++-------
include/linux/usb/rndis_host.h | 2 ++
2 files changed, 34 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/rndis_host.c b/drivers/net/usb/rndis_host.c
index 5994a25..6d6c1da 100644
--- a/drivers/net/usb/rndis_host.c
+++ b/drivers/net/usb/rndis_host.c
@@ -104,8 +104,10 @@ static void rndis_msg_indicate(struct usbnet *dev, struct rndis_indicate *msg,
int rndis_command(struct usbnet *dev, struct rndis_msg_hdr *buf, int buflen)
{
struct cdc_state *info = (void *) &dev->data;
+ struct usb_cdc_notification notification;
int master_ifnum;
int retval;
+ int partial;
unsigned count;
__le32 rsp;
u32 xid = 0, msg_len, request_id;
@@ -133,13 +135,20 @@ int rndis_command(struct usbnet *dev, struct rndis_msg_hdr *buf, int buflen)
if (unlikely(retval < 0 || xid == 0))
return retval;
- // FIXME Seems like some devices discard responses when
- // we time out and cancel our "get response" requests...
- // so, this is fragile. Probably need to poll for status.
+ /* Some devices don't respond on the control channel until
+ * polled on the status channel, so do that first. */
+ if (dev->driver_info->data & RNDIS_DRIVER_DATA_POLL_STATUS) {
+ retval = usb_interrupt_msg(
+ dev->udev,
+ usb_rcvintpipe(dev->udev,
+ dev->status->desc.bEndpointAddress),
+ ¬ification, sizeof(notification), &partial,
+ RNDIS_CONTROL_TIMEOUT_MS);
+ if (unlikely(retval < 0))
+ return retval;
+ }
- /* ignore status endpoint, just poll the control channel;
- * the request probably completed immediately
- */
+ /* Poll the control channel; the request probably completed immediately */
rsp = buf->msg_type | RNDIS_MSG_COMPLETION;
for (count = 0; count < 10; count++) {
memset(buf, 0, CONTROL_BUFFER_SIZE);
@@ -581,17 +590,33 @@ static const struct driver_info rndis_info = {
.tx_fixup = rndis_tx_fixup,
};
+static const struct driver_info rndis_poll_status_info = {
+ .description = "RNDIS device (poll status before control)",
+ .flags = FLAG_ETHER | FLAG_FRAMING_RN | FLAG_NO_SETINT,
+ .data = RNDIS_DRIVER_DATA_POLL_STATUS,
+ .bind = rndis_bind,
+ .unbind = rndis_unbind,
+ .status = rndis_status,
+ .rx_fixup = rndis_rx_fixup,
+ .tx_fixup = rndis_tx_fixup,
+};
+
/*-------------------------------------------------------------------------*/
static const struct usb_device_id products [] = {
{
+ /* 2Wire HomePortal 1000SW */
+ USB_DEVICE_AND_INTERFACE_INFO(0x1630, 0x0042,
+ USB_CLASS_COMM, 2 /* ACM */, 0x0ff),
+ .driver_info = (unsigned long) &rndis_poll_status_info,
+}, {
/* RNDIS is MSFT's un-official variant of CDC ACM */
USB_INTERFACE_INFO(USB_CLASS_COMM, 2 /* ACM */, 0x0ff),
.driver_info = (unsigned long) &rndis_info,
}, {
/* "ActiveSync" is an undocumented variant of RNDIS, used in WM5 */
USB_INTERFACE_INFO(USB_CLASS_MISC, 1, 1),
- .driver_info = (unsigned long) &rndis_info,
+ .driver_info = (unsigned long) &rndis_poll_status_info,
}, {
/* RNDIS for tethering */
USB_INTERFACE_INFO(USB_CLASS_WIRELESS_CONTROLLER, 1, 3),
diff --git a/include/linux/usb/rndis_host.h b/include/linux/usb/rndis_host.h
index 05ef528..88fceb7 100644
--- a/include/linux/usb/rndis_host.h
+++ b/include/linux/usb/rndis_host.h
@@ -256,6 +256,8 @@ struct rndis_keepalive_c { /* IN (optionally OUT) */
#define FLAG_RNDIS_PHYM_NOT_WIRELESS 0x0001
#define FLAG_RNDIS_PHYM_WIRELESS 0x0002
+/* Flags for driver_info::data */
+#define RNDIS_DRIVER_DATA_POLL_STATUS 1 /* poll status before control */
extern void rndis_status(struct usbnet *dev, struct urb *urb);
extern int
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC v3 5/6] j1939: rename NAME to UUID?
From: Kurt Van Dijck @ 2011-04-13 4:49 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D8623BE.2080807-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Oliver et.al.,
On Sun, Mar 20, 2011 at 04:56:46PM +0100, Oliver Hartkopp wrote:
> On 14.03.2011 14:59, Kurt Van Dijck wrote:
>
> Then you suggest to attach static and/or dynamic addresses to the interface.
>
> > + Assigning addresses is done via
> > + $ ip addr add dev canX j1939 0xXX
> > + statically or
> > + $ ip addr add dev canX j1939 name 0xXX
> > + dynamically. In the latter case, address claiming must take place
> > + before other traffic can leave.
>
> like you would have using DHCP/DNS (adapted for j1939) ...
>
I suspect the confustion with DHCP/DNS comes free with the used terminology.
Specifications talk about a 64bit NAME, where is actually is a 64bit UUID.
Calling this number a UUID may clarify things, but leaves the spec in the
terminology.
one would then do:
$ ip addr add dev canX j1939 uuid XXXX
Would that be a good way to progress?
Kurt
^ permalink raw reply
* Re: [PATCH] bridge: reset IPCB in br_parse_ip_options
From: Scot Doyle @ 2011-04-13 4:12 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Stephen Hemminger, Jan Lübbe, Hiroaki SHIMODA,
netdev, Bandan Das
In-Reply-To: <4DA4E68B.9010401@scotdoyle.com>
On 04/12/2011 06:55 PM, Scot Doyle wrote:
> On 04/12/2011 12:18 PM, Eric Dumazet wrote:
>> Commit 462fb2af9788a82 (bridge : Sanitize skb before it enters the IP
>> stack), missed one IPCB init before calling ip_options_compile()
>>
>> Thanks to Scot Doyle for his tests and bug reports.
>>
>> Reported-by: Scot Doyle<lkml@scotdoyle.com>
>> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
>> Cc: Hiroaki SHIMODA<shimoda.hiroaki@gmail.com>
>> Acked-by: Bandan Das<bandan.das@stratus.com>
>> Acked-by: Stephen Hemminger<shemminger@vyatta.com>
>> Cc: Jan Lübbe<jluebbe@debian.org>
>> ---
>> net/bridge/br_netfilter.c | 6 ++----
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
>> index 008ff6c..b353f7c 100644
>> --- a/net/bridge/br_netfilter.c
>> +++ b/net/bridge/br_netfilter.c
>> @@ -249,11 +249,9 @@ static int br_parse_ip_options(struct sk_buff *skb)
>> goto drop;
>> }
>>
>> - /* Zero out the CB buffer if no options present */
>> - if (iph->ihl == 5) {
>> - memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
>> + memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
>> + if (iph->ihl == 5)
>> return 0;
>> - }
>>
>> opt->optlen = iph->ihl*4 - sizeof(struct iphdr);
>> if (ip_options_compile(dev_net(dev), opt, skb))
>>
>>
>
>
> Here's the output after pulling 2.6.39-rc3, applying the patches listed
> below, doing a "make clean" and hitting the bridge's assigned ip address
> with the IP Stack Checker tcpsic command. Maybe I should also be
> applying the patch from yesterday too? I'll try that next.
>
> diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
> index 008ff6c..b9bdff9 100644
> --- a/net/bridge/br_netfilter.c
> +++ b/net/bridge/br_netfilter.c
> @@ -249,11 +249,9 @@ static int br_parse_ip_options(struct sk_buff *skb)
> goto drop;
> }
>
> - /* Zero out the CB buffer if no options present */
> - if (iph->ihl == 5) {
> - memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
> - return 0;
> - }
> + memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
> + if (iph->ihl == 5)
> + return 0;
>
> opt->optlen = iph->ihl*4 - sizeof(struct iphdr);
> if (ip_options_compile(dev_net(dev), opt, skb))
>
> diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
> index dd1b20e..9df4e63 100644
> --- a/net/ipv4/inetpeer.c
> +++ b/net/ipv4/inetpeer.c
> @@ -354,7 +354,8 @@ static void inetpeer_free_rcu(struct rcu_head *head)
> }
>
> /* May be called with local BH enabled. */
> -static void unlink_from_pool(struct inet_peer *p, struct inet_peer_base
> *base)
> +static void unlink_from_pool(struct inet_peer *p, struct inet_peer_base
> *base,
> + struct inet_peer __rcu **stack[PEER_MAXDEPTH])
> {
> int do_free;
>
> @@ -368,7 +369,6 @@ static void unlink_from_pool(struct inet_peer *p,
> struct inet_peer_base *base)
> * We use refcnt=-1 to alert lockless readers this entry is deleted.
> */
> if (atomic_cmpxchg(&p->refcnt, 1, -1) == 1) {
> - struct inet_peer __rcu **stack[PEER_MAXDEPTH];
> struct inet_peer __rcu ***stackptr, ***delp;
> if (lookup(&p->daddr, stack, base) != p)
> BUG();
> @@ -422,7 +422,7 @@ static struct inet_peer_base *peer_to_base(struct
> inet_peer *p)
> }
>
> /* May be called with local BH enabled. */
> -static int cleanup_once(unsigned long ttl)
> +static int cleanup_once(unsigned long ttl, struct inet_peer __rcu
> **stack[PEER_MAXDEPTH])
> {
> struct inet_peer *p = NULL;
>
> @@ -454,7 +454,7 @@ static int cleanup_once(unsigned long ttl)
> * happen because of entry limits in route cache. */
> return -1;
>
> - unlink_from_pool(p, peer_to_base(p));
> + unlink_from_pool(p, peer_to_base(p), stack);
> return 0;
> }
>
> @@ -524,7 +524,7 @@ struct inet_peer *inet_getpeer(struct inetpeer_addr
> *daddr, int create)
>
> if (base->total >= inet_peer_threshold)
> /* Remove one less-recently-used entry. */
> - cleanup_once(0);
> + cleanup_once(0, stack);
>
> return p;
> }
> @@ -540,6 +540,7 @@ static void peer_check_expire(unsigned long dummy)
> {
> unsigned long now = jiffies;
> int ttl, total;
> + struct inet_peer __rcu **stack[PEER_MAXDEPTH];
>
> total = compute_total();
> if (total >= inet_peer_threshold)
> @@ -548,7 +549,7 @@ static void peer_check_expire(unsigned long dummy)
> ttl = inet_peer_maxttl
> - (inet_peer_maxttl - inet_peer_minttl) / HZ *
> total / inet_peer_threshold * HZ;
> - while (!cleanup_once(ttl)) {
> + while (!cleanup_once(ttl, stack)) {
> if (jiffies != now)
> break;
> }
>
> diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
> index 28a736f..dea9947 100644
> --- a/net/ipv4/ip_options.c
> +++ b/net/ipv4/ip_options.c
> @@ -200,6 +200,11 @@ int ip_options_echo(struct ip_options * dopt,
> struct sk_buff * skb)
> *dptr++ = IPOPT_END;
> dopt->optlen++;
> }
> + if (unlikely(dopt->optlen > 40)) {
> + pr_err("ip_options_echo() fatal error optlen=%u > 40\n", dopt->optlen);
> + print_hex_dump(KERN_ERR, "ip options: ", DUMP_PREFIX_OFFSET,
> + 16, 1, dopt->__data, dopt->optlen, false);
> + }
> return 0;
> }
>
>
> ------------
>
>
> [ 761.720393] BUG: unable to handle kernel NULL pointer dereference at
> 00000000000000d0
> [ 761.728206] IP: [<ffffffff8129fbe9>] ip_options_compile+0x1c1/0x435
> [ 761.734452] PGD 0
> [ 761.736459] Oops: 0000 [#1] SMP
> [ 761.739683] last sysfs file: /sys/devices/virtual/misc/kvm/uevent
> [ 761.745744] CPU 0
> [ 761.747570] Modules linked in: kvm_intel kvm bridge stp loop snd_pcm
> snd_timer snd tpm_tis tpm tpm_bios soundcore psmouse snd_page_alloc
> processor ghes thermal_sys
> i7core_edac evdev pcspkr serio_raw edac_core dcdbas power_meter button
> hed ext2 mbcache dm_mod raid1 md_mod sd_mod crc_t10dif usb_storage uas
> uhci_hcd ehci_hcd mpt2sas
> scsi_transport_sas raid_class igb scsi_mod usbcore bnx2 dca [last
> unloaded: scsi_wait_scan]
> [ 761.785171]
> [ 761.786651] Pid: 0, comm: swapper Not tainted 2.6.39-rc3+ #14 Dell
> Inc. PowerEdge R510/0DPRKF
> [ 761.795157] RIP: 0010:[<ffffffff8129fbe9>] [<ffffffff8129fbe9>]
> ip_options_compile+0x1c1/0x435
> [ 761.803823] RSP: 0018:ffff88042f203af0 EFLAGS: 00010286
> [ 761.809106] RAX: 0000000000000017 RBX: ffff8804027b3600 RCX:
> ffff88040466a864
> [ 761.816205] RDX: 000000000000001a RSI: 0000000000000000 RDI:
> ffffffff817e6100
> [ 761.823304] RBP: ffff88040466a862 R08: ffffffffa01d6e89 R09:
> ffff88042f203c58
> [ 761.830402] R10: 0000000000000000 R11: 0000000000000000 R12:
> ffff8804027b3628
> [ 761.837501] R13: 000000000000001d R14: ffff88040466a84e R15:
> 0000000000000024
> [ 761.844601] FS: 0000000000000000(0000) GS:ffff88042f200000(0000)
> knlGS:0000000000000000
> [ 761.852650] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 761.858365] CR2: 00000000000000d0 CR3: 0000000001603000 CR4:
> 00000000000006f0
> [ 761.865463] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ 761.872562] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [ 761.879661] Process swapper (pid: 0, threadinfo ffffffff81600000, task
> ffffffff8160b020)
> [ 761.887710] Stack:
> [ 761.889708] 0000000000000000 ffffffff81276928 0000000000000000
> ffffffff817e6100
> [ 761.897102] 000000000000004e ffff88040500e600 ffff88040500e600
> ffff8804027b3600
> [ 761.904496] ffff880404fc0000 ffff8804027b3628 0000000000000000
> ffff880404fc0000
> [ 761.911889] Call Trace:
> [ 761.914319] <IRQ>
> [ 761.916413] [<ffffffff81276928>] ? netif_receive_skb+0x52/0x58
> [ 761.922306] [<ffffffffa01dae3b>] ? br_parse_ip_options+0x134/0x1a8
> [bridge]
> [ 761.929319] [<ffffffffa01dbbe0>] ? br_nf_pre_routing+0x348/0x3cb [bridge]
> [ 761.936160] [<ffffffff81298527>] ? nf_iterate+0x41/0x7e
> [ 761.941444] [<ffffffff8104afaa>] ? irq_exit+0x58/0x8f
> [ 761.946556] [<ffffffffa01d6e89>] ? NF_HOOK.clone.4+0x56/0x56 [bridge]
> [ 761.953052] [<ffffffffa01d6e89>] ? NF_HOOK.clone.4+0x56/0x56 [bridge]
> [ 761.959546] [<ffffffff812985d7>] ? nf_hook_slow+0x73/0x114
> [ 761.965089] [<ffffffffa01d6e89>] ? NF_HOOK.clone.4+0x56/0x56 [bridge]
> [ 761.971583] [<ffffffff8126d097>] ? __netdev_alloc_skb+0x15/0x2f
> [ 761.977561] [<ffffffffa01d6e89>] ? NF_HOOK.clone.4+0x56/0x56 [bridge]
> [ 761.984055] [<ffffffffa01d6e6f>] ? NF_HOOK.clone.4+0x3c/0x56 [bridge]
> [ 761.990551] [<ffffffff812a7dde>] ? tcp_gro_receive+0xa1/0x204
> [ 761.996355] [<ffffffffa01d71e5>] ? br_handle_frame+0x195/0x1ac [bridge]
> [ 762.003022] [<ffffffffa01d7050>] ? br_handle_frame_finish+0x1c7/0x1c7
> [bridge]
> [ 762.010294] [<ffffffff812764ef>] ? __netif_receive_skb+0x2a7/0x450
> [ 762.016530] [<ffffffff81276928>] ? netif_receive_skb+0x52/0x58
> [ 762.022420] [<ffffffff81276e2a>] ? napi_gro_receive+0x1f/0x2f
> [ 762.028222] [<ffffffff812769ff>] ? napi_skb_finish+0x1c/0x31
> [ 762.033941] [<ffffffffa024afcd>] ? igb_poll+0x6d9/0x9ee [igb]
> [ 762.039744] [<ffffffff8109034f>] ? handle_irq_event+0x40/0x55
> [ 762.045547] [<ffffffff8106fc3c>] ? arch_local_irq_save+0x14/0x1d
> [ 762.051609] [<ffffffff81276f55>] ? net_rx_action+0xa4/0x1b1
> [ 762.057239] [<ffffffff8104ad26>] ? __do_softirq+0xb8/0x176
> [ 762.062783] [<ffffffff81333cdc>] ? call_softirq+0x1c/0x30
> [ 762.068241] [<ffffffff8100aa57>] ? do_softirq+0x3f/0x84
> [ 762.073524] [<ffffffff8104af91>] ? irq_exit+0x3f/0x8f
> [ 762.078635] [<ffffffff8100a793>] ? do_IRQ+0x85/0x9e
> [ 762.083575] [<ffffffff8132cc53>] ? common_interrupt+0x13/0x13
> [ 762.089375] <EOI>
> [ 762.091469] [<ffffffff81061348>] ? enqueue_hrtimer+0x3f/0x53
> [ 762.097188] [<ffffffffa0430417>] ? arch_local_irq_enable+0x7/0x8
> [processor]
> [ 762.104288] [<ffffffffa0430dab>] ? acpi_idle_enter_c1+0x86/0xa2
> [processor]
> [ 762.111303] [<ffffffff8125d05d>] ? cpuidle_idle_call+0xf4/0x17e
> [ 762.117277] [<ffffffff81008298>] ? cpu_idle+0xa2/0xc4
> [ 762.122388] [<ffffffff8169db60>] ? start_kernel+0x3b9/0x3c4
> [ 762.128018] [<ffffffff8169d3c6>] ? x86_64_start_kernel+0x102/0x10f
> [ 762.134253] Code: 4d 02 3c 03 0f 86 59 02 00 00 0f b6 d0 44 39 ea 7f
> 32 83 c2 03 44 39 ea 0f 8f 45 02 00 00 48 85 db 74 18 48 8b 74 24 10 0f
> b6 c0 <8b> 96 d0 00 00 00 89 54 05 ff 41 80 4c 24 08 04 80 01 04 41 80
> [ 762.153593] RIP [<ffffffff8129fbe9>] ip_options_compile+0x1c1/0x435
> [ 762.159923] RSP <ffff88042f203af0>
> [ 762.163391] CR2: 00000000000000d0
> [ 762.167017] ---[ end trace e15d7b082f680b62 ]---
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Good news! I cannot create any kernel panics with the following patches
to 2.6.39-rc3 commit a6360dd37e1a144ed11e6548371bade559a1e4df while
targeting either the host's bridged IP address or the guest virtual
machine bridged IP addresses with the IP Stack Checker tools.
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 008ff6c..cdb4423 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -221,6 +221,7 @@ static int br_parse_ip_options(struct sk_buff *skb)
struct ip_options *opt;
struct iphdr *iph;
struct net_device *dev = skb->dev;
+ struct rtable *rt;
u32 len;
iph = ip_hdr(skb);
@@ -249,10 +250,18 @@ static int br_parse_ip_options(struct sk_buff *skb)
goto drop;
}
- /* Zero out the CB buffer if no options present */
- if (iph->ihl == 5) {
- memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
- return 0;
+ memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
+ if (iph->ihl == 5)
+ return 0;
+
+ /* Associate bogus bridge route table */
+ if (!skb_dst(skb)) {
+ rt = bridge_parent_rtable(dev);
+ if (!rt) {
+ kfree_skb(skb);
+ return 0;
+ }
+ skb_dst_set_noref(skb,&rt->dst);
}
opt->optlen = iph->ihl*4 - sizeof(struct iphdr);
diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
index dd1b20e..9df4e63 100644
--- a/net/ipv4/inetpeer.c
+++ b/net/ipv4/inetpeer.c
@@ -354,7 +354,8 @@ static void inetpeer_free_rcu(struct rcu_head *head)
}
/* May be called with local BH enabled. */
-static void unlink_from_pool(struct inet_peer *p, struct inet_peer_base
*base)
+static void unlink_from_pool(struct inet_peer *p, struct inet_peer_base
*base,
+ struct inet_peer __rcu **stack[PEER_MAXDEPTH])
{
int do_free;
@@ -368,7 +369,6 @@ static void unlink_from_pool(struct inet_peer *p,
struct inet_peer_base *base)
* We use refcnt=-1 to alert lockless readers this entry is
deleted.
*/
if (atomic_cmpxchg(&p->refcnt, 1, -1) == 1) {
- struct inet_peer __rcu **stack[PEER_MAXDEPTH];
struct inet_peer __rcu ***stackptr, ***delp;
if (lookup(&p->daddr, stack, base) != p)
BUG();
@@ -422,7 +422,7 @@ static struct inet_peer_base *peer_to_base(struct
inet_peer *p)
}
/* May be called with local BH enabled. */
-static int cleanup_once(unsigned long ttl)
+static int cleanup_once(unsigned long ttl, struct inet_peer __rcu
**stack[PEER_MAXDEPTH])
{
struct inet_peer *p = NULL;
@@ -454,7 +454,7 @@ static int cleanup_once(unsigned long ttl)
* happen because of entry limits in route cache. */
return -1;
- unlink_from_pool(p, peer_to_base(p));
+ unlink_from_pool(p, peer_to_base(p), stack);
return 0;
}
@@ -524,7 +524,7 @@ struct inet_peer *inet_getpeer(struct inetpeer_addr
*daddr, int create)
if (base->total >= inet_peer_threshold)
/* Remove one less-recently-used entry. */
- cleanup_once(0);
+ cleanup_once(0, stack);
return p;
}
@@ -540,6 +540,7 @@ static void peer_check_expire(unsigned long dummy)
{
unsigned long now = jiffies;
int ttl, total;
+ struct inet_peer __rcu **stack[PEER_MAXDEPTH];
total = compute_total();
if (total >= inet_peer_threshold)
@@ -548,7 +549,7 @@ static void peer_check_expire(unsigned long dummy)
ttl = inet_peer_maxttl
- (inet_peer_maxttl - inet_peer_minttl)
/ HZ *
total / inet_peer_threshold * HZ;
- while (!cleanup_once(ttl)) {
+ while (!cleanup_once(ttl, stack)) {
if (jiffies != now)
break;
}
^ permalink raw reply related
* Re: [PATCH] e1000: Remove blink_led_start declaration
From: Jeff Kirsher @ 2011-04-13 3:53 UTC (permalink / raw)
To: Yinghai Lu; +Cc: Jesse Brandeburg, e1000-devel, NetDev
In-Reply-To: <4DA4E016.1050800@kernel.org>
On Tue, Apr 12, 2011 at 16:28, Yinghai Lu <yinghai@kernel.org> wrote:
>
> It is left over code.
>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>
> ---
> drivers/net/e1000/e1000_hw.h | 1 -
> 1 file changed, 1 deletion(-)
>
Thanks for the patch, I have added the patch to my queue of e1000
patches.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [stable] [PATCH NET-2.6 1/1] qlcnic: limit skb frags for non tso packet
From: Greg KH @ 2011-04-13 3:42 UTC (permalink / raw)
To: Amit Salecha
Cc: David Miller, netdev@vger.kernel.org, Anirban Chakraborty,
stable@kernel.org, Ameen Rahman
In-Reply-To: <99737F4847ED0A48AECC9F4A1974A4B80FD1383FAC@MNEXMB2.qlogic.org>
On Tue, Apr 12, 2011 at 09:01:13PM -0500, Amit Salecha wrote:
>
> This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
I have received this transmission in error.
Please remove this from your footer, otherwise we can not accept any
emails sent from you as actually being allowed to contribute to the
kernel properly :(
thanks,
greg k-h
^ permalink raw reply
* [NET-2.6 PATCHv2 0/1]qlcnic: bug fix
From: amit.salecha @ 2011-04-13 3:05 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty
David,
Apply this fix to net-2.6. this is series two as earlier email got corrupted.
Same netxen_nic apply to qlcnic.
This patch will give hunk failure while merging to net-next tree.
Two lines below diff has changed in qlcnic_xmit_frame().
Sorry, for all spam and corrupted emails. I understand your work load and
this nuisance really distrubed all people. As people give their precious time
in reviewing patches.
Going forward will make sure these type of events not repeated by Qlogic.
-Amit
^ permalink raw reply
* [PATCHv2 NET-2.6 1/1] qlcnic: limit skb frags for non tso packet
From: amit.salecha @ 2011-04-13 3:05 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, Amit Kumar Salecha,
stable
In-Reply-To: <1302663955-31849-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Machines are getting deadlock in four node cluster environment.
All nodes are accessing (find /gfs2 -depth -print|cpio -ocv > /dev/null)
200 GB storage on a GFS2 filesystem.
This result in memory fragmentation and driver receives 18 frags for
1448 byte packets.
For non tso packet, fw drops the tx request, if it has >14 frags.
Fixing it by pulling extra frags.
Cc: stable@kernel.org
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 1 +
drivers/net/qlcnic/qlcnic_main.c | 14 ++++++++++++++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index dc44564..b0dead0 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -99,6 +99,7 @@
#define TX_UDPV6_PKT 0x0c
/* Tx defines */
+#define QLCNIC_MAX_FRAGS_PER_TX 14
#define MAX_TSO_HEADER_DESC 2
#define MGMT_CMD_DESC_RESV 4
#define TX_STOP_THRESH ((MAX_SKB_FRAGS >> 2) + MAX_TSO_HEADER_DESC \
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index cd88c7e..cb1a1ef 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -2099,6 +2099,7 @@ qlcnic_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
struct cmd_desc_type0 *hwdesc, *first_desc;
struct pci_dev *pdev;
struct ethhdr *phdr;
+ int delta = 0;
int i, k;
u32 producer;
@@ -2118,6 +2119,19 @@ qlcnic_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
}
frag_count = skb_shinfo(skb)->nr_frags + 1;
+ /* 14 frags supported for normal packet and
+ * 32 frags supported for TSO packet
+ */
+ if (!skb_is_gso(skb) && frag_count > QLCNIC_MAX_FRAGS_PER_TX) {
+
+ for (i = 0; i < (frag_count - QLCNIC_MAX_FRAGS_PER_TX); i++)
+ delta += skb_shinfo(skb)->frags[i].size;
+
+ if (!__pskb_pull_tail(skb, delta))
+ goto drop_packet;
+
+ frag_count = 1 + skb_shinfo(skb)->nr_frags;
+ }
/* 4 fragments per cmd des */
no_of_desc = (frag_count + 3) >> 2;
--
1.6.0.2
^ permalink raw reply related
* Re: [Bugme-new] [Bug 32832] New: shutdown(2) does not fully shut down socket any more
From: Eric Dumazet @ 2011-04-13 3:00 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, bugzilla-daemon, bugme-daemon, kees
In-Reply-To: <1302663327.2811.55.camel@edumazet-laptop>
Le mercredi 13 avril 2011 à 04:55 +0200, Eric Dumazet a écrit :
> Since SO_REUSEPORT is not a 'stable fix', I suggest we revert the patch,
> and eventually work on SO_REUSEPORT on net-next-2.6
>
> What do you think ?
>
Sorry, I should have mentioned commit id : c191a836a908d1dd6
(tcp: disallow bind() to reuse addr/port)
^ permalink raw reply
* Re: [Bugme-new] [Bug 32832] New: shutdown(2) does not fully shut down socket any more
From: Eric Dumazet @ 2011-04-13 2:55 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, bugzilla-daemon, bugme-daemon, kees
In-Reply-To: <20110412.161744.27803776.davem@davemloft.net>
Le mardi 12 avril 2011 à 16:17 -0700, David Miller a écrit :
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Tue, 12 Apr 2011 16:15:56 -0700
>
> >
> > (switched to email. Please respond via emailed reply-to-all, not via the
> > bugzilla web interface).
>
> Stephen Hemminger forwarded this to the list last week, and Eric
> Dumazet is actively working on a fix.
I worked on it this week end to discover FreeBSD 8.1 would not allow
several CLOSE sockets bound to same port even with REUSEADDR.
So haproxy claim is a bit wrong (its trick doesnt work on FreeBSD), and
used an undocumented linux feature.
I feel this case is a call for SO_REUSEPORT, eventually.
http://www.unixguide.net/network/socketfaq/4.11.shtml
SO_REUSEADDR allows your server to bind to an address which is in a
TIME_WAIT state. It does not allow more than one server to bind to
the same address. It was mentioned that use of this flag can create a
security risk because another server can bind to a the same port, by
binding to a specific address as opposed to INADDR_ANY. The
SO_REUSEPORT flag allows multiple processes to bind to the same
address provided all of them use the SO_REUSEPORT option.
Since SO_REUSEPORT is not a 'stable fix', I suggest we revert the patch,
and eventually work on SO_REUSEPORT on net-next-2.6
What do you think ?
^ permalink raw reply
* Re: [PATCH] sctp: fix oops while removed transport still using as retran path
From: David Miller @ 2011-04-13 2:34 UTC (permalink / raw)
To: yjwei; +Cc: netdev, linux-sctp
In-Reply-To: <4DA4FACE.5060706@cn.fujitsu.com>
From: Wei Yongjun <yjwei@cn.fujitsu.com>
Date: Wed, 13 Apr 2011 09:22:22 +0800
> Since we can not update retran path to unconfirmed transports,
> when we remove a peer, the retran path may not be update if the
> other transports are all unconfirmed, and we will still using
> the removed transport as the retran path. This may cause panic
> if retrasnmit happen.
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Applied.
^ permalink raw reply
* Re: [PATCH] sctp: fix oops when updating retransmit path with DEBUG on
From: David Miller @ 2011-04-13 2:34 UTC (permalink / raw)
To: yjwei; +Cc: netdev, linux-sctp
In-Reply-To: <4DA4FA70.50506@cn.fujitsu.com>
From: Wei Yongjun <yjwei@cn.fujitsu.com>
Date: Wed, 13 Apr 2011 09:20:48 +0800
> From: Vlad Yasevich <vladislav.yasevich@hp.com>
>
> commit fbdf501c9374966a56829ecca3a7f25d2b49a305
> sctp: Do no select unconfirmed transports for retransmissions
>
> Introduced the initial falt.
>
> commit d598b166ced20d9b9281ea3527c0e18405ddb803
> sctp: Make sure we always return valid retransmit path
>
> Solved the problem, but forgot to change the DEBUG statement.
> Thus it was still possible to dereference a NULL pointer.
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6 2/2] net: Disable NETIF_F_TSO_ECN when TSO is disabled
From: David Miller @ 2011-04-13 2:30 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, mirq-linux
In-Reply-To: <1302655635.2880.35.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 13 Apr 2011 01:47:15 +0100
> NETIF_F_TSO_ECN has no effect when TSO is disabled; this just means
> that feature state will be accurately reported to user-space.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6 1/2] net: Disable all TSO features when SG is disabled
From: David Miller @ 2011-04-13 2:29 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, mirq-linux
In-Reply-To: <1302655117.2880.33.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 13 Apr 2011 01:38:37 +0100
> The feature flags NETIF_F_TSO and NETIF_F_TSO6 independently enable
> TSO for IPv4 and IPv6 respectively. However, the test in
> netdev_fix_features() and its predecessor functions was never updated
> to check for NETIF_F_TSO6, possibly because it was originally proposed
> that TSO for IPv6 would be dependent on both feature flags.
>
> Now that these feature flags can be changed independently from
> user-space and we depend on netdev_fix_features() to fix invalid
> feature combinations, it's important to disable them both if
> scatter-gather is disabled. Also disable NETIF_F_TSO_ECN so
> user-space sees all TSO features as disabled.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: David Miller @ 2011-04-13 2:28 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, jpirko
In-Reply-To: <20110413120323.36030bcf.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 13 Apr 2011 12:03:23 +1000
> After merging the net tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/infiniband/ulp/iser/iser_initiator.o: In function `vlan_untag':
> iser_initiator.c:(.opd+0x0): multiple definition of `vlan_untag'
> drivers/infiniband/ulp/iser/iser_verbs.o:iser_verbs.c:(.opd+0x0): first defined here
> drivers/infiniband/ulp/iser/iser_initiator.o: In function `.vlan_untag':
> iser_initiator.c:(.text+0x0): multiple definition of `.vlan_untag'
> drivers/infiniband/ulp/iser/iser_verbs.o:iser_verbs.c:(.text+0x0): first defined here
>
> and on and on ... (lota and lots :-()
Strange, I wonder why this driver isn't enabled in my allmodconfig builds.
Let's see.
Oh, this driver depends upon INFINIBAND_ADDR_TRANS which will never be
enabled if IPV6=m, because of:
config INFINIBAND_ADDR_TRANS
bool
depends on INET
depends on !(INFINIBAND = y && IPV6 = m)
default y
come on...
> Probably caused by commit bcc6d4790361 ("net: vlan: make non-hw-accel rx
> path similar to hw-accel") which added a "non-static" inline version of
> vlan_untag() to include/linux/if_vlan.h.
Yeah, this issue is not specific to this driver and actually is just
a missing "static" in the vlan disabled case.
I'll add the following fix, thanks Stephen.
--------------------
net: Missing 'inline' in vlan-disabled vlan_untag()
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/linux/if_vlan.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index 998b299..546d9d3 100644
--- a/include/linux/if_vlan.h
+++ b/include/linux/if_vlan.h
@@ -174,7 +174,7 @@ static inline bool vlan_do_receive(struct sk_buff **skb)
return false;
}
-inline struct sk_buff *vlan_untag(struct sk_buff *skb)
+static inline struct sk_buff *vlan_untag(struct sk_buff *skb)
{
return skb;
}
--
1.7.4.3
^ permalink raw reply related
* linux-next: build failure after merge of the net tree
From: Stephen Rothwell @ 2011-04-13 2:03 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Jiri Pirko
[-- Attachment #1: Type: text/plain, Size: 963 bytes --]
Hi all,
After merging the net tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/infiniband/ulp/iser/iser_initiator.o: In function `vlan_untag':
iser_initiator.c:(.opd+0x0): multiple definition of `vlan_untag'
drivers/infiniband/ulp/iser/iser_verbs.o:iser_verbs.c:(.opd+0x0): first defined here
drivers/infiniband/ulp/iser/iser_initiator.o: In function `.vlan_untag':
iser_initiator.c:(.text+0x0): multiple definition of `.vlan_untag'
drivers/infiniband/ulp/iser/iser_verbs.o:iser_verbs.c:(.text+0x0): first defined here
and on and on ... (lota and lots :-()
Probably caused by commit bcc6d4790361 ("net: vlan: make non-hw-accel rx
path similar to hw-accel") which added a "non-static" inline version of
vlan_untag() to include/linux/if_vlan.h.
I have used the net tree from next-20110412 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* RE: [PATCH NET-2.6 1/1] qlcnic: limit skb frags for non tso packet
From: Amit Salecha @ 2011-04-13 2:01 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, Ameen Rahman, Anirban Chakraborty,
stable@kernel.org
In-Reply-To: <20110412.135522.71113479.davem@davemloft.net>
> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
> Date: Tue, 12 Apr 2011 00:19:41 -0700
>
> > <<< No Message Collected >>>
>
> Can you PLEASE fix your email.
>
> PLEASE?
>
> Yesterday you spammed us all, and today you've sent three postings
> with this subject line.
>
> 1) One with the patch, and the proper set of CC:'s (myself, other
> qlogic engineers, netdev, and stable)
>
> 2) One with the patch, and a too short CC: list (only netdev and
> stable)
>
> 3) And now this email with no actual content and a weird message.
>
> I really can't spend my afternoons sifting through the emails that
> spam from qlogic, trying to figure out which ones I should pay
> attention to for review, and which ones are spam.
>
> Please resend properly any patches you actually want me to pay
> attention to.
>
> If you cannot make sure at this time that the patches will be sent
> without incident, sit on them until you can.
>
> Thank you.
Sorry for all this. Yesterday, 1st patch got send to all other than netdev mailing list.
So I resend that to netdev mailing list. I didn't cc all other, as they will receive duplicate email.
In all these header patch got corrupted. Our IT is working on it and soon will resolve all these problem.
I will resend patch with version 2.
-Amit
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox