On Fri, May 31, 2019 at 08:45:47AM -0700, Eric Dumazet wrote:
>
>
> On 5/31/19 7:45 AM, Herbert Xu wrote:
> > On Fri, May 31, 2019 at 10:24:08AM +0200, Dmitry Vyukov wrote:
> >>
> >> OK, let's call it barrier. But we need more than a barrier here then.
> >
> > READ_ONCE/WRITE_ONCE is not some ma
On Sat, Jun 08, 2019 at 10:50:51AM -0700, Linus Torvalds wrote:
> On Sat, Jun 8, 2019 at 10:42 AM Linus Torvalds
> wrote:
> >
> > There are no atomic rmw sequences that have reasonable performance for
> > the bitfield updates themselves.
>
> Note that this is purely about the writing side. Reads
On Tue, Dec 15, 2020 at 07:50:31AM +0530, Naresh Kamboju wrote:
> There are two warnings "WARNING: suspicious RCU usage" noticed on arm64
> juno-r2
> device while running selftest bpf test_tc_edt.sh and net: udpgro_bench.sh.
> These warnings are occurring intermittently.
>
> metadata:
> git bra
On Tue, Nov 17, 2020 at 08:09:22PM -0500, Steven Rostedt wrote:
> On Tue, 17 Nov 2020 16:42:44 -0800
> Matt Mullins wrote:
>
>
> > > Indeed with a stub function, I don't see any need for
> > > READ_ONCE/WRITE_ONCE.
> >
> > I'm not sure if this is a practical issue, but without WRITE_ONCE, ca
On Sat, Apr 17, 2021 at 02:27:19PM +0200, Toke Høiland-Jørgensen wrote:
> "Paul E. McKenney" writes:
>
> > On Fri, Apr 16, 2021 at 11:22:52AM -0700, Martin KaFai Lau wrote:
> >> On Fri, Apr 16, 2021 at 03:45:23PM +0200, Jesper Dangaard Brouer wrote:
> >&
On Mon, Apr 19, 2021 at 08:12:27PM +0200, Toke Høiland-Jørgensen wrote:
> "Paul E. McKenney" writes:
>
> > On Sat, Apr 17, 2021 at 02:27:19PM +0200, Toke Høiland-Jørgensen wrote:
> >> "Paul E. McKenney" writes:
> >>
> >> > On
On Mon, Apr 19, 2021 at 11:21:41PM +0200, Toke Høiland-Jørgensen wrote:
> "Paul E. McKenney" writes:
>
> > On Mon, Apr 19, 2021 at 08:12:27PM +0200, Toke Høiland-Jørgensen wrote:
> >> "Paul E. McKenney" writes:
> >>
> >> > On Sat,
On Tue, Apr 20, 2021 at 12:16:40AM +0200, Toke Høiland-Jørgensen wrote:
> "Paul E. McKenney" writes:
>
> > On Mon, Apr 19, 2021 at 11:21:41PM +0200, Toke Høiland-Jørgensen wrote:
> >> "Paul E. McKenney" writes:
> >>
> >> > On Mon,
On Sun, Apr 04, 2021 at 11:24:57AM +0100, Matthew Wilcox wrote:
> On Sat, Apr 03, 2021 at 09:15:17PM -0700, syzbot wrote:
> > HEAD commit:2bb25b3a Merge tag 'mips-fixes_5.12_3' of git://git.kernel..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1284c
On Sun, Apr 04, 2021 at 07:24:53PM +0100, Matthew Wilcox wrote:
> On Sun, Apr 04, 2021 at 09:48:08AM -0700, Paul E. McKenney wrote:
> > On Sun, Apr 04, 2021 at 11:24:57AM +0100, Matthew Wilcox wrote:
> > > On Sat, Apr 03, 2021 at 09:15:17PM -0700, syzbot wrote:
> > >
On Fri, Apr 16, 2021 at 11:22:52AM -0700, Martin KaFai Lau wrote:
> On Fri, Apr 16, 2021 at 03:45:23PM +0200, Jesper Dangaard Brouer wrote:
> > On Thu, 15 Apr 2021 17:39:13 -0700
> > Martin KaFai Lau wrote:
> >
> > > On Thu, Apr 15, 2021 at 10:29:40PM +0200, Toke Høiland-Jørgensen wrote:
> > > >
On Wed, Mar 03, 2021 at 06:04:22PM +, Russell King - ARM Linux admin wrote:
> On Wed, Mar 03, 2021 at 09:53:38AM -0800, Paul E. McKenney wrote:
> > drivers/net: #ifdef mdio_bus_phy_suspend() and mdio_bus_phy_suspend()
> >
> > The following build error is emitted by rcuto
used only in CONFIG_PM_SLEEP=y kernels. This commit therefore
wraps them in #ifdef CONFIG_PM_SLEEP.
Cc: Andrew Lunn
Cc: Heiner Kallweit
Cc: Russell King
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc:
Signed-off-by: Paul E. McKenney
diff --git a/drivers/net/phy/phy_device.c b/drive
On Mon, Aug 10, 2020 at 04:08:59PM -0400, Joel Fernandes wrote:
> On Fri, Aug 07, 2020 at 03:20:15PM -0700, Paul E. McKenney wrote:
> > On Fri, Aug 07, 2020 at 04:47:56PM -0400, Joel Fernandes wrote:
> > > Hi,
> > > Adding more of us working on RCU as well. Johan from a
On Thu, Feb 21, 2019 at 04:31:17PM +0100, Peter Zijlstra wrote:
> On Thu, Feb 21, 2019 at 10:21:39AM -0500, Joel Fernandes wrote:
> > On Thu, Feb 21, 2019 at 10:18:05AM +0100, Peter Zijlstra wrote:
> > > On Thu, Feb 21, 2019 at 12:49:40AM -0500, Joel Fernandes (Google) wrote:
> > > > @@ -34,8 +34,1
On Thu, Feb 21, 2019 at 12:13:11PM -0500, Joel Fernandes wrote:
> On Thu, Feb 21, 2019 at 05:11:44PM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 21, 2019 at 07:52:18AM -0800, Paul E. McKenney wrote:
> > > On Thu, Feb 21, 2019 at 04:31:17PM +0100, Peter Zijlstra wrote:
> >
ab net/core/rtnetlink.c:332:13:got struct
> rtnl_link *[noderef] *
>
> Signed-off-by: Joel Fernandes (Google)
>From an RCU perspective:
Reviewed-by: Paul E. McKenney
> ---
> net/core/rtnetlink.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --
Signed-off-by: Joel Fernandes (Google)
>From an RCU perspective:
Reviewed-by: Paul E. McKenney
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 4 ++--
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 15 ++-
> 2 files changed, 12 insertions(+), 7 deletions(-)
&g
arse catch any future RCU misuage bugs.
>
> Signed-off-by: Joel Fernandes (Google)
>From an RCU perspective:
Reviewed-by: Paul E. McKenney
> ---
> kernel/sched/cpufreq.c | 2 +-
> kernel/sched/sched.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
>
fair.c:9421:16: error: incompatible types in comparison expression
> fair.c:9421:16: error: incompatible types in comparison expression
>
> Signed-off-by: Joel Fernandes (Google)
>From an RCU perspective:
Reviewed-by: Paul E. McKenney
> ---
> include/linux/sched/topology.h |
:16: sparse: error: incompatible types in comparison expression
>
> Signed-off-by: Joel Fernandes (Google)
>From an RCU perspective:
Reviewed-by: Paul E. McKenney
> ---
> include/linux/rcuwait.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
ng __rcu will also help sparse catch any future bugs.
>
> Signed-off-by: Joel Fernandes (Google)
>From an RCU perspective:
Reviewed-by: Paul E. McKenney
> ---
> kernel/sched/sched.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/sc
On Fri, Oct 06, 2017 at 02:57:45PM +0200, Paolo Abeni wrote:
> The networking subsystem is currently using some kind of long-lived
> RCU-protected, references to avoid the overhead of full book-keeping.
>
> Such references - skb_dst() noref - are stored inside the skbs and can be
> moved across re
On Fri, Oct 06, 2017 at 05:10:09PM +0200, Paolo Abeni wrote:
> Hi,
>
> On Fri, 2017-10-06 at 06:34 -0700, Paul E. McKenney wrote:
> > On Fri, Oct 06, 2017 at 02:57:45PM +0200, Paolo Abeni wrote:
> > > The networking subsystem is currently using some kind of long-l
READ_ONCE() now implies smp_read_barrier_depends(), which means that
the instances in arpt_do_table(), ipt_do_table(), and ip6t_do_table()
are now redundant. This commit removes them and adjusts the comments.
Signed-off-by: Paul E. McKenney
Cc: Pablo Neira Ayuso
Cc: Jozsef Kadlecsik
Cc
smp_read_barrier_depends().
Signed-off-by: Paul E. McKenney
Cc: Ariel Elior
Cc:
Cc:
---
drivers/net/ethernet/qlogic/qed/qed_spq.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_spq.c
b/drivers/net/ethernet/qlogic/qed/qed_spq.c
index
On Tue, Oct 10, 2017 at 10:43:34AM +0200, Peter Zijlstra wrote:
> On Mon, Oct 09, 2017 at 05:22:48PM -0700, Paul E. McKenney wrote:
> > READ_ONCE() now implies smp_read_barrier_depends(), which means that
> > the instances in arpt_do_table(), ipt_do_table(), and ip6t_do_tabl
On Mon, Oct 09, 2017 at 06:53:12PM +0200, Paolo Abeni wrote:
> On Fri, 2017-10-06 at 09:34 -0700, Paul E. McKenney wrote:
> > On Fri, Oct 06, 2017 at 05:10:09PM +0200, Paolo Abeni wrote:
> > > Hi,
> > >
> > > On Fri, 2017-10-06 at 06:34 -0700, Paul E. McKenney
On Wed, Oct 11, 2017 at 04:50:36PM +0200, Paolo Abeni wrote:
> On Tue, 2017-10-10 at 21:02 -0700, Paul E. McKenney wrote:
> > Linus and Ingo will ask me how users decide how they should set that
> > additional build flag. Especially given that if there is code that
> >
On Mon, Oct 07, 2019 at 12:04:16PM +0200, Marco Elver wrote:
> +RCU maintainers
> This might be a data-race in RCU itself.
Quite possibly. I will take a look, but there will be delays due to this
week being bootcamp and all.
Thanx, Paul
>
On Mon, Sep 14, 2020 at 03:47:38PM -0700, Jakub Kicinski wrote:
> On Mon, 14 Sep 2020 16:21:22 -0400 Joel Fernandes wrote:
> > On Tue, Sep 08, 2020 at 05:27:51PM -0700, Jakub Kicinski wrote:
> > > On Tue, 08 Sep 2020 21:15:56 +0300 niko...@cumulusnetworks.com wrote:
> > > > Ah, you want to solve
On Mon, Sep 14, 2020 at 05:30:29PM -0700, Jakub Kicinski wrote:
> On Mon, 14 Sep 2020 17:20:11 -0700 Paul E. McKenney wrote:
> > > Seems like quite a few places depend on the macro disappearing its
> > > argument. I was concerned that it's going to be had to pick out whe
On Fri, Aug 07, 2020 at 04:47:56PM -0400, Joel Fernandes wrote:
> Hi,
> Adding more of us working on RCU as well. Johan from another team at
> Google discovered a likely issue in openswitch, details below:
>
> On Fri, Aug 7, 2020 at 11:32 AM Johan Knöös wrote:
> >
> > On Tue, Aug 4, 2020 at 8:52
On Wed, Sep 16, 2020 at 11:45:21AM -0700, Jakub Kicinski wrote:
> Hi!
>
> So I unfolded the RFC patch into smaller chunks and fixed an issue
> in SRCU pointed out by build bot. Build bot has been quiet for
> a day but I'm not 100% sure it's scanning my tree, so let's
> give these patches some ML e
used without
> BPF_SYSCALL.
>
> Reported-by: kernel test robot
> Fixes: 1e6c62a88215 ("bpf: Introduce sleepable BPF programs")
> Signed-off-by: Alexei Starovoitov
A couple of nits below, but overall:
Acked-by: Paul E. McKenney
> ---
> include/linux/rcupdate_trace
On Sun, Aug 30, 2020 at 05:53:21PM -0700, Alexei Starovoitov wrote:
> On Sun, Aug 30, 2020 at 03:03:13PM -0700, Paul E. McKenney wrote:
> > On Sun, Aug 30, 2020 at 01:43:28PM -0700, Alexei Starovoitov wrote:
> > > From: Alexei Starovoitov
> > >
> > > Whe
d BPF trampoline logic won't be used without BPF_SYSCALL.
>
> Reported-by: kernel test robot
> Fixes: 1e6c62a88215 ("bpf: Introduce sleepable BPF programs")
> Acked-by: Paul E. McKenney
> Signed-off-by: Alexei Starovoitov
Looks goo
On Fri, Oct 19, 2018 at 12:02:43PM +0100, Will Deacon wrote:
> On Thu, Oct 18, 2018 at 08:53:42PM -0700, Alexei Starovoitov wrote:
> > On Thu, Oct 18, 2018 at 09:00:46PM +0200, Daniel Borkmann wrote:
> > > On 10/18/2018 05:33 PM, Alexei Starovoitov wrote:
> > > > On Thu, Oct 18, 2018 at 05:04:34PM
On Thu, Jan 24, 2019 at 07:56:52PM +0100, Peter Zijlstra wrote:
> On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> >
> > Thanks for having kernel/locking people on Cc...
> >
> > On Wed, Jan 23, 2019 at 08:13:55PM -0800, Alexei Starovoitov wrote:
> >
> > > Implementation details:
On Thu, Jan 24, 2019 at 04:05:16PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 24, 2019 at 03:42:32PM -0800, Paul E. McKenney wrote:
> > On Thu, Jan 24, 2019 at 07:56:52PM +0100, Peter Zijlstra wrote:
> > > On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
>
On Fri, Jan 25, 2019 at 02:46:55AM +0100, Jann Horn wrote:
> On Fri, Jan 25, 2019 at 2:22 AM Paul E. McKenney
> wrote:
> > On Thu, Jan 24, 2019 at 04:05:16PM -0800, Alexei Starovoitov wrote:
> > > On Thu, Jan 24, 2019 at 03:42:32PM -0800, Paul E. McKenney wrote:
> >
On Fri, Jan 25, 2019 at 04:27:02AM +, Alexei Starovoitov wrote:
> On 1/24/19 6:38 PM, Alexei Starovoitov wrote:
> >> For programs created with CAP_SYS_ADMIN,
> >> things get more tricky because you can create your own functions and
> >> call them repeatedly; I'm not sure whether the pessimal ru
On Fri, Jan 25, 2019 at 04:47:20AM +, Alexei Starovoitov wrote:
> On 1/24/19 8:31 PM, Paul E. McKenney wrote:
> > On Fri, Jan 25, 2019 at 04:27:02AM +, Alexei Starovoitov wrote:
> >> On 1/24/19 6:38 PM, Alexei Starovoitov wrote:
> >>>> For programs created
On Fri, Jan 25, 2019 at 05:18:12PM +0100, Jann Horn wrote:
> On Fri, Jan 25, 2019 at 5:12 AM Paul E. McKenney
> wrote:
> > On Fri, Jan 25, 2019 at 02:46:55AM +0100, Jann Horn wrote:
> > > On Fri, Jan 25, 2019 at 2:22 AM Paul E. McKenney
> > > wrote:
> > &g
On Wed, Jan 30, 2019 at 06:11:00PM +, Will Deacon wrote:
> Hi Alexei,
>
> On Mon, Jan 28, 2019 at 01:56:24PM -0800, Alexei Starovoitov wrote:
> > On Mon, Jan 28, 2019 at 10:24:08AM +0100, Peter Zijlstra wrote:
> > > On Fri, Jan 25, 2019 at 04:17:26PM -0800, Alexei Starovoitov wrote:
> > > > Wh
On Wed, Jan 30, 2019 at 11:51:14AM -0800, Alexei Starovoitov wrote:
> On Wed, Jan 30, 2019 at 10:36:18AM -0800, Paul E. McKenney wrote:
> > On Wed, Jan 30, 2019 at 06:11:00PM +, Will Deacon wrote:
> > > Hi Alexei,
> > >
> > > On Mon, Jan 28, 2019 at 01:56:
On Wed, Jan 30, 2019 at 02:57:43PM -0800, Alexei Starovoitov wrote:
> On Wed, Jan 30, 2019 at 01:05:36PM -0800, Paul E. McKenney wrote:
> > On Wed, Jan 30, 2019 at 11:51:14AM -0800, Alexei Starovoitov wrote:
> > > On Wed, Jan 30, 2019 at 10:36:18AM -0800, Paul E. McKenney wro
On Thu, Jan 31, 2019 at 10:47:50AM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 31, 2019 at 06:01:56AM -0800, Paul E. McKenney wrote:
> > On Wed, Jan 30, 2019 at 02:57:43PM -0800, Alexei Starovoitov wrote:
> > > On Wed, Jan 30, 2019 at 01:05:36PM -0800, Paul E. McKenney wro
On Tue, Dec 18, 2018 at 02:26:00PM +0100, Dmitry Vyukov wrote:
> On Tue, Dec 18, 2018 at 1:40 PM Stefano Brivio wrote:
> >
> > On Tue, 18 Dec 2018 09:49:17 +0100
> > Dmitry Vyukov wrote:
> >
> > > On Tue, Dec 18, 2018 at 12:18 AM Stefano Brivio
> > > wrote:
> > > >
> > > > On Mon, 17 Dec 2018 1
On Mon, Jan 07, 2019 at 08:36:36AM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 07, 2019 at 10:46:10AM +0100, Peter Zijlstra wrote:
> > On Sun, Jan 06, 2019 at 11:23:07PM -0500, Michael S. Tsirkin wrote:
> > > On Mon, Jan 07, 2019 at 11:58:23AM +0800, Jason Wang wrote:
> > > > On 2019/1/3 上午4:57,
On Mon, Jan 07, 2019 at 02:13:29PM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 07, 2019 at 11:02:36AM -0800, Paul E. McKenney wrote:
> > On Mon, Jan 07, 2019 at 08:36:36AM -0500, Michael S. Tsirkin wrote:
> > > On Mon, Jan 07, 2019 at 10:46:10AM +0100, Peter Zijlstra wrote:
&
On Fri, Dec 07, 2018 at 03:47:07PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the rcu tree got conflicts in:
>
> net/bridge/br_mdb.c
> net/bridge/br_multicast.c
>
> between commits:
>
> 19e3a9c90c53 ("net: bridge: convert multicast to generic rhashtable")
>
On Mon, Dec 17, 2018 at 10:44:52AM +0100, Dmitry Vyukov wrote:
> On Sun, Dec 16, 2018 at 8:04 PM Paul E. McKenney
> wrote:
> >
> > On Sat, Dec 15, 2018 at 04:41:03AM -0800, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following crash on:
On Mon, Dec 17, 2018 at 03:40:06PM +0100, Dmitry Vyukov wrote:
> On Mon, Dec 17, 2018 at 3:14 PM Arjan van de Ven
> wrote:
> >
> > On 12/17/2018 3:29 AM, Paul E. McKenney wrote:
> > > As does this sort of report on a line that contains simple integer
> > &g
On Mon, Dec 17, 2018 at 07:45:58PM +0100, Dmitry Vyukov wrote:
> On Mon, Dec 17, 2018 at 12:29 PM Paul E. McKenney
> wrote:
> > Any chance of a bisection?
>
> Better later then never. Bisection also needs testing :)
Well, it looks like it did pass the test, arriving at th
smp_read_barrier_depends().
Signed-off-by: Paul E. McKenney
Cc: Ariel Elior
Cc:
Cc:
---
drivers/net/ethernet/qlogic/qed/qed_spq.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_spq.c
b/drivers/net/ethernet/qlogic/qed/qed_spq.c
index
Because READ_ONCE() now implies read_barrier_depends(), the
read_barrier_depends() in next_desc() is now redundant. This commit
therefore removes it and the related comments.
Signed-off-by: Paul E. McKenney
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc:
Cc:
Cc:
---
drivers/vhost/v
READ_ONCE() now implies smp_read_barrier_depends(), which means that
the instances in arpt_do_table(), ipt_do_table(), and ip6t_do_table()
are now redundant. This commit removes them and adjusts the comments.
Signed-off-by: Paul E. McKenney
Cc: Pablo Neira Ayuso
Cc: Jozsef Kadlecsik
Cc
On Thu, May 14, 2020 at 02:30:11PM -0700, Andrii Nakryiko wrote:
> On Thu, May 14, 2020 at 1:39 PM Thomas Gleixner wrote:
> >
> > Jakub Kicinski writes:
> >
> > > On Wed, 13 May 2020 12:25:27 -0700 Andrii Nakryiko wrote:
> > >> One interesting implementation bit, that significantly simplifies (an
On Sun, May 17, 2020 at 12:57:21PM -0700, Andrii Nakryiko wrote:
> This commits adds a new MPSC ring buffer implementation into BPF ecosystem,
> which allows multiple CPUs to submit data to a single shared ring buffer. On
> the consumption side, only single consumer is assumed.
[ . . . ]
Focusing
en2=1; px=2;
> 0:rFail=0; 1:rFail=0; 2:rFail=0; 3:rFail=0; cx=1; len1=1; len2=1; px=3;
> 0:rFail=0; 1:rFail=0; 2:rFail=0; 3:rFail=0; cx=2; len1=1; len2=1; px=2;
> 0:rFail=0; 1:rFail=0; 2:rFail=0; 3:rFail=0; cx=2; len1=1; len2=1; px=3;
> Ok
> Witnesses
> Positive: 558 Negative:
On Fri, May 22, 2020 at 11:46:49AM -0700, Andrii Nakryiko wrote:
> On Thu, May 21, 2020 at 5:25 PM Paul E. McKenney wrote:
> >
> > On Sun, May 17, 2020 at 12:57:21PM -0700, Andrii Nakryiko wrote:
> > > This commits adds a new MPSC ring buffer implementation into BPF
>
On Mon, May 25, 2020 at 04:33:15PM -0700, Andrii Nakryiko wrote:
> On Fri, May 22, 2020 at 11:51 AM Andrii Nakryiko
> wrote:
> >
> > On Thu, May 21, 2020 at 5:34 PM Paul E. McKenney wrote:
> > >
> > > On Sun, May 17, 2020 at 12:57:22PM -0700, Andrii Nakryiko w
On Thu, Apr 30, 2020 at 09:28:32AM -0400, Qian Cai wrote:
> > On Apr 30, 2020, at 9:15 AM, Paul E. McKenney wrote:
> >> https://raw.githubusercontent.com/cailca/linux-mm/master/x86.config
> >>
> >> [53294.651754][T149877] futex_wake_op: trinity-c25 tries t
On Tue, May 05, 2020 at 09:25:06AM -0700, Eric Dumazet wrote:
>
>
> On 5/5/20 9:13 AM, SeongJae Park wrote:
> > On Tue, 5 May 2020 09:00:44 -0700 Eric Dumazet wrote:
> >
> >> On Tue, May 5, 2020 at 8:47 AM SeongJae Park wrote:
> >>>
> >>> On Tue, 5 May 2020 08:20:50 -0700 Eric Dumazet
> >>>
On Tue, May 05, 2020 at 09:37:42AM -0700, Eric Dumazet wrote:
>
>
> On 5/5/20 9:31 AM, Eric Dumazet wrote:
> >
> >
> > On 5/5/20 9:25 AM, Eric Dumazet wrote:
> >>
> >>
> >> On 5/5/20 9:13 AM, SeongJae Park wrote:
> >>> On Tue, 5 May 2020 09:00:44 -0700 Eric Dumazet
> >>> wrote:
> >>>
> O
On Tue, May 05, 2020 at 07:05:53PM +0200, SeongJae Park wrote:
> On Tue, 5 May 2020 09:37:42 -0700 Eric Dumazet wrote:
>
> >
> >
> > On 5/5/20 9:31 AM, Eric Dumazet wrote:
> > >
> > >
> > > On 5/5/20 9:25 AM, Eric Dumazet wrote:
> > >>
> > >>
> > >> On 5/5/20 9:13 AM, SeongJae Park wrote:
> >
On Tue, May 05, 2020 at 07:56:05PM +0200, SeongJae Park wrote:
> On Tue, 5 May 2020 10:30:36 -0700 "Paul E. McKenney"
> wrote:
>
> > On Tue, May 05, 2020 at 07:05:53PM +0200, SeongJae Park wrote:
> > > On Tue, 5 May 2020 09:37:4
On Tue, May 05, 2020 at 07:49:43PM +0200, SeongJae Park wrote:
> On Tue, 5 May 2020 10:23:58 -0700 "Paul E. McKenney"
> wrote:
>
> > On Tue, May 05, 2020 at 09:25:06AM -0700, Eric Dumazet wrote:
> > >
> > >
> > > On 5/5/20 9:13 AM, Seon
On Tue, May 05, 2020 at 08:40:07PM +0200, SeongJae Park wrote:
> On Tue, 5 May 2020 11:27:20 -0700 "Paul E. McKenney"
> wrote:
>
> > On Tue, May 05, 2020 at 07:49:43PM +0200, SeongJae Park wrote:
> > > On Tue, 5 May 2020 10:23:58 -0700 "Paul E. McKenne
On Tue, May 05, 2020 at 08:34:02PM +0200, SeongJae Park wrote:
> On Tue, 5 May 2020 11:17:07 -0700 "Paul E. McKenney"
> wrote:
>
> > On Tue, May 05, 2020 at 07:56:05PM +0200, SeongJae Park wrote:
> > > On Tue, 5 May 2020 10:30:36 -0700 "Paul E. McKenne
On Wed, May 06, 2020 at 02:59:26PM +0200, SeongJae Park wrote:
> TL; DR: It was not kernel's fault, but the benchmark program.
>
> So, the problem is reproducible using the lebench[1] only. I carefully read
> it's code again.
>
> Before running the problem occurred "poll big" sub test, lebench e
i Starovoitov
> Acked-by: Andrii Nakryiko
>From an RCU perspective:
Acked-by: Paul E. McKenney
> ---
> kernel/bpf/arraymap.c | 9 -
> kernel/bpf/hashtab.c | 8 +++-
> kernel/bpf/lpm_trie.c | 5 -
> kernel/bpf/queue_stack_maps.c |
e_disable() and
> new bpf_map_release_elem() will do corresponding migrate_enable().
> Or explicit bpf_migrate_disable/enable() helpers will be introduced.
>
> Signed-off-by: Alexei Starovoitov
> Acked-by: Andrii Nakryiko
>From an RCU viewpoint:
Acked-by: Paul E. McKenney
I was going to
On Thu, Jun 11, 2020 at 03:29:09PM -0700, Alexei Starovoitov wrote:
> On Thu, Jun 11, 2020 at 3:23 PM Alexei Starovoitov
> wrote:
> >
> > /* dummy _ops. The verifier will operate on target program's ops. */
> > const struct bpf_verifier_ops bpf_extension_verifier_ops = {
> > @@ -205,14 +206,12 @
On Thu, Jun 11, 2020 at 07:13:01PM -0700, Alexei Starovoitov wrote:
> On Thu, Jun 11, 2020 at 05:04:47PM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 11, 2020 at 03:29:09PM -0700, Alexei Starovoitov wrote:
> > > On Thu, Jun 11, 2020 at 3:23 PM Alexei Starov
On Wed, Jul 25, 2018 at 02:53:36PM +1000, NeilBrown wrote:
> On Tue, Jul 24 2018, Paul E. McKenney wrote:
>
> > On Tue, Jul 24, 2018 at 07:52:03AM +1000, NeilBrown wrote:
> >> On Mon, Jul 23 2018, Paul E. McKenney wrote:
> >>
> >> > On Mon, Jul 23,
Hello!
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This series therefore removes spin_unlock_wait() and changes
its users to instead use a lock/unlock pair. The commits are as follows,
in thr
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This commit therefore removes the underlying arch-specific
arch_spin_unlock_wait().
Signed-off-by: Paul E. McKenney
Cc: Russell King
Cc
safe from a performance perspective because exit_sem()
is rarely invoked in production.
Signed-off-by: Paul E. McKenney
Cc: Andrew Morton
Cc: Davidlohr Bueso
Cc: Manfred Spraul
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Alan Stern
Cc: Andrea Parri
Cc: Linus Torvalds
---
ipc/sem.c | 3 ++-
1
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This commit therefore removes the underlying arch-specific
arch_spin_unlock_wait().
Signed-off-by: Paul E. McKenney
Cc: Richard Henderso
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This commit therefore removes the underlying arch-specific
arch_spin_unlock_wait().
Signed-off-by: Paul E. McKenney
Cc: Chris Zankel
Cc
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This commit therefore removes the underlying arch-specific
arch_spin_unlock_wait().
Signed-off-by: Paul E. McKenney
Cc: "James E.J. Bott
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This commit therefore removes the underlying arch-specific
arch_spin_unlock_wait().
Signed-off-by: Paul E. McKenney
Cc: Yoshinori Sato
Cc:
ately by spin_unlock(). These functions do not appear
to be invoked on any fastpaths.
Signed-off-by: Paul E. McKenney
Cc: Pablo Neira Ayuso
Cc: Jozsef Kadlecsik
Cc: Florian Westphal
Cc: "David S. Miller"
Cc:
Cc:
Cc:
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Alan Stern
Cc: A
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This commit therefore removes the underlying arch-specific
arch_spin_unlock_wait().
Signed-off-by: Paul E. McKenney
Cc: "David S. Miller
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This commit therefore removes the underlying arch-specific
arch_spin_unlock_wait().
Signed-off-by: Paul E. McKenney
Cc: Martin Schwidefsk
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This commit therefore removes the underlying arch-specific
arch_spin_unlock_wait().
Signed-off-by: Paul E. McKenney
Cc: Benjamin Herrenschmid
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This commit therefore removes the underlying arch-specific
arch_spin_unlock_wait().
Signed-off-by: Paul E. McKenney
Cc: David Howells
Cc
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This commit therefore removes the underlying arch-specific
arch_spin_unlock_wait().
Signed-off-by: Paul E. McKenney
Cc: Tony Luck
Cc: Fengh
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This commit therefore removes the underlying arch-specific
arch_spin_unlock_wait().
Signed-off-by: Paul E. McKenney
Cc: Richard Kuo
Cc:
Cc:
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This commit therefore removes the underlying arch-specific
arch_spin_unlock_wait().
Signed-off-by: Paul E. McKenney
Cc: Catalin Marinas
Cc:
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This commit therefore removes the underlying arch-specific
arch_spin_unlock_wait().
Signed-off-by: Paul E. McKenney
Cc: Steven Miao
Cc:
Cc:
of
the "if" statement. This should be safe from a performance perspective
because according to Tejun there should be few if any drivers that don't
set their own error handler.
Signed-off-by: Paul E. McKenney
Acked-by: Tejun Heo
Cc:
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Alan St
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This commit therefore removes the underlying arch-specific
arch_spin_unlock_wait().
Signed-off-by: Paul E. McKenney
Cc: Ralf Baechle
Cc
hould be safe from a performance perspective because the lock
will be held only the wakeup happens really quickly.
Signed-off-by: Paul E. McKenney
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Alan Stern
Cc: Andrea Parri
Cc: Linus Torvalds
---
kernel/sched/completion.c | 9 ++-
On Thu, Jun 29, 2017 at 05:06:16PM -0700, Linus Torvalds wrote:
> On Thu, Jun 29, 2017 at 5:01 PM, Paul E. McKenney
> wrote:
> > There is no agreed-upon definition of spin_unlock_wait()'s semantics,
> > and it appears that all callers could do just as well with a lock
ld be safe from a performance perspective because the lock is
this tasks ->pi_lock, and this is called only after the task exits.
Signed-off-by: Paul E. McKenney
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Alan Stern
Cc: Andrea Parri
Cc: Linus Torvalds
---
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This commit therefore removes the underlying arch-specific
arch_spin_unlock_wait().
Signed-off-by: Paul E. McKenney
Cc: Will Deacon
Cc:
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This commit therefore removes the underlying arch-specific
arch_spin_unlock_wait().
Signed-off-by: Paul E. McKenney
Cc: Chris Metcalf
Cc:
1 - 100 of 328 matches
Mail list logo
