* [PATCH 05/11] broadcom: replace open-coded ARRAY_SIZE with macro
From: Jim Cromie @ 2012-04-11 0:56 UTC (permalink / raw)
To: netdev; +Cc: trivial, Jim Cromie
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
drivers/net/ethernet/broadcom/bnx2.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
index 8297e28..0552168 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -7343,8 +7343,7 @@ static struct {
{ "rx_fw_discards" },
};
-#define BNX2_NUM_STATS (sizeof(bnx2_stats_str_arr)/\
- sizeof(bnx2_stats_str_arr[0]))
+#define BNX2_NUM_STATS ARRAY_SIZE(bnx2_stats_str_arr)
#define STATS_OFFSET32(offset_name) (offsetof(struct statistics_block, offset_name) / 4)
--
1.7.8.1
^ permalink raw reply related
* Re: [net-next PATCH v1 7/7] macvlan: add FDB bridge ops and new macvlan mode
From: Sridhar Samudrala @ 2012-04-11 0:46 UTC (permalink / raw)
To: John Fastabend
Cc: Michael S. Tsirkin, roprabhu, stephen.hemminger, davem, hadi,
bhutchings, jeffrey.t.kirsher, netdev, gregory.v.rose, krkumar2
In-Reply-To: <4F845345.8090601@intel.com>
On 4/10/2012 8:35 AM, John Fastabend wrote:
> On 4/10/2012 8:30 AM, Michael S. Tsirkin wrote:
>> On Tue, Apr 10, 2012 at 08:26:21AM -0700, John Fastabend wrote:
>>> On 4/10/2012 7:35 AM, Michael S. Tsirkin wrote:
>>>> On Tue, Apr 10, 2012 at 07:25:58AM -0700, John Fastabend wrote:
>>>>>> Hmm okay, but this would mean we should convert
>>>>>> MACVLAN_MODE_PASSTHRU_NOPROMISC to something
>>>>>> that can combined with all modes. E.g.
>>>>>> MACVLAN_MODE_BRIDGE | MACVLAN_MODE_FLAG_XXXXX
>>>>>>
>>>>>> and document that it does not promise to flood
>>>>>> multicast.
>>>>>>
>>>>> How about changing MACVLAN_MODE_PASSTHRU_NOPROMISC -> MACVLAN_MODE_NOPORMISC
>>>>> for this patch. Then a follow on series can rework bridge
>>>>> and VEPA to use it as well.
>>>> Right. We probably need a better name if it's going to
>>>> affect other things besides promisc though.
>>>>
>>> how about MACVLAN_MODE_FDBFLAG?
>> The idea being that no one figures out what this means so
>> no one will make any wrong assumptions? ;)
>>
> Well its a flag to enable the FDB (forwarding database) ops
> and skip dev_set_promisc() on passthru mode. Any better ideas?
> Maybe MACVLAN_MODE_FDBENABLE or MACVLAN_MODE_MANAGE_FDB?
Do we need to introduce another mode? I think this patch is enabling
passthru mode without the need
to put the underlying device in promiscuous mode. So basically we can
consider this patch as
an optimization.
Thanks
Sridhar
^ permalink raw reply
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: David Miller @ 2012-04-11 0:42 UTC (permalink / raw)
To: thockin; +Cc: romieu, netdev
In-Reply-To: <CAAAKZwt9TUdDS6-pQ_aDAMxJ+MRTNnHxC0Fuajm_WsqjUED6wg@mail.gmail.com>
From: Tim Hockin <thockin@hockin.org>
Date: Tue, 10 Apr 2012 17:19:42 -0700
> I agree. The patches to this driver have been very few and far
> between, but even those I am largely unable to review any more.
>
> I'm more than willing to hand it off to someone who can do a better job of it
My inclination was the mark the driver Orphan'd, which represents
the current state of affairs quite accurately.
^ permalink raw reply
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: Tim Hockin @ 2012-04-11 0:19 UTC (permalink / raw)
To: David Miller; +Cc: romieu, netdev
In-Reply-To: <20120410.200212.1031414009653598743.davem@davemloft.net>
I agree. The patches to this driver have been very few and far
between, but even those I am largely unable to review any more.
I'm more than willing to hand it off to someone who can do a better job of it
Tim
On Tue, Apr 10, 2012 at 5:02 PM, David Miller <davem@davemloft.net> wrote:
> From: Tim Hockin <thockin@hockin.org>
> Date: Tue, 10 Apr 2012 16:39:31 -0700
>
>> OK, so that addresses that concern. :) Thanks.
>>
>> Overall nothing in the CL stands out as bad, except for the IO vs MMIO
>> BAR thing, which I can not answer with certainty any more.
>
> If you capacity to review patches to the driver for anything other
> than trivial changes is close to zero, which it appears to be, you
> might consider whether you should be listed in MAINTAINERS for it any
> long. And also, therefore, whether this driver should be marked
> as Maintained.
>
^ permalink raw reply
* Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: Arvid Brodin @ 2012-04-11 0:00 UTC (permalink / raw)
To: Stephen Hemminger, Ben Hutchings, David Miller
Cc: netdev@vger.kernel.org, balferreira@googlemail.com
In-Reply-To: <20120406111912.172bb1fb@nehalam.linuxnetplumber.net>
On 2012-04-06 20:19, Stephen Hemminger wrote:
> On Fri, 6 Apr 2012 18:06:31 +0100
> Ben Hutchings <bhutchings@solarflare.com> wrote:
>
>> On Fri, 2012-04-06 at 17:51 +0200, Arvid Brodin wrote:
>>> David Miller wrote:
>>>> From: Stephen Hemminger <shemminger@vyatta.com>
>>>> Date: Wed, 4 Apr 2012 16:55:59 -0700
>>>>
>>>>> That isn't so bad, doing a memcpy versus a structure copy.
>>>>
>>>> GCC is going to inline the memcpy and thus we'll still do the
>>>> unaligned accesses. This change therefore won't fix the problem.
>>>
>>> Well, it does work for me, with gcc-4.2.2-compiled linux-2.6.37 running
>>> on an AVR32 board.
>>>
>>> Just out of curiosity, what's the mechanism behind this inline
>>> assignment that turns the memcpy into an unaligned access? If gcc is
>>> "smart" enough to detect a bunch of char * accesses and turn them
>>> into unaligned 32-bit accesses, isn't that a bug in gcc?
>>
>> If I remember correctly, casting a char* pointer to foo* where the
>> original pointer isn't properly aligned for type foo results in
>> undefined behaviour. And that is what icmp_hdr() is doing, so there is
>> no requirement that the compiler does anything reasonable with the
>> result. Removing that cast (using skb_transport_header() instead of
>> icmp_hdr()) should avoid that.
>>
>> (We do generally assume, however, that if the processor can handle
>> unaligned accesses in a useful way then the compiler will be reasonable
>> and not break them.)
>>
>> Ben.
>>
>>> Or will this only happen on archs which __HAVE_ARCH_MEMCPY? (But looking
>>> at a couple of arch/xxx/lib/string.c, these too seem to take alignment
>>> into account.)
>>>
>>
>
> Since icmp_hdr is 64 bits you might be able to use get_unaligned64
> in some way.
>
I'm sorry, I have no idea how to do this. Besides, get_unaligned64 seems to be implemented
for the "c6x" arch only?
So far we have:
1) icmp_hdr() casts an unaligned char * to a wider type, which is bad (undefined).
2) We cannot use skb_transport_header():
On 2012-04-06 00:31, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Thu, 5 Apr 2012 20:21:08 +0100
>>
>> So presumably icmp_hdr() should be changed to skb_transport_header().
>
> I would not say so. Otherwise we introduce ugly casts everywhere.
>
3) My feeble suggestion to cast icmp_hdr() to (char *) is of course even worse (it doesn't
even avoid the erroneous cast in the first place).
So what do we do?
--
Arvid Brodin
Enea Services Stockholm AB - since February 16 a part of Xdin in the Alten Group. Soon we
will be working under the common brand name Xdin. Read more at www.xdin.com.
^ permalink raw reply
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: David Miller @ 2012-04-11 0:02 UTC (permalink / raw)
To: thockin; +Cc: romieu, netdev
In-Reply-To: <CAAAKZwvRvc=6qwainJAkHCUEme+PsFY-s0PWxj9tYXwSmBcYJA@mail.gmail.com>
From: Tim Hockin <thockin@hockin.org>
Date: Tue, 10 Apr 2012 16:39:31 -0700
> OK, so that addresses that concern. :) Thanks.
>
> Overall nothing in the CL stands out as bad, except for the IO vs MMIO
> BAR thing, which I can not answer with certainty any more.
If you capacity to review patches to the driver for anything other
than trivial changes is close to zero, which it appears to be, you
might consider whether you should be listed in MAINTAINERS for it any
long. And also, therefore, whether this driver should be marked
as Maintained.
^ permalink raw reply
* Re: via-rhine: Problem with lost link after a while
From: Bjarke Istrup Pedersen @ 2012-04-10 23:58 UTC (permalink / raw)
To: Francois Romieu
Cc: linux-kernel, netdev, Svenning Sørensen, Andreas Mohr
In-Reply-To: <20120410225534.GA28480@electric-eye.fr.zoreil.com>
11. apr. 2012 00.55 skrev Francois Romieu <romieu@fr.zoreil.com>:
> Bjarke Istrup Pedersen <gurligebis@gentoo.org> :
>> 10. apr. 2012 22.42 skrev Francois Romieu <romieu@fr.zoreil.com>:
> [...]
>> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;h=3f8c91a7398b9266fbe7abcbe4bd5dffef907643
> [...]
>> Great, I'll try a 3.4-rc2 kernel, and see how it runs.
>>
>> The thread I was talking about earlier is here:
>> http://lists.soekris.com/pipermail/soekris-tech/2012-April/018318.html
>> Is there any of the changes he has there, that makes sense in the new
>> driver you wrote ?
>
> (I did not write a new driver)
Sorry, bad choice of words, meant fixed some issues with the driver :)
> Regarding Svenning's patch:
> - the wmb in alloc_rbufs may help rhine_reset_task().
> - one should probably add one in rhine_rx() as well.
> - rhine_start_tx() is supposed to stop queueing when there is no room left.
> I'm curious to know if the "Tx descriptor busy" test triggered.
> - the rmb() in rhine_tx() will not make a difference for a single core but
> it's a good reminder that I should not have forgotten to propagate the
> xmit / Tx completion fix back from the r8169 driver to the via-rhine one
> (sigh)
>
> mmiowb is probably missing. I doubt it hits hard right now.
I'll give it a spin tomorrow, and see how it runs :)
> I have not checked if MMIO flushes are missing. Actually I need some sleep.
>
> diff --git a/drivers/net/ethernet/via/via-rhine.c b/drivers/net/ethernet/via/via-rhine.c
> index fcfa01f..dfa9fc0 100644
> --- a/drivers/net/ethernet/via/via-rhine.c
> +++ b/drivers/net/ethernet/via/via-rhine.c
> @@ -1163,6 +1163,7 @@ static void alloc_rbufs(struct net_device *dev)
> PCI_DMA_FROMDEVICE);
>
> rp->rx_ring[i].addr = cpu_to_le32(rp->rx_skbuff_dma[i]);
> + wmb();
> rp->rx_ring[i].rx_status = cpu_to_le32(DescOwn);
> }
> rp->dirty_rx = (unsigned int)(i - RX_RING_SIZE);
> @@ -1709,8 +1710,13 @@ static netdev_tx_t rhine_start_tx(struct sk_buff *skb,
> ioaddr + ChipCmd1);
> IOSYNC;
>
> - if (rp->cur_tx == rp->dirty_tx + TX_QUEUE_LEN)
> + if (rp->cur_tx == rp->dirty_tx + TX_QUEUE_LEN) {
> + smp_wmb();
> netif_stop_queue(dev);
> + smp_mb();
> + if (rp->cur_tx != rp->dirty_tx + TX_QUEUE_LEN)
> + netif_wake_queue(dev);
> + }
>
> netif_dbg(rp, tx_queued, dev, "Transmit frame #%d queued in slot %d\n",
> rp->cur_tx - 1, entry);
> @@ -1759,6 +1765,7 @@ static void rhine_tx(struct net_device *dev)
> struct rhine_private *rp = netdev_priv(dev);
> int txstatus = 0, entry = rp->dirty_tx % TX_RING_SIZE;
>
> + smp_rmb();
> /* find and cleanup dirty tx descriptors */
> while (rp->dirty_tx != rp->cur_tx) {
> txstatus = le32_to_cpu(rp->tx_ring[entry].tx_status);
> @@ -1806,8 +1813,12 @@ static void rhine_tx(struct net_device *dev)
> rp->tx_skbuff[entry] = NULL;
> entry = (++rp->dirty_tx) % TX_RING_SIZE;
> }
> - if ((rp->cur_tx - rp->dirty_tx) < TX_QUEUE_LEN - 4)
> +
> + smp_mb();
> + if (netif_queue_stopped(dev) &&
> + (rp->cur_tx - rp->dirty_tx) < TX_QUEUE_LEN - 4) {
> netif_wake_queue(dev);
> + }
> }
>
> /**
> @@ -1947,6 +1958,7 @@ static int rhine_rx(struct net_device *dev, int limit)
> PCI_DMA_FROMDEVICE);
> rp->rx_ring[entry].addr = cpu_to_le32(rp->rx_skbuff_dma[entry]);
> }
> + wmb();
> rp->rx_ring[entry].rx_status = cpu_to_le32(DescOwn);
> }
>
> --
> Ueimor
>
> Will code drivers for food.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [v2] Re: [RFC] l2tp/ipv6: support for L2TPv2 over UDP over IPv6
From: Benjamin LaHaise @ 2012-04-10 23:40 UTC (permalink / raw)
To: James Chapman; +Cc: Eric Dumazet, netdev
In-Reply-To: <20120410184916.GE24092@kvack.org>
On Tue, Apr 10, 2012 at 02:49:16PM -0400, Benjamin LaHaise wrote:
...
> Also, I found a bug in OpenL2TPd (1.8 I think): certain types of AVPs are
> not accepted if they are hidden, despite the fact that RFC 2661 permits
> hiding these AVPs. The AVPs in question are: Assigned Tunnel ID, Challege,
> Challenge Response and Assigned Session ID.
Here's the fix for OpenL2TPd 1.8. The use-after-realloc() in l2tp_avp_hide()
doesn't always work if the memory gets moved and glibc scribbles on
orig_buffer. There's also an interesting typo in l2tp_avp_message_decode().
-ben
--
"Thought is the essence of where you are now."
--- openl2tp-1.8/l2tp_avp.c.xxx 2008-05-08 15:05:26.000000000 -0400
+++ openl2tp-1.8/l2tp_avp.c 2012-04-10 18:07:05.866208480 -0400
@@ -535,16 +535,18 @@ static int l2tp_avp_hide(void **buffer,
* and we just need to shift the data up 2 bytes.
*/
new_buffer_len = orig_buffer_len + 2 + pad + 16;
- new_buffer = realloc(orig_buffer, new_buffer_len + L2TP_AVP_HEADER_LEN);
+ new_buffer = malloc(new_buffer_len + L2TP_AVP_HEADER_LEN);
if (new_buffer == NULL) {
return -ENOMEM;
}
- memmove(new_buffer + L2TP_AVP_HEADER_LEN + 2, orig_buffer + L2TP_AVP_HEADER_LEN, orig_buffer_len - L2TP_AVP_HEADER_LEN);
+ memcpy(new_buffer, orig_buffer, L2TP_AVP_HEADER_LEN);
+ memcpy(new_buffer + L2TP_AVP_HEADER_LEN + 2, orig_buffer + L2TP_AVP_HEADER_LEN, orig_buffer_len - L2TP_AVP_HEADER_LEN);
orig_len = new_buffer + L2TP_AVP_HEADER_LEN;
*orig_len = htons(orig_buffer_len - L2TP_AVP_HEADER_LEN);
if (new_buffer != orig_buffer) {
*buffer = new_buffer;
}
+ free(orig_buffer);
flag_len = new_buffer;
tmp = ntohs(*flag_len);
*flag_len = htons(tmp + 2 + pad);
@@ -1995,7 +1997,7 @@ int l2tp_avp_message_decode(int msg_len,
result = l2tp_avp_unhide(avp, &unhidden_avp_len,
(unsigned char *const) secret, secret_len,
(unsigned char *const) data[TYPE(RANDOM_VECTOR)].value,
- data[TYPE(RANDOM_VECTOR].value_len));
+ data[TYPE(RANDOM_VECTOR)].value_len);
if (result < 0) {
l2tp_tunnel_log(tunnel, L2TP_AVPHIDE, LOG_ERR, "AVPHIDE: tunl %hu: avp unhide error: %s",
l2tp_tunnel_id(tunnel), l2tp_strerror(-result));
^ permalink raw reply
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: Tim Hockin @ 2012-04-10 23:39 UTC (permalink / raw)
To: David Miller; +Cc: romieu, netdev
In-Reply-To: <20120410.193042.1153959183942458232.davem@davemloft.net>
OK, so that addresses that concern. :) Thanks.
Overall nothing in the CL stands out as bad, except for the IO vs MMIO
BAR thing, which I can not answer with certainty any more.
On Tue, Apr 10, 2012 at 4:30 PM, David Miller <davem@davemloft.net> wrote:
> From: Tim Hockin <thockin@hockin.org>
> Date: Tue, 10 Apr 2012 15:53:53 -0700
>
>> First, because I am not so involved any more, I can't say with
>> certainty that these fields of struct net_device are not needed.
>
> It's the whole basis of this patch set, and described neatly
> in his "00/39" posting.
^ permalink raw reply
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: David Miller @ 2012-04-10 23:30 UTC (permalink / raw)
To: thockin; +Cc: romieu, netdev
In-Reply-To: <CAAAKZwu4D6QZ02gaRQ2pmF=tLyxjefu1c=H83cxAJq2TTgdxmA@mail.gmail.com>
From: Tim Hockin <thockin@hockin.org>
Date: Tue, 10 Apr 2012 15:53:53 -0700
> First, because I am not so involved any more, I can't say with
> certainty that these fields of struct net_device are not needed.
It's the whole basis of this patch set, and described neatly
in his "00/39" posting.
^ permalink raw reply
* Re: via-rhine: Problem with lost link after a while
From: Francois Romieu @ 2012-04-10 22:55 UTC (permalink / raw)
To: Bjarke Istrup Pedersen
Cc: linux-kernel, netdev, Svenning Sørensen, Andreas Mohr
In-Reply-To: <CACPM=kWsU8QZOHqwEThTQCuSSvaTDoxO1d17EyoW=+kx8QG3vw@mail.gmail.com>
Bjarke Istrup Pedersen <gurligebis@gentoo.org> :
> 10. apr. 2012 22.42 skrev Francois Romieu <romieu@fr.zoreil.com>:
[...]
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;h=3f8c91a7398b9266fbe7abcbe4bd5dffef907643
[...]
> Great, I'll try a 3.4-rc2 kernel, and see how it runs.
>
> The thread I was talking about earlier is here:
> http://lists.soekris.com/pipermail/soekris-tech/2012-April/018318.html
> Is there any of the changes he has there, that makes sense in the new
> driver you wrote ?
(I did not write a new driver)
Regarding Svenning's patch:
- the wmb in alloc_rbufs may help rhine_reset_task().
- one should probably add one in rhine_rx() as well.
- rhine_start_tx() is supposed to stop queueing when there is no room left.
I'm curious to know if the "Tx descriptor busy" test triggered.
- the rmb() in rhine_tx() will not make a difference for a single core but
it's a good reminder that I should not have forgotten to propagate the
xmit / Tx completion fix back from the r8169 driver to the via-rhine one
(sigh)
mmiowb is probably missing. I doubt it hits hard right now.
I have not checked if MMIO flushes are missing. Actually I need some sleep.
diff --git a/drivers/net/ethernet/via/via-rhine.c b/drivers/net/ethernet/via/via-rhine.c
index fcfa01f..dfa9fc0 100644
--- a/drivers/net/ethernet/via/via-rhine.c
+++ b/drivers/net/ethernet/via/via-rhine.c
@@ -1163,6 +1163,7 @@ static void alloc_rbufs(struct net_device *dev)
PCI_DMA_FROMDEVICE);
rp->rx_ring[i].addr = cpu_to_le32(rp->rx_skbuff_dma[i]);
+ wmb();
rp->rx_ring[i].rx_status = cpu_to_le32(DescOwn);
}
rp->dirty_rx = (unsigned int)(i - RX_RING_SIZE);
@@ -1709,8 +1710,13 @@ static netdev_tx_t rhine_start_tx(struct sk_buff *skb,
ioaddr + ChipCmd1);
IOSYNC;
- if (rp->cur_tx == rp->dirty_tx + TX_QUEUE_LEN)
+ if (rp->cur_tx == rp->dirty_tx + TX_QUEUE_LEN) {
+ smp_wmb();
netif_stop_queue(dev);
+ smp_mb();
+ if (rp->cur_tx != rp->dirty_tx + TX_QUEUE_LEN)
+ netif_wake_queue(dev);
+ }
netif_dbg(rp, tx_queued, dev, "Transmit frame #%d queued in slot %d\n",
rp->cur_tx - 1, entry);
@@ -1759,6 +1765,7 @@ static void rhine_tx(struct net_device *dev)
struct rhine_private *rp = netdev_priv(dev);
int txstatus = 0, entry = rp->dirty_tx % TX_RING_SIZE;
+ smp_rmb();
/* find and cleanup dirty tx descriptors */
while (rp->dirty_tx != rp->cur_tx) {
txstatus = le32_to_cpu(rp->tx_ring[entry].tx_status);
@@ -1806,8 +1813,12 @@ static void rhine_tx(struct net_device *dev)
rp->tx_skbuff[entry] = NULL;
entry = (++rp->dirty_tx) % TX_RING_SIZE;
}
- if ((rp->cur_tx - rp->dirty_tx) < TX_QUEUE_LEN - 4)
+
+ smp_mb();
+ if (netif_queue_stopped(dev) &&
+ (rp->cur_tx - rp->dirty_tx) < TX_QUEUE_LEN - 4) {
netif_wake_queue(dev);
+ }
}
/**
@@ -1947,6 +1958,7 @@ static int rhine_rx(struct net_device *dev, int limit)
PCI_DMA_FROMDEVICE);
rp->rx_ring[entry].addr = cpu_to_le32(rp->rx_skbuff_dma[entry]);
}
+ wmb();
rp->rx_ring[entry].rx_status = cpu_to_le32(DescOwn);
}
--
Ueimor
Will code drivers for food.
^ permalink raw reply related
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: Tim Hockin @ 2012-04-10 22:53 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, David Miller
In-Reply-To: <d13055fe45a281c97ec85454ca8e1c2bc9932166.1333704409.git.romieu@fr.zoreil.com>
On Fri, Apr 6, 2012 at 3:06 AM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> It's useless to check mem_start on a newly allocated device.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Cc: Tim Hockin <thockin@hockin.org>
Honestly, it's been a long time since I was actively involved with
this device, but I have three remarks on this patch. First, because I
am not so involved any more, I can't say with certainty that these
fields of struct net_device are not needed. Second, I think it is
possible to not map the MMIO BAR of this device, but I am not sure
that would cause a problem (without a lot more code inspection).
Third, this patch description describes 1 or 2 of about 20 diff
chunks. either describe them all, or send multiple patches.
> ---
> drivers/net/ethernet/natsemi/natsemi.c | 67 ++++++++++++++++++-------------
> 1 files changed, 39 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/net/ethernet/natsemi/natsemi.c b/drivers/net/ethernet/natsemi/natsemi.c
> index d38e48d..5b61d12 100644
> --- a/drivers/net/ethernet/natsemi/natsemi.c
> +++ b/drivers/net/ethernet/natsemi/natsemi.c
> @@ -547,6 +547,7 @@ struct netdev_private {
> struct sk_buff *tx_skbuff[TX_RING_SIZE];
> dma_addr_t tx_dma[TX_RING_SIZE];
> struct net_device *dev;
> + void __iomem *ioaddr;
> struct napi_struct napi;
> /* Media monitoring timer */
> struct timer_list timer;
> @@ -699,7 +700,9 @@ static ssize_t natsemi_set_dspcfg_workaround(struct device *dev,
>
> static inline void __iomem *ns_ioaddr(struct net_device *dev)
> {
> - return (void __iomem *) dev->base_addr;
> + struct netdev_private *np = netdev_priv(dev);
> +
> + return np->ioaddr;
> }
>
> static inline void natsemi_irq_enable(struct net_device *dev)
> @@ -863,10 +866,9 @@ static int __devinit natsemi_probe1 (struct pci_dev *pdev,
> /* Store MAC Address in perm_addr */
> memcpy(dev->perm_addr, dev->dev_addr, ETH_ALEN);
>
> - dev->base_addr = (unsigned long __force) ioaddr;
> - dev->irq = irq;
> -
> np = netdev_priv(dev);
> + np->ioaddr = ioaddr;
> +
> netif_napi_add(dev, &np->napi, natsemi_poll, 64);
> np->dev = dev;
>
> @@ -914,9 +916,6 @@ static int __devinit natsemi_probe1 (struct pci_dev *pdev,
> }
>
> option = find_cnt < MAX_UNITS ? options[find_cnt] : 0;
> - if (dev->mem_start)
> - option = dev->mem_start;
> -
> /* The lower four bits are the media type. */
> if (option) {
> if (option & 0x200)
> @@ -1532,20 +1531,21 @@ static int netdev_open(struct net_device *dev)
> {
> struct netdev_private *np = netdev_priv(dev);
> void __iomem * ioaddr = ns_ioaddr(dev);
> + const int irq = np->pci_dev->irq;
> int i;
>
> /* Reset the chip, just in case. */
> natsemi_reset(dev);
>
> - i = request_irq(dev->irq, intr_handler, IRQF_SHARED, dev->name, dev);
> + i = request_irq(irq, intr_handler, IRQF_SHARED, dev->name, dev);
> if (i) return i;
>
> if (netif_msg_ifup(np))
> printk(KERN_DEBUG "%s: netdev_open() irq %d.\n",
> - dev->name, dev->irq);
> + dev->name, irq);
> i = alloc_ring(dev);
> if (i < 0) {
> - free_irq(dev->irq, dev);
> + free_irq(irq, dev);
> return i;
> }
> napi_enable(&np->napi);
> @@ -1794,6 +1794,7 @@ static void netdev_timer(unsigned long data)
> struct netdev_private *np = netdev_priv(dev);
> void __iomem * ioaddr = ns_ioaddr(dev);
> int next_tick = NATSEMI_TIMER_FREQ;
> + const int irq = np->pci_dev->irq;
>
> if (netif_msg_timer(np)) {
> /* DO NOT read the IntrStatus register,
> @@ -1817,14 +1818,14 @@ static void netdev_timer(unsigned long data)
> if (netif_msg_drv(np))
> printk(KERN_NOTICE "%s: possible phy reset: "
> "re-initializing\n", dev->name);
> - disable_irq(dev->irq);
> + disable_irq(irq);
> spin_lock_irq(&np->lock);
> natsemi_stop_rxtx(dev);
> dump_ring(dev);
> reinit_ring(dev);
> init_registers(dev);
> spin_unlock_irq(&np->lock);
> - enable_irq(dev->irq);
> + enable_irq(irq);
> } else {
> /* hurry back */
> next_tick = HZ;
> @@ -1841,10 +1842,10 @@ static void netdev_timer(unsigned long data)
> spin_unlock_irq(&np->lock);
> }
> if (np->oom) {
> - disable_irq(dev->irq);
> + disable_irq(irq);
> np->oom = 0;
> refill_rx(dev);
> - enable_irq(dev->irq);
> + enable_irq(irq);
> if (!np->oom) {
> writel(RxOn, ioaddr + ChipCmd);
> } else {
> @@ -1885,8 +1886,9 @@ static void ns_tx_timeout(struct net_device *dev)
> {
> struct netdev_private *np = netdev_priv(dev);
> void __iomem * ioaddr = ns_ioaddr(dev);
> + const int irq = np->pci_dev->irq;
>
> - disable_irq(dev->irq);
> + disable_irq(irq);
> spin_lock_irq(&np->lock);
> if (!np->hands_off) {
> if (netif_msg_tx_err(np))
> @@ -1905,7 +1907,7 @@ static void ns_tx_timeout(struct net_device *dev)
> dev->name);
> }
> spin_unlock_irq(&np->lock);
> - enable_irq(dev->irq);
> + enable_irq(irq);
>
> dev->trans_start = jiffies; /* prevent tx timeout */
> dev->stats.tx_errors++;
> @@ -2470,9 +2472,12 @@ static struct net_device_stats *get_stats(struct net_device *dev)
> #ifdef CONFIG_NET_POLL_CONTROLLER
> static void natsemi_poll_controller(struct net_device *dev)
> {
> - disable_irq(dev->irq);
> - intr_handler(dev->irq, dev);
> - enable_irq(dev->irq);
> + struct netdev_private *np = netdev_priv(dev);
> + const int irq = np->pci_dev->irq;
> +
> + disable_irq(irq);
> + intr_handler(irq, dev);
> + enable_irq(irq);
> }
> #endif
>
> @@ -2523,8 +2528,9 @@ static int natsemi_change_mtu(struct net_device *dev, int new_mtu)
> if (netif_running(dev)) {
> struct netdev_private *np = netdev_priv(dev);
> void __iomem * ioaddr = ns_ioaddr(dev);
> + const int irq = np->pci_dev->irq;
>
> - disable_irq(dev->irq);
> + disable_irq(irq);
> spin_lock(&np->lock);
> /* stop engines */
> natsemi_stop_rxtx(dev);
> @@ -2537,7 +2543,7 @@ static int natsemi_change_mtu(struct net_device *dev, int new_mtu)
> /* restart engines */
> writel(RxOn | TxOn, ioaddr + ChipCmd);
> spin_unlock(&np->lock);
> - enable_irq(dev->irq);
> + enable_irq(irq);
> }
> return 0;
> }
> @@ -3135,6 +3141,7 @@ static int netdev_close(struct net_device *dev)
> {
> void __iomem * ioaddr = ns_ioaddr(dev);
> struct netdev_private *np = netdev_priv(dev);
> + const int irq = np->pci_dev->irq;
>
> if (netif_msg_ifdown(np))
> printk(KERN_DEBUG
> @@ -3156,14 +3163,14 @@ static int netdev_close(struct net_device *dev)
> */
>
> del_timer_sync(&np->timer);
> - disable_irq(dev->irq);
> + disable_irq(irq);
> spin_lock_irq(&np->lock);
> natsemi_irq_disable(dev);
> np->hands_off = 1;
> spin_unlock_irq(&np->lock);
> - enable_irq(dev->irq);
> + enable_irq(irq);
>
> - free_irq(dev->irq, dev);
> + free_irq(irq, dev);
>
> /* Interrupt disabled, interrupt handler released,
> * queue stopped, timer deleted, rtnl_lock held
> @@ -3256,9 +3263,11 @@ static int natsemi_suspend (struct pci_dev *pdev, pm_message_t state)
>
> rtnl_lock();
> if (netif_running (dev)) {
> + const int irq = np->pci_dev->irq;
> +
> del_timer_sync(&np->timer);
>
> - disable_irq(dev->irq);
> + disable_irq(irq);
> spin_lock_irq(&np->lock);
>
> natsemi_irq_disable(dev);
> @@ -3267,7 +3276,7 @@ static int natsemi_suspend (struct pci_dev *pdev, pm_message_t state)
> netif_stop_queue(dev);
>
> spin_unlock_irq(&np->lock);
> - enable_irq(dev->irq);
> + enable_irq(irq);
>
> napi_disable(&np->napi);
>
> @@ -3307,6 +3316,8 @@ static int natsemi_resume (struct pci_dev *pdev)
> if (netif_device_present(dev))
> goto out;
> if (netif_running(dev)) {
> + const int irq = np->pci_dev->irq;
> +
> BUG_ON(!np->hands_off);
> ret = pci_enable_device(pdev);
> if (ret < 0) {
> @@ -3320,13 +3331,13 @@ static int natsemi_resume (struct pci_dev *pdev)
>
> natsemi_reset(dev);
> init_ring(dev);
> - disable_irq(dev->irq);
> + disable_irq(irq);
> spin_lock_irq(&np->lock);
> np->hands_off = 0;
> init_registers(dev);
> netif_device_attach(dev);
> spin_unlock_irq(&np->lock);
> - enable_irq(dev->irq);
> + enable_irq(irq);
>
> mod_timer(&np->timer, round_jiffies(jiffies + 1*HZ));
> }
> --
> 1.7.7.6
>
^ permalink raw reply
* Re: [RFC] API to modify /proc/sys/net/ipv4/ip_local_reserved_ports
From: Eric W. Biederman @ 2012-04-10 22:13 UTC (permalink / raw)
To: Helge Deller
Cc: Cong Wang, Octavian Purdila, netdev, David Miller, Andrew Morton,
Frank Danapfel, Laszlo Ersek, shemminger
In-Reply-To: <4F84A06F.3090808@gmx.de>
Helge Deller <deller@gmx.de> writes:
> On 04/09/2012 10:43 AM, Cong Wang wrote:
>> On Wed, 2012-04-04 at 22:24 +0200, Helge Deller wrote:
>>> I would like to follow up on my last patch series to be able to modify
>>> the contents of the /proc/sys/net/ipv4/ip_local_reserved_ports port list
>>> from userspace.
>>>
>>> My last patch (https://lkml.org/lkml/2012/3/10/187) was based on
>>> modifications to the proc interface, which - based on the feedback here
>>> on the list - seemed to not be the right way to go (although I personally
>>> still like the idea very much :-)).
>>>
>>> Anyway, with this RFC I would like to get feedback about a new proposed
>>> API and attached kernel patch.
>>>
>>> The idea is to introduce a new<optname> value for get/setsockopt()
>>> named SO_RESERVED_PORTS to get/set the ip_local_reserved_ports
>>> bitmap via standard get/setsockopt() syscalls.
>>> As far as I understand this seems to be similiar to how iptables works.
>>>
>>> An untested kernel patch for review and feedback is attached below.
>>>
>>> In userspace it then would be possible to write a new tool or to extend
>>> for example the "ip" tool to accept commands like:
>>> $> ip reserved_ports add 100-2000
>>> $> ip reserved_ports remove 50-60
>>> $> ip reserved_ports list (to show current reserved port list)
>>>
>>> This userspace tool could then read the port bitmap from kernel via
>>> a) socket(PF_INET, SOCK_RAW, IPPROTO_RAW)
>>> b) getsockopt(3, SOL_SOCKET, SO_RESERVED_PORTS,<bitmaplist>)
>>> and write back the results after modification via
>>> c) setsockopt(3, SOL_SOCKET, SO_RESERVED_PORTS,<bitmaplist>)
>>>
>>> Would that be an acceptable solution?
>> Hmm, it is indeed that bitmap fits for syscall rather than /proc file.
>>
>> But it seems that using getsockopt()/setsockopt() makes it like it is a
>> per-socket setting, actually it is a system-wide setting.
> Yes, that's the reason why I used SOL_SOCKET which configures at least
> a few system-wide settings too.
>
>> So I am
>> wondering if exporting a binary /proc file for this is a better
>> solution.
> Yeah - that's another solution, but (65536 ports)/(8 bits per byte) = 8 KByte,
> so we
> may again hit the 4k limit of /proc (unless you do binary reads which should
> be done with a binary /proc-entry anyway).
>
> Again, I'm open to develop any kind of solution which would get an OK
> here.
Just looking at proc_do_large_bitmap, it does appear that there is a
very local 4k limit on writes.
Can you please just modify proc_do_large_bitmap so that there is not a
4k limit on writes. Ideally the code would just read another 4k from
userspace when it is getting close to the end of it's 4k buffer, or
perhaps we just read everything directly from userspace and run slowly.
The bitmap is installed atomically at the end so any weird partial
states should not be a problem..
Eric
^ permalink raw reply
* p54: Weird error in log
From: Bjarke Istrup Pedersen @ 2012-04-10 21:30 UTC (permalink / raw)
To: linux-kernel, netdev
Hey,
I keep getting this error in my dmesg log:
p54pci 0000:00:0e.0: rx'd frame size exceeds length threshold
The p54 card is bridged together with two via-rhine network cards, to
create an access point.
The card seems to work fine - it is just that this message floods the
logs - I could comment it out in the driver, but it would make more
sense to figure out if it is a bug that causes it to get hit, or a
configuration issue.
Any ideas?
/Bjarke
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample
From: Dave Taht @ 2012-04-10 21:24 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, ncardwell, netdev, nanditad, ycheng, edumazet,
therbert
In-Reply-To: <1334092931.5300.648.camel@edumazet-glaptop>
On Tue, Apr 10, 2012 at 2:22 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2012-04-10 at 17:16 -0400, David Miller wrote:
>
>> Sorry, that's my private URL and only works if you're logged
>> in as me :-) This one is better:
>>
>> http://patchwork.ozlabs.org/bundle/davem/stable/?state=*
>
> Thanks, added to my bookmarks ;)
Mine too! I had no idea. Useful.
Is there an emacs interface? :)
>
>
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample
From: Eric Dumazet @ 2012-04-10 21:22 UTC (permalink / raw)
To: David Miller
Cc: dave.taht, ncardwell, netdev, nanditad, ycheng, edumazet,
therbert
In-Reply-To: <20120410.171637.622088330832657275.davem@davemloft.net>
On Tue, 2012-04-10 at 17:16 -0400, David Miller wrote:
> Sorry, that's my private URL and only works if you're logged
> in as me :-) This one is better:
>
> http://patchwork.ozlabs.org/bundle/davem/stable/?state=*
Thanks, added to my bookmarks ;)
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample
From: David Miller @ 2012-04-10 21:16 UTC (permalink / raw)
To: eric.dumazet
Cc: dave.taht, ncardwell, netdev, nanditad, ycheng, edumazet,
therbert
In-Reply-To: <1334092294.5300.614.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 10 Apr 2012 23:11:34 +0200
> On Tue, 2012-04-10 at 17:07 -0400, David Miller wrote:
>> From: Dave Taht <dave.taht@gmail.com>
>> Date: Tue, 10 Apr 2012 13:46:38 -0700
>>
>> > awesome, is this needed in stable?
>>
>> I have it queued up there already.
>>
>> But you didn't need to write your email at all, you could
>> have checked this yourself:
>>
>> http://patchwork.ozlabs.org/user/bundle/2566/?state=*
>
> Not sure this URL works (it doesnt for me)
Sorry, that's my private URL and only works if you're logged
in as me :-) This one is better:
http://patchwork.ozlabs.org/bundle/davem/stable/?state=*
^ permalink raw reply
* Re: via-rhine: Problem with lost link after a while
From: Bjarke Istrup Pedersen @ 2012-04-10 21:15 UTC (permalink / raw)
To: Francois Romieu; +Cc: linux-kernel, netdev
In-Reply-To: <20120410204249.GA26627@electric-eye.fr.zoreil.com>
10. apr. 2012 22.42 skrev Francois Romieu <romieu@fr.zoreil.com>:
> Bjarke Istrup Pedersen <gurligebis@gentoo.org> :
> [...]
>> Got any ideas?
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;h=3f8c91a7398b9266fbe7abcbe4bd5dffef907643
>
> Courtesy of Andreas Mohr.
Great, I'll try a 3.4-rc2 kernel, and see how it runs.
The thread I was talking about earlier is here:
http://lists.soekris.com/pipermail/soekris-tech/2012-April/018318.html
Is there any of the changes he has there, that makes sense in the new
driver you wrote?
Thanks :)
/Bjarke
> --
> Ueimor
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample
From: Eric Dumazet @ 2012-04-10 21:11 UTC (permalink / raw)
To: David Miller
Cc: dave.taht, ncardwell, netdev, nanditad, ycheng, edumazet,
therbert
In-Reply-To: <20120410.170749.354288312321198124.davem@davemloft.net>
On Tue, 2012-04-10 at 17:07 -0400, David Miller wrote:
> From: Dave Taht <dave.taht@gmail.com>
> Date: Tue, 10 Apr 2012 13:46:38 -0700
>
> > awesome, is this needed in stable?
>
> I have it queued up there already.
>
> But you didn't need to write your email at all, you could
> have checked this yourself:
>
> http://patchwork.ozlabs.org/user/bundle/2566/?state=*
Not sure this URL works (it doesnt for me)
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample
From: David Miller @ 2012-04-10 21:07 UTC (permalink / raw)
To: dave.taht; +Cc: ncardwell, netdev, nanditad, ycheng, edumazet, therbert
In-Reply-To: <CAA93jw5opbBobzkgJ2diRPu2X0aKOsnF9hmcm_LfsLPipeAK7g@mail.gmail.com>
From: Dave Taht <dave.taht@gmail.com>
Date: Tue, 10 Apr 2012 13:46:38 -0700
> awesome, is this needed in stable?
I have it queued up there already.
But you didn't need to write your email at all, you could
have checked this yourself:
http://patchwork.ozlabs.org/user/bundle/2566/?state=*
^ permalink raw reply
* Re: [RFC] API to modify /proc/sys/net/ipv4/ip_local_reserved_ports
From: Helge Deller @ 2012-04-10 21:04 UTC (permalink / raw)
To: Cong Wang
Cc: Octavian Purdila, netdev, David Miller, Andrew Morton,
Eric W. Biederman, Frank Danapfel, Laszlo Ersek, shemminger
In-Reply-To: <1333960981.414.24.camel@cr0>
On 04/09/2012 10:43 AM, Cong Wang wrote:
> On Wed, 2012-04-04 at 22:24 +0200, Helge Deller wrote:
>> I would like to follow up on my last patch series to be able to modify
>> the contents of the /proc/sys/net/ipv4/ip_local_reserved_ports port list
>> from userspace.
>>
>> My last patch (https://lkml.org/lkml/2012/3/10/187) was based on
>> modifications to the proc interface, which - based on the feedback here
>> on the list - seemed to not be the right way to go (although I personally
>> still like the idea very much :-)).
>>
>> Anyway, with this RFC I would like to get feedback about a new proposed
>> API and attached kernel patch.
>>
>> The idea is to introduce a new<optname> value for get/setsockopt()
>> named SO_RESERVED_PORTS to get/set the ip_local_reserved_ports
>> bitmap via standard get/setsockopt() syscalls.
>> As far as I understand this seems to be similiar to how iptables works.
>>
>> An untested kernel patch for review and feedback is attached below.
>>
>> In userspace it then would be possible to write a new tool or to extend
>> for example the "ip" tool to accept commands like:
>> $> ip reserved_ports add 100-2000
>> $> ip reserved_ports remove 50-60
>> $> ip reserved_ports list (to show current reserved port list)
>>
>> This userspace tool could then read the port bitmap from kernel via
>> a) socket(PF_INET, SOCK_RAW, IPPROTO_RAW)
>> b) getsockopt(3, SOL_SOCKET, SO_RESERVED_PORTS,<bitmaplist>)
>> and write back the results after modification via
>> c) setsockopt(3, SOL_SOCKET, SO_RESERVED_PORTS,<bitmaplist>)
>>
>> Would that be an acceptable solution?
> Hmm, it is indeed that bitmap fits for syscall rather than /proc file.
>
> But it seems that using getsockopt()/setsockopt() makes it like it is a
> per-socket setting, actually it is a system-wide setting.
Yes, that's the reason why I used SOL_SOCKET which configures at least
a few system-wide settings too.
> So I am
> wondering if exporting a binary /proc file for this is a better
> solution.
Yeah - that's another solution, but (65536 ports)/(8 bits per byte) = 8
KByte, so we
may again hit the 4k limit of /proc (unless you do binary reads which should
be done with a binary /proc-entry anyway).
Again, I'm open to develop any kind of solution which would get an OK here.
Helge
^ permalink raw reply
* [PATCH 4/4] net: Remove redundant spi driver bus initialization
From: Lars-Peter Clausen @ 2012-04-10 20:51 UTC (permalink / raw)
To: linux-kernel
Cc: Lars-Peter Clausen, David S. Miller, Gabor Juhos,
Frederic Lambert, netdev
In-Reply-To: <1334091089-10138-1-git-send-email-lars@metafoo.de>
In ancient times it was necessary to manually initialize the bus field of an
spi_driver to spi_bus_type. These days this is done in spi_driver_register() so
we can drop the manual assignment.
The patch was generated using the following coccinelle semantic patch:
// <smpl>
@@
identifier _driver;
@@
struct spi_driver _driver = {
.driver = {
- .bus = &spi_bus_type,
},
};
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Gabor Juhos <juhosg@openwrt.org>
Cc: Frederic Lambert <frdrc66@gmail.com>
Cc: netdev@vger.kernel.org
---
drivers/net/phy/spi_ks8995.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/phy/spi_ks8995.c b/drivers/net/phy/spi_ks8995.c
index 116a2dd..4eb98bc 100644
--- a/drivers/net/phy/spi_ks8995.c
+++ b/drivers/net/phy/spi_ks8995.c
@@ -348,7 +348,6 @@ static int __devexit ks8995_remove(struct spi_device *spi)
static struct spi_driver ks8995_driver = {
.driver = {
.name = "spi-ks8995",
- .bus = &spi_bus_type,
.owner = THIS_MODULE,
},
.probe = ks8995_probe,
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample
From: Dave Taht @ 2012-04-10 20:46 UTC (permalink / raw)
To: David Miller; +Cc: ncardwell, netdev, nanditad, ycheng, edumazet, therbert
In-Reply-To: <20120410.144737.1047745906309843732.davem@davemloft.net>
On Tue, Apr 10, 2012 at 11:47 AM, David Miller <davem@davemloft.net> wrote:
> From: Neal Cardwell <ncardwell@google.com>
> Date: Tue, 10 Apr 2012 13:59:20 -0400
>
>> Fix a code path in tcp_rcv_rtt_update() that was comparing scaled and
>> unscaled RTT samples.
>>
>> The intent in the code was to only use the 'm' measurement if it was a
>> new minimum. However, since 'm' had not yet been shifted left 3 bits
>> but 'new_sample' had, this comparison would nearly always succeed,
>> leading us to erroneously set our receive-side RTT estimate to the 'm'
>> sample when that sample could be nearly 8x too high to use.
>>
>> The overall effect is to often cause the receive-side RTT estimate to
>> be significantly too large (up to 40% too large for brief periods in
>> my tests).
>>
>> Signed-off-by: Neal Cardwell <ncardwell@google.com>
>
> Applied, thanks.
> --
awesome, is this needed in stable?
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
^ permalink raw reply
* Re: Please revert removal of /sys/class/net/*/features
From: Stephen Hemminger @ 2012-04-10 20:46 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Michał Mirosław, David Miller, netdev
In-Reply-To: <1334089547.2624.4.camel@bwh-desktop.uk.solarflarecom.com>
On Tue, 10 Apr 2012 21:25:47 +0100
Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Tue, 2012-04-10 at 21:59 +0200, Michał Mirosław wrote:
> > On Tue, Apr 10, 2012 at 11:08:51AM -0700, Stephen Hemminger wrote:
> > > This commit needs to be reverted. It removed an available sysfs file, and sysfs
> > > files are part of the ABI. It caused a bug in our current release of Vyatta because
> > > the shell script was using the sysfs file to see if VLAN was supported on a device.
> > >
> > > An API maybe redundant, but you can't just remove it.
> >
> > There was a discussion about it before the patch was accepted. It was
> > concluded that due to features flags changes, the /sys/class/net/*/features
> > was never a stable API.
>
> For reference:
> http://thread.gmane.org/gmane.linux.network/199115/focus=199136
>
> But note that the VLAN-related feature flags never actually changed
> value.
>
> Ben.
>
It is actually not a big deal for our product since 3.3 is
really early in development cycle and the script can be fixed in
that release. Also, we release an image with utilities, scripts and
kernel in one release, and don't have to support running new kernels with
older userspace.
I am more worried that other people might be hit
the same thing. What about a patch to keep the old flags values
available for backwards compatiablity. Also, when removing a sysfs
file, shouldn't the documented feature removal process be used?
^ permalink raw reply
* Re: via-rhine: Problem with lost link after a while
From: Francois Romieu @ 2012-04-10 20:42 UTC (permalink / raw)
To: Bjarke Istrup Pedersen; +Cc: linux-kernel, netdev
In-Reply-To: <CACPM=kWa=UWuCMaYAtVMGJ7pzCy-PfyNRWBSuJnTZGtssU0W6g@mail.gmail.com>
Bjarke Istrup Pedersen <gurligebis@gentoo.org> :
[...]
> Got any ideas?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;h=3f8c91a7398b9266fbe7abcbe4bd5dffef907643
Courtesy of Andreas Mohr.
--
Ueimor
^ 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