* Re: [PATCH 1/7] drivers/net/irda/irtty-sir.c: Return -ENOMEM on memory allocation failure
From: Samuel Ortiz @ 2010-10-15 13:48 UTC (permalink / raw)
To: Julia Lawall; +Cc: kernel-janitors, netdev, linux-kernel
In-Reply-To: <1287147610-8041-1-git-send-email-julia@diku.dk>
Hi Julia,
On Fri, 2010-10-15 at 15:00 +0200, Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> In this code, 0 is returned on memory allocation failure, even though other
> failures return -ENOMEM or other similar values.
>
> The initial value of ret as 0 is never used, so drop the initialization.
Thanks, patch applied to my irda-2.6 tree.
Cheers,
Samuel.
^ permalink raw reply
* Re: [PATCH] connector: remove lazy workqueue creation
From: Evgeniy Polyakov @ 2010-10-15 13:49 UTC (permalink / raw)
To: Tejun Heo; +Cc: netdev@vger.kernel.org, Frederic Weisbecker, David S. Miller
In-Reply-To: <4CB85945.8040801@kernel.org>
On Fri, Oct 15, 2010 at 03:38:13PM +0200, Tejun Heo (tj@kernel.org) wrote:
> Are you gonna route this patch? If not, I can route it through
> workqueue tree.
If it does not depend on other work, I believe Dave will pull into
network tree.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH] connector: remove lazy workqueue creation
From: Tejun Heo @ 2010-10-15 13:50 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: netdev@vger.kernel.org, Frederic Weisbecker, David S. Miller
In-Reply-To: <20101015134942.GA4422@ioremap.net>
On 10/15/2010 03:49 PM, Evgeniy Polyakov wrote:
> On Fri, Oct 15, 2010 at 03:38:13PM +0200, Tejun Heo (tj@kernel.org) wrote:
>> Are you gonna route this patch? If not, I can route it through
>> workqueue tree.
>
> If it does not depend on other work, I believe Dave will pull into
> network tree.
Nope, there's no dependency, so network tree then.
Thank you.
--
tejun
^ permalink raw reply
* Re: [PATCH 1/6] r8169: check dma mapping failures
From: Stanislaw Gruszka @ 2010-10-15 14:11 UTC (permalink / raw)
To: Francois Romieu, Eric Dumazet, David S. Miller; +Cc: netdev, Denis Kirjanov
In-Reply-To: <20101015134158.GA4417@electric-eye.fr.zoreil.com>
On Fri, Oct 15, 2010 at 03:41:58PM +0200, Francois Romieu wrote:
> Stanislaw Gruszka <sgruszka@redhat.com> :
> > Check possible dma mapping errors and do clean up if it happens,
> > when sending frames stop the tx queue.
>
> Almost ok: NETDEV_TX_BUSY can not be used like that. Afaik the DMA
> failure path in the driver really wants a NETDEV_TX_OK (and a device
> stats update, though missing in tg3 ?).
I'm not sure if any driver handle that in the right way. Returning
"TX OK" when the transmission was not "OK", doesn't look correctly
to me.
Eric, David, what you think?
> Actually the former NETDEV_TX_BUSY condition mostly checks for a bug.
Driver handling code from net/core/*.c does not give me such impression.
Stanislaw
^ permalink raw reply
* Re: [PATCH net-next 4/8] tg3: Add EEE support
From: Ben Hutchings @ 2010-10-15 14:17 UTC (permalink / raw)
To: Matt Carlson; +Cc: davem, netdev, andy
In-Reply-To: <1287088665-22135-5-git-send-email-mcarlson@broadcom.com>
On Thu, 2010-10-14 at 13:37 -0700, Matt Carlson wrote:
> This patch adds Energy Efficient Ethernet (EEE) support for the 5718
> device ID and the 57765 B0 asic revision.
[...]
> +/* Clause 45 expansion registers */
> +#define TG3_CL45_D7_EEEADV_CAP 0x003c
> +#define TG3_CL45_D7_EEEADV_CAP_100TX 0x0002
> +#define TG3_CL45_D7_EEEADV_CAP_1000T 0x0004
I assume this is going to be a standard register, so I think it should
be defined in <linux/mdio.h>.
> +#define TG3_CL45_D7_EEERES_STAT 0x803e
> +#define TG3_CL45_D7_EEERES_STAT_LP_100TX 0x0002
> +#define TG3_CL45_D7_EEERES_STAT_LP_1000T 0x0004
0x803e not 0x003e?
Also Dave suggested there should be an ethtool interface to control EEE
<http://thread.gmane.org/gmane.linux.network/164141/focus=165143>.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next] net: allocate skbs on local node
From: Christoph Lameter @ 2010-10-15 14:23 UTC (permalink / raw)
To: David Rientjes
Cc: Pekka Enberg, Andrew Morton, Eric Dumazet, David Miller, netdev,
Michael Chan, Eilon Greenstein, Christoph Hellwig, LKML,
Nick Piggin
In-Reply-To: <alpine.DEB.2.00.1010131539440.27839@chino.kir.corp.google.com>
On Wed, 13 Oct 2010, David Rientjes wrote:
> On Wed, 13 Oct 2010, Christoph Lameter wrote:
>
> > > I was going to mention that as an idea, but I thought storing the metadata
> > > for certain debugging features might differ from the two allocators so
> > > substantially that it would be even more convoluted and difficult to
> > > maintain?
> >
> > We could have some callbacks to store allocator specific metadata?
> >
>
> It depends on whether we could share the same base for both slab (unified
> allocator) and slub, which you snipped from your reply, that would make
> this cleaner.
I already said before that we should consider having a common base so I
thought that was not necessary.
^ permalink raw reply
* Re: [PATCH] sctp: implement SIOCINQ ioctl() (take 3 bis)
From: Diego Elio Pettenò @ 2010-10-15 14:22 UTC (permalink / raw)
To: netdev; +Cc: linux-sctp
In-Reply-To: <1285926965-5130-1-git-send-email-flameeyes@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 594 bytes --]
Il giorno ven, 01/10/2010 alle 11.56 +0200, Diego Elio Pettenò ha
scritto:
>
>
> This simple patch copies the current approach for SIOCINQ ioctl() from
> DCCP
> into SCTP so that the userland code working with SCTP can use a
> similar
> interface across different protocols to know how much space to
> allocate for
> a buffer.
Any news on getting this one in? Pretty please? :)
--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/
If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* netlink versus pid namespaces
From: Andi Kleen @ 2010-10-15 14:23 UTC (permalink / raw)
To: netdev, xemul, kuznet, virtualization
Hi,
I have been trying to figure out how pid namespaces interact
with netlink.
netlink uses pids (or really tids I hope?) to address sockets
associated with processes.
The netlink code passes around pids without caring much about
the pid namespace. It does pass around some information about the
network namespace, but that doesn't help here because the pid
namespace is not necessarily related to the net namespace.
When the netlink consumer runs in kernel (like rtnetlink) and
happens to run in the same process context while receiving
and processing the data it should do the right thing because
it has the same pid namespace.
If it runs in some other process that is not guaranteed and
it may actually send the reply back to the wrong pid.
When a process receives netlink in user space and it isn't
in the same pid space as the sender it is unlikely that
the reply gets back.
Anything I'm missing here?
Does netlink need to be extended?
Or perhaps forbid passing netlink between name spaces?
Thanks,
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH 1/6] r8169: check dma mapping failures
From: Denis Kirjanov @ 2010-10-15 14:23 UTC (permalink / raw)
To: Francois Romieu; +Cc: Stanislaw Gruszka, netdev, David S. Miller
In-Reply-To: <20101015134158.GA4417@electric-eye.fr.zoreil.com>
Right, we should pass TX_BUSY to upper layers only when the device hw
queue is full
On Fri, Oct 15, 2010 at 5:41 PM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> Stanislaw Gruszka <sgruszka@redhat.com> :
>> Check possible dma mapping errors and do clean up if it happens,
>> when sending frames stop the tx queue.
>
> Almost ok: NETDEV_TX_BUSY can not be used like that. Afaik the DMA
> failure path in the driver really wants a NETDEV_TX_OK (and a device
> stats update, though missing in tg3 ?).
>
> Actually the former NETDEV_TX_BUSY condition mostly checks for a bug.
>
> --
> Ueimor
>
--
Regards,
Denis
^ permalink raw reply
* Re: [PATCH 6/6] r8169: print errors when dma mapping fail
From: Francois Romieu @ 2010-10-15 14:52 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: netdev, Denis Kirjanov
In-Reply-To: <1287144922-3297-6-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> :
> Print errors because dma mapping failures can cause device to stop
> working and will need user intervention to recover.
I am hesitating (overengineered ? bloaty ? not the right place ?).
The Tx stats are kept up-to-date : Tx failure will go along a Tx drop
stat increase.
Regarding a mapping failure in the Rx path, either it will behave as
an allocation failure at open / resume time - and I have no idea how
the user will recover - or it will happen during a Rx ring refill.
...
Ok, something could have gone unnoticed. Let's try it.
--
Ueimor
^ permalink raw reply
* [PATCH] net/nuc900: change dev_warn to dev_dbg when link down occurs
From: Wan ZongShun @ 2010-10-15 15:00 UTC (permalink / raw)
To: netdev, yachen, David S. Miller, linux-kernel
Hi David,
When I didnot connect the net cable, the warning infos are always showed,
so I change the dev_warn to dev_dbg.
Signed-off-by: Wan ZongShun <mcuos.com@gmail.com>
---
drivers/net/arm/w90p910_ether.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/arm/w90p910_ether.c b/drivers/net/arm/w90p910_ether.c
index 4545d5a..98f8ada 100644
--- a/drivers/net/arm/w90p910_ether.c
+++ b/drivers/net/arm/w90p910_ether.c
@@ -213,7 +213,7 @@ static void update_linkspeed(struct net_device *dev)
if (!mii_link_ok(ðer->mii)) {
ether->linkflag = 0x0;
netif_carrier_off(dev);
- dev_warn(&pdev->dev, "%s: Link down.\n", dev->name);
+ dev_dbg(&pdev->dev, "%s: Link down.\n", dev->name);
return;
}
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] secmark: do not return early if there was no error
From: Patrick McHardy @ 2010-10-15 15:08 UTC (permalink / raw)
To: Eric Paris
Cc: netfilter-devel, netfilter, coreteam, netdev, davem, jengelh,
paul.moore, jmorris
In-Reply-To: <20101013202105.15011.60553.stgit@paris.rdu.redhat.com>
Am 13.10.2010 22:21, schrieb Eric Paris:
> Commit 4a5a5c73 attempted to pass decent error messages back to userspace for
> netfilter errors. In xt_SECMARK.c however the patch screwed up and returned
> on 0 (aka no error) early and didn't finish setting up secmark. This results
> in a kernel BUG if you use SECMARK.
>
> ------------[ cut here ]------------
> kernel BUG at net/netfilter/xt_SECMARK.c:38!
> invalid opcode: 0000 [#1] SMP
> last sysfs file: /sys/devices/system/cpu/cpu2/cache/index2/shared_cpu_map
> CPU 0
> Modules linked in: xt_SECMARK iptable_mangle nfs lockd fscache nfs_acl
> auth_rpcgss sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables
> uinput virtio_net virtio_balloon i2c_piix4 i2c_core joydev microcode ipv6
> virtio_blk virtio_pci virtio_ring virtio [last unloaded: speedstep_lib]
>
> ...
> RIP [<ffffffffa022117d>] secmark_tg+0x17/0x2e [xt_SECMARK]
> RSP <ffff880003e03a40>
> ---[ end trace 9aa5d06a71143e74 ]---
>
> Signed-off-by: Eric Paris <eparis@redhat.com>
> Acked-by: Paul Moore <paul.moore@hp.com>
> Acked-by: James Morris <jmorris@namei.org>
Acked-by: Patrick McHardy <kaber@trash.net>
I'll leave it up to Dave whether this can still go into 2.6.36.
^ permalink raw reply
* [PATCH net-next] bonding: make release_and_destroy static
From: Stephen Hemminger @ 2010-10-15 15:09 UTC (permalink / raw)
To: Jay Vosburgh, David Miller; +Cc: bonding-devel, netdev
Only used in main file.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/bonding/bond_main.c 2010-10-15 08:07:14.163898236 -0700
+++ b/drivers/net/bonding/bond_main.c 2010-10-15 08:07:31.956373660 -0700
@@ -2057,8 +2057,8 @@ int bond_release(struct net_device *bond
* First release a slave and than destroy the bond if no more slaves are left.
* Must be under rtnl_lock when this function is called.
*/
-int bond_release_and_destroy(struct net_device *bond_dev,
- struct net_device *slave_dev)
+static int bond_release_and_destroy(struct net_device *bond_dev,
+ struct net_device *slave_dev)
{
struct bonding *bond = netdev_priv(bond_dev);
int ret;
--- a/drivers/net/bonding/bonding.h 2010-10-15 08:07:14.179898632 -0700
+++ b/drivers/net/bonding/bonding.h 2010-10-15 08:07:31.956373660 -0700
@@ -334,7 +334,6 @@ static inline void bond_unset_master_alb
struct vlan_entry *bond_next_vlan(struct bonding *bond, struct vlan_entry *curr);
int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev);
int bond_create(struct net *net, const char *name);
-int bond_release_and_destroy(struct net_device *bond_dev, struct net_device *slave_dev);
int bond_create_sysfs(void);
void bond_destroy_sysfs(void);
void bond_prepare_sysfs_group(struct bonding *bond);
^ permalink raw reply
* [PATCH net-next] rtnetlink: remove rtnl_kill_links
From: Stephen Hemminger @ 2010-10-15 15:12 UTC (permalink / raw)
To: David Miller; +Cc: netdev
The function rtnl_kill_links is defined but never used.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/include/net/rtnetlink.h 2010-10-02 15:28:38.350854857 +0900
+++ b/include/net/rtnetlink.h 2010-10-02 15:29:42.650840398 +0900
@@ -79,7 +79,6 @@ struct rtnl_link_ops {
extern int __rtnl_link_register(struct rtnl_link_ops *ops);
extern void __rtnl_link_unregister(struct rtnl_link_ops *ops);
-extern void rtnl_kill_links(struct net *net, struct rtnl_link_ops *ops);
extern int rtnl_link_register(struct rtnl_link_ops *ops);
extern void rtnl_link_unregister(struct rtnl_link_ops *ops);
--- a/net/core/rtnetlink.c 2010-10-02 15:28:38.370839030 +0900
+++ b/net/core/rtnetlink.c 2010-10-02 15:29:42.660839574 +0900
@@ -299,14 +299,6 @@ static void __rtnl_kill_links(struct net
unregister_netdevice_many(&list_kill);
}
-void rtnl_kill_links(struct net *net, struct rtnl_link_ops *ops)
-{
- rtnl_lock();
- __rtnl_kill_links(net, ops);
- rtnl_unlock();
-}
-EXPORT_SYMBOL_GPL(rtnl_kill_links);
-
/**
* __rtnl_link_unregister - Unregister rtnl_link_ops from rtnetlink.
* @ops: struct rtnl_link_ops * to unregister
^ permalink raw reply
* [PATCH net-next] xfrm: make xfrm_bundle_ok local
From: Stephen Hemminger @ 2010-10-15 15:14 UTC (permalink / raw)
To: Herbert Xu, David Miller; +Cc: netdev
Only used in one place.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/include/net/xfrm.h 2010-10-05 23:27:43.971148720 +0900
+++ b/include/net/xfrm.h 2010-10-05 23:27:54.631127801 +0900
@@ -1466,8 +1466,6 @@ struct xfrm_state *xfrm_find_acq(struct
xfrm_address_t *saddr, int create,
unsigned short family);
extern int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol);
-extern int xfrm_bundle_ok(struct xfrm_policy *pol, struct xfrm_dst *xdst,
- struct flowi *fl, int family, int strict);
#ifdef CONFIG_XFRM_MIGRATE
extern int km_migrate(struct xfrm_selector *sel, u8 dir, u8 type,
--- a/net/xfrm/xfrm_policy.c 2010-10-05 23:27:43.995125930 +0900
+++ b/net/xfrm/xfrm_policy.c 2010-10-05 23:28:27.244135115 +0900
@@ -50,6 +50,9 @@ static struct xfrm_policy_afinfo *xfrm_p
static void xfrm_policy_put_afinfo(struct xfrm_policy_afinfo *afinfo);
static void xfrm_init_pmtu(struct dst_entry *dst);
static int stale_bundle(struct dst_entry *dst);
+static int xfrm_bundle_ok(struct xfrm_policy *pol, struct xfrm_dst *xdst,
+ struct flowi *fl, int family, int strict);
+
static struct xfrm_policy *__xfrm_policy_unlink(struct xfrm_policy *pol,
int dir);
@@ -2276,7 +2279,7 @@ static void xfrm_init_pmtu(struct dst_en
* still valid.
*/
-int xfrm_bundle_ok(struct xfrm_policy *pol, struct xfrm_dst *first,
+static int xfrm_bundle_ok(struct xfrm_policy *pol, struct xfrm_dst *first,
struct flowi *fl, int family, int strict)
{
struct dst_entry *dst = &first->u.dst;
@@ -2358,8 +2361,6 @@ int xfrm_bundle_ok(struct xfrm_policy *p
return 1;
}
-EXPORT_SYMBOL(xfrm_bundle_ok);
-
int xfrm_policy_register_afinfo(struct xfrm_policy_afinfo *afinfo)
{
struct net *net;
^ permalink raw reply
* [PATCH net-next] xfrm6: make xfrm6_tunnel_free_spi local
From: Stephen Hemminger @ 2010-10-15 15:15 UTC (permalink / raw)
To: David Miller, Herbert Xu, YOSHIFUJI Hideaki; +Cc: netdev
Function only defined and used in one file.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/include/net/xfrm.h 2010-10-05 23:33:55.959118983 +0900
+++ b/include/net/xfrm.h 2010-10-05 23:34:05.079117188 +0900
@@ -1419,7 +1419,6 @@ extern int xfrm6_input_addr(struct sk_bu
extern int xfrm6_tunnel_register(struct xfrm6_tunnel *handler, unsigned short family);
extern int xfrm6_tunnel_deregister(struct xfrm6_tunnel *handler, unsigned short family);
extern __be32 xfrm6_tunnel_alloc_spi(struct net *net, xfrm_address_t *saddr);
-extern void xfrm6_tunnel_free_spi(struct net *net, xfrm_address_t *saddr);
extern __be32 xfrm6_tunnel_spi_lookup(struct net *net, xfrm_address_t *saddr);
extern int xfrm6_extract_output(struct xfrm_state *x, struct sk_buff *skb);
extern int xfrm6_prepare_output(struct xfrm_state *x, struct sk_buff *skb);
--- a/net/ipv6/xfrm6_tunnel.c 2010-10-05 23:33:56.039118393 +0900
+++ b/net/ipv6/xfrm6_tunnel.c 2010-10-05 23:34:21.011117560 +0900
@@ -199,7 +199,7 @@ static void x6spi_destroy_rcu(struct rcu
container_of(head, struct xfrm6_tunnel_spi, rcu_head));
}
-void xfrm6_tunnel_free_spi(struct net *net, xfrm_address_t *saddr)
+static void xfrm6_tunnel_free_spi(struct net *net, xfrm_address_t *saddr)
{
struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net);
struct xfrm6_tunnel_spi *x6spi;
@@ -223,8 +223,6 @@ void xfrm6_tunnel_free_spi(struct net *n
spin_unlock_bh(&xfrm6_tunnel_spi_lock);
}
-EXPORT_SYMBOL(xfrm6_tunnel_free_spi);
-
static int xfrm6_tunnel_output(struct xfrm_state *x, struct sk_buff *skb)
{
skb_push(skb, -skb_network_offset(skb));
^ permalink raw reply
* Re: netlink versus pid namespaces
From: Alexey Kuznetsov @ 2010-10-15 15:19 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev, xemul, virtualization
In-Reply-To: <20101015142357.GA29321@basil.fritz.box>
Hello!
> netlink uses pids (or really tids I hope?) to address sockets
> associated with processes.
Not really. It uses port number which is called "pid" occasionally. Bad name.
Autobind function simply selects tgid of calling process as the first guess.
Actually sockets are addressed by pair (net namespace, port) and
communication is possible only inside net namespace. So, communication
between namespaces is already prohibited.
pid namespaces do not participate in the picture at all.
Alexey
^ permalink raw reply
* Re: netlink versus pid namespaces
From: Andi Kleen @ 2010-10-15 15:23 UTC (permalink / raw)
To: Alexey Kuznetsov; +Cc: Andi Kleen, netdev, xemul, virtualization
In-Reply-To: <20101015151903.GA3487@ms2.inr.ac.ru>
On Fri, Oct 15, 2010 at 07:19:03PM +0400, Alexey Kuznetsov wrote:
> Hello!
>
> > netlink uses pids (or really tids I hope?) to address sockets
> > associated with processes.
>
> Not really. It uses port number which is called "pid" occasionally. Bad name.
> Autobind function simply selects tgid of calling process as the first guess.
Thanks for the clarification, Alexey. I guess I should have read more
code :/
-Andi
^ permalink raw reply
* Re: [PATCH net-next] bonding: make release_and_destroy static
From: Andy Gospodarek @ 2010-10-15 15:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jay Vosburgh, David Miller, bonding-devel, netdev
In-Reply-To: <20101015080934.6dc28388@nehalam>
On Fri, Oct 15, 2010 at 08:09:34AM -0700, Stephen Hemminger wrote:
> Only used in main file.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> --- a/drivers/net/bonding/bond_main.c 2010-10-15 08:07:14.163898236 -0700
> +++ b/drivers/net/bonding/bond_main.c 2010-10-15 08:07:31.956373660 -0700
> @@ -2057,8 +2057,8 @@ int bond_release(struct net_device *bond
> * First release a slave and than destroy the bond if no more slaves are left.
> * Must be under rtnl_lock when this function is called.
> */
> -int bond_release_and_destroy(struct net_device *bond_dev,
> - struct net_device *slave_dev)
> +static int bond_release_and_destroy(struct net_device *bond_dev,
> + struct net_device *slave_dev)
> {
> struct bonding *bond = netdev_priv(bond_dev);
> int ret;
> --- a/drivers/net/bonding/bonding.h 2010-10-15 08:07:14.179898632 -0700
> +++ b/drivers/net/bonding/bonding.h 2010-10-15 08:07:31.956373660 -0700
> @@ -334,7 +334,6 @@ static inline void bond_unset_master_alb
> struct vlan_entry *bond_next_vlan(struct bonding *bond, struct vlan_entry *curr);
> int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev);
> int bond_create(struct net *net, const char *name);
> -int bond_release_and_destroy(struct net_device *bond_dev, struct net_device *slave_dev);
> int bond_create_sysfs(void);
> void bond_destroy_sysfs(void);
> void bond_prepare_sysfs_group(struct bonding *bond);
Seems fine.
Acked-by: Andy Gospodarek <andy@greyhouse.net>
^ permalink raw reply
* [PATCH V2 net-next] can-raw: add msg_flags to distinguish local traffic
From: Kurt Van Dijck @ 2010-10-15 15:38 UTC (permalink / raw)
To: netdev, socketcan-core-0fE9KPoRgkgATYTw5x5z8w; +Cc: Oliver Hartkopp
differences in V2:
1) use 'unsigned int' for flags, conform to the msg_flags
in the kernel headers (glibc uses 'int')
2) fixed typo in comments
3) Add description in Documentation
4) correct email address in Signed-off-by
CAN has no addressing scheme. It is currently impossible
for userspace to tell is a received CAN frame comes from
another process on the local host, or from a remote CAN
device.
This patch add support for userspace applications to distinguish
between 'own', 'local' and 'remote' CAN traffic.
Distinction is made by returning flags in msg->msg_flags
in the call to recvmsg.
The Documentation/... explains the flags.
Signed-off-by: Kurt Van Dijck <kurt.van.dijck-/BeEPy95v10@public.gmane.org>
---
Documentation/networking/can.txt | 11 +++++++++++
net/can/raw.c | 33 ++++++++++++++++++++++++++++++---
2 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
index cd79735..95341aa 100644
--- a/Documentation/networking/can.txt
+++ b/Documentation/networking/can.txt
@@ -22,6 +22,7 @@ This file contains
4.1.2 RAW socket option CAN_RAW_ERR_FILTER
4.1.3 RAW socket option CAN_RAW_LOOPBACK
4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
+ 4.1.5 RAW socket returned flags
4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
4.3 connected transport protocols (SOCK_SEQPACKET)
4.4 unconnected transport protocols (SOCK_DGRAM)
@@ -471,6 +472,16 @@ solution for a couple of reasons:
setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS,
&recv_own_msgs, sizeof(recv_own_msgs));
+ 4.1.5 RAW socket returned flags
+
+ When using recvmsg() call, the msg->msg_flags may contain following flags:
+
+ MSG_DONTROUTE: set when the frame was sent via the same physical device,
+ ie. a loopback frame.
+ MSG_CONFIRM: set when the frame was sent via the socket it is received on.
+ This flag acts as a 'transmission confirmation'.
+ In order to receive such messages, CAN_RAW_RECV_OWN_MSGS must be set.
+
4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
4.3 connected transport protocols (SOCK_SEQPACKET)
4.4 unconnected transport protocols (SOCK_DGRAM)
diff --git a/net/can/raw.c b/net/can/raw.c
index 7d77e67..9020c4f 100644
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -90,23 +90,39 @@ struct raw_sock {
can_err_mask_t err_mask;
};
+/*
+ * return some space to store extra msg flags in.
+ * We use 1 int beyond the 'struct sockaddr_can' in skb->cb
+ * to store those.
+ * These flags will be use in raw_recvmsg()
+ */
+static inline unsigned int *raw_flags(struct sk_buff *skb)
+{
+ BUILD_BUG_ON(sizeof(skb->cb) <= (sizeof(struct sockaddr_can)
+ + sizeof(unsigned int)));
+ /* return pointer after struct sockaddr_can */
+ return (unsigned int *)(&((struct sockaddr_can *)skb->cb)[1]);
+}
+
static inline struct raw_sock *raw_sk(const struct sock *sk)
{
return (struct raw_sock *)sk;
}
-static void raw_rcv(struct sk_buff *skb, void *data)
+static void raw_rcv(struct sk_buff *oskb, void *data)
{
struct sock *sk = (struct sock *)data;
struct raw_sock *ro = raw_sk(sk);
struct sockaddr_can *addr;
+ struct sk_buff *skb;
+ unsigned int *pflags;
/* check the received tx sock reference */
- if (!ro->recv_own_msgs && skb->sk == sk)
+ if (!ro->recv_own_msgs && oskb->sk == sk)
return;
/* clone the given skb to be able to enqueue it into the rcv queue */
- skb = skb_clone(skb, GFP_ATOMIC);
+ skb = skb_clone(oskb, GFP_ATOMIC);
if (!skb)
return;
@@ -123,6 +139,14 @@ static void raw_rcv(struct sk_buff *skb, void *data)
addr->can_family = AF_CAN;
addr->can_ifindex = skb->dev->ifindex;
+ /* prepare the flags for raw_recvmsg() */
+ pflags = raw_flags(skb);
+ *pflags = 0;
+ if (oskb->sk)
+ *pflags |= MSG_DONTROUTE;
+ if (oskb->sk == sk)
+ *pflags |= MSG_CONFIRM;
+
if (sock_queue_rcv_skb(sk, skb) < 0)
kfree_skb(skb);
}
@@ -707,6 +731,9 @@ static int raw_recvmsg(struct kiocb *iocb, struct socket *sock,
memcpy(msg->msg_name, skb->cb, msg->msg_namelen);
}
+ /* assign the flags that have been recorded in raw_rcv() */
+ msg->msg_flags |= *(raw_flags(skb));
+
skb_free_datagram(sk, skb);
return size;
^ permalink raw reply related
* [PATCH net-next] net: avoid RCU for NOCACHE dst
From: Eric Dumazet @ 2010-10-15 15:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev
There is no point using RCU for dst we allocate for a very short time
(used once).
Change dst_release() to take DST_NOCACHE into account, but also change
skb_dst_set_noref() to force a refcount increment for such dst.
This is a _huge_ gain, because we dont waste memory to store xx thousand
of dsts. Instead of queueing them to RCU, we can free them instantly.
CPU caches can stay hot, re-using same memory blocks to hold temporary
dsts.
Note : remove unneeded smp_mb__before_atomic_dec(); in dst_release(),
since atomic_dec_return() implies a full memory barrier.
Stress test, 160.000.000 udp frames sent, IP route cache disabled
(DDOS).
Before:
real 0m38.091s
user 0m13.189s
sys 7m53.018s
After:
real 0m29.946s
user 0m12.157s
sys 7m40.605s
For reference, if IP route cache was enabled :
real 0m32.030s
user 0m10.521s
sys 8m15.243s
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/linux/skbuff.h | 14 +-------------
net/core/dst.c | 29 ++++++++++++++++++++++++++++-
net/ipv4/route.c | 9 ++++-----
3 files changed, 33 insertions(+), 19 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 0b53c43..9ccbbbd 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -460,19 +460,7 @@ static inline void skb_dst_set(struct sk_buff *skb, struct dst_entry *dst)
skb->_skb_refdst = (unsigned long)dst;
}
-/**
- * skb_dst_set_noref - sets skb dst, without a reference
- * @skb: buffer
- * @dst: dst entry
- *
- * Sets skb dst, assuming a reference was not taken on dst
- * skb_dst_drop() should not dst_release() this dst
- */
-static inline void skb_dst_set_noref(struct sk_buff *skb, struct dst_entry *dst)
-{
- WARN_ON(!rcu_read_lock_held() && !rcu_read_lock_bh_held());
- skb->_skb_refdst = (unsigned long)dst | SKB_DST_NOREF;
-}
+extern void skb_dst_set_noref(struct sk_buff *skb, struct dst_entry *dst);
/**
* skb_dst_is_noref - Test if skb dst isnt refcounted
diff --git a/net/core/dst.c b/net/core/dst.c
index 32e542d..8abe628 100644
--- a/net/core/dst.c
+++ b/net/core/dst.c
@@ -271,13 +271,40 @@ void dst_release(struct dst_entry *dst)
if (dst) {
int newrefcnt;
- smp_mb__before_atomic_dec();
newrefcnt = atomic_dec_return(&dst->__refcnt);
WARN_ON(newrefcnt < 0);
+ if (unlikely(dst->flags & DST_NOCACHE) && !newrefcnt) {
+ dst = dst_destroy(dst);
+ if (dst)
+ __dst_free(dst);
+ }
}
}
EXPORT_SYMBOL(dst_release);
+/**
+ * skb_dst_set_noref - sets skb dst, without a reference
+ * @skb: buffer
+ * @dst: dst entry
+ *
+ * Sets skb dst, assuming a reference was not taken on dst
+ * skb_dst_drop() should not dst_release() this dst
+ */
+void skb_dst_set_noref(struct sk_buff *skb, struct dst_entry *dst)
+{
+ WARN_ON(!rcu_read_lock_held() && !rcu_read_lock_bh_held());
+ /* If dst not in cache, we must take a reference, because
+ * dst_release() will destroy dst as soon as its refcount becomes zero
+ */
+ if (unlikely(dst->flags & DST_NOCACHE)) {
+ dst_hold(dst);
+ skb_dst_set(skb, dst);
+ } else {
+ skb->_skb_refdst = (unsigned long)dst | SKB_DST_NOREF;
+ }
+}
+EXPORT_SYMBOL(skb_dst_set_noref);
+
/* Dirty hack. We did it in 2.2 (in __dst_free),
* we have _very_ good reasons not to repeat
* this mistake in 2.3, but we have no choice
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 0755aa4..f2ce07b 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1105,9 +1105,9 @@ restart:
* Note that we do rt_free on this new route entry, so that
* once its refcount hits zero, we are still able to reap it
* (Thanks Alexey)
- * Note also the rt_free uses call_rcu. We don't actually
- * need rcu protection here, this is just our path to get
- * on the route gc list.
+ * Note: To avoid expensive rcu stuff for this uncached dst,
+ * we set DST_NOCACHE so that dst_release() can free dst without
+ * waiting a grace period.
*/
rt->dst.flags |= DST_NOCACHE;
@@ -1117,12 +1117,11 @@ restart:
if (net_ratelimit())
printk(KERN_WARNING
"Neighbour table failure & not caching routes.\n");
- rt_drop(rt);
+ ip_rt_put(rt);
return err;
}
}
- rt_free(rt);
goto skip_hashing;
}
^ permalink raw reply related
* Re: [PATCH 3/7] drivers/net/wireless/p54/eeprom.c: Return -ENOMEM on memory allocation failure
From: Christian Lamparter @ 2010-10-15 15:49 UTC (permalink / raw)
To: Julia Lawall
Cc: kernel-janitors-u79uwXL29TY76Z2rM5mHXA, John W. Linville,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1287147610-8041-3-git-send-email-julia-dAYI7NvHqcQ@public.gmane.org>
On Friday 15 October 2010 15:00:06 Julia Lawall wrote:
> From: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
>
> In this code, 0 is returned on memory allocation failure, even though other
> failures return -ENOMEM or other similar values.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression ret;
> expression x,e1,e2,e3;
> @@
>
> ret = 0
> ... when != ret = e1
> *x = \(kmalloc\|kcalloc\|kzalloc\)(...)
> ... when != ret = e2
> if (x == NULL) { ... when != ret = e3
> return ret;
> }
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
Cc: <stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Acked-by: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> ---
> drivers/net/wireless/p54/eeprom.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff -u -p a/drivers/net/wireless/p54/eeprom.c b/drivers/net/wireless/p54/eeprom.c
> --- a/drivers/net/wireless/p54/eeprom.c
> +++ b/drivers/net/wireless/p54/eeprom.c
> @@ -261,8 +261,10 @@ static int p54_generate_channel_lists(st
> list->max_entries = max_channel_num;
> list->channels = kzalloc(sizeof(struct p54_channel_entry) *
> max_channel_num, GFP_KERNEL);
> - if (!list->channels)
> + if (!list->channels) {
> + ret = -ENOMEM;
> goto free;
> + }
>
> for (i = 0; i < max_channel_num; i++) {
> if (i < priv->iq_autocal_len) {
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/6] r8169: print errors when dma mapping fail
From: Stanislaw Gruszka @ 2010-10-15 15:59 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, Denis Kirjanov
In-Reply-To: <20101015145201.GB4417@electric-eye.fr.zoreil.com>
On Fri, Oct 15, 2010 at 04:52:01PM +0200, Francois Romieu wrote:
> Stanislaw Gruszka <sgruszka@redhat.com> :
> > Print errors because dma mapping failures can cause device to stop
> > working and will need user intervention to recover.
>
> I am hesitating (overengineered ? bloaty ? not the right place ?).
As someone who seen lot's of bug reports like "my network device stops
working, nothing in dmesg", or like "my network device stops working,
there is NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out in
dmesg" (what is nothing but useful information), I do no think this is
overengineered or bloaty. I could agree for "not the right place", but
even if the error would be reported by upper layers, exact reason of
the problem will be unknown. Regarding lower layers, I don't think iommu
or other dma code print warning with calltrace in case of failure.
> The Tx stats are kept up-to-date : Tx failure will go along a Tx drop
> stat increase.
In current implementation, I stop tx queue on dma errors, if that
happens the queue can never be started again. I will probably change
that as you suggest not returning NETDEV_TX_BUSY, stopping the queue
is also wrong. But I would like to keep this error messages, perhaps
after adding net_ratelimit() check.
> Regarding a mapping failure in the Rx path, either it will behave as
> an allocation failure at open / resume time -
Still it's worth to know exact reason of failure.
> and I have no idea how
> the user will recover - or it will happen during a Rx ring refill.
ifconfig eth0 down/up or reloading module
Stanislaw
^ permalink raw reply
* Re: [PATCH V2 net-next] can-raw: add msg_flags to distinguish local traffic
From: Oliver Hartkopp @ 2010-10-15 16:15 UTC (permalink / raw)
To: Kurt Van Dijck; +Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w, netdev
In-Reply-To: <20101015153829.GA317-MxZ6Iy/zr/UdbCeoMzGj59i2O/JbrIOy@public.gmane.org>
Hello Kurt,
thanks for the patch.
I really appreciate this extension.
Some remarks inline ...
On 15.10.2010 17:38, Kurt Van Dijck wrote:
> diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
> index cd79735..95341aa 100644
> --- a/Documentation/networking/can.txt
> +++ b/Documentation/networking/can.txt
> @@ -22,6 +22,7 @@ This file contains
> 4.1.2 RAW socket option CAN_RAW_ERR_FILTER
> 4.1.3 RAW socket option CAN_RAW_LOOPBACK
> 4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
> + 4.1.5 RAW socket returned flags
> 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
> 4.3 connected transport protocols (SOCK_SEQPACKET)
> 4.4 unconnected transport protocols (SOCK_DGRAM)
> @@ -471,6 +472,16 @@ solution for a couple of reasons:
> setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS,
> &recv_own_msgs, sizeof(recv_own_msgs));
>
> + 4.1.5 RAW socket returned flags
> +
> + When using recvmsg() call, the msg->msg_flags may contain following flags:
> +
> + MSG_DONTROUTE: set when the frame was sent via the same physical device,
> + ie. a loopback frame.
According the code MSG_DONTROUTE indicates frames that have been originated on
the local host. Nothing more.
Only when you enabled CAN_RAW_RECV_OWN_MSGS and you bound the socket to a
specific CAN interface, the description becomes correct.
Better write:
MSG_DONTROUTE : set when the received frame was created on the local host.
> + MSG_CONFIRM: set when the frame was sent via the socket it is received on.
ok.
> + This flag acts as a 'transmission confirmation'.
Better:
This flag can be interpreted as a 'transmission confirmation' when the CAN
driver supports the echo of CAN frames on driver level, see 3.2 and 6.2
> + In order to receive such messages, CAN_RAW_RECV_OWN_MSGS must be set.
> +
> 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
> 4.3 connected transport protocols (SOCK_SEQPACKET)
> 4.4 unconnected transport protocols (SOCK_DGRAM)
> diff --git a/net/can/raw.c b/net/can/raw.c
> index 7d77e67..9020c4f 100644
> --- a/net/can/raw.c
> +++ b/net/can/raw.c
> @@ -90,23 +90,39 @@ struct raw_sock {
> can_err_mask_t err_mask;
> };
>
> +/*
> + * return some space to store extra msg flags in.
> + * We use 1 int beyond the 'struct sockaddr_can' in skb->cb
> + * to store those.
> + * These flags will be use in raw_recvmsg()
> + */
/*
* Return pointer to store the extra msg flags for raw_recvmsg().
* We use the space of one unsigned int beyond the 'struct sockaddr_can'
* in skb->cb.
*/
> +static inline unsigned int *raw_flags(struct sk_buff *skb)
> +{
> + BUILD_BUG_ON(sizeof(skb->cb) <= (sizeof(struct sockaddr_can)
> + + sizeof(unsigned int)));
One empty line would be nice here ...
> + /* return pointer after struct sockaddr_can */
> + return (unsigned int *)(&((struct sockaddr_can *)skb->cb)[1]);
> +}
> +
> static inline struct raw_sock *raw_sk(const struct sock *sk)
> {
> return (struct raw_sock *)sk;
> }
>
> -static void raw_rcv(struct sk_buff *skb, void *data)
> +static void raw_rcv(struct sk_buff *oskb, void *data)
> {
> struct sock *sk = (struct sock *)data;
> struct raw_sock *ro = raw_sk(sk);
> struct sockaddr_can *addr;
> + struct sk_buff *skb;
> + unsigned int *pflags;
>
> /* check the received tx sock reference */
> - if (!ro->recv_own_msgs && skb->sk == sk)
> + if (!ro->recv_own_msgs && oskb->sk == sk)
> return;
>
> /* clone the given skb to be able to enqueue it into the rcv queue */
> - skb = skb_clone(skb, GFP_ATOMIC);
> + skb = skb_clone(oskb, GFP_ATOMIC);
> if (!skb)
> return;
>
> @@ -123,6 +139,14 @@ static void raw_rcv(struct sk_buff *skb, void *data)
> addr->can_family = AF_CAN;
> addr->can_ifindex = skb->dev->ifindex;
>
> + /* prepare the flags for raw_recvmsg() */
> + pflags = raw_flags(skb);
> + *pflags = 0;
> + if (oskb->sk)
> + *pflags |= MSG_DONTROUTE;
> + if (oskb->sk == sk)
> + *pflags |= MSG_CONFIRM;
> +
A good improvement since your first proof-of-concept code :-)
> if (sock_queue_rcv_skb(sk, skb) < 0)
> kfree_skb(skb);
> }
> @@ -707,6 +731,9 @@ static int raw_recvmsg(struct kiocb *iocb, struct socket *sock,
> memcpy(msg->msg_name, skb->cb, msg->msg_namelen);
> }
>
> + /* assign the flags that have been recorded in raw_rcv() */
> + msg->msg_flags |= *(raw_flags(skb));
> +
dito :-)
> skb_free_datagram(sk, skb);
>
> return size;
Tnx & regards,
Oliver
^ permalink raw reply
* Re: [PATCH 2.6.35-rc6] net-next: Add multiqueue support to vmxnet3 driver
From: David Miller @ 2010-10-15 16:23 UTC (permalink / raw)
To: sbhatewara; +Cc: bhutchings, shemminger, netdev, pv-drivers, linux-kernel
In-Reply-To: <89E2752CFA8EC044846EB8499819134102BF0F3B1D@EXCH-MBX-4.vmware.com>
From: Shreyas Bhatewara <sbhatewara@vmware.com>
Date: Thu, 14 Oct 2010 16:31:35 -0700
> Okay. It would be best to keep module parameters to dictate number
> of queues till ethtool commands to do so become available/easy to
> use (command to change number of tx queues do not exist).
No, because then you can never remove these knobs, they must stay
forever.
And also then every other driver developer can make the same
argument. And then we have private knobs in every driver and
the user experience is a complete disaster.
Instead, the onus is on you to help get the ethtool interfaces
completed so your driver can provide the functionality it
wants.
Not the other way around (add crap first, use the proper interface
later whenever someone else gets around to it).
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