* [cdc_ncm] kickstart
From: Enrico Mioso @ 2014-11-25 21:29 UTC (permalink / raw)
To: netdev, linux-usb; +Cc: alexxst, bjorn
Hi Bjorn,
Hi Alex.
So - I tried to read and understand parts of the logic implemented in the
cdc_ncm driver.
What I understood is:
- the device and the drive exchange "obviously" lots of infos about lengths and
so on
- lots of sanity checks all over the place
And the basic assumption that we are working inndp 16 mode.
So there is a lot of code to write - but not a lot of logic to change, right?
Or are there differences in 32 bit mode that might need attention? (behavioural
attention, math changes or anything)
So - first of all the tx and rx fixup functions should be changed,
reimplementing the needed code to let them work.
I was thinking to proceed this way, but I would like to have some comments
before moving on.
Note that all these line numbers refer to the cdc_ncm.c file in the current
kernel git tree as of today (Nov 25 at 22:27).
1 - Have a module parameter that inhibits the current forcing of 16 bit NTBs:
and check for it more or less at line 469 of cdc_ncm.c in function
cdc_ncm_init.
2 - Check somehow (how?) for the format we are using in .{rx,tx}_fixup
functions, and switch to two different distinct functions:
- one to handle 16 bits
- one to handle 32 bits
3 - Disambiguate some function names if needed: for example, cdc_ncm_ndp at
line 983 of the cdc_ncm.c file.
Please CC me and Alex, since (at least I) am not subscribed to the list. Any
hint or help would be greatly apreciated. Sorry for the long to / cc lists:
what's the appropriate list for these things?
Enrico
^ permalink raw reply
* Re: [PATCH rfc 1/4] net-timestamp: pull headers for SOCK_STREAM
From: Andy Lutomirski @ 2014-11-25 21:39 UTC (permalink / raw)
To: David Miller; +Cc: Willem de Bruijn, Network Development, Richard Cochran
In-Reply-To: <20141125.145434.1790615963499624322.davem@davemloft.net>
On Tue, Nov 25, 2014 at 11:54 AM, David Miller <davem@davemloft.net> wrote:
> From: Willem de Bruijn <willemb@google.com>
> Date: Tue, 25 Nov 2014 14:52:00 -0500
>
>> On Tue, Nov 25, 2014 at 1:42 PM, David Miller <davem@davemloft.net> wrote:
>>> From: Willem de Bruijn <willemb@google.com>
>>> Date: Tue, 25 Nov 2014 12:58:03 -0500
>>>
>>> What's the harm in exposing the headers? Either it's harmful, and
>>> therefore doing so for UDP is bad too, or it's harmless and
>>
>> Headers may expose information not available otherwise. I don't
>> immediately see critical problems, but that does not mean that they
>> might not lurk there.
>>
>> We so far avoid exposing the sequence number, though keeping it hidden
>> is more about third parties. More in general, unprivileged processes
>> may start requesting timestamps only to learn tcp state that they
>> should either get from tcpinfo or cannot currently get at all, likely
>> for good reason. A far-fetched example is identifying admin iptables
>> tos mangling rules by reading the tos bits at the driver layer. At least
>> on my machine, iptables -L is privileged.
>>
>>> we should probably leave it alone to not risk breaking anyone.
>>
>> That's fair. I sent it for rfc first for that reason. I won't resubmit
>> unless more serious concerns are raised.
>
> I just worry about the potential breakage.
>
> Your concerns are valid... I honestly don't know what we should do here.
> Both choices have merit.
Here's a scenario in which giving the headers might be dangerous:
Suppose I create a network namespace that's designed to contain
something, e.g. a Tor or Tor-like client, that shouldn't know any of
its public addressing information. I might assign something like a
tunnel interface to the namespace, but, if the contained code can get
lower-level headers, it might learn something that would identify the
*other* end of the tunnel, which wouldn't be so good. Admittedly,
this would be just one of several things that would require care to
get this right.
Also, what happens if the output is transformed by ipsec? Does the
timestamp message show the ciphertext?
TBH, I'd rather send no payload at all and have an scm message that
the sender provides that specifies a cookie identifying the particular
sent data. But that ship mostly sailed awhile ago.
For bytestreams, though, isn't this all new in 3.18? Or am I off by a release.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* Re: [patch net-next v3 04/17] net: introduce generic switch devices support
From: Thomas Graf @ 2014-11-25 21:54 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Jiri Pirko, netdev, davem, nhorman, andy, dborkman, ogerlitz,
jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, sfeldma, f.fainelli,
roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <5474B795.3080204@mojatatu.com>
On 11/25/14 at 12:08pm, Jamal Hadi Salim wrote:
> On 11/25/14 11:49, Jiri Pirko wrote:
>
> >
> >What does it do? "L3 switching"?
> >
>
> Absolutely not - that is too easy;-> Why not just a mellanox
> chip for that? (Testing if Aviad is awake). But flows and associated
> constructs apply.
It would definitely help if you could expose some more details on the
"some network processor" you have. We're all very eager ;-)
> I think this interface is usable for example to offload to user space
> ala DPDK and friends just as it would be for ASICs or standard NIC
> offload (which we already have with fdb offload).
> I dont know what a good name is - but switch looks incorrect.
I'm with Jiri but I agree it's not a perfect fit. I doubt there is but
if you can come up with something that fits better I'm open to it.
I considered "dataplane" or "dp" for a bit but it's quite generic as
well.
^ permalink raw reply
* [PATCH v2] net: Hyper-V: Deletion of an unnecessary check before the function call "vfree"
From: SF Markus Elfring @ 2014-11-25 21:55 UTC (permalink / raw)
To: David Miller, devel, netdev
Cc: Julia Lawall, Haiyang Zhang, kernel-janitors, linux-kernel
In-Reply-To: <20141121.151503.1986113223309494197.davem@davemloft.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Tue, 25 Nov 2014 22:33:45 +0100
The vfree() function performs also input parameter validation.
Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
drivers/net/hyperv/netvsc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 6b46311..6fc834e 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -561,9 +561,7 @@ int netvsc_device_remove(struct hv_device *device)
vmbus_close(device->channel);
/* Release all resources */
- if (net_device->sub_cb_buf)
- vfree(net_device->sub_cb_buf);
-
+ vfree(net_device->sub_cb_buf);
free_netvsc_device(net_device);
return 0;
}
--
2.1.3
^ permalink raw reply related
* Re: [patch net-next v3 07/17] rocker: introduce rocker switch driver
From: tgraf @ 2014-11-25 21:57 UTC (permalink / raw)
To: Scott Feldman
Cc: David Laight, Jiri Pirko, netdev@vger.kernel.org,
davem@davemloft.net, nhorman@tuxdriver.com, andy@greyhouse.net,
dborkman@redhat.com, ogerlitz@mellanox.com, jesse@nicira.com,
pshelar@nicira.com, azhou@nicira.com, ben@decadent.org.uk,
stephen@networkplumber.org, jeffrey.t.kirsher@intel.com,
vyasevic@redhat.com, xiyou.wangcong@gmail.com,
john.r.fastabend@intel.com, edumazet@google.com, jhs@mojatatu.com
In-Reply-To: <CAE4R7bC=jnq=OX2BNa9hpzbx8fpxHF+zGf1cV1ahP31htpE7kQ@mail.gmail.com>
On 11/25/14 at 09:19am, Scott Feldman wrote:
> On Tue, Nov 25, 2014 at 6:13 AM, David Laight <David.Laight@aculab.com> wrote:
> > From: Jiri Pirko
> >>
> >> This patch introduces the first driver to benefit from the switchdev
> >> infrastructure and to implement newly introduced switch ndos. This is a
> >> driver for emulated switch chip implemented in qemu:
> >> https://github.com/sfeldma/qemu-rocker/
> >
> > If this driver caller 'rocker' just to get the (bad) pun 'rocker switch'?
> > IMHO A more descriptive name would be a lot better.
>
> Sorry, it's the best we could do since qla3xxx and mlx4 and fm10k were
> already taken.
Given the amount of momentum rocker has created in the cause of
driving this API forward, I find the name quite appropriate.
^ permalink raw reply
* RESPOND FOR TRANSFSER DETAILS
From: Important Notice @ 2014-11-25 21:50 UTC (permalink / raw)
You have $250,000 lodged in Western Union to be transferred to you.
^ permalink raw reply
* Re: [PATCH] net/mlx4: Fix EEH recovery failure
From: Or Gerlitz @ 2014-11-25 22:00 UTC (permalink / raw)
To: Gavin Shan
Cc: Linux Netdev List, Amir Vadai, David Miller, Wei Yang,
Yishai Hadas, Jack Morgenstein
In-Reply-To: <20141124215555.GA6970@shangw>
On Mon, Nov 24, 2014 at 11:55 PM, Gavin Shan <gwshan@linux.vnet.ibm.com> wrote:
> On Mon, Nov 24, 2014 at 11:17:55PM +0200, Or Gerlitz wrote:
>>On Sat, Nov 22, 2014 at 12:56 PM, Gavin Shan <gwshan@linux.vnet.ibm.com> wrote:
>>> The patch fixes couple of EEH recovery failures on PPC PowerNV
>>> platform:
>>
>>> * Don't clear struct mlx4_priv instance in mlx4_pci_err_detected().
>>> Otherwise, __mlx4_init_one() runs into kernel crash because
>>> of dereferencing to NULL pointer.
>>
>>I don't see this change in the patch, I see no-clearing of mlx4_priv
>>in __mlx4_unload_one - please clarify, also is this patch
>>based/targeted on the net or net-next tree?
>>
>
> Yes, It would be: Don't clear struct mlx4_priv instance in mlx4_unload_one(),
> which is called by mlx4_pci_err_detected().
But the struct mlx4_priv instance is cleared in mlx4_unload_one() for
a reason, I suspect that you might made the EEH callback to work, but
broke something else... e.g did you made sure that kexec works after
your changes as it did before?
> It's based on 3.18.rc5, where I had couple of EEH fixes on top of it.
> When testing EEH with it, I hit the issue.
>>> With the patch applied, EEH recovery for mlx4 adapter succeeds on PPC
>>> PowerNV platform.
>>>
>>> # lspci
>>> 0003:0f:00.0 Network controller: Mellanox Technologies \
>>> MT27500 Family [ConnectX-3]
>>>
>>> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>>> ---
>>> drivers/net/ethernet/mellanox/mlx4/main.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
>>> index 90de6e1..e118ac9 100644
>>> --- a/drivers/net/ethernet/mellanox/mlx4/main.c
>>> +++ b/drivers/net/ethernet/mellanox/mlx4/main.c
>>> @@ -2809,7 +2809,6 @@ static void mlx4_unload_one(struct pci_dev *pdev)
>>> kfree(dev->caps.qp1_proxy);
>>> kfree(dev->dev_vfs);
>>>
>>> - memset(priv, 0, sizeof(*priv));
>>> priv->pci_dev_data = pci_dev_data;
>>> priv->removed = 1;
>>> }
>>> @@ -2900,6 +2899,8 @@ static pci_ers_result_t mlx4_pci_err_detected(struct pci_dev *pdev,
>>> pci_channel_state_t state)
>>> {
>>> mlx4_unload_one(pdev);
>>> + pci_release_regions(pdev);
>>> + pci_disable_device(pdev);
>>>
>>> return state == pci_channel_io_perm_failure ?
>>> PCI_ERS_RESULT_DISCONNECT : PCI_ERS_RESULT_NEED_RESET;
>>> --
^ permalink raw reply
* Re: [patch net-next v3 16/17] bridge: add brport flags to dflt bridge_getlink
From: Thomas Graf @ 2014-11-25 22:07 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <1416911328-10979-17-git-send-email-jiri@resnulli.us>
On 11/25/14 at 11:28am, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> To allow brport device to return current brport flags set on port. Add
> returned flags to nested IFLA_PROTINFO netlink msg built in dflt getlink.
> With this change, netlink msg returned for bridge_getlink contains the port's
> offloaded flag settings (the port's SELF settings).
>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Minor nit below. Otherwise:
Acked-by: Thomas Graf <tgraf@suug.ch>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index bd5e783..91e5368 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -2687,12 +2687,22 @@ static int rtnl_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb)
> return skb->len;
> }
>
> +static int brport_nla_put_flag(struct sk_buff *skb, u32 flags, u32 mask,
> + unsigned int attrnum, unsigned int flag)
> +{
> + if (mask & flag)
> + return nla_put_u8(skb, attrnum, !!(flags & flag));
nla_put_flag()?
^ permalink raw reply
* Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: josh-iaAMLnmF4UmaiuxdJuQwMA @ 2014-11-25 22:08 UTC (permalink / raw)
To: Randy Dunlap
Cc: Pieter Smith, Alexander Duyck, Alexander Viro, Alexei Starovoitov,
Andrew Morton, Bertrand Jacquin, Catalina Mocanu, Daniel Borkmann,
David S. Miller, Eric Dumazet, Eric W. Biederman,
Fabian Frederick, open list:FUSE: FILESYSTEM...,
Geert Uytterhoeven, Hugh Dickins, Iulia Manda, Jan Beulich,
J. Bruce Fields, Jeff Layton, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, open list
In-Reply-To: <5474ABB6.3030400-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
[Resending this mail due to some email encoding brokenness that
prevented it from reaching LKML the first time; sorry to anyone who
receives two copies.]
On Tue, Nov 25, 2014 at 08:17:58AM -0800, Randy Dunlap wrote:
> On 11/24/2014 03:00 PM, Pieter Smith wrote:
> >REPO: https://github.com/smipi1/linux-tinification.git
> >
> >BRANCH: tiny/config-syscall-splice
> >
> >BACKGROUND: This patch-set forms part of the Linux Kernel Tinification effort (
> > https://tiny.wiki.kernel.org/).
> >
> >GOAL: Support compiling out the splice family of syscalls (splice, vmsplice,
> > tee and sendfile) along with all supporting infrastructure if not needed.
> > Many embedded systems will not need the splice-family syscalls. Omitting them
> > saves space.
>
> Hi,
>
> Is the splice family of syscalls the only one that tiny has identified
> for optional building or can we expect similar treatment for other
> syscalls?
Pretty much any system call that you could conceive of writing a
userspace without.
There's a partial project list at https://tiny.wiki.kernel.org/projects.
> Why will many embedded systems not need these syscalls? You know
> exactly what apps they run and you are positive that those apps do
> not use splice?
Yes, precisely. We're talking about embedded systems small enough that
you're booting with init=/your/app and don't even call fork(), where you
know exactly what code you're putting in and what libraries you use.
And they're almost certainly not running glibc.
> >RESULTS: A tinyconfig bloat-o-meter score for the entire patch-set:
> >
> >add/remove: 0/41 grow/shrink: 5/7 up/down: 23/-8422 (-8399)
>
> The summary is that this patch saves around 8 KB of code space --
> is that correct?
Right. For reference, we're talking about kernels where the *total*
size is a few hundred kB.
> How much storage space do embedded systems have nowadays?
For the embedded systems we're targeting for the tinification effort, in
a first pass: 512k-2M of storage (often for an *uncompressed* kernel, to
support execute-in-place), and 128k-512k of memory. We've successfully
built useful kernels and userspaces for such environments, and we'd like
to go even smaller.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch net-next v3 01/17] bridge: rename fdb_*_hw to fdb_*_hw_addr to avoid confusion
From: Thomas Graf @ 2014-11-25 22:11 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <1416911328-10979-2-git-send-email-jiri@resnulli.us>
On 11/25/14 at 11:28am, Jiri Pirko wrote:
> The current name might seem that this actually offloads the fdb entry to
> hw. So rename it to clearly present that this for hardware address
> addition/removal.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
FWIW
Acked-by: Thomas Graf <tgraf@suug.ch>
^ permalink raw reply
* Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Thomas Graf @ 2014-11-25 22:14 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <1416911328-10979-3-git-send-email-jiri@resnulli.us>
On 11/25/14 at 11:28am, Jiri Pirko wrote:
> Do the work of parsing NDA_VLAN directly in rtnetlink code, pass simple
> u16 vid to drivers from there.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
I'm slightly confused ;-)
We both argued that parsing Netlink attributes in the drivers is wrong.
What happened to the plan of renaming ndo_fdb_ to ndo_neigh_ and
introducing a non-Netlink in-kernel API for advanced usage by swdev?
^ permalink raw reply
* Re: [patch net-next v3 08/17] bridge: call netdev_sw_port_stp_update when bridge port STP status changes
From: Thomas Graf @ 2014-11-25 22:18 UTC (permalink / raw)
To: Jiri Pirko
Cc: Andy Gospodarek, netdev, davem, nhorman, andy, dborkman, ogerlitz,
jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, bcrl
In-Reply-To: <20141125165308.GL1971@nanopsycho.orion>
On 11/25/14 at 05:53pm, Jiri Pirko wrote:
> Tue, Nov 25, 2014 at 04:58:32PM CET, gospo@cumulusnetworks.com wrote:
> >I do not expect that this first set would provide full feedback to
> >br_make_forwarding, br_make_blocking, etc, to allow spanning tree to
> >properly deal with the failure (that change is fine to add later), but a
> >short one-liner indicating that the call to the hardware failed would e
> >good. What about something simple like this:
> >
> >void br_set_state(struct net_bridge_port *p, unsigned int state)
> >{
> > int ret;
> > p->state = state;
> > ret = netdev_switch_port_stp_update(p->dev, state);
> > if (ret && ret != -EOPNOTSUPP)
> > br_warn(br, "error setting offload STP state for interface %s\n",
> > p->dev->name);
> >}
>
> That makes sense. Will add this.
Feel free to add:
Acked-by: Thomas Graf <tgraf@suug.ch>
^ permalink raw reply
* Re: [patch net-next v3 08/17] bridge: call netdev_sw_port_stp_update when bridge port STP status changes
From: Florian Fainelli @ 2014-11-25 22:20 UTC (permalink / raw)
To: Andy Gospodarek, Jiri Pirko
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
bcrl
In-Reply-To: <20141125155832.GG27416@gospo.rtplab.test>
On 25/11/14 07:58, Andy Gospodarek wrote:
> On Tue, Nov 25, 2014 at 11:28:39AM +0100, Jiri Pirko wrote:
>> From: Scott Feldman <sfeldma@gmail.com>
>>
>> To notify switch driver of change in STP state of bridge port, add new
>> .ndo op and provide switchdev wrapper func to call ndo op. Use it in bridge
>> code then.
>>
>> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
[snip]
>> #include "br_private.h"
>> #include "br_private_stp.h"
>> @@ -39,6 +40,7 @@ void br_log_state(const struct net_bridge_port *p)
>> void br_set_state(struct net_bridge_port *p, unsigned int state)
>> {
>> p->state = state;
>> + netdev_switch_port_stp_update(p->dev, state);
>
> The only thing that concerns me about this patch is the fact that there
> is nothing paying attention to the return code.
>
> This means if *something* in the driver fails to set the STP state we
> have no way to feed this information back to the user to let them know
> that their hardware isn't exactly functioning as we expect.
This typically translates into an actual HW register write in general
(writing the STP algorithm result per-port), so although they typically
don't fail in most HW transports, I so no harm in returning something
useful just in case.
Once you do this, feel free to add a:
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks!
>
> I do not expect that this first set would provide full feedback to
> br_make_forwarding, br_make_blocking, etc, to allow spanning tree to
> properly deal with the failure (that change is fine to add later), but a
> short one-liner indicating that the call to the hardware failed would e
> good. What about something simple like this:
>
> void br_set_state(struct net_bridge_port *p, unsigned int state)
> {
> int ret;
> p->state = state;
> ret = netdev_switch_port_stp_update(p->dev, state);
> if (ret && ret != -EOPNOTSUPP)
> br_warn(br, "error setting offload STP state for interface %s\n",
> p->dev->name);
> }
>
>>
>> /* called under bridge lock */
>> diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
>> index 66973de..d162b21 100644
>> --- a/net/switchdev/switchdev.c
>> +++ b/net/switchdev/switchdev.c
>> @@ -31,3 +31,22 @@ int netdev_switch_parent_id_get(struct net_device *dev,
>> return ops->ndo_switch_parent_id_get(dev, psid);
>> }
>> EXPORT_SYMBOL(netdev_switch_parent_id_get);
>> +
>> +/**
>> + * netdev_switch_port_stp_update - Notify switch device port of STP
>> + * state change
>> + * @dev: port device
>> + * @state: port STP state
>> + *
>> + * Notify switch device port of bridge port STP state change.
>> + */
>> +int netdev_switch_port_stp_update(struct net_device *dev, u8 state)
>> +{
>> + const struct net_device_ops *ops = dev->netdev_ops;
>> +
>> + if (!ops->ndo_switch_port_stp_update)
>> + return -EOPNOTSUPP;
>> + WARN_ON(!ops->ndo_switch_parent_id_get);
>> + return ops->ndo_switch_port_stp_update(dev, state);
>> +}
>> +EXPORT_SYMBOL(netdev_switch_port_stp_update);
>> --
>> 1.9.3
>>
^ permalink raw reply
* Re: [patch net-next v3 13/17] bridge: move private brport flags to if_bridge.h so port drivers can use flags
From: Florian Fainelli @ 2014-11-25 22:20 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-14-git-send-email-jiri@resnulli.us>
On 25/11/14 02:28, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
^ permalink raw reply
* Re: [PATCH] net/mlx4: Fix EEH recovery failure
From: Gavin Shan @ 2014-11-25 22:21 UTC (permalink / raw)
To: Or Gerlitz
Cc: Gavin Shan, Linux Netdev List, Amir Vadai, David Miller, Wei Yang,
Yishai Hadas, Jack Morgenstein
In-Reply-To: <CAJ3xEMi9G+tFsaANwndhmOZ78gt79WZ35Oq4CiFOm1WqxBXyqQ@mail.gmail.com>
On Wed, Nov 26, 2014 at 12:00:31AM +0200, Or Gerlitz wrote:
>On Mon, Nov 24, 2014 at 11:55 PM, Gavin Shan <gwshan@linux.vnet.ibm.com> wrote:
>> On Mon, Nov 24, 2014 at 11:17:55PM +0200, Or Gerlitz wrote:
>>>On Sat, Nov 22, 2014 at 12:56 PM, Gavin Shan <gwshan@linux.vnet.ibm.com> wrote:
>>>> The patch fixes couple of EEH recovery failures on PPC PowerNV
>>>> platform:
>>>
>>>> * Don't clear struct mlx4_priv instance in mlx4_pci_err_detected().
>>>> Otherwise, __mlx4_init_one() runs into kernel crash because
>>>> of dereferencing to NULL pointer.
>>>
>>>I don't see this change in the patch, I see no-clearing of mlx4_priv
>>>in __mlx4_unload_one - please clarify, also is this patch
>>>based/targeted on the net or net-next tree?
>>>
>>
>> Yes, It would be: Don't clear struct mlx4_priv instance in mlx4_unload_one(),
>> which is called by mlx4_pci_err_detected().
>
>
>But the struct mlx4_priv instance is cleared in mlx4_unload_one() for
>a reason, I suspect that you might made the EEH callback to work, but
>broke something else... e.g did you made sure that kexec works after
>your changes as it did before?
>
Nope, I didn't try kexec out and I'll have a try, thanks!
Gavin
>> It's based on 3.18.rc5, where I had couple of EEH fixes on top of it.
>> When testing EEH with it, I hit the issue.
>
>>>> With the patch applied, EEH recovery for mlx4 adapter succeeds on PPC
>>>> PowerNV platform.
>>>>
>>>> # lspci
>>>> 0003:0f:00.0 Network controller: Mellanox Technologies \
>>>> MT27500 Family [ConnectX-3]
>>>>
>>>> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>>>> ---
>>>> drivers/net/ethernet/mellanox/mlx4/main.c | 3 ++-
>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
>>>> index 90de6e1..e118ac9 100644
>>>> --- a/drivers/net/ethernet/mellanox/mlx4/main.c
>>>> +++ b/drivers/net/ethernet/mellanox/mlx4/main.c
>>>> @@ -2809,7 +2809,6 @@ static void mlx4_unload_one(struct pci_dev *pdev)
>>>> kfree(dev->caps.qp1_proxy);
>>>> kfree(dev->dev_vfs);
>>>>
>>>> - memset(priv, 0, sizeof(*priv));
>>>> priv->pci_dev_data = pci_dev_data;
>>>> priv->removed = 1;
>>>> }
>>>> @@ -2900,6 +2899,8 @@ static pci_ers_result_t mlx4_pci_err_detected(struct pci_dev *pdev,
>>>> pci_channel_state_t state)
>>>> {
>>>> mlx4_unload_one(pdev);
>>>> + pci_release_regions(pdev);
>>>> + pci_disable_device(pdev);
>>>>
>>>> return state == pci_channel_io_perm_failure ?
>>>> PCI_ERS_RESULT_DISCONNECT : PCI_ERS_RESULT_NEED_RESET;
>>>> --
>
^ permalink raw reply
* Re: [PATCH v2] net: Hyper-V: Deletion of an unnecessary check before the function call "vfree"
From: David Miller @ 2014-11-25 22:25 UTC (permalink / raw)
To: elfring
Cc: devel, netdev, haiyangz, kys, linux-kernel, kernel-janitors,
julia.lawall
In-Reply-To: <5474FAD6.4060704@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Tue, 25 Nov 2014 22:55:34 +0100
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 25 Nov 2014 22:33:45 +0100
>
> The vfree() function performs also input parameter validation.
> Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Applied, thanks.
^ permalink raw reply
* Re: [patch net-next v3 06/17] net-sysfs: expose physical switch id for particular device
From: Florian Fainelli @ 2014-11-25 22:27 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-7-git-send-email-jiri@resnulli.us>
On 25/11/14 02:28, Jiri Pirko wrote:
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> Reviewed-by: Thomas Graf <tgraf@suug.ch>
> Acked-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
.. only if you also update Documentation/ABI/testing/sysfs-class-net as
well ;)
> ---
> v2->v3:
> -changed "sw" string to "switch" to avoid confusion
> v1->v2:
> -no change
> ---
> net/core/net-sysfs.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
> index 26c46f4..9993412 100644
> --- a/net/core/net-sysfs.c
> +++ b/net/core/net-sysfs.c
> @@ -12,6 +12,7 @@
> #include <linux/capability.h>
> #include <linux/kernel.h>
> #include <linux/netdevice.h>
> +#include <net/switchdev.h>
> #include <linux/if_arp.h>
> #include <linux/slab.h>
> #include <linux/nsproxy.h>
> @@ -416,6 +417,28 @@ static ssize_t phys_port_id_show(struct device *dev,
> }
> static DEVICE_ATTR_RO(phys_port_id);
>
> +static ssize_t phys_switch_id_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct net_device *netdev = to_net_dev(dev);
> + ssize_t ret = -EINVAL;
> +
> + if (!rtnl_trylock())
> + return restart_syscall();
> +
> + if (dev_isalive(netdev)) {
> + struct netdev_phys_item_id ppid;
> +
> + ret = netdev_switch_parent_id_get(netdev, &ppid);
> + if (!ret)
> + ret = sprintf(buf, "%*phN\n", ppid.id_len, ppid.id);
> + }
> + rtnl_unlock();
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(phys_switch_id);
> +
> static struct attribute *net_class_attrs[] = {
> &dev_attr_netdev_group.attr,
> &dev_attr_type.attr,
> @@ -441,6 +464,7 @@ static struct attribute *net_class_attrs[] = {
> &dev_attr_tx_queue_len.attr,
> &dev_attr_gro_flush_timeout.attr,
> &dev_attr_phys_port_id.attr,
> + &dev_attr_phys_switch_id.attr,
> NULL,
> };
> ATTRIBUTE_GROUPS(net_class);
>
^ permalink raw reply
* Re: [patch net-next v3 01/17] bridge: rename fdb_*_hw to fdb_*_hw_addr to avoid confusion
From: Florian Fainelli @ 2014-11-25 22:33 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <1416911328-10979-2-git-send-email-jiri@resnulli.us>
On 25/11/14 02:28, Jiri Pirko wrote:
> The current name might seem that this actually offloads the fdb entry to
> hw. So rename it to clearly present that this for hardware address
> addition/removal.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
FWIW:
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
^ permalink raw reply
* Re: [patch net-next v3 09/17] bridge: add API to notify bridge driver of learned FBD on offloaded device
From: Thomas Graf @ 2014-11-25 22:36 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Jiri Pirko, netdev, davem, nhorman, andy, dborkman, ogerlitz,
jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, bcrl
In-Reply-To: <20141125163853.GJ27416@gospo.rtplab.test>
On 11/25/14 at 11:38am, Andy Gospodarek wrote:
> On Tue, Nov 25, 2014 at 11:28:40AM +0100, Jiri Pirko wrote:
> > From: Scott Feldman <sfeldma@gmail.com>
> >
> > When the swdev device learns a new mac/vlan on a port, it sends some async
> > notification to the driver and the driver installs an FDB in the device.
> > To give a holistic system view, the learned mac/vlan should be reflected
> > in the bridge's FBD table, so the user, using normal iproute2 cmds, can view
> > what is currently learned by the device. This API on the bridge driver gives
> > a way for the swdev driver to install an FBD entry in the bridge FBD table.
> > (And remove one).
> >
> > This is equivalent to the device running these cmds:
> >
> > bridge fdb [add|del] <mac> dev <dev> vid <vlan id> master
> >
> > This patch needs some extra eyeballs for review, in paricular around the
> > locking and contexts.
> >
> > Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> > Signed-off-by: Jiri Pirko <jiri@resnulli.us>
I like the simplicity of this. That said, given we'll have multiple
users of swdev including OVS, shouldn't this be a notifier or a
callback that depends on who is controlling the device?
> > + spin_lock(&br->hash_lock);
> (Since you asked to check locking...)
>
> Most of the other fdb_add/delete/insert/update calls take this with
> spin_lock_bh. Did you try this with lockdep enabled just to see if that
> is needed here? I suspect that anytime br->hash_lock is taken it will
> need to be with softirqs disabled from this point forward.
At least br_fdb_update() seems to be called from BH context so I would
agree and argue the lock in br_fdb_cleanup() and br_fdb_update() need a
fix too. I'll send a patch.
^ permalink raw reply
* Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Florian Fainelli @ 2014-11-25 22:39 UTC (permalink / raw)
To: Thomas Graf, Jiri Pirko
Cc: netdev, davem, nhorman, andy, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <20141125221417.GF3912@casper.infradead.org>
On 25/11/14 14:14, Thomas Graf wrote:
> On 11/25/14 at 11:28am, Jiri Pirko wrote:
>> Do the work of parsing NDA_VLAN directly in rtnetlink code, pass simple
>> u16 vid to drivers from there.
>>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>
> I'm slightly confused ;-)
>
> We both argued that parsing Netlink attributes in the drivers is wrong.
> What happened to the plan of renaming ndo_fdb_ to ndo_neigh_ and
> introducing a non-Netlink in-kernel API for advanced usage by swdev?
>
Not sure I follow you here, the commit message says what it says it
does, are we looking at the same patch?
--
Florian
^ permalink raw reply
* [net-next PATCH 0/5] net: Add helper for padding short Ethernet frames
From: Alexander Duyck @ 2014-11-25 22:43 UTC (permalink / raw)
To: netdev; +Cc: davem
This patch series adds a helper to pad short Ethernet frames. The general
idea is to clean up a number of code paths that were all writing their own
versions of the same or similar function.
An added advantage is that this will help to discourage introducing new
bugs as in at least one case I found the skb->len had been updated, but the
tail pointer update was overlooked.
---
Alexander Duyck (5):
etherdevice: Add function for handling padding frame to ETH_ZLEN
ethernet/intel: Use eth_skb_pad helper
niu: Use eth_skb_pad helper
myri10ge: use eth_skb_pad helper
r8169: Use eth_skb_pad function
drivers/net/ethernet/intel/e1000/e1000_main.c | 8 ++------
drivers/net/ethernet/intel/fm10k/fm10k_main.c | 11 +++--------
drivers/net/ethernet/intel/igb/igb_main.c | 11 +++--------
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 11 +++--------
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 11 +++--------
drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 15 +++++----------
drivers/net/ethernet/realtek/r8169.c | 12 ++----------
drivers/net/ethernet/sun/niu.c | 9 ++-------
include/linux/etherdevice.h | 21 +++++++++++++++++++++
9 files changed, 44 insertions(+), 65 deletions(-)
--
^ permalink raw reply
* [net-next PATCH 1/5] etherdevice: Add function for handling padding frame to ETH_ZLEN
From: Alexander Duyck @ 2014-11-25 22:44 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <20141125223727.1867.43890.stgit@ahduyck-vm-fedora20>
This patch adds a simple function for padding a frame up to the minimum
size for for Ethernet. The motivation behind it is that there are a number
of implementations throughout the network device drivers that are all doing
the same thing, but each a little bit differently and as a result several
implementations contain bugs such as updating the length without updating
the tail offset and other similar issues.
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
---
include/linux/etherdevice.h | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index 733980f..7e436f3 100644
--- a/include/linux/etherdevice.h
+++ b/include/linux/etherdevice.h
@@ -392,4 +392,25 @@ static inline unsigned long compare_ether_header(const void *a, const void *b)
#endif
}
+/**
+ * eth_skb_pad - Pad buffer to mininum number of octets for Ethernet frame
+ * @skb: Buffer to pad
+ *
+ * An Ethernet frame should have a minimum size of 60 bytes. This function
+ * takes short frames and pads them with zeros up to the 60 byte limit.
+ */
+static inline int eth_skb_pad(struct sk_buff *skb)
+{
+ unsigned int size = skb->len;
+
+ if (unlikely(size < ETH_ZLEN)) {
+ size = ETH_ZLEN - size;
+ if (skb_pad(skb, size))
+ return -ENOMEM;
+ __skb_put(skb, size);
+ }
+
+ return 0;
+}
+
#endif /* _LINUX_ETHERDEVICE_H */
^ permalink raw reply related
* [net-next PATCH 2/5] ethernet/intel: Use eth_skb_pad helper
From: Alexander Duyck @ 2014-11-25 22:44 UTC (permalink / raw)
To: netdev; +Cc: Jeff Kirsher, davem
In-Reply-To: <20141125223727.1867.43890.stgit@ahduyck-vm-fedora20>
Update the Intel Ethernet drivers to use eth_skb_pad() instead of doing
their own implementations of the function.
Also this cleans up two other spots where skb_pad was called but the length
and tail pointers were being manipulated directly instead of just having
the padding length added via __skb_put.
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
---
drivers/net/ethernet/intel/e1000/e1000_main.c | 8 ++------
drivers/net/ethernet/intel/fm10k/fm10k_main.c | 11 +++--------
drivers/net/ethernet/intel/igb/igb_main.c | 11 +++--------
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 11 +++--------
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 11 +++--------
5 files changed, 14 insertions(+), 38 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 24f3986..862d198 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -3136,12 +3136,8 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
* packets may get corrupted during padding by HW.
* To WA this issue, pad all small packets manually.
*/
- if (skb->len < ETH_ZLEN) {
- if (skb_pad(skb, ETH_ZLEN - skb->len))
- return NETDEV_TX_OK;
- skb->len = ETH_ZLEN;
- skb_set_tail_pointer(skb, ETH_ZLEN);
- }
+ if (eth_skb_pad(skb))
+ return NETDEV_TX_OK;
mss = skb_shinfo(skb)->gso_size;
/* The controller does a simple calculation to
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_main.c b/drivers/net/ethernet/intel/fm10k/fm10k_main.c
index 73457ed..91516ae 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_main.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_main.c
@@ -578,14 +578,9 @@ static bool fm10k_cleanup_headers(struct fm10k_ring *rx_ring,
if (skb_is_nonlinear(skb))
fm10k_pull_tail(rx_ring, rx_desc, skb);
- /* if skb_pad returns an error the skb was freed */
- if (unlikely(skb->len < 60)) {
- int pad_len = 60 - skb->len;
-
- if (skb_pad(skb, pad_len))
- return true;
- __skb_put(skb, pad_len);
- }
+ /* if eth_skb_pad returns an error the skb was freed */
+ if (eth_skb_pad(skb))
+ return true;
return false;
}
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index b0e12e7..3cb54d0 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -6843,14 +6843,9 @@ static bool igb_cleanup_headers(struct igb_ring *rx_ring,
if (skb_is_nonlinear(skb))
igb_pull_tail(rx_ring, rx_desc, skb);
- /* if skb_pad returns an error the skb was freed */
- if (unlikely(skb->len < 60)) {
- int pad_len = 60 - skb->len;
-
- if (skb_pad(skb, pad_len))
- return true;
- __skb_put(skb, pad_len);
- }
+ /* if eth_skb_pad returns an error the skb was freed */
+ if (eth_skb_pad(skb))
+ return true;
return false;
}
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 932f779..7d0991a 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1766,14 +1766,9 @@ static bool ixgbe_cleanup_headers(struct ixgbe_ring *rx_ring,
return false;
#endif
- /* if skb_pad returns an error the skb was freed */
- if (unlikely(skb->len < 60)) {
- int pad_len = 60 - skb->len;
-
- if (skb_pad(skb, pad_len))
- return true;
- __skb_put(skb, pad_len);
- }
+ /* if eth_skb_pad returns an error the skb was freed */
+ if (eth_skb_pad(skb))
+ return true;
return false;
}
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 755f71f..465d6a8 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -612,14 +612,9 @@ static bool ixgbevf_cleanup_headers(struct ixgbevf_ring *rx_ring,
if (skb_is_nonlinear(skb))
ixgbevf_pull_tail(rx_ring, skb);
- /* if skb_pad returns an error the skb was freed */
- if (unlikely(skb->len < 60)) {
- int pad_len = 60 - skb->len;
-
- if (skb_pad(skb, pad_len))
- return true;
- __skb_put(skb, pad_len);
- }
+ /* if eth_skb_pad returns an error the skb was freed */
+ if (eth_skb_pad(skb))
+ return true;
return false;
}
^ permalink raw reply related
* [net-next PATCH 3/5] niu: Use eth_skb_pad helper
From: Alexander Duyck @ 2014-11-25 22:44 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <20141125223727.1867.43890.stgit@ahduyck-vm-fedora20>
Replace the standard layout for padding an ethernet frame with the
eth_skb_pad call.
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
---
drivers/net/ethernet/sun/niu.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
index 904fd1a..4aaa324 100644
--- a/drivers/net/ethernet/sun/niu.c
+++ b/drivers/net/ethernet/sun/niu.c
@@ -6651,13 +6651,8 @@ static netdev_tx_t niu_start_xmit(struct sk_buff *skb,
return NETDEV_TX_BUSY;
}
- if (skb->len < ETH_ZLEN) {
- unsigned int pad_bytes = ETH_ZLEN - skb->len;
-
- if (skb_pad(skb, pad_bytes))
- goto out;
- skb_put(skb, pad_bytes);
- }
+ if (eth_skb_pad(skb))
+ goto out;
len = sizeof(struct tx_pkt_hdr) + 15;
if (skb_headroom(skb) < len) {
^ permalink raw reply related
* [net-next PATCH 4/5] myri10ge: use eth_skb_pad helper
From: Alexander Duyck @ 2014-11-25 22:44 UTC (permalink / raw)
To: netdev; +Cc: Hyong-Youb Kim, davem
In-Reply-To: <20141125223727.1867.43890.stgit@ahduyck-vm-fedora20>
Update myri10ge to use eth_skb_pad helper. This also corrects a minor
issue as the driver was updating length without updating the tail pointer.
Cc: Hyong-Youb Kim <hykim@myri.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
---
drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
index 9e7e3f1..af09905 100644
--- a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
+++ b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
@@ -2913,16 +2913,11 @@ again:
flags |= MXGEFW_FLAGS_SMALL;
/* pad frames to at least ETH_ZLEN bytes */
- if (unlikely(skb->len < ETH_ZLEN)) {
- if (skb_padto(skb, ETH_ZLEN)) {
- /* The packet is gone, so we must
- * return 0 */
- ss->stats.tx_dropped += 1;
- return NETDEV_TX_OK;
- }
- /* adjust the len to account for the zero pad
- * so that the nic can know how long it is */
- skb->len = ETH_ZLEN;
+ if (eth_skb_pad(skb)) {
+ /* The packet is gone, so we must
+ * return 0 */
+ ss->stats.tx_dropped += 1;
+ return NETDEV_TX_OK;
}
}
^ 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