* [PATCH 3.6.0-rc3 1/2] of/mdio: Add dummy functions in of_mdio.h.
From: Srinivas KANDAGATLA @ 2012-08-24 11:58 UTC (permalink / raw)
To: netdev, laurentp
Cc: srinivas.kandagatla, davem, devicetree-discuss, grant.likely
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch adds dummy functions in of_mdio.h, so that driver need not
ifdef there code with CONFIG_OF.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
include/linux/of_mdio.h | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
index 912c27a..6ef49b8 100644
--- a/include/linux/of_mdio.h
+++ b/include/linux/of_mdio.h
@@ -12,6 +12,7 @@
#include <linux/phy.h>
#include <linux/of.h>
+#ifdef CONFIG_OF
extern int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np);
extern struct phy_device *of_phy_find_device(struct device_node *phy_np);
extern struct phy_device *of_phy_connect(struct net_device *dev,
@@ -24,4 +25,36 @@ extern struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
extern struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np);
+#else /* CONFIG_OF */
+int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
+{
+ return -ENOSYS;
+}
+
+struct phy_device *of_phy_find_device(struct device_node *phy_np)
+{
+ return NULL;
+}
+
+struct phy_device *of_phy_connect(struct net_device *dev,
+ struct device_node *phy_np,
+ void (*hndlr)(struct net_device *),
+ u32 flags, phy_interface_t iface)
+{
+ return NULL;
+}
+
+struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
+ void (*hndlr)(struct net_device *),
+ phy_interface_t iface)
+{
+ return NULL;
+}
+
+struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np)
+{
+ return NULL;
+}
+#endif /* CONFIG_OF */
+
#endif /* __LINUX_OF_MDIO_H */
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-next] netpoll: provide an IP ident in UDP frames
From: Eric Dumazet @ 2012-08-24 11:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
Let's fill IP header ident field with a meaningful value,
it might help some setups.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/netpoll.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 346b1eb..5af9c26 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -388,6 +388,7 @@ void netpoll_send_udp(struct netpoll *np, const char *msg, int len)
struct udphdr *udph;
struct iphdr *iph;
struct ethhdr *eth;
+ static atomic_t ip_ident;
udp_len = len + sizeof(*udph);
ip_len = udp_len + sizeof(*iph);
@@ -423,7 +424,7 @@ void netpoll_send_udp(struct netpoll *np, const char *msg, int len)
put_unaligned(0x45, (unsigned char *)iph);
iph->tos = 0;
put_unaligned(htons(ip_len), &(iph->tot_len));
- iph->id = 0;
+ iph->id = htons(atomic_inc_return(&ip_ident));
iph->frag_off = 0;
iph->ttl = 64;
iph->protocol = IPPROTO_UDP;
^ permalink raw reply related
* [PATCH v2] ethtool: don't overwrite useful bits in advertising bitfield
From: Johan Gunnarsson @ 2012-08-24 11:32 UTC (permalink / raw)
To: netdev; +Cc: bhutchings
There are bits in this bitfield that we want to leave untouched (PAUSE
and ASYM_PAUSE bits) when changing other bits (speed and duplex bits.)
Previously, these were always overwritten to zero when running commands
like "ethtool -s eth0 speed 10 duplex full autoneg off".
Signed-off-by: Johan Gunnarsson <johangu@axis.com>
---
Changes since v1:
* Added missing 10G and 40G link modes.
* Warn when drivers supports advertising flags that we don't know about.
* Removed "& ecmd.supported" in the advertising_wanted > 0 case.
ethtool.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++----------
1 file changed, 75 insertions(+), 14 deletions(-)
diff --git a/ethtool.c b/ethtool.c
index e573357..9cbe231 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -46,6 +46,53 @@
#define MAX_ADDR_LEN 32
#endif
+#define ALL_ADVERTISED_MODES \
+ (ADVERTISED_10baseT_Half | \
+ ADVERTISED_10baseT_Full | \
+ ADVERTISED_100baseT_Half | \
+ ADVERTISED_100baseT_Full | \
+ ADVERTISED_1000baseT_Half | \
+ ADVERTISED_1000baseT_Full | \
+ ADVERTISED_2500baseX_Full | \
+ ADVERTISED_10000baseKX4_Full | \
+ ADVERTISED_10000baseKR_Full | \
+ ADVERTISED_10000baseR_FEC | \
+ ADVERTISED_20000baseMLD2_Full | \
+ ADVERTISED_20000baseKR2_Full | \
+ ADVERTISED_40000baseKR4_Full | \
+ ADVERTISED_40000baseCR4_Full | \
+ ADVERTISED_40000baseSR4_Full | \
+ ADVERTISED_40000baseLR4_Full)
+
+#define ALL_ADVERTISED_FLAGS \
+ (ADVERTISED_10baseT_Half | \
+ ADVERTISED_10baseT_Full | \
+ ADVERTISED_100baseT_Half | \
+ ADVERTISED_100baseT_Full | \
+ ADVERTISED_1000baseT_Half | \
+ ADVERTISED_1000baseT_Full | \
+ ADVERTISED_Autoneg | \
+ ADVERTISED_TP | \
+ ADVERTISED_AUI | \
+ ADVERTISED_MII | \
+ ADVERTISED_FIBRE | \
+ ADVERTISED_BNC | \
+ ADVERTISED_10000baseT_Full | \
+ ADVERTISED_Pause | \
+ ADVERTISED_Asym_Pause | \
+ ADVERTISED_2500baseX_Full | \
+ ADVERTISED_Backplane | \
+ ADVERTISED_1000baseKX_Full | \
+ ADVERTISED_10000baseKX4_Full | \
+ ADVERTISED_10000baseKR_Full | \
+ ADVERTISED_10000baseR_FEC | \
+ ADVERTISED_20000baseMLD2_Full | \
+ ADVERTISED_20000baseKR2_Full | \
+ ADVERTISED_40000baseKR4_Full | \
+ ADVERTISED_40000baseCR4_Full | \
+ ADVERTISED_40000baseSR4_Full | \
+ ADVERTISED_40000baseLR4_Full)
+
#ifndef HAVE_NETIF_MSG
enum {
NETIF_MSG_DRV = 0x0001,
@@ -2202,6 +2249,7 @@ static int do_sset(struct cmd_context *ctx)
int autoneg_wanted = -1;
int phyad_wanted = -1;
int xcvr_wanted = -1;
+ int full_advertising_wanted = -1;
int advertising_wanted = -1;
int gset_changed = 0; /* did anything in GSET change? */
u32 wol_wanted = 0;
@@ -2277,7 +2325,7 @@ static int do_sset(struct cmd_context *ctx)
i += 1;
if (i >= argc)
exit_bad_args();
- advertising_wanted = get_int(argp[i], 16);
+ full_advertising_wanted = get_int(argp[i], 16);
} else if (!strcmp(argp[i], "phyad")) {
gset_changed = 1;
i += 1;
@@ -2334,7 +2382,10 @@ static int do_sset(struct cmd_context *ctx)
}
}
- if (advertising_wanted < 0) {
+ if (full_advertising_wanted < 0) {
+ /* User didn't supply a full advertisement bitfield:
+ * construct one from the specified speed and duplex.
+ */
if (speed_wanted == SPEED_10 && duplex_wanted == DUPLEX_HALF)
advertising_wanted = ADVERTISED_10baseT_Half;
else if (speed_wanted == SPEED_10 &&
@@ -2405,19 +2456,29 @@ static int do_sset(struct cmd_context *ctx)
}
if (autoneg_wanted == AUTONEG_ENABLE &&
advertising_wanted == 0) {
- ecmd.advertising = ecmd.supported &
- (ADVERTISED_10baseT_Half |
- ADVERTISED_10baseT_Full |
- ADVERTISED_100baseT_Half |
- ADVERTISED_100baseT_Full |
- ADVERTISED_1000baseT_Half |
- ADVERTISED_1000baseT_Full |
- ADVERTISED_2500baseX_Full |
- ADVERTISED_10000baseT_Full |
- ADVERTISED_20000baseMLD2_Full |
- ADVERTISED_20000baseKR2_Full);
+ /* Auto negotation enabled, but with
+ * unspecified speed and duplex: enable all
+ * supported speeds and duplexes.
+ */
+ ecmd.advertising = (ecmd.advertising &
+ ~ALL_ADVERTISED_MODES) |
+ (ALL_ADVERTISED_MODES & ecmd.supported);
+
+ /* If driver supports unknown flags, we can not
+ * be sure that we enable all link modes.
+ */
+ if ((ecmd.supported & ALL_ADVERTISED_FLAGS) !=
+ ecmd.supported) {
+ fprintf(stderr, "Drivers supports one "
+ "or more unknown flags\n");
+ }
} else if (advertising_wanted > 0) {
- ecmd.advertising = advertising_wanted;
+ /* Enable all requested modes */
+ ecmd.advertising = (ecmd.advertising &
+ ~ALL_ADVERTISED_MODES) |
+ advertising_wanted;
+ } else if (full_advertising_wanted > 0) {
+ ecmd.advertising = full_advertising_wanted;
}
/* Try to perform the update. */
--
1.7.10
^ permalink raw reply related
* Re: Q: what protects dev->napi_list?
From: Eric Dumazet @ 2012-08-24 11:29 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, Sylvain Munaut, David Miller
In-Reply-To: <1345804753.11584.43.camel@cr0>
On Fri, 2012-08-24 at 18:39 +0800, Cong Wang wrote:
> On Fri, 2012-08-24 at 12:12 +0200, Eric Dumazet wrote:
> > On Fri, 2012-08-24 at 17:46 +0800, Cong Wang wrote:
> > > Hi,
> > >
> > > Sylvain reported a netpoll CPU stall
> > > http://marc.info/?l=linux-netdev&m=134563282530588&w=2
> > >
> > > I tried to provide some fix for it:
> > > http://marc.info/?l=linux-netdev&m=134571069921429&w=2
> > >
> > > When reviewing that code, I noticed a problem, it seems dev->napi_list
> > > is not protected by any lock? What if the device driver calls
> > > netif_napi_del() meanwhile we are iterating &dev->napi_list in
> > > poll_napi()? It seems netif_napi_del()/netif_napi_add() are usually
> > > called with the RTNL lock held during driver init/uninit, but again
> > > poll_napi() doesn't have RTNL lock.
> > >
> >
> > Of course poll_napi() cant try to get RTNL (its a mutex by the way)
> >
> > There are no problems, since :
> >
> > netif_napi_add() is called at device open time (before napi_poll() can
> > use it)
> >
> > netif_napi_del() at device dismantle time (after making sure napi_poll()
> > wont use the device again)
>
> Yeah, but bnx2 driver calls it at other time too, for example
> bnx2_change_ring_size() which in turn could be called by
> bnx2_set_channels().
Then at this point, device is stopped, or should be.
^ permalink raw reply
* [PATCH 1/1] l2tp: avoid to use synchronize_rcu in tunnel free function
From: Kozlov Dmitry @ 2012-08-24 11:07 UTC (permalink / raw)
To: netdev; +Cc: kleptog, jchapman
Avoid to use synchronize_rcu in l2tp_tunnel_free because context may be
atomic.
Signed-off-by: Dmitry Kozlov <xeb@mail.ru>
---
net/l2tp/l2tp_core.c | 3 +--
net/l2tp/l2tp_core.h | 1 +
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index 393355d..513cab0 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1347,11 +1347,10 @@ static void l2tp_tunnel_free(struct l2tp_tunnel *tunnel)
/* Remove from tunnel list */
spin_lock_bh(&pn->l2tp_tunnel_list_lock);
list_del_rcu(&tunnel->list);
+ kfree_rcu(tunnel, rcu);
spin_unlock_bh(&pn->l2tp_tunnel_list_lock);
- synchronize_rcu();
atomic_dec(&l2tp_tunnel_count);
- kfree(tunnel);
}
/* Create a socket for the tunnel, if one isn't set up by
diff --git a/net/l2tp/l2tp_core.h b/net/l2tp/l2tp_core.h
index a38ec6c..56d583e 100644
--- a/net/l2tp/l2tp_core.h
+++ b/net/l2tp/l2tp_core.h
@@ -163,6 +163,7 @@ struct l2tp_tunnel_cfg {
struct l2tp_tunnel {
int magic; /* Should be L2TP_TUNNEL_MAGIC */
+ struct rcu_head rcu;
rwlock_t hlist_lock; /* protect session_hlist */
struct hlist_head session_hlist[L2TP_HASH_SIZE];
/* hashed list of sessions,
^ permalink raw reply related
* [PATCH 0/1] l2tp: avoid to use synchronize_rcu in tunnel free function
From: Kozlov Dmitry @ 2012-08-24 11:07 UTC (permalink / raw)
To: netdev; +Cc: kleptog, jchapman
Avoid to use synchronize_rcu in l2tp_tunnel_free because context may be
atomic.
This fixes following condition:
[ 71.773006] BUG: scheduling while atomic: swapper/0/0/0x00000100
[ 71.775593] Modules linked in: authenc rmd160 crypto_null l2tp_ppp
l2tp_core pptp pppox gre camellia_generic cast6 cast5 deflate zlib_deflate cts
ctr gcm ccm serpent_sse2_i586 lrw serpent_generic xts gf128mul
blowfish_generic blowfish_common twofish_generic twofish_i586 twofish_common
xcbc sha512_generic des_generic geode_aes xfrm_user ah4 esp4 xfrm4_mode_beet
xfrm4_tunnel tunnel4 xfrm4_mode_tunnel xfrm4_mode_transport ipcomp xfrm_ipcomp
tunnel6 af_key xfrm_algo coretemp kvm_intel kvm aesni_intel cryptd mgag200 ttm
drm_kms_helper drm aes_i586 i2c_algo_bit sysimgblt sysfillrect syscopyarea
dcdbas lpc_ich microcode mac_hid lp parport usb_storage uas hid_generic usbhid
hid mpt2sas scsi_transport_sas raid_class bnx2
[ 71.775627] Pid: 0, comm: swapper/0 Not tainted 3.5.0-11-generic #11-Ubuntu
[ 71.775628] Call Trace:
[ 71.775632] [<c15bf650>] __schedule_bug+0x52/0x5e
[ 71.775635] [<c15c7ede>] __schedule+0x75e/0x770
[ 71.775639] [<c152e797>] ? udp_rcv+0x17/0x20
[ 71.775642] [<c1506179>] ? ip_local_deliver_finish+0xa9/0x260
[ 71.775644] [<c150647c>] ? ip_local_deliver+0x3c/0x80
[ 71.775646] [<c15c8193>] schedule+0x23/0x60
[ 71.775647] [<c15c69a5>] schedule_timeout+0x215/0x280
[ 71.775650] [<c12c80af>] ? cpumask_next_and+0x1f/0x40
[ 71.775653] [<c107c4ed>] ? update_sd_lb_stats+0xcd/0x4b0
[ 71.775655] [<c15c8011>] wait_for_common+0xa1/0x120
[ 71.775657] [<c1075f50>] ? try_to_wake_up+0x230/0x230
[ 71.775661] [<c10cbc50>] ? call_rcu_bh+0x20/0x20
[ 71.775662] [<c15c8167>] wait_for_completion+0x17/0x20
[ 71.775665] [<c10627b9>] wait_rcu_gp+0x39/0x40
[ 71.775667] [<c10627c0>] ? wait_rcu_gp+0x40/0x40
[ 71.775669] [<c10cad82>] synchronize_sched+0x32/0x40
[ 71.775672] [<f8c93a47>] l2tp_tunnel_free+0x87/0xd0 [l2tp_core]
[ 71.775674] [<f8c93c25>] l2tp_tunnel_destruct+0x195/0x210 [l2tp_core]
[ 71.775676] [<c14cb649>] __sk_free+0x19/0x120
[ 71.775678] [<c14cb782>] sock_wfree+0x32/0x60
[ 71.775680] [<c14ceed3>] skb_release_head_state+0x43/0xc0
[ 71.775682] [<c14cecd0>] __kfree_skb+0x10/0x90
[ 71.775684] [<c14cf11c>] consume_skb+0x2c/0x80
[ 71.775689] [<f848b951>] bnx2_poll_work+0x1f1/0x3b0 [bnx2]
[ 71.775692] [<f848bb39>] bnx2_poll_msix+0x29/0xa0 [bnx2]
[ 71.775695] [<c14daca5>] net_rx_action+0xf5/0x1d0
[ 71.775698] [<c104cac7>] __do_softirq+0x87/0x180
[ 71.775700] [<c104ca40>] ? local_bh_enable_ip+0x90/0x90
[ 71.775701] <IRQ> [<c104ce15>] ? irq_exit+0x95/0xa0
[ 71.775705] [<c15d04db>] ? do_IRQ+0x4b/0xc0
[ 71.775707] [<c15d0330>] ? common_interrupt+0x30/0x38
[ 71.775710] [<c10400e0>] ? virt_efi_get_variable+0x10/0x40
[ 71.775712] [<c1326c43>] ? intel_idle+0xc3/0x120
^ permalink raw reply
* Re: [PATCH 1/2] ipv6: do not hold route table lock when send ndisc probe
From: Cong Wang @ 2012-08-24 10:45 UTC (permalink / raw)
To: Eric Dumazet
Cc: Debabrata Banerjee, netdev, Banerjee, Debabrata, David S. Miller,
Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <1345801484.29722.2.camel@edumazet-glaptop>
On Fri, 2012-08-24 at 11:44 +0200, Eric Dumazet wrote:
> On Fri, 2012-08-24 at 17:15 +0800, Cong Wang wrote:
>
> >
> > Right... If we call dev_hold() in the work, it is possible that the work
> > is still not scheduled to running when we unregister the device. What's
> > more, we can't flush work here as we are holding a read lock.
>
> You need a global list (and a single work, not one per req), so that a
> notifier can flush it at demand.
>
>
Agreed. I will make a new patch.
Thanks!
^ permalink raw reply
* Re: Q: what protects dev->napi_list?
From: Cong Wang @ 2012-08-24 10:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Sylvain Munaut, David Miller
In-Reply-To: <1345803142.29722.20.camel@edumazet-glaptop>
On Fri, 2012-08-24 at 12:12 +0200, Eric Dumazet wrote:
> On Fri, 2012-08-24 at 17:46 +0800, Cong Wang wrote:
> > Hi,
> >
> > Sylvain reported a netpoll CPU stall
> > http://marc.info/?l=linux-netdev&m=134563282530588&w=2
> >
> > I tried to provide some fix for it:
> > http://marc.info/?l=linux-netdev&m=134571069921429&w=2
> >
> > When reviewing that code, I noticed a problem, it seems dev->napi_list
> > is not protected by any lock? What if the device driver calls
> > netif_napi_del() meanwhile we are iterating &dev->napi_list in
> > poll_napi()? It seems netif_napi_del()/netif_napi_add() are usually
> > called with the RTNL lock held during driver init/uninit, but again
> > poll_napi() doesn't have RTNL lock.
> >
>
> Of course poll_napi() cant try to get RTNL (its a mutex by the way)
>
> There are no problems, since :
>
> netif_napi_add() is called at device open time (before napi_poll() can
> use it)
>
> netif_napi_del() at device dismantle time (after making sure napi_poll()
> wont use the device again)
Yeah, but bnx2 driver calls it at other time too, for example
bnx2_change_ring_size() which in turn could be called by
bnx2_set_channels().
^ permalink raw reply
* Re: [RFC Patch net-next] ipv6: unify conntrack reassembly expire code with standard one
From: Cong Wang @ 2012-08-24 10:13 UTC (permalink / raw)
To: Michal Kubecek
Cc: netdev, Herbert Xu, David S. Miller, Hideaki YOSHIFUJI,
Patrick McHardy, Pablo Neira Ayuso, netfilter-devel
In-Reply-To: <20120820202109.GB28790@unicorn.suse.cz>
Hi, Michal,
Could you help to test my updated patches?
You can find them (the most top 4 patches) in my github tree:
https://github.com/congwang/linux/commits/ipv6
which is based on net-next.
I tried to setup the environment to reproduce it, but failed. I also
tried scapy, but I still can't trigger "Fragment Reassembly Timeout".
Thanks a lot!
^ permalink raw reply
* Re: Q: what protects dev->napi_list?
From: Eric Dumazet @ 2012-08-24 10:12 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, Sylvain Munaut, David Miller
In-Reply-To: <1345801604.11584.24.camel@cr0>
On Fri, 2012-08-24 at 17:46 +0800, Cong Wang wrote:
> Hi,
>
> Sylvain reported a netpoll CPU stall
> http://marc.info/?l=linux-netdev&m=134563282530588&w=2
>
> I tried to provide some fix for it:
> http://marc.info/?l=linux-netdev&m=134571069921429&w=2
>
> When reviewing that code, I noticed a problem, it seems dev->napi_list
> is not protected by any lock? What if the device driver calls
> netif_napi_del() meanwhile we are iterating &dev->napi_list in
> poll_napi()? It seems netif_napi_del()/netif_napi_add() are usually
> called with the RTNL lock held during driver init/uninit, but again
> poll_napi() doesn't have RTNL lock.
>
Of course poll_napi() cant try to get RTNL (its a mutex by the way)
There are no problems, since :
netif_napi_add() is called at device open time (before napi_poll() can
use it)
netif_napi_del() at device dismantle time (after making sure napi_poll()
wont use the device again)
^ permalink raw reply
* Re: [net-next 10/13] igb: Tidy up wrapping for CONFIG_IGB_PTP.
From: Richard Cochran @ 2012-08-24 10:10 UTC (permalink / raw)
To: Vick, Matthew
Cc: Keller, Jacob E, Kirsher, Jeffrey T, davem@davemloft.net,
netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com
In-Reply-To: <06DFBC1E25D8024DB214DC7F41A3CD34488DD35B@ORSMSX101.amr.corp.intel.com>
On Thu, Aug 23, 2012 at 06:40:25PM +0000, Vick, Matthew wrote:
>
> I tend to agree with Jake here--I like having the information. I'm fine removing them, but I'd like to do it for all CONFIG_IGB_PTP wrapping if we're going to do it. What do you think, Richard?
Come to think of it, I never liked the CONFIG_IGB_PTP very much in the
first place. These were added after the fact by Jeff Kirsher. He had
said off list that there was some issue with CONFIG_PTP_1588_CLOCK and
igb as a module, or something like that. At that time I said, just go
ahead and fix it up.
I think it would be better if the "time stamp all Rx packets" of the
82580 were always available, and that the PHC feature always be
compiled when CONFIG_PTP_1588_CLOCK is selected.
Maybe you could ask Jeff what the issue was, and then see if there is
a way to remove CONFIG_IGB_PTP altogether.
Thanks,
Richard
^ permalink raw reply
* RE: netlink scm creds uid and gids are always 0.
From: David Laight @ 2012-08-24 9:45 UTC (permalink / raw)
To: Eric W. Biederman, Eric Dumazet; +Cc: netdev
In-Reply-To: <877gsok68x.fsf@xmission.com>
> There is still a possible issue with netlink sockets and pids when the
> two processes talking over netlink are in different pid namespaces.
Isn't there a more general problem of the sending process exiting
and its pid being reused before the receiving program makes use
of the value?
IIRC 2.6.27 tried to alleviate this for some code paths by
using a reference-counted structure for some kernel calls.
(A PITA because the function to lose the reference is exported
GPL_ONLY ...)
David
^ permalink raw reply
* Re: NULL deref in bnx2 / crashes ? ( was: netconsole leads to stalled CPU task )
From: Sylvain Munaut @ 2012-08-24 9:50 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev
In-Reply-To: <k14s5v$7bs$2@ger.gmane.org>
Hi,
>>
>> Could you test the following patch?
>>
>> diff --git a/net/core/netpoll.c b/net/core/netpoll.c
>> index ddc453b..ed4d1e4 100644
>> --- a/net/core/netpoll.c
>> +++ b/net/core/netpoll.c
>> @@ -166,11 +166,18 @@ static int poll_one_napi(struct netpoll_info *npinfo,
>> static void poll_napi(struct net_device *dev)
>> {
>> struct napi_struct *napi;
>> + LIST_HEAD(napi_list);
>> int budget = 16;
>>
>> WARN_ON_ONCE(!irqs_disabled());
>>
>> - list_for_each_entry(napi, &dev->napi_list, dev_list) {
>> + /* After we enable the IRQ, new entries could be added
>> + * to this list, we need to save it before re-enable
>> + * IRQ.
>> + */
>> + list_splice_tail(&dev->napi_list, &napi_list);
>> +
>
> This one should be list_splice_init()...
>
>
>> + list_for_each_entry(napi, &napi_list, dev_list) {
>> local_irq_enable();
>> if (napi->poll_owner != smp_processor_id() &&
>> spin_trylock(&napi->poll_lock)) {
>> @@ -187,6 +194,7 @@ static void poll_napi(struct net_device *dev)
>> }
>> local_irq_disable();
>> }
>> + list_splice_tail(&napi_list, &dev->napi_list);
>> }
>>
>> static void service_arp_queue(struct netpoll_info *npi)
I've just tested this patch on the intel machine and the behavior didn't change.
When I do the netconsole modprobe, it sends a couple of line, the
modprobe hangs and then a couple of second later the whole machine
hangs, with nothing printed on the screen or anything.
Cheers,
Sylvain
^ permalink raw reply
* RE: [PATCH] ethtool: don't overwrite useful bits in advertising bitfield
From: Johan Gunnarsson @ 2012-08-24 9:50 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev@vger.kernel.org, Mikael Starvik
In-Reply-To: <1345568582.2659.53.camel@bwh-desktop.uk.solarflarecom.com>
> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> Sent: den 21 augusti 2012 19:03
> To: Johan Gunnarsson
> Cc: netdev@vger.kernel.org; Mikael Starvik
> Subject: RE: [PATCH] ethtool: don't overwrite useful bits in
> advertising bitfield
>
> [...]
>
> <linux/ethtool.h> or ethtool-copy.h currently defines the meanings of
> bits 0-26 in the supported field. You define ALL_ADVERTISED_MODES to
> include all of those that are link modes. But some time in the future,
> the remaining bits will be assigned to new capabilities.
>
> If today's ethtool is used with a newer driver that sets bit 27 in its
> supported field, ethtool can't tell whether that represents a new link
> mode that should be included in ALL_ADVERTISED_MODES, or some other
> kind
> of capability. So it may not be able to set the driver's advertising
> mask correctly.
I see. Thanks. I'll submit new version of the patch.
>
> Ben.
>
> --
> Ben Hutchings, Staff Engineer, Solarflare
> 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
* Q: what protects dev->napi_list?
From: Cong Wang @ 2012-08-24 9:46 UTC (permalink / raw)
To: netdev; +Cc: Eric Dumazet, Sylvain Munaut, David Miller
Hi,
Sylvain reported a netpoll CPU stall
http://marc.info/?l=linux-netdev&m=134563282530588&w=2
I tried to provide some fix for it:
http://marc.info/?l=linux-netdev&m=134571069921429&w=2
When reviewing that code, I noticed a problem, it seems dev->napi_list
is not protected by any lock? What if the device driver calls
netif_napi_del() meanwhile we are iterating &dev->napi_list in
poll_napi()? It seems netif_napi_del()/netif_napi_add() are usually
called with the RTNL lock held during driver init/uninit, but again
poll_napi() doesn't have RTNL lock.
Am I missing anything?
Thanks!
^ permalink raw reply
* Re: [PATCH 1/2] ipv6: do not hold route table lock when send ndisc probe
From: Eric Dumazet @ 2012-08-24 9:44 UTC (permalink / raw)
To: Cong Wang
Cc: Debabrata Banerjee, netdev, Banerjee, Debabrata, David S. Miller,
Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <1345799724.11584.15.camel@cr0>
On Fri, 2012-08-24 at 17:15 +0800, Cong Wang wrote:
>
> Right... If we call dev_hold() in the work, it is possible that the work
> is still not scheduled to running when we unregister the device. What's
> more, we can't flush work here as we are holding a read lock.
You need a global list (and a single work, not one per req), so that a
notifier can flush it at demand.
^ permalink raw reply
* pull-request: can 2012-08-24
From: Marc Kleine-Budde @ 2012-08-24 9:30 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-can
Hello David,
here are two fixes for the v3.6 release cycle. Alexey Khoroshilov submitted a
fix for a memory leak in the softing driver (in softing_load_fw()) in case a
krealloc() fails. Sven Schmitt fixed the misuse of the IRQF_SHARED flag in the
irq resouce of the sja1000 platform driver, now the correct flag is used. There
are no mainline users of this feature which need to be converted.
regards, Marc
The following changes since commit a0dfb2634e5671770f598cda08002d8cda66ac77:
af_packet: match_fanout_group() can be static (2012-08-23 09:27:12 -0700)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can.git fixes-for-3.6
for you to fetch changes up to da3d50ef308d53f216f1f92f4971f245c13e9f65:
can: sja1000_platform: fix wrong flag IRQF_SHARED for interrupt sharing (2012-08-24 10:54:05 +0200)
----------------------------------------------------------------
Alexey Khoroshilov (1):
can: softing: Fix potential memory leak in softing_load_fw()
Sven Schmitt (1):
can: sja1000_platform: fix wrong flag IRQF_SHARED for interrupt sharing
drivers/net/can/sja1000/sja1000_platform.c | 4 +++-
drivers/net/can/softing/softing_fw.c | 7 ++++---
2 files changed, 7 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH 2/2] can: sja1000_platform: fix wrong flag IRQF_SHARED for interrupt sharing
From: Marc Kleine-Budde @ 2012-08-24 9:30 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-can, Sven Schmitt, Marc Kleine-Budde
In-Reply-To: <1345800643-29456-1-git-send-email-mkl@pengutronix.de>
From: Sven Schmitt <sven.schmitt@volkswagen.de>
The sja1000 platform driver wrongly assumes that a shared IRQ is indicated
with the IRQF_SHARED flag in irq resource flags. This patch changes the
driver to handle the correct flag IORESOURCE_IRQ_SHAREABLE instead.
There are no mainline users of the platform driver which wrongly make use
of IRQF_SHARED.
Signed-off-by: Sven Schmitt <sven.schmitt@volkswagen.de>
Acked-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/sja1000/sja1000_platform.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/sja1000/sja1000_platform.c b/drivers/net/can/sja1000/sja1000_platform.c
index 4f50145..662c5f7 100644
--- a/drivers/net/can/sja1000/sja1000_platform.c
+++ b/drivers/net/can/sja1000/sja1000_platform.c
@@ -109,7 +109,9 @@ static int sp_probe(struct platform_device *pdev)
priv = netdev_priv(dev);
dev->irq = res_irq->start;
- priv->irq_flags = res_irq->flags & (IRQF_TRIGGER_MASK | IRQF_SHARED);
+ priv->irq_flags = res_irq->flags & IRQF_TRIGGER_MASK;
+ if (res_irq->flags & IORESOURCE_IRQ_SHAREABLE)
+ priv->irq_flags |= IRQF_SHARED;
priv->reg_base = addr;
/* The CAN clock frequency is half the oscillator clock frequency */
priv->can.clock.freq = pdata->osc_freq / 2;
--
1.7.10
^ permalink raw reply related
* [PATCH 1/2] can: softing: Fix potential memory leak in softing_load_fw()
From: Marc Kleine-Budde @ 2012-08-24 9:30 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-can, Alexey Khoroshilov, Marc Kleine-Budde
In-Reply-To: <1345800643-29456-1-git-send-email-mkl@pengutronix.de>
From: Alexey Khoroshilov <khoroshilov@ispras.ru>
Do not leak memory by updating pointer with potentially NULL realloc return value.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/softing/softing_fw.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/softing/softing_fw.c b/drivers/net/can/softing/softing_fw.c
index 3105961..b595d34 100644
--- a/drivers/net/can/softing/softing_fw.c
+++ b/drivers/net/can/softing/softing_fw.c
@@ -150,7 +150,7 @@ int softing_load_fw(const char *file, struct softing *card,
const uint8_t *mem, *end, *dat;
uint16_t type, len;
uint32_t addr;
- uint8_t *buf = NULL;
+ uint8_t *buf = NULL, *new_buf;
int buflen = 0;
int8_t type_end = 0;
@@ -199,11 +199,12 @@ int softing_load_fw(const char *file, struct softing *card,
if (len > buflen) {
/* align buflen */
buflen = (len + (1024-1)) & ~(1024-1);
- buf = krealloc(buf, buflen, GFP_KERNEL);
- if (!buf) {
+ new_buf = krealloc(buf, buflen, GFP_KERNEL);
+ if (!new_buf) {
ret = -ENOMEM;
goto failed;
}
+ buf = new_buf;
}
/* verify record data */
memcpy_fromio(buf, &dpram[addr + offset], len);
--
1.7.10
^ permalink raw reply related
* Re: [net-next 11/13] igb: Update PTP function names/variables and locations.
From: Joe Perches @ 2012-08-24 9:22 UTC (permalink / raw)
To: Richard Cochran
Cc: Vick, Matthew, Kirsher, Jeffrey T, davem@davemloft.net,
netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com
In-Reply-To: <20120824063240.GB2212@netboy.at.omicron.at>
On Fri, 2012-08-24 at 08:32 +0200, Richard Cochran wrote:
> On Thu, Aug 23, 2012 at 08:02:25PM -0700, Joe Perches wrote:
>
> > Improving code clarity and consistency isn't churn.
>
> This patch series moves code around for no good reason. That is, by
> definition, churn.
For your definition of good.
> > The most valuable form of code is the current one,
> > not any antecedent version.
>
> You really haven't noticed all the code review and rebasing that goes
> on around here in order to improve the commit history, have you?
That'd be incorrect too.
^ permalink raw reply
* Re: [PATCH 1/2] ipv6: do not hold route table lock when send ndisc probe
From: Cong Wang @ 2012-08-24 9:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: Debabrata Banerjee, netdev, Banerjee, Debabrata, David S. Miller,
Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <1345738232.5904.1244.camel@edumazet-glaptop>
On Thu, 2012-08-23 at 18:10 +0200, Eric Dumazet wrote:
> On Tue, 2012-08-21 at 11:44 +0800, Cong Wang wrote:
> > Hi, Debabrata,
> >
> > Could you help to test the attached patch below?
> >
> > Thanks!
> >
>
> Hard to comment on your patch since its not inlined.
>
> + nw = kmalloc(sizeof(*nw), GFP_ATOMIC);
> + if (nw) {
> + memcpy(&nw->target, &neigh->primary_key, sizeof(struct in6_addr));
> + addrconf_addr_solict_mult(&nw->target, &nw->mcaddr);
> + nw->dev = rt->dst.dev;
> + INIT_WORK(&nw->work, queue_ndisc);
> + schedule_work(&nw->work);
> + }
>
> You cant do that without taking extra reference on dev,
> and release it in queue_ndisc()
>
> This also will add interesting side effects at device dismantle.
>
Right... If we call dev_hold() in the work, it is possible that the work
is still not scheduled to running when we unregister the device. What's
more, we can't flush work here as we are holding a read lock.
Hmm.
^ permalink raw reply
* Re: netlink scm creds uid and gids are always 0.
From: Eric W. Biederman @ 2012-08-24 9:07 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <87txvsk8h7.fsf@xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> Eric Dumazet <eric.dumazet@gmail.com> writes:
>
>> On Thu, 2012-08-23 at 23:45 -0700, Eric W. Biederman wrote:
>>> While working on the kuid_t and kgid_t conversion of the audit subsystem
>>> I noticed that since the performance problem of scm creds and af_unix
>>> sockets were fixed af_netlink sockets have not filled in the uid or gid
>>> of the originator of the socket.
>>>
>>> I think all we need is an appropriate cred_to_ucred call to fix this
>>> regression, but I am going so many different directions right now I
>>> can't get myself to focus on this long enough to work up an appripriate
>>> patch to fix.
>>>
>>> Eric do you think you might take a gander?
>>
>> Wasnt it fixed by e0e3cea46d31d23dc40df0a49a7a2c04fe8edfea
>>
>> af_netlink: force credentials passing [CVE-2012-3520]
>>
>> Or is it a different thing ?
>
> Same thing. I didn't see that fix go by.
>
> One more little thing I can cross off my list. Hooray!
Looking a little deeper it looks like I am going to have to
give scm credentials a little more tender loving care.
There is still a possible issue with netlink sockets and pids when the
two processes talking over netlink are in different pid namespaces.
And I need to take care in my usernamespace tree for 3.7, to keep from
reintroucing the ability to spoof root if the two netlink talkers are in
different user namespaces.
With a little luck for uids and gids I can just pass around kuid_t and
kgid_t values and throw out the ref-counting complexity. Something
to sleep on and benchmark, and then generate a patch I guess.
I know at least from my last attempt that ref counting in the NETLINK_CB
was a lost cause. So I don't know what to do about the pids :(
Eric
^ permalink raw reply
* Re: netlink scm creds uid and gids are always 0.
From: Eric W. Biederman @ 2012-08-24 8:19 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1345795065.5904.2287.camel@edumazet-glaptop>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> On Thu, 2012-08-23 at 23:45 -0700, Eric W. Biederman wrote:
>> While working on the kuid_t and kgid_t conversion of the audit subsystem
>> I noticed that since the performance problem of scm creds and af_unix
>> sockets were fixed af_netlink sockets have not filled in the uid or gid
>> of the originator of the socket.
>>
>> I think all we need is an appropriate cred_to_ucred call to fix this
>> regression, but I am going so many different directions right now I
>> can't get myself to focus on this long enough to work up an appripriate
>> patch to fix.
>>
>> Eric do you think you might take a gander?
>
> Wasnt it fixed by e0e3cea46d31d23dc40df0a49a7a2c04fe8edfea
>
> af_netlink: force credentials passing [CVE-2012-3520]
>
> Or is it a different thing ?
Same thing. I didn't see that fix go by.
One more little thing I can cross off my list. Hooray!
Eric
^ permalink raw reply
* Business
From: hashi @ 2012-08-24 7:31 UTC (permalink / raw)
Good Day,
I am Mr. Xiao Gang from Bank of China.I have a secured business proposal worth
$45,275,000.00. Get back to me for more details.
Regards,
Mr. XIAO Gang
^ permalink raw reply
* Re: netlink scm creds uid and gids are always 0.
From: Eric Dumazet @ 2012-08-24 7:57 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev
In-Reply-To: <871uiwlrf3.fsf@xmission.com>
On Thu, 2012-08-23 at 23:45 -0700, Eric W. Biederman wrote:
> While working on the kuid_t and kgid_t conversion of the audit subsystem
> I noticed that since the performance problem of scm creds and af_unix
> sockets were fixed af_netlink sockets have not filled in the uid or gid
> of the originator of the socket.
>
> I think all we need is an appropriate cred_to_ucred call to fix this
> regression, but I am going so many different directions right now I
> can't get myself to focus on this long enough to work up an appripriate
> patch to fix.
>
> Eric do you think you might take a gander?
Wasnt it fixed by e0e3cea46d31d23dc40df0a49a7a2c04fe8edfea
af_netlink: force credentials passing [CVE-2012-3520]
Or is it a different thing ?
^ 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