* Re: [PATCH] [net] nvmem: disallow modular CONFIG_NVMEM
From: David Miller @ 2018-04-04 15:48 UTC (permalink / raw)
To: arnd
Cc: srinivas.kandagatla, mike.looijmans, f.fainelli, andrew, netdev,
gregkh, o.rempel, martin.blumenstingl, linux-kernel
In-Reply-To: <20180404103900.4090118-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 4 Apr 2018 12:38:40 +0200
> The new of_get_nvmem_mac_address() helper function causes a link error
> with CONFIG_NVMEM=m:
>
> drivers/of/of_net.o: In function `of_get_nvmem_mac_address':
> of_net.c:(.text+0x168): undefined reference to `of_nvmem_cell_get'
> of_net.c:(.text+0x19c): undefined reference to `nvmem_cell_read'
> of_net.c:(.text+0x1a8): undefined reference to `nvmem_cell_put'
>
> I could not come up with a good solution for this, as the code is always
> built-in. Using an #if IS_REACHABLE() check around it would solve the
> link time issue but then stop it from working in that configuration.
> Making of_nvmem_cell_get() an inline function could also solve that, but
> seems a bit ugly since it's somewhat larger than most inline functions,
> and it would just bring that problem into the callers. Splitting the
> function into a separate file might be an alternative.
>
> This uses the big hammer by making CONFIG_NVMEM itself a 'bool' symbol,
> which avoids the problem entirely but makes the vmlinux larger for anyone
> that might use NVMEM support but doesn't need it built-in otherwise.
>
> Fixes: 9217e566bdee ("of_net: Implement of_get_nvmem_mac_address helper")
> Cc: Mike Looijmans <mike.looijmans@topic.nl>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> The problem arrived through the networking tree, but it's now in
> mainline, so the fix could go through either tree
Ok, applied, thanks Arnd.
^ permalink raw reply
* Re: [PATCH 40/47] netfilter: nf_tables: build-in filter chain type
From: Pablo Neira Ayuso @ 2018-04-04 15:46 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: netfilter-devel, David Miller, Networking
In-Reply-To: <CAK8P3a1nEJ450Ori2-xPnC8WDPcHxiQR_844ArqOgZ2eRGpcbw@mail.gmail.com>
On Wed, Apr 04, 2018 at 05:38:31PM +0200, Arnd Bergmann wrote:
> On Fri, Mar 30, 2018 at 1:46 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > One module per supported filter chain family type takes too much memory
> > for very little code - too much modularization - place all chain filter
> > definitions in one single file.
> >
> > Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>
> Hi Pablo,
>
> I've bisected a link error to this patch:
>
> net/netfilter/nft_reject_inet.o: In function `nft_reject_inet_eval':
> nft_reject_inet.c:(.text+0xa7): undefined reference to `nf_send_unreach6'
> nft_reject_inet.c:(.text+0x10c): undefined reference to `nf_send_unreach6'
> nft_reject_inet.c:(.text+0x138): undefined reference to `nf_send_reset6'
>
> Unfortunately I don't immediately see what went wrong, maybe you
> can spot it.
Can you pass me your .config file? I will have a look at it. Thanks.
Looks like some missing Kconfig stuff.
^ permalink raw reply
* Re: [Cluster-devel] [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek
From: Bob Peterson @ 2018-04-04 15:46 UTC (permalink / raw)
To: Andreas Gruenbacher
Cc: cluster-devel, Herbert Xu, netdev, linux-kernel, NeilBrown,
Thomas Graf, Tom Herbert
In-Reply-To: <20180329120612.6104-1-agruenba@redhat.com>
----- Original Message -----
> Here's a second version of the patch (now a patch set) to eliminate
> rhashtable_walk_peek in gfs2.
>
> The first patch introduces lockref_put_not_zero, the inverse of
> lockref_get_not_zero.
>
> The second patch eliminates rhashtable_walk_peek in gfs2. In
> gfs2_glock_iter_next, the new lockref function from patch one is used to
> drop a lockref count as long as the count doesn't drop to zero. This is
> almost always the case; if there is a risk of dropping the last
> reference, we must defer that to a work queue because dropping the last
> reference may sleep.
>
> Thanks,
> Andreas
>
> Andreas Gruenbacher (2):
> lockref: Add lockref_put_not_zero
> gfs2: Stop using rhashtable_walk_peek
>
> fs/gfs2/glock.c | 47 ++++++++++++++++++++++++++++-------------------
> include/linux/lockref.h | 1 +
> lib/lockref.c | 28 ++++++++++++++++++++++++++++
> 3 files changed, 57 insertions(+), 19 deletions(-)
>
> --
> 2.14.3
Hi,
The patches look good. The big question is whether to add them to this
merge window while it's still open. Opinions?
Acked-by: Bob Peterson <rpeterso@redhat.com>
Regards,
Bob Peterson
^ permalink raw reply
* Re: [PATCH] net: hns3: fix length overflow when CONFIG_ARM64_64K_PAGES
From: David Miller @ 2018-04-04 15:46 UTC (permalink / raw)
To: tanxiaojun
Cc: yisen.zhuang, salil.mehta, huawei.libin, netdev, linux-kernel,
wangzhou1, linyunsheng
In-Reply-To: <1522834848-63974-1-git-send-email-tanxiaojun@huawei.com>
From: Tan Xiaojun <tanxiaojun@huawei.com>
Date: Wed, 4 Apr 2018 17:40:48 +0800
> When enable the config item "CONFIG_ARM64_64K_PAGES", the size of PAGE_SIZE
> is 65536(64K). But the type of length is u16, it will overflow. So change it
> to u32.
>
> Signed-off-by: Tan Xiaojun <tanxiaojun@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] nfp: use full 40 bits of the NSP buffer address
From: David Miller @ 2018-04-04 15:45 UTC (permalink / raw)
To: jakub.kicinski; +Cc: oss-drivers, netdev, dirk.vandermerwe
In-Reply-To: <20180404002423.6422-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Tue, 3 Apr 2018 17:24:23 -0700
> From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
>
> The NSP default buffer is a piece of NFP memory where additional
> command data can be placed. Its format has been copied from
> host buffer, but the PCIe selection bits do not make sense in
> this case. If those get masked out from a NFP address - writes
> to random place in the chip memory may be issued and crash the
> device.
>
> Even in the general NSP buffer case, it doesn't make sense to have the
> PCIe selection bits there anymore. These are unused at the moment, and
> when it becomes necessary, the PCIe selection bits should rather be
> moved to another register to utilise more bits for the buffer address.
>
> This has never been an issue because the buffer used to be
> allocated in memory with less-than-38-bit-long address but that
> is about to change.
>
> Fixes: 1a64821c6af7 ("nfp: add support for service processor access")
> Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] netdevsim: remove incorrect __net_initdata annotations
From: Arnd Bergmann @ 2018-04-04 15:42 UTC (permalink / raw)
To: David Ahern
Cc: Jakub Kicinski, David S. Miller, Networking,
Linux Kernel Mailing List
In-Reply-To: <5181fd00-1943-6e76-ea18-1d3951dd9b58@cumulusnetworks.com>
On Wed, Apr 4, 2018 at 5:33 PM, David Ahern <dsa@cumulusnetworks.com> wrote:
> On 4/4/18 6:12 AM, Arnd Bergmann wrote:
>> The __net_initdata section cannot currently be used for structures that
>> get cleaned up in an exitcall using unregister_pernet_operations:
>>
>
> I am confused ... I do the same thing in the VRF driver and that code
> has been there since June 2017.
I don't see any exit call in that driver, the only caller of
unregister_pernet_operations() there is in the init function itself,
and the module cannot be removed.
Arnd
^ permalink raw reply
* Re: [PATCH v2] lan78xx: Connect phy early
From: David Miller @ 2018-04-04 15:41 UTC (permalink / raw)
To: agraf
Cc: netdev, linux-usb, linux-kernel, Nisar.Sayed, Woojung.Huh,
UNGLinuxDriver, tbogendoerfer, phil, andrew,
RaghuramChary.Jallipalli
In-Reply-To: <20180403221935.51099-1-agraf@suse.de>
From: Alexander Graf <agraf@suse.de>
Date: Wed, 4 Apr 2018 00:19:35 +0200
> When using wicked with a lan78xx device attached to the system, we
> end up with ethtool commands issued on the device before an ifup
> got issued. That lead to the following crash:
>
...
> The culprit is quite simple: The driver tries to access the phy left and right,
> but only actually has a working reference to it when the device is up.
>
> The fix thus is quite simple too: Get a reference to the phy on probe already
> and keep it even when the device is going down.
>
> With this patch applied, I can successfully run wicked on my system and bring
> the interface up and down as many times as I want, without getting NULL pointer
> dereferences in between.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
Applied, thank you.
^ permalink raw reply
* [PATCH net] sfc: remove ctpio_dmabuf_start from stats
From: Bert Kenward @ 2018-04-04 15:40 UTC (permalink / raw)
To: Dave Miller; +Cc: netdev, linux-net-drivers
The ctpio_dmabuf_start entry is not actually a stat and shouldn't
be exposed to ethtool.
Fixes: 2c0b6ee837db ("sfc: expose CTPIO stats on NICs that support
them")
Signed-off-by: Bert Kenward <bkenward@solarflare.com>
---
drivers/net/ethernet/sfc/ef10.c | 2 --
drivers/net/ethernet/sfc/nic.h | 1 -
2 files changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
index c4c45c94da77..50daad0a1482 100644
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -1666,7 +1666,6 @@ static const struct efx_hw_stat_desc efx_ef10_stat_desc[EF10_STAT_COUNT] = {
EF10_DMA_STAT(fec_corrected_symbols_lane1, FEC_CORRECTED_SYMBOLS_LANE1),
EF10_DMA_STAT(fec_corrected_symbols_lane2, FEC_CORRECTED_SYMBOLS_LANE2),
EF10_DMA_STAT(fec_corrected_symbols_lane3, FEC_CORRECTED_SYMBOLS_LANE3),
- EF10_DMA_STAT(ctpio_dmabuf_start, CTPIO_DMABUF_START),
EF10_DMA_STAT(ctpio_vi_busy_fallback, CTPIO_VI_BUSY_FALLBACK),
EF10_DMA_STAT(ctpio_long_write_success, CTPIO_LONG_WRITE_SUCCESS),
EF10_DMA_STAT(ctpio_missing_dbell_fail, CTPIO_MISSING_DBELL_FAIL),
@@ -1777,7 +1776,6 @@ static const struct efx_hw_stat_desc efx_ef10_stat_desc[EF10_STAT_COUNT] = {
* These bits are in the second u64 of the raw mask.
*/
#define EF10_CTPIO_STAT_MASK ( \
- (1ULL << (EF10_STAT_ctpio_dmabuf_start - 64)) | \
(1ULL << (EF10_STAT_ctpio_vi_busy_fallback - 64)) | \
(1ULL << (EF10_STAT_ctpio_long_write_success - 64)) | \
(1ULL << (EF10_STAT_ctpio_missing_dbell_fail - 64)) | \
diff --git a/drivers/net/ethernet/sfc/nic.h b/drivers/net/ethernet/sfc/nic.h
index 5640034bda10..5cca0556b47f 100644
--- a/drivers/net/ethernet/sfc/nic.h
+++ b/drivers/net/ethernet/sfc/nic.h
@@ -332,7 +332,6 @@ enum {
EF10_STAT_fec_corrected_symbols_lane1,
EF10_STAT_fec_corrected_symbols_lane2,
EF10_STAT_fec_corrected_symbols_lane3,
- EF10_STAT_ctpio_dmabuf_start,
EF10_STAT_ctpio_vi_busy_fallback,
EF10_STAT_ctpio_long_write_success,
EF10_STAT_ctpio_missing_dbell_fail,
--
2.13.6
^ permalink raw reply related
* Re: [PATCH net-next 2/2] inet: frags: fix ip6frag_low_thresh boundary
From: Eric Dumazet @ 2018-04-04 15:40 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller; +Cc: netdev, Eric Dumazet
In-Reply-To: <20180404153510.213392-1-edumazet@google.com>
On 04/04/2018 08:35 AM, Eric Dumazet wrote:
> Giving an integer to proc_doulongvec_minmax() is dangerous on 64bit arches,
> since linker might place next to it a non zero value preventing a change
> to ip6frag_low_thresh.
>
> ip6frag_low_thresh is not used anymore in the kernel, but we do not
> want to prematuraly break user scripts wanting to change it.
>
> Since specifying a minimal value of 0 for proc_doulongvec_minmax()
> is moot, let's remove these zero values in all defrag units.
>
> Fixes: 6e00f7dd5e4e ("ipv6: frags: fix /proc/sys/net/ipv6/ip6frag_low_thresh")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Maciej Żenczykowski <maze@google.com>
David, please ignore the net-next 2/2 in the title, there is a single patch, targeting net tree,
sorry for the confusion.
^ permalink raw reply
* Re: [PATCH 40/47] netfilter: nf_tables: build-in filter chain type
From: Arnd Bergmann @ 2018-04-04 15:38 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel, David Miller, Networking
In-Reply-To: <20180330114619.18797-1-pablo@netfilter.org>
On Fri, Mar 30, 2018 at 1:46 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> One module per supported filter chain family type takes too much memory
> for very little code - too much modularization - place all chain filter
> definitions in one single file.
>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Hi Pablo,
I've bisected a link error to this patch:
net/netfilter/nft_reject_inet.o: In function `nft_reject_inet_eval':
nft_reject_inet.c:(.text+0xa7): undefined reference to `nf_send_unreach6'
nft_reject_inet.c:(.text+0x10c): undefined reference to `nf_send_unreach6'
nft_reject_inet.c:(.text+0x138): undefined reference to `nf_send_reset6'
Unfortunately I don't immediately see what went wrong, maybe you
can spot it.
Arnd
^ permalink raw reply
* Re: [PATCH net-next] nfp: add a separate counter for packets with CHECKSUM_COMPLETE
From: David Miller @ 2018-04-04 15:37 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev, oss-drivers
In-Reply-To: <20180402203120.14039-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Mon, 2 Apr 2018 13:31:20 -0700
> We are currently counting packets with CHECKSUM_COMPLETE as
> "hw_rx_csum_ok". This is confusing. Add a new counter.
> To make sure it fits in the same cacheline move the less used
> error counter to a different location.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Applied, thank you.
^ permalink raw reply
* [PATCH net-next 2/2] inet: frags: fix ip6frag_low_thresh boundary
From: Eric Dumazet @ 2018-04-04 15:35 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet
Giving an integer to proc_doulongvec_minmax() is dangerous on 64bit arches,
since linker might place next to it a non zero value preventing a change
to ip6frag_low_thresh.
ip6frag_low_thresh is not used anymore in the kernel, but we do not
want to prematuraly break user scripts wanting to change it.
Since specifying a minimal value of 0 for proc_doulongvec_minmax()
is moot, let's remove these zero values in all defrag units.
Fixes: 6e00f7dd5e4e ("ipv6: frags: fix /proc/sys/net/ipv6/ip6frag_low_thresh")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Maciej Żenczykowski <maze@google.com>
---
net/ieee802154/6lowpan/reassembly.c | 2 --
net/ipv4/ip_fragment.c | 5 ++---
net/ipv6/netfilter/nf_conntrack_reasm.c | 2 --
net/ipv6/reassembly.c | 2 --
4 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/net/ieee802154/6lowpan/reassembly.c b/net/ieee802154/6lowpan/reassembly.c
index 44f148a6bb57bb737c35a07e3f070472e209ea23..1790b65944b3ee188608b1a76d4f9a42fb1479d5 100644
--- a/net/ieee802154/6lowpan/reassembly.c
+++ b/net/ieee802154/6lowpan/reassembly.c
@@ -411,7 +411,6 @@ int lowpan_frag_rcv(struct sk_buff *skb, u8 frag_type)
}
#ifdef CONFIG_SYSCTL
-static long zero;
static struct ctl_table lowpan_frags_ns_ctl_table[] = {
{
@@ -428,7 +427,6 @@ static struct ctl_table lowpan_frags_ns_ctl_table[] = {
.maxlen = sizeof(unsigned long),
.mode = 0644,
.proc_handler = proc_doulongvec_minmax,
- .extra1 = &zero,
.extra2 = &init_net.ieee802154_lowpan.frags.high_thresh
},
{
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 994fa70a910f472ebecc336ddd62d1442014eaba..8e9528ebaa8e1af91172466cc161a83301a217ca 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -667,7 +667,7 @@ struct sk_buff *ip_check_defrag(struct net *net, struct sk_buff *skb, u32 user)
EXPORT_SYMBOL(ip_check_defrag);
#ifdef CONFIG_SYSCTL
-static long zero;
+static int dist_min;
static struct ctl_table ip4_frags_ns_ctl_table[] = {
{
@@ -684,7 +684,6 @@ static struct ctl_table ip4_frags_ns_ctl_table[] = {
.maxlen = sizeof(unsigned long),
.mode = 0644,
.proc_handler = proc_doulongvec_minmax,
- .extra1 = &zero,
.extra2 = &init_net.ipv4.frags.high_thresh
},
{
@@ -700,7 +699,7 @@ static struct ctl_table ip4_frags_ns_ctl_table[] = {
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = proc_dointvec_minmax,
- .extra1 = &zero
+ .extra1 = &dist_min,
},
{ }
};
diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
index 3622aac343aea3cd0d8165d8681f42595735cd90..5e0332014c1738999e680c1853829f384e880284 100644
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -55,7 +55,6 @@ static const char nf_frags_cache_name[] = "nf-frags";
static struct inet_frags nf_frags;
#ifdef CONFIG_SYSCTL
-static long zero;
static struct ctl_table nf_ct_frag6_sysctl_table[] = {
{
@@ -71,7 +70,6 @@ static struct ctl_table nf_ct_frag6_sysctl_table[] = {
.maxlen = sizeof(unsigned long),
.mode = 0644,
.proc_handler = proc_doulongvec_minmax,
- .extra1 = &zero,
.extra2 = &init_net.nf_frag.frags.high_thresh
},
{
diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
index 70e4a578b2fb6b2941daeebe4f476214953db047..4979610287e262a873b807a06ac980a17cd1101b 100644
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -548,7 +548,6 @@ static const struct inet6_protocol frag_protocol = {
};
#ifdef CONFIG_SYSCTL
-static int zero;
static struct ctl_table ip6_frags_ns_ctl_table[] = {
{
@@ -565,7 +564,6 @@ static struct ctl_table ip6_frags_ns_ctl_table[] = {
.maxlen = sizeof(unsigned long),
.mode = 0644,
.proc_handler = proc_doulongvec_minmax,
- .extra1 = &zero,
.extra2 = &init_net.ipv6.frags.high_thresh
},
{
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply related
* Re: [net-next 1/1] tipc: Fix missing list initializations in struct tipc_subscription
From: David Miller @ 2018-04-04 15:34 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen,
hoang.h.le, canh.d.luu, ying.xue, tipc-discussion
In-Reply-To: <1522775479-16746-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Tue, 3 Apr 2018 19:11:19 +0200
> When an item of struct tipc_subscription is created, we fail to
> initialize the two lists aggregated into the struct. This has so far
> never been a problem, since the items are just added to a root
> object by list_add(), which does not require the addee list to be
> pre-initialized. However, syzbot is provoking situations where this
> addition fails, whereupon the attempted removal if the item from
> the list causes a crash.
>
> This problem seems to always have been around, despite that the code
> for creating this object was rewritten in commit 242e82cc95f6 ("tipc:
> collapse subscription creation functions"), which is still in net-next.
>
> We fix this for that commit by initializing the two lists properly.
>
> Fixes: 242e82cc95f6 ("tipc: collapse subscription creation functions")
> Reported-by: syzbot+0bb443b74ce09197e970@syzkaller.appspotmail.com
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied, thanks Jon.
^ permalink raw reply
* Re: [PATCH] netdevsim: remove incorrect __net_initdata annotations
From: David Ahern @ 2018-04-04 15:33 UTC (permalink / raw)
To: Arnd Bergmann, Jakub Kicinski; +Cc: David S. Miller, netdev, linux-kernel
In-Reply-To: <20180404121347.3089169-1-arnd@arndb.de>
On 4/4/18 6:12 AM, Arnd Bergmann wrote:
> The __net_initdata section cannot currently be used for structures that
> get cleaned up in an exitcall using unregister_pernet_operations:
>
> WARNING: vmlinux.o(.text+0x868c34): Section mismatch in reference from the function nsim_devlink_exit() to the (unknown reference) .init.data:(unknown)
> The function nsim_devlink_exit() references
> the (unknown reference) __initdata (unknown).
> This is often because nsim_devlink_exit lacks a __initdata
> annotation or the annotation of (unknown) is wrong.
> WARNING: vmlinux.o(.text+0x868c64): Section mismatch in reference from the function nsim_devlink_init() to the (unknown reference) .init.data:(unknown)
> WARNING: vmlinux.o(.text+0x8692bc): Section mismatch in reference from the function nsim_fib_exit() to the (unknown reference) .init.data:(unknown)
> WARNING: vmlinux.o(.text+0x869300): Section mismatch in reference from the function nsim_fib_init() to the (unknown reference) .init.data:(unknown)
>
> As that warning tells us, discarding the structure after a module is
> loaded would lead to a undefined behavior when that module is removed.
>
> It might be possible to change that annotation so it has no effect for
> loadable modules, but I have not figured out exactly how to do that, and
> we want this to be fixed in -rc1.
>
> This just removes the annotations, just like we do for all other such
> modules.
>
> Fixes: 37923ed6b8ce ("netdevsim: Add simple FIB resource controller via devlink")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/net/netdevsim/devlink.c | 2 +-
> drivers/net/netdevsim/fib.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/netdevsim/devlink.c b/drivers/net/netdevsim/devlink.c
> index 27ae05c5fdaf..1dba47936456 100644
> --- a/drivers/net/netdevsim/devlink.c
> +++ b/drivers/net/netdevsim/devlink.c
> @@ -267,7 +267,7 @@ static int __net_init nsim_devlink_netns_init(struct net *net)
> return 0;
> }
>
> -static struct pernet_operations nsim_devlink_net_ops __net_initdata = {
> +static struct pernet_operations nsim_devlink_net_ops = {
> .init = nsim_devlink_netns_init,
> .id = &nsim_devlink_id,
> .size = sizeof(bool),
> diff --git a/drivers/net/netdevsim/fib.c b/drivers/net/netdevsim/fib.c
> index 0d105bafa261..9bfe9e151e13 100644
> --- a/drivers/net/netdevsim/fib.c
> +++ b/drivers/net/netdevsim/fib.c
> @@ -230,7 +230,7 @@ static int __net_init nsim_fib_netns_init(struct net *net)
> return 0;
> }
>
> -static struct pernet_operations nsim_fib_net_ops __net_initdata = {
> +static struct pernet_operations nsim_fib_net_ops = {
> .init = nsim_fib_netns_init,
> .id = &nsim_fib_net_id,
> .size = sizeof(struct nsim_fib_data),
>
I am confused ... I do the same thing in the VRF driver and that code
has been there since June 2017.
^ permalink raw reply
* Re: [PATCH net v6 0/4] ipv6: udp: set dst cache for a connected sk if current not valid
From: David Miller @ 2018-04-04 15:32 UTC (permalink / raw)
To: alexey.kodanev; +Cc: netdev, edumazet, kafai
In-Reply-To: <1522756810-24985-1-git-send-email-alexey.kodanev@oracle.com>
From: Alexey Kodanev <alexey.kodanev@oracle.com>
Date: Tue, 3 Apr 2018 15:00:06 +0300
> A new RTF_CACHE route can be created with the socket's dst cache
> update between the below calls in udpv6_sendmsg(), when datagram
> sending results to ICMPV6_PKT_TOOBIG error:
>
> dst = ip6_sk_dst_lookup_flow(...)
> ...
> release_dst:
> if (dst) {
> if (connected) {
> ip6_dst_store(sk, dst)
>
> Therefore, the new socket's dst cache reset to the old one on
> "release_dst:".
>
> The first three patches prepare the code to store dst cache
> with ip6_sk_dst_lookup_flow():
...
> The last patch contains the actual fix that removes sk dst cache
> update in the end of udpv6_sendmsg(), and allows to do it in
> ip6_sk_dst_lookup_flow().
Looks good, applied and queued up for -stable.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next 5/5] macvlan/macvtap: Add support for SCTP checksum offload.
From: Davide Caratti @ 2018-04-04 15:31 UTC (permalink / raw)
To: Vladislav Yasevich, netdev
Cc: linux-sctp, virtualization, mst, jasowang, nhorman,
Vladislav Yasevich
In-Reply-To: <20180402134006.10111-6-vyasevic@redhat.com>
On Mon, 2018-04-02 at 09:40 -0400, Vladislav Yasevich wrote:
> Since we now have support for software CRC32c offload, turn it on
> for macvlan and macvtap devices so that guests can take advantage
> of offload SCTP checksums to the host or host hardware.
>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> ---
> drivers/net/macvlan.c | 5 +++--
> drivers/net/tap.c | 8 +++++---
> include/uapi/linux/if_tun.h | 1 +
> 3 files changed, 9 insertions(+), 5 deletions(-)
>
I think also ipvlan can improve its SCTP performance with a similar patch.
WDYT?
thanks,
--
davide
^ permalink raw reply
* Re: [PATCH v2] net: phy: marvell10g: add thermal hwmon device
From: David Miller @ 2018-04-04 15:25 UTC (permalink / raw)
To: rmk+kernel; +Cc: andrew, f.fainelli, linux, netdev
In-Reply-To: <E1f3II5-00077a-R3@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 03 Apr 2018 10:31:45 +0100
> Add a thermal monitoring device for the Marvell 88x3310, which updates
> once a second. We also need to hook into the suspend/resume mechanism
> to ensure that the thermal monitoring is reconfigured when we resume.
>
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> v2: update to apply to net-next
Applied, thanks for respinning.
^ permalink raw reply
* Re: [PATCH net-next] pptp: remove a buggy dst release in pptp_connect()
From: David Miller @ 2018-04-04 15:19 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <20180403014837.56377-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 2 Apr 2018 18:48:37 -0700
> Once dst has been cached in socket via sk_setup_caps(),
> it is illegal to call ip_rt_put() (or dst_release()),
> since sk_setup_caps() did not change dst refcount.
>
> We can still dereference it since we hold socket lock.
>
> Caugth by syzbot :
...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH net] net: dsa: mt7530: Use NULL instead of plain integer
From: David Miller @ 2018-04-04 15:16 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, sean.wang, andrew, vivien.didelot, linux-kernel
In-Reply-To: <20180402232414.19671-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 2 Apr 2018 16:24:14 -0700
> We would be passing 0 instead of NULL as the rsp argument to
> mt7530_fdb_cmd(), fix that.
>
> Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] net: dsa: b53: Fix sparse warnings in b53_mmap.c
From: David Miller @ 2018-04-04 15:16 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, jonas.gorski, andrew, vivien.didelot, linux-kernel
In-Reply-To: <20180402231701.17348-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 2 Apr 2018 16:17:01 -0700
> sparse complains about the following warnings:
>
> drivers/net/dsa/b53/b53_mmap.c:33:31: warning: incorrect type in
> initializer (different address spaces)
> drivers/net/dsa/b53/b53_mmap.c:33:31: expected unsigned char
> [noderef] [usertype] <asn:2>*regs
> drivers/net/dsa/b53/b53_mmap.c:33:31: got void *priv
>
> and indeed, while what we are doing is functional, we are dereferencing
> a void * pointer into a void __iomem * which is not great. Just use the
> defined b53_mmap_priv structure which holds our register base and use
> that.
>
> Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied.
^ permalink raw reply
* Re: [Patch net] af_unix: remove redundant lockdep class
From: David Miller @ 2018-04-04 15:14 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, pabeni
In-Reply-To: <20180402180127.4047-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 2 Apr 2018 11:01:27 -0700
> After commit 581319c58600 ("net/socket: use per af lockdep classes for sk queues")
> sock queue locks now have per-af lockdep classes, including unix socket.
> It is no longer necessary to workaround it.
>
> I noticed this while looking at a syzbot deadlock report, this patch
> itself doesn't fix it (this is why I don't add Reported-by).
>
> Fixes: 581319c58600 ("net/socket: use per af lockdep classes for sk queues")
> Cc: Paolo Abeni <pabeni@redhat.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied, thanks Cong.
^ permalink raw reply
* Re: [PATCH net 0/2] net: Broadcom drivers sparse fixes
From: David Miller @ 2018-04-04 15:07 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, opendmb, linux-kernel
In-Reply-To: <20180402225856.4351-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 2 Apr 2018 15:58:54 -0700
> This patch series fixes the same warning reported by sparse in bcmsysport and
> bcmgenet in the code that deals with inserting the TX checksum pointers:
>
> drivers/net/ethernet/broadcom/bcmsysport.c:1155:26: warning: cast from restricted __be16
> drivers/net/ethernet/broadcom/bcmsysport.c:1155:26: warning: incorrect type in argument 1 (different base types)
> drivers/net/ethernet/broadcom/bcmsysport.c:1155:26: expected unsigned short [unsigned] [usertype] val
> drivers/net/ethernet/broadcom/bcmsysport.c:1155:26: got restricted __be16 [usertype] protocol
>
> This patch fixes both issues by using the same construct and not swapping
> skb->protocol but instead the values we are checking against.
Series applied, thanks Florian.
^ permalink raw reply
* Re: [PATCH net-next] rxrpc: Fix undefined packet handling
From: David Miller @ 2018-04-04 15:06 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-afs, linux-kernel
In-Reply-To: <152270949946.20618.15535005483715424318.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Mon, 02 Apr 2018 23:51:39 +0100
> By analogy with other Rx implementations, RxRPC packet types 9, 10 and 11
> should just be discarded rather than being aborted like other undefined
> packet types.
>
> Reported-by: Jeffrey Altman <jaltman@auristor.com>
> Signed-off-by: David Howells <dhowells@redhat.com>
Applied, thank you.
^ permalink raw reply
* RE: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun
From: Jon Rosen (jrosen) @ 2018-04-04 14:59 UTC (permalink / raw)
To: Willem de Bruijn
Cc: David S. Miller, Willem de Bruijn, Eric Dumazet, Kees Cook,
David Windsor, Rosen, Rami, Reshetova, Elena, Mike Maloney,
Benjamin Poirier, open list:NETWORKING [GENERAL], open list
In-Reply-To: <CAF=yD-L8DaS7LW4SAaTRd2RPxVnfrdiVLCdWJxxaTu3Hn8ORSA@mail.gmail.com>
On Wednesday, April 04, 2018 9:49 AM, Willem de Bruijn <willemb@google.com> wrote:
>
> On Tue, Apr 3, 2018 at 11:55 PM, Jon Rosen <jrosen@cisco.com> wrote:
> > Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
> > casues the ring to get corrupted by allowing multiple kernel threads
> > to claim ownership of the same ring entry, Mark the ring entry as
> > already being used within the spin_lock to prevent other kernel
> > threads from reusing the same entry before it's fully filled in,
> > passed to user space, and then eventually passed back to the kernel
> > for use with a new packet.
> >
> > Note that the proposed change may modify the semantics of the
> > interface between kernel space and user space in a way which may cause
> > some applications to no longer work properly.
>
> As long as TP_STATUS_USER (1) is not set, userspace should ignore
> the slot..
>
> > One issue with the above proposed change to use TP_STATUS_IN_PROGRESS
> > is that the documentation of the tp_status field is somewhat
> > inconsistent. In some places it's described as TP_STATUS_KERNEL(0)
> > meaning the entry is owned by the kernel and !TP_STATUS_KERNEL(0)
> > meaning the entry is owned by user space. In other places ownership
> > by user space is defined by the TP_STATUS_USER(1) bit being set.
>
> But indeed this example in packet_mmap.txt is problematic
>
> if (status == TP_STATUS_KERNEL)
> retval = poll(&pfd, 1, timeout);
>
> It does not really matter whether the docs are possibly inconsistent and
> which one is authoritative. Examples like the above make it likely that
> some user code expects such code to work.
Yes, that's exactly my concern. Yet another troubling example seems to be
lipbcap which also is looking specifically for status to be anything other than
TP_STATUS_KERNEL(0) to indicate a frame is available in user space.
Either way things are broken. They are broken as they stand now because the
ring can get overrun and the kernel and user space tracking of the ring can
get out of sync. And they are broken with the below change because some user
space applications will be looking for anything other than TP_STATUS_KERNEL,
so again the ring will get out of sync.
The difference here being that the way it is today is on average (across all environments
and across all user space apps) less likely to occur while with the change below it is
much more likely to occur.
Maybe the right answer here is to implement a fix that is compatible for existing
applications and accept any potential performance impacts and then add yet another
version (TPACKET_V4?) which more strictly requires the TP_STATUS_USER bit for
passing ownership.
>
> > +++ b/net/packet/af_packet.c
> > @@ -2287,6 +2287,15 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev,
> > if (po->stats.stats1.tp_drops)
> > status |= TP_STATUS_LOSING;
> > }
> > +
> > + /*
> > + * Mark this entry as TP_STATUS_IN_PROGRESS to prevent other
> > + * kernel threads from re-using this same entry.
> > + */
> > +#define TP_STATUS_IN_PROGRESS TP_STATUS_LOSING
>
> No need to reinterpret existing flags. tp_status is a u32 with
> sufficient undefined bits.
Agreed.
>
> > + if (po->tp_version <= TPACKET_V2)
> > + __packet_set_status(po, h.raw, TP_STATUS_IN_PROGRESS);
> > +
> > po->stats.stats1.tp_packets++;
> > if (copy_skb) {
> > status |= TP_STATUS_COPY;
> > --
> > 2.10.3.dirty
> >
Thanks for the feedback!
Jon.
^ permalink raw reply
* Re: RTL8723BE performance regression
From: Steve deRosier @ 2018-04-04 14:54 UTC (permalink / raw)
To: João Paulo Rechi Vita
Cc: Larry Finger, Yan-Hsuan Chuang, Ping-Ke Shih, Birming Chiu,
Shaofu, Steven Ting, Chaoming Li, Kalle Valo, linux-wireless,
Network Development, LKML, Daniel Drake,
João Paulo Rechi Vita, Linux Upstreaming Team
In-Reply-To: <CA+A7VXX+z8FrDhzW2BQ6AGMJ=_j_53wkUL_YNgkreEbWSh+jCw@mail.gmail.com>
On Tue, Apr 3, 2018 at 6:51 PM, João Paulo Rechi Vita <jprvita@gmail.com> wrote:
>
> This are the results (testing with speedtest.net) I got at some key points:
>
> Version Commit Ping Down Up
>
> v4.11 a351e9b 12 25.44 5.99
> v4.11 a351e9b 131 17.02 5.89
>
> v4.13 569dbb8 174 14.08 0.00
> v4.13 569dbb8 261 8.41 0.00
>
> v4.15+revert d8a5b80 19 23.86 1.41
> v4.15+revert d8a5b80 189 18.69 1.39
>
I recommend doing throughput testing in a closed system using iperf.
speedtest.net is potentially useful for testing your ISP's bandwidth
at some particular point in time, but little else as it exposes you to
too many variables. I wouldn't take those numbers to mean much and the
inconclusive results you're getting could be explained by external
network loading and having little to do with your bisect effort. I can
get that spread in numbers from speedtest.net without making any
changes other than the time of day I do the test.
Here's how to do it. Install iperf2 (you could use iperf3, personal
choice) on two machines, one being your device under test (DUT). Setup
a network configuration that looks similar to this:
server <==hardwire==> AP <--wireless link--> DUT
Be sure your hardwire is more bandwidth than your wireless link is
capable of, or set it up where the server is the AP. What you're
looking for here is environmental consistency, not maximum throughput
numbers.
On the computer hardwired to the network, start the server, we'll
assume it has an ip of 192.168.33.18:
iperf -s
On your DUT:
iperf -c 192.168.33.18
That's the most basic setup, check the man page for more options.
You will get best results if you can exclude other computers from your
test network and other wireless devices from your airspace.
- Steve
--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/
^ 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