* 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: [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: 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
* 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: [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
* 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: 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: 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: [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: [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: 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: [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: [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: 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: [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: [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
* [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
* [PATCH 06/11] enic: 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/cisco/enic/enic_pp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/cisco/enic/enic_pp.c b/drivers/net/ethernet/cisco/enic/enic_pp.c
index dafea1e..43464f0 100644
--- a/drivers/net/ethernet/cisco/enic/enic_pp.c
+++ b/drivers/net/ethernet/cisco/enic/enic_pp.c
@@ -184,7 +184,7 @@ static int (*enic_pp_handlers[])(struct enic *enic, int vf,
};
static const int enic_pp_handlers_count =
- sizeof(enic_pp_handlers)/sizeof(*enic_pp_handlers);
+ ARRAY_SIZE(enic_pp_handlers);
static int enic_pp_preassociate(struct enic *enic, int vf,
struct enic_port_profile *prev_pp, int *restore_pp)
--
1.7.8.1
^ permalink raw reply related
* [PATCH 07/11] ethernet: replace open-coded ARRAY_SIZE with macro
From: Jim Cromie @ 2012-04-11 0:56 UTC (permalink / raw)
To: netdev, davem, jeffrey.t.kirsher, joe, florian, netdev
Cc: trivial, Jim Cromie
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
drivers/net/ethernet/s6gmac.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/s6gmac.c b/drivers/net/ethernet/s6gmac.c
index 1895605..8e9fda0 100644
--- a/drivers/net/ethernet/s6gmac.c
+++ b/drivers/net/ethernet/s6gmac.c
@@ -937,7 +937,7 @@ static struct net_device_stats *s6gmac_stats(struct net_device *dev)
do {
unsigned long flags;
spin_lock_irqsave(&pd->lock, flags);
- for (i = 0; i < sizeof(pd->stats) / sizeof(unsigned long); i++)
+ for (i = 0; i < ARRAY_SIZE(pd->stats); i++)
pd->stats[i] =
pd->carry[i] << (S6_GMAC_STAT_SIZE_MIN - 1);
s6gmac_stats_collect(pd, &statinf[0][0]);
--
1.7.8.1
^ permalink raw reply related
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: Tim Hockin @ 2012-04-11 0:59 UTC (permalink / raw)
To: David Miller; +Cc: romieu, netdev
In-Reply-To: <20120410.204202.923592889066244236.davem@davemloft.net>
On Tue, Apr 10, 2012 at 5:42 PM, David Miller <davem@davemloft.net> wrote:
> 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.
I'm OK with that. As much as I don't like being a deadbeat, it's a
more accurate snapshot of this driver today.
Tim
^ permalink raw reply
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: David Miller @ 2012-04-11 1:11 UTC (permalink / raw)
To: thockin; +Cc: romieu, netdev
In-Reply-To: <CAAAKZwsVA7XxbbUfYRdC20Z0gjTG-3vAmQibA1Z5yaFdpa9jgA@mail.gmail.com>
From: Tim Hockin <thockin@hockin.org>
Date: Tue, 10 Apr 2012 17:59:40 -0700
> On Tue, Apr 10, 2012 at 5:42 PM, David Miller <davem@davemloft.net> wrote:
>> 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.
>
> I'm OK with that. As much as I don't like being a deadbeat, it's a
> more accurate snapshot of this driver today.
Ok, I'll push that MAINTAINERS change, thanks Tim.
^ permalink raw reply
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: Tim Hockin @ 2012-04-11 1:16 UTC (permalink / raw)
To: David Miller; +Cc: romieu, netdev
In-Reply-To: <20120410.211114.643908401942868800.davem@davemloft.net>
On Tue, Apr 10, 2012 at 6:11 PM, David Miller <davem@davemloft.net> wrote:
> From: Tim Hockin <thockin@hockin.org>
> Date: Tue, 10 Apr 2012 17:59:40 -0700
>
>> On Tue, Apr 10, 2012 at 5:42 PM, David Miller <davem@davemloft.net> wrote:
>>> 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.
>>
>> I'm OK with that. As much as I don't like being a deadbeat, it's a
>> more accurate snapshot of this driver today.
>
> Ok, I'll push that MAINTAINERS change, thanks Tim.
I wish there were a way to say "I know a fair amount about this
device" without claiming an "M" line (send patches here).
Tim
^ permalink raw reply
* Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: Stephen Hemminger @ 2012-04-11 1:28 UTC (permalink / raw)
To: Arvid Brodin
Cc: Ben Hutchings, David Miller, netdev@vger.kernel.org,
balferreira@googlemail.com
In-Reply-To: <4F84CA36.7020209@xdin.com>
> 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?
>
Reading Documentation/unalgined-memory-access.txt suggests that you
probably should copy the skb before passing up the stack (if necessary).
That is safe (but slightly slower).
^ permalink raw reply
* Re: [net-next PATCH v1 7/7] macvlan: add FDB bridge ops and new macvlan mode
From: John Fastabend @ 2012-04-11 1:42 UTC (permalink / raw)
To: Sridhar Samudrala, Michael S. Tsirkin
Cc: roprabhu, stephen.hemminger, davem, hadi, bhutchings,
jeffrey.t.kirsher, netdev, gregory.v.rose, krkumar2
In-Reply-To: <4F84D472.8090602@us.ibm.com>
On 4/10/2012 5:46 PM, Sridhar Samudrala wrote:
> 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
>
Sridhar, Michael,
After thinking about this a bit I would propose keeping this
patch as is. Or if we prefer I can make this a flag but I don't
think that helps much. passthru mode is the only macvlan mode
that calls dev_set_promiscuity(). Either way I think this mode
or flag should _only_ toggle the call to dev_set_promiscuity().
Setting multicast dev->flag IFF_ALLMULTI seems to be a completely
separate optimization that we can work with a follow up patch.
Any thoughts?
Thanks for the feedback,
John
^ permalink raw reply
* rcu_sched_state detected stall, no stack trace
From: Prashant Batra (prbatra) @ 2012-04-11 2:20 UTC (permalink / raw)
To: netdev
Hi,
I am running vanilla kernel 3.0.23 . I am trying to add some 6K and more
IPv6 IPSec tunnels.
I am getting these warnings in dmesg close to 6k tunnels, after which
the kernel hangs and have to reboot the kernel.
[ 1511.045261] INFO: rcu_sched_state detected stall on CPU 4 (t=300000
jiffies) [ 1534.736899] INFO: rcu_bh_state detected stalls on
CPUs/tasks: { 4} (detected by 13, t=300002 jiffies)
I am not getting any back-trace also, to figure out what is actually
causing the stall to happen.
Could someone help to figure out the issue.
Regards,
Prashant
^ 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