* Re: [PATCH] net: ethernet: marvell: sky2.c: Cleaning up missing null-terminate in conjunction with strncpy
From: Stephen Hemminger @ 2014-09-15 2:05 UTC (permalink / raw)
To: Rickard Strandqvist; +Cc: Mirko Lindner, netdev, linux-kernel
In-Reply-To: <1410716023-16068-1-git-send-email-rickard_strandqvist@spectrumdigital.se>
On Sun, 14 Sep 2014 19:33:43 +0200
Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> wrote:
> 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;
Useless and unnecessary since the list of names is right there.
Why not avoid the copy all together?
Subject: sky2: avoid strncpy
Don't use strncpy() since security thought police think it is bad.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/drivers/net/ethernet/marvell/sky2.c 2014-08-25 09:01:16.292060455 -0700
+++ b/drivers/net/ethernet/marvell/sky2.c 2014-09-14 19:02:26.731034094 -0700
@@ -4889,7 +4889,7 @@ static int sky2_test_msi(struct sky2_hw
}
/* This driver supports yukon2 chipset only */
-static const char *sky2_name(u8 chipid, char *buf, int sz)
+static const char *sky2_name(u8 chipid)
{
const char *name[] = {
"XL", /* 0xb3 */
@@ -4905,11 +4905,12 @@ static const char *sky2_name(u8 chipid,
"OptimaEEE", /* 0xbd */
"Optima 2", /* 0xbe */
};
+ static char buf[16];
if (chipid >= CHIP_ID_YUKON_XL && chipid <= CHIP_ID_YUKON_OP_2)
- strncpy(buf, name[chipid - CHIP_ID_YUKON_XL], sz);
- else
- snprintf(buf, sz, "(chip %#x)", chipid);
+ return name[chipid - CHIP_ID_YUKON_XL];
+
+ snprintf(buf, sizeof(buf), "(chip %#x)", chipid);
return buf;
}
@@ -4919,7 +4920,6 @@ static int sky2_probe(struct pci_dev *pd
struct sky2_hw *hw;
int err, using_dac = 0, wol_default;
u32 reg;
- char buf1[16];
err = pci_enable_device(pdev);
if (err) {
@@ -5014,7 +5014,7 @@ static int sky2_probe(struct pci_dev *pd
}
dev_info(&pdev->dev, "Yukon-2 %s chip revision %d\n",
- sky2_name(hw->chip_id, buf1, sizeof(buf1)), hw->chip_rev);
+ sky2_name(hw->chip_id), hw->chip_rev);
sky2_reset(hw);
^ permalink raw reply
* 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
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