On 06/13/2018 05:56 PM, Martin KaFai Lau wrote:
> On Wed, Jun 13, 2018 at 10:50:14AM -0700, John Fastabend wrote:
>> After adding checks to ensure TCP is in ESTABLISHED state when a
>> sock is added we need to also ensure that user does not transition
>> through tcp_disconnect() and back into ESTAB
any reason to put output-mark on its own line? Why not
mark 0x1/0x3 output-mark 0x2
Hi David
I will move it to the same line in v3.
is the documentation clear on the difference between mark and
output-mark?
Lorenzo has described the differences in detail in the kernel c
On Wed, Jun 13, 2018 at 8:40 PM, Toshiaki Makita
wrote:
> On 2018/06/14 11:56, Y Song wrote:
> ...
>>> @@ -586,6 +589,15 @@ int dev_map_enqueue(struct bpf_dtab_netdev *dst,
>>> struct xdp_buff *xdp,
>>> return 0;
>>> }
>>>
>>> +struct sk_buff;
>>> +
>>> +static inline int dev_map_generic
This feature is actually already supported by sk->sk_reuse which can be
set by socket level opt SO_REUSEADDR. But it's not working exactly as
RFC6458 demands in section 8.1.27, like:
- This option only supports one-to-one style SCTP sockets
- This socket option must not be used after calling b
On 2018/06/14 11:56, Y Song wrote:
...
>> @@ -586,6 +589,15 @@ int dev_map_enqueue(struct bpf_dtab_netdev *dst, struct
>> xdp_buff *xdp,
>> return 0;
>> }
>>
>> +struct sk_buff;
>> +
>> +static inline int dev_map_generic_redirect(struct bpf_dtab_netdev *dst,
>> +
On 6/12/18 9:14 PM, Lorenzo Colitti wrote:
> On Wed, Jun 13, 2018 at 3:48 AM Subash Abhinov Kasiviswanathan
> wrote:
>>
>> src 192.168.1.1 dst 192.168.1.2
>> proto esp spi 0x4321 reqid 0 mode tunnel
>> replay-window 0 flag af-unspec
>> mark 0x1/0x3
>> ou
On Wed, Jun 13, 2018 at 7:07 PM, Toshiaki Makita
wrote:
> Commit 67f29e07e131 ("bpf: devmap introduce dev_map_enqueue") changed
> the return value type of __devmap_lookup_elem() from struct net_device *
> to struct bpf_dtab_netdev * but forgot to modify generic XDP code
> accordingly.
> Thus gener
On 06/13/2018 05:53 PM, Saeed Mahameed wrote:
> When a new rx packet arrives, the rx path will decide whether to reuse
> the same page or not according to the current rx frag page offset and
> frag size, i.e:
> release = frags->page_offset + frag_info->frag_size > PAGE_SIZE;
>
> Martin debugged
Commit 67f29e07e131 ("bpf: devmap introduce dev_map_enqueue") changed
the return value type of __devmap_lookup_elem() from struct net_device *
to struct bpf_dtab_netdev * but forgot to modify generic XDP code
accordingly.
Thus generic XDP incorrectly used struct bpf_dtab_netdev where struct
net_dev
From: Neil Horman
Date: Wed, 13 Jun 2018 20:46:43 -0400
> Do you have any performance numbers to compare with and without this
> patch? Adding a function like this implies that any fixes that go
> into skb_gro_receive now need to be evaluated for this function too,
> which means theres an implie
> Hi Andrey
>
> This commit was reverted, do we still need this patch ?
I think it still makes things easier to understand...
On Thu, Jun 14, 2018 at 8:46 AM, Neil Horman wrote:
> On Thu, Jun 14, 2018 at 07:37:02AM +0800, Xin Long wrote:
>> Now sctp GSO uses skb_gro_receive() to append the data into head
>> skb frag_list. However it actually only needs very few code from
>> skb_gro_receive(). Besides, NAPI_GRO_CB has to
> #define SK_NO_REUSE0
> #define SK_CAN_REUSE 1
since it's a boolean now these should go away too I believe.
should there simply/also be a separate privileged socket option to
set/get force reuse?
The commit f396922d862a added a check to not allow changing
SO_REUSEADDR/SO_REUSEPORT on bound sockets. First, it doesn't
take into account that TCP_REPAIR changes SO_REUSEADDR. Second, now it
is impossible to restore a socket state and set SO_REUSEADDR,
because the kernel always sets SO_REUSEADDR
On Wed, Jun 13, 2018 at 10:50:14AM -0700, John Fastabend wrote:
> After adding checks to ensure TCP is in ESTABLISHED state when a
> sock is added we need to also ensure that user does not transition
> through tcp_disconnect() and back into ESTABLISHED state without
> sockmap removing the sock.
>
When a new rx packet arrives, the rx path will decide whether to reuse
the same page or not according to the current rx frag page offset and
frag size, i.e:
release = frags->page_offset + frag_info->frag_size > PAGE_SIZE;
Martin debugged this and he showed that this can cause mlx4 XDP to reuse
buf
On Thu, Jun 14, 2018 at 07:37:02AM +0800, Xin Long wrote:
> Now sctp GSO uses skb_gro_receive() to append the data into head
> skb frag_list. However it actually only needs very few code from
> skb_gro_receive(). Besides, NAPI_GRO_CB has to be set while most
> of its members are not needed here.
>
On 2018/06/13 18:27, kbuild test robot wrote:
> Hi Toshiaki,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on bpf/master]
>
> url:
> https://github.com/0day-ci/linux/commits/Toshiaki-Makita/xdp-Fix-handling-of-devmap-in-gen
On 2018/06/13 18:06, Daniel Borkmann wrote:
> On 06/13/2018 10:08 AM, Toshiaki Makita wrote:
>> i40e_build_skb() reserves I40E_SKB_PAD + (xdp->data -
>> xdp->data_hard_start) but obviously I40E_SKB_PAD is unnecessary here
>> and mac_header/data feilds in skb becomes incorrect, and breaks normal
>>
On Thu, Jun 14, 2018 at 07:37:02AM +0800, Xin Long wrote:
> Now sctp GSO uses skb_gro_receive() to append the data into head
> skb frag_list. However it actually only needs very few code from
> skb_gro_receive(). Besides, NAPI_GRO_CB has to be set while most
> of its members are not needed here.
>
Now sctp GSO uses skb_gro_receive() to append the data into head
skb frag_list. However it actually only needs very few code from
skb_gro_receive(). Besides, NAPI_GRO_CB has to be set while most
of its members are not needed here.
This patch is to add sctp_packet_gso_append() to build GSO frames
i
On Tue, Jun 12, 2018 at 05:41:26PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jun 12, 2018 at 05:31:24PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Thu, Jun 07, 2018 at 01:07:01PM -0700, Martin KaFai Lau escreveu:
> > > On Thu, Jun 07, 2018 at 04:30:29PM -0300, Arnaldo Carvalho de Melo
John Linville asked me to ship the ethtool.8 patch to this list.
That's the first 0001 patch in the enclosures and should be applied
to the ethtool repo.
The others are more syntax fixups for the iproute2 repo. Some
are things like list syntax errors that you don't notice when
rendering via groff
Hi,
The stmmac ethernet has stopped working in linux-next and linus/master
branch(v4.17-11782-gbe779f03d563)
It appears that the stmmac ethernet has stopped working after these 2 commits:
4dbbe8dde848 net: stmmac: Add support for U32 TC filter using Flexible RX Parser
5f0456b43140 net: stmmac: I
On Fri, Jun 08, 2018 at 11:20:05AM +0200, Ivan Vecera wrote:
> Fixes: b0fe96d ("Ethtool: Implements
> ETHTOOL_PHY_GTUNABLE/ETHTOOL_PHY_STUNABLE and PHY downshift")
> Signed-off-by: Ivan Vecera
LGTM -- I have queued the series for the next release, including
extending the commit IDs...
Thanks!
On 06/12/2018 05:31 PM, Daniel Borkmann wrote:
> On 06/11/2018 08:47 PM, John Fastabend wrote:
>> In selftest test_maps the sockmap test case attempts to add a socket
>> in listening state to the sockmap. This is no longer a valid operation
>> so it fails as expected. However, the test wrongly repo
In selftest test_maps the sockmap test case attempts to add a socket
in listening state to the sockmap. This is no longer a valid operation
so it fails as expected. However, the test wrongly reports this as an
error now. Fix the test to avoid adding sockets in listening state.
Signed-off-by: John
This fixes a crash where we assign tcp_prot to IPv6 sockets instead
of tcpv6_prot.
Previously we overwrote the sk->prot field with tcp_prot even in the
AF_INET6 case. This patch ensures the correct tcp_prot and tcpv6_prot
are used. Further, only allow ESTABLISHED connections to join the
map per no
Add map_release_uref pointer to hashmap ops. This was dropped when
original sockhash code was ported into bpf-next before initial
commit.
Fixes: 81110384441a ("bpf: sockmap, add hash map support")
Signed-off-by: John Fastabend
---
kernel/bpf/sockmap.c |1 +
1 file changed, 1 insertion(+)
di
First in tcp_close, reduce scope of sk_callback_lock() the lock is
only needed for protecting smap_release_sock() the ingress and cork
lists are protected by sock lock. Having the lock in wider scope is
harmless but may confuse the reader who may infer it is in fact
needed.
Next, in sock_hash_dele
After adding checks to ensure TCP is in ESTABLISHED state when a
sock is added we need to also ensure that user does not transition
through tcp_disconnect() and back into ESTABLISHED state without
sockmap removing the sock.
To do this add unhash hook and remove sock from map there.
Reported-by: E
This addresses two syzbot issues that lead to identifing (by Eric and
Wei) a class of bugs where we don't correctly check for IPv4/v6
sockets and their associated state. The second issue was a locking
error in sockhash.
The first 2 patches address handling IPv4 correctly and then ensuring
that onl
Per the note in the TLS ULP (which is actually a generic statement
regarding ULPs)
/* The TLS ulp is currently supported only for TCP sockets
* in ESTABLISHED state.
* Supporting sockets in LISTEN state will require us
* to modify the accept implementation to clone rather then
* share the
On Wed, Jun 13, 2018 at 9:26 AM, John Fastabend
wrote:
> On 06/13/2018 02:04 AM, Daniel Borkmann wrote:
>> Using skb_reserve(skb, I40E_SKB_PAD + (xdp->data - xdp->data_hard_start))
>> is clearly wrong since I40E_SKB_PAD already points to the offset where
>> the original xdp->data was sitting since
On Wed, Jun 13, 2018 at 5:03 AM, Wang Jian wrote:
> Grep tunnel type directly to make sure 'ip' command supports it.
>
> Signed-off-by: Jian Wang
Acked-by: Yonghong Song
On 06/13/2018 06:35 AM, Tejaswi Tanikella wrote:
> On Tue, Jun 12, 2018 at 06:30:32PM +0200, Andrew Lunn wrote:
>> On Mon, Jun 11, 2018 at 05:22:28PM +0530, Tejaswi Tanikella wrote:
>>> Signed-off-by: Tejaswi Tanikella
>>> ---
>>> include/linux/ktime.h | 4
>>> 1 file changed, 4 insertions(+
On 06/13/2018 02:04 AM, Daniel Borkmann wrote:
> Using skb_reserve(skb, I40E_SKB_PAD + (xdp->data - xdp->data_hard_start))
> is clearly wrong since I40E_SKB_PAD already points to the offset where
> the original xdp->data was sitting since xdp->data_hard_start is defined
> as xdp->data - i40e_rx_off
2018-06-13 2:22 GMT+02:00 Stephen Hemminger :
> On Tue, 12 Jun 2018 16:12:57 +0200
> Daniele Palmas wrote:
>
>> This patch adds basic support for Qualcomm rmnet devices.
>>
>> Signed-off-by: Daniele Palmas
>> ---
>> ip/Makefile | 2 +-
>> ip/iplink.c | 2 +-
>> ip/iplink_rmnet.c |
2018-06-13 1:06 GMT+02:00 Subash Abhinov Kasiviswanathan
:
>> +
>> +static void print_explain(FILE *f)
>> +{
>> + fprintf(f,
>> + "Usage: ... rmnet mux_id MUXID\n"
>> + "\n"
>> + "MUXID := 1-127\n"
>> + );
>> +}
>
>
> Hi Daniele
>
> This range c
> I'll try to explain my scenario. This was observed on a arm64 device.
> An application registers for a mcast group, and just listens to mcast
> packets. The connection is setup and mcast packets are being forwarded
> by the router. Multicast packets are sent out every few minutes.
> Not a very bu
Hi,
On Wed, Jun 13, 2018 at 2:40 PM, Florian Westphal wrote:
> Can you test attached patch?
>
> I'd like to see how much the pcpu cache helps or if it actually hurts
> in your setup.
>
> Subject: [TEST PATCH 4.14.y] xfrm: remove pcpu policy cache
>
> We need to re-evaluate if this still buys anyt
On Tue, Jun 12, 2018 at 06:30:32PM +0200, Andrew Lunn wrote:
> On Mon, Jun 11, 2018 at 05:22:28PM +0530, Tejaswi Tanikella wrote:
> > Signed-off-by: Tejaswi Tanikella
> > ---
> > include/linux/ktime.h | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/include/linux/ktime.h b/incl
On Tue, Jun 12, 2018 at 06:28:18PM +0200, Andrew Lunn wrote:
> On Mon, Jun 11, 2018 at 05:21:05PM +0530, Tejaswi Tanikella wrote:
> > On receiving a IGMPv2/v3 query, based on max_delay set in the header a
> > timer is started to send out a response after a random time within
> > max_delay. If the s
On Wed, Jun 13, 2018 at 11:04:36AM +0200, Daniel Borkmann wrote:
> Using skb_reserve(skb, I40E_SKB_PAD + (xdp->data - xdp->data_hard_start))
> is clearly wrong since I40E_SKB_PAD already points to the offset where
> the original xdp->data was sitting since xdp->data_hard_start is defined
> as xdp->
Define cfg.pw_type so that the new session is created with its .pwtype
field properly set (L2TP_PWTYPE_PPP).
Not setting the pseudo-wire type had several annoying effects:
* Invalid value returned in the L2TP_ATTR_PW_TYPE attribute when
dumping sessions with the netlink API.
* Impossibil
If 'fd' is negative, l2tp_tunnel_create() creates a tunnel socket using
the configuration passed in 'tcfg'. Currently, pppol2tp_connect() sets
the relevant fields to zero, tricking l2tp_tunnel_create() into setting
up an unusable kernel socket.
We can't set 'tcfg' with the required fields because
This series fixes a few remaining issues with pppol2tp_connect().
It doesn't try to prevent invalid configurations that have no effect on
kernel's reliability. That would be work for a future patch set.
Patch 2 is the most important as it avoids an invalid pointer
dereference crashing the kernel.
l2tp_session_priv() returns a struct pppol2tp_session pointer only for
PPPoL2TP sessions. In particular, if the session is an L2TP_PWTYPE_ETH
pseudo-wire, l2tp_session_priv() returns a pointer to an l2tp_eth_sess
structure, which is much smaller than struct pppol2tp_session. This
leads to invalid m
pppol2tp_connect() may create a tunnel or a session. Remove them in
case of error.
Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp
parts")
Signed-off-by: Guillaume Nault
---
net/l2tp/l2tp_ppp.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/net/l2tp/
Kristian Evensen wrote:
> Hello,
>
> On Tue, Jul 18, 2017 at 8:15 PM, David Miller wrote:
> > Steffen, I know you have some level of trepidation about this because
> > there is obviously some performance cost immediately for removing this
> > DoS problem.
>
> In a project I am involved in, we a
Grep tunnel type directly to make sure 'ip' command supports it.
Signed-off-by: Jian Wang
---
tools/testing/selftests/bpf/test_tunnel.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/test_tunnel.sh
b/tools/testing/selftests/bpf/test_tunnel.sh
ind
Dear Friend,
Mr. john Matthias ouedraogo, the manager in charge of auditing and accounting
section
of Bank of Africa (BOA) Ouagadougou Burkina-Faso West-Africa. I would like you
to indicate your interest to receive the transfer of $19.3 Million Dollars. I
will like you to stand as the next of ki
On Wed, Jun 13, 2018 at 12:19 PM, Sowmini Varadhan
wrote:
> On (06/13/18 09:52), Dmitry Vyukov wrote:
>> I think this is:
>>
>> #syz dup: KASAN: use-after-free Read in rds_cong_queue_updates
>
> Indeed. We'd had a discussion about getting a dump of threads
> using sysrq (or similar), given the cha
On (06/13/18 09:52), Dmitry Vyukov wrote:
> I think this is:
>
> #syz dup: KASAN: use-after-free Read in rds_cong_queue_updates
Indeed. We'd had a discussion about getting a dump of threads
using sysrq (or similar), given the challenges around actually
getting a crash dump, is that now possible?
Hi Toshiaki,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on bpf/master]
url:
https://github.com/0day-ci/linux/commits/Toshiaki-Makita/xdp-Fix-handling-of-devmap-in-generic-XDP/20180613-161204
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf
On 06/13/2018 10:08 AM, Toshiaki Makita wrote:
> i40e_build_skb() reserves I40E_SKB_PAD + (xdp->data -
> xdp->data_hard_start) but obviously I40E_SKB_PAD is unnecessary here
> and mac_header/data feilds in skb becomes incorrect, and breaks normal
> skb receive path as well as XDP receive path.
>
>
Using skb_reserve(skb, I40E_SKB_PAD + (xdp->data - xdp->data_hard_start))
is clearly wrong since I40E_SKB_PAD already points to the offset where
the original xdp->data was sitting since xdp->data_hard_start is defined
as xdp->data - i40e_rx_offset(rx_ring) where latter offsets to I40E_SKB_PAD
when
Hi Toshiaki,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on bpf/master]
url:
https://github.com/0day-ci/linux/commits/Toshiaki-Makita/xdp-Fix-handling-of-devmap-in-generic-XDP/20180613-161204
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf
i40e_build_skb() reserves I40E_SKB_PAD + (xdp->data -
xdp->data_hard_start) but obviously I40E_SKB_PAD is unnecessary here
and mac_header/data feilds in skb becomes incorrect, and breaks normal
skb receive path as well as XDP receive path.
Fixes: cc5b114dcf98 ("bpf, i40e: add meta data support")
S
Commit 67f29e07e131 ("bpf: devmap introduce dev_map_enqueue") changed
the return value type of __devmap_lookup_elem() from struct net_device *
to struct bpf_dtab_netdev * but forgot to modify generic XDP code
accordingly.
Thus generic XDP incorrectly used struct bpf_dtab_netdev where struct
net_dev
60 matches
Mail list logo
