* Re: [PATCH iproute2] ip monitor: Fixed printing timestamp few times
From: vadim4j @ 2014-12-03 17:41 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20141203094731.4d310fc5@urahara>
On Wed, Dec 03, 2014 at 09:47:31AM -0800, Stephen Hemminger wrote:
> On Wed, 3 Dec 2014 19:11:26 +0200
> vadim4j@gmail.com wrote:
>
> > I think it was caused by RTM_NEWNDUSEROPT which was sent by router.
> > So in this case the message will be skipped with printed timestamp.
>
> Can that be decoded? it might be useful.
Sorry, you mean how it can be reproduced by clean scenario?
^ permalink raw reply
* Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request
From: Stephen Hemminger @ 2014-12-03 17:51 UTC (permalink / raw)
To: vadim4j; +Cc: netdev
In-Reply-To: <20141203172010.GA8639@angus-think.wlc.globallogic.com>
On Wed, 3 Dec 2014 19:20:10 +0200
vadim4j@gmail.com wrote:
> On Wed, Dec 03, 2014 at 09:21:29AM -0800, Stephen Hemminger wrote:
> > On Tue, 2 Dec 2014 16:53:04 +0200
> > Vadim Kochan <vadim4j@gmail.com> wrote:
> >
> > > Replaced handling netlink messages by rtnl_dump_filter
> > > from lib/libnetlink.c, also:
> > >
> > > - removed unused dump_fp arg;
> > > - added MAGIC_SEQ #define for 123456 seq id
> > >
> > > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
> >
> > This doesn't work correctly.
> >
> > Simple test
> > $ misc/ss >/dev/null
> > RTNETLINK answers: No such file or directory
> > RTNETLINK answers: No such file or directory
> > RTNETLINK answers: No such file or directory
>
> Just tried, I did not get such errors.
I have OpenVPN running.
^ permalink raw reply
* Re: [PATCH iproute2] ip monitor: Fixed printing timestamp few times
From: Stephen Hemminger @ 2014-12-03 17:47 UTC (permalink / raw)
To: vadim4j; +Cc: netdev
In-Reply-To: <20141203171126.GA7381@angus-think.wlc.globallogic.com>
On Wed, 3 Dec 2014 19:11:26 +0200
vadim4j@gmail.com wrote:
> I think it was caused by RTM_NEWNDUSEROPT which was sent by router.
> So in this case the message will be skipped with printed timestamp.
Can that be decoded? it might be useful.
^ permalink raw reply
* Re: [PATCH Iproute2 next v2] ip link: Add ipvlan support to the iproute2/ip util
From: Stephen Hemminger @ 2014-12-03 17:38 UTC (permalink / raw)
To: Mahesh Bandewar
Cc: netdev, Eric Dumazet, Maciej Zenczykowski, Laurent Chavey,
Tim Hockin, David Miller, Brandon Philips, Pavel Emelianov
In-Reply-To: <1416794771-11193-1-git-send-email-maheshb@google.com>
On Sun, 23 Nov 2014 18:06:11 -0800
Mahesh Bandewar <maheshb@google.com> wrote:
> Adding basic support to create virtual devices using 'ip'
> utility. Following is the syntax -
>
> ip link add link <master> <virtual> type ipvlan mode [ l2 | l3 ]
> e.g. ip link add link eth0 ipvl0 type ipvlan mode l3
>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Maciej Żenczykowski <maze@google.com>
> Cc: Laurent Chavey <chavey@google.com>
> Cc: Tim Hockin <thockin@google.com>
> Cc: Brandon Philips <brandon.philips@coreos.com>
> Cc: Pavel Emelianov <xemul@parallels.com>
Applied to net-next branch.
^ permalink raw reply
* Re: [patch iproute2 v4] tc: add support for vlan tc action
From: Stephen Hemminger @ 2014-12-03 17:35 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, jhs, pshelar, therbert, edumazet, willemb,
dborkman, mst, fw, Paul.Durrant, tgraf, cwang
In-Reply-To: <1416402506-31852-1-git-send-email-jiri@resnulli.us>
On Wed, 19 Nov 2014 14:08:26 +0100
Jiri Pirko <jiri@resnulli.us> wrote:
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> Reviewed-by: Cong Wang <cwang@twopensource.com>
Applied to net-next branch.
^ permalink raw reply
* Re: [PATCH v2 4/7] fs/proc/task_mmu.c: shift mm_access() from m_start() to proc_maps_open()
From: Oleg Nesterov @ 2014-12-03 17:34 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: David S. Miller, Linus Torvalds, Andrew Morton, Alexander Viro,
Cyrill Gorcunov, David Howells, Eric W. Biederman,
Kirill A. Shutemov, Peter Zijlstra, Sasha Levin, linux-fsdevel,
linux-kernel, Alexey Dobriyan, netdev
In-Reply-To: <20141203141433.GA25683@node.dhcp.inet.fi>
On 12/03, Kirill A. Shutemov wrote:
>
> On Tue, Aug 05, 2014 at 09:46:55PM +0200, Oleg Nesterov wrote:
> > A simple test-case from Kirill Shutemov
> >
> > cat /proc/self/maps >/dev/null
> > chmod +x /proc/self/net/packet
> > exec /proc/self/net/packet
> >
> > makes lockdep unhappy, cat/exec take seq_file->lock + cred_guard_mutex in
> > the opposite order.
>
> Oleg, I see it again with almost the same test-case:
>
> cat /proc/self/stack >/dev/null
> chmod +x /proc/self/net/packet
> exec /proc/self/net/packet
Yes, there are more lock_trace/mm_access (ab)users. Fortunately, they
are much simpler than proc/pid/maps (which also asked for other cleanups
and fixes).
I'll try to take a look, thanks for reminding.
And I agree with Eric, chmod+x probably makes no sense. Still I think
this code deserves some cleanups regardless. To the point I think that
lock_trace() should probably die.
Thanks!
Oleg.
^ permalink raw reply
* [PATCH net-next] tc_act: export uapi header file
From: Stephen Hemminger @ 2014-12-03 17:33 UTC (permalink / raw)
To: Jiri Pirko, Jamal Hadi Salim, David Miller; +Cc: netdev
This file is used by iproute2 and should be exported.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/include/uapi/linux/tc_act/Kbuild 2014-02-12 08:21:56.614859066 -0800
+++ b/include/uapi/linux/tc_act/Kbuild 2014-12-03 09:31:10.619225148 -0800
@@ -7,3 +7,4 @@ header-y += tc_mirred.h
header-y += tc_nat.h
header-y += tc_pedit.h
header-y += tc_skbedit.h
+header-y += tc_vlan.h
^ permalink raw reply
* Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request
From: vadim4j @ 2014-12-03 17:20 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20141203092129.49f16769@urahara>
On Wed, Dec 03, 2014 at 09:21:29AM -0800, Stephen Hemminger wrote:
> On Tue, 2 Dec 2014 16:53:04 +0200
> Vadim Kochan <vadim4j@gmail.com> wrote:
>
> > Replaced handling netlink messages by rtnl_dump_filter
> > from lib/libnetlink.c, also:
> >
> > - removed unused dump_fp arg;
> > - added MAGIC_SEQ #define for 123456 seq id
> >
> > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
>
> This doesn't work correctly.
>
> Simple test
> $ misc/ss >/dev/null
> RTNETLINK answers: No such file or directory
> RTNETLINK answers: No such file or directory
> RTNETLINK answers: No such file or directory
Just tried, I did not get such errors.
^ permalink raw reply
* Re: [PATCH v2] iproute2: Refactor: using new nl_msg struct for the all Netlink handlers
From: Stephen Hemminger @ 2014-12-03 17:23 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <1409913328-9003-1-git-send-email-vadim4j@gmail.com>
On Fri, 5 Sep 2014 13:35:28 +0300
Vadim Kochan <vadim4j@gmail.com> wrote:
> It will easy to extend with new parameters in future.
>
> Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
This is a big change and not needed yet. Please hold off refactoring until the
new parameters are actually needed.
^ permalink raw reply
* Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request
From: Stephen Hemminger @ 2014-12-03 17:21 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <1417531984-3522-1-git-send-email-vadim4j@gmail.com>
On Tue, 2 Dec 2014 16:53:04 +0200
Vadim Kochan <vadim4j@gmail.com> wrote:
> Replaced handling netlink messages by rtnl_dump_filter
> from lib/libnetlink.c, also:
>
> - removed unused dump_fp arg;
> - added MAGIC_SEQ #define for 123456 seq id
>
> Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
This doesn't work correctly.
Simple test
$ misc/ss >/dev/null
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
^ permalink raw reply
* Re: [PATCH iproute2] ip monitor: Fixed printing timestamp few times
From: vadim4j @ 2014-12-03 17:11 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20141203091338.2d32de2c@urahara>
On Wed, Dec 03, 2014 at 09:13:38AM -0800, Stephen Hemminger wrote:
> I don't see how you could get into accept_msg and cause this.
>
> The filtering should already be done by kernel for most things.
> The code already filters TC messages in kernel. Other types
> should be done as well.
I think it was caused by RTM_NEWNDUSEROPT which was sent by router.
So in this case the message will be skipped with printed timestamp.
> Ps: this code is crying to be a switch statement.
I agree.
^ permalink raw reply
* Re: [PATCH iproute2] man ip-link: Fix indentation for 'ip link show' options
From: Stephen Hemminger @ 2014-12-03 17:18 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <1417552751-3132-1-git-send-email-vadim4j@gmail.com>
On Tue, 2 Dec 2014 22:39:11 +0200
Vadim Kochan <vadim4j@gmail.com> wrote:
> BEFORE:
> The show command has additional formatting options:
>
> -s, -stats, -statistics
> output more statistics about packet usage.
>
> -d, -details
> output more detailed information.
>
> -h, -human, -human-readble
> output statistics with human readable values number followed by suffix
>
> -iec print human readable rates in IEC units (ie. 1K = 1024).
> AFTER:
> The show command has additional formatting options:
>
> -s, -stats, -statistics
> output more statistics about packet usage.
>
> -d, -details
> output more detailed information.
>
> -h, -human, -human-readble
> output statistics with human readable values number followed by suffix
>
> -iec print human readable rates in IEC units (ie. 1K = 1024).
>
> Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
> ---
> man/man8/ip-link.8.in | 3 +++
> 1 file changed, 3 insertions(+)
Applied
^ permalink raw reply
* Re: [PATCH iproute2] ip route: don't assume default route
From: Stephen Hemminger @ 2014-12-03 17:17 UTC (permalink / raw)
To: Pavel Šimerda; +Cc: netdev
In-Reply-To: <20141202164510.GA9005@mole.pavlix.net>
On Tue, 2 Dec 2014 17:45:10 +0100
=?UTF-8?q?Pavel=20=C5=A0imerda?= <psimerda@redhat.com> wrote:
> Just print the help when "ip route del" is called without any other
> arguments.
>
> Resolves:
>
> * https://bugzilla.redhat.com/show_bug.cgi?id=997965
>
> Signed-off-by: Pavel Šimerda <psimerda@redhat.com>
> ---
> ip/iproute.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/ip/iproute.c b/ip/iproute.c
> index d77b1e3..c171f29 100644
> --- a/ip/iproute.c
> +++ b/ip/iproute.c
> @@ -975,6 +975,9 @@ static int iproute_modify(int cmd, unsigned flags, int argc, char **argv)
> argc--; argv++;
> }
>
> + if (!dst_ok)
> + usage();
> +
> if (d || nhs_ok) {
> int idx;
>
Good catch. Applied
^ permalink raw reply
* Re: [PATCH iproute2] ip monitor: Fixed printing timestamp few times
From: Stephen Hemminger @ 2014-12-03 17:13 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <1417389262-25189-1-git-send-email-vadim4j@gmail.com>
On Mon, 1 Dec 2014 01:14:22 +0200
Vadim Kochan <vadim4j@gmail.com> wrote:
> Another fix when timestamp is printed few times
> before the event message.
>
> Fixed by skipping the message types which are not supported.
>
> Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
I don't see how you could get into accept_msg and cause this.
The filtering should already be done by kernel for most things.
The code already filters TC messages in kernel. Other types
should be done as well.
Ps: this code is crying to be a switch statement.
^ permalink raw reply
* Re: ovs datapath complains on unexpected mask for netlink commands
From: Jesse Gross @ 2014-12-03 17:09 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Or Gerlitz, Pravin Shelar, netdev@vger.kernel.org
In-Reply-To: <CAJ3xEMjL-ngoniJP9Lrw-UYMuHfQsEB8+OoR7W1GRQDD8aOnmw@mail.gmail.com>
On Wed, Dec 3, 2014 at 9:01 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Tue, Dec 2, 2014 at 1:39 AM, Jesse Gross <jesse@nicira.com> wrote:
>> On Thu, Nov 27, 2014 at 9:20 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
>>> Hi Jesse,
>>>
>>> I am running with net-next as of commit 2ad7bf36 "ipvlan: Initial check-in
>>> [...]"
>>> and user-space OVS v2.0.90 built from the upstream git.
>>>
>>> I suddenly realized that my kernel logs gets filled with the below
>>> prints which effectively take place for each ovs-vsctl command I run...
>>>
>>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>>
>> Thanks I see the problem. It looks like Pravin just sent out a patch
>> to fix this issue last night - "[PATCH net] openvswitch: Fix flow mask
>> validation.".
>
> I see, now (I know the patch wasn't applied yet) on my net clone, the
> complaint is a bit different...
>
> openvswitch: netlink: Contain more than allowed mask fields
> (mask_attrs=1205c, mask_allowed=19805c).
> openvswitch: netlink: Contain more than allowed mask fields
> (mask_attrs=19a05c, mask_allowed=19805c).
>
> so same fix for that too?
It's the same problem, only the text string was changed in the meantime.
^ permalink raw reply
* Re: [PATCH v2 4/7] fs/proc/task_mmu.c: shift mm_access() from m_start() to proc_maps_open()
From: Eric W. Biederman @ 2014-12-03 16:59 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Oleg Nesterov, David S. Miller, Linus Torvalds, Andrew Morton,
Alexander Viro, Cyrill Gorcunov, David Howells,
Kirill A. Shutemov, Peter Zijlstra, Sasha Levin, linux-fsdevel,
linux-kernel, Alexey Dobriyan, netdev
In-Reply-To: <20141203141433.GA25683@node.dhcp.inet.fi>
"Kirill A. Shutemov" <kirill@shutemov.name> writes:
> On Tue, Aug 05, 2014 at 09:46:55PM +0200, Oleg Nesterov wrote:
>> A simple test-case from Kirill Shutemov
>>
>> cat /proc/self/maps >/dev/null
>> chmod +x /proc/self/net/packet
>> exec /proc/self/net/packet
>>
>> makes lockdep unhappy, cat/exec take seq_file->lock + cred_guard_mutex in
>> the opposite order.
>
> Oleg, I see it again with almost the same test-case:
>
> cat /proc/self/stack >/dev/null
> chmod +x /proc/self/net/packet
> exec /proc/self/net/packet
>
> Looks like bunch of proc files were converted to use seq_file by Alexey
> Dobriyan around the same time you've fixed the issue for /proc/pid/maps.
>
> More generic test-case:
>
> find /proc/self/ -type f -exec dd if='{}' of=/dev/null bs=1 count=1 ';' 2>/dev/null
> chmod +x /proc/self/net/packet
> exec /proc/self/net/packet
>
> David, any justification for allowing chmod +x for files under
> /proc/pid/net?
I don't think there are any good reasons for allowing chmod +x for the
proc generic files. Certainly executing any of them is nonsense.
I do recall some weird conner cases existing. I think they resulted
in a need to preserve chmod if not chmod +x. This is just me saying
tread carefully before you change anything.
It really should be safe to tweak proc_notify_change to not allow
messing with the executable bits of proc files.
> [ 2.042212] ======================================================
> [ 2.042930] [ INFO: possible circular locking dependency detected ]
> [ 2.043648] 3.18.0-rc7-00003-g3a18ca061311-dirty #237 Not tainted
> [ 2.044350] -------------------------------------------------------
> [ 2.045054] sh/94 is trying to acquire lock:
> [ 2.045546] (&p->lock){+.+.+.}, at: [<ffffffff811e12fd>] seq_read+0x3d/0x3e0
> [ 2.045781]
> [ 2.045781] but task is already holding lock:
> [ 2.045781] (&sig->cred_guard_mutex){+.+.+.}, at: [<ffffffff811c0e3d>] prepare_bprm_creds+0x2d/0x90
> [ 2.045781]
> [ 2.045781] which lock already depends on the new lock.
> [ 2.045781]
> [ 2.045781]
> [ 2.045781] the existing dependency chain (in reverse order) is:
> [ 2.045781]
> -> #1 (&sig->cred_guard_mutex){+.+.+.}:
> [ 2.045781] [<ffffffff810a6e99>] __lock_acquire+0x4d9/0xd40
> [ 2.045781] [<ffffffff810a7ff2>] lock_acquire+0xd2/0x2a0
> [ 2.045781] [<ffffffff81849da6>] mutex_lock_killable_nested+0x66/0x460
> [ 2.045781] [<ffffffff81229de4>] lock_trace+0x24/0x70
> [ 2.045781] [<ffffffff81229e8f>] proc_pid_stack+0x5f/0xe0
> [ 2.045781] [<ffffffff81227244>] proc_single_show+0x54/0xa0
> [ 2.045781] [<ffffffff811e13a0>] seq_read+0xe0/0x3e0
> [ 2.045781] [<ffffffff811b9377>] vfs_read+0x97/0x180
> [ 2.045781] [<ffffffff811b9f5d>] SyS_read+0x4d/0xc0
> [ 2.045781] [<ffffffff8184e492>] system_call_fastpath+0x12/0x17
> [ 2.045781]
> -> #0 (&p->lock){+.+.+.}:
> [ 2.045781] [<ffffffff810a389f>] validate_chain.isra.36+0xfff/0x1400
> [ 2.045781] [<ffffffff810a6e99>] __lock_acquire+0x4d9/0xd40
> [ 2.045781] [<ffffffff810a7ff2>] lock_acquire+0xd2/0x2a0
> [ 2.045781] [<ffffffff81849629>] mutex_lock_nested+0x69/0x3c0
> [ 2.045781] [<ffffffff811e12fd>] seq_read+0x3d/0x3e0
> [ 2.045781] [<ffffffff81226428>] proc_reg_read+0x48/0x70
> [ 2.045781] [<ffffffff811b9377>] vfs_read+0x97/0x180
> [ 2.045781] [<ffffffff811bf1a8>] kernel_read+0x48/0x60
> [ 2.045781] [<ffffffff811bfb2c>] prepare_binprm+0xdc/0x180
> [ 2.045781] [<ffffffff811c139a>] do_execve_common.isra.29+0x4fa/0x960
> [ 2.045781] [<ffffffff811c1818>] do_execve+0x18/0x20
> [ 2.045781] [<ffffffff811c1b05>] SyS_execve+0x25/0x30
> [ 2.045781] [<ffffffff8184ea49>] stub_execve+0x69/0xa0
> [ 2.045781]
> [ 2.045781] other info that might help us debug this:
> [ 2.045781]
> [ 2.045781] Possible unsafe locking scenario:
> [ 2.045781]
> [ 2.045781] CPU0 CPU1
> [ 2.045781] ---- ----
> [ 2.045781] lock(&sig->cred_guard_mutex);
> [ 2.045781] lock(&p->lock);
> [ 2.045781] lock(&sig->cred_guard_mutex);
> [ 2.045781] lock(&p->lock);
> [ 2.045781]
> [ 2.045781] *** DEADLOCK ***
> [ 2.045781]
> [ 2.045781] 1 lock held by sh/94:
> [ 2.045781] #0: (&sig->cred_guard_mutex){+.+.+.}, at: [<ffffffff811c0e3d>] prepare_bprm_creds+0x2d/0x90
> [ 2.045781]
> [ 2.045781] stack backtrace:
> [ 2.045781] CPU: 0 PID: 94 Comm: sh Not tainted 3.18.0-rc7-00003-g3a18ca061311-dirty #237
> [ 2.045781] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
> [ 2.045781] ffffffff82a48d50 ffff88085427bad8 ffffffff81844a85 0000000000000cac
> [ 2.045781] ffffffff82a654a0 ffff88085427bb28 ffffffff810a1b03 0000000000000000
> [ 2.045781] ffff88085427bb68 ffff88085427bb28 ffff8808547f1500 ffff8808547f1c40
> [ 2.045781] Call Trace:
> [ 2.045781] [<ffffffff81844a85>] dump_stack+0x4e/0x68
> [ 2.045781] [<ffffffff810a1b03>] print_circular_bug+0x203/0x310
> [ 2.045781] [<ffffffff810a389f>] validate_chain.isra.36+0xfff/0x1400
> [ 2.045781] [<ffffffff8108fa76>] ? local_clock+0x16/0x30
> [ 2.045781] [<ffffffff810a6e99>] __lock_acquire+0x4d9/0xd40
> [ 2.045781] [<ffffffff810a7ff2>] lock_acquire+0xd2/0x2a0
> [ 2.045781] [<ffffffff811e12fd>] ? seq_read+0x3d/0x3e0
> [ 2.045781] [<ffffffff81849629>] mutex_lock_nested+0x69/0x3c0
> [ 2.045781] [<ffffffff811e12fd>] ? seq_read+0x3d/0x3e0
> [ 2.045781] [<ffffffff8108f9f8>] ? sched_clock_cpu+0x98/0xc0
> [ 2.045781] [<ffffffff811e12fd>] ? seq_read+0x3d/0x3e0
> [ 2.045781] [<ffffffff814050b9>] ? lockref_put_or_lock+0x29/0x40
> [ 2.045781] [<ffffffff811e12fd>] seq_read+0x3d/0x3e0
> [ 2.045781] [<ffffffff814050b9>] ? lockref_put_or_lock+0x29/0x40
> [ 2.045781] [<ffffffff81226428>] proc_reg_read+0x48/0x70
> [ 2.045781] [<ffffffff811b9377>] vfs_read+0x97/0x180
> [ 2.045781] [<ffffffff811bf1a8>] kernel_read+0x48/0x60
> [ 2.045781] [<ffffffff811bfb2c>] prepare_binprm+0xdc/0x180
> [ 2.045781] [<ffffffff811c139a>] do_execve_common.isra.29+0x4fa/0x960
> [ 2.092142] tsc: Refined TSC clocksource calibration: 2693.484 MHz
> [ 2.045781] [<ffffffff811c0fd3>] ? do_execve_common.isra.29+0x133/0x960
> [ 2.045781] [<ffffffff8184f04d>] ? retint_swapgs+0xe/0x13
> [ 2.045781] [<ffffffff811c1818>] do_execve+0x18/0x20
> [ 2.045781] [<ffffffff811c1b05>] SyS_execve+0x25/0x30
> [ 2.045781] [<ffffffff8184ea49>] stub_execve+0x69/0xa0
^ permalink raw reply
* Re: ovs datapath complains on unexpected mask for netlink commands
From: Or Gerlitz @ 2014-12-03 17:01 UTC (permalink / raw)
To: Jesse Gross; +Cc: Or Gerlitz, Pravin Shelar, netdev@vger.kernel.org
In-Reply-To: <CAEP_g=-g7hH2NtOzdzRMiv+1onk74e0Tny8H0v7zHoqqTvog7Q@mail.gmail.com>
On Tue, Dec 2, 2014 at 1:39 AM, Jesse Gross <jesse@nicira.com> wrote:
> On Thu, Nov 27, 2014 at 9:20 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
>> Hi Jesse,
>>
>> I am running with net-next as of commit 2ad7bf36 "ipvlan: Initial check-in
>> [...]"
>> and user-space OVS v2.0.90 built from the upstream git.
>>
>> I suddenly realized that my kernel logs gets filled with the below
>> prints which effectively take place for each ovs-vsctl command I run...
>>
>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>
> Thanks I see the problem. It looks like Pravin just sent out a patch
> to fix this issue last night - "[PATCH net] openvswitch: Fix flow mask
> validation.".
I see, now (I know the patch wasn't applied yet) on my net clone, the
complaint is a bit different...
openvswitch: netlink: Contain more than allowed mask fields
(mask_attrs=1205c, mask_allowed=19805c).
openvswitch: netlink: Contain more than allowed mask fields
(mask_attrs=19a05c, mask_allowed=19805c).
so same fix for that too?
^ permalink raw reply
* Re: What's the concern about setting irq thread's policy as SCHED_FIFO
From: Rick Jones @ 2014-12-03 16:51 UTC (permalink / raw)
To: Qin Chuanyu, netdev; +Cc: linux-kernel
In-Reply-To: <547EC4A3.6060408@huawei.com>
On 12/03/2014 12:06 AM, Qin Chuanyu wrote:
> I am doing network performance test under suse11sp3 and intel 82599 nic,
> Becasuse the softirq is out of schedule policy's control, so netserver
> thread couldn't always get 100% cpu usage, then packet dropped in kernel
> udp socket's receive queue.
>
> In order to get a stable result, I did some patch in ixgbe driver and
> then use irq_thread instead of softirq to handle rx.
> It seems work well, but irq_thread's SCHED_FIFO schedule policy cause
> that when the cpu is limited, netserver couldn't work at all.
I cannot speak to any scheduling issues/questions, but can ask if you
tried binding netserver to a CPU other than the one servicing the
interrupts via the -T option on the netperf command line:
netperf -T <netperfCPU>,<netserverCPU> ...
http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#index-g_t_002dT_002c-Global-41
happy benchnmarking,
rick jones
>
> So I change the irq_thread's schedule policy from SCHED_FIFO to
> SCHED_NORMAL, then the irq_thread could share the cpu usage with
> netserver thread.
>
> the question is:
> What's the concrete reason about setting irq thread's policy as SCHED_FIFO?
> Except the priority affecting the cpu usage, any function would be
> broken if irq thread change to SCHED_NORMAL?
>
> --
> 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
* Fw: [Bug 89201] New: sendto changes buffer used by recvfrom of other proccesses
From: Stephen Hemminger @ 2014-12-03 16:32 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Wed, 3 Dec 2014 05:51:34 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 89201] New: sendto changes buffer used by recvfrom of other proccesses
https://bugzilla.kernel.org/show_bug.cgi?id=89201
Bug ID: 89201
Summary: sendto changes buffer used by recvfrom of other
proccesses
Product: Networking
Version: 2.5
Kernel Version: 3.4.0-perf-ga6edd5e
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: shemminger@linux-foundation.org
Reporter: tuxmind.bug@gmail.com
Regression: No
hi,
i found a bug with recvfrom/sendto.
the affected kernel is the android one, sources can be found there:
https://android.googlesource.com/kernel/msm/+/android-msm-mako-3.4-kitkat-mr2
configuration:
https://android.googlesource.com/kernel/msm/+/android-msm-mako-3.4-kitkat-mr2/arch/arm/configs/mako_defconfig
description:
when a process call recvfrom on a PF_PACKET/SOCK_RAW socket when another
process
call sendto/write on a socket that use the same interface, the ethernet address
is weird.
recvfrom returns the following ethernet header:
UU:XX:00:00:00:00:AA:AA:03:00:00:00:YY:ZZ
instead of
UU:XX:VV:VV:VV:VV:HH:HH:HH:HH:HH:HH:YY:ZZ
where:
HH:HH:HH:HH:HH:HH is the source MAC address
UU:XX:VV:VV:VV:VV is the destination MAC address
YY:ZZ is the ethernet type
i think that recvfrom save the user buffer pointer somewhere because
perform some 'long' work on the buffer ( like using a printf to debug this
problem ) increase the error rate from 2/9480 bad headers to about 779/4301.
i already opened various bug reports and questions.
external references:
http://stackoverflow.com/questions/27251904/recvfrom-read-wrong-ethernet-address-from-raw-socket
https://code.google.com/p/android/issues/detail?id=81370
step to reproduce:
sample program: http://pastebin.com/kkjUrft9
( you have to change the hardcoded ip address )
> gcc -g -o -DSENDER main.c -o sender
> gcc -g -o main.c -o receiver
> ./receiver wlan0 &
> ./sender wlan0
> Ctrl+C ( SIGINT ) after a while
> fg
> Ctrl+C ( SIGINT )
you should see the amount of sniffed packets and the amount of bad ones.
commenting out the fprintf/fflush calls drastically reduce bad packets count.
thanks in advance for any help.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [PATCH v2 2/6] ethernet/intel: Use eth_skb_pad and skb_put_padto helpers
From: Alexander Duyck @ 2014-12-03 16:17 UTC (permalink / raw)
To: netdev; +Cc: Jeff Kirsher, davem
In-Reply-To: <20141203161440.9223.39633.stgit@ahduyck-vm-fedora20>
Update the Intel Ethernet drivers to use eth_skb_pad() and skb_put_padto
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/e1000e/netdev.c | 8 ++------
drivers/net/ethernet/intel/fm10k/fm10k_main.c | 11 +++--------
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 8 ++------
drivers/net/ethernet/intel/igb/igb_main.c | 19 +++++--------------
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 19 +++++--------------
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 11 +++--------
7 files changed, 22 insertions(+), 62 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/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 370cfa2..88936aa 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5554,12 +5554,8 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
/* The minimum packet size with TCTL.PSP set is 17 bytes so
* pad skb in order to meet this minimum size requirement
*/
- if (unlikely(skb->len < 17)) {
- if (skb_pad(skb, 17 - skb->len))
- return NETDEV_TX_OK;
- skb->len = 17;
- skb_set_tail_pointer(skb, 17);
- }
+ if (skb_put_padto(skb, 17))
+ return NETDEV_TX_OK;
mss = skb_shinfo(skb)->gso_size;
if (mss) {
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_main.c b/drivers/net/ethernet/intel/fm10k/fm10k_main.c
index 8c8deec..a05d228 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/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 3195d82..04b4414 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2399,12 +2399,8 @@ netdev_tx_t i40e_lan_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
/* hardware can't handle really short frames, hardware padding works
* beyond this point
*/
- if (unlikely(skb->len < I40E_MIN_TX_LEN)) {
- if (skb_pad(skb, I40E_MIN_TX_LEN - skb->len))
- return NETDEV_TX_OK;
- skb->len = I40E_MIN_TX_LEN;
- skb_set_tail_pointer(skb, I40E_MIN_TX_LEN);
- }
+ if (skb_put_padto(skb, I40E_MIN_TX_LEN))
+ return NETDEV_TX_OK;
return i40e_xmit_frame_ring(skb, tx_ring);
}
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 6261399..36467cf 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -5091,12 +5091,8 @@ static netdev_tx_t igb_xmit_frame(struct sk_buff *skb,
/* The minimum packet size with TCTL.PSP set is 17 so pad the skb
* in order to meet this minimum size requirement.
*/
- if (unlikely(skb->len < 17)) {
- if (skb_pad(skb, 17 - skb->len))
- return NETDEV_TX_OK;
- skb->len = 17;
- skb_set_tail_pointer(skb, 17);
- }
+ if (skb_put_padto(skb, 17))
+ return NETDEV_TX_OK;
return igb_xmit_frame_ring(skb, igb_tx_queue_mapping(adapter, skb));
}
@@ -6847,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 23d72a2..702cc64 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1755,14 +1755,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;
}
@@ -7248,12 +7243,8 @@ static netdev_tx_t __ixgbe_xmit_frame(struct sk_buff *skb,
* The minimum packet size for olinfo paylen is 17 so pad the skb
* in order to meet this minimum size requirement.
*/
- if (unlikely(skb->len < 17)) {
- if (skb_pad(skb, 17 - skb->len))
- return NETDEV_TX_OK;
- skb->len = 17;
- skb_set_tail_pointer(skb, 17);
- }
+ if (skb_put_padto(skb, 17))
+ return NETDEV_TX_OK;
tx_ring = ring ? ring : adapter->tx_ring[skb->queue_mapping];
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
* Re: [PATCH] SSB / B44: fix WOL for BCM4401
From: Michael Büsch @ 2014-12-03 16:23 UTC (permalink / raw)
To: John W. Linville
Cc: Larry Finger, Andrey Skvortsov, Rafael J. Wysocki, Gary.Zambrano,
netdev, linux-kernel, b43-dev, Rafał Miłecki
In-Reply-To: <20141203161452.GD2896@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 2714 bytes --]
On Wed, 3 Dec 2014 11:14:52 -0500
"John W. Linville" <linville@tuxdriver.com> wrote:
> On Wed, Dec 03, 2014 at 04:18:55PM +0100, Michael Büsch wrote:
> > On Tue, 02 Dec 2014 16:23:49 -0600
> > Larry Finger <Larry.Finger@lwfinger.net> wrote:
> >
> > > On 12/02/2014 02:12 PM, Michael Büsch wrote:
> > > > On Tue, 2 Dec 2014 23:01:29 +0300
> > > > Andrey Skvortsov <andrej.skvortzov@gmail.com> wrote:
> > > >
> > > >> On Mon, Dec 01, 2014 at 10:10:23PM +0100, Michael Büsch wrote:
> > > >>> On Mon, 1 Dec 2014 23:46:38 +0300
> > > >>> Andrey Skvortsov <andrej.skvortzov@gmail.com> wrote:
> > > >>>
> > > >>>> Wake On Lan was not working on laptop DELL Vostro 1500.
> > > >>>> If WOL was turned on, BCM4401 was powered up in suspend mode. LEDs blinked.
> > > >>>> But the laptop could not be woken up with the Magic Packet. The reason for
> > > >>>> that was that PCIE was not enabled as a system wakeup source and
> > > >>>> therefore the host PCI bridge was not powered up in suspend mode.
> > > >>>> PCIE was not enabled in suspend by PM because no child devices were
> > > >>>> registered as wakeup source during suspend process.
> > > >>>> On laptop BCM4401 is connected through the SSB bus, that is connected to the
> > > >>>> PCI-Express bus. SSB and B44 did not use standard PM wakeup functions
> > > >>>> and did not forward wakeup settings to their parents.
> > > >>>> To fix that B44 driver enables PM wakeup and registers new wakeup source
> > > >>>> using device_set_wakeup_enable(). Wakeup is automatically reported to the parent SSB
> > > >>>> bus via power.wakeup_path. SSB bus enables wakeup for the parent PCI bridge, if there is any
> > > >>>> child devices with enabled wakeup functionality. All other steps are
> > > >>>> done by PM core code.
> > > >>>
> > > >>> Thanks, this looks good.
> > > >>> I assume you tested this (I currently don't have a device to test this).
> > > >>
> > > >> Sure, I've tested it. WOL from suspend is working and after resume from hibernate Ethernet is working too.
> > > >
> > > > That sounds good, indeed.
> > > > I'd still prefer, if someone with b43 (wireless) would test it, too.
> > >
> > > I did a partial test with my PowerBook G4. With the patch installed, it would
> > > both suspend and hibernate, but WOL would be impossible. This computer uses a
> > > PCMCIA version of the BCM4318, and power is turned off to the PCMCIA card when
> > > suspended or hibernating.
> >
> > Thanks for testing.
> >
> > John, can you take this one? Or do we need to split the b44 part out?
> > I added my Signed-off.
>
> Um, sure...3.19 is OK I presume?
I think we could even wait for 3.20.
--
Michael
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH v2 6/6] r8169: Use eth_skb_pad function
From: Alexander Duyck @ 2014-12-03 16:18 UTC (permalink / raw)
To: netdev; +Cc: Realtek linux nic maintainers, davem
In-Reply-To: <20141203161440.9223.39633.stgit@ahduyck-vm-fedora20>
Replace rtl_skb_pad with eth_skb_pad since they do the same thing.
Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
---
drivers/net/ethernet/realtek/r8169.c | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index cf154f7..e9b44fc 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6832,14 +6832,6 @@ err_out:
return -EIO;
}
-static bool rtl_skb_pad(struct sk_buff *skb)
-{
- if (skb_padto(skb, ETH_ZLEN))
- return false;
- skb_put(skb, ETH_ZLEN - skb->len);
- return true;
-}
-
static bool rtl_test_hw_pad_bug(struct rtl8169_private *tp, struct sk_buff *skb)
{
return skb->len < ETH_ZLEN && tp->mac_version == RTL_GIGA_MAC_VER_34;
@@ -6980,7 +6972,7 @@ static bool rtl8169_tso_csum_v2(struct rtl8169_private *tp,
u8 ip_protocol;
if (unlikely(rtl_test_hw_pad_bug(tp, skb)))
- return skb_checksum_help(skb) == 0 && rtl_skb_pad(skb);
+ return !(skb_checksum_help(skb) || eth_skb_pad(skb));
if (transport_offset > TCPHO_MAX) {
netif_warn(tp, tx_err, tp->dev,
@@ -7015,7 +7007,7 @@ static bool rtl8169_tso_csum_v2(struct rtl8169_private *tp,
opts[1] |= transport_offset << TCPHO_SHIFT;
} else {
if (unlikely(rtl_test_hw_pad_bug(tp, skb)))
- return rtl_skb_pad(skb);
+ return !eth_skb_pad(skb);
}
return true;
^ permalink raw reply related
* [PATCH v2 5/6] myri10ge: use eth_skb_pad helper
From: Alexander Duyck @ 2014-12-03 16:17 UTC (permalink / raw)
To: netdev; +Cc: Hyong-Youb Kim, davem
In-Reply-To: <20141203161440.9223.39633.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
* [PATCH v2 4/6] niu: Use eth_skb_pad helper
From: Alexander Duyck @ 2014-12-03 16:17 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <20141203161440.9223.39633.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
* [PATCH v2 3/6] emulex: Use skb_put_padto instead of skb_padto() and skb->len assignment
From: Alexander Duyck @ 2014-12-03 16:17 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <20141203161440.9223.39633.stgit@ahduyck-vm-fedora20>
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index e0ab767..9461ad8 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -1017,9 +1017,8 @@ static struct sk_buff *be_xmit_workarounds(struct be_adapter *adapter,
* to pad short packets (<= 32 bytes) to a 36-byte length.
*/
if (unlikely(!BEx_chip(adapter) && skb->len <= 32)) {
- if (skb_padto(skb, 36))
+ if (skb_put_padto(skb, 36))
return NULL;
- skb->len = 36;
}
if (BEx_chip(adapter) || lancer_chip(adapter)) {
^ 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