* [PATCH 3/5] xfrm: remove VLA usage in __xfrm6_sort()
From: Steffen Klassert @ 2018-05-07 9:01 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20180507090116.31222-1-steffen.klassert@secunet.com>
From: Kees Cook <keescook@chromium.org>
In the quest to remove all stack VLA usage removed from the kernel[1],
just use XFRM_MAX_DEPTH as already done for the "class" array. In one
case, it'll do this loop up to 5, the other caller up to 6.
[1] https://lkml.org/lkml/2018/3/7/621
Co-developed-by: Andreas Christoforou <andreaschristofo@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv6/xfrm6_state.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/xfrm6_state.c b/net/ipv6/xfrm6_state.c
index 16f434791763..5bdca3d5d6b7 100644
--- a/net/ipv6/xfrm6_state.c
+++ b/net/ipv6/xfrm6_state.c
@@ -60,11 +60,9 @@ xfrm6_init_temprop(struct xfrm_state *x, const struct xfrm_tmpl *tmpl,
static int
__xfrm6_sort(void **dst, void **src, int n, int (*cmp)(void *p), int maxclass)
{
- int i;
+ int count[XFRM_MAX_DEPTH] = { };
int class[XFRM_MAX_DEPTH];
- int count[maxclass];
-
- memset(count, 0, sizeof(count));
+ int i;
for (i = 0; i < n; i++) {
int c;
--
2.14.1
^ permalink raw reply related
* pull request (net-next): ipsec-next 2018-05-07
From: Steffen Klassert @ 2018-05-07 9:01 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
1) Add selftests for the xfrm commands.
From Shannon Nelson.
2) Enable hardware checksum offload for ESP encapsulated
UDP packets if the hardware supports this.
From Jacek Kalwas.
3) Remove VLA usage in __xfrm6_sort. From Kees Cook.
4) Fix a typo in the comment of vti6_ioctl.
From Sun Lianwen.
5) Use a dedicated slab cache for struct xfrm_state,
this reduces the memory usage of this struct
by 25 percent. From Mathias Krause.
Please note that this pull request has a merge conflict
between commit:
bec1f6f69736 ("udp: generate gso with UDP_SEGMENT")
from the net-next tree and commit:
cd027a5433d6 ("udp: enable UDP checksum offload for ESP")
from the ipsec-next tree.
The conflict can be solved as done in linux-next.
Please pull or let me know if there are problems.
Thanks!
The following changes since commit ef53e9e14714de2ce26eaae0244c07c426064d69:
net: Remove unused tcp_set_state tracepoint (2018-04-16 19:02:15 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git master
for you to fetch changes up to 565f0fa902b64020d5d147ff1708567e9e0b6e49:
xfrm: use a dedicated slab cache for struct xfrm_state (2018-05-04 10:14:00 +0200)
----------------------------------------------------------------
Jacek Kalwas (1):
udp: enable UDP checksum offload for ESP
Kees Cook (1):
xfrm: remove VLA usage in __xfrm6_sort()
Mathias Krause (1):
xfrm: use a dedicated slab cache for struct xfrm_state
Shannon Nelson (1):
selftests: add xfrm state-policy-monitor to rtnetlink.sh
Sun Lianwen (1):
change the comment of vti6_ioctl
net/ipv4/ip_output.c | 2 +-
net/ipv6/ip6_vti.c | 2 +-
net/ipv6/xfrm6_state.c | 6 +-
net/xfrm/xfrm_state.c | 9 ++-
tools/testing/selftests/net/rtnetlink.sh | 103 +++++++++++++++++++++++++++++++
5 files changed, 114 insertions(+), 8 deletions(-)
^ permalink raw reply
* [PATCH 1/3] af_key: Always verify length of provided sadb_key
From: Steffen Klassert @ 2018-05-07 8:43 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20180507084323.22165-1-steffen.klassert@secunet.com>
From: Kevin Easton <kevin@guarana.org>
Key extensions (struct sadb_key) include a user-specified number of key
bits. The kernel uses that number to determine how much key data to copy
out of the message in pfkey_msg2xfrm_state().
The length of the sadb_key message must be verified to be long enough,
even in the case of SADB_X_AALG_NULL. Furthermore, the sadb_key_len value
must be long enough to include both the key data and the struct sadb_key
itself.
Introduce a helper function verify_key_len(), and call it from
parse_exthdrs() where other exthdr types are similarly checked for
correctness.
Signed-off-by: Kevin Easton <kevin@guarana.org>
Reported-by: syzbot+5022a34ca5a3d49b84223653fab632dfb7b4cf37@syzkaller.appspotmail.com
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/key/af_key.c | 45 +++++++++++++++++++++++++++++++++++----------
1 file changed, 35 insertions(+), 10 deletions(-)
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 7e2e7188e7f4..e62e52e8f141 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -437,6 +437,24 @@ static int verify_address_len(const void *p)
return 0;
}
+static inline int sadb_key_len(const struct sadb_key *key)
+{
+ int key_bytes = DIV_ROUND_UP(key->sadb_key_bits, 8);
+
+ return DIV_ROUND_UP(sizeof(struct sadb_key) + key_bytes,
+ sizeof(uint64_t));
+}
+
+static int verify_key_len(const void *p)
+{
+ const struct sadb_key *key = p;
+
+ if (sadb_key_len(key) > key->sadb_key_len)
+ return -EINVAL;
+
+ return 0;
+}
+
static inline int pfkey_sec_ctx_len(const struct sadb_x_sec_ctx *sec_ctx)
{
return DIV_ROUND_UP(sizeof(struct sadb_x_sec_ctx) +
@@ -533,16 +551,25 @@ static int parse_exthdrs(struct sk_buff *skb, const struct sadb_msg *hdr, void *
return -EINVAL;
if (ext_hdrs[ext_type-1] != NULL)
return -EINVAL;
- if (ext_type == SADB_EXT_ADDRESS_SRC ||
- ext_type == SADB_EXT_ADDRESS_DST ||
- ext_type == SADB_EXT_ADDRESS_PROXY ||
- ext_type == SADB_X_EXT_NAT_T_OA) {
+ switch (ext_type) {
+ case SADB_EXT_ADDRESS_SRC:
+ case SADB_EXT_ADDRESS_DST:
+ case SADB_EXT_ADDRESS_PROXY:
+ case SADB_X_EXT_NAT_T_OA:
if (verify_address_len(p))
return -EINVAL;
- }
- if (ext_type == SADB_X_EXT_SEC_CTX) {
+ break;
+ case SADB_X_EXT_SEC_CTX:
if (verify_sec_ctx_len(p))
return -EINVAL;
+ break;
+ case SADB_EXT_KEY_AUTH:
+ case SADB_EXT_KEY_ENCRYPT:
+ if (verify_key_len(p))
+ return -EINVAL;
+ break;
+ default:
+ break;
}
ext_hdrs[ext_type-1] = (void *) p;
}
@@ -1104,14 +1131,12 @@ static struct xfrm_state * pfkey_msg2xfrm_state(struct net *net,
key = ext_hdrs[SADB_EXT_KEY_AUTH - 1];
if (key != NULL &&
sa->sadb_sa_auth != SADB_X_AALG_NULL &&
- ((key->sadb_key_bits+7) / 8 == 0 ||
- (key->sadb_key_bits+7) / 8 > key->sadb_key_len * sizeof(uint64_t)))
+ key->sadb_key_bits == 0)
return ERR_PTR(-EINVAL);
key = ext_hdrs[SADB_EXT_KEY_ENCRYPT-1];
if (key != NULL &&
sa->sadb_sa_encrypt != SADB_EALG_NULL &&
- ((key->sadb_key_bits+7) / 8 == 0 ||
- (key->sadb_key_bits+7) / 8 > key->sadb_key_len * sizeof(uint64_t)))
+ key->sadb_key_bits == 0)
return ERR_PTR(-EINVAL);
x = xfrm_state_alloc(net);
--
2.14.1
^ permalink raw reply related
* [PATCH 2/3] xfrm: Fix warning in xfrm6_tunnel_net_exit.
From: Steffen Klassert @ 2018-05-07 8:43 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20180507084323.22165-1-steffen.klassert@secunet.com>
We need to make sure that all states are really deleted
before we check that the state lists are empty. Otherwise
we trigger a warning.
Fixes: baeb0dbbb5659 ("xfrm6_tunnel: exit_net cleanup check added")
Reported-and-tested-by:syzbot+777bf170a89e7b326405@syzkaller.appspotmail.com
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
include/net/xfrm.h | 1 +
net/ipv6/xfrm6_tunnel.c | 3 +++
net/xfrm/xfrm_state.c | 6 ++++++
3 files changed, 10 insertions(+)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index a872379b69da..45e75c36b738 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -375,6 +375,7 @@ struct xfrm_input_afinfo {
int xfrm_input_register_afinfo(const struct xfrm_input_afinfo *afinfo);
int xfrm_input_unregister_afinfo(const struct xfrm_input_afinfo *afinfo);
+void xfrm_flush_gc(void);
void xfrm_state_delete_tunnel(struct xfrm_state *x);
struct xfrm_type {
diff --git a/net/ipv6/xfrm6_tunnel.c b/net/ipv6/xfrm6_tunnel.c
index f85f0d7480ac..4a46df8441c9 100644
--- a/net/ipv6/xfrm6_tunnel.c
+++ b/net/ipv6/xfrm6_tunnel.c
@@ -341,6 +341,9 @@ static void __net_exit xfrm6_tunnel_net_exit(struct net *net)
struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net);
unsigned int i;
+ xfrm_state_flush(net, IPSEC_PROTO_ANY, false);
+ xfrm_flush_gc();
+
for (i = 0; i < XFRM6_TUNNEL_SPI_BYADDR_HSIZE; i++)
WARN_ON_ONCE(!hlist_empty(&xfrm6_tn->spi_byaddr[i]));
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index f9d2f2233f09..6c177ae7a6d9 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -2175,6 +2175,12 @@ struct xfrm_state_afinfo *xfrm_state_get_afinfo(unsigned int family)
return afinfo;
}
+void xfrm_flush_gc(void)
+{
+ flush_work(&xfrm_state_gc_work);
+}
+EXPORT_SYMBOL(xfrm_flush_gc);
+
/* Temporarily located here until net/xfrm/xfrm_tunnel.c is created */
void xfrm_state_delete_tunnel(struct xfrm_state *x)
{
--
2.14.1
^ permalink raw reply related
* [PATCH 3/3] vti6: Change minimum MTU to IPV4_MIN_MTU, vti6 can carry IPv4 too
From: Steffen Klassert @ 2018-05-07 8:43 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20180507084323.22165-1-steffen.klassert@secunet.com>
From: Stefano Brivio <sbrivio@redhat.com>
A vti6 interface can carry IPv4 as well, so it makes no sense to
enforce a minimum MTU of IPV6_MIN_MTU.
If the user sets an MTU below IPV6_MIN_MTU, IPv6 will be
disabled on the interface, courtesy of addrconf_notify().
Reported-by: Xin Long <lucien.xin@gmail.com>
Fixes: b96f9afee4eb ("ipv4/6: use core net MTU range checking")
Fixes: c6741fbed6dc ("vti6: Properly adjust vti6 MTU from MTU of lower device")
Fixes: 53c81e95df17 ("ip6_vti: adjust vti mtu according to mtu of lower device")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv6/ip6_vti.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index c214ffec02f0..ca957dd93a29 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -669,7 +669,7 @@ static void vti6_link_config(struct ip6_tnl *t, bool keep_mtu)
else
mtu = ETH_DATA_LEN - LL_MAX_HEADER - sizeof(struct ipv6hdr);
- dev->mtu = max_t(int, mtu, IPV6_MIN_MTU);
+ dev->mtu = max_t(int, mtu, IPV4_MIN_MTU);
}
/**
@@ -881,7 +881,7 @@ static void vti6_dev_setup(struct net_device *dev)
dev->priv_destructor = vti6_dev_free;
dev->type = ARPHRD_TUNNEL6;
- dev->min_mtu = IPV6_MIN_MTU;
+ dev->min_mtu = IPV4_MIN_MTU;
dev->max_mtu = IP_MAX_MTU - sizeof(struct ipv6hdr);
dev->flags |= IFF_NOARP;
dev->addr_len = sizeof(struct in6_addr);
--
2.14.1
^ permalink raw reply related
* pull request (net): ipsec 2018-05-07
From: Steffen Klassert @ 2018-05-07 8:43 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
1) Always verify length of provided sadb_key to fix a
slab-out-of-bounds read in pfkey_add. From Kevin Easton.
2) Make sure that all states are really deleted
before we check that the state lists are empty.
Otherwise we trigger a warning.
3) Fix MTU handling of the VTI6 interfaces on
interfamily tunnels. From Stefano Brivio.
Please pull or let me know if there are problems.
Thanks!
The following changes since commit 76327a35caabd1a932e83d6a42b967aa08584e5d:
dp83640: Ensure against premature access to PHY registers after reset (2018-04-08 19:58:52 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec.git master
for you to fetch changes up to b4331a681822b420511b3258f1c3db35001fde48:
vti6: Change minimum MTU to IPV4_MIN_MTU, vti6 can carry IPv4 too (2018-04-27 07:29:23 +0200)
----------------------------------------------------------------
Kevin Easton (1):
af_key: Always verify length of provided sadb_key
Stefano Brivio (1):
vti6: Change minimum MTU to IPV4_MIN_MTU, vti6 can carry IPv4 too
Steffen Klassert (1):
xfrm: Fix warning in xfrm6_tunnel_net_exit.
include/net/xfrm.h | 1 +
net/ipv6/ip6_vti.c | 4 ++--
net/ipv6/xfrm6_tunnel.c | 3 +++
net/key/af_key.c | 45 +++++++++++++++++++++++++++++++++++----------
net/xfrm/xfrm_state.c | 6 ++++++
5 files changed, 47 insertions(+), 12 deletions(-)
^ permalink raw reply
* Re: WARNING in kernfs_add_one
From: Johannes Berg @ 2018-05-07 8:43 UTC (permalink / raw)
To: Greg KH, linux-wireless, Eric Dumazet
Cc: netdev, syzbot, linux-kernel, syzkaller-bugs, tj
In-Reply-To: <20180505220721.GA10829@kroah.com>
On Sat, 2018-05-05 at 15:07 -0700, Greg KH wrote:
> > > > syzbot found the following crash on:
Maybe it should learn to differentiate warnings, if it's going to set
panic_on_warn :-)
I get why, but still, at least differentiating in the emails wouldn't be
bad.
> > > > kernfs: ns required in 'ieee80211' for 'phy3'
Huh. What does that even mean?
> > > > RIP: 0010:kernfs_add_one+0x406/0x4d0 fs/kernfs/dir.c:758
> > > > RSP: 0018:ffff8801ca9eece0 EFLAGS: 00010286
> > > > RAX: 000000000000002d RBX: ffffffff87d5cee0 RCX: ffffffff8160ba7d
> > > > RDX: 0000000000000000 RSI: ffffffff81610731 RDI: ffff8801ca9ee840
> > > > RBP: ffff8801ca9eed20 R08: ffff8801d9538500 R09: 0000000000000006
> > > > R10: ffff8801d9538500 R11: 0000000000000000 R12: ffff8801ad1cb6c0
> > > > R13: ffffffff885da640 R14: 0000000000000020 R15: 0000000000000000
> > > > kernfs_create_link+0x112/0x180 fs/kernfs/symlink.c:41
> > > > sysfs_do_create_link_sd.isra.2+0x90/0x130 fs/sysfs/symlink.c:43
> > > > sysfs_do_create_link fs/sysfs/symlink.c:79 [inline]
> > > > sysfs_create_link+0x65/0xc0 fs/sysfs/symlink.c:91
> > > > device_add_class_symlinks drivers/base/core.c:1612 [inline]
> > > > device_add+0x7a0/0x16d0 drivers/base/core.c:1810
> > > > wiphy_register+0x178a/0x2430 net/wireless/core.c:806
> > > > ieee80211_register_hw+0x13cd/0x35d0 net/mac80211/main.c:1047
> > > > mac80211_hwsim_new_radio+0x1d9b/0x3410
> > > > drivers/net/wireless/mac80211_hwsim.c:2772
> > > > hwsim_new_radio_nl+0x7a7/0xa60 drivers/net/wireless/mac80211_hwsim.c:3246
> > > > genl_family_rcv_msg+0x889/0x1120 net/netlink/genetlink.c:599
Basically we're creating a new virtual radio, which in turn creates a
new device, which we have to register.
Something is going on with the context here that makes sysfs unhappy,
but TBH I have no idea what.
johannes
^ permalink raw reply
* Re: [PATCH] bpf: fix misaligned access for BPF_PROG_TYPE_PERF_EVENT program type on x86_32 platform
From: Daniel Borkmann @ 2018-05-07 8:25 UTC (permalink / raw)
To: Wang YanQing, Alexei Starovoitov, ast, netdev, linux-kernel
In-Reply-To: <20180507072305.GA11275@udknight>
On 05/07/2018 09:23 AM, Wang YanQing wrote:
> On Sat, Apr 28, 2018 at 01:29:17PM +0800, Wang YanQing wrote:
>> On Sat, Apr 28, 2018 at 01:33:15AM +0200, Daniel Borkmann wrote:
>>> On 04/28/2018 12:48 AM, Alexei Starovoitov wrote:
>>>> On Thu, Apr 26, 2018 at 05:57:49PM +0800, Wang YanQing wrote:
>>>>> All the testcases for BPF_PROG_TYPE_PERF_EVENT program type in
>>>>> test_verifier(kselftest) report below errors on x86_32:
>>>>> "
>>>>> 172/p unpriv: spill/fill of different pointers ldx FAIL
>>>>> Unexpected error message!
>>>>> 0: (bf) r6 = r10
>>>>> 1: (07) r6 += -8
>>>>> 2: (15) if r1 == 0x0 goto pc+3
>>>>> R1=ctx(id=0,off=0,imm=0) R6=fp-8,call_-1 R10=fp0,call_-1
>>>>> 3: (bf) r2 = r10
>>>>> 4: (07) r2 += -76
>>>>> 5: (7b) *(u64 *)(r6 +0) = r2
>>>>> 6: (55) if r1 != 0x0 goto pc+1
>>>>> R1=ctx(id=0,off=0,imm=0) R2=fp-76,call_-1 R6=fp-8,call_-1 R10=fp0,call_-1 fp-8=fp
>>>>> 7: (7b) *(u64 *)(r6 +0) = r1
>>>>> 8: (79) r1 = *(u64 *)(r6 +0)
>>>>> 9: (79) r1 = *(u64 *)(r1 +68)
>>>>> invalid bpf_context access off=68 size=8
>>>>>
>>>>> 378/p check bpf_perf_event_data->sample_period byte load permitted FAIL
>>>>> Failed to load prog 'Permission denied'!
>>>>> 0: (b7) r0 = 0
>>>>> 1: (71) r0 = *(u8 *)(r1 +68)
>>>>> invalid bpf_context access off=68 size=1
>>>>>
>>>>> 379/p check bpf_perf_event_data->sample_period half load permitted FAIL
>>>>> Failed to load prog 'Permission denied'!
>>>>> 0: (b7) r0 = 0
>>>>> 1: (69) r0 = *(u16 *)(r1 +68)
>>>>> invalid bpf_context access off=68 size=2
>>>>>
>>>>> 380/p check bpf_perf_event_data->sample_period word load permitted FAIL
>>>>> Failed to load prog 'Permission denied'!
>>>>> 0: (b7) r0 = 0
>>>>> 1: (61) r0 = *(u32 *)(r1 +68)
>>>>> invalid bpf_context access off=68 size=4
>>>>>
>>>>> 381/p check bpf_perf_event_data->sample_period dword load permitted FAIL
>>>>> Failed to load prog 'Permission denied'!
>>>>> 0: (b7) r0 = 0
>>>>> 1: (79) r0 = *(u64 *)(r1 +68)
>>>>> invalid bpf_context access off=68 size=8
>>>>> "
>>>>>
>>>>> This patch fix it, the fix isn't only necessary for x86_32, it will fix the
>>>>> same problem for other platforms too, if their size of bpf_user_pt_regs_t
>>>>> can't divide exactly into 8.
>>>>>
>>>>> Signed-off-by: Wang YanQing <udknight@gmail.com>
>>>>> ---
>>>>> Hi all!
>>>>> After mainline accept this patch, then we need to submit a sync patch
>>>>> to update the tools/include/uapi/linux/bpf_perf_event.h.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> include/uapi/linux/bpf_perf_event.h | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/include/uapi/linux/bpf_perf_event.h b/include/uapi/linux/bpf_perf_event.h
>>>>> index eb1b9d2..ff4c092 100644
>>>>> --- a/include/uapi/linux/bpf_perf_event.h
>>>>> +++ b/include/uapi/linux/bpf_perf_event.h
>>>>> @@ -12,7 +12,7 @@
>>>>>
>>>>> struct bpf_perf_event_data {
>>>>> bpf_user_pt_regs_t regs;
>>>>> - __u64 sample_period;
>>>>> + __u64 sample_period __attribute__((aligned(8)));
>>>>
>>>> I don't think this necessary.
>>>> imo it's a bug in pe_prog_is_valid_access
>>>> that should have allowed 8-byte access to 4-byte aligned sample_period.
>>>> The access rewritten by pe_prog_convert_ctx_access anyway,
>>>> no alignment issues as far as I can see.
>>>
>>> Right, good point. Wang, could you give the below a test run:
>>>
>>> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
>>> index 56ba0f2..95b9142 100644
>>> --- a/kernel/trace/bpf_trace.c
>>> +++ b/kernel/trace/bpf_trace.c
>>> @@ -833,8 +833,14 @@ static bool pe_prog_is_valid_access(int off, int size, enum bpf_access_type type
>>> return false;
>>> if (type != BPF_READ)
>>> return false;
>>> - if (off % size != 0)
>>> - return false;
>>> + if (off % size != 0) {
>>> + if (sizeof(long) != 4)
>>> + return false;
>>> + if (size != 8)
>>> + return false;
>>> + if (off % size != 4)
>>> + return false;
>>> + }
>>>
>>> switch (off) {
>>> case bpf_ctx_range(struct bpf_perf_event_data, sample_period):
>> Hi all!
>>
>> I have tested this patch, but test_verifier reports the same errors
>> for the five testcases.
>>
>> The reason is they all failed to pass the test of bpf_ctx_narrow_access_ok.
>>
>> Thanks.
> Hi! Daniel Borkmann.
>
> Do you have any plan to fix bpf_ctx_narrow_access_ok for these problems?
Yep, sorry for the delay, will get to it during this week.
Thanks,
Daniel
^ permalink raw reply
* Re: linux-next: manual merge of the tip tree with the bpf-next tree
From: Daniel Borkmann @ 2018-05-07 8:15 UTC (permalink / raw)
To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Alexei Starovoitov, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20180507141003.79783848@canb.auug.org.au>
On 05/07/2018 06:10 AM, Stephen Rothwell wrote:
> On Mon, 7 May 2018 12:09:09 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the tip tree got a conflict in:
>>
>> arch/x86/net/bpf_jit_comp.c
>>
>> between commit:
>>
>> e782bdcf58c5 ("bpf, x64: remove ld_abs/ld_ind")
>>
>> from the bpf-next tree and commit:
>>
>> 5f26c50143f5 ("x86/bpf: Clean up non-standard comments, to make the code more readable")
>>
>> from the tip tree.
>>
>> I fixed it up (the former commit removed some code modified by the latter,
>> so I just removed it) and can carry the fix as necessary. This is now
>> fixed as far as linux-next is concerned, but any non trivial conflicts
>> should be mentioned to your upstream maintainer when your tree is
>> submitted for merging. You may also want to consider cooperating with
>> the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
>
> Actually the tip tree commit has been added to the bpf-next tree as a
> different commit, so dropping it from the tip tree will clean this up.
Yep, it's been cherry-picked into bpf-next to avoid merge conflicts with
ongoing work.
^ permalink raw reply
* Re: [PATCH] netfilter: nf_queue: Replace conntrack entry
From: Dan Carpenter @ 2018-05-07 8:07 UTC (permalink / raw)
To: kbuild, Kristian Evensen
Cc: Kristian Evensen, netdev, Florian Westphal, linux-kernel,
coreteam, netfilter-devel, kbuild-all, Jozsef Kadlecsik,
David S. Miller, Pablo Neira Ayuso
In-Reply-To: <20180503140745.26588-1-kristian.evensen@gmail.com>
Hi Kristian,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on nf-next/master]
[also build test WARNING on v4.17-rc3 next-20180504]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Kristian-Evensen/netfilter-nf_queue-Replace-conntrack-entry/20180504-051218
base: https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git master
smatch warnings:
net/netfilter/nfnetlink_queue.c:1141 nfqnl_recv_verdict_batch() warn: curly braces intended?
# https://github.com/0day-ci/linux/commit/8776e32a6c6e2ba0c6c8ce85e227672b81a1649d
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 8776e32a6c6e2ba0c6c8ce85e227672b81a1649d
vim +1141 net/netfilter/nfnetlink_queue.c
8776e32a net/netfilter/nfnetlink_queue.c Kristian Evensen 2018-05-03 1093
7b8002a1 net/netfilter/nfnetlink_queue.c Pablo Neira Ayuso 2015-12-15 1094 static int nfqnl_recv_verdict_batch(struct net *net, struct sock *ctnl,
7b8002a1 net/netfilter/nfnetlink_queue.c Pablo Neira Ayuso 2015-12-15 1095 struct sk_buff *skb,
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1096 const struct nlmsghdr *nlh,
04ba724b net/netfilter/nfnetlink_queue.c Pablo Neira Ayuso 2017-06-19 1097 const struct nlattr * const nfqa[],
04ba724b net/netfilter/nfnetlink_queue.c Pablo Neira Ayuso 2017-06-19 1098 struct netlink_ext_ack *extack)
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1099 {
3da07c0c net/netfilter/nfnetlink_queue_core.c David S. Miller 2012-06-26 1100 struct nfgenmsg *nfmsg = nlmsg_data(nlh);
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1101 struct nf_queue_entry *entry, *tmp;
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1102 unsigned int verdict, maxid;
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1103 struct nfqnl_msg_verdict_hdr *vhdr;
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1104 struct nfqnl_instance *queue;
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1105 LIST_HEAD(batch_list);
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1106 u16 queue_num = ntohs(nfmsg->res_id);
e8179610 net/netfilter/nfnetlink_queue_core.c Gao feng 2013-03-24 1107 struct nfnl_queue_net *q = nfnl_queue_pernet(net);
8776e32a net/netfilter/nfnetlink_queue.c Kristian Evensen 2018-05-03 1108 enum ip_conntrack_info ctinfo;
e8179610 net/netfilter/nfnetlink_queue_core.c Gao feng 2013-03-24 1109
e8179610 net/netfilter/nfnetlink_queue_core.c Gao feng 2013-03-24 1110 queue = verdict_instance_lookup(q, queue_num,
e8179610 net/netfilter/nfnetlink_queue_core.c Gao feng 2013-03-24 1111 NETLINK_CB(skb).portid);
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1112 if (IS_ERR(queue))
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1113 return PTR_ERR(queue);
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1114
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1115 vhdr = verdicthdr_get(nfqa);
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1116 if (!vhdr)
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1117 return -EINVAL;
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1118
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1119 verdict = ntohl(vhdr->verdict);
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1120 maxid = ntohl(vhdr->id);
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1121
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1122 spin_lock_bh(&queue->lock);
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1123
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1124 list_for_each_entry_safe(entry, tmp, &queue->queue_list, list) {
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1125 if (nfq_id_after(entry->id, maxid))
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1126 break;
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1127 __dequeue_entry(queue, entry);
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1128 list_add_tail(&entry->list, &batch_list);
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1129 }
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1130
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1131 spin_unlock_bh(&queue->lock);
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1132
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1133 if (list_empty(&batch_list))
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1134 return -ENOENT;
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1135
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1136 list_for_each_entry_safe(entry, tmp, &batch_list, list) {
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1137 if (nfqa[NFQA_MARK])
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1138 entry->skb->mark = ntohl(nla_get_be32(nfqa[NFQA_MARK]));
8776e32a net/netfilter/nfnetlink_queue.c Kristian Evensen 2018-05-03 1139
8776e32a net/netfilter/nfnetlink_queue.c Kristian Evensen 2018-05-03 1140 #if IS_ENABLED(CONFIG_NF_CONNTRACK)
8776e32a net/netfilter/nfnetlink_queue.c Kristian Evensen 2018-05-03 @1141 nf_ct_get(entry->skb, &ctinfo);
8776e32a net/netfilter/nfnetlink_queue.c Kristian Evensen 2018-05-03 1142
8776e32a net/netfilter/nfnetlink_queue.c Kristian Evensen 2018-05-03 1143 if (ctinfo == IP_CT_NEW && verdict != NF_STOLEN &&
8776e32a net/netfilter/nfnetlink_queue.c Kristian Evensen 2018-05-03 1144 verdict != NF_DROP) {
8776e32a net/netfilter/nfnetlink_queue.c Kristian Evensen 2018-05-03 1145 nfqnl_update_ct(net, entry->skb);
8776e32a net/netfilter/nfnetlink_queue.c Kristian Evensen 2018-05-03 1146 }
8776e32a net/netfilter/nfnetlink_queue.c Kristian Evensen 2018-05-03 1147 #endif
8776e32a net/netfilter/nfnetlink_queue.c Kristian Evensen 2018-05-03 1148
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1149 nf_reinject(entry, verdict);
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1150 }
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1151 return 0;
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1152 }
97d32cf9 net/netfilter/nfnetlink_queue.c Florian Westphal 2011-07-19 1153
^ permalink raw reply
* [PATCH net-next 1/2] net: ipv6: Fix typo in ipv6_find_hdr() documentation
From: Tariq Toukan @ 2018-05-07 7:45 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Tariq Toukan
In-Reply-To: <1525679127-26987-1-git-send-email-tariqt@mellanox.com>
Fix 'an' into 'and', and use a comma instead of a period.
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
---
net/ipv6/exthdrs_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/exthdrs_core.c b/net/ipv6/exthdrs_core.c
index b643f5ce6c80..ae365df8abf7 100644
--- a/net/ipv6/exthdrs_core.c
+++ b/net/ipv6/exthdrs_core.c
@@ -161,7 +161,7 @@ int ipv6_find_tlv(const struct sk_buff *skb, int offset, int type)
* if target < 0. "last header" is transport protocol header, ESP, or
* "No next header".
*
- * Note that *offset is used as input/output parameter. an if it is not zero,
+ * Note that *offset is used as input/output parameter, and if it is not zero,
* then it must be a valid offset to an inner IPv6 header. This can be used
* to explore inner IPv6 header, eg. ICMPv6 error messages.
*
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 0/2] net/ipv6 misc
From: Tariq Toukan @ 2018-05-07 7:45 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Tariq Toukan
Hi Dave,
This patchset contains two patches for net/ipv6.
Patch 1 is a trivial typo fix in documentation.
Patch 2 by Eran is a re-spin. It adds GRO support for IPv6 GRE tunnel,
this significantly improves performance in case GRO in native interface
is disabled.
Series generated against net-next commit:
90278871d4b0 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next
Thanks,
Tariq.
Eran Ben Elisha (1):
net: ipv6/gre: Add GRO support
Tariq Toukan (1):
net: ipv6: Fix typo in ipv6_find_hdr() documentation
net/ipv6/exthdrs_core.c | 2 +-
net/ipv6/ip6_gre.c | 37 +++++++++++++++++++++++++++----------
2 files changed, 28 insertions(+), 11 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net-next 2/2] net: ipv6/gre: Add GRO support
From: Tariq Toukan @ 2018-05-07 7:45 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Tariq Toukan, Eric Dumazet
In-Reply-To: <1525679127-26987-1-git-send-email-tariqt@mellanox.com>
From: Eran Ben Elisha <eranbe@mellanox.com>
Add GRO capability for IPv6 GRE tunnel and ip6erspan tap, via gro_cells
infrastructure.
Performance testing: 55% higher badwidth.
Measuring bandwidth of 1 thread IPv4 TCP traffic over IPv6 GRE tunnel
while GRO on the physical interface is disabled.
CPU: Intel Xeon E312xx (Sandy Bridge)
NIC: Mellanox Technologies MT27700 Family [ConnectX-4]
Before (GRO not working in tunnel) : 2.47 Gbits/sec
After (GRO working in tunnel) : 3.85 Gbits/sec
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
CC: Eric Dumazet <edumazet@google.com>
---
net/ipv6/ip6_gre.c | 37 +++++++++++++++++++++++++++----------
1 file changed, 27 insertions(+), 10 deletions(-)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 04c69e0c84b3..b511818b268c 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -1314,6 +1314,7 @@ static void ip6gre_dev_free(struct net_device *dev)
{
struct ip6_tnl *t = netdev_priv(dev);
+ gro_cells_destroy(&t->gro_cells);
dst_cache_destroy(&t->dst_cache);
free_percpu(dev->tstats);
}
@@ -1381,11 +1382,12 @@ static int ip6gre_tunnel_init_common(struct net_device *dev)
return -ENOMEM;
ret = dst_cache_init(&tunnel->dst_cache, GFP_KERNEL);
- if (ret) {
- free_percpu(dev->tstats);
- dev->tstats = NULL;
- return ret;
- }
+ if (ret)
+ goto cleanup_alloc_pcpu_stats;
+
+ ret = gro_cells_init(&tunnel->gro_cells, dev);
+ if (ret)
+ goto cleanup_dst_cache_init;
tunnel->tun_hlen = gre_calc_hlen(tunnel->parms.o_flags);
tunnel->hlen = tunnel->tun_hlen + tunnel->encap_hlen;
@@ -1405,6 +1407,13 @@ static int ip6gre_tunnel_init_common(struct net_device *dev)
ip6gre_tnl_init_features(dev);
return 0;
+
+cleanup_dst_cache_init:
+ dst_cache_destroy(&tunnel->dst_cache);
+cleanup_alloc_pcpu_stats:
+ free_percpu(dev->tstats);
+ dev->tstats = NULL;
+ return ret;
}
static int ip6gre_tunnel_init(struct net_device *dev)
@@ -1751,11 +1760,12 @@ static int ip6erspan_tap_init(struct net_device *dev)
return -ENOMEM;
ret = dst_cache_init(&tunnel->dst_cache, GFP_KERNEL);
- if (ret) {
- free_percpu(dev->tstats);
- dev->tstats = NULL;
- return ret;
- }
+ if (ret)
+ goto cleanup_alloc_pcpu_stats;
+
+ ret = gro_cells_init(&tunnel->gro_cells, dev);
+ if (ret)
+ goto cleanup_dst_cache_init;
tunnel->tun_hlen = 8;
tunnel->hlen = tunnel->tun_hlen + tunnel->encap_hlen +
@@ -1773,6 +1783,13 @@ static int ip6erspan_tap_init(struct net_device *dev)
ip6gre_tnl_link_config(tunnel, 1);
return 0;
+
+cleanup_dst_cache_init:
+ dst_cache_destroy(&tunnel->dst_cache);
+cleanup_alloc_pcpu_stats:
+ free_percpu(dev->tstats);
+ dev->tstats = NULL;
+ return ret;
}
static const struct net_device_ops ip6erspan_netdev_ops = {
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] bpf: fix misaligned access for BPF_PROG_TYPE_PERF_EVENT program type on x86_32 platform
From: Wang YanQing @ 2018-05-07 7:23 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, ast, netdev, linux-kernel
In-Reply-To: <20180428052917.GA1579@udknight>
On Sat, Apr 28, 2018 at 01:29:17PM +0800, Wang YanQing wrote:
> On Sat, Apr 28, 2018 at 01:33:15AM +0200, Daniel Borkmann wrote:
> > On 04/28/2018 12:48 AM, Alexei Starovoitov wrote:
> > > On Thu, Apr 26, 2018 at 05:57:49PM +0800, Wang YanQing wrote:
> > >> All the testcases for BPF_PROG_TYPE_PERF_EVENT program type in
> > >> test_verifier(kselftest) report below errors on x86_32:
> > >> "
> > >> 172/p unpriv: spill/fill of different pointers ldx FAIL
> > >> Unexpected error message!
> > >> 0: (bf) r6 = r10
> > >> 1: (07) r6 += -8
> > >> 2: (15) if r1 == 0x0 goto pc+3
> > >> R1=ctx(id=0,off=0,imm=0) R6=fp-8,call_-1 R10=fp0,call_-1
> > >> 3: (bf) r2 = r10
> > >> 4: (07) r2 += -76
> > >> 5: (7b) *(u64 *)(r6 +0) = r2
> > >> 6: (55) if r1 != 0x0 goto pc+1
> > >> R1=ctx(id=0,off=0,imm=0) R2=fp-76,call_-1 R6=fp-8,call_-1 R10=fp0,call_-1 fp-8=fp
> > >> 7: (7b) *(u64 *)(r6 +0) = r1
> > >> 8: (79) r1 = *(u64 *)(r6 +0)
> > >> 9: (79) r1 = *(u64 *)(r1 +68)
> > >> invalid bpf_context access off=68 size=8
> > >>
> > >> 378/p check bpf_perf_event_data->sample_period byte load permitted FAIL
> > >> Failed to load prog 'Permission denied'!
> > >> 0: (b7) r0 = 0
> > >> 1: (71) r0 = *(u8 *)(r1 +68)
> > >> invalid bpf_context access off=68 size=1
> > >>
> > >> 379/p check bpf_perf_event_data->sample_period half load permitted FAIL
> > >> Failed to load prog 'Permission denied'!
> > >> 0: (b7) r0 = 0
> > >> 1: (69) r0 = *(u16 *)(r1 +68)
> > >> invalid bpf_context access off=68 size=2
> > >>
> > >> 380/p check bpf_perf_event_data->sample_period word load permitted FAIL
> > >> Failed to load prog 'Permission denied'!
> > >> 0: (b7) r0 = 0
> > >> 1: (61) r0 = *(u32 *)(r1 +68)
> > >> invalid bpf_context access off=68 size=4
> > >>
> > >> 381/p check bpf_perf_event_data->sample_period dword load permitted FAIL
> > >> Failed to load prog 'Permission denied'!
> > >> 0: (b7) r0 = 0
> > >> 1: (79) r0 = *(u64 *)(r1 +68)
> > >> invalid bpf_context access off=68 size=8
> > >> "
> > >>
> > >> This patch fix it, the fix isn't only necessary for x86_32, it will fix the
> > >> same problem for other platforms too, if their size of bpf_user_pt_regs_t
> > >> can't divide exactly into 8.
> > >>
> > >> Signed-off-by: Wang YanQing <udknight@gmail.com>
> > >> ---
> > >> Hi all!
> > >> After mainline accept this patch, then we need to submit a sync patch
> > >> to update the tools/include/uapi/linux/bpf_perf_event.h.
> > >>
> > >> Thanks.
> > >>
> > >> include/uapi/linux/bpf_perf_event.h | 2 +-
> > >> 1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/include/uapi/linux/bpf_perf_event.h b/include/uapi/linux/bpf_perf_event.h
> > >> index eb1b9d2..ff4c092 100644
> > >> --- a/include/uapi/linux/bpf_perf_event.h
> > >> +++ b/include/uapi/linux/bpf_perf_event.h
> > >> @@ -12,7 +12,7 @@
> > >>
> > >> struct bpf_perf_event_data {
> > >> bpf_user_pt_regs_t regs;
> > >> - __u64 sample_period;
> > >> + __u64 sample_period __attribute__((aligned(8)));
> > >
> > > I don't think this necessary.
> > > imo it's a bug in pe_prog_is_valid_access
> > > that should have allowed 8-byte access to 4-byte aligned sample_period.
> > > The access rewritten by pe_prog_convert_ctx_access anyway,
> > > no alignment issues as far as I can see.
> >
> > Right, good point. Wang, could you give the below a test run:
> >
> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index 56ba0f2..95b9142 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/bpf_trace.c
> > @@ -833,8 +833,14 @@ static bool pe_prog_is_valid_access(int off, int size, enum bpf_access_type type
> > return false;
> > if (type != BPF_READ)
> > return false;
> > - if (off % size != 0)
> > - return false;
> > + if (off % size != 0) {
> > + if (sizeof(long) != 4)
> > + return false;
> > + if (size != 8)
> > + return false;
> > + if (off % size != 4)
> > + return false;
> > + }
> >
> > switch (off) {
> > case bpf_ctx_range(struct bpf_perf_event_data, sample_period):
> Hi all!
>
> I have tested this patch, but test_verifier reports the same errors
> for the five testcases.
>
> The reason is they all failed to pass the test of bpf_ctx_narrow_access_ok.
>
> Thanks.
Hi! Daniel Borkmann.
Do you have any plan to fix bpf_ctx_narrow_access_ok for these problems?
Thanks.
^ permalink raw reply
* Re: [PATCH v3 12/20] media: Remove depends on HAS_DMA in case of platform dependency
From: Geert Uytterhoeven @ 2018-05-07 7:21 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Ulf Hansson, Wolfram Sang, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-fpga-u79uwXL29TY76Z2rM5mHXA,
open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM,
ALSA Development Mailing List, Bjorn Andersson, Eric Anholt,
netdev, MTD Maling List, Linux I2C,
linux1394-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Christoph Hellwig, Stefan Wahren, Boris Brezillon, Herbert Xu,
Richard Weinberger, Jassi Brar, Marek Vasut,
open list:SERIAL DRIVERS, Matias Bjorling
In-Reply-To: <20180505094743.4d201ba0-ch4gOOMV7nf/PtFMR13I2A@public.gmane.org>
Hi Mauro,
On Sat, May 5, 2018 at 2:47 PM, Mauro Carvalho Chehab
<mchehab+samsung-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Em Tue, 17 Apr 2018 19:49:12 +0200
> Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> escreveu:
>
>> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
>> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
>
> Applying a patch like that is hard, as there are lots of churn at
> the code. That's against latest media upstream:
[...]
I can rebase. What's your preferred target? media-next?
>> In most cases this other symbol is an architecture or platform specific
>> symbol, or PCI.
>>
>> Generic symbols and drivers without platform dependencies keep their
>> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
>> cannot work anyway.
>
> Actually, depends on HAS_DMA was introduced on media because builds
> were failing otherwise. We started adding it before the addition
> of COMPILE_TEST.
Indeed. Before the 5 commits below, a missing dependency on HAS_DMA
would cause the build to fail for NO_DMA platforms.
f29ab49b5388b2f8 dma-mapping: Convert NO_DMA get_dma_ops() into a real dummy
ab642e952f80c66c dma-coherent: Add NO_DMA dummies for managed DMA API
c1ce6c2beea38171 mm: Add NO_DMA dummies for DMA pool API
bff739b6559e2fce scsi: Add NO_DMA dummies for SCSI DMA mapping API
1f674e16f9ce6eb2 usb: gadget: Add NO_DMA dummies for DMA mapping API
> Can we just remove all HAS_DMA Kconfig dependencies as a hole from the
> entire media subsystem, with something like:
>
> $ for i in $(find drivers/media -name Kconfig) $(find drivers/staging/media -name Kconfig); do sed '/depends on HAS_DMA/d;s/ && HAS_DMA//g' -i $i; done
>
> Or would it cause build issues?
It should not cause build issues, but it would enable lots of drivers that
need DMA platform support on platforms where they wouldn't work, making the
life of distro configurators harder.
That's why my series removes HAS_DMA only for symbols that have a platform
dependency.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 03/17] batman-adv: Add network_coding and mcast sysfs files to README
From: Sven Eckelmann @ 2018-05-07 6:34 UTC (permalink / raw)
To: Linus Lüssing
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
The list for a Better Approach To Mobile Ad-hoc Networking,
Jiri Pirko, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20180327154307.GA2052@otheros>
[-- Attachment #1: Type: text/plain, Size: 809 bytes --]
On Dienstag, 27. März 2018 17:43:08 CEST Linus Lüssing wrote:
> On Sat, Oct 29, 2016 at 12:56:28PM +0200, Jiri Pirko wrote:
> > >> I strongly believe it is a huge mistake to use sysfs for things like
> > >> this. This should be done via generic netlink api.
> > >
> > >This doesn't change the problem that it is already that way. This patch
> > >only adds the list of available files to the README.
> >
> > Sure. Just found out you did it like that. Therefore I commented. I
> > suggest to rework the api to use genl entirely.
>
> Hi Jiri,
>
> Thanks for sharing your thoughts!
>
> Could you explain a bit more on which disadvantages you see in
> the usage of sysfs here?
Linus is asking because of following patch:
https://patchwork.open-mesh.org/patch/17340/
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] ipv6: support sport and dport in RTM_GETROUTE
From: kbuild test robot @ 2018-05-07 6:23 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: kbuild-all, davem, netdev, dsa, nikolay, idosch
In-Reply-To: <1525654787-21990-3-git-send-email-roopa@cumulusnetworks.com>
Hi Roopa,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Roopa-Prabhu/fib-rule-selftest/20180507-094538
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
net/ipv6/route.c:2591:15: sparse: expression using sizeof(void)
net/ipv6/route.c:1391:15: sparse: expression using sizeof(void)
net/ipv6/route.c:1590:36: sparse: incorrect type in initializer (different address spaces) @@ expected struct fib6_info *from @@ got struct fib6_info struct fib6_info *from @@
net/ipv6/route.c:1590:36: expected struct fib6_info *from
net/ipv6/route.c:1590:36: got struct fib6_info [noderef] <asn:4>*from
net/ipv6/route.c:1968:39: sparse: incorrect type in assignment (different base types) @@ expected unsigned int [unsigned] [usertype] flow_label @@ got gned] [usertype] flow_label @@
net/ipv6/route.c:1968:39: expected unsigned int [unsigned] [usertype] flow_label
net/ipv6/route.c:1968:39: got restricted __be32
net/ipv6/route.c:2311:15: sparse: expression using sizeof(void)
>> net/ipv6/route.c:4735:29: sparse: incorrect type in initializer (different base types) @@ expected int [signed] p @@ got restint [signed] p @@
net/ipv6/route.c:4735:29: expected int [signed] p
net/ipv6/route.c:4735:29: got restricted __be16
>> net/ipv6/route.c:4740:15: sparse: incorrect type in assignment (different base types) @@ expected restricted __be16 [usertype] <noident> @@ got 6 [usertype] <noident> @@
net/ipv6/route.c:4740:15: expected restricted __be16 [usertype] <noident>
net/ipv6/route.c:4740:15: got int [signed] p
net/ipv6/route.c:3196:12: sparse: context imbalance in 'ip6_route_del' - wrong count at exit
vim +4735 net/ipv6/route.c
4732
4733 static int nla_get_port(struct nlattr *attr, __be16 *port)
4734 {
> 4735 int p = nla_get_be16(attr);
4736
4737 if (p <= 0 || p >= 0xffff)
4738 return -EINVAL;
4739
> 4740 *port = p;
4741 return 0;
4742 }
4743
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCHv2] net/xfrm: Revert "[XFRM]: Do not add a state whose SPI is zero to the SPI hash."
From: Steffen Klassert @ 2018-05-07 6:20 UTC (permalink / raw)
To: Dmitry Safonov
Cc: linux-kernel, 0x7f454c46, Herbert Xu, Masahide NAKAMURA,
YOSHIFUJI Hideaki, David S. Miller, netdev
In-Reply-To: <20180504012009.643-1-dima@arista.com>
On Fri, May 04, 2018 at 02:20:09AM +0100, Dmitry Safonov wrote:
> This reverts commit 7b4dc3600e48 ("[XFRM]: Do not add a state whose SPI
> is zero to the SPI hash.").
>
> Zero SPI is legal and defined for IPcomp.
> We shouldn't omit adding the state to SPI hash because it'll not be
> possible to delete or lookup for it afterward:
> __xfrm_state_insert() obviously doesn't add hash for zero
> SPI in xfrm.state_byspi, and xfrm_user_state_lookup() will fail as
> xfrm_state_lookup() does lookups by hash.
>
> It also isn't possible to workaround from userspace as
> xfrm_id_proto_match() will be always true for ah/esp/comp protos.
>
> v1 link: https://lkml.kernel.org/r/<20180502020220.2027-1-dima@arista.com>
>
> Cc: Masahide NAKAMURA <nakam@linux-ipv6.org>
> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> Cc: Steffen Klassert <steffen.klassert@secunet.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: netdev@vger.kernel.org
> Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Dmitry Safonov <dima@arista.com>
This patch does much more than reverting the commit you mentioned.
It removes all the logic that is needed to handle larval SAs.
The result is a disaster, all connections that are negotiated
by an IKE deamon stop working.
On traffic triggered connections the IKE deamon inserts a new SA
for each packet that matches a policy.
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] ipv4: support sport and dport in RTM_GETROUTE
From: kbuild test robot @ 2018-05-07 5:49 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: kbuild-all, davem, netdev, dsa, nikolay, idosch
In-Reply-To: <1525654787-21990-2-git-send-email-roopa@cumulusnetworks.com>
Hi Roopa,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Roopa-Prabhu/fib-rule-selftest/20180507-094538
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
net/ipv4/route.c:1271:31: sparse: expression using sizeof(void)
net/ipv4/route.c:1271:31: sparse: expression using sizeof(void)
net/ipv4/route.c:1274:16: sparse: expression using sizeof(void)
net/ipv4/route.c:1274:16: sparse: expression using sizeof(void)
net/ipv4/route.c:1295:15: sparse: expression using sizeof(void)
net/ipv4/route.c:688:38: sparse: expression using sizeof(void)
net/ipv4/route.c:712:38: sparse: expression using sizeof(void)
net/ipv4/route.c:782:46: sparse: incorrect type in argument 2 (different base types) @@ expected unsigned int [unsigned] [usertype] key @@ got ed int [unsigned] [usertype] key @@
net/ipv4/route.c:782:46: expected unsigned int [unsigned] [usertype] key
net/ipv4/route.c:782:46: got restricted __be32 [usertype] new_gw
>> net/ipv4/route.c:2695:29: sparse: incorrect type in initializer (different base types) @@ expected int [signed] p @@ got restint [signed] p @@
net/ipv4/route.c:2695:29: expected int [signed] p
net/ipv4/route.c:2695:29: got restricted __be16
>> net/ipv4/route.c:2700:15: sparse: incorrect type in assignment (different base types) @@ expected restricted __be16 [usertype] <noident> @@ got 6 [usertype] <noident> @@
net/ipv4/route.c:2700:15: expected restricted __be16 [usertype] <noident>
net/ipv4/route.c:2700:15: got int [signed] p
>> net/ipv4/route.c:2816:27: sparse: incorrect type in assignment (different base types) @@ expected restricted __be16 [usertype] len @@ got 6 [usertype] len @@
net/ipv4/route.c:2816:27: expected restricted __be16 [usertype] len
net/ipv4/route.c:2816:27: got unsigned long
vim +2695 net/ipv4/route.c
2692
2693 static int nla_get_port(struct nlattr *attr, __be16 *port)
2694 {
> 2695 int p = nla_get_be16(attr);
2696
2697 if (p <= 0 || p >= 0xffff)
2698 return -EINVAL;
2699
> 2700 *port = p;
2701 return 0;
2702 }
2703
2704 static int inet_rtm_getroute_reply(struct sk_buff *in_skb, struct nlmsghdr *nlh,
2705 __be32 dst, __be32 src, struct flowi4 *fl4,
2706 struct rtable *rt, struct fib_result *res)
2707 {
2708 struct net *net = sock_net(in_skb->sk);
2709 struct rtmsg *rtm = nlmsg_data(nlh);
2710 u32 table_id = RT_TABLE_MAIN;
2711 struct sk_buff *skb;
2712 int err = 0;
2713
2714 skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
2715 if (!skb) {
2716 err = -ENOMEM;
2717 return err;
2718 }
2719
2720 if (rtm->rtm_flags & RTM_F_LOOKUP_TABLE)
2721 table_id = res->table ? res->table->tb_id : 0;
2722
2723 if (rtm->rtm_flags & RTM_F_FIB_MATCH)
2724 err = fib_dump_info(skb, NETLINK_CB(in_skb).portid,
2725 nlh->nlmsg_seq, RTM_NEWROUTE, table_id,
2726 rt->rt_type, res->prefix, res->prefixlen,
2727 fl4->flowi4_tos, res->fi, 0);
2728 else
2729 err = rt_fill_info(net, dst, src, rt, table_id,
2730 fl4, skb, NETLINK_CB(in_skb).portid,
2731 nlh->nlmsg_seq);
2732 if (err < 0)
2733 goto errout;
2734
2735 return rtnl_unicast(skb, net, NETLINK_CB(in_skb).portid);
2736
2737 errout:
2738 kfree_skb(skb);
2739 return err;
2740 }
2741
2742 static int inet_rtm_getroute(struct sk_buff *in_skb, struct nlmsghdr *nlh,
2743 struct netlink_ext_ack *extack)
2744 {
2745 struct net *net = sock_net(in_skb->sk);
2746 struct nlattr *tb[RTA_MAX+1];
2747 __be16 sport = 0, dport = 0;
2748 struct fib_result res = {};
2749 struct rtable *rt = NULL;
2750 struct sk_buff *skb;
2751 struct rtmsg *rtm;
2752 struct flowi4 fl4;
2753 struct iphdr *iph;
2754 struct udphdr *udph;
2755 __be32 dst = 0;
2756 __be32 src = 0;
2757 kuid_t uid;
2758 u32 iif;
2759 int err;
2760 int mark;
2761
2762 err = nlmsg_parse(nlh, sizeof(*rtm), tb, RTA_MAX, rtm_ipv4_policy,
2763 extack);
2764 if (err < 0)
2765 return err;
2766
2767 rtm = nlmsg_data(nlh);
2768
2769 skb = alloc_skb(NLMSG_GOODSIZE, GFP_KERNEL);
2770 if (!skb) {
2771 err = -ENOBUFS;
2772 return err;
2773 }
2774
2775 /* Reserve room for dummy headers, this skb can pass
2776 through good chunk of routing engine.
2777 */
2778 skb_reset_mac_header(skb);
2779 skb_reset_network_header(skb);
2780
2781 src = tb[RTA_SRC] ? nla_get_in_addr(tb[RTA_SRC]) : 0;
2782 dst = tb[RTA_DST] ? nla_get_in_addr(tb[RTA_DST]) : 0;
2783 iif = tb[RTA_IIF] ? nla_get_u32(tb[RTA_IIF]) : 0;
2784 mark = tb[RTA_MARK] ? nla_get_u32(tb[RTA_MARK]) : 0;
2785 if (tb[RTA_UID])
2786 uid = make_kuid(current_user_ns(), nla_get_u32(tb[RTA_UID]));
2787 else
2788 uid = (iif ? INVALID_UID : current_uid());
2789 if (tb[RTA_SPORT]) {
2790 err = nla_get_port(tb[RTA_SPORT], &sport);
2791 if (err)
2792 goto errout_free;
2793 }
2794
2795 if (tb[RTA_DPORT]) {
2796 err = nla_get_port(tb[RTA_DPORT], &dport);
2797 if (err)
2798 goto errout_free;
2799 }
2800
2801 skb->protocol = htons(ETH_P_IP);
2802 iph = skb_put(skb, sizeof(struct iphdr));
2803 iph->protocol = IPPROTO_UDP;
2804 iph->saddr = src;
2805 iph->daddr = dst;
2806 iph->version = 0x4;
2807 iph->frag_off = 0;
2808
2809 if (sport || dport) {
2810 iph->ihl = 0x5;
2811 skb_set_transport_header(skb, skb->len);
2812
2813 udph = skb_put(skb, sizeof(struct udphdr));
2814 udph->dest = dport;
2815 udph->source = sport;
> 2816 udph->len = sizeof(struct udphdr);
2817 udph->check = 0;
2818 }
2819
2820 memset(&fl4, 0, sizeof(fl4));
2821 fl4.daddr = dst;
2822 fl4.saddr = src;
2823 fl4.flowi4_tos = rtm->rtm_tos;
2824 fl4.flowi4_oif = tb[RTA_OIF] ? nla_get_u32(tb[RTA_OIF]) : 0;
2825 fl4.flowi4_mark = mark;
2826 fl4.flowi4_uid = uid;
2827 if (sport)
2828 fl4.fl4_sport = sport;
2829 if (dport)
2830 fl4.fl4_dport = dport;
2831 fl4.flowi4_proto = IPPROTO_UDP;
2832
2833 rcu_read_lock();
2834
2835 if (iif) {
2836 struct net_device *dev;
2837
2838 dev = dev_get_by_index_rcu(net, iif);
2839 if (!dev) {
2840 err = -ENODEV;
2841 goto errout_rcu;
2842 }
2843
2844 fl4.flowi4_iif = iif; /* for rt_fill_info */
2845 skb->protocol = htons(ETH_P_IP);
2846 skb->dev = dev;
2847 skb->mark = mark;
2848 err = ip_route_input_rcu(skb, dst, src, rtm->rtm_tos,
2849 dev, &res);
2850
2851 rt = skb_rtable(skb);
2852 if (err == 0 && rt->dst.error)
2853 err = -rt->dst.error;
2854 } else {
2855 fl4.flowi4_iif = LOOPBACK_IFINDEX;
2856 rt = ip_route_output_key_hash_rcu(net, &fl4, &res, skb);
2857 err = 0;
2858 if (IS_ERR(rt))
2859 err = PTR_ERR(rt);
2860 else
2861 skb_dst_set(skb, &rt->dst);
2862 }
2863
2864 if (err)
2865 goto errout_rcu;
2866
2867 if (rtm->rtm_flags & RTM_F_NOTIFY)
2868 rt->rt_flags |= RTCF_NOTIFY;
2869
2870 if (rtm->rtm_flags & RTM_F_FIB_MATCH) {
2871 if (!res.fi) {
2872 err = fib_props[res.type].error;
2873 if (!err)
2874 err = -EHOSTUNREACH;
2875 goto errout_rcu;
2876 }
2877 }
2878
2879 err = inet_rtm_getroute_reply(in_skb, nlh, dst, src, &fl4, rt, &res);
2880 if (err < 0)
2881 goto errout_rcu;
2882
2883 rcu_read_unlock();
2884
2885 errout_free:
2886 kfree_skb(skb);
2887 return err;
2888 errout_rcu:
2889 rcu_read_unlock();
2890 goto errout_free;
2891 }
2892
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: linux-next: manual merge of the tip tree with the bpf-next tree
From: Stephen Rothwell @ 2018-05-07 4:10 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Daniel Borkmann, Alexei Starovoitov, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20180507120909.1fee1683@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]
Hi all,
On Mon, 7 May 2018 12:09:09 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/x86/net/bpf_jit_comp.c
>
> between commit:
>
> e782bdcf58c5 ("bpf, x64: remove ld_abs/ld_ind")
>
> from the bpf-next tree and commit:
>
> 5f26c50143f5 ("x86/bpf: Clean up non-standard comments, to make the code more readable")
>
> from the tip tree.
>
> I fixed it up (the former commit removed some code modified by the latter,
> so I just removed it) and can carry the fix as necessary. This is now
> fixed as far as linux-next is concerned, but any non trivial conflicts
> should be mentioned to your upstream maintainer when your tree is
> submitted for merging. You may also want to consider cooperating with
> the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Actually the tip tree commit has been added to the bpf-next tree as a
different commit, so dropping it from the tip tree will clean this up.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 3/3] arcnet: com20020: Add ethtool support
From: Tobin C. Harding @ 2018-05-07 3:08 UTC (permalink / raw)
To: Andrea Greco; +Cc: m.grzeschik, Andrea Greco, netdev, linux-kernel
In-Reply-To: <20180505213530.8294-1-andrea.greco.gapmilano@gmail.com>
On Sat, May 05, 2018 at 11:35:29PM +0200, Andrea Greco wrote:
> From: Andrea Greco <a.greco@4sigma.it>
>
> Setup ethtols for export com20020 diag register
>
> Signed-off-by: Andrea Greco <a.greco@4sigma.it>
> ---
> drivers/net/arcnet/com20020-isa.c | 1 +
> drivers/net/arcnet/com20020-membus.c | 1 +
> drivers/net/arcnet/com20020.c | 29 +++++++++++++++++++++++++++++
> drivers/net/arcnet/com20020.h | 1 +
> drivers/net/arcnet/com20020_cs.c | 1 +
> include/uapi/linux/if_arcnet.h | 6 ++++++
> 6 files changed, 39 insertions(+)
>
> diff --git a/drivers/net/arcnet/com20020-isa.c b/drivers/net/arcnet/com20020-isa.c
> index 38fa60ddaf2e..44ab6dcccb58 100644
> --- a/drivers/net/arcnet/com20020-isa.c
> +++ b/drivers/net/arcnet/com20020-isa.c
> @@ -154,6 +154,7 @@ static int __init com20020_init(void)
> dev->dev_addr[0] = node;
>
> dev->netdev_ops = &com20020_netdev_ops;
> + dev->ethtool_ops = &com20020_ethtool_ops;
>
> lp = netdev_priv(dev);
> lp->backplane = backplane;
> diff --git a/drivers/net/arcnet/com20020-membus.c b/drivers/net/arcnet/com20020-membus.c
> index 6e4a2f3a84f7..9eead734a3cf 100644
> --- a/drivers/net/arcnet/com20020-membus.c
> +++ b/drivers/net/arcnet/com20020-membus.c
> @@ -91,6 +91,7 @@ static int com20020_probe(struct platform_device *pdev)
>
> dev = alloc_arcdev(NULL);// Let autoassign name arc%d
> dev->netdev_ops = &com20020_netdev_ops;
> + dev->ethtool_ops = &com20020_ethtool_ops;
> lp = netdev_priv(dev);
>
> lp->card_flags = ARC_CAN_10MBIT;/* pretend all of them can 10Mbit */
> diff --git a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c
> index abd32ed8ec9b..2089b45e81c8 100644
> --- a/drivers/net/arcnet/com20020.c
> +++ b/drivers/net/arcnet/com20020.c
> @@ -201,6 +201,34 @@ const struct net_device_ops com20020_netdev_ops = {
> .ndo_set_rx_mode = com20020_set_mc_list,
> };
>
> +static int com20020_ethtool_regs_len(struct net_device *netdev)
> +{
> + return sizeof(struct com20020_ethtool_regs);
> +}
> +
> +static void com20020_ethtool_regs_read(struct net_device *dev,
> + struct ethtool_regs *regs, void *p)
> +{
> + struct arcnet_local *lp;
> + struct com20020_ethtool_regs *com_reg;
> +
> + lp = netdev_priv(dev);
> + memset(p, 0, sizeof(struct com20020_ethtool_regs));
perhaps:
struct arcnet_local *lp = netdev_priv(dev);
struct com20020_ethtool_regs *com_reg = p;
memset(com_reg, 0, sizeof(*com_reg));
> +
> + regs->version = 1;
Should this function really have a side effect? If so, perhaps it could
be commented.
> +
> + com_reg = p;
> +
> + com_reg->status = lp->hw.status(dev) & 0xFF;
> + com_reg->diag_register = (lp->hw.status(dev) >> 8) & 0xFF;
> + com_reg->reconf_count = lp->num_recons;
> +}
> +
> +const struct ethtool_ops com20020_ethtool_ops = {
> + .get_regs = com20020_ethtool_regs_read,
> + .get_regs_len = com20020_ethtool_regs_len,
> +};
> +
Hope this helps,
Tobin.
^ permalink raw reply
* Re: [RFC PATCH 2/3] arcnet: com20020: Fixup missing SLOWARB bit
From: Tobin C. Harding @ 2018-05-07 2:55 UTC (permalink / raw)
To: Andrea Greco; +Cc: m.grzeschik, Andrea Greco, netdev, linux-kernel
In-Reply-To: <20180505213754.8400-1-andrea.greco.gapmilano@gmail.com>
On Sat, May 05, 2018 at 11:37:54PM +0200, Andrea Greco wrote:
> From: Andrea Greco <a.greco@4sigma.it>
>
> If com20020 clock is major of 40Mhz SLOWARB bit is requested.
>
> Signed-off-by: Andrea Greco <a.greco@4sigma.it>
> ---
> drivers/net/arcnet/com20020.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c
> index f09ea77dd6a8..abd32ed8ec9b 100644
> --- a/drivers/net/arcnet/com20020.c
> +++ b/drivers/net/arcnet/com20020.c
> @@ -102,6 +102,10 @@ int com20020_check(struct net_device *dev)
> lp->setup = lp->clockm ? 0 : (lp->clockp << 1);
> lp->setup2 = (lp->clockm << 4) | 8;
>
> + // If clock is major of 40Mhz, SLOWARB bit must be set
/* C89 style comments please :) */
Hope this helps,
Tobin.
^ permalink raw reply
* Re: [RFC PATCH 1/3] arcnet: com20020: Add memory map of com20020
From: Tobin C. Harding @ 2018-05-07 2:55 UTC (permalink / raw)
To: Andrea Greco
Cc: m.grzeschik, Andrea Greco, Rob Herring, Mark Rutland, netdev,
devicetree, linux-kernel
In-Reply-To: <20180505213448.8180-1-andrea.greco.gapmilano@gmail.com>
On Sat, May 05, 2018 at 11:34:45PM +0200, Andrea Greco wrote:
> From: Andrea Greco <a.greco@4sigma.it>
Hi Andrea,
Here are some (mostly stylistic) suggestions to help you get your driver merged.
> Add support for com20022I/com20020, memory mapped chip version.
> Support bus: Intel 80xx and Motorola 68xx.
> Bus size: Only 8 bit bus size is supported.
> Added related device tree bindings
>
> Signed-off-by: Andrea Greco <a.greco@4sigma.it>
> ---
> .../devicetree/bindings/net/smsc-com20020.txt | 23 +++
> drivers/net/arcnet/Kconfig | 12 +-
> drivers/net/arcnet/Makefile | 1 +
> drivers/net/arcnet/arcdevice.h | 27 ++-
> drivers/net/arcnet/com20020-membus.c | 191 +++++++++++++++++++++
> drivers/net/arcnet/com20020.c | 9 +-
> 6 files changed, 253 insertions(+), 10 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/smsc-com20020.txt
> create mode 100644 drivers/net/arcnet/com20020-membus.c
>
> diff --git a/Documentation/devicetree/bindings/net/smsc-com20020.txt b/Documentation/devicetree/bindings/net/smsc-com20020.txt
> new file mode 100644
> index 000000000000..39c5b19c55af
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/smsc-com20020.txt
> @@ -0,0 +1,23 @@
> +SMSC com20020, com20022I
> +
> +timeout: Arcnet timeout, checkout datashet
> +clockp: Clock Prescaler, checkout datashet
> +clockm: Clock multiplier, checkout datasheet
> +
> +phy-reset-gpios: Chip reset ppin
> +phy-irq-gpios: Chip irq pin
> +
> +com20020_A@0 {
> + compatible = "smsc,com20020";
> +
> + timeout = <0x3>;
> + backplane = <0x0>;
> +
> + clockp = <0x0>;
> + clockm = <0x3>;
> +
> + phy-reset-gpios = <&gpio3 21 GPIO_ACTIVE_LOW>;
> + phy-irq-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
> +
> + status = "okay";
> +};
> diff --git a/drivers/net/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
> index 39bd16f3f86d..d39faf45be1e 100644
> --- a/drivers/net/arcnet/Kconfig
> +++ b/drivers/net/arcnet/Kconfig
> @@ -3,7 +3,7 @@
> #
>
> menuconfig ARCNET
> - depends on NETDEVICES && (ISA || PCI || PCMCIA)
> + depends on NETDEVICES
> tristate "ARCnet support"
> ---help---
> If you have a network card of this type, say Y and check out the
> @@ -129,5 +129,15 @@ config ARCNET_COM20020_CS
>
> To compile this driver as a module, choose M here: the module will be
> called com20020_cs. If unsure, say N.
> +config ARCNET_COM20020_MEMORY_BUS
> + bool "Support for COM20020 on external memory"
> + depends on ARCNET_COM20020 && !(ARCNET_COM20020_PCI || ARCNET_COM20020_ISA || ARCNET_COM20020_CS)
> + help
> + Say Y here if on your custom board mount com20020 or friends.
> +
> + Com20022I support arcnet bus 10Mbitps.
> + This driver support only 8bit
This driver only supports 8bit bus size.
> , and DMA is not supported is attached on your board at external interface bus.
This bit does not make sense, sorry.
> + Supported bus Intel80xx / Motorola 68xx.
> + This driver not work with other com20020 module: PCI or PCMCIA compiled as [M].
I'm not sure exactly what you want to say here, perhaps:
This driver does not work with other com20020 modules compiled
as PCI or PCMCIA [M].
>
> endif # ARCNET
> diff --git a/drivers/net/arcnet/Makefile b/drivers/net/arcnet/Makefile
> index 53525e8ea130..19425c1e06f4 100644
> --- a/drivers/net/arcnet/Makefile
> +++ b/drivers/net/arcnet/Makefile
> @@ -14,3 +14,4 @@ obj-$(CONFIG_ARCNET_COM20020) += com20020.o
> obj-$(CONFIG_ARCNET_COM20020_ISA) += com20020-isa.o
> obj-$(CONFIG_ARCNET_COM20020_PCI) += com20020-pci.o
> obj-$(CONFIG_ARCNET_COM20020_CS) += com20020_cs.o
> +obj-$(CONFIG_ARCNET_COM20020_MEMORY_BUS) += com20020-membus.o
> diff --git a/drivers/net/arcnet/arcdevice.h b/drivers/net/arcnet/arcdevice.h
> index d09b2b46ab63..16c608269cca 100644
> --- a/drivers/net/arcnet/arcdevice.h
> +++ b/drivers/net/arcnet/arcdevice.h
> @@ -201,7 +201,7 @@ struct ArcProto {
> void (*rx)(struct net_device *dev, int bufnum,
> struct archdr *pkthdr, int length);
> int (*build_header)(struct sk_buff *skb, struct net_device *dev,
> - unsigned short ethproto, uint8_t daddr);
> + unsigned short ethproto, uint8_t daddr);
+ unsigned short ethproto, uint8_t daddr);
Please use Linux coding style style, parameters continuing on separate
line are aligned with opening parenthesis.
> /* these functions return '1' if the skb can now be freed */
> int (*prepare_tx)(struct net_device *dev, struct archdr *pkt,
> @@ -326,9 +326,9 @@ struct arcnet_local {
> void (*recontrigger) (struct net_device * dev, int enable);
>
> void (*copy_to_card)(struct net_device *dev, int bufnum,
> - int offset, void *buf, int count);
> + int offset, void *buf, int count);
> void (*copy_from_card)(struct net_device *dev, int bufnum,
> - int offset, void *buf, int count);
> + int offset, void *buf, int count);
> } hw;
>
> void __iomem *mem_start; /* pointer to ioremap'ed MMIO */
> @@ -360,7 +360,7 @@ struct net_device *alloc_arcdev(const char *name);
> int arcnet_open(struct net_device *dev);
> int arcnet_close(struct net_device *dev);
> netdev_tx_t arcnet_send_packet(struct sk_buff *skb,
> - struct net_device *dev);
> + struct net_device *dev);
> void arcnet_timeout(struct net_device *dev);
>
> /* I/O equivalents */
> @@ -371,7 +371,23 @@ void arcnet_timeout(struct net_device *dev);
> #define BUS_ALIGN 1
> #endif
>
> -/* addr and offset allow register like names to define the actual IO address.
> +#ifdef CONFIG_ARCNET_COM20020_MEMORY_BUS
> +#define arcnet_inb(addr, offset) \
> + ioread8((void __iomem *)(addr) + BUS_ALIGN * (offset))
> +
> +#define arcnet_outb(value, addr, offset) \
> + iowrite8(value, (void __iomem *)(addr) + BUS_ALIGN * (offset))
> +
> +#define arcnet_insb(addr, offset, buffer, count) \
> + ioread8_rep((void __iomem *) \
> + (addr) + BUS_ALIGN * (offset), buffer, count)
> +
> +#define arcnet_outsb(addr, offset, buffer, count) \
> + iowrite8_rep((void __iomem *) \
> + (addr) + BUS_ALIGN * (offset), buffer, count)
> +#else
> +/**
> + * addr and offset allow register like names to define the actual IO address.
> * A configuration option multiplies the offset for alignment.
> */
> #define arcnet_inb(addr, offset) \
> @@ -388,6 +404,7 @@ void arcnet_timeout(struct net_device *dev);
> readb((addr) + (offset))
> #define arcnet_writeb(value, addr, offset) \
> writeb(value, (addr) + (offset))
> +#endif
>
> #endif /* __KERNEL__ */
> #endif /* _LINUX_ARCDEVICE_H */
> diff --git a/drivers/net/arcnet/com20020-membus.c b/drivers/net/arcnet/com20020-membus.c
> new file mode 100644
> index 000000000000..6e4a2f3a84f7
> --- /dev/null
> +++ b/drivers/net/arcnet/com20020-membus.c
> @@ -0,0 +1,191 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/* Linux ARCnet driver for com 20020.
> + *
> + * This datasheet:
> + * http://ww1.microchip.com/downloads/en/DeviceDoc/200223vrevc.pdf
> + * http://ww1.microchip.com/downloads/en/DeviceDoc/20020.pdf
> + *
> + * This driver support:
* This driver supports:
> + * - com20020,
> + * - com20022
> + * - com20022I-3v3
> + *
> + * This driver support only, 8bit read and write.
* This driver supports only 8bit read and write.
> + * DMA is not supported by this driver.
> + */
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/device.h>
> +#include <linux/kernel.h>
> +#include <linux/errno.h>
> +#include <linux/platform_device.h>
> +#include <linux/netdevice.h>
> +#include <linux/of_address.h>
> +#include <linux/of_gpio.h>
> +#include <linux/sizes.h>
> +#include <linux/interrupt.h>
> +#include <linux/ioport.h>
> +#include <linux/random.h>
> +
> +#include <linux/delay.h>
> +#include "arcdevice.h"
> +#include "com20020.h"
White space line is not needed here, you might have meant to have it one
line down?
> +
> +#define VERSION "arcnet: COM20020 MEMORY BUS support loaded.\n"
> +
> +static int com20020_probe(struct platform_device *pdev)
> +{
> + struct device_node *np;
> + struct net_device *dev;
> + struct arcnet_local *lp;
> + struct resource res, *iores;
> + int ret, phy_reset, err;
> + u32 timeout, backplane, clockp, clockm;
> + void __iomem *ioaddr;
> +
> + np = pdev->dev.of_node;
> +
> + iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +
> + if (of_address_to_resource(np, 0, &res))
> + return -EINVAL;
> +
> + ret = of_property_read_u32(np, "timeout", &timeout);
> + if (ret) {
> + dev_err(&pdev->dev, "timeout is required param");
> + return ret;
> + }
> +
> + ret = of_property_read_u32(np, "backplane", &backplane);
> + if (ret) {
> + dev_err(&pdev->dev, "backplane is required param");
> + return ret;
> + }
> +
> + ret = of_property_read_u32(np, "clockp", &clockp);
> + if (ret) {
> + dev_err(&pdev->dev, "clockp is required param");
> + return ret;
> + }
> +
> + ret = of_property_read_u32(np, "clockm", &clockm);
> + if (ret) {
> + dev_err(&pdev->dev, "clockm is required param");
> + return ret;
> + }
> +
> + phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
> + if (phy_reset == -EPROBE_DEFER) {
> + return phy_reset;
> + } else if (!gpio_is_valid(phy_reset)) {
> + dev_err(&pdev->dev, "phy-reset-gpios not valid !");
> + return 0;
> + }
> +
> + err = devm_gpio_request_one(&pdev->dev, phy_reset, GPIOF_OUT_INIT_LOW,
> + "arcnet-phy-reset");
> + if (err) {
> + dev_err(&pdev->dev, "failed to get phy-reset-gpios: %d\n", err);
> + return err;
> + }
> +
> + dev = alloc_arcdev(NULL);// Let autoassign name arc%d
/* C89 style comments please */
> + dev->netdev_ops = &com20020_netdev_ops;
> + lp = netdev_priv(dev);
> +
> + lp->card_flags = ARC_CAN_10MBIT;/* pretend all of them can 10Mbit */
> +
> + // Force address to 0
Unnecessary, we can see this in the code :) Please don't comment 'what'
the code does (unless it is obfuscated or difficult to read). You may
still like to comment 'why' the code does what it does though.
> + // Will be set by user with `ip set dev arc0 address YOUR_NODE_ID`
> + dev->dev_addr[0] = 0;
> +
> + // request to system this memory region
Same as above
> + if (!devm_request_mem_region(&pdev->dev, res.start, resource_size(&res),
> + lp->card_name))
> + return -EBUSY;
> +
> + ioaddr = devm_ioremap(&pdev->dev, iores->start, resource_size(iores));
> + if (!ioaddr) {
> + dev_err(&pdev->dev, "ioremap fallied\n");
> + return -ENOMEM;
> + }
> +
> + // Reset time is 5 * xTalFreq, minimal xtal is 10Mhz
> + // (5 * 1000) / 10Mhz = 500ns
perhaps a macro definition
#define MAX_XTAL_RESET_TIME ??
> +
> + gpio_set_value_cansleep(phy_reset, 0);
> + ndelay(500);
> + gpio_set_value_cansleep(phy_reset, 1);
> + ndelay(500);
> +
> + /* Dummy access after Reset
> + * ARCNET controller needs
> + * this access to detect bustype
> + */
nit: Upto 72 characters wide is fine for comments
/* Dummy access after Reset ARCNET controller needs
* this access to detect bustype
*/
> + arcnet_outb(0x00, ioaddr, COM20020_REG_W_COMMAND);
> + arcnet_inb(ioaddr, COM20020_REG_R_DIAGSTAT);
> +
> + dev->base_addr = (unsigned long)ioaddr;
> + get_random_bytes(dev->dev_addr, sizeof(u8));
> +
> + dev->irq = of_get_named_gpio(np, "phy-irq-gpios", 0);
> + if (dev->irq == -EPROBE_DEFER) {
> + return dev->irq;
> + } else if (!gpio_is_valid(dev->irq)) {
> + dev_err(&pdev->dev, "phy-irq-gpios not valid !");
> + return 0;
> + }
> + dev->irq = gpio_to_irq(dev->irq);
> +
> + lp->backplane = backplane;
> + lp->clockp = clockp & 7;
> + lp->clockm = clockm & 3;
> + lp->timeout = timeout;
> + lp->hw.owner = THIS_MODULE;
> +
> + if (arcnet_inb(ioaddr, COM20020_REG_R_STATUS) == 0xFF) {
> + ret = -EIO;
> + goto err_release_mem;
> + }
> +
> + if (com20020_check(dev)) {
> + ret = -EIO;
> + goto err_release_mem;
> + }
> +
> + ret = com20020_found(dev, IRQF_TRIGGER_FALLING);
> + if (ret)
> + goto err_release_mem;
> +
> + dev_dbg(&pdev->dev, "probe Done\n");
> + return 0;
> +
> +err_release_mem:
> + devm_iounmap(&pdev->dev, (void __iomem *)ioaddr);
> + devm_release_mem_region(&pdev->dev, res.start, resource_size(&res));
> + dev_err(&pdev->dev, "probe failed!\n");
> + return ret;
> +}
> +
> +static const struct of_device_id of_com20020_match[] = {
> + { .compatible = "smsc,com20020", },
> + { },
> +};
> +
> +MODULE_DEVICE_TABLE(of, of_com20020_match);
> +
> +static struct platform_driver of_com20020_driver = {
> + .driver = {
> + .name = "com20020-memory-bus",
> + .of_match_table = of_com20020_match,
> + },
> + .probe = com20020_probe,
> +};
> +
> +static int com20020_init(void)
> +{
> + return platform_driver_register(&of_com20020_driver);
> +}
> +late_initcall(com20020_init);
> +
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c
> index 78043a9c5981..f09ea77dd6a8 100644
> --- a/drivers/net/arcnet/com20020.c
> +++ b/drivers/net/arcnet/com20020.c
> @@ -43,7 +43,7 @@
> #include "com20020.h"
>
> static const char * const clockrates[] = {
> - "XXXXXXX", "XXXXXXXX", "XXXXXX", "2.5 Mb/s",
> + "10 Mb/s", "XXXXXXXX", "XXXXXX", "2.5 Mb/s",
> "1.25Mb/s", "625 Kb/s", "312.5 Kb/s", "156.25 Kb/s",
> "Reserved", "Reserved", "Reserved"
> };
> @@ -391,9 +391,10 @@ static void com20020_set_mc_list(struct net_device *dev)
> }
> }
>
> -#if defined(CONFIG_ARCNET_COM20020_PCI_MODULE) || \
> - defined(CONFIG_ARCNET_COM20020_ISA_MODULE) || \
> - defined(CONFIG_ARCNET_COM20020_CS_MODULE)
> +#if defined(CONFIG_ARCNET_COM20020_PCI_MODULE) || \
> + defined(CONFIG_ARCNET_COM20020_ISA_MODULE) || \
> + defined(CONFIG_ARCNET_COM20020_CS_MODULE) || \
> + defined(CONFIG_ARCNET_COM20020_MEMORY_BUS)
Why the whitespace change?
Hope this helps,
Tobin.
^ permalink raw reply
* [PATCH net] net/tls: Fix connection stall on partial tls record
From: Andre Tomt @ 2018-05-07 2:24 UTC (permalink / raw)
To: David S . Miller, netdev, borisp, Aviad Yehezkel, Dave Watson; +Cc: Andre Tomt
In the case of writing a partial tls record we forgot to clear the
ctx->in_tcp_sendpages flag, causing some connections to stall.
Fixes: c212d2c7fc47 ("net/tls: Don't recursively call push_record during tls_write_space callbacks")
Signed-off-by: Andre Tomt <andre@tomt.net>
---
net/tls/tls_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index cc03e00785c7..a02ebdfa0675 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -135,6 +135,7 @@ int tls_push_sg(struct sock *sk,
offset -= sg->offset;
ctx->partially_sent_offset = offset;
ctx->partially_sent_record = (void *)sg;
+ ctx->in_tcp_sendpages = false;
return ret;
}
--
2.17.0
^ permalink raw reply related
* linux-next: manual merge of the tip tree with the bpf-next tree
From: Stephen Rothwell @ 2018-05-07 2:09 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Daniel Borkmann, Alexei Starovoitov, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 814 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/net/bpf_jit_comp.c
between commit:
e782bdcf58c5 ("bpf, x64: remove ld_abs/ld_ind")
from the bpf-next tree and commit:
5f26c50143f5 ("x86/bpf: Clean up non-standard comments, to make the code more readable")
from the tip tree.
I fixed it up (the former commit removed some code modified by the latter,
so I just removed it) and can carry the fix as necessary. This is now
fixed as far as linux-next is concerned, but any non trivial conflicts
should be mentioned to your upstream maintainer when your tree is
submitted for merging. You may also want to consider cooperating with
the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ 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