* Re: [PATCH v4 1/9] atm: propagate signal changes via notifier
From: Karl Hiramoto @ 2010-07-09 6:36 UTC (permalink / raw)
To: David Miller; +Cc: linux-atm-general, netdev, chas
In-Reply-To: <20100708.214745.48520104.davem@davemloft.net>
On 07/09/2010 06:47 AM, David Miller wrote:
> From: Karl Hiramoto <karl@hiramoto.org>
> Date: Thu, 8 Jul 2010 10:34:47 +0200
>
>> +
>> +/*
>> + * atm_dev_signal_change
>> + *
>> + * Propagate lower layer signal change in atm_dev->signal to netdevice.
>> + * The event will be sent via a notifier call chain.
>> + */
> I said to format comments:
>
> /* Like
> * this.
> */
>
> not:
>
> /*
> * Like
> * this.
> */
>
> Honestly, I don't know how I can be more clear about this :-)
Ok, fixing it, but there are 100's of occurences in net/ like i had it. :-)
--
Karl
^ permalink raw reply
* Re: [PATCH 2/6 net-next-2.6] vxge: Use fifo based trans_start time
From: David Miller @ 2010-07-09 6:34 UTC (permalink / raw)
To: jon.mason; +Cc: netdev, sreenivasa.honnur, ram.vepa
In-Reply-To: <20100708192125.GB15167@exar.com>
From: Jon Mason <jon.mason@exar.com>
Date: Thu, 8 Jul 2010 14:21:26 -0500
> @@ -968,8 +969,10 @@ vxge_xmit(struct sk_buff *skb, struct net_device *dev)
> VXGE_HW_FIFO_TXD_TX_CKO_UDP_EN);
>
> vxge_hw_fifo_txdl_post(fifo_hw, dtr);
> +
> #ifdef NETIF_F_LLTX
> - dev->trans_start = jiffies; /* NETIF_F_LLTX driver :( */
> + txq = netdev_get_tx_queue(dev, vpath_no);
> + txq->trans_start = jiffies;
> #endif
This comment was placed there not just for it's artistic value,
you should heed what it's saying when making changes like this.
NETIF_F_LLTX drivers cannot use the per-txq trans_start mechanism,
because doing so is racy.
The dev_watchdog() timer, which checks these ->trans_start values,
can only synchornize with the driver by the traditional means,
which is by taking the spinlock on the TX queue. This is bypassed
by NETIF_F_LLTX drivers, so the driver can be in it's TX handler
while the watchdog timer is trying to evaluate the trans_start
state.
This is one of a many reasons why NETIF_F_LLTX is a bad idea and you
should convert your driver away from it.
^ permalink raw reply
* [PATCH v2] ks8842: Do the TX timeout work in workqueue context.
From: Richard Röjfors @ 2010-07-09 6:01 UTC (permalink / raw)
To: netdev; +Cc: davem
Currently all code that needs to be run at TX timeout is done in the
calling context, where bottom halves are disabled. Some of the code
blocks, so it needs to be done in a different context. This patch
adds in a work struct which is scheduled at TX timeout. Then the
timeout code is executed within work queue context.
In the process an unnecessary bank change before resetting the
controller was removed.
Signed-off-by: Richard Röjfors <richard.rojfors@pelagicore.com>
---
diff --git a/drivers/net/ks8842.c b/drivers/net/ks8842.c
index d47bba9..0be9261 100644
--- a/drivers/net/ks8842.c
+++ b/drivers/net/ks8842.c
@@ -119,6 +119,8 @@ struct ks8842_adapter {
int irq;
struct tasklet_struct tasklet;
spinlock_t lock; /* spinlock to be interrupt safe */
+ struct work_struct timeout_work;
+ struct net_device *netdev;
};
static inline void ks8842_select_bank(struct ks8842_adapter *adapter, u16 bank)
@@ -197,7 +199,6 @@ static void ks8842_reset(struct ks8842_adapter *adapter)
msleep(10);
iowrite16(0, adapter->hw_addr + REG_GRR);
*/
- iowrite16(32, adapter->hw_addr + REG_SELECT_BANK);
iowrite32(0x1, adapter->hw_addr + REG_TIMB_RST);
msleep(20);
}
@@ -553,6 +554,8 @@ static int ks8842_close(struct net_device *netdev)
netdev_dbg(netdev, "%s - entry\n", __func__);
+ cancel_work_sync(&adapter->timeout_work);
+
/* free the irq */
free_irq(adapter->irq, netdev);
@@ -595,9 +598,11 @@ static int ks8842_set_mac(struct net_device *netdev, void *p)
return 0;
}
-static void ks8842_tx_timeout(struct net_device *netdev)
+static void ks8842_tx_timeout_work(struct work_struct *work)
{
- struct ks8842_adapter *adapter = netdev_priv(netdev);
+ struct ks8842_adapter *adapter =
+ container_of(work, struct ks8842_adapter, timeout_work);
+ struct net_device *netdev = adapter->netdev;
unsigned long flags;
netdev_dbg(netdev, "%s: entry\n", __func__);
@@ -606,6 +611,9 @@ static void ks8842_tx_timeout(struct net_device *netdev)
/* disable interrupts */
ks8842_write16(adapter, 18, 0, REG_IER);
ks8842_write16(adapter, 18, 0xFFFF, REG_ISR);
+
+ netif_stop_queue(netdev);
+
spin_unlock_irqrestore(&adapter->lock, flags);
ks8842_reset_hw(adapter);
@@ -615,6 +623,15 @@ static void ks8842_tx_timeout(struct net_device *netdev)
ks8842_update_link_status(netdev, adapter);
}
+static void ks8842_tx_timeout(struct net_device *netdev)
+{
+ struct ks8842_adapter *adapter = netdev_priv(netdev);
+
+ netdev_dbg(netdev, "%s: entry\n", __func__);
+
+ schedule_work(&adapter->timeout_work);
+}
+
static const struct net_device_ops ks8842_netdev_ops = {
.ndo_open = ks8842_open,
.ndo_stop = ks8842_close,
@@ -649,6 +666,8 @@ static int __devinit ks8842_probe(struct platform_device *pdev)
SET_NETDEV_DEV(netdev, &pdev->dev);
adapter = netdev_priv(netdev);
+ adapter->netdev = netdev;
+ INIT_WORK(&adapter->timeout_work, ks8842_tx_timeout_work);
adapter->hw_addr = ioremap(iomem->start, resource_size(iomem));
if (!adapter->hw_addr)
goto err_ioremap;
^ permalink raw reply related
* Re: [PATCH -net-2.6] ll_temac: fix DMA resources leak
From: David Miller @ 2010-07-09 6:23 UTC (permalink / raw)
To: dkirjanov; +Cc: john.linn, brian.hill, netdev
In-Reply-To: <20100708135445.GA30923@hera.kernel.org>
From: Denis Kirjanov <dkirjanov@hera.kernel.org>
Date: Thu, 8 Jul 2010 13:54:45 +0000
> Fix DMA resources leak.
>
> Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: 2.6.35-rc4-git3: Reported regressions from 2.6.34
From: David Miller @ 2010-07-09 6:20 UTC (permalink / raw)
To: eric.dumazet
Cc: torvalds, rjw, linux-kernel, akpm, netdev, kaber, jengelh,
casteyde.christian
In-Reply-To: <1278653334.2435.196.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 09 Jul 2010 07:28:54 +0200
> Le jeudi 08 juillet 2010 à 21:34 -0700, David Miller a écrit :
>> From: Linus Torvalds <torvalds@linux-foundation.org>
>> Date: Thu, 8 Jul 2010 18:34:25 -0700
>>
>> > On Thu, Jul 8, 2010 at 4:33 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> >>
>> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16187
>> >> Subject : Carrier detection failed in dhcpcd when link is up
>> >> Submitter : Christian Casteyde <casteyde.christian@free.fr>
>> >> Date : 2010-06-12 15:15 (27 days old)
>> >> First-Bad-Commit: http://git.kernel.org/linus/10708f37ae729baba9b67bd134c3720709d4ae62
>> >> Handled-By : Andrew Morton <akpm@linux-foundation.org>
>> >
>> > David? This bisects to a networking commit. Doesn't look sensible, but
>> > what do I know?
>>
>> My suspicion is that dhcpd uses netlink to dump the info of the
>> available links, and due to some bug gets confused with the new 64-bit
>> statistic netlink attribute being there now.
>> a second to have a look at this.
>
> It could be a dhcpcd bug because of extended size of answer
>
> According to strace, dhcpcd tries a recvmsg() call with
> a 256 bytes buffer to hold answer.
>
> Looking at current dhcpcd source, I confirm it cannot realloc its buffer
...
> This program needs to fix this.
Agreed, I don't there is any reasonable way we could cater to this
application bug with some compatability bits. Restricting the link
dump to 256 bytes is just too much inflexibility.
If NetworkManager can get this right, dhcpd very well can too :-)
^ permalink raw reply
* Re: [PATCH] cxgb4vf: remove obsolete DECLARE_PCI_UNMAP_ADDR usage
From: FUJITA Tomonori @ 2010-07-09 6:12 UTC (permalink / raw)
To: davem; +Cc: fujita.tomonori, leedom, netdev
In-Reply-To: <20100708.230939.102558536.davem@davemloft.net>
On Thu, 08 Jul 2010 23:09:39 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> > btw, I'm not sure that seeing if a platform does real DMA unmapping in
> > a driver is a good thing. But I suppose that we need to accept it if
> > this leads to big performance boost.
> >
> > Both can be applied to net-next.
>
> I think the value of these "optimizations" is rapidly decreasing to
> zero. And I believe I've told the authors of either this driver or
> another one that they should just remove this stuff completely.
I prefer to remove this stuff completely too.
If this trick improves the performance greatly, we could add this to
the DMA API (that's better than adding such ifdef hack to drivers).
^ permalink raw reply
* Re: [PATCH net-next-2.6 V2] tg3: 64 bit stats on all arches
From: David Miller @ 2010-07-09 6:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, mcarlson, mchan
In-Reply-To: <1278571464.2543.7.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 08 Jul 2010 08:44:24 +0200
> Now core network is able to handle 64 bit netdevice stats on 32 bit
> arches, we can provide them for tg3, since hardware maintains 64 bit
> counters.
>
> I'll provide bnx2 and bnx2x patches as well.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bnx2: 64 bit stats on all arches
From: David Miller @ 2010-07-09 6:13 UTC (permalink / raw)
To: eric.dumazet; +Cc: mchan, netdev, mcarlson
In-Reply-To: <1278598123.2651.24.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 08 Jul 2010 16:08:43 +0200
> [PATCH net-next-2.6] bnx2: 64 bit stats on all arches
>
> Now core network is able to handle 64 bit netdevice stats on 32 bit
> arches, we can provide them for bnx2, since hardware maintains some 64
> bit counters.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Acked-by: Michael Chan <mchan@broadcom.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] tg3: allow TSO on vlan devices
From: David Miller @ 2010-07-09 6:12 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, mcarlson, mchan
In-Reply-To: <1278605695.2651.48.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 08 Jul 2010 18:14:55 +0200
> Similar to commit 72dccb01e8632aa (bnx2: Update vlan_features)
>
> In order to enable TSO on vlan devices, tg3 needs to update
> dev->vlan_features.
>
> Tested on HP NC326m (aka BCM5715S (rev a3))
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3] vlan: allow TSO setting on vlan interfaces
From: David Miller @ 2010-07-09 6:10 UTC (permalink / raw)
To: bhutchings; +Cc: eric.dumazet, netdev, kaber
In-Reply-To: <1278613548.16013.193.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 08 Jul 2010 19:25:48 +0100
> On Thu, 2010-07-08 at 18:37 +0200, Eric Dumazet wrote:
>> When we need to shape traffic using low speeds, we need to
>> disable tso on network interface :
>>
>> ethtool -K eth0.2240 tso off
>>
>> It seems vlan interfaces miss the set_tso() ethtool method.
>>
>> Before enabling TSO, we must check real device supports
>> TSO for VLAN-tagged packets and enables TSO.
>>
>> Note that a TSO change on real device propagates TSO setting
>> on all vlans, even if admin selected a different TSO setting.
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Ok, just to clarify, I'll make sure I get this version instead of "v2"
which I just replied to :)
^ permalink raw reply
* Re: [PATCH v2] vlan: allow TSO setting on vlan interfaces
From: David Miller @ 2010-07-09 6:10 UTC (permalink / raw)
To: eric.dumazet; +Cc: bhutchings, netdev, kaber
In-Reply-To: <1278581971.2651.10.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 08 Jul 2010 11:39:31 +0200
> When we need to shape traffic with low speeds, we need to disable tso on
> network interface :
>
> ethtool -K eth0.2240 tso off
>
> It seems vlan interfaces miss the set_tso() ethtool method.
> Propagating tso changes from lower device is not always wanted, some
> vlans want TSO on, others want TSO off.
>
> Before enabling TSO, we must check real device supports it.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-next-2.6, thanks Eric.
^ permalink raw reply
* Re: [PATCH] cxgb4vf: remove obsolete DECLARE_PCI_UNMAP_ADDR usage
From: David Miller @ 2010-07-09 6:09 UTC (permalink / raw)
To: fujita.tomonori; +Cc: leedom, netdev
In-Reply-To: <20100708190126X.fujita.tomonori@lab.ntt.co.jp>
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Date: Thu, 08 Jul 2010 19:01:26 +0900
> On Thu, 8 Jul 2010 18:52:37 +0900
> FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
>
>> We could use DEFINE_DMA_UNMAP_ADDR instead but using
>> CONFIG_NEED_DMA_MAP_STATE is a simpler way to see if a platform does
>> real DMA unmapping.
>>
>> Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
>> ---
>> drivers/net/cxgb4vf/sge.c | 14 +++++---------
>> 1 files changed, 5 insertions(+), 9 deletions(-)
>
> btw, I'm not sure that seeing if a platform does real DMA unmapping in
> a driver is a good thing. But I suppose that we need to accept it if
> this leads to big performance boost.
>
> Both can be applied to net-next.
I think the value of these "optimizations" is rapidly decreasing to
zero. And I believe I've told the authors of either this driver or
another one that they should just remove this stuff completely.
^ permalink raw reply
* Re: [PATCH] cxgb3: simplify need_skb_unmap
From: David Miller @ 2010-07-09 6:08 UTC (permalink / raw)
To: fujita.tomonori; +Cc: netdev, divy
In-Reply-To: <20100708185209E.fujita.tomonori@lab.ntt.co.jp>
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Date: Thu, 8 Jul 2010 18:52:38 +0900
> We can use CONFIG_NEED_DMA_MAP_STATE to see if a platform does real
> DMA unmapping.
>
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Applied.
^ permalink raw reply
* Re: [PATCH] cxgb4vf: remove obsolete DECLARE_PCI_UNMAP_ADDR usage
From: David Miller @ 2010-07-09 6:08 UTC (permalink / raw)
To: fujita.tomonori; +Cc: netdev, leedom
In-Reply-To: <20100708185111D.fujita.tomonori@lab.ntt.co.jp>
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Date: Thu, 8 Jul 2010 18:52:37 +0900
> We could use DEFINE_DMA_UNMAP_ADDR instead but using
> CONFIG_NEED_DMA_MAP_STATE is a simpler way to see if a platform does
> real DMA unmapping.
>
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Applied.
^ permalink raw reply
* Re: [PATCH linux-2.6.35-rc3] ks8842 driver
From: Simon Horman @ 2010-07-09 6:08 UTC (permalink / raw)
To: David Miller; +Cc: David.Choi, netdev, Charles.Li
In-Reply-To: <20100708.214101.39178389.davem@davemloft.net>
On Thu, Jul 08, 2010 at 09:41:01PM -0700, David Miller wrote:
> From: "Choi, David" <David.Choi@Micrel.Com>
> Date: Thu, 8 Jul 2010 12:01:51 -0700
>
> > The original ks8842 driver is designed to work on the customized bus
> > interface based on an FPGA. This patch is intended to address the more
> > commonly used generic bus interface available on the majority of SoC in
> > the market.
> >
> > It is unlikely that for a system to use both FPGA based and generic bus
> > interface for ks8842, I am quite certain that those 2 devices are used
> > mutual exclusively.
>
> Like Simon, I'm not to thrilled with this approach.
>
> Any flag bit test you'd need to add to the driver to handle both cases
> will have zero performance impact since the cost of the MMIO accesses
> will dominate such tests entirely.
>
> Add a boolean flag bit to the driver software state, set it based upon
> some platform_device private setting, and test it in these paths to
> device what to do.
>
> As a bonus, anyone who enables this driver at all in their build will
> test the compilation of both code paths. And to me, that extra
> compilation testing trumps whatever arguments you may make for not
> making this support dynamic.
I was thinking more in terms of needing fewer kernels,
but yes build coverage is a big win.
^ permalink raw reply
* Re: [PATCH v2] ks8842: Do the TX timeout work in workqueue context.
From: David Miller @ 2010-07-09 6:07 UTC (permalink / raw)
To: richard.rojfors; +Cc: netdev
In-Reply-To: <1278655286.5481.4.camel@debian>
From: Richard Röjfors <richard.rojfors@pelagicore.com>
Date: Fri, 09 Jul 2010 08:01:26 +0200
> Currently all code that needs to be run at TX timeout is done in the
> calling context, where bottom halves are disabled. Some of the code
> blocks, so it needs to be done in a different context. This patch
> adds in a work struct which is scheduled at TX timeout. Then the
> timeout code is executed within work queue context.
>
> In the process an unnecessary bank change before resetting the
> controller was removed.
>
> Signed-off-by: Richard Röjfors <richard.rojfors@pelagicore.com>
If the bank change removal is unrelated to this change you should
do it in a seperate change.
This way it's easy for someone to find out if a regression is
caused by the TX workqueue bits, rather than this bank change
removal.
So, please submit this as a two patch sequence, one that does
the bank change line removal. And then a second that does
the TX workqueue bits.
Thanks.
^ permalink raw reply
* [PATCH] tproxy: the length of lines should be within 80
From: Changli Gao @ 2010-07-09 5:31 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, netfilter-devel, netdev, Changli Gao
tproxy: the length of lines should be within 80
According to the Documentation/CodingStyle, the length of lines should be
within 80.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/netfilter/xt_TPROXY.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/xt_TPROXY.c b/net/netfilter/xt_TPROXY.c
index e1a0ded..c61294d 100644
--- a/net/netfilter/xt_TPROXY.c
+++ b/net/netfilter/xt_TPROXY.c
@@ -37,8 +37,10 @@ tproxy_tg(struct sk_buff *skb, const struct xt_action_param *par)
return NF_DROP;
sk = nf_tproxy_get_sock_v4(dev_net(skb->dev), iph->protocol,
- iph->saddr, tgi->laddr ? tgi->laddr : iph->daddr,
- hp->source, tgi->lport ? tgi->lport : hp->dest,
+ iph->saddr,
+ tgi->laddr ? tgi->laddr : iph->daddr,
+ hp->source,
+ tgi->lport ? tgi->lport : hp->dest,
par->in, true);
/* NOTE: assign_sock consumes our sk reference */
^ permalink raw reply related
* Re: 2.6.35-rc4-git3: Reported regressions from 2.6.34
From: Eric Dumazet @ 2010-07-09 5:28 UTC (permalink / raw)
To: David Miller
Cc: torvalds, rjw, linux-kernel, akpm, netdev, kaber, jengelh,
casteyde.christian
In-Reply-To: <20100708.213420.112614033.davem@davemloft.net>
Le jeudi 08 juillet 2010 à 21:34 -0700, David Miller a écrit :
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Thu, 8 Jul 2010 18:34:25 -0700
>
> > On Thu, Jul 8, 2010 at 4:33 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >>
> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16187
> >> Subject : Carrier detection failed in dhcpcd when link is up
> >> Submitter : Christian Casteyde <casteyde.christian@free.fr>
> >> Date : 2010-06-12 15:15 (27 days old)
> >> First-Bad-Commit: http://git.kernel.org/linus/10708f37ae729baba9b67bd134c3720709d4ae62
> >> Handled-By : Andrew Morton <akpm@linux-foundation.org>
> >
> > David? This bisects to a networking commit. Doesn't look sensible, but
> > what do I know?
>
> My suspicion is that dhcpd uses netlink to dump the info of the
> available links, and due to some bug gets confused with the new 64-bit
> statistic netlink attribute being there now.
> a second to have a look at this.
It could be a dhcpcd bug because of extended size of answer
According to strace, dhcpcd tries a recvmsg() call with
a 256 bytes buffer to hold answer.
Looking at current dhcpcd source, I confirm it cannot realloc its buffer
static int
get_netlink(int fd, int flags,
int (*callback)(struct nlmsghdr *))
{
char *buffer = NULL;
ssize_t bytes;
struct nlmsghdr *nlm;
int r = -1;
buffer = xzalloc(sizeof(char) * BUFFERLEN);
for (;;) {
bytes = recv(fd, buffer, BUFFERLEN, flags);
if (bytes == -1) {
if (errno == EAGAIN) {
r = 0;
goto eexit;
}
if (errno == EINTR)
continue;
goto eexit;
}
This program needs to fix this.
^ permalink raw reply
* Re: [PATCH v4 1/9] atm: propagate signal changes via notifier
From: David Miller @ 2010-07-09 4:47 UTC (permalink / raw)
To: karl; +Cc: linux-atm-general, netdev, chas
In-Reply-To: <1278578095-25324-2-git-send-email-karl@hiramoto.org>
From: Karl Hiramoto <karl@hiramoto.org>
Date: Thu, 8 Jul 2010 10:34:47 +0200
> +
> +/*
> + * atm_dev_signal_change
> + *
> + * Propagate lower layer signal change in atm_dev->signal to netdevice.
> + * The event will be sent via a notifier call chain.
> + */
I said to format comments:
/* Like
* this.
*/
not:
/*
* Like
* this.
*/
Honestly, I don't know how I can be more clear about this :-)
^ permalink raw reply
* Re: [PATCH net-2.6] Phonet: fix skb leak in pipe endpoint accept()
From: David Miller @ 2010-07-09 4:45 UTC (permalink / raw)
To: remi.denis-courmont; +Cc: netdev
In-Reply-To: <1278572213-6239-1-git-send-email-remi.denis-courmont@nokia.com>
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Date: Thu, 8 Jul 2010 09:56:53 +0300
> From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] ks8842: Do the TX timeout work in workqueue context.
From: David Miller @ 2010-07-09 4:43 UTC (permalink / raw)
To: richard.rojfors; +Cc: netdev
In-Reply-To: <1278429625.32432.10.camel@debian>
From: Richard Röjfors <richard.rojfors@pelagicore.com>
Date: Tue, 06 Jul 2010 17:20:25 +0200
> Currently all code that needs to be run at TX timeout is done in the
> calling context, where bottom halves are disabled. Some of the code
> blocks, so it needs to be done in a different context. This patch
> adds in a work struct which is scheduled at TX timeout. Then the
> timeout code is executed within work queue context.
>
> Signed-off-by: Richard Röjfors <richard.rojfors@pelagicore.com>
Your patch is corrupted by your email client, and it does more than
you say it does in this commit message:
> static inline void ks8842_select_bank(struct ks8842_adapter *adapter,
> u16 bank)
> @@ -197,7 +199,6 @@ static void ks8842_reset(struct ks8842_adapter
> *adapter)
Your email client is wrapping long lines in the patch, corrupting it
and making it unusable. Please fix your email client to not molest
the patch in any way.
> msleep(10);
> iowrite16(0, adapter->hw_addr + REG_GRR);
> */
> - iowrite16(32, adapter->hw_addr + REG_SELECT_BANK);
> iowrite32(0x1, adapter->hw_addr + REG_TIMB_RST);
> msleep(20);
> }
Your commit message fails to describe what this REG_SELECT_BANK write
removal is needed for. It must be accounted for in your log message
otherwise other developers won't understand why this line gets
removed in your change.
Thanks.
^ permalink raw reply
* Re: [PATCH linux-2.6.35-rc3] ks8842 driver
From: David Miller @ 2010-07-09 4:41 UTC (permalink / raw)
To: David.Choi; +Cc: horms, netdev, Charles.Li
In-Reply-To: <C43529A246480145B0A6D0234BDB0F0D481D67@MELANITE.micrel.com>
From: "Choi, David" <David.Choi@Micrel.Com>
Date: Thu, 8 Jul 2010 12:01:51 -0700
> The original ks8842 driver is designed to work on the customized bus
> interface based on an FPGA. This patch is intended to address the more
> commonly used generic bus interface available on the majority of SoC in
> the market.
>
> It is unlikely that for a system to use both FPGA based and generic bus
> interface for ks8842, I am quite certain that those 2 devices are used
> mutual exclusively.
Like Simon, I'm not to thrilled with this approach.
Any flag bit test you'd need to add to the driver to handle both cases
will have zero performance impact since the cost of the MMIO accesses
will dominate such tests entirely.
Add a boolean flag bit to the driver software state, set it based upon
some platform_device private setting, and test it in these paths to
device what to do.
As a bonus, anyone who enables this driver at all in their build will
test the compilation of both code paths. And to me, that extra
compilation testing trumps whatever arguments you may make for not
making this support dynamic.
Thanks.
^ permalink raw reply
* Re: [RFC] gre: propagate ipv6 transport class
From: David Miller @ 2010-07-09 4:36 UTC (permalink / raw)
To: shemminger; +Cc: yoshfuji, herbert, netdev
In-Reply-To: <20100706105821.7b0e2538@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 6 Jul 2010 10:58:21 -0700
> This patch makes IPV6 over IPv4 GRE tunnel propagate the transport
> class field from the underlying IPV6 header to the IPV4 Type Of Service
> field. Without the patch, all IPV6 packets in tunnel look the same to QoS.
>
> This assumes that IPV6 transport class is exactly the same
> as IPv4 TOS. Not sure if that is always the case? Maybe need
> to mask off some bits.
>
> The mask and shift to get tclass is copied from ipv6/datagram.c
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Looks good, but we should use ipv6_get_dsfield() just like
ipgre_ecn_encapsulate() does.
Note that this also influences the route since this 'tos' feeds
into the flowi lookup key. We should make sure that this is OK
too.
Anyways, I've committed the following to net-next-2.6, thanks!
--------------------
gre: propagate ipv6 transport class
This patch makes IPV6 over IPv4 GRE tunnel propagate the transport
class field from the underlying IPV6 header to the IPV4 Type Of Service
field. Without the patch, all IPV6 packets in tunnel look the same to QoS.
This assumes that IPV6 transport class is exactly the same
as IPv4 TOS. Not sure if that is always the case? Maybe need
to mask off some bits.
The mask and shift to get tclass is copied from ipv6/datagram.c
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/ip_gre.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 749e548..945b20a 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -731,6 +731,8 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
tos = 0;
if (skb->protocol == htons(ETH_P_IP))
tos = old_iph->tos;
+ else if (skb->protocol == htons(ETH_P_IPV6))
+ tos = ipv6_get_dsfield((struct ipv6hdr *)old_iph);
}
{
--
1.7.1.1
^ permalink raw reply related
* Re: 2.6.35-rc4-git3: Reported regressions from 2.6.34
From: David Miller @ 2010-07-09 4:34 UTC (permalink / raw)
To: torvalds; +Cc: rjw, linux-kernel, akpm, netdev, kaber, jengelh
In-Reply-To: <AANLkTiknnzWyVpqnPCpyiEVHLgkewd0zaGzLInABRe2G@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu, 8 Jul 2010 18:34:25 -0700
> On Thu, Jul 8, 2010 at 4:33 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16187
>> Subject : Carrier detection failed in dhcpcd when link is up
>> Submitter : Christian Casteyde <casteyde.christian@free.fr>
>> Date : 2010-06-12 15:15 (27 days old)
>> First-Bad-Commit: http://git.kernel.org/linus/10708f37ae729baba9b67bd134c3720709d4ae62
>> Handled-By : Andrew Morton <akpm@linux-foundation.org>
>
> David? This bisects to a networking commit. Doesn't look sensible, but
> what do I know?
My suspicion is that dhcpd uses netlink to dump the info of the
available links, and due to some bug gets confused with the new 64-bit
statistic netlink attribute being there now.
That shouldn't happen, applications should just ignore the attributes
which they don't understand.
I'll try to find a second to have a look at this.
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] net: Get rid of rtnl_link_stats64 / net_device_stats union
From: Eric Dumazet @ 2010-07-09 4:25 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, linux-net-drivers
In-Reply-To: <1278631762.16013.307.camel@achroite.uk.solarflarecom.com>
Le vendredi 09 juillet 2010 à 00:29 +0100, Ben Hutchings a écrit :
> In commit be1f3c2c027cc5ad735df6a45a542ed1db7ec48b "net: Enable 64-bit
> net device statistics on 32-bit architectures" I redefined struct
> net_device_stats so that it could be used in a union with struct
> rtnl_link_stats64, avoiding the need for explicit copying or
> conversion between the two. However, this is unsafe because there is
> no locking required and no lock consistently held around calls to
> dev_get_stats() and use of the statistics structure it returns.
>
> In commit 28172739f0a276eb8d6ca917b3974c2edb036da3 "net: fix 64 bit
> counters on 32 bit arches" Eric Dumazet dealt with that problem by
> requiring callers of dev_get_stats() to provide storage for the
> result. This means that the net_device::stats64 field and the padding
> in struct net_device_stats are now redundant, so remove them.
>
> Update the comment on net_device_ops::ndo_get_stats64 to reflect its
> new usage.
>
> Change dev_txq_stats_fold() to use struct rtnl_link_stats64, since
> that is what all its callers are really using and it is no longer
> going to be compatible with struct net_device_stats.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> drivers/net/macvlan.c | 2 +-
> include/linux/netdevice.h | 70 ++++++++++++++++++---------------------------
> net/8021q/vlan_dev.c | 2 +-
> net/core/dev.c | 19 +++++++++---
> 4 files changed, 44 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> index 6112f14..1b28aae 100644
> --- a/drivers/net/macvlan.c
> +++ b/drivers/net/macvlan.c
> @@ -436,7 +436,7 @@ static struct rtnl_link_stats64 *macvlan_dev_get_stats64(struct net_device *dev,
> {
> struct macvlan_dev *vlan = netdev_priv(dev);
>
> - dev_txq_stats_fold(dev, (struct net_device_stats *)stats);
> + dev_txq_stats_fold(dev, stats);
>
> if (vlan->rx_stats) {
> struct macvlan_rx_stats *p, accum = {0};
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 8018f6b..17e95e3 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -162,42 +162,32 @@ static inline bool dev_xmit_complete(int rc)
> /*
> * Old network device statistics. Fields are native words
> * (unsigned long) so they can be read and written atomically.
> - * Each field is padded to 64 bits for compatibility with
> - * rtnl_link_stats64.
> */
>
> -#if BITS_PER_LONG == 64
> -#define NET_DEVICE_STATS_DEFINE(name) unsigned long name
> -#elif defined(__LITTLE_ENDIAN)
> -#define NET_DEVICE_STATS_DEFINE(name) unsigned long name, pad_ ## name
> -#else
> -#define NET_DEVICE_STATS_DEFINE(name) unsigned long pad_ ## name, name
> -#endif
> -
> struct net_device_stats {
> - NET_DEVICE_STATS_DEFINE(rx_packets);
> - NET_DEVICE_STATS_DEFINE(tx_packets);
> - NET_DEVICE_STATS_DEFINE(rx_bytes);
> - NET_DEVICE_STATS_DEFINE(tx_bytes);
> - NET_DEVICE_STATS_DEFINE(rx_errors);
> - NET_DEVICE_STATS_DEFINE(tx_errors);
> - NET_DEVICE_STATS_DEFINE(rx_dropped);
> - NET_DEVICE_STATS_DEFINE(tx_dropped);
> - NET_DEVICE_STATS_DEFINE(multicast);
> - NET_DEVICE_STATS_DEFINE(collisions);
> - NET_DEVICE_STATS_DEFINE(rx_length_errors);
> - NET_DEVICE_STATS_DEFINE(rx_over_errors);
> - NET_DEVICE_STATS_DEFINE(rx_crc_errors);
> - NET_DEVICE_STATS_DEFINE(rx_frame_errors);
> - NET_DEVICE_STATS_DEFINE(rx_fifo_errors);
> - NET_DEVICE_STATS_DEFINE(rx_missed_errors);
> - NET_DEVICE_STATS_DEFINE(tx_aborted_errors);
> - NET_DEVICE_STATS_DEFINE(tx_carrier_errors);
> - NET_DEVICE_STATS_DEFINE(tx_fifo_errors);
> - NET_DEVICE_STATS_DEFINE(tx_heartbeat_errors);
> - NET_DEVICE_STATS_DEFINE(tx_window_errors);
> - NET_DEVICE_STATS_DEFINE(rx_compressed);
> - NET_DEVICE_STATS_DEFINE(tx_compressed);
> + unsigned long rx_packets;
> + unsigned long tx_packets;
> + unsigned long rx_bytes;
> + unsigned long tx_bytes;
> + unsigned long rx_errors;
> + unsigned long tx_errors;
> + unsigned long rx_dropped;
> + unsigned long tx_dropped;
> + unsigned long multicast;
> + unsigned long collisions;
> + unsigned long rx_length_errors;
> + unsigned long rx_over_errors;
> + unsigned long rx_crc_errors;
> + unsigned long rx_frame_errors;
> + unsigned long rx_fifo_errors;
> + unsigned long rx_missed_errors;
> + unsigned long tx_aborted_errors;
> + unsigned long tx_carrier_errors;
> + unsigned long tx_fifo_errors;
> + unsigned long tx_heartbeat_errors;
> + unsigned long tx_window_errors;
> + unsigned long rx_compressed;
> + unsigned long tx_compressed;
> };
>
> #endif /* __KERNEL__ */
> @@ -666,14 +656,13 @@ struct netdev_rx_queue {
> * Callback uses when the transmitter has not made any progress
> * for dev->watchdog ticks.
> *
> - * struct rtnl_link_stats64* (*ndo_get_stats64)(struct net_device *dev
> + * struct rtnl_link_stats64* (*ndo_get_stats64)(struct net_device *dev,
> * struct rtnl_link_stats64 *storage);
> * struct net_device_stats* (*ndo_get_stats)(struct net_device *dev);
> * Called when a user wants to get the network device usage
> * statistics. Drivers must do one of the following:
> - * 1. Define @ndo_get_stats64 to update a rtnl_link_stats64 structure
> - * (which should normally be dev->stats64) and return a ponter to
> - * it. The structure must not be changed asynchronously.
> + * 1. Define @ndo_get_stats64 to fill in a zero-initialised
> + * rtnl_link_stats64 structure passed by the caller.
> * 2. Define @ndo_get_stats to update a net_device_stats structure
> * (which should normally be dev->stats) and return a pointer to
> * it. The structure may be changed asynchronously only if each
> @@ -888,10 +877,7 @@ struct net_device {
> int ifindex;
> int iflink;
>
> - union {
> - struct rtnl_link_stats64 stats64;
> - struct net_device_stats stats;
> - };
> + struct net_device_stats stats;
>
> #ifdef CONFIG_WIRELESS_EXT
> /* List of functions to handle Wireless Extensions (instead of ioctl).
> @@ -2147,7 +2133,7 @@ extern void dev_mcast_init(void);
> extern const struct rtnl_link_stats64 *dev_get_stats(struct net_device *dev,
> struct rtnl_link_stats64 *storage);
> extern void dev_txq_stats_fold(const struct net_device *dev,
> - struct net_device_stats *stats);
> + struct rtnl_link_stats64 *stats);
>
> extern int netdev_max_backlog;
> extern int netdev_tstamp_prequeue;
> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
> index 7865a4c..e66c9bf 100644
> --- a/net/8021q/vlan_dev.c
> +++ b/net/8021q/vlan_dev.c
> @@ -805,7 +805,7 @@ static u32 vlan_ethtool_get_flags(struct net_device *dev)
>
> static struct rtnl_link_stats64 *vlan_dev_get_stats64(struct net_device *dev, struct rtnl_link_stats64 *stats)
> {
> - dev_txq_stats_fold(dev, (struct net_device_stats *)stats);
> + dev_txq_stats_fold(dev, stats);
>
> if (vlan_dev_info(dev)->vlan_rx_stats) {
> struct vlan_rx_stats *p, accum = {0};
> diff --git a/net/core/dev.c b/net/core/dev.c
> index eb4201c..5ec2eec 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5274,10 +5274,10 @@ void netdev_run_todo(void)
> /**
> * dev_txq_stats_fold - fold tx_queues stats
> * @dev: device to get statistics from
> - * @stats: struct net_device_stats to hold results
> + * @stats: struct rtnl_link_stats64 to hold results
> */
> void dev_txq_stats_fold(const struct net_device *dev,
> - struct net_device_stats *stats)
> + struct rtnl_link_stats64 *stats)
> {
> unsigned long tx_bytes = 0, tx_packets = 0, tx_dropped = 0;
> unsigned int i;
> @@ -5311,17 +5311,26 @@ const struct rtnl_link_stats64 *dev_get_stats(struct net_device *dev,
> struct rtnl_link_stats64 *storage)
> {
> const struct net_device_ops *ops = dev->netdev_ops;
> + size_t i, n = sizeof(*storage) / sizeof(u64);
> + u64 *stats64 = (u64 *)storage;
> + const unsigned long *stats;
>
> if (ops->ndo_get_stats64) {
> memset(storage, 0, sizeof(*storage));
> return ops->ndo_get_stats64(dev, storage);
> }
> +
> if (ops->ndo_get_stats) {
> - memcpy(storage, ops->ndo_get_stats(dev), sizeof(*storage));
> + stats = (const unsigned long *)ops->ndo_get_stats(dev);
> + for (i = 0; i < n; i++)
> + stats64[i] = stats[i];
This could be a small helper function, to hide the sizeof(*storage) /
sizeof(u64) magic..
static void stats_to_stats64(struct rtnl_link_stats64 *dst,
const net_device_stats *src)
{
#if BITS_PER_LONG == 64
BUILD_BUG_ON(sizeof(*dst) != sizeof(*src));
memcpy(dst, src, sizeof(*src));
#else
size_t i, n = sizeof(*dst) / sizeof(u64);
u64 *stats64 = (u64 *)dst;
const unsigned long *stats = (const unsigned long *)src;
BUILD_BUG_ON(sizeof(*src) != n * sizeof(unsigned long));
for (i = 0; i < n, i++)
stats64[i] = stats[i];
#endif
}
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