Re: [PATCH v2] epoll: add nsec timeout support

> Signed-off-by: Willem de Bruijn Acked-by: Soheil Hassas Yeganeh > --- > > Applies cleanly both to 5.10-rc4 and next-20201116. > In next, nstimeout no longer fills padding with new field refs. > > Selftest for now at github. Can follow-up for kselftests. > https:/

Re: [PATCH 0/8] simplify ep_poll

On Tue, Nov 10, 2020 at 5:05 PM Andrew Morton wrote: > > On Sat, 7 Nov 2020 23:45:30 -0500 Soheil Hassas Yeganeh > wrote: > > > On Sat, Nov 7, 2020 at 8:43 PM Andrew Morton > > wrote: > > > > > > On Fri, 6 Nov 2020 18:16:27 -0500 Soheil Hassas

Re: [PATCH 0/8] simplify ep_poll

On Mon, Nov 9, 2020 at 2:22 PM Davidlohr Bueso wrote: > > On Sat, 07 Nov 2020, Soheil Hassas Yeganeh wrote: > >FWIW, I also stress-tested the patch series applied on top of > >linux-next/master for a couple of hours. > > Out of curiosity, what exactly did you use for

Re: [PATCH 0/8] simplify ep_poll

On Sat, Nov 7, 2020 at 8:43 PM Andrew Morton wrote: > > On Fri, 6 Nov 2020 18:16:27 -0500 Soheil Hassas Yeganeh > wrote: > > > From: Soheil Hassas Yeganeh > > > > This patch series is a follow up based on the suggestions and feedback by > > Linus: >

[PATCH 6/8] epoll: pull all code between fetch_events and send_event into the loop

From: Soheil Hassas Yeganeh This is a no-op change which simplifies the follow up patches. Suggested-by: Linus Torvalds Signed-off-by: Soheil Hassas Yeganeh Reviewed-by: Eric Dumazet Reviewed-by: Willem de Bruijn Reviewed-by: Khazhismel Kumykov --- fs/eventpoll.c | 41

[PATCH 5/8] epoll: simplify and optimize busy loop logic

From: Soheil Hassas Yeganeh ep_events_available() is called multiple times around the busy loop logic, even though the logic is generally not used. ep_reset_busy_poll_napi_id() is similarly always called, even when busy loop is not used. Eliminate ep_reset_busy_poll_napi_id() and inline

[PATCH 2/8] epoll: simplify signal handling

From: Soheil Hassas Yeganeh Check signals before locking ep->lock, and immediately return -EINTR if there is any signal pending. This saves a few loads, stores, and branches from the hot path and simplifies the loop structure for follow up patches. Suggested-by: Linus Torvalds Signed-

[PATCH 4/8] epoll: move eavail next to the list_empty_careful check

From: Soheil Hassas Yeganeh This is a no-op change and simply to make the code more coherent. Suggested-by: Linus Torvalds Signed-off-by: Soheil Hassas Yeganeh Reviewed-by: Eric Dumazet Reviewed-by: Willem de Bruijn Reviewed-by: Khazhismel Kumykov --- fs/eventpoll.c | 3 +-- 1 file

[PATCH 1/8] epoll: check for events when removing a timed out thread from the wait queue

From: Soheil Hassas Yeganeh After abc610e01c66 ("fs/epoll: avoid barrier after an epoll_wait(2) timeout"), we break out of the ep_poll loop upon timeout, without checking whether there is any new events available. Prior to that patch-series we always called ep_events_available() aft

[PATCH 3/8] epoll: pull fatal signal checks into ep_send_events()

From: Soheil Hassas Yeganeh To simplify the code, pull in checking the fatal signals into ep_send_events(). ep_send_events() is called only from ep_poll(). Note that, previously, we were always checking fatal events, but it is checked only if eavail is true. This should be fine because

[PATCH 0/8] simplify ep_poll

From: Soheil Hassas Yeganeh This patch series is a follow up based on the suggestions and feedback by Linus: https://lkml.kernel.org/r/CAHk-=wizk=oxuyqpbo8ms41w2pag1kniuv5wdd5qwl-gq1k...@mail.gmail.com The first patch in the series is a fix for the epoll race in presence of timeouts, so

[PATCH 7/8] epoll: replace gotos with a proper loop

From: Soheil Hassas Yeganeh The existing loop is pointless, and the labels make it really hard to follow the structure. Replace that control structure with a simple loop that returns when there are new events, there is a signal, or the thread has timed out. Suggested-by: Linus Torvalds Signed

[PATCH 8/8] epoll: eliminate unnecessary lock for zero timeout

From: Soheil Hassas Yeganeh We call ep_events_available() under lock when timeout is 0, and then call it without locks in the loop for the other cases. Instead, call ep_events_available() without lock for all cases. For non-zero timeouts, we will recheck after adding the thread to the wait

[PATCH 2/2] epoll: add a selftest for epoll timeout race

From: Soheil Hassas Yeganeh Add a test case to ensure an event is observed by at least one poller when an epoll timeout is used. Signed-off-by: Guantao Liu Signed-off-by: Soheil Hassas Yeganeh Reviewed-by: Eric Dumazet Acked-by: Willem de Bruijn Reviewed-by: Khazhismel Kumykov

[PATCH 1/2] epoll: check ep_events_available() upon timeout

From: Soheil Hassas Yeganeh After abc610e01c66, we break out of the ep_poll loop upon timeout, without checking whether there is any new events available. Prior to that patch-series we always called ep_events_available() after exiting the loop. This can cause races and missed wakeups

Re: [PATCH] epoll: add nsec timeout support

me cacheline. > > Signed-off-by: Willem de Bruijn Acked-by: Soheil Hassas Yeganeh Thanks for adding the feature! > --- > > Selftest for now at github. Can follow-up for kselftests. > https://github.com/wdebruij/kerneltools/blob/master/tests/epo

Re: [PATCH net-next 2/2] bpf: avoid unused variable warning in tcp_bpf_rtt()

ror,-Wunused-variable] > struct tcp_sock *tp = tcp_sk(sk); > > The variable is only used in one place, so it can be > replaced with its value there to avoid the warning. > > Fixes: 23729ff23186 ("bpf: add BPF_CGROUP_SOCK_OPS callback that is executed > on every RTT") >

Re: [PATCH v3 net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive

_RECEIVE ...) > > Note that memcg might require additional changes. > > Fixes: 93ab6cc69162 ("tcp: implement mmap() for zero copy receive") > Signed-off-by: Eric Dumazet <eduma...@google.com> > Reported-by: syzbot <syzkal...@googlegroups.com> > Suggested-by:

Re: [PATCH v3 net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive

that memcg might require additional changes. > > Fixes: 93ab6cc69162 ("tcp: implement mmap() for zero copy receive") > Signed-off-by: Eric Dumazet > Reported-by: syzbot > Suggested-by: Andy Lutomirski > Cc: linux...@kvack.org > Cc: Soheil Hassas Yeganeh

Re: [PATCH v3 net-next 2/2] selftests: net: tcp_mmap must use TCP_ZEROCOPY_RECEIVE

d, because not properly page > aligned. > > Signed-off-by: Eric Dumazet <eduma...@google.com> > Cc: Andy Lutomirski <l...@kernel.org> > Cc: Soheil Hassas Yeganeh <soh...@google.com> Acked-by: Soheil Hassas Yeganeh <soh...@google.com> Thank you, again! >

Re: [PATCH v3 net-next 2/2] selftests: net: tcp_mmap must use TCP_ZEROCOPY_RECEIVE

page > aligned. > > Signed-off-by: Eric Dumazet > Cc: Andy Lutomirski > Cc: Soheil Hassas Yeganeh Acked-by: Soheil Hassas Yeganeh Thank you, again! > --- > tools/testing/selftests/net/tcp_mmap.c | 64 +++--- > 1 file changed, 37 insertions(+), 27 d

Re: [PATCH v2 net-next 0/2] tcp: mmap: rework zerocopy receive

adding a new setsockopt() operation and changes mmap() > behavior. > > Second patch changes tcp_mmap reference program. > > v2: > Added a missing page align of zc->length in tcp_zerocopy_receive() > Properly clear zc->recv_skip_hint in case user request was completed. Acked-b

Re: [PATCH v2 net-next 0/2] tcp: mmap: rework zerocopy receive

n and changes mmap() > behavior. > > Second patch changes tcp_mmap reference program. > > v2: > Added a missing page align of zc->length in tcp_zerocopy_receive() > Properly clear zc->recv_skip_hint in case user request was completed. Acked-by: Soheil Hassas Yeganeh

Re: [linux-next] [6f5b24e] WARNING: CPU: 0 PID: 10288 at net/ipv4/tcp_input.c:889 tcp_update_reordering+0x1c4/0x1e0

nfig : attached > Test: CPU toggle > > WARN_ON was first introduced with the commit: > > commit 6f5b24eed0278136c29c27f2a7b3a2b6a202ac68 > Author: Soheil Hassas Yeganeh <soh...@google.com> > Date: Tue May 16 17:39:02 2017 -0400 > > tcp: warn on negative reordering valu

Re: [linux-next] [6f5b24e] WARNING: CPU: 0 PID: 10288 at net/ipv4/tcp_input.c:889 tcp_update_reordering+0x1c4/0x1e0

gt; > WARN_ON was first introduced with the commit: > > commit 6f5b24eed0278136c29c27f2a7b3a2b6a202ac68 > Author: Soheil Hassas Yeganeh > Date: Tue May 16 17:39:02 2017 -0400 > > tcp: warn on negative reordering values > > Commit bafbb9c73241 ("tcp: eliminate

Re: commit f5f99309 (sock: do not set sk_err in sock_dequeue_err_skb) has broken ping

On Thu, Jun 1, 2017 at 11:36 AM, Cyril Hrubis wrote: > It seems to repeatedly produce (until I plug the cable back): > > ee_errno = 113 ee_origin = 2 ee_type = 3 ee_code = 1 ee_info = 0 ee_data = 0 > > So we get EHOSTUNREACH on SO_EE_ORIGIN_ICMP. Thank you very much! I have a

Re: commit f5f99309 (sock: do not set sk_err in sock_dequeue_err_skb) has broken ping

On Thu, Jun 1, 2017 at 11:36 AM, Cyril Hrubis wrote: > It seems to repeatedly produce (until I plug the cable back): > > ee_errno = 113 ee_origin = 2 ee_type = 3 ee_code = 1 ee_info = 0 ee_data = 0 > > So we get EHOSTUNREACH on SO_EE_ORIGIN_ICMP. Thank you very much! I have a wild guess that,

Re: commit f5f99309 (sock: do not set sk_err in sock_dequeue_err_skb) has broken ping

On Thu, Jun 1, 2017 at 11:10 AM, Cyril Hrubis wrote: >> Thank you for the confirmation. Could you please try the following >> patch to see if it fixes your issue? > > Does not seem to help, I still got the same bussy loop. Thank you for trying the patch. Unfortunately, I can't

Re: commit f5f99309 (sock: do not set sk_err in sock_dequeue_err_skb) has broken ping

On Thu, Jun 1, 2017 at 11:10 AM, Cyril Hrubis wrote: >> Thank you for the confirmation. Could you please try the following >> patch to see if it fixes your issue? > > Does not seem to help, I still got the same bussy loop. Thank you for trying the patch. Unfortunately, I can't reproduce on my

Re: commit f5f99309 (sock: do not set sk_err in sock_dequeue_err_skb) has broken ping

you please try the following patch to see if it fixes your issue? >From 3ec438460425d127741b20f03f78644c9e441e8c Mon Sep 17 00:00:00 2001 From: Soheil Hassas Yeganeh <soh...@google.com> Date: Thu, 1 Jun 2017 10:34:09 -0400 Subject: [PATCH net] sock: reset sk_err when the error queue is empty Befor

Re: commit f5f99309 (sock: do not set sk_err in sock_dequeue_err_skb) has broken ping

ch to see if it fixes your issue? >From 3ec438460425d127741b20f03f78644c9e441e8c Mon Sep 17 00:00:00 2001 From: Soheil Hassas Yeganeh Date: Thu, 1 Jun 2017 10:34:09 -0400 Subject: [PATCH net] sock: reset sk_err when the error queue is empty Before f5f99309fa74 (sock: do no

Re: commit f5f99309 (sock: do not set sk_err in sock_dequeue_err_skb) has broken ping

On Thu, Jun 1, 2017 at 10:00 AM, Cyril Hrubis <chru...@suse.cz> wrote: > I've bisected the problem to this commit: > > commit f5f99309fa7481f59a500f0d08f3379cd6424c1f (HEAD, refs/bisect/bad) > Author: Soheil Hassas Yeganeh <soh...@google.com> > Date: Thu Nov 3 18:24

Re: commit f5f99309 (sock: do not set sk_err in sock_dequeue_err_skb) has broken ping

On Thu, Jun 1, 2017 at 10:00 AM, Cyril Hrubis wrote: > I've bisected the problem to this commit: > > commit f5f99309fa7481f59a500f0d08f3379cd6424c1f (HEAD, refs/bisect/bad) > Author: Soheil Hassas Yeganeh > Date: Thu Nov 3 18:24:27 2016 -0400 > > so

Re: [PATCH] ipv6: make sure to initialize sockc.tsflags before first use

ialization earlier. > > The bug was detected with KMSAN. Nice catch and thanks for the fix! This is missing a "fixes" attribution, added below. > Signed-off-by: Alexander Potapenko <gli...@google.com> Fixes: c14ac9451c34 ("sock: enable timestamping using control messages") Acked-by: Soheil Hassas Yeganeh <soh...@google.com>

Re: [PATCH] ipv6: make sure to initialize sockc.tsflags before first use

e bug was detected with KMSAN. Nice catch and thanks for the fix! This is missing a "fixes" attribution, added below. > Signed-off-by: Alexander Potapenko Fixes: c14ac9451c34 ("sock: enable timestamping using control messages") Acked-by: Soheil Hassas Yeganeh

Re: [BUG] 4.10-rc8 - ping spinning?

On Thu, Feb 16, 2017 at 11:08 AM, <l...@pengaru.com> wrote: > On Thu, Feb 16, 2017 at 10:52:19AM -0500, Soheil Hassas Yeganeh wrote: >> On Thu, Feb 16, 2017 at 10:50 AM, Soheil Hassas Yeganeh >> <soh...@google.com> wrote: >> > Thank you Vito for the report. &g

Re: [BUG] 4.10-rc8 - ping spinning?

On Thu, Feb 16, 2017 at 11:08 AM, wrote: > On Thu, Feb 16, 2017 at 10:52:19AM -0500, Soheil Hassas Yeganeh wrote: >> On Thu, Feb 16, 2017 at 10:50 AM, Soheil Hassas Yeganeh >> wrote: >> > Thank you Vito for the report. >> > >> > The patch you

Re: [BUG] 4.10-rc8 - ping spinning?

On Thu, Feb 16, 2017 at 10:50 AM, Soheil Hassas Yeganeh <soh...@google.com> wrote: > Thank you Vito for the report. > > The patch you cited actually resolves a similar backward compatibility > problem for traceroute. > > I suspect the problem here is that ther

Re: [BUG] 4.10-rc8 - ping spinning?

On Thu, Feb 16, 2017 at 10:50 AM, Soheil Hassas Yeganeh wrote: > Thank you Vito for the report. > > The patch you cited actually resolves a similar backward compatibility > problem for traceroute. > > I suspect the problem here is that there's a local error queued on the &

Re: [BUG] 4.10-rc8 - ping spinning?

d message below. This was sent to linux-kernel but > after digging a little I suspect it's specific to the network stack. > > Perusing the net/ changes between 4.9 and 4.10-rc8 this sounded awful related > to what I'm observing: > > commit 83a1a1a70e87f676fbb6086b26b6ac7f7fdd107d > Au

Re: [BUG] 4.10-rc8 - ping spinning?

after digging a little I suspect it's specific to the network stack. > > Perusing the net/ changes between 4.9 and 4.10-rc8 this sounded awful related > to what I'm observing: > > commit 83a1a1a70e87f676fbb6086b26b6ac7f7fdd107d > Author: Soheil Hassas Yeganeh > Date: Wed Nov