* [patch -next] netfilter: use kfree_skb() not kfree()
From: Dan Carpenter @ 2012-06-30 11:48 UTC (permalink / raw)
To: Bart De Schuymer
Cc: coreteam, netdev, bridge, kernel-janitors, David S. Miller,
netfilter, netfilter-devel, Stephen Hemminger, Pablo Neira Ayuso
This was should be a kfree_skb() here to free the sk_buff pointer.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/net/bridge/netfilter/ebt_ulog.c b/net/bridge/netfilter/ebt_ulog.c
index 1bd1732..dfbb019 100644
--- a/net/bridge/netfilter/ebt_ulog.c
+++ b/net/bridge/netfilter/ebt_ulog.c
@@ -156,7 +156,7 @@ static void ebt_ulog_packet(unsigned int hooknr, const struct sk_buff *skb,
nlh = nlmsg_put(ub->skb, 0, ub->qlen, 0,
size - NLMSG_ALIGN(sizeof(*nlh)), 0);
if (!nlh) {
- kfree(ub->skb);
+ kfree_skb(ub->skb);
ub->skb = NULL;
goto unlock;
}
^ permalink raw reply related
* [patch] [SCSI] bnx2i: use strlcpy() instead of memcpy() for strings
From: Dan Carpenter @ 2012-06-30 11:49 UTC (permalink / raw)
To: James E.J. Bottomley, Barak Witkowski
Cc: Eddie Wai, Michael Chan, linux-scsi, netdev, David S. Miller
DRV_MODULE_VERSION here is "2.7.2.2" which is only 8 chars but we copy
12 bytes from the stack so it's a small information leak.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
This was just added to linux-next yesterday, but I'm not sure which tree
it came from.
diff --git a/drivers/scsi/bnx2i/bnx2i_init.c b/drivers/scsi/bnx2i/bnx2i_init.c
index 7729a52..b17637a 100644
--- a/drivers/scsi/bnx2i/bnx2i_init.c
+++ b/drivers/scsi/bnx2i/bnx2i_init.c
@@ -400,7 +400,7 @@ int bnx2i_get_stats(void *handle)
if (!stats)
return -ENOMEM;
- memcpy(stats->version, DRV_MODULE_VERSION, sizeof(stats->version));
+ strlcpy(stats->version, DRV_MODULE_VERSION, sizeof(stats->version));
memcpy(stats->mac_add1 + 2, hba->cnic->mac_addr, ETH_ALEN);
stats->max_frame_size = hba->netdev->mtu;
^ permalink raw reply related
* Re: [PATCH V3 2/2] bonding support for IPv6 transmit hashing
From: Hannes Frederic Sowa @ 2012-06-30 11:59 UTC (permalink / raw)
To: John; +Cc: netdev
In-Reply-To: <4FEE99EE.2000001@8192.net>
On Sat, Jun 30, 2012 at 8:17 AM, John <linux@8192.net> wrote:
> diff --git a/Documentation/networking/bonding.txt
> b/Documentation/networking/bonding.txt
> index bfea8a3..5db14fe 100644
> --- a/Documentation/networking/bonding.txt
> +++ b/Documentation/networking/bonding.txt
> @@ -752,12 +752,22 @@ xmit_hash_policy
> protocol information to generate the hash.
>
> Uses XOR of hardware MAC addresses and IP addresses to
> - generate the hash. The formula is
> + generate the hash. The IPv4 formula is
>
> (((source IP XOR dest IP) AND 0xffff) XOR
> ( source MAC XOR destination MAC ))
> modulo slave count
>
> + The IPv6 forumla is
> +
> + iphash =
> + (source ip quad 2 XOR dest IP quad 2) XOR
> + (source ip quad 3 XOR dest IP quad 3) XOR
> + (source ip quad 4 XOR dest IP quad 4)
> +
> + ((iphash >> 16) XOR (iphash >> 8) XOR iphash)
> + modulo slave count
> +
Wouldn't it be beneficial to include the ipv6 flow label in the hash
calculation?
Greetings,
Hannes
^ permalink raw reply
* problems with iproute2 m_xt again...
From: Andreas Henriksson @ 2012-06-30 12:09 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: shemminger, netdev, YANG Zhe
Hello!
Mailing you in hope that you could help out with the xt module of iproute2 tc
once more, as you've done in the past.... It seems to be broken again. sigh.
amd64:~# iptables -nL | grep test
Chain test (0 references)
amd64:~# tc filter add dev fon parent ffff: protocol ip prio 10 u32 action xt -j test
failed to find target test
bad action parsing
parse_action: bad value (3:xt)!
Illegal "action"
amd64:~#
And maybe even more interesting is when I try to use a built-in chain like DROP:
amd64:~# tc filter add dev fon parent ffff: protocol ip prio 10 u32 action xt -j DROP
tablename: mangle hook: NF_IP_PRE_ROUTING
Segmentation fault
amd64:~#
(gdb) set args filter add dev fon parent ffff: protocol ip prio 10 u32 action xt -j DROP
(gdb) run
Starting program: /home/gem/opt/pkg-iproute/iproute/tc/tc filter add dev fon parent ffff: protocol ip prio 10 u32 action xt -j DROP
tablename: mangle hook: NF_IP_PRE_ROUTING
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
Starting program: tc filter add dev fon parent ffff: protocol ip prio 10 u32 action xt -j DROP
tablename: mangle hook: NF_IP_PRE_ROUTING
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff71b87a0 in parse_ipt (a=0x7ffff73b9500, argc_p=0x7fffffff9e94,
argv_p=0x7fffffff9e88, tca_id=2, n=0x7fffffffa840) at m_xt.c:230
#2 0x000000000040dc11 in parse_action (argc_p=0x7fffffff9eec,
argv_p=0x7fffffff9ee0, tca_id=7, n=0x7fffffffa840) at m_action.c:214
#3 0x000000000042177e in u32_parse_opt (qu=0x648c80, handle=0x0, argc=3,
argv=0x7fffffffea50, n=0x7fffffffa840) at f_u32.c:1126
#4 0x0000000000409bf8 in tc_filter_modify (cmd=44, flags=1536, argc=4,
argv=0x7fffffffea48) at tc_filter.c:142
#5 0x000000000040a620 in do_filter (argc=14, argv=0x7fffffffe9f8)
at tc_filter.c:357
#6 0x0000000000406c74 in do_cmd (argc=15, argv=0x7fffffffe9f0) at tc.c:199
#7 0x00000000004071ae in main (argc=16, argv=0x7fffffffe9e8) at tc.c:316
This is with the iproute package version 20120521-3 on Debian unstable.
Did I screw anything up? Did I use the wrong commands? Or are things just
broken again?
Btw. I have iptables package version 1.4.14-2
--
Andreas Henriksson
^ permalink raw reply
* possible integer underflow in __sctp_auth_cid()
From: Dan Carpenter @ 2012-06-30 12:17 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: linux-sctp, netdev
In 555d3d5d "SCTP: Fix chunk acceptance when no authenticated chunks
were listed.", we added a check for if (param->param_hdr.length == 0).
Shouldn't that check be a check for if
(param->param_hdr.length < sizeos(sizeof(sctp_paramhdr_t)))? Otherwise,
when we do the substraction on the next line we would unintentionally
end up with a high positive number.
I had a similar question about sctp_auth_ep_add_chunkid():
net/sctp/auth.c
770 /* Check if we can add this chunk to the array */
771 param_len = ntohs(p->param_hdr.length);
772 nchunks = param_len - sizeof(sctp_paramhdr_t);
773 if (nchunks == SCTP_NUM_CHUNK_TYPES)
774 return -EINVAL;
775
776 p->chunks[nchunks] = chunk_id;
If param_len is less than sizeof(sctp_paramhdr_t) we could write past
the end of the array. There are a couple other places with this same
subtraction as well.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v5] sctp: be more restrictive in transport selection on bundled sacks
From: Neil Horman @ 2012-06-30 12:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, vyasevich, linux-sctp
In-Reply-To: <20120629.163408.1111786778802302299.davem@davemloft.net>
On Fri, Jun 29, 2012 at 04:34:08PM -0700, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Fri, 29 Jun 2012 16:15:29 -0400
>
> > + /* Has this transport moved the ctsn since we last sacked */
> > + __u32 sack_generation;
> > +
> ...
> > + __u32 sack_generation;
>
> These are __u32 but they only take on the value '1' or '0'. Please
> use bool and give it a more reasonable name, a name that describes
> how it is really a predicate.
>
This is wrong. Its a counter that increments every time we call sctp_make_sack,
so that we can create a unique generation identifier for use in tagging which
transports move ctsn in a given generation. It saves us from having to iterate
over a list every time we send a sack.
> > - struct sctp_association *asoc;
> > struct timer_list *timer;
> > - asoc = pkt->transport->asoc;
> > + struct sctp_association *asoc = pkt->transport->asoc;
> > +
>
> Please leave asoc where it was, on the first line. We encourage
> listing local variables such that the longest lines come first,
> then gradually shorter and short lines.
>
> > + /*
> > + * Once we have a sack generated, check to see what our sack
> > + * generation is, if its 0, reset the transports to 0, and reset
>
> Please format:
>
> /* Like
> * this.
> */
>
> Thanks.
>
Very well, I'll repost in the next few days
Neil
>
^ permalink raw reply
* Re: AF_BUS socket address family
From: Alan Cox @ 2012-06-30 12:52 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Vincent Sanders, David Miller, netdev, linux-kernel
In-Reply-To: <20120630001350.GS21968@kvack.org>
On Fri, 29 Jun 2012 20:13:50 -0400
Benjamin LaHaise <bcrl@kvack.org> wrote:
> On Sat, Jun 30, 2012 at 12:42:30AM +0100, Vincent Sanders wrote:
> > The current users are suffering from the issues outlined in my
> > introductory mail all the time. These issues are caused by emulating an
> > IPC system over AF_UNIX in userspace.
>
> Nothing in your introductory statements indicate how your requirements
> can't be met through a hybrid socket + shared memory solution. The IPC
> facilities of the kernel are already quite rich, and sufficient for
> building many kinds of complex systems. What's so different about DBus'
> requirements?
dbus wants to
- multicast
- pass file handles
- never lose an event
- be fast
- have a security model
The security model makes a shared memory hack impractical, the file
handle passing means at least some of it needs to be AF_UNIX. The event
loss handling/speed argue for putting it in kernel.
I'm not convinced AF_BUS entirely sorts this either. In particular the
failure case dbus currently has to handle for not losing events allows it
to identify who in a "group" has jammed the bus by not listening (eg by
locking up). This information appears to be lost in the AF_BUS case and
that's slightly catastrophic for error recovery.
Alan
^ permalink raw reply
* [PATCH v6] sctp: be more restrictive in transport selection on bundled sacks
From: Neil Horman @ 2012-06-30 13:04 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Vlad Yaseivch, David S. Miller, linux-sctp
In-Reply-To: <1340742704-2192-1-git-send-email-nhorman@tuxdriver.com>
It was noticed recently that when we send data on a transport, its possible that
we might bundle a sack that arrived on a different transport. While this isn't
a major problem, it does go against the SHOULD requirement in section 6.4 of RFC
2960:
An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
etc.) to the same destination transport address from which it
received the DATA or control chunk to which it is replying. This
rule should also be followed if the endpoint is bundling DATA chunks
together with the reply chunk.
This patch seeks to correct that. It restricts the bundling of sack operations
to only those transports which have moved the ctsn of the association forward
since the last sack. By doing this we guarantee that we only bundle outbound
saks on a transport that has received a chunk since the last sack. This brings
us into stricter compliance with the RFC.
Vlad had initially suggested that we strictly allow only sack bundling on the
transport that last moved the ctsn forward. While this makes sense, I was
concerned that doing so prevented us from bundling in the case where we had
received chunks that moved the ctsn on multiple transports. In those cases, the
RFC allows us to select any of the transports having received chunks to bundle
the sack on. so I've modified the approach to allow for that, by adding a state
variable to each transport that tracks weather it has moved the ctsn since the
last sack. This I think keeps our behavior (and performance), close enough to
our current profile that I think we can do this without a sysctl knob to
enable/disable it.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Vlad Yaseivch <vyasevich@gmail.com>
CC: David S. Miller <davem@davemloft.net>
CC: linux-sctp@vger.kernel.org
Reported-by: Michele Baldessari <michele@redhat.com>
Reported-by: sorin serban <sserban@redhat.com>
---
Change Notes:
V2)
* Removed unused variable as per Dave M. Request
* Delayed rwnd adjustment until we are sure we will sack (Vlad Y.)
V3)
* Switched test to use pkt->transport rather than chunk->transport
* Modified detection of sacka-able transport. Instead of just setting
and clearning a flag, we now mark each transport and association with
a sack generation tag. We increment the associations generation on
every sack, and assign that generation tag to every transport that
updates the ctsn. This prevents us from having to iterate over a for
loop on every sack, which is much more scalable.
V4)
* Fixed up wrapping comment and logic
V5)
* Simplified wrap logic further per request from vlad
V6)
* Changed some style point as per request from Dave M.
---
include/net/sctp/structs.h | 4 ++++
include/net/sctp/tsnmap.h | 3 ++-
net/sctp/associola.c | 1 +
net/sctp/output.c | 5 +++++
net/sctp/sm_make_chunk.c | 16 ++++++++++++++++
net/sctp/sm_sideeffect.c | 2 +-
net/sctp/transport.c | 2 ++
net/sctp/tsnmap.c | 6 +++++-
net/sctp/ulpevent.c | 3 ++-
net/sctp/ulpqueue.c | 2 +-
10 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index e4652fe..fecdf31 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -912,6 +912,9 @@ struct sctp_transport {
/* Is this structure kfree()able? */
malloced:1;
+ /* Has this transport moved the ctsn since we last sacked */
+ __u32 sack_generation;
+
struct flowi fl;
/* This is the peer's IP address and port. */
@@ -1584,6 +1587,7 @@ struct sctp_association {
*/
__u8 sack_needed; /* Do we need to sack the peer? */
__u32 sack_cnt;
+ __u32 sack_generation;
/* These are capabilities which our peer advertised. */
__u8 ecn_capable:1, /* Can peer do ECN? */
diff --git a/include/net/sctp/tsnmap.h b/include/net/sctp/tsnmap.h
index e7728bc..2c5d2b4 100644
--- a/include/net/sctp/tsnmap.h
+++ b/include/net/sctp/tsnmap.h
@@ -117,7 +117,8 @@ void sctp_tsnmap_free(struct sctp_tsnmap *map);
int sctp_tsnmap_check(const struct sctp_tsnmap *, __u32 tsn);
/* Mark this TSN as seen. */
-int sctp_tsnmap_mark(struct sctp_tsnmap *, __u32 tsn);
+int sctp_tsnmap_mark(struct sctp_tsnmap *, __u32 tsn,
+ struct sctp_transport *trans);
/* Mark this TSN and all lower as seen. */
void sctp_tsnmap_skip(struct sctp_tsnmap *map, __u32 tsn);
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index 5bc9ab1..b16517e 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -271,6 +271,7 @@ static struct sctp_association *sctp_association_init(struct sctp_association *a
*/
asoc->peer.sack_needed = 1;
asoc->peer.sack_cnt = 0;
+ asoc->peer.sack_generation = 1;
/* Assume that the peer will tell us if he recognizes ASCONF
* as part of INIT exchange.
diff --git a/net/sctp/output.c b/net/sctp/output.c
index f1b7d4b..6ae47ac 100644
--- a/net/sctp/output.c
+++ b/net/sctp/output.c
@@ -248,6 +248,11 @@ static sctp_xmit_t sctp_packet_bundle_sack(struct sctp_packet *pkt,
/* If the SACK timer is running, we have a pending SACK */
if (timer_pending(timer)) {
struct sctp_chunk *sack;
+
+ if (pkt->transport->sack_generation !=
+ pkt->transport->asoc->peer.sack_generation)
+ return retval;
+
asoc->a_rwnd = asoc->rwnd;
sack = sctp_make_sack(asoc);
if (sack) {
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index a85eeeb..098cff5 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -734,8 +734,10 @@ struct sctp_chunk *sctp_make_sack(const struct sctp_association *asoc)
int len;
__u32 ctsn;
__u16 num_gabs, num_dup_tsns;
+ struct sctp_association *aptr = (struct sctp_association *)asoc;
struct sctp_tsnmap *map = (struct sctp_tsnmap *)&asoc->peer.tsn_map;
struct sctp_gap_ack_block gabs[SCTP_MAX_GABS];
+ struct sctp_transport *trans;
memset(gabs, 0, sizeof(gabs));
ctsn = sctp_tsnmap_get_ctsn(map);
@@ -805,6 +807,20 @@ struct sctp_chunk *sctp_make_sack(const struct sctp_association *asoc)
sctp_addto_chunk(retval, sizeof(__u32) * num_dup_tsns,
sctp_tsnmap_get_dups(map));
+ /* Once we have a sack generated, check to see what our sack
+ * generation is, if its 0, reset the transports to 0, and reset
+ * the association generation to 1
+ *
+ * The idea is that zero is never used as a valid generation for the
+ * association so no transport will match after a wrap event like this,
+ * Until the next sack
+ */
+ if (++aptr->peer.sack_generation == 0) {
+ list_for_each_entry(trans, &asoc->peer.transport_addr_list,
+ transports)
+ trans->sack_generation = 0;
+ aptr->peer.sack_generation = 1;
+ }
nodata:
return retval;
}
diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index c96d1a8..8716da1 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -1268,7 +1268,7 @@ static int sctp_cmd_interpreter(sctp_event_t event_type,
case SCTP_CMD_REPORT_TSN:
/* Record the arrival of a TSN. */
error = sctp_tsnmap_mark(&asoc->peer.tsn_map,
- cmd->obj.u32);
+ cmd->obj.u32, NULL);
break;
case SCTP_CMD_REPORT_FWDTSN:
diff --git a/net/sctp/transport.c b/net/sctp/transport.c
index b026ba0..1dcceb6 100644
--- a/net/sctp/transport.c
+++ b/net/sctp/transport.c
@@ -68,6 +68,8 @@ static struct sctp_transport *sctp_transport_init(struct sctp_transport *peer,
peer->af_specific = sctp_get_af_specific(addr->sa.sa_family);
memset(&peer->saddr, 0, sizeof(union sctp_addr));
+ peer->sack_generation = 0;
+
/* From 6.3.1 RTO Calculation:
*
* C1) Until an RTT measurement has been made for a packet sent to the
diff --git a/net/sctp/tsnmap.c b/net/sctp/tsnmap.c
index f1e40ceb..b5fb7c4 100644
--- a/net/sctp/tsnmap.c
+++ b/net/sctp/tsnmap.c
@@ -114,7 +114,8 @@ int sctp_tsnmap_check(const struct sctp_tsnmap *map, __u32 tsn)
/* Mark this TSN as seen. */
-int sctp_tsnmap_mark(struct sctp_tsnmap *map, __u32 tsn)
+int sctp_tsnmap_mark(struct sctp_tsnmap *map, __u32 tsn,
+ struct sctp_transport *trans)
{
u16 gap;
@@ -133,6 +134,9 @@ int sctp_tsnmap_mark(struct sctp_tsnmap *map, __u32 tsn)
*/
map->max_tsn_seen++;
map->cumulative_tsn_ack_point++;
+ if (trans)
+ trans->sack_generation =
+ trans->asoc->peer.sack_generation;
map->base_tsn++;
} else {
/* Either we already have a gap, or about to record a gap, so
diff --git a/net/sctp/ulpevent.c b/net/sctp/ulpevent.c
index 8a84017..33d8947 100644
--- a/net/sctp/ulpevent.c
+++ b/net/sctp/ulpevent.c
@@ -715,7 +715,8 @@ struct sctp_ulpevent *sctp_ulpevent_make_rcvmsg(struct sctp_association *asoc,
* can mark it as received so the tsn_map is updated correctly.
*/
if (sctp_tsnmap_mark(&asoc->peer.tsn_map,
- ntohl(chunk->subh.data_hdr->tsn)))
+ ntohl(chunk->subh.data_hdr->tsn),
+ chunk->transport))
goto fail_mark;
/* First calculate the padding, so we don't inadvertently
diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
index f2d1de7..f5a6a4f 100644
--- a/net/sctp/ulpqueue.c
+++ b/net/sctp/ulpqueue.c
@@ -1051,7 +1051,7 @@ void sctp_ulpq_renege(struct sctp_ulpq *ulpq, struct sctp_chunk *chunk,
if (chunk && (freed >= needed)) {
__u32 tsn;
tsn = ntohl(chunk->subh.data_hdr->tsn);
- sctp_tsnmap_mark(&asoc->peer.tsn_map, tsn);
+ sctp_tsnmap_mark(&asoc->peer.tsn_map, tsn, chunk->transport);
sctp_ulpq_tail_data(ulpq, chunk, gfp);
sctp_ulpq_partial_delivery(ulpq, chunk, gfp);
--
1.7.7.6
^ permalink raw reply related
* Re: AF_BUS socket address family
From: Alan Cox @ 2012-06-30 13:12 UTC (permalink / raw)
To: David Miller; +Cc: vincent.sanders, netdev, linux-kernel
In-Reply-To: <20120629.165023.1605284574408858612.davem@davemloft.net>
> What you really don't get is that packet drops and event losses are
> absolutely fundamental.
The world is full of "receiver reliable" multicast transport providers
which provide ordered defined message delivery properties.
They are reliable in the sense that a message is either queued to the
other ends or is not queued. They are not reliable in the sense of "we
wait forever".
In fact if you look up the stack you'll find a large number of multicast
messaging systems which do reliable transport built on top of IP. In fact
Red Hat provides a high level messaging cluster service that does exactly
this. (as well as dbus which does it on the deskop level) plus a ton of
stuff on top of that (JGroups etc)
Everybody at the application level has been using these 'receiver
reliable' multicast services for years (Websphere MQ, TIBCO, RTPGM,
OpenPGM, MS-PGM, you name it). There are even accelerators for PGM based
protocols in things like Cisco routers and Solarflare can do much of it
on the card for 10Gbit.
> As long as receivers lack infinite receive queue this will always be
> the case.
>
> Multicast operates in non-reliable transports only so that one stuck
> or malfunctioning receiver doesn't screw things over for everyone nor
> unduly brudon the sender.
All the world is not IP. Dealing with a malfunctioning receiver is
something dbus already has to deal with. "Unduly burden the sender" is
you talking out of your underwear. The sender is already implementing
this property set - in user space. So there can't be any more burdening,
in fact the point of this is to get rid of excess burdens caused by lack
of kernel support.
This is a latency issue not a throughput one so you can't hide it with
buffers. A few ms shaved off desktop behaviour here and there makes a
massive difference to perceived responsiveness. Less task switches and
daemons means a lot less tasks bouncing around processors which means
less power consumption.
Alan
^ permalink raw reply
* Re: [PATCH] iwlegacy: print how long queue was actually stuck
From: Paul Bolle @ 2012-06-30 13:20 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: John W. Linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <1340786187.1911.24.camel@x61.thuisdomein>
On Wed, 2012-06-27 at 10:36 +0200, Paul Bolle wrote:
> Every now and then, after resuming from suspend, the iwlegacy driver
> prints
> iwl4965 0000:03:00.0: Queue 2 stuck for 2000 ms.
> iwl4965 0000:03:00.0: On demand firmware reload
>
> I have no idea what causes these errors. But the code currently uses
> wd_timeout in the first error. wd_timeout will generally be set at
> IL_DEF_WD_TIMEOUT (ie, 2000). Perhaps printing for how long the queue
> was actually stuck can clarify the cause of these errors.
0) It's not just after resume! I just found the following lines through
dmesg (note that it's a period that all messages in dmesg were wlan
related, for some reason):
[...]
[114649.872338] wlan0: associated
[115837.970798] wlan0: deauthenticated from [...] (Reason: 7)
[115837.993405] cfg80211: Calling CRDA to update world regulatory domain
[115838.011979] cfg80211: World regulatory domain updated:
[115838.011986] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[115838.011995] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[115838.012033] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[115838.012041] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[115838.012048] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[115838.012055] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[115838.012108] cfg80211: Calling CRDA for country: NL
[115838.022615] cfg80211: Regulatory domain changed to country: NL
[115838.022622] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[115838.022630] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[115838.022637] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[115838.022644] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[115838.022651] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
[115840.219977] wlan0: authenticate with [...]
[115840.228865] wlan0: send auth to [...] (try 1/3)
[115840.429054] wlan0: send auth to [...] (try 2/3)
[115840.630026] wlan0: send auth to [...] (try 3/3)
[115840.831051] wlan0: authentication with [...] timed out
[115848.022336] wlan0: authenticate with [...]
[115848.022495] wlan0: direct probe to [...] (try 1/3)
[115848.223052] wlan0: direct probe to [...] (try 2/3)
[115848.424052] wlan0: direct probe to [...] (try 3/3)
[115848.625048] wlan0: authentication with [...] timed out
[115855.702461] wlan0: authenticate with [...]
[115855.702623] wlan0: direct probe to [...] (try 1/3)
[115855.903053] wlan0: direct probe to [...] (try 2/3)
[115856.104061] wlan0: direct probe to [...] (try 3/3)
[115856.305050] wlan0: authentication with [...] timed out
[115863.464067] wlan0: authenticate with [...]
[115863.464221] wlan0: direct probe to [...] (try 1/3)
[115863.665054] wlan0: direct probe to [...] (try 2/3)
[115863.866058] wlan0: direct probe to [...] (try 3/3)
[115864.067051] wlan0: authentication with [...] timed out
[115871.267216] wlan0: authenticate with [...]
[115871.267376] wlan0: send auth to [...] (try 1/3)
[115871.269191] wlan0: authenticated
[115871.279459] wlan0: associate with [...] (try 1/3)
[115871.281715] wlan0: RX AssocResp from [...] (capab=0x411 status=0 aid=2)
[115871.281723] wlan0: associated
[115871.457043] iwl4965 0000:03:00.0: Queue 2 stuck for 33487 ms.
[115871.457048] iwl4965 0000:03:00.0: On demand firmware reload
[115871.457149] ieee80211 phy0: Hardware restart was requested
[117985.197630] wlan0: deauthenticating from [...] by local choice (reason=3)
[...]
1) My guess is that I left my laptop unattended for quite some time (so
_perhaps_ generating little to no wlan traffic), and in that period
NetworkManager and friends ran into trouble re-authenticating to my
wireless router. By the time authentication succeeded it just looked
like "Queue 2" was stuck. Wild, uneducated guess, actually.
2) It's always "Queue 2" that's stuck. What does that queue do?
Paul Bolle
^ permalink raw reply
* Re: problems with iproute2 m_xt again...
From: Jan Engelhardt @ 2012-06-30 13:17 UTC (permalink / raw)
To: Andreas Henriksson
Cc: shemminger, Linux Networking Developer Mailing List, YANG Zhe
In-Reply-To: <20120630120939.GA18134@amd64.fatal.se>
On Saturday 2012-06-30 14:09, Andreas Henriksson wrote:
>Hello!
>
>Mailing you in hope that you could help out with the xt module of iproute2 tc
>once more, as you've done in the past.... It seems to be broken again. sigh.
>
>amd64:~# iptables -nL | grep test
>Chain test (0 references)
>amd64:~# tc filter add dev fon parent ffff: protocol ip prio 10 u32 action xt -j test
> failed to find target test
>
>bad action parsing
>parse_action: bad value (3:xt)!
>Illegal "action"
>amd64:~#
Looks more like a syntax error. I don't see any functions of m_xt.so
being ever called (and it only has two).
>And maybe even more interesting is when I try to use a built-in chain
>like DROP:
DROP is not a chain, but a verdict.
>amd64:~# tc filter add dev fon parent ffff: protocol ip prio 10 u32
>action xt -j DROP
>tablename: mangle hook: NF_IP_PRE_ROUTING
>Segmentation fault
Rather than a segfault, this gets me "bad action parsing" in
iproute2-3.4.0 as well.
^ permalink raw reply
* Re: [PATCH] iwlegacy: print how long queue was actually stuck
From: Emmanuel Grumbach @ 2012-06-30 18:18 UTC (permalink / raw)
To: Paul Bolle
Cc: Stanislaw Gruszka, John W. Linville,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1341062406.1911.76.camel-uMdlDhfIn7prKue/0VVhAg@public.gmane.org>
>
> On Wed, 2012-06-27 at 10:36 +0200, Paul Bolle wrote:
> > Every now and then, after resuming from suspend, the iwlegacy driver
> > prints
> > iwl4965 0000:03:00.0: Queue 2 stuck for 2000 ms.
> > iwl4965 0000:03:00.0: On demand firmware reload
> >
> > I have no idea what causes these errors. But the code currently uses
> > wd_timeout in the first error. wd_timeout will generally be set at
> > IL_DEF_WD_TIMEOUT (ie, 2000). Perhaps printing for how long the queue
> > was actually stuck can clarify the cause of these errors.
>
You may want to try this one:
http://www.spinics.net/lists/stable-commits/msg18110.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* STRICTLY AND CONFIDENTIAL :
From: IBRAHIM ARWAN @ 2012-06-30 18:42 UTC (permalink / raw)
^ permalink raw reply
* Re: [PATCH] iwlegacy: print how long queue was actually stuck
From: Paul Bolle @ 2012-06-30 19:11 UTC (permalink / raw)
To: Emmanuel Grumbach
Cc: Stanislaw Gruszka, John W. Linville, linux-wireless, netdev,
linux-kernel
In-Reply-To: <CANUX_P3kypkUv+-meABAOGa6GQ9cR5ugySJj+SjvVfCykCQuYQ@mail.gmail.com>
On Sat, 2012-06-30 at 21:18 +0300, Emmanuel Grumbach wrote:
> You may want to try this one:
> http://www.spinics.net/lists/stable-commits/msg18110.html
That issue looks similar, though it regards iwlwifi. Thanks anyway.
Perhaps commit d6ee27eb13beab94056e0de52d81220058ca2297 ("iwlwifi: don't
mess up the SCD when removing a key") can be ported to iwlegacy. We'll
see whether I manage to port it and whether it helps.
Note that iwlwifi also seems to print the (default) timeout in its
message and not how long a queue was actually stuck. So perhaps
something like my patch could be ported to iwlwifi too.
Paul Bolle
^ permalink raw reply
* Re: [PATCH V3 2/2] bonding support for IPv6 transmit hashing
From: John @ 2012-06-30 19:38 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev
In-Reply-To: <CAMEyesBOj2cd6sAmowjk1vATrMjxHreeJoDEdksVwENkEWWqLQ@mail.gmail.com>
On 6/30/2012 4:59 AM, Hannes Frederic Sowa wrote:
> On Sat, Jun 30, 2012 at 8:17 AM, John <linux@8192.net> wrote:
>> diff --git a/Documentation/networking/bonding.txt
>> b/Documentation/networking/bonding.txt
>> index bfea8a3..5db14fe 100644
>> --- a/Documentation/networking/bonding.txt
>> +++ b/Documentation/networking/bonding.txt
>> @@ -752,12 +752,22 @@ xmit_hash_policy
>> protocol information to generate the hash.
>>
>> Uses XOR of hardware MAC addresses and IP addresses to
>> - generate the hash. The formula is
>> + generate the hash. The IPv4 formula is
>>
>> (((source IP XOR dest IP) AND 0xffff) XOR
>> ( source MAC XOR destination MAC ))
>> modulo slave count
>>
>> + The IPv6 forumla is
>> +
>> + iphash =
>> + (source ip quad 2 XOR dest IP quad 2) XOR
>> + (source ip quad 3 XOR dest IP quad 3) XOR
>> + (source ip quad 4 XOR dest IP quad 4)
>> +
>> + ((iphash >> 16) XOR (iphash >> 8) XOR iphash)
>> + modulo slave count
>> +
>
> Wouldn't it be beneficial to include the ipv6 flow label in the hash
> calculation?
>
> Greetings,
>
> Hannes
> --
> 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
>
Hannes,
In all of the traffic I inspected I don't believe I saw a single flow
label set. Even if it were set 100% of the time by Linux, any packets
routed or bridged from another operating system wouldn't see any
benefit. The current algorithm distributes the traffic very well, I
don't believe adding the flow label would be beneficial even if it were
set more frequently.
If you feel strongly about its inclusion, though, I am willing to
reconsider.
John
^ permalink raw reply
* Re: [PATCH V3 1/2] bonding support for IPv6 transmit hashing
From: John Eaglesham @ 2012-06-30 19:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120630.010514.79398765104671796.davem@davemloft.net>
On 6/30/2012 1:05 AM, David Miller wrote:
>
> If you're going to post multiple patches, give them unique
> subject line texts describing what each change does uniquely.
> Do not use identical subject lines ever, that is very unhelpful
> for the people reading your changes.
>
> From: John <linux@8192.net>
> Date: Fri, 29 Jun 2012 23:17:11 -0700
>
>> + skb_network_header_len(skb) >= sizeof(struct ipv6hdr)) {
>> + ipv6h = ipv6_hdr(skb);
>> + v6hash =
>> + (ipv6h->saddr.s6_addr32[1] ^ ipv6h->daddr.s6_addr32[1]) ^
>> + (ipv6h->saddr.s6_addr32[2] ^ ipv6h->daddr.s6_addr32[2]) ^
>> + (ipv6h->saddr.s6_addr32[3] ^ ipv6h->daddr.s6_addr32[3]);
>> + v6hash = (v6hash >> 16) ^ (v6hash >> 8) ^ v6hash;
>> + return (v6hash ^ data->h_dest[5] ^ data->h_source[5]) % count;
>
> Either you formatted this terribly, or your email client corrupted
> your patches.
> --
> 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
>
Thanks for the feedback. It must have been my mail client formatting
that incorrectly. I will re-submit with useful subject lines in a method
that preserves the intended indentation.
John
^ permalink raw reply
* Re: [BUG, regression, bisected] Marvell 88E8055 NIC (sky2) fails to detect link after resume from S3
From: Francois Romieu @ 2012-06-30 20:02 UTC (permalink / raw)
To: Michal Zatloukal; +Cc: Stephen Hemminger, netdev
In-Reply-To: <CAKKZj2DVX7Kr4Ag7jubtr7fSa5sSLYR=kt2b6=PV=8fV6q0d8Q@mail.gmail.com>
Michal Zatloukal <myxal.mxl@gmail.com> :
[...]
> Is there something I can try?
I have not used it for quite some time but comparing mmiotrace output
(see Documentation/trace/mmiotrace.txt) before and after the regression
commit may give some hint.
Otherwise I would ask for help on linux-pm@vger.kernel.org
--
Ueimor
^ permalink raw reply
* Re: AF_BUS socket address family
From: Hans-Peter Jansen @ 2012-06-30 20:41 UTC (permalink / raw)
To: Vincent Sanders; +Cc: netdev, linux-kernel, David S. Miller
In-Reply-To: <1340988354-26981-1-git-send-email-vincent.sanders@collabora.co.uk>
Dear Vincent,
On Friday 29 June 2012, 18:45:39 Vincent Sanders wrote:
> This series adds the bus address family (AF_BUS) it is against
> net-next as of yesterday.
>
> AF_BUS is a message oriented inter process communication system.
>
> The principle features are:
>
> - Reliable datagram based communication (all sockets are of type
> SOCK_SEQPACKET)
>
> - Multicast message delivery (one to many, unicast as a subset)
>
> - Strict ordering (messages are delivered to every client in the
> same order)
>
> - Ability to pass file descriptors
>
> - Ability to pass credentials
>
> The basic concept is to provide a virtual bus on which multiple
> processes can communicate and policy is imposed by a "bus master".
>
> Introduction
> ------------
>
> AF_BUS is based upon AF_UNIX but extended for multicast operation and
> removes stream operation, responding to extensive feedback on
> previous approaches we have made the implementation as isolated as
> possible. There are opportunities in the future to integrate the
> socket garbage collector with that of the unix socket implementation.
>
> The impetus for creating this IPC mechanism is to replace the
> underlying transport for D-Bus. The D-Bus system currently emulates
> this IPC mechanism using AF_UNIX sockets in userspace and has
> numerous undesirable behaviours. D-Bus is now widely deployed in many
> areas and has become a de-facto IPC standard. Using this IPC
> mechanism as a transport gives a significant (100% or more)
> improvement to throughput with comparable improvement to latency.
Your introduction is missing a comprehensive "Discussion" section, where
you compare the AF_UNIX based implementation with AF_BUS ones.
You should elaborate on each of the above noted undesirable behaviours,
why and how AF_BUS is advantageous. Show the workarounds, that are
needed by AF_UNIX to operate (properly?!?) and how the new
implementation is going to improve this situation.
This will help to get some progress into the indurated discussion here.
Please also note, that, while your aims are nice and sound, it's even
more important for IPC mechanisms to operate properly - even during
persisting error conditions (crashed bus master and clients,
misbehaving or even abusing members). It would be cool to create a
D-BUS test rig, that not only measures performance numbers, but also
checks for dead locks, corner cases and abuse attempts in both IPC
implementations.
It's a juggling act: while AF_UNIX might suffer from downsides, the code
is heavily exercised in every aspect. Your implementation will only be
exercised by a handful of users (basically one lib), but in order to
rectify its existence in kernel space, such extensions need different
kinds of users, and the basic concepts need to fit in the whole kernel
picture as well, or you need to call it AF_DBUS with even less chance
to get it into mainstream.
Wishing you all the best and good luck,
Pete
^ permalink raw reply
* Re: [net-next] e1000e: remove use of IP payload checksum
From: Ben Hutchings @ 2012-06-30 21:36 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Bruce Allan, netdev, gospo, sassmann
In-Reply-To: <1341052528-2444-1-git-send-email-jeffrey.t.kirsher@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]
On Sat, 2012-06-30 at 03:35 -0700, Jeff Kirsher wrote:
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Currently only used when packet split mode is enabled with jumbo frames,
> IP payload checksum (for fragmented UDP packets) is mutually exclusive with
> receive hashing offload since the hardware uses the same space in the
> receive descriptor for the hardware-provided packet checksum and the RSS
> hash, respectively. Users currently must disable jumbos when receive
> hashing offload is enabled, or vice versa, because of this incompatibility.
> Since testing has shown that IP payload checksum does not provide any real
> benefit, just remove it so that there is no longer a choice between jumbos
> or receive hashing offload but not both as done in other Intel GbE drivers
> (e.g. e1000, igb).
>
> Also, add a missing check for IP checksum error reported by the hardware;
> let the stack verify the checksum when this happens.
[...]
The change to enable RX hashing in 3.4, with this odd restriction seems
to have broken most existing systems using jumbo MTU on e1000e. None of
the distro scripts or network management daemons will automatically
change offload configuration before MTU; how could they know?
Therefore this needs to be fixed in 3.5 and 3.4.y, not net-next.
Ben.
--
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing anyway.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [patch -next] netfilter: use kfree_skb() not kfree()
From: David Miller @ 2012-07-01 0:27 UTC (permalink / raw)
To: dan.carpenter
Cc: netfilter, coreteam, netdev, bridge, kernel-janitors,
bart.de.schuymer, netfilter-devel, shemminger, pablo
In-Reply-To: <20120630114853.GA22767@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Sat, 30 Jun 2012 14:48:53 +0300
> This was should be a kfree_skb() here to free the sk_buff pointer.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
My bad, applied, thanks Dan.
^ permalink raw reply
* Re: AF_BUS socket address family
From: David Miller @ 2012-07-01 0:33 UTC (permalink / raw)
To: alan; +Cc: vincent.sanders, netdev, linux-kernel
In-Reply-To: <20120630141222.60df95a5@pyramind.ukuu.org.uk>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Sat, 30 Jun 2012 14:12:22 +0100
> In fact if you look up the stack you'll find a large number of multicast
> messaging systems which do reliable transport built on top of IP. In fact
> Red Hat provides a high level messaging cluster service that does exactly
> this. (as well as dbus which does it on the deskop level) plus a ton of
> stuff on top of that (JGroups etc)
>
> Everybody at the application level has been using these 'receiver
> reliable' multicast services for years (Websphere MQ, TIBCO, RTPGM,
> OpenPGM, MS-PGM, you name it). There are even accelerators for PGM based
> protocols in things like Cisco routers and Solarflare can do much of it
> on the card for 10Gbit.
The issue is that what to do when a receiver goes deaf is a policy
issue.
^ permalink raw reply
* Re: [net-next] e1000e: remove use of IP payload checksum
From: David Miller @ 2012-07-01 0:37 UTC (permalink / raw)
To: ben; +Cc: jeffrey.t.kirsher, bruce.w.allan, netdev, gospo, sassmann
In-Reply-To: <1341092196.4852.43.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sat, 30 Jun 2012 22:36:36 +0100
> On Sat, 2012-06-30 at 03:35 -0700, Jeff Kirsher wrote:
>> From: Bruce Allan <bruce.w.allan@intel.com>
>>
>> Currently only used when packet split mode is enabled with jumbo frames,
>> IP payload checksum (for fragmented UDP packets) is mutually exclusive with
>> receive hashing offload since the hardware uses the same space in the
>> receive descriptor for the hardware-provided packet checksum and the RSS
>> hash, respectively. Users currently must disable jumbos when receive
>> hashing offload is enabled, or vice versa, because of this incompatibility.
>> Since testing has shown that IP payload checksum does not provide any real
>> benefit, just remove it so that there is no longer a choice between jumbos
>> or receive hashing offload but not both as done in other Intel GbE drivers
>> (e.g. e1000, igb).
>>
>> Also, add a missing check for IP checksum error reported by the hardware;
>> let the stack verify the checksum when this happens.
> [...]
>
> The change to enable RX hashing in 3.4, with this odd restriction seems
> to have broken most existing systems using jumbo MTU on e1000e. None of
> the distro scripts or network management daemons will automatically
> change offload configuration before MTU; how could they know?
>
> Therefore this needs to be fixed in 3.5 and 3.4.y, not net-next.
Agreed.
^ permalink raw reply
* Re: [PATCH v5] sctp: be more restrictive in transport selection on bundled sacks
From: David Miller @ 2012-07-01 0:38 UTC (permalink / raw)
To: nhorman; +Cc: netdev, vyasevich, linux-sctp
In-Reply-To: <20120630122647.GA22647@neilslaptop.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Sat, 30 Jun 2012 08:26:47 -0400
> This is wrong. Its a counter that increments every time we call sctp_make_sack,
> so that we can create a unique generation identifier for use in tagging which
> transports move ctsn in a given generation. It saves us from having to iterate
> over a list every time we send a sack.
Sorry, I missed the counter bump.
^ permalink raw reply
* Re: [PATCH v6] sctp: be more restrictive in transport selection on bundled sacks
From: David Miller @ 2012-07-01 0:39 UTC (permalink / raw)
To: nhorman; +Cc: netdev, vyasevich, linux-sctp
In-Reply-To: <1341061466-4186-1-git-send-email-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Sat, 30 Jun 2012 09:04:26 -0400
> It was noticed recently that when we send data on a transport, its possible that
> we might bundle a sack that arrived on a different transport. While this isn't
> a major problem, it does go against the SHOULD requirement in section 6.4 of RFC
> 2960:
>
> An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
> etc.) to the same destination transport address from which it
> received the DATA or control chunk to which it is replying. This
> rule should also be followed if the endpoint is bundling DATA chunks
> together with the reply chunk.
>
> This patch seeks to correct that. It restricts the bundling of sack operations
> to only those transports which have moved the ctsn of the association forward
> since the last sack. By doing this we guarantee that we only bundle outbound
> saks on a transport that has received a chunk since the last sack. This brings
> us into stricter compliance with the RFC.
>
> Vlad had initially suggested that we strictly allow only sack bundling on the
> transport that last moved the ctsn forward. While this makes sense, I was
> concerned that doing so prevented us from bundling in the case where we had
> received chunks that moved the ctsn on multiple transports. In those cases, the
> RFC allows us to select any of the transports having received chunks to bundle
> the sack on. so I've modified the approach to allow for that, by adding a state
> variable to each transport that tracks weather it has moved the ctsn since the
> last sack. This I think keeps our behavior (and performance), close enough to
> our current profile that I think we can do this without a sysctl knob to
> enable/disable it.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: Vlad Yaseivch <vyasevich@gmail.com>
> CC: David S. Miller <davem@davemloft.net>
> CC: linux-sctp@vger.kernel.org
> Reported-by: Michele Baldessari <michele@redhat.com>
> Reported-by: sorin serban <sserban@redhat.com>
Once this has Vlad's ACK I'll apply it.
There has to be a better way to handle this situation, wherein the
responsible party has ACK'd the patch but I just ask for a few coding
style fixups and whatnot. As it stands now I have to twiddle my
thumbs waiting for the new ACK.
^ permalink raw reply
* Re: [net] igbvf: fix divide by zero
From: David Miller @ 2012-07-01 0:41 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: mitch.a.williams, netdev, gospo, sassmann, stable, daahern
In-Reply-To: <1341051799-8824-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 30 Jun 2012 03:23:19 -0700
> From: Mitch A Williams <mitch.a.williams@intel.com>
>
> Using ethtool -C ethX rx-usecs 0 crashes with a divide by zero.
> Refactor this function to fix this issue and make it more clear
> what the intent of each conditional is. Add comment regarding
> using a setting of zero.
>
> CC: stable <stable@vger.kernel.org> [3.3+]
> CC: David Ahern <daahern@cisco.com>
> Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks.
^ 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