* [PATCHv2 0/2] forcedeth: recv cache to make NIC work steadily
From: Zhu Yanjun @ 2019-07-21 12:53 UTC (permalink / raw)
To: yanjun.zhu, davem, netdev
These patches are to this scenario:
"
When the host run for long time, there are a lot of memory fragments in
the hosts. And it is possible that kernel will compact memory fragments.
But normally it is difficult for NIC driver to allocate a memory from
kernel. From this variable stat_rx_dropped, we can confirm that NIC driver
can not allocate skb very frequently.
"
Since NIC driver can not allocate skb in time, this makes some important
tasks not be completed in time.
To avoid it, a recv cache is created to pre-allocate skb for NIC driver.
This can make the important tasks be completed in time.
From Nan's tests in LAB, these patches can make NIC driver work steadily.
Now in production hosts, these patches are applied.
With these patches, one NIC port needs 125MiB reserved. This 125MiB memory
can not be used by others. To a host on which the communications are not
mandatory, it is not necessary to reserve so much memory. So this recv cache
is disabled by default.
V1->V2:
1. ndelay is replaced with GFP_KERNEL function __netdev_alloc_skb.
2. skb_queue_purge is used when recv cache is destroyed.
3. RECV_LIST_ALLOCATE bit is removed.
4. schedule_delayed_work is moved out of while loop.
Zhu Yanjun (2):
forcedeth: add recv cache make nic work steadily
forcedeth: disable recv cache by default
drivers/net/ethernet/nvidia/Kconfig | 11 +++
drivers/net/ethernet/nvidia/Makefile | 1 +
drivers/net/ethernet/nvidia/forcedeth.c | 129 +++++++++++++++++++++++++++++++-
3 files changed, 139 insertions(+), 2 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH net] kbuild: add net/netfilter/nf_tables_offload.h to header-test blacklist.
From: Jeremy Sowden @ 2019-07-21 11:31 UTC (permalink / raw)
To: Netdev; +Cc: Pablo Neira Ayuso, Jakub Kicinski
In-Reply-To: <20190719100743.2ea14575@cakuba.netronome.com>
net/netfilter/nf_tables_offload.h includes net/netfilter/nf_tables.h
which is itself on the blacklist.
Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Jeremy Sowden <jeremy@azazel.net>
---
include/Kbuild | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/Kbuild b/include/Kbuild
index 7e9f1acb9dd5..8de846a83d8f 100644
--- a/include/Kbuild
+++ b/include/Kbuild
@@ -909,6 +909,7 @@ header-test- += net/netfilter/nf_tables.h
header-test- += net/netfilter/nf_tables_core.h
header-test- += net/netfilter/nf_tables_ipv4.h
header-test- += net/netfilter/nf_tables_ipv6.h
+header-test- += net/netfilter/nf_tables_offload.h
header-test- += net/netfilter/nft_fib.h
header-test- += net/netfilter/nft_meta.h
header-test- += net/netfilter/nft_reject.h
--
2.20.1
^ permalink raw reply related
* Re: ENOBUILD in nf_tables
From: Jeremy Sowden @ 2019-07-21 11:15 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Jakub Kicinski, netdev@vger.kernel.org
In-Reply-To: <20190720074443.nteynyxuptizbkdx@salvia>
[-- Attachment #1: Type: text/plain, Size: 697 bytes --]
On 2019-07-20, at 09:44:43 +0200, Pablo Neira Ayuso wrote:
> On Fri, Jul 19, 2019 at 10:07:43AM -0700, Jakub Kicinski wrote:
> > I hit the following build breakage on net with the config attached.
> >
> > GCC 9, doesn't seem like your just-posted series fixes this?
>
> $ gcc -v
> ...
> gcc version 9.1.0
>
> $ make
> ...
> CC include/net/netfilter/nf_tables_offload.h.s
> ...
> $
>
> Works for me here.
I think the compiler version is a red herring. I reproduced the failure
with gcc-8 (Debian 8.3.0-6) and gcc-9 (Debian 9.1.0-4). The problem is
that CONFIG_HEADER_TEST is defined and nf_tables_offload.h is not on the
header-test blacklist, but includes nf_tables.h, which is.
J.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] tipc: Fix a typo
From: Christophe JAILLET @ 2019-07-21 10:38 UTC (permalink / raw)
To: jon.maloy, ying.xue, davem
Cc: netdev, tipc-discussion, linux-kernel, kernel-janitors,
Christophe JAILLET
s/tipc_toprsv_listener_data_ready/tipc_topsrv_listener_data_ready/
(r and s switched in topsrv)
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
The function name could also be removed from the comment. It does not
bring any useful information IMHO.
---
net/tipc/topsrv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tipc/topsrv.c b/net/tipc/topsrv.c
index f345662890a6..ca8ac96d22a9 100644
--- a/net/tipc/topsrv.c
+++ b/net/tipc/topsrv.c
@@ -476,7 +476,7 @@ static void tipc_topsrv_accept(struct work_struct *work)
}
}
-/* tipc_toprsv_listener_data_ready - interrupt callback with connection request
+/* tipc_topsrv_listener_data_ready - interrupt callback with connection request
* The queued job is launched into tipc_topsrv_accept()
*/
static void tipc_topsrv_listener_data_ready(struct sock *sk)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] rat_cs: Remove duplicate code
From: Stefano Brivio @ 2019-07-21 9:12 UTC (permalink / raw)
To: Hariprasad Kelam
Cc: Kalle Valo, David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <20190720174613.GA31062@hari-Inspiron-1545>
On Sat, 20 Jul 2019 23:16:47 +0530
Hariprasad Kelam <hariprasad.kelam@gmail.com> wrote:
> Code is same if translate is true/false in case invalid packet is
> received.So remove else part.
>
> Issue identified with coccicheck
>
> Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
> ---
> drivers/net/wireless/ray_cs.c | 29 ++++++++---------------------
> 1 file changed, 8 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/wireless/ray_cs.c b/drivers/net/wireless/ray_cs.c
> index cf37268..a51bbe7 100644
> --- a/drivers/net/wireless/ray_cs.c
> +++ b/drivers/net/wireless/ray_cs.c
> @@ -2108,29 +2108,16 @@ static void rx_data(struct net_device *dev, struct rcs __iomem *prcs,
> #endif
>
> if (!sniffer) {
> - if (translate) {
> /* TBD length needs fixing for translated header */
> - if (rx_len < (ETH_HLEN + RX_MAC_HEADER_LENGTH) ||
> - rx_len >
> - (dev->mtu + RX_MAC_HEADER_LENGTH + ETH_HLEN +
> - FCS_LEN)) {
> - pr_debug(
> - "ray_cs invalid packet length %d received\n",
> - rx_len);
> - return;
> - }
> - } else { /* encapsulated ethernet */
> -
> - if (rx_len < (ETH_HLEN + RX_MAC_HEADER_LENGTH) ||
> - rx_len >
> - (dev->mtu + RX_MAC_HEADER_LENGTH + ETH_HLEN +
> - FCS_LEN)) {
> - pr_debug(
> - "ray_cs invalid packet length %d received\n",
> - rx_len);
> - return;
> + if (rx_len < (ETH_HLEN + RX_MAC_HEADER_LENGTH) ||
> + rx_len >
> + (dev->mtu + RX_MAC_HEADER_LENGTH + ETH_HLEN +
> + FCS_LEN)) {
> + pr_debug(
> + "ray_cs invalid packet length %d received\n",
> + rx_len);
> + return;
> }
> - }
NACK. The TBD comment makes no sense anymore if you remove one of the
branches. Believe me or not, I have one of those cards, a (yes, 22
years old) Buslink Raytheon model 24020. That check needed (for sure)
and needs (maybe) to be fixed.
Besides, patch subject and resulting coding style are also wrong.
--
Stefano
^ permalink raw reply
* [PATCH] allocate_flower_entry: should check for null deref
From: Navid Emamdoost @ 2019-07-21 6:37 UTC (permalink / raw)
Cc: kjlu, smccaman, secalert, emamd001, Navid Emamdoost,
Vishal Kulkarni, David S. Miller, netdev, linux-kernel
allocate_flower_entry does not check for allocation success, but tries
to deref the result. I only moved the spin_lock under null check, because
the caller is checking allocation's status at line 652.
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
index 312599c6b35a..e447976bdd3e 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
@@ -67,7 +67,8 @@ static struct ch_tc_pedit_fields pedits[] = {
static struct ch_tc_flower_entry *allocate_flower_entry(void)
{
struct ch_tc_flower_entry *new = kzalloc(sizeof(*new), GFP_KERNEL);
- spin_lock_init(&new->lock);
+ if (new)
+ spin_lock_init(&new->lock);
return new;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] netfilter: ebtables: compat: fix a memory leak bug
From: Florian Westphal @ 2019-07-21 0:26 UTC (permalink / raw)
To: Wenwen Wang
Cc: Wenwen Wang, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, Roopa Prabhu, Nikolay Aleksandrov,
David S. Miller, open list:NETFILTER, open list:NETFILTER,
moderated list:ETHERNET BRIDGE, open list:ETHERNET BRIDGE,
open list
In-Reply-To: <1563625366-3602-1-git-send-email-wang6495@umn.edu>
Wenwen Wang <wang6495@umn.edu> wrote:
> From: Wenwen Wang <wenwen@cs.uga.edu>
>
> In compat_do_replace(), a temporary buffer is allocated through vmalloc()
> to hold entries copied from the user space. The buffer address is firstly
> saved to 'newinfo->entries', and later on assigned to 'entries_tmp'. Then
> the entries in this temporary buffer is copied to the internal kernel
> structure through compat_copy_entries(). If this copy process fails,
> compat_do_replace() should be terminated. However, the allocated temporary
> buffer is not freed on this path, leading to a memory leak.
>
> To fix the bug, free the buffer before returning from compat_do_replace().
>
> Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Reviewed-by: Florian Westphal <fw@strlen.de>
^ permalink raw reply
* Re: WARNING in xt_compat_add_offset
From: syzbot @ 2019-07-20 23:55 UTC (permalink / raw)
To: bridge, coreteam, davem, fw, kadlec, kadlec, linux-kernel, netdev,
netfilter-devel, nikolay, pablo, roopa, syzkaller-bugs
In-Reply-To: <00000000000081994205827ea9a0@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: abdfd52a Merge tag 'armsoc-defconfig' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=146c4968600000
kernel config: https://syzkaller.appspot.com/x/.config?x=b8e53b1e149c0183
dashboard link: https://syzkaller.appspot.com/bug?extid=276ddebab3382bbf72db
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
userspace arch: i386
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=159be500600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=139364f0600000
The bug was bisected to:
commit 2035f3ff8eaa29cfb5c8e2160b0f6e85eeb21a95
Author: Florian Westphal <fw@strlen.de>
Date: Mon Jan 21 20:54:36 2019 +0000
netfilter: ebtables: compat: un-break 32bit setsockopt when no rules
are present
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1462834d200000
final crash: https://syzkaller.appspot.com/x/report.txt?x=1662834d200000
console output: https://syzkaller.appspot.com/x/log.txt?x=1262834d200000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+276ddebab3382bbf72db@syzkaller.appspotmail.com
Fixes: 2035f3ff8eaa ("netfilter: ebtables: compat: un-break 32bit
setsockopt when no rules are present")
------------[ cut here ]------------
WARNING: CPU: 1 PID: 9012 at net/netfilter/x_tables.c:649
xt_compat_add_offset.cold+0x11/0x36 /net/netfilter/x_tables.c:649
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 9012 Comm: syz-executor131 Not tainted 5.2.0+ #64
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack /lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 /lib/dump_stack.c:113
panic+0x2dc/0x755 /kernel/panic.c:219
__warn.cold+0x20/0x4c /kernel/panic.c:576
report_bug+0x263/0x2b0 /lib/bug.c:186
fixup_bug /arch/x86/kernel/traps.c:179 [inline]
fixup_bug /arch/x86/kernel/traps.c:174 [inline]
do_error_trap+0x11b/0x200 /arch/x86/kernel/traps.c:272
do_invalid_op+0x37/0x50 /arch/x86/kernel/traps.c:291
invalid_op+0x14/0x20 /arch/x86/entry/entry_64.S:1008
RIP: 0010:xt_compat_add_offset.cold+0x11/0x36 /net/netfilter/x_tables.c:649
Code: 89 ee 48 c7 c7 c0 29 2d 88 e8 0c 76 7b fb 41 bc ea ff ff ff e9 87 88
ff ff e8 08 d3 91 fb 48 c7 c7 00 2a 2d 88 e8 f0 75 7b fb <0f> 0b 41 bc f4
ff ff ff e9 01 8b ff ff e8 ea d2 91 fb 48 c7 c7 00
RSP: 0018:ffff8880a382f8d8 EFLAGS: 00010286
RAX: 0000000000000024 RBX: ffff888216b74ad0 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff815c3a26 RDI: ffffed1014705f0d
RBP: ffff8880a382f908 R08: 0000000000000024 R09: ffffed1015d260b1
R10: ffffed1015d260b0 R11: ffff8880ae930587 R12: 0000000000000014
R13: 0000000000000060 R14: ffff88808b7b6180 R15: 0000000000000000
size_entry_mwt /net/bridge/netfilter/ebtables.c:2122 [inline]
compat_copy_entries+0x10e9/0x1340 /net/bridge/netfilter/ebtables.c:2147
compat_do_replace+0x3b3/0x680 /net/bridge/netfilter/ebtables.c:2243
compat_do_ebt_set_ctl+0x22f/0x27e /net/bridge/netfilter/ebtables.c:2325
compat_nf_sockopt /net/netfilter/nf_sockopt.c:144 [inline]
compat_nf_setsockopt+0x98/0x140 /net/netfilter/nf_sockopt.c:156
compat_ip_setsockopt /net/ipv4/ip_sockglue.c:1286 [inline]
compat_ip_setsockopt+0x106/0x140 /net/ipv4/ip_sockglue.c:1267
compat_raw_setsockopt+0xe0/0x100 /net/ipv4/raw.c:865
compat_sock_common_setsockopt+0xb2/0x140 /net/core/sock.c:3141
__compat_sys_setsockopt+0x185/0x380 /net/compat.c:384
__do_compat_sys_setsockopt /net/compat.c:397 [inline]
__se_compat_sys_setsockopt /net/compat.c:394 [inline]
__ia32_compat_sys_setsockopt+0xbd/0x150 /net/compat.c:394
do_syscall_32_irqs_on /arch/x86/entry/common.c:332 [inline]
do_fast_syscall_32+0x27b/0xdb3 /arch/x86/entry/common.c:403
entry_SYSENTER_compat+0x70/0x7f /arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7f489c9
Code: d3 83 c4 10 5b 5e 5d c3 ba 80 96 98 00 eb a9 8b 04 24 c3 8b 34 24 c3
8b 3c 24 c3 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90
90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 002b:00000000ffaa6d8c EFLAGS: 00000292 ORIG_RAX: 000000000000016e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000000000
RDX: 0000000000000080 RSI: 0000000020000000 RDI: 00000000000001fc
RBP: 0000000000000012 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Kernel Offset: disabled
Rebooting in 86400 seconds..
^ permalink raw reply
* Re: linux-headers-5.2 and proper use of SIOCGSTAMP
From: Arnd Bergmann @ 2019-07-20 20:40 UTC (permalink / raw)
To: Florian Weimer
Cc: Sergei Trofimovich, Networking, Linux Kernel Mailing List,
GNU C Library, David S. Miller, Michael Kerrisk, linux-man
In-Reply-To: <87muh8a4a3.fsf@mid.deneb.enyo.de>
On Sat, Jul 20, 2019 at 9:34 PM Florian Weimer <fw@deneb.enyo.de> wrote:
> * Arnd Bergmann:
> > On Sat, Jul 20, 2019 at 8:10 PM Florian Weimer <fw@deneb.enyo.de> wrote:
> > As far as I can tell, nobody thought it would be a problem to move it
> > from asm/sockios.h to linux/sockios.h, as the general rule is that one
> > should use the linux/*.h version if both exist, and that the asm/*.h
> > version only contains architecture specific definitions. The new
> > definition is the same across all architectures, so it made sense to
> > have it in the common file.
>
> Most of the socket-related constants are not exposed in UAPI headers,
> although userspace is expected to use them. It seems to me that due
> to the lack of other options among the UAPI headers, <asm/socket.h>
> has been a dumping ground for various socket-related things in the
> past, whether actually architecture-specific or not.
>
> <linux/socket.h> does not include <asm/socket.h>, so that's why we
> usually end up with including <asm/socket.h> (perhaps indirectly via
> <sys/socket.h>), which used to include <asm/sockios.h> on most (all?)
> architectures. That in turn provided some of the SIOC* constants in
> the past, so people didn't investigate other options.
It seems that both the missing constants and the fact that
linux/socket.h doesn't include asm/socket.h and linux/sockios.h
goes back to a 21 year old commit:
commit 74f513101058f7585176ea8cdf6fb026faea8a7e
Author: linus1 <torvalds@linuxfoundation.org>
Date: Wed May 20 11:00:00 1998 -0800
[tytso] include/asm-i386/posix_types.h
This quick fix eliminates a lot of warning messages when
compiling e2fsprogs under glibc. This is because the glibc header files
defines its own version of FD_SET, FD_ZERO, etc., and so if you need to
#include the kernel include files, you get a lot of duplicate defined
macro warning messages. This patch simply #ifdef's out the kernel
versions of these function if the kernel is not being compiled and the
glibc header files are in use.
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 08f0d281401c..35a7629b6b70 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -1,6 +1,8 @@
#ifndef _LINUX_SOCKET_H
#define _LINUX_SOCKET_H
+#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)
+
#include <asm/socket.h> /* arch-dependent
defines */
#include <linux/sockios.h> /* the SIOCxxx I/O controls */
#include <linux/uio.h> /* iovec support */
@@ -256,4 +258,5 @@ extern int move_addr_to_user(void *kaddr, int
klen, void *uaddr, int *ulen);
extern int move_addr_to_kernel(void *uaddr, int ulen, void *kaddr);
extern int put_cmsg(struct msghdr*, int level, int type, int len, void *data);
#endif
+#endif /* not kernel and not glibc */
#endif /* _LINUX_SOCKET_H */
(the same commit did similar changes in linux/stat.h and asm/posix_types.h)
Over time, the check for glibc was removed (to allow including linux/socket.h
before sys/socket.h), and all the #ifdef __KERNEL__ bits were removed
from the installed header as part of the uapi header split.
> I think we can change glibc to include <linux/sockios.h> in addition
> to <asm/socket.h>. <linux/sockios.h> looks reasonably clean to me,
> much better than <asm/socket.h>.
That seems reasonable to me, but overall my fear is that these headers
are already so broken that any change will risk breaking something
in more or less unexpected ways.
Arnd
^ permalink raw reply related
* pull-request: mac80211 2019-07-20
From: Johannes Berg @ 2019-07-20 20:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Sorry, this really should've gone out much earlier, in partilar
the vendor command fixes. Not much for now, more -next material
will come later.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 1a03bb532934e90c7d662f7c59f4f66ea8451fa4:
r8169: fix RTL8168g PHY init (2019-07-20 12:17:45 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2019-07-20
for you to fetch changes up to d2b3fe42bc629c2d4002f652b3abdfb2e72991c7:
mac80211: don't warn about CW params when not using them (2019-07-20 21:40:32 +0200)
----------------------------------------------------------------
We have a handful of fixes:
* ignore bad CW parameters if we aren't using them,
instead of warning
* fix operation (and then build) with the new netlink vendor
command policy requirement
* fix a memory leak in an error path when setting beacons
----------------------------------------------------------------
Brian Norris (1):
mac80211: don't warn about CW params when not using them
Johannes Berg (2):
wireless: fix nl80211 vendor commands
nl80211: fix VENDOR_CMD_RAW_DATA
John Crispin (1):
nl80211: fix NL80211_HE_MAX_CAPABILITY_LEN
Lorenzo Bianconi (1):
mac80211: fix possible memory leak in ieee80211_assign_beacon
drivers/net/wireless/ath/wil6210/cfg80211.c | 4 ++++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c | 1 +
drivers/net/wireless/ti/wlcore/vendor_cmd.c | 3 +++
include/net/cfg80211.h | 2 +-
include/uapi/linux/nl80211.h | 2 +-
net/mac80211/cfg.c | 8 ++++++--
net/mac80211/driver-ops.c | 13 +++++++++----
7 files changed, 25 insertions(+), 8 deletions(-)
^ permalink raw reply
* Re: linux-headers-5.2 and proper use of SIOCGSTAMP
From: Florian Weimer @ 2019-07-20 19:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sergei Trofimovich, Networking, Linux Kernel Mailing List,
GNU C Library, David S. Miller, Michael Kerrisk, linux-man
In-Reply-To: <CAK8P3a3s3OeBj1MviaJV2UR0eUhF0GKPBi1iFf_3QKQyNPkuqw@mail.gmail.com>
* Arnd Bergmann:
> On Sat, Jul 20, 2019 at 8:10 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>>
>> * Sergei Trofimovich:
>>
>> > Should #include <linux/sockios.h> always be included by user app?
>> > Or should glibc tweak it's definition of '#include <sys/socket.h>'
>> > to make it available on both old and new version of linux headers?
>>
>> What is the reason for dropping SIOCGSTAMP from <asm/socket.h>?
>>
>> If we know that, it will be much easier to decide what to do about
>> <sys/socket.h>.
>
> As far as I can tell, nobody thought it would be a problem to move it
> from asm/sockios.h to linux/sockios.h, as the general rule is that one
> should use the linux/*.h version if both exist, and that the asm/*.h
> version only contains architecture specific definitions. The new
> definition is the same across all architectures, so it made sense to
> have it in the common file.
Most of the socket-related constants are not exposed in UAPI headers,
although userspace is expected to use them. It seems to me that due
to the lack of other options among the UAPI headers, <asm/socket.h>
has been a dumping ground for various socket-related things in the
past, whether actually architecture-specific or not.
<linux/socket.h> does not include <asm/socket.h>, so that's why we
usually end up with including <asm/socket.h> (perhaps indirectly via
<sys/socket.h>), which used to include <asm/sockios.h> on most (all?)
architectures. That in turn provided some of the SIOC* constants in
the past, so people didn't investigate other options.
I think we can change glibc to include <linux/sockios.h> in addition
to <asm/socket.h>. <linux/sockios.h> looks reasonably clean to me,
much better than <asm/socket.h>. I'm still working on the other
breakage, and I'm severely limited by the machine resources I have
access to.
^ permalink raw reply
* Re: [PATCH net] r8169: fix RTL8168g PHY init
From: David Miller @ 2019-07-20 19:18 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev, tv
In-Reply-To: <eeb20312-1418-24c3-6482-09c051075b9e@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat, 20 Jul 2019 19:01:22 +0200
> From: Thomas Voegtle <tv@lio96.de>
> This fixes a copy&paste error in the original patch. Setting the wrong
> register resulted in massive packet loss on some systems.
>
> Fixes: a2928d28643e ("r8169: use paged versions of phylib MDIO access functions")
> Tested-by: Thomas Voegtle <tv@lio96.de>
> Signed-off-by: Thomas Voegtle <tv@lio96.de>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: linux-headers-5.2 and proper use of SIOCGSTAMP
From: Arnd Bergmann @ 2019-07-20 18:50 UTC (permalink / raw)
To: Florian Weimer
Cc: Sergei Trofimovich, Networking, Linux Kernel Mailing List,
GNU C Library, David S. Miller, Michael Kerrisk, linux-man
In-Reply-To: <87wogca86l.fsf@mid.deneb.enyo.de>
On Sat, Jul 20, 2019 at 8:10 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * Sergei Trofimovich:
>
> > Should #include <linux/sockios.h> always be included by user app?
> > Or should glibc tweak it's definition of '#include <sys/socket.h>'
> > to make it available on both old and new version of linux headers?
>
> What is the reason for dropping SIOCGSTAMP from <asm/socket.h>?
>
> If we know that, it will be much easier to decide what to do about
> <sys/socket.h>.
As far as I can tell, nobody thought it would be a problem to move it
from asm/sockios.h to linux/sockios.h, as the general rule is that one
should use the linux/*.h version if both exist, and that the asm/*.h
version only contains architecture specific definitions. The new
definition is the same across all architectures, so it made sense to
have it in the common file.
If the assumption was wrong, the obvious solution is to duplicate the
definitions everywhere or move the common parts into
asm-generic/sockios.h, but it would have been better to hear about
that earlier.
Arnd
^ permalink raw reply
* Re: linux-headers-5.2 and proper use of SIOCGSTAMP
From: Florian Weimer @ 2019-07-20 18:10 UTC (permalink / raw)
To: Sergei Trofimovich
Cc: netdev, linux-kernel, libc-alpha, Arnd Bergmann, David S. Miller,
mtk.manpages, linux-man
In-Reply-To: <20190720174844.4b989d34@sf>
* Sergei Trofimovich:
> Should #include <linux/sockios.h> always be included by user app?
> Or should glibc tweak it's definition of '#include <sys/socket.h>'
> to make it available on both old and new version of linux headers?
What is the reason for dropping SIOCGSTAMP from <asm/socket.h>?
If we know that, it will be much easier to decide what to do about
<sys/socket.h>.
^ permalink raw reply
* [PATCH] rat_cs: Remove duplicate code
From: Hariprasad Kelam @ 2019-07-20 17:46 UTC (permalink / raw)
To: Kalle Valo, David S. Miller, linux-wireless, netdev, linux-kernel
Code is same if translate is true/false in case invalid packet is
received.So remove else part.
Issue identified with coccicheck
Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
---
drivers/net/wireless/ray_cs.c | 29 ++++++++---------------------
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/drivers/net/wireless/ray_cs.c b/drivers/net/wireless/ray_cs.c
index cf37268..a51bbe7 100644
--- a/drivers/net/wireless/ray_cs.c
+++ b/drivers/net/wireless/ray_cs.c
@@ -2108,29 +2108,16 @@ static void rx_data(struct net_device *dev, struct rcs __iomem *prcs,
#endif
if (!sniffer) {
- if (translate) {
/* TBD length needs fixing for translated header */
- if (rx_len < (ETH_HLEN + RX_MAC_HEADER_LENGTH) ||
- rx_len >
- (dev->mtu + RX_MAC_HEADER_LENGTH + ETH_HLEN +
- FCS_LEN)) {
- pr_debug(
- "ray_cs invalid packet length %d received\n",
- rx_len);
- return;
- }
- } else { /* encapsulated ethernet */
-
- if (rx_len < (ETH_HLEN + RX_MAC_HEADER_LENGTH) ||
- rx_len >
- (dev->mtu + RX_MAC_HEADER_LENGTH + ETH_HLEN +
- FCS_LEN)) {
- pr_debug(
- "ray_cs invalid packet length %d received\n",
- rx_len);
- return;
+ if (rx_len < (ETH_HLEN + RX_MAC_HEADER_LENGTH) ||
+ rx_len >
+ (dev->mtu + RX_MAC_HEADER_LENGTH + ETH_HLEN +
+ FCS_LEN)) {
+ pr_debug(
+ "ray_cs invalid packet length %d received\n",
+ rx_len);
+ return;
}
- }
}
pr_debug("ray_cs rx_data packet\n");
/* If fragmented packet, verify sizes of fragments add up */
--
2.7.4
^ permalink raw reply related
* [PATCH net] r8169: fix RTL8168g PHY init
From: Heiner Kallweit @ 2019-07-20 17:01 UTC (permalink / raw)
To: David Miller, Realtek linux nic maintainers
Cc: netdev@vger.kernel.org, Thomas Voegtle
From: Thomas Voegtle <tv@lio96.de>
This fixes a copy&paste error in the original patch. Setting the wrong
register resulted in massive packet loss on some systems.
Fixes: a2928d28643e ("r8169: use paged versions of phylib MDIO access functions")
Tested-by: Thomas Voegtle <tv@lio96.de>
Signed-off-by: Thomas Voegtle <tv@lio96.de>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index 0637c6752..6272115b2 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -3251,9 +3251,9 @@ static void rtl8168g_1_hw_phy_config(struct rtl8169_private *tp)
ret = phy_read_paged(tp->phydev, 0x0a46, 0x13);
if (ret & BIT(8))
- phy_modify_paged(tp->phydev, 0x0c41, 0x12, 0, BIT(1));
+ phy_modify_paged(tp->phydev, 0x0c41, 0x15, 0, BIT(1));
else
- phy_modify_paged(tp->phydev, 0x0c41, 0x12, BIT(1), 0);
+ phy_modify_paged(tp->phydev, 0x0c41, 0x15, BIT(1), 0);
/* Enable PHY auto speed down */
phy_modify_paged(tp->phydev, 0x0a44, 0x11, 0, BIT(3) | BIT(2));
--
2.22.0
^ permalink raw reply related
* linux-headers-5.2 and proper use of SIOCGSTAMP
From: Sergei Trofimovich @ 2019-07-20 16:48 UTC (permalink / raw)
To: netdev, linux-kernel, libc-alpha
Cc: Arnd Bergmann, David S. Miller, mtk.manpages, linux-man
Commit https://github.com/torvalds/linux/commit/0768e17073dc527ccd18ed5f96ce85f9985e9115
("net: socket: implement 64-bit timestamps") caused a bit of userspace breakage
for existing programs:
- firefox: https://bugs.gentoo.org/689808
- qemu: https://lists.sr.ht/~philmd/qemu/%3C20190604071915.288045-1-borntraeger%40de.ibm.com%3E
- linux-atm: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dialup/linux-atm/files/linux-atm-2.5.2-linux-5.2-SIOCGSTAMP.patch?id=408621819a85bf67a73efd33a06ea371c20ea5a2
I have a question: how a well-behaved app should include 'SIOCGSTAMP'
definition to keep being buildable against old and new linux-headers?
'man 7 socket' explicitly mentions SIOCGSTAMP and mentions only
#include <sys/socket.h>
as needed header.
Should #include <linux/sockios.h> always be included by user app?
Or should glibc tweak it's definition of '#include <sys/socket.h>'
to make it available on both old and new version of linux headers?
CCing both kernel and glibc folk as I don't understand on which
side issue should be fixed.
Thanks!
--
Sergei
^ permalink raw reply
* Re: network problems with r8169
From: Heiner Kallweit @ 2019-07-20 16:44 UTC (permalink / raw)
To: Thomas Voegtle; +Cc: linux-kernel, netdev@vger.kernel.org
In-Reply-To: <alpine.LSU.2.21.1907201620070.2099@er-systems.de>
On 20.07.2019 16:22, Thomas Voegtle wrote:
> On Sat, 20 Jul 2019, Heiner Kallweit wrote:
>
>> On 19.07.2019 23:12, Thomas Voegtle wrote:
>>> On Fri, 19 Jul 2019, Heiner Kallweit wrote:
>>>
>>>> On 18.07.2019 20:50, Thomas Voegtle wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I'm having network problems with the commits on r8169 since v5.2. There are ping packet loss, sometimes 100%, sometimes 50%. In the end network is unusable.
>>>>>
>>>>> v5.2 is fine, I bisected it down to:
>>>>>
>>>>> a2928d28643e3c064ff41397281d20c445525032 is the first bad commit
>>>>> commit a2928d28643e3c064ff41397281d20c445525032
>>>>> Author: Heiner Kallweit <hkallweit1@gmail.com>
>>>>> Date: Sun Jun 2 10:53:49 2019 +0200
>>>>>
>>>>> r8169: use paged versions of phylib MDIO access functions
>>>>>
>>>>> Use paged versions of phylib MDIO access functions to simplify
>>>>> the code.
>>>>>
>>>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>>>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>>>>
>>>>>
>>>>> Reverting that commit on top of v5.2-11564-g22051d9c4a57 fixes the problem
>>>>> for me (had to adjust the renaming to r8169_main.c).
>>>>>
>>>>> I have a:
>>>>> 04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
>>>>> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev
>>>>> 0c)
>>>>> Subsystem: Biostar Microtech Int'l Corp Device [1565:2400]
>>>>> Kernel driver in use: r8169
>>>>>
>>>>> on a BIOSTAR H81MG motherboard.
>>>>>
>>>> Interesting. I have the same chip version (RTL8168g) and can't reproduce
>>>> the issue. Can you provide a full dmesg output and test the patch below
>>>> on top of linux-next? I'd be interested in the WARN_ON stack traces
>>>> (if any) and would like to know whether the experimental change to
>>>> __phy_modify_changed helps.
>>>>
>>>>>
>>>>> greetings,
>>>>>
>>>>> Thomas
>>>>>
>>>>>
>>>> Heiner
>>>>
>>>>
>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>>> index 8d7dd4c5f..26be73000 100644
>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>> @@ -1934,6 +1934,8 @@ static int rtl_get_eee_supp(struct rtl8169_private *tp)
>>>> struct phy_device *phydev = tp->phydev;
>>>> int ret;
>>>>
>>>> + WARN_ON(phy_read(phydev, 0x1f));
>>>> +
>>>> switch (tp->mac_version) {
>>>> case RTL_GIGA_MAC_VER_34:
>>>> case RTL_GIGA_MAC_VER_35:
>>>> @@ -1957,6 +1959,8 @@ static int rtl_get_eee_lpadv(struct rtl8169_private *tp)
>>>> struct phy_device *phydev = tp->phydev;
>>>> int ret;
>>>>
>>>> + WARN_ON(phy_read(phydev, 0x1f));
>>>> +
>>>> switch (tp->mac_version) {
>>>> case RTL_GIGA_MAC_VER_34:
>>>> case RTL_GIGA_MAC_VER_35:
>>>> @@ -1980,6 +1984,8 @@ static int rtl_get_eee_adv(struct rtl8169_private *tp)
>>>> struct phy_device *phydev = tp->phydev;
>>>> int ret;
>>>>
>>>> + WARN_ON(phy_read(phydev, 0x1f));
>>>> +
>>>> switch (tp->mac_version) {
>>>> case RTL_GIGA_MAC_VER_34:
>>>> case RTL_GIGA_MAC_VER_35:
>>>> @@ -2003,6 +2009,8 @@ static int rtl_set_eee_adv(struct rtl8169_private *tp, int val)
>>>> struct phy_device *phydev = tp->phydev;
>>>> int ret = 0;
>>>>
>>>> + WARN_ON(phy_read(phydev, 0x1f));
>>>> +
>>>> switch (tp->mac_version) {
>>>> case RTL_GIGA_MAC_VER_34:
>>>> case RTL_GIGA_MAC_VER_35:
>>>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>>>> index 16667fbac..1aa1142b8 100644
>>>> --- a/drivers/net/phy/phy-core.c
>>>> +++ b/drivers/net/phy/phy-core.c
>>>> @@ -463,12 +463,10 @@ int __phy_modify_changed(struct phy_device *phydev, u32 regnum, u16 mask,
>>>> return ret;
>>>>
>>>> new = (ret & ~mask) | set;
>>>> - if (new == ret)
>>>> - return 0;
>>>>
>>>> - ret = __phy_write(phydev, regnum, new);
>>>> + __phy_write(phydev, regnum, new);
>>>>
>>>> - return ret < 0 ? ret : 1;
>>>> + return new != ret;
>>>> }
>>>> EXPORT_SYMBOL_GPL(__phy_modify_changed);
>>>>
>>>>
>>>
>>> Took your patch on top of next-20190719.
>>> See attached dmesg.
>>> It didn't work. Same thing, lots of ping drops, no usable network.
>>>
>>> like that:
>>> 44 packets transmitted, 2 received, 95% packet loss, time 44005ms
>>>
>>>
>>> Maybe important:
>>> I build a kernel with no modules.
>>>
>>> I have to power off when I booted a kernel which doesn't work, a (soft) reboot into a older kernel (e.g. 4.9.y) doesn't
>>> fix the problem. Powering off and on does.
>>>
>>
>> Then, what you could do is reversing the hunks of the patch step by step.
>> Or make them separate patches and bisect.
>> Relevant are the hunks from point 1 and 2.
>>
>> 1. first 5 hunks (I don't think you have to reverse them individually)
>> EEE-related
>>
>> 2. rtl8168g_disable_aldps, rtl8168g_phy_adjust_10m_aldps, rtl8168g_1_hw_phy_config
>> all of these hunks are in the path for RTL8168g
>>
>> 3. rtl8168h_1_hw_phy_config, rtl8168h_2_hw_phy_config, rtl8168ep_1_hw_phy_config,
>> rtl8168ep_2_hw_phy_config
>> not in the path for RTL8168g
>>
>
> this is the minimal revert:
>
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index efef5453b94f..267995a614b5 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -3249,12 +3249,14 @@ static void rtl8168g_1_hw_phy_config(struct rtl8169_private *tp)
> else
> phy_modify_paged(tp->phydev, 0x0bcc, 0x12, 0, BIT(15));
>
> - ret = phy_read_paged(tp->phydev, 0x0a46, 0x13);
> - if (ret & BIT(8))
> - phy_modify_paged(tp->phydev, 0x0c41, 0x12, 0, BIT(1));
> - else
> - phy_modify_paged(tp->phydev, 0x0c41, 0x12, BIT(1), 0);
> -
> + rtl_writephy(tp, 0x1f, 0x0a46);
> + if (rtl_readphy(tp, 0x13) & 0x0100) {
> + rtl_writephy(tp, 0x1f, 0x0c41);
> + rtl_w0w1_phy(tp, 0x15, 0x0002, 0x0000);
> + } else {
> + rtl_writephy(tp, 0x1f, 0x0c41);
> + rtl_w0w1_phy(tp, 0x15, 0x0000, 0x0002);
> + }
> /* Enable PHY auto speed down */
> phy_modify_paged(tp->phydev, 0x0a44, 0x11, 0, BIT(3) | BIT(2));
>
>
>
> Could it be, that there is just a typo?
>
I looked a hundred times over this piece of code ..
Yes, it's simply a typo. I'll submit a patch for it.
Thanks a lot for your testing efforts!
> if (ret & BIT(8))
> - phy_modify_paged(tp->phydev, 0x0c41, 0x12, 0, BIT(1));
> + phy_modify_paged(tp->phydev, 0x0c41, 0x15, 0, BIT(1));
> else
> - phy_modify_paged(tp->phydev, 0x0c41, 0x12, BIT(1), 0);
> + phy_modify_paged(tp->phydev, 0x0c41, 0x15, BIT(1), 0);
>
>
>
>
> greetings,
>
> Thomas
Heiner
^ permalink raw reply
* Re: [PATCH net-next v2 8/8] net: mscc: PTP Hardware Clock (PHC) support
From: kbuild test robot @ 2019-07-20 15:23 UTC (permalink / raw)
To: Antoine Tenart
Cc: kbuild-all, davem, richardcochran, alexandre.belloni,
UNGLinuxDriver, ralf, paul.burton, jhogan, Antoine Tenart, netdev,
linux-mips, thomas.petazzoni, allan.nielsen
In-Reply-To: <20190705195213.22041-9-antoine.tenart@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]
Hi Antoine,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Antoine-Tenart/net-mscc-PTP-Hardware-Clock-PHC-support/20190707-075931
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=ia64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
ERROR: "ia64_delay_loop" [drivers/spi/spi-thunderx.ko] undefined!
ERROR: "ia64_delay_loop" [drivers/net/phy/mdio-cavium.ko] undefined!
>> ERROR: "ocelot_ptp_gettime64" [drivers/net/ethernet/mscc/ocelot_board.ko] undefined!
>> ERROR: "ocelot_get_hwtimestamp" [drivers/net/ethernet/mscc/ocelot_board.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 54158 bytes --]
^ permalink raw reply
* Re: network problems with r8169
From: Thomas Voegtle @ 2019-07-20 14:22 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: linux-kernel, netdev@vger.kernel.org
In-Reply-To: <9cab7996-d801-0ae5-9e82-6d24eeb8d7c7@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6602 bytes --]
On Sat, 20 Jul 2019, Heiner Kallweit wrote:
> On 19.07.2019 23:12, Thomas Voegtle wrote:
>> On Fri, 19 Jul 2019, Heiner Kallweit wrote:
>>
>>> On 18.07.2019 20:50, Thomas Voegtle wrote:
>>>>
>>>> Hello,
>>>>
>>>> I'm having network problems with the commits on r8169 since v5.2. There are ping packet loss, sometimes 100%, sometimes 50%. In the end network is unusable.
>>>>
>>>> v5.2 is fine, I bisected it down to:
>>>>
>>>> a2928d28643e3c064ff41397281d20c445525032 is the first bad commit
>>>> commit a2928d28643e3c064ff41397281d20c445525032
>>>> Author: Heiner Kallweit <hkallweit1@gmail.com>
>>>> Date: Sun Jun 2 10:53:49 2019 +0200
>>>>
>>>> r8169: use paged versions of phylib MDIO access functions
>>>>
>>>> Use paged versions of phylib MDIO access functions to simplify
>>>> the code.
>>>>
>>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>>>
>>>>
>>>> Reverting that commit on top of v5.2-11564-g22051d9c4a57 fixes the problem
>>>> for me (had to adjust the renaming to r8169_main.c).
>>>>
>>>> I have a:
>>>> 04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
>>>> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev
>>>> 0c)
>>>> Subsystem: Biostar Microtech Int'l Corp Device [1565:2400]
>>>> Kernel driver in use: r8169
>>>>
>>>> on a BIOSTAR H81MG motherboard.
>>>>
>>> Interesting. I have the same chip version (RTL8168g) and can't reproduce
>>> the issue. Can you provide a full dmesg output and test the patch below
>>> on top of linux-next? I'd be interested in the WARN_ON stack traces
>>> (if any) and would like to know whether the experimental change to
>>> __phy_modify_changed helps.
>>>
>>>>
>>>> greetings,
>>>>
>>>> Thomas
>>>>
>>>>
>>> Heiner
>>>
>>>
>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>> index 8d7dd4c5f..26be73000 100644
>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>> @@ -1934,6 +1934,8 @@ static int rtl_get_eee_supp(struct rtl8169_private *tp)
>>> struct phy_device *phydev = tp->phydev;
>>> int ret;
>>>
>>> + WARN_ON(phy_read(phydev, 0x1f));
>>> +
>>> switch (tp->mac_version) {
>>> case RTL_GIGA_MAC_VER_34:
>>> case RTL_GIGA_MAC_VER_35:
>>> @@ -1957,6 +1959,8 @@ static int rtl_get_eee_lpadv(struct rtl8169_private *tp)
>>> struct phy_device *phydev = tp->phydev;
>>> int ret;
>>>
>>> + WARN_ON(phy_read(phydev, 0x1f));
>>> +
>>> switch (tp->mac_version) {
>>> case RTL_GIGA_MAC_VER_34:
>>> case RTL_GIGA_MAC_VER_35:
>>> @@ -1980,6 +1984,8 @@ static int rtl_get_eee_adv(struct rtl8169_private *tp)
>>> struct phy_device *phydev = tp->phydev;
>>> int ret;
>>>
>>> + WARN_ON(phy_read(phydev, 0x1f));
>>> +
>>> switch (tp->mac_version) {
>>> case RTL_GIGA_MAC_VER_34:
>>> case RTL_GIGA_MAC_VER_35:
>>> @@ -2003,6 +2009,8 @@ static int rtl_set_eee_adv(struct rtl8169_private *tp, int val)
>>> struct phy_device *phydev = tp->phydev;
>>> int ret = 0;
>>>
>>> + WARN_ON(phy_read(phydev, 0x1f));
>>> +
>>> switch (tp->mac_version) {
>>> case RTL_GIGA_MAC_VER_34:
>>> case RTL_GIGA_MAC_VER_35:
>>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>>> index 16667fbac..1aa1142b8 100644
>>> --- a/drivers/net/phy/phy-core.c
>>> +++ b/drivers/net/phy/phy-core.c
>>> @@ -463,12 +463,10 @@ int __phy_modify_changed(struct phy_device *phydev, u32 regnum, u16 mask,
>>> return ret;
>>>
>>> new = (ret & ~mask) | set;
>>> - if (new == ret)
>>> - return 0;
>>>
>>> - ret = __phy_write(phydev, regnum, new);
>>> + __phy_write(phydev, regnum, new);
>>>
>>> - return ret < 0 ? ret : 1;
>>> + return new != ret;
>>> }
>>> EXPORT_SYMBOL_GPL(__phy_modify_changed);
>>>
>>>
>>
>> Took your patch on top of next-20190719.
>> See attached dmesg.
>> It didn't work. Same thing, lots of ping drops, no usable network.
>>
>> like that:
>> 44 packets transmitted, 2 received, 95% packet loss, time 44005ms
>>
>>
>> Maybe important:
>> I build a kernel with no modules.
>>
>> I have to power off when I booted a kernel which doesn't work, a (soft) reboot into a older kernel (e.g. 4.9.y) doesn't
>> fix the problem. Powering off and on does.
>>
>
> Then, what you could do is reversing the hunks of the patch step by step.
> Or make them separate patches and bisect.
> Relevant are the hunks from point 1 and 2.
>
> 1. first 5 hunks (I don't think you have to reverse them individually)
> EEE-related
>
> 2. rtl8168g_disable_aldps, rtl8168g_phy_adjust_10m_aldps, rtl8168g_1_hw_phy_config
> all of these hunks are in the path for RTL8168g
>
> 3. rtl8168h_1_hw_phy_config, rtl8168h_2_hw_phy_config, rtl8168ep_1_hw_phy_config,
> rtl8168ep_2_hw_phy_config
> not in the path for RTL8168g
>
this is the minimal revert:
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
index efef5453b94f..267995a614b5 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -3249,12 +3249,14 @@ static void rtl8168g_1_hw_phy_config(struct
rtl8169_private *tp)
else
phy_modify_paged(tp->phydev, 0x0bcc, 0x12, 0, BIT(15));
- ret = phy_read_paged(tp->phydev, 0x0a46, 0x13);
- if (ret & BIT(8))
- phy_modify_paged(tp->phydev, 0x0c41, 0x12, 0, BIT(1));
- else
- phy_modify_paged(tp->phydev, 0x0c41, 0x12, BIT(1), 0);
-
+ rtl_writephy(tp, 0x1f, 0x0a46);
+ if (rtl_readphy(tp, 0x13) & 0x0100) {
+ rtl_writephy(tp, 0x1f, 0x0c41);
+ rtl_w0w1_phy(tp, 0x15, 0x0002, 0x0000);
+ } else {
+ rtl_writephy(tp, 0x1f, 0x0c41);
+ rtl_w0w1_phy(tp, 0x15, 0x0000, 0x0002);
+ }
/* Enable PHY auto speed down */
phy_modify_paged(tp->phydev, 0x0a44, 0x11, 0, BIT(3) | BIT(2));
Could it be, that there is just a typo?
if (ret & BIT(8))
- phy_modify_paged(tp->phydev, 0x0c41, 0x12, 0, BIT(1));
+ phy_modify_paged(tp->phydev, 0x0c41, 0x15, 0, BIT(1));
else
- phy_modify_paged(tp->phydev, 0x0c41, 0x12, BIT(1), 0);
+ phy_modify_paged(tp->phydev, 0x0c41, 0x15, BIT(1), 0);
greetings,
Thomas
^ permalink raw reply related
* [PATCH] netfilter: ebtables: compat: fix a memory leak bug
From: Wenwen Wang @ 2019-07-20 12:22 UTC (permalink / raw)
To: Wenwen Wang
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
Roopa Prabhu, Nikolay Aleksandrov, David S. Miller,
open list:NETFILTER, open list:NETFILTER,
moderated list:ETHERNET BRIDGE, open list:ETHERNET BRIDGE,
open list
From: Wenwen Wang <wenwen@cs.uga.edu>
In compat_do_replace(), a temporary buffer is allocated through vmalloc()
to hold entries copied from the user space. The buffer address is firstly
saved to 'newinfo->entries', and later on assigned to 'entries_tmp'. Then
the entries in this temporary buffer is copied to the internal kernel
structure through compat_copy_entries(). If this copy process fails,
compat_do_replace() should be terminated. However, the allocated temporary
buffer is not freed on this path, leading to a memory leak.
To fix the bug, free the buffer before returning from compat_do_replace().
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
net/bridge/netfilter/ebtables.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index 963dfdc..fd84b48e 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -2261,8 +2261,10 @@ static int compat_do_replace(struct net *net, void __user *user,
state.buf_kern_len = size64;
ret = compat_copy_entries(entries_tmp, tmp.entries_size, &state);
- if (WARN_ON(ret < 0))
+ if (WARN_ON(ret < 0)) {
+ vfree(entries_tmp);
goto out_unlock;
+ }
vfree(entries_tmp);
tmp.entries_size = size64;
--
2.7.4
^ permalink raw reply related
* Re: network problems with r8169
From: Heiner Kallweit @ 2019-07-20 9:13 UTC (permalink / raw)
To: Thomas Voegtle; +Cc: linux-kernel, netdev@vger.kernel.org
In-Reply-To: <alpine.LSU.2.21.1907192310140.11569@er-systems.de>
On 19.07.2019 23:12, Thomas Voegtle wrote:
> On Fri, 19 Jul 2019, Heiner Kallweit wrote:
>
>> On 18.07.2019 20:50, Thomas Voegtle wrote:
>>>
>>> Hello,
>>>
>>> I'm having network problems with the commits on r8169 since v5.2. There are ping packet loss, sometimes 100%, sometimes 50%. In the end network is unusable.
>>>
>>> v5.2 is fine, I bisected it down to:
>>>
>>> a2928d28643e3c064ff41397281d20c445525032 is the first bad commit
>>> commit a2928d28643e3c064ff41397281d20c445525032
>>> Author: Heiner Kallweit <hkallweit1@gmail.com>
>>> Date: Sun Jun 2 10:53:49 2019 +0200
>>>
>>> r8169: use paged versions of phylib MDIO access functions
>>>
>>> Use paged versions of phylib MDIO access functions to simplify
>>> the code.
>>>
>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>>
>>>
>>> Reverting that commit on top of v5.2-11564-g22051d9c4a57 fixes the problem
>>> for me (had to adjust the renaming to r8169_main.c).
>>>
>>> I have a:
>>> 04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
>>> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev
>>> 0c)
>>> Subsystem: Biostar Microtech Int'l Corp Device [1565:2400]
>>> Kernel driver in use: r8169
>>>
>>> on a BIOSTAR H81MG motherboard.
>>>
>> Interesting. I have the same chip version (RTL8168g) and can't reproduce
>> the issue. Can you provide a full dmesg output and test the patch below
>> on top of linux-next? I'd be interested in the WARN_ON stack traces
>> (if any) and would like to know whether the experimental change to
>> __phy_modify_changed helps.
>>
>>>
>>> greetings,
>>>
>>> Thomas
>>>
>>>
>> Heiner
>>
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>> index 8d7dd4c5f..26be73000 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -1934,6 +1934,8 @@ static int rtl_get_eee_supp(struct rtl8169_private *tp)
>> struct phy_device *phydev = tp->phydev;
>> int ret;
>>
>> + WARN_ON(phy_read(phydev, 0x1f));
>> +
>> switch (tp->mac_version) {
>> case RTL_GIGA_MAC_VER_34:
>> case RTL_GIGA_MAC_VER_35:
>> @@ -1957,6 +1959,8 @@ static int rtl_get_eee_lpadv(struct rtl8169_private *tp)
>> struct phy_device *phydev = tp->phydev;
>> int ret;
>>
>> + WARN_ON(phy_read(phydev, 0x1f));
>> +
>> switch (tp->mac_version) {
>> case RTL_GIGA_MAC_VER_34:
>> case RTL_GIGA_MAC_VER_35:
>> @@ -1980,6 +1984,8 @@ static int rtl_get_eee_adv(struct rtl8169_private *tp)
>> struct phy_device *phydev = tp->phydev;
>> int ret;
>>
>> + WARN_ON(phy_read(phydev, 0x1f));
>> +
>> switch (tp->mac_version) {
>> case RTL_GIGA_MAC_VER_34:
>> case RTL_GIGA_MAC_VER_35:
>> @@ -2003,6 +2009,8 @@ static int rtl_set_eee_adv(struct rtl8169_private *tp, int val)
>> struct phy_device *phydev = tp->phydev;
>> int ret = 0;
>>
>> + WARN_ON(phy_read(phydev, 0x1f));
>> +
>> switch (tp->mac_version) {
>> case RTL_GIGA_MAC_VER_34:
>> case RTL_GIGA_MAC_VER_35:
>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>> index 16667fbac..1aa1142b8 100644
>> --- a/drivers/net/phy/phy-core.c
>> +++ b/drivers/net/phy/phy-core.c
>> @@ -463,12 +463,10 @@ int __phy_modify_changed(struct phy_device *phydev, u32 regnum, u16 mask,
>> return ret;
>>
>> new = (ret & ~mask) | set;
>> - if (new == ret)
>> - return 0;
>>
>> - ret = __phy_write(phydev, regnum, new);
>> + __phy_write(phydev, regnum, new);
>>
>> - return ret < 0 ? ret : 1;
>> + return new != ret;
>> }
>> EXPORT_SYMBOL_GPL(__phy_modify_changed);
>>
>>
>
> Took your patch on top of next-20190719.
> See attached dmesg.
> It didn't work. Same thing, lots of ping drops, no usable network.
>
> like that:
> 44 packets transmitted, 2 received, 95% packet loss, time 44005ms
>
I remember that I once had problems with this chip version and 100Mbps.
Could you check whether you face the same issues with 1Gbps?
>
> Maybe important:
> I build a kernel with no modules.
>
> I have to power off when I booted a kernel which doesn't work, a (soft) reboot into a older kernel (e.g. 4.9.y) doesn't
> fix the problem. Powering off and on does.
>
>
> greetings,
>
> Thomas
^ permalink raw reply
* Re: network problems with r8169
From: Heiner Kallweit @ 2019-07-20 9:11 UTC (permalink / raw)
To: Thomas Voegtle; +Cc: linux-kernel, netdev@vger.kernel.org
In-Reply-To: <alpine.LSU.2.21.1907192310140.11569@er-systems.de>
On 19.07.2019 23:12, Thomas Voegtle wrote:
> On Fri, 19 Jul 2019, Heiner Kallweit wrote:
>
>> On 18.07.2019 20:50, Thomas Voegtle wrote:
>>>
>>> Hello,
>>>
>>> I'm having network problems with the commits on r8169 since v5.2. There are ping packet loss, sometimes 100%, sometimes 50%. In the end network is unusable.
>>>
>>> v5.2 is fine, I bisected it down to:
>>>
>>> a2928d28643e3c064ff41397281d20c445525032 is the first bad commit
>>> commit a2928d28643e3c064ff41397281d20c445525032
>>> Author: Heiner Kallweit <hkallweit1@gmail.com>
>>> Date: Sun Jun 2 10:53:49 2019 +0200
>>>
>>> r8169: use paged versions of phylib MDIO access functions
>>>
>>> Use paged versions of phylib MDIO access functions to simplify
>>> the code.
>>>
>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>>
>>>
>>> Reverting that commit on top of v5.2-11564-g22051d9c4a57 fixes the problem
>>> for me (had to adjust the renaming to r8169_main.c).
>>>
>>> I have a:
>>> 04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
>>> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev
>>> 0c)
>>> Subsystem: Biostar Microtech Int'l Corp Device [1565:2400]
>>> Kernel driver in use: r8169
>>>
>>> on a BIOSTAR H81MG motherboard.
>>>
>> Interesting. I have the same chip version (RTL8168g) and can't reproduce
>> the issue. Can you provide a full dmesg output and test the patch below
>> on top of linux-next? I'd be interested in the WARN_ON stack traces
>> (if any) and would like to know whether the experimental change to
>> __phy_modify_changed helps.
>>
>>>
>>> greetings,
>>>
>>> Thomas
>>>
>>>
>> Heiner
>>
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>> index 8d7dd4c5f..26be73000 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -1934,6 +1934,8 @@ static int rtl_get_eee_supp(struct rtl8169_private *tp)
>> struct phy_device *phydev = tp->phydev;
>> int ret;
>>
>> + WARN_ON(phy_read(phydev, 0x1f));
>> +
>> switch (tp->mac_version) {
>> case RTL_GIGA_MAC_VER_34:
>> case RTL_GIGA_MAC_VER_35:
>> @@ -1957,6 +1959,8 @@ static int rtl_get_eee_lpadv(struct rtl8169_private *tp)
>> struct phy_device *phydev = tp->phydev;
>> int ret;
>>
>> + WARN_ON(phy_read(phydev, 0x1f));
>> +
>> switch (tp->mac_version) {
>> case RTL_GIGA_MAC_VER_34:
>> case RTL_GIGA_MAC_VER_35:
>> @@ -1980,6 +1984,8 @@ static int rtl_get_eee_adv(struct rtl8169_private *tp)
>> struct phy_device *phydev = tp->phydev;
>> int ret;
>>
>> + WARN_ON(phy_read(phydev, 0x1f));
>> +
>> switch (tp->mac_version) {
>> case RTL_GIGA_MAC_VER_34:
>> case RTL_GIGA_MAC_VER_35:
>> @@ -2003,6 +2009,8 @@ static int rtl_set_eee_adv(struct rtl8169_private *tp, int val)
>> struct phy_device *phydev = tp->phydev;
>> int ret = 0;
>>
>> + WARN_ON(phy_read(phydev, 0x1f));
>> +
>> switch (tp->mac_version) {
>> case RTL_GIGA_MAC_VER_34:
>> case RTL_GIGA_MAC_VER_35:
>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>> index 16667fbac..1aa1142b8 100644
>> --- a/drivers/net/phy/phy-core.c
>> +++ b/drivers/net/phy/phy-core.c
>> @@ -463,12 +463,10 @@ int __phy_modify_changed(struct phy_device *phydev, u32 regnum, u16 mask,
>> return ret;
>>
>> new = (ret & ~mask) | set;
>> - if (new == ret)
>> - return 0;
>>
>> - ret = __phy_write(phydev, regnum, new);
>> + __phy_write(phydev, regnum, new);
>>
>> - return ret < 0 ? ret : 1;
>> + return new != ret;
>> }
>> EXPORT_SYMBOL_GPL(__phy_modify_changed);
>>
>>
>
> Took your patch on top of next-20190719.
> See attached dmesg.
> It didn't work. Same thing, lots of ping drops, no usable network.
>
> like that:
> 44 packets transmitted, 2 received, 95% packet loss, time 44005ms
>
>
> Maybe important:
> I build a kernel with no modules.
>
> I have to power off when I booted a kernel which doesn't work, a (soft) reboot into a older kernel (e.g. 4.9.y) doesn't
> fix the problem. Powering off and on does.
>
Then, what you could do is reversing the hunks of the patch step by step.
Or make them separate patches and bisect.
Relevant are the hunks from point 1 and 2.
1. first 5 hunks (I don't think you have to reverse them individually)
EEE-related
2. rtl8168g_disable_aldps, rtl8168g_phy_adjust_10m_aldps, rtl8168g_1_hw_phy_config
all of these hunks are in the path for RTL8168g
3. rtl8168h_1_hw_phy_config, rtl8168h_2_hw_phy_config, rtl8168ep_1_hw_phy_config,
rtl8168ep_2_hw_phy_config
not in the path for RTL8168g
>
> greetings,
>
> Thomas
Heiner
^ permalink raw reply
* Re: ENOBUILD in nf_tables
From: Pablo Neira Ayuso @ 2019-07-20 7:44 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev@vger.kernel.org
In-Reply-To: <20190719100743.2ea14575@cakuba.netronome.com>
Hi Jakub,
On Fri, Jul 19, 2019 at 10:07:43AM -0700, Jakub Kicinski wrote:
> Hi Pablo!
>
> I hit the following build breakage on net with the config attached.
>
> GCC 9, doesn't seem like your just-posted series fixes this?
$ gcc -v
...
gcc version 9.1.0
$ make
...
CC include/net/netfilter/nf_tables_offload.h.s
...
$
Works for me here.
^ permalink raw reply
* Re: [patch net-next rfc 7/7] net: rtnetlink: add possibility to use alternative names as message handle
From: Jiri Pirko @ 2019-07-20 7:22 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, davem, sthemmin, dsahern, dcbw, mkubecek, andrew, parav,
saeedm, mlxsw
In-Reply-To: <20190719205927.6638187f@cakuba>
Sat, Jul 20, 2019 at 05:59:27AM CEST, jakub.kicinski@netronome.com wrote:
>On Fri, 19 Jul 2019 13:00:29 +0200, Jiri Pirko wrote:
>> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>> index 1fa30d514e3f..68ad12a7fc4d 100644
>> --- a/net/core/rtnetlink.c
>> +++ b/net/core/rtnetlink.c
>> @@ -1793,6 +1793,8 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
>> [IFLA_MAX_MTU] = { .type = NLA_U32 },
>> [IFLA_ALT_IFNAME_MOD] = { .type = NLA_STRING,
>> .len = ALTIFNAMSIZ - 1 },
>> + [IFLA_ALT_IFNAME] = { .type = NLA_STRING,
>> + .len = ALTIFNAMSIZ - 1 },
>
>What's the disadvantage of just letting IFLA_IFNAME to get longer
>on input? Is it just that the handling would be asymmetrical?
Hmm, that might work. But the problem is that sometimes the IFLA_IFNAME
is used as a handle, but sometimes it is used to carry the ifname
(newlink, changename). That might be a bit confusing and the code would
be harder to follow. I don't know...
>
>> };
>>
>> static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox