* Re: [PATCH net] net: fix sysfs symlinks of adjacent devices
From: David Miller @ 2014-09-14 21:45 UTC (permalink / raw)
To: vyasevich; +Cc: git.user, netdev, cwang, vyasevic, andres
In-Reply-To: <5412F633.8020102@gmail.com>
From: Vlad Yasevich <vyasevich@gmail.com>
Date: Fri, 12 Sep 2014 09:33:39 -0400
> Looking over the code, it might make sense to move all the net_eq checks
> into adjacent_sysfs calls so as to consolidate them. I haven't audited
> all code paths, but at first glance it should do the right thing.
>
> What do you think?
Agreed, let's do the following then?
diff --git a/net/core/dev.c b/net/core/dev.c
index ab9a165..a70e49e 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4809,9 +4809,14 @@ static void netdev_adjacent_sysfs_del(struct net_device *dev,
sysfs_remove_link(&(dev->dev.kobj), linkname);
}
-#define netdev_adjacent_is_neigh_list(dev, dev_list) \
- (dev_list == &dev->adj_list.upper || \
- dev_list == &dev->adj_list.lower)
+static bool netdev_adjacent_is_neigh_list(struct net_device *dev,
+ struct net_device *adj_dev,
+ struct list_head *dev_list)
+{
+ return (dev_list == &dev->adj_list.upper ||
+ dev_list == &dev->adj_list.lower) &&
+ net_eq(dev_net(dev), dev_net(adj_dev));
+}
static int __netdev_adjacent_dev_insert(struct net_device *dev,
struct net_device *adj_dev,
@@ -4841,7 +4846,7 @@ static int __netdev_adjacent_dev_insert(struct net_device *dev,
pr_debug("dev_hold for %s, because of link added from %s to %s\n",
adj_dev->name, dev->name, adj_dev->name);
- if (netdev_adjacent_is_neigh_list(dev, dev_list)) {
+ if (netdev_adjacent_is_neigh_list(dev, adj_dev, dev_list)) {
ret = netdev_adjacent_sysfs_add(dev, adj_dev, dev_list);
if (ret)
goto free_adj;
@@ -4862,7 +4867,7 @@ static int __netdev_adjacent_dev_insert(struct net_device *dev,
return 0;
remove_symlinks:
- if (netdev_adjacent_is_neigh_list(dev, dev_list))
+ if (netdev_adjacent_is_neigh_list(dev, adj_dev, dev_list))
netdev_adjacent_sysfs_del(dev, adj_dev->name, dev_list);
free_adj:
kfree(adj);
@@ -4895,8 +4900,7 @@ static void __netdev_adjacent_dev_remove(struct net_device *dev,
if (adj->master)
sysfs_remove_link(&(dev->dev.kobj), "master");
- if (netdev_adjacent_is_neigh_list(dev, dev_list) &&
- net_eq(dev_net(dev),dev_net(adj_dev)))
+ if (netdev_adjacent_is_neigh_list(dev, adj_dev, dev_list))
netdev_adjacent_sysfs_del(dev, adj_dev->name, dev_list);
list_del_rcu(&adj->list);
^ permalink raw reply related
* Re: [PATCH net-next 5/5] netfilter: Convert pr_warning to pr_warn
From: Jozsef Kadlecsik @ 2014-09-14 19:13 UTC (permalink / raw)
To: Joe Perches
Cc: netdev, Pablo Neira Ayuso, Patrick McHardy, David S. Miller,
netfilter-devel, coreteam, linux-kernel
In-Reply-To: <4708b4ef0485c1bc9efe3c0e59924a0f1c3c3bb4.1410322181.git.joe@perches.com>
On Tue, 9 Sep 2014, Joe Perches wrote:
> Use the more common pr_warn.
>
> Other miscellanea:
>
> o Coalesce formats
> o Realign arguments
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> net/netfilter/ipset/ip_set_core.c | 23 +++++++++++-----------
> net/netfilter/ipset/ip_set_hash_gen.h | 12 ++++++------
> net/netfilter/xt_connbytes.c | 2 +-
> net/netfilter/xt_hashlimit.c | 2 +-
> net/netfilter/xt_set.c | 36 ++++++++++++++++-------------------
> 5 files changed, 35 insertions(+), 40 deletions(-)
Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* Re: iwlwifi no authentication with AP - Re: pull request: wireless-next 2014-09-08
From: Kalle Valo @ 2014-09-14 18:08 UTC (permalink / raw)
To: Emmanuel Grumbach
Cc: Oliver Hartkopp, Vadim Kochan, John W. Linville, linux-wireless,
netdev@vger.kernel.org
In-Reply-To: <CANUX_P3kOetqEneHgqoCDN4c85SQYD-G=mQj_o1c_TvKmE5psA@mail.gmail.com>
Emmanuel Grumbach <egrumbach@gmail.com> writes:
> On Wed, Sep 10, 2014 at 8:01 AM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>> On 10.09.2014 00:07, Vadim Kochan wrote:
>>> I have the same issue with iwlwifi.
>>
>> I tried an old zd1211 wireless USB stick to check if this problem is 80211
>> related. But the USB stick works fine (I'm using it right now).
>> So its definitely looks like an iwlwifi issue.
>>
>>> iwlwifi 0000:02:00.0: fail to flush all tx fifo queues Q 0
>>
>> Wasn't there any change in the iwlwifi tx path recently??
>
> Can you please try the patch attached? It works for me.
Upgraded to latest wireless-testing and iwldvm was broken. This patch
fixed it for me as well.
Could we have the fix in the wireless tree ASAP? Not really fun to find
out that the driver is completely broken.
--
Kalle Valo
^ permalink raw reply
* [PATCH] net: ethernet: neterion: vxge: vxge-main.c: Cleaning up missing null-terminate in conjunction with strncpy
From: Rickard Strandqvist @ 2014-09-14 17:34 UTC (permalink / raw)
To: Jon Mason, David S. Miller
Cc: Rickard Strandqvist, Eric W. Biederman, Jingoo Han,
Alexander Gordeev, Benoit Taine, Manuel Schölling,
Ben Hutchings, John Stultz, Christian Engelmayer, netdev,
linux-kernel
Replacing strncpy with strlcpy to avoid strings that lacks null terminate.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
drivers/net/ethernet/neterion/vxge/vxge-main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/neterion/vxge/vxge-main.c b/drivers/net/ethernet/neterion/vxge/vxge-main.c
index 4f40d7b..cc0485e 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-main.c
+++ b/drivers/net/ethernet/neterion/vxge/vxge-main.c
@@ -3537,7 +3537,7 @@ static void vxge_device_unregister(struct __vxge_hw_device *hldev)
vxge_debug_entryexit(vdev->level_trace, "%s: %s:%d", vdev->ndev->name,
__func__, __LINE__);
- strncpy(buf, dev->name, IFNAMSIZ);
+ strlcpy(buf, dev->name, IFNAMSIZ);
flush_work(&vdev->reset_task);
--
1.7.10.4
^ permalink raw reply related
* [PATCH] net: ethernet: marvell: sky2.c: Cleaning up missing null-terminate in conjunction with strncpy
From: Rickard Strandqvist @ 2014-09-14 17:33 UTC (permalink / raw)
To: Mirko Lindner, Stephen Hemminger
Cc: Rickard Strandqvist, netdev, linux-kernel
Replacing strncpy with strlcpy to avoid strings that lacks null terminate.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
drivers/net/ethernet/marvell/sky2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/sky2.c b/drivers/net/ethernet/marvell/sky2.c
index dba48a5c..7053d38 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -4907,7 +4907,7 @@ static const char *sky2_name(u8 chipid, char *buf, int sz)
};
if (chipid >= CHIP_ID_YUKON_XL && chipid <= CHIP_ID_YUKON_OP_2)
- strncpy(buf, name[chipid - CHIP_ID_YUKON_XL], sz);
+ strlcpy(buf, name[chipid - CHIP_ID_YUKON_XL], sz);
else
snprintf(buf, sz, "(chip %#x)", chipid);
return buf;
--
1.7.10.4
^ permalink raw reply related
* [PATCH] net: ethernet: freescale: fec_main.c: Cleaning up missing null-terminate in conjunction with strncpy
From: Rickard Strandqvist @ 2014-09-14 17:32 UTC (permalink / raw)
To: Grant Likely, Rob Herring
Cc: Rickard Strandqvist, David S. Miller, Nimrod Andy, Russell King,
Fabio Estevam, Frank Li, Uwe Kleine-König,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Replacing strncpy with strlcpy to avoid strings that lacks null terminate.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist-IW2WV5XWFqGZkjO+N0TKoMugMpMbD5Xr@public.gmane.org>
---
drivers/net/ethernet/freescale/fec_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 89355a7..e84b132 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1674,13 +1674,13 @@ static int fec_enet_mii_probe(struct net_device *ndev)
continue;
if (dev_id--)
continue;
- strncpy(mdio_bus_id, fep->mii_bus->id, MII_BUS_ID_SIZE);
+ strlcpy(mdio_bus_id, fep->mii_bus->id, MII_BUS_ID_SIZE);
break;
}
if (phy_id >= PHY_MAX_ADDR) {
netdev_info(ndev, "no PHY, assuming direct connection to switch\n");
- strncpy(mdio_bus_id, "fixed-0", MII_BUS_ID_SIZE);
+ strlcpy(mdio_bus_id, "fixed-0", MII_BUS_ID_SIZE);
phy_id = 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 related
* [PATCH] net: can: usb: peak_usb: pcan_usb_core.c: Cleaning up missing null-terminate in conjunction with strncpy
From: Rickard Strandqvist @ 2014-09-14 17:31 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde
Cc: Rickard Strandqvist, Oliver Hartkopp, Stephane Grosjean,
Alexey Khoroshilov, Christopher R. Baker, linux-can, netdev,
linux-kernel
Replacing strncpy with strlcpy to avoid strings that lacks null terminate.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
index 644e6ab..d4fe8ac 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
@@ -830,7 +830,7 @@ static void peak_usb_disconnect(struct usb_interface *intf)
char name[IFNAMSIZ];
dev->state &= ~PCAN_USB_STATE_CONNECTED;
- strncpy(name, netdev->name, IFNAMSIZ);
+ strlcpy(name, netdev->name, IFNAMSIZ);
unregister_netdev(netdev);
free_candev(netdev);
--
1.7.10.4
^ permalink raw reply related
* [PATCH] net: can: sja1000: peak_pcmcia.c: Cleaning up missing null-terminate in conjunction with strncpy
From: Rickard Strandqvist @ 2014-09-14 17:30 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde
Cc: Rickard Strandqvist, Christopher R. Baker, linux-can, netdev,
linux-kernel
Replacing strncpy with strlcpy to avoid strings that lacks null terminate.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
drivers/net/can/sja1000/peak_pcmcia.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/sja1000/peak_pcmcia.c b/drivers/net/can/sja1000/peak_pcmcia.c
index dd56133..fc9f8b01 100644
--- a/drivers/net/can/sja1000/peak_pcmcia.c
+++ b/drivers/net/can/sja1000/peak_pcmcia.c
@@ -487,7 +487,7 @@ static void pcan_free_channels(struct pcan_pccard *card)
if (!netdev)
continue;
- strncpy(name, netdev->name, IFNAMSIZ);
+ strlcpy(name, netdev->name, IFNAMSIZ);
unregister_sja1000dev(netdev);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCHv3 net-next 1/3] sunvnet: upgrade to VIO protocol version 1.6
From: Raghuram Kothakota @ 2014-09-14 17:21 UTC (permalink / raw)
To: David L Stevens; +Cc: David Miller, netdev
In-Reply-To: <541583E0.7050504@oracle.com>
The following is a highlevel view of what we have in LDoms virtual network
infrastructure.
1. The vio protocol version number to introduce new messages and/or
changes to the existing messages.
In the past there may be a case or two where the version number is
assumed as a capability, an example is the version 1.3.
2. Flexibility to negotiate or enable individual feature/enhancement. That
is attribute negotiation includes the ability for each peer to negotiate
any specific feature/enhancement independently of the others.
An example of this are, physical link state updates(that you pointed out),
mtu, LSO support, dring mode(TX_DRING or RX_DRING_DATA) etc.
3. Properties in MD(machine description) as way to set or enable these features
for a Guest. This typically involves an administrative command.
For example, an administrator can enable/disable the behavior of physical
linkstate. The vlan-ids and mtu are also part of the administrative commands.
4. Finally the OS version(and/or patches) that is installed in a guest.
Without the OS/driver support, an administrator settings may not work.
Most of the controls revolve around the service domain, we use a new framework
in place for administrative commands to check if the given service domain
has the required support to enforce a specific option. In case of Guest domains,
it's just to the Guest to enable/disable or implement a feature.
Please below for my response.
On Sep 14, 2014, at 5:02 AM, David L Stevens <david.stevens@oracle.com> wrote:
>
>
> On 09/13/2014 11:30 PM, Raghuram Kothakota wrote:
>> I have a question around bumping the sunvnet vio_version to 1.6.
>> Each of the versions from 1.0, have a specific feature or behavior defined in the
>> protocol, if a given version is negotiated then peers will assume the Guest
>> can handle all those feature/enhancement automatically. If a given feature
>> is not supported or implemented, it may be best to handle those cases gracefully.
>
> It doesn't (and shouldn't) assume it supports any feature that isn't negotiated, and
> the code I submitted does not support or negotiate receive rings, for example. It
> therefore does not set the bit. The VIO protocol can negotiate TSO,
> which is not supported on Linux, so it doesn't set VNET_LSO_IPV4_CAPAB. And,
> as in your example, we don't want physical link state updates, so we use
> PHYSLINK_UPDATE_NONE (==0).
>
> I implemented from the VIO protocol spec and verified interoperability by testing
> with pre-patched Linux (VIO v1.0) and Solaris 11.1 and 11.2.
Thanks, if you have verified these cases then it addresses my comment.
In the code, it will be good to explicitly set the attribute such as "plnk_updt" to
the PHYSLINK_UPDATE_NONE and probably add a comment on top of
it would be even better. The same could be done for the other attribute as
well.
>
>> For example, if version 1.3 or higher is negotiated, then Guest is assumed to
>> support vlan packet processing.
>
> Nobody should *assume* VLAN support is there based on the VIO protocol version. v1.3
> and higher require from the driver that there be space for a vlan header, which I have
> added in the patch. I did not do anything else with VLAN processing, because this is
> not a patch to add VLAN support, and nothing requires Solaris to enable it. It is no
> different with respect to VLAN support than it was before the patch, meaning that if
> an admin tries to use a feature that isn't supported on all the machines, it won't
> work, just as it wouldn't work pre-patch to enable VLAN on Solaris and try to use it
> with Linux over sunvnet. The patch is to update the VIO protocol, which is the layout
> and semantics of the fields. It is not to support every feature that can be negotiated
> within the protocol.
That's fine. My point was about we have verified each of these
minor version specifics are thought and the behavior is understood.
-Raghuram
>
> +-DLS
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] isdn: act2000: capi.c: Cleaning up unnecessary use of memset in conjunction with strncpy
From: Rickard Strandqvist @ 2014-09-14 16:13 UTC (permalink / raw)
To: Karsten Keil, Rickard Strandqvist
Cc: Network Development, linux-kernel@vger.kernel.org
In-Reply-To: <1410710471-14341-1-git-send-email-rickard_strandqvist@spectrumdigital.se>
2014-09-14 18:01 GMT+02:00 Rickard Strandqvist
<rickard_strandqvist@spectrumdigital.se>:
> Using memset before strncpy just to ensure a trailing null
> character is an unnecessary double writing of a string
>
> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
> ---
> drivers/isdn/act2000/capi.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/isdn/act2000/capi.c b/drivers/isdn/act2000/capi.c
> index 3f66ca2..1267739 100644
> --- a/drivers/isdn/act2000/capi.c
> +++ b/drivers/isdn/act2000/capi.c
> @@ -907,10 +907,10 @@ actcapi_dispatch(struct work_struct *work)
> case 0xff02:
> /* MANUFACTURER_IND */
> if (msg->msg.manuf_msg == 3) {
> - memset(tmp, 0, sizeof(tmp));
> strncpy(tmp,
> &msg->msg.manufacturer_ind_err.errstring,
> - msg->hdr.len - 16);
> + sizeof(tmp));
> + tmp[sizeof(tmp) - 1] = '\0';
> if (msg->msg.manufacturer_ind_err.errcode)
> printk(KERN_WARNING "act2000: %s\n", tmp);
> else {
> @@ -1136,9 +1136,9 @@ actcapi_debug_msg(struct sk_buff *skb, int direction)
> msg->msg.manufacturer_ind_err.controller);
> printk(KERN_DEBUG " Code = 0x%08x\n",
> msg->msg.manufacturer_ind_err.errcode);
> - memset(tmp, 0, sizeof(tmp));
> strncpy(tmp, &msg->msg.manufacturer_ind_err.errstring,
> - msg->hdr.len - 16);
> + sizeof(tmp));
> + tmp[sizeof(tmp) - 1] = '\0';
> printk(KERN_DEBUG " Emsg = '%s'\n", tmp);
> break;
> }
> --
> 1.7.10.4
>
Hi
I'm sorry, this will not give the same effect :-(
Please, ignore this patch!
Kind regards
Rickard Strandqvist
^ permalink raw reply
* [PATCH] isdn: act2000: capi.c: Cleaning up unnecessary use of memset in conjunction with strncpy
From: Rickard Strandqvist @ 2014-09-14 16:01 UTC (permalink / raw)
To: Karsten Keil, Rickard Strandqvist; +Cc: netdev, linux-kernel
Using memset before strncpy just to ensure a trailing null
character is an unnecessary double writing of a string
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
drivers/isdn/act2000/capi.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/isdn/act2000/capi.c b/drivers/isdn/act2000/capi.c
index 3f66ca2..1267739 100644
--- a/drivers/isdn/act2000/capi.c
+++ b/drivers/isdn/act2000/capi.c
@@ -907,10 +907,10 @@ actcapi_dispatch(struct work_struct *work)
case 0xff02:
/* MANUFACTURER_IND */
if (msg->msg.manuf_msg == 3) {
- memset(tmp, 0, sizeof(tmp));
strncpy(tmp,
&msg->msg.manufacturer_ind_err.errstring,
- msg->hdr.len - 16);
+ sizeof(tmp));
+ tmp[sizeof(tmp) - 1] = '\0';
if (msg->msg.manufacturer_ind_err.errcode)
printk(KERN_WARNING "act2000: %s\n", tmp);
else {
@@ -1136,9 +1136,9 @@ actcapi_debug_msg(struct sk_buff *skb, int direction)
msg->msg.manufacturer_ind_err.controller);
printk(KERN_DEBUG " Code = 0x%08x\n",
msg->msg.manufacturer_ind_err.errcode);
- memset(tmp, 0, sizeof(tmp));
strncpy(tmp, &msg->msg.manufacturer_ind_err.errstring,
- msg->hdr.len - 16);
+ sizeof(tmp));
+ tmp[sizeof(tmp) - 1] = '\0';
printk(KERN_DEBUG " Emsg = '%s'\n", tmp);
break;
}
--
1.7.10.4
^ permalink raw reply related
* DSA and skb->protocol
From: Andrew Lunn @ 2014-09-14 15:37 UTC (permalink / raw)
To: f.fainelli; +Cc: seugene, Andrew Lunn, netdev
Hi Florian
I've been debugging a WARNING when using DSA with a D-Link
DIR665. I've had reports of the same warning with another device.
WARNING: CPU: 0 PID: 2014 at net/core/dev.c:2260 skb_warn_bad_offload+0xd0/0x104()
mv643xx_eth_port: caps=(0x0000000400014803, 0x00000000001b482b) len=1722 data_len=16 gso_size=1448 gso_type=1 gso_segs 2 ip_summed=3 encapsulation 0 features 400014801
Modules linked in:
CPU: 0 PID: 2014 Comm: sshd Tainted: G W 3.17.0-rc1-00007-g2f06b2c08099-dirty #228
[<c000e2a0>] (unwind_backtrace) from [<c000bd88>] (show_stack+0x10/0x14)
[<c000bd88>] (show_stack) from [<c0016db8>] (warn_slowpath_common+0x6c/0x8c)
[<c0016db8>] (warn_slowpath_common) from [<c0016e08>] (warn_slowpath_fmt+0x30/0x40)
[<c0016e08>] (warn_slowpath_fmt) from [<c04ebad4>] (skb_warn_bad_offload+0xd0/0x104)
[<c04ebad4>] (skb_warn_bad_offload) from [<c03eea5c>] (skb_checksum_help+0x160/0x170)
[<c03eea5c>] (skb_checksum_help) from [<c03eef40>] (dev_hard_start_xmit+0x3f8/0x4c0)
[<c03eef40>] (dev_hard_start_xmit) from [<c04071ec>] (sch_direct_xmit+0x148/0x250)
[<c04071ec>] (sch_direct_xmit) from [<c03ef280>] (__dev_queue_xmit+0x278/0x5f4)
[<c03ef280>] (__dev_queue_xmit) from [<c04719b8>] (edsa_xmit+0xf8/0x2c8)
[<c04719b8>] (edsa_xmit) from [<c03eee24>] (dev_hard_start_xmit+0x2dc/0x4c0)
[<c03eee24>] (dev_hard_start_xmit) from [<c03ef3cc>] (__dev_queue_xmit+0x3c4/0x5f4)
[<c03ef3cc>] (__dev_queue_xmit) from [<c0415e88>] (ip_finish_output+0x64c/0x920)
[<c0415e88>] (ip_finish_output) from [<c0416e2c>] (ip_local_out_sk+0x34/0x38)
[<c0416e2c>] (ip_local_out_sk) from [<c0417144>] (ip_queue_xmit+0x128/0x388)
[<c0417144>] (ip_queue_xmit) from [<c042caa8>] (tcp_transmit_skb+0x534/0x93c)
[<c042caa8>] (tcp_transmit_skb) from [<c042cff8>] (tcp_write_xmit+0x148/0xbf8)
[<c042cff8>] (tcp_write_xmit) from [<c042dd7c>] (__tcp_push_pending_frames+0x30/0x9c)
[<c042dd7c>] (__tcp_push_pending_frames) from [<c041fbc8>] (tcp_sendmsg+0xc0/0xcec)
[<c041fbc8>] (tcp_sendmsg) from [<c0445710>] (inet_sendmsg+0x3c/0x70)
[<c0445710>] (inet_sendmsg) from [<c03d7d5c>] (sock_aio_write+0xcc/0xec)
[<c03d7d5c>] (sock_aio_write) from [<c00bb218>] (do_sync_write+0x7c/0xa4)
[<c00bb218>] (do_sync_write) from [<c00bbc40>] (vfs_write+0x108/0x1b0)
[<c00bbc40>] (vfs_write) from [<c00bc214>] (SyS_write+0x40/0x94)
[<c00bc214>] (SyS_write) from [<c0009480>] (ret_fast_syscall+0x0/0x2c)
---[ end trace b1b02d15aba4766a ]---
I think i understand what is going on, and one of your recent patches
may indicate you have seen something similar.
int dev_hard_start_xmit() we have:
2607
2608 features = netif_skb_features(skb);
...
2637 /* If packet is not checksummed and device does not
2638 * support checksumming for this protocol, complete
2639 * checksumming here.
2640 */
2641 if (skb->ip_summed == CHECKSUM_PARTIAL) {
2642 if (skb->encapsulation)
2643 skb_set_inner_transport_header(skb,
2644 skb_checksum_start_offset(skb));
2645 else
2646 skb_set_transport_header(skb,
2647 skb_checksum_start_offset(skb));
2648 if (!(features & NETIF_F_ALL_CSUM) &&
2649 skb_checksum_help(skb))
2650 goto out_kfree_skb;
2651 }
This packet is CHECKSUM_PARTIAL, but it is also a GSO packet, with two
segments, so the skb_checksum_help() is throwing the warning. It is
expected that the hardware with do the checksum when using GSO. The
reason it is trying to do software checksums, not hardware, is because
features does not indicate the protocol is supported by hardware
checksumming. This i initially thought was odd, since this is a TCP/IP
packet, as you can see from the stack trace. However,
netif_skb_features(skb) calls harmonize_features() which calls
can_checksum_protocol():
3206 static inline bool can_checksum_protocol(netdev_features_t features,
3207 __be16 protocol)
3208 {
3209 return ((features & NETIF_F_GEN_CSUM) ||
3210 ((features & NETIF_F_V4_CSUM) &&
3211 protocol == htons(ETH_P_IP)) ||
3212 ((features & NETIF_F_V6_CSUM) &&
3213 protocol == htons(ETH_P_IPV6)) ||
3214 ((features & NETIF_F_FCOE_CRC) &&
3215 protocol == htons(ETH_P_FCOE)));
3216 }
However looking in the skb, we see protocol is now ETH_P_EDSA, not
ETH_P_IP. Hence the hardware does not support this protocol.
This protocol value is because edsa_xmit() changes it in the slave
device TX path.
Your patch "net: dsa: change tag_protocol to an enum"
has a hunk:
diff --git a/net/dsa/tag_brcm.c b/net/dsa/tag_brcm.c
index e0b759ec209e..8fbc21c0de78 100644
--- a/net/dsa/tag_brcm.c
+++ b/net/dsa/tag_brcm.c
@@ -91,7 +91,6 @@ static netdev_tx_t brcm_tag_xmit(struct sk_buff *skb, struct net_device *dev)
/* Queue the SKB for transmission on the parent interface, but
* do not modify its EtherType
*/
- skb->protocol = htons(ETH_P_BRCMTAG);
skb->dev = p->parent->dst->master_netdev;
dev_queue_xmit(skb);
making me think it is not actually needed to change
skb->protocol. When i remove this from edsa_xmit(), the warning goes
away and networking seems to work O.K.
Is this the right fix? Should we remove this setting of skb->protocol
in the other dsa xmit functions?
Thanks
Andrew
^ permalink raw reply related
* Re: [Bridge] [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge
From: Toshiaki Makita @ 2014-09-14 15:39 UTC (permalink / raw)
To: Vladislav Yasevich, netdev; +Cc: Vladislav Yasevich, shemminger, bridge
In-Reply-To: <1410554691-18467-4-git-send-email-vyasevic@redhat.com>
(14/09/13 (土) 5:44), Vladislav Yasevich wrote:
> If the user configures vlan devices on top of the bridge,
> automatically set up filter entries for it as long as
> bridge vlan protocol matches that of the vlan.
> This allows the user to atomatically receive vlan traffic
> for the vlans that are convifgured.
Changing br->vlan_proto seems to cause inconsistency between vlan
interfaces and filter settings.
Can we automatically change filters when setting vlan_proto?
>
...
> +static int br_vlan_rx_kill_vid(struct net_device *br_dev,
> + __be16 proto, u16 vid)
...
> + /* Don't report error. This will fail if the vlan was
> + * previousely remove by some other means and we don't
> + * wan't to polute the log/bug the user.
> + */
> + br_vlan_delete(br, vid);
> + return 0;
> +}
It might lead to unexpected behaviour, for example,
1. create br0.10
2. set pvid to 10 on br0
3. delete br0.10
Then, pvid will also be cleared?
Something like ref counting is needed?
Thanks,
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH 2/3] bridge: Add filtering support for default_pvid
From: Toshiaki Makita @ 2014-09-14 15:21 UTC (permalink / raw)
To: Vladislav Yasevich, netdev; +Cc: Vladislav Yasevich, shemminger, bridge
In-Reply-To: <1410554691-18467-3-git-send-email-vyasevic@redhat.com>
(14/09/13 (土) 5:44), Vladislav Yasevich wrote:
> Currently when vlan filtering is turned on on the bridge, the bridge
> will drop all traffic untill the user configures the filter. This
> isn't very nice for ports that don't care about vlans and just
> want untagged traffic.
>
> A concept of a default_pvid was recently introduced. This patch
> adds filtering support for default_pvid. Now, ports that don't
> care about vlans and don't define there own filter will belong
> to the VLAN of the default_pvid and continue to receive untagged
> traffic.
If user sets pvid, then vid 1 (default_pvid) will become non-pvid but
still not be filtered, right?
vlan_bitmap of default_pvid shouldn't be cleared on setting pvid?
Thanks,
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH 1/2] bridge: Check if vlan filtering is enabled only once.
From: Toshiaki Makita @ 2014-09-14 14:43 UTC (permalink / raw)
To: Vladislav Yasevich, netdev
Cc: shemminger, Toshiaki Makita, Vladislav Yasevich
In-Reply-To: <1410553577-17519-2-git-send-email-vyasevic@redhat.com>
(14/09/13 (土) 5:26), Vladislav Yasevich wrote:
> The bridge code checks if vlan filtering is enabled on both
> ingress and egress. When the state flip happens, it
> is possible for the bridge to currently be forwarding packets
> and forwarding behavior becomes non-deterministic. Bridge
> may drop packets on some interfaces, but not others.
>
> This patch solves this by caching the filtered state of the
> packet into skb_cb on ingress. The skb_cb is guaranteed to
> not be over-written between the time packet entres bridge
> forwarding path and the time it leaves it. On egress, we
> can then check the cached state to see if we need to
> apply filtering information.
...
> @@ -270,7 +275,8 @@ bool br_should_learn(struct net_bridge_port *p, struct sk_buff *skb, u16 *vid)
> struct net_bridge *br = p->br;
> struct net_port_vlans *v;
>
> - if (!br->vlan_enabled)
> + /* If filtering was disabled at input, let it pass. */
> + if (!BR_INPUT_SKB_CB(skb)->vlan_filtered)
> return true;
>
> v = rcu_dereference(p->vlan_info);
>
I'm afraid br_should_learn() is not called after calling
br_allowed_ingress(), so vlan_filtered doesn't seem to be initialized at
this point.
Thanks,
Toshiaki Makita
^ permalink raw reply
* Re: [PATCHv3 net-next 2/3] sunvnet: allow admin to set sunvnet MTU
From: David L Stevens @ 2014-09-14 13:24 UTC (permalink / raw)
To: sowmini.varadhan, David Miller; +Cc: netdev
In-Reply-To: <54158835.8000508@oracle.com>
On 09/14/2014 08:21 AM, Sowmini Varadhan wrote:
> To put things in perspective, in practice its only legacy linux today that will do the v1.0, and administrators are likely to want to upgrade
> to the later version, so encumbering the code with legacy version support may end up becoming hard-to-maintain code?
No, v1.8 Solaris would force us to a 1/3 drop in performance between linux LDOMs because of its 16000 byte MTU limit.
I don't think it's particularly hard to maintain -- it's virtually a literal translation of the text in the VIO protocol
document. Everything that's there should stay there; only new revisions of the protocol would cause new changes, presumably
in other areas of the code where those new features are implemented. And I don't think reverse compatibility is optional.
> As I understand it, this method of sending ICMP from the driver will not
> work for L2 (non-IP) packets, and it will not even work for IP packets that are coming to us, from, say, openvswitch, right? So in practice it
> actually has limited usability?
It wouldn't work for a bridged L2 network with no local IP address, because there would be no valid return IP address for the
ICMP error we generate (in IPv4 -- IPv6 will always have a valid link-local address). Everything else, including openvswitch as far
as I can tell, should make use of the standard pmtud routing information that these update.
What I come back to, as before, is the simple notion that nothing forces an administrator to the otherwise unusual circumstance
of setting different MTUs on directly-attached common networks. If you want to bridge L2 traffic, make your MTU 1500 and it'll
work exactly as before. If you, instead, are using IPv4 or IPv6 and ordinary routed traffic, you can have 8X performance improvement
between hosts that can support it, even if other hosts on the same vswitch and outside your control cannot. You can talk to all
hosts on the vswitch, with a performance that matches the capabilities of each peer. I don't see any way that's not better.
+-DLS
^ permalink raw reply
* Re: [PATCHv3 net-next 2/3] sunvnet: allow admin to set sunvnet MTU
From: Sowmini Varadhan @ 2014-09-14 12:21 UTC (permalink / raw)
To: David L Stevens, David Miller; +Cc: netdev
In-Reply-To: <5414FA4D.6030504@oracle.com>
On 09/13/2014 10:15 PM, David L Stevens wrote:
> I wouldn't say I like it, either, but the problem is that without it, we
> are tied to the least common denominator. Anything that doesn't support
> v1.6 of the VIO protocol is stuck at the low MTU and low throughput, and
To put things in perspective, in practice its only legacy linux today
that will do the v1.0, and administrators are likely to want to upgrade
to the later version, so encumbering the code with legacy version
support may end up becoming hard-to-maintain code?
> I think of it as an Ethernet connected to a virtual switch, and the ICMP
> errors are for PMTUD are analogous to IGMP snooping. This is not an Ethernet
> device alone-- those don't negotiate per-destination link MTUs. But nothing forces
> anyone to mix MTUs; the ICMP errors simply allow it.
As I understand it, this method of sending ICMP from the driver will not
work for L2 (non-IP) packets, and it will not even work for IP packets
that are coming to us, from, say, openvswitch, right? So in practice it
actually has limited usability?
--Sowmini
^ permalink raw reply
* Re: [PATCHv3 net-next 1/3] sunvnet: upgrade to VIO protocol version 1.6
From: David L Stevens @ 2014-09-14 12:02 UTC (permalink / raw)
To: Raghuram Kothakota; +Cc: David Miller, netdev
In-Reply-To: <028736E5-2648-4642-881C-25BBC6E7C848@oracle.com>
On 09/13/2014 11:30 PM, Raghuram Kothakota wrote:
> I have a question around bumping the sunvnet vio_version to 1.6.
> Each of the versions from 1.0, have a specific feature or behavior defined in the
> protocol, if a given version is negotiated then peers will assume the Guest
> can handle all those feature/enhancement automatically. If a given feature
> is not supported or implemented, it may be best to handle those cases gracefully.
It doesn't (and shouldn't) assume it supports any feature that isn't negotiated, and
the code I submitted does not support or negotiate receive rings, for example. It
therefore does not set the bit. The VIO protocol can negotiate TSO,
which is not supported on Linux, so it doesn't set VNET_LSO_IPV4_CAPAB. And,
as in your example, we don't want physical link state updates, so we use
PHYSLINK_UPDATE_NONE (==0).
I implemented from the VIO protocol spec and verified interoperability by testing
with pre-patched Linux (VIO v1.0) and Solaris 11.1 and 11.2.
> For example, if version 1.3 or higher is negotiated, then Guest is assumed to
> support vlan packet processing.
Nobody should *assume* VLAN support is there based on the VIO protocol version. v1.3
and higher require from the driver that there be space for a vlan header, which I have
added in the patch. I did not do anything else with VLAN processing, because this is
not a patch to add VLAN support, and nothing requires Solaris to enable it. It is no
different with respect to VLAN support than it was before the patch, meaning that if
an admin tries to use a feature that isn't supported on all the machines, it won't
work, just as it wouldn't work pre-patch to enable VLAN on Solaris and try to use it
with Linux over sunvnet. The patch is to update the VIO protocol, which is the layout
and semantics of the fields. It is not to support every feature that can be negotiated
within the protocol.
+-DLS
^ permalink raw reply
* Re
From: Mrs Ana Rita @ 2014-09-14 10:54 UTC (permalink / raw)
I HAVE A PROJECT TO TRANSACT WITH YOU IF INTERESTED REPY TO EMAIL :
ana.rita.gashkova@7mt.org
^ permalink raw reply
* Jeg skal bruge dine HASTER RESPOND
From: Mr chin sang @ 2014-09-13 11:22 UTC (permalink / raw)
Jeg skal bruge dine HASTER RESPOND
Jeg bruger dette medie til at informere dig om transaktionen for
overførsel på $ 21500000 (Twenty-en million fem hundrede tusinde dollars)
i min bank i Kina
til dig som modtager. Det vil være 100% sikker, er den finansielle officer
af den afdøde kunden.
Kontakt venligst på min private e-mail nedenfor for eventuelle
spørgsmål og yderligere information.
Med venlig hilsen
sang Chin
e-post: chinsang411@gmail.com
^ permalink raw reply
* Re: [PATCH] net: axienet: remove unnecessary ether_setup after alloc_etherdev
From: sundeep subbaraya @ 2014-09-14 8:30 UTC (permalink / raw)
To: David Miller
Cc: Subbaraya Sundeep Bhatta, jeffrey.t.kirsher, jesse.brandeburg,
netdev, linux-kernel@vger.kernel.org, Michal Simek, svemula,
anirudh, Subbaraya Sundeep Bhatta
In-Reply-To: <20140912.181605.1878319812562851527.davem@davemloft.net>
Thanks David,
Sundeep.
On Sat, Sep 13, 2014 at 3:46 AM, David Miller <davem@davemloft.net> wrote:
> From: Subbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@xilinx.com>
> Date: Thu, 11 Sep 2014 14:53:33 +0530
>
>> calling ether_setup is redundant since alloc_etherdev calls
>> it.
>>
>> Signed-off-by: Subbaraya Sundeep Bhatta <sbhatta@xilinx.com>
>
> Applied.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 0/4 linux-next] drivers/net: use container_of where possible
From: Arend van Spriel @ 2014-09-14 7:32 UTC (permalink / raw)
To: Fabian Frederick
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w
In-Reply-To: <1410640709-18295-1-git-send-email-fabf-AgBVmzD5pcezQB+pC5nmwQ@public.gmane.org>
On 09/13/14 22:38, Fabian Frederick wrote:
> Small patchset using container_of instead of casting on first structure member address.
Hi Fabian,
I think you need to split up this series. One for the ethernet drivers
and one for the wireless driver. As there is not dependency between the
patches they can each go through their own subsystem git tree. Generally
I tend to submit patches to the subsystem maintainer and Cc the
appropriate mailing lists.
Regarding the patches for brcmsmac, you can add
Acked-by: Arend van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Regards,
Arend
> Fabian Frederick (4):
> net: fec: use container_of to resolve bufdesc_ex from bufdesc
> bna: use container_of to resolve bufdesc_ex from bufdesc
> brcm80211: use container_of to resolve brcms_phy from brcms_phy_pub
> brcm80211: use container_of to resolve dma_info from dma_pub
>
> drivers/net/ethernet/brocade/bna/bna_enet.c | 9 +-
> drivers/net/ethernet/brocade/bna/bna_tx_rx.c | 4 +-
> drivers/net/ethernet/freescale/fec_main.c | 4 +-
> drivers/net/wireless/brcm80211/brcmsmac/dma.c | 38 +++----
> .../net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c | 122 ++++++++++-----------
> .../net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c | 6 +-
> .../net/wireless/brcm80211/brcmsmac/phy/phy_n.c | 8 +-
> 7 files changed, 97 insertions(+), 94 deletions(-)
>
--
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: Rusty away 18th September -- 11th October
From: Michael S. Tsirkin @ 2014-09-14 6:21 UTC (permalink / raw)
To: Rusty Russell; +Cc: netdev, Linus Torvalds, LKML, virtualization
In-Reply-To: <87tx4dhbks.fsf@rustcorp.com.au>
On Fri, Sep 12, 2014 at 10:58:03AM +0930, Rusty Russell wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> > On Thu, Sep 11, 2014 at 10:26:52AM +0930, Rusty Russell wrote:
> >> Hi all,
> >>
> >> Probably won't read mail. Linus, I'll have pull requests early
> >> next week; if there's anything needed I'm sure Michael Tsirkin can
> >> handle it.
> >
> > Sure.
> > Rusty, there's a small chance virtio 1.0 bits will be ready in time.
> > I started working on them based on your virtio-pci-new-layout branch.
> >
> > If ready before the merge window, are you ok with me merging this
> > support (without you having the opportunity to review first)?
>
> Sorry, absolutely not. I *really* want to review this in depth; if we
> make a mistake, it's going to hurt us significantly.
Right but it's only a merge window - we can fix bugs and even disable
the new driver afterwards, can't we?
> And until we have the qemu bits ready, it's really hard to tell if we've
> got this right.
Sure, I meant if qemu bits are ready too, and if things work together.
It wouldn't do to merge a driver that isn't ready.
> So I'd rather delay and make sure we're solid.
>
> Thanks,
> Rusty.
Something else we can do, is refactoring that splits driver
out to common and legacy bits, and changes APIs.
No?
--
MSt
^ permalink raw reply
* [PATCH 1/1 v2] netdev: octeon_mgmt: ISO C90 forbids mixed declarations and code
From: Heinrich Schuchardt @ 2014-09-14 5:02 UTC (permalink / raw)
To: David Daney
Cc: David S. Miller, Luka Perkov, Willem de Bruijn, Russell King,
netdev, linux-kernel, Heinrich Schuchardt, Joe Perches
Revised patch takes into account comments by Joe and David.
Compiling with OCTEON_MGMT_ETHERNET gives a warning
drivers/net/ethernet/octeon/octeon_mgmt.c:295:4:
warning: ISO C90 forbids mixed declarations and code
[-Wdeclaration-after-statement]
The patch cleans up the code.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
CC: Joe Perches <joe@perches.com>
CC: David S. Miller <davem@davemloft.net>
---
drivers/net/ethernet/octeon/octeon_mgmt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/octeon/octeon_mgmt.c b/drivers/net/ethernet/octeon/octeon_mgmt.c
index 979c698..6cc68b1 100644
--- a/drivers/net/ethernet/octeon/octeon_mgmt.c
+++ b/drivers/net/ethernet/octeon/octeon_mgmt.c
@@ -290,9 +290,10 @@ static void octeon_mgmt_clean_tx_buffers(struct octeon_mgmt *p)
/* Read the hardware TX timestamp if one was recorded */
if (unlikely(re.s.tstamp)) {
struct skb_shared_hwtstamps ts;
+ u64 ns;
memset(&ts, 0, sizeof(ts));
/* Read the timestamp */
- u64 ns = cvmx_read_csr(CVMX_MIXX_TSTAMP(p->port));
+ ns = cvmx_read_csr(CVMX_MIXX_TSTAMP(p->port));
/* Remove the timestamp from the FIFO */
cvmx_write_csr(CVMX_MIXX_TSCTL(p->port), 0);
/* Tell the kernel about the timestamp */
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] Freeing dst when the reference count <0 causes general protection fault, it could be a major security flaw as rogue app can modify dst to crash kernel.
From: Eric Dumazet @ 2014-09-14 3:54 UTC (permalink / raw)
To: shakil A Khan; +Cc: netdev, linux-kernel, edumazet, davem
In-Reply-To: <1723887.mNMu0nmDbO@localhost.localdomain>
On Sat, 2014-09-13 at 11:35 -0700, shakil A Khan wrote:
> On Saturday, September 13, 2014 04:50:22 AM Eric Dumazet wrote:
> > On Sat, 2014-09-13 at 01:27 -0700, Shakil A Khan wrote:
> > > Signed-off-by: Shakil A Khan <shakilk1729@gmail.com>
> > > ---
> > >
> > > net/core/dst.c | 5 ++++-
> > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/net/core/dst.c b/net/core/dst.c
> > > index a028409..6a848b0 100644
> > > --- a/net/core/dst.c
> > > +++ b/net/core/dst.c
> > > @@ -284,7 +284,10 @@ void dst_release(struct dst_entry *dst)
> > >
> > > int newrefcnt;
> > >
> > > newrefcnt = atomic_dec_return(&dst->__refcnt);
> > >
> > > - WARN_ON(newrefcnt < 0);
> > > +
> > > + if (WARN(newrefcnt < 0, "dst reference count less than zero"))
> > > + return;
> > > +
> > >
> > > if (unlikely(dst->flags & DST_NOCACHE) && !newrefcnt)
> > >
> > > call_rcu(&dst->rcu_head, dst_destroy_rcu);
> > >
> > > }
> >
> > A rogue application can not do trigger this, unless a major bug in the
> > kernel exists.
>
> Please check this kernel trace. It is able to crash the kernel.
>
> general protection fault: 0000 [#1] PREEMPT SMP
> Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss oid_registry
> nfsv4 nfs fscache lockd sunrpc tun nbd ipmi_si ipmi_watchdog ipmi_devintf
> ipmi_msghandler xt_mark xt_owner ipt_MASQUERADE xt_physdev xt_state xt_LOG
> iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
> nf_conntrack iptable_filter ip_tables xen_acpi_processor xen_pciback
> xen_netback xen_blkback xen_gntalloc xen_gntdev xenfs xen_privcmd bridge stp
> llc ipv6 ext4 jbd2 freq_table mperf coretemp crc32c_intel ghash_clmulni_intel
> microcode pcspkr sb_edac edac_core lpc_ich mfd_core i2c_i801 sg ioatdma igb
> dca i2c_algo_bit i2c_core ptp pps_core ext3 jbd mbcache sd_mod crc_t10dif
> aesni_intel ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 ahci
> libahci isci libsas scsi_transport_sas megaraid_sas wmi dm_mirror
> dm_region_hash dm_log dm_mod [last unloaded: iTCO_vendor_support]
> CPU: 6 PID: 15324 Comm: XXXX Not tainted 3.10.45-xen.322.17.41238 #1
> Hardware name: McAfee, Inc. ATD-6000/S4600LH...., BIOS
> SE5C600.86B.02.01.0002.082220131453 08/22/2013
> task: ffff882bc6255000 ti: ffff882bc61aa000 task.ti: ffff882bc61aa000
> RIP: e030:[<ffffffff8148473f>] [<ffffffff8148473f>] ipv4_dst_destroy+0x3b/0x77
> RSP: e02b:ffff882bc61abb48 EFLAGS: 00010296
> RAX: dead000000200200 RBX: ffff882bc625bc80 RCX: 0001338a9b7110db
> RDX: dead000000100100 RSI: ffffffff82267e30 RDI: 00000000000003f4
> RBP: ffff882bc61abb58 R08: 00000000d5d6df8b R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffffffff820e5880 R14: ffff88070e584b80 R15: 0000000000000000
> FS: 00007f8d3fff2700(0000) GS:ffff88081e6c0000(0000) knlGS:0000000000000000
> CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000031d0e36ac0 CR3: 0000002db0165000 CR4: 0000000000042660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Stack:
> ffff882bc61abb58 ffff882bc625bc80 ffff882bc61abb88 ffffffff8145bfc5
> ffff882bc61abba8 ffff882bc625bc80 0000000000000000 ffff882bc625bc80
> ffff882bc61abba8 ffffffff8145c2c5 ffff88070e584b80 ffff882b991c2300
> Call Trace:
> [<ffffffff8145bfc5>] dst_destroy+0x29/0xbd
> [<ffffffff8145c2c5>] dst_release+0x58/0x67
> [<ffffffff814ad539>] tcp_v4_do_rcv+0x11b/0x287
> [<ffffffff81443e24>] __release_sock+0x7c/0xe7
> [<ffffffff81443ebd>] release_sock+0x2e/0x7c
> [<ffffffff81499cdf>] tcp_sendmsg+0xe0/0xd41
> [<ffffffff814bf369>] inet_sendmsg+0x7d/0xa0
> [<ffffffff8143d794>] sock_aio_write+0x159/0x17d
> [<ffffffff81005859>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
> [<ffffffff8116d12b>] do_sync_write+0x7f/0xa7
> [<ffffffff8116d392>] ? rw_verify_area+0x56/0xd5
> [<ffffffff8116d555>] vfs_write+0x144/0x170
> [<ffffffff8116d977>] SyS_write+0x54/0x8f
> [<ffffffff810d078f>] ? __audit_syscall_exit+0x20c/0x29c
> [<ffffffff8151e959>] system_call_fastpath+0x16/0x1b
> Code: fb 48 8d 87 b0 00 00 00 48 39 87 b0 00 00 00 74 4f 48 c7 c7 04 8f 3c 82
> e8 32 23 09 00 48 8b 93 b0 00 00 00 48 8b 83 b8 00 00 00 <48> 89 42 08 48 89
> 10 48 b9 00 01 10 00 00 00 ad de 48 89 8b b0
> RIP [<ffffffff8148473f>] ipv4_dst_destroy+0x3b/0x77
> RSP <ffff882bc61abb48>
> ---[ end trace d56f90482c47af91 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
>
>
> >
> > Instead of trying to hide the kernel bug, we need to fix it.
> There are two problems with this. First the list has somehow got out of
> sync in terms of number of delete and allocate, so we need to fix that.
> But at the same time refcount if <0 signifies its been already freed so we need
> not free up.
> We need fix for both and my patch targets later as my system works fine with
> this patch.
> >
> > Can you describe how this could trigger with a pristine kernel ?
> This is triggered with custom software to imitate malware traffic(Kernel was not
> having any custom patch whatsoever, it was a pristine kernel 3.10.45).
> Point is if an application can crash this, then it would be big security flaw
> not exactly similar but like SSL love bug, which can be exploited to bring
> down systems.
3.10.45 is old, you are a bit late, as we already spent a good amount of
time fixing all this about 3 months ago.
3.10.45 misses this fix :
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7f502361531e9eecb396cf99bdc9e9a59f7ebd7f
And this one :
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f88649721268999bdff09777847080a52004f691
And also :
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9709674e68646cee5a24e3000b3558d25412203a
All these should already be in 3.10.54
I suggest you try a 3.10.54 kernel. If it still crashes, then try a 3.16
kernel.
Then, we'll investigate, _if_ needed.
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