Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Uladzislau Rezki <urezki@gmail.com>
Date:   Thu, 29 Oct 2020 21:13:42 +0100
To:     "Paul E. McKenney" <paulmck@kernel.org>
Cc:     "Uladzislau Rezki (Sony)" <urezki@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>, RCU <rcu@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Michal Hocko <mhocko@suse.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        "Theodore Y . Ts'o" <tytso@mit.edu>,
        Joel Fernandes <joel@joelfernandes.org>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Subject: Re: [PATCH 16/16] rcu/tree: Use delayed work instead of hrtimer to
 refill the cache
Message-ID: <20201029201342.GA24122@pc636>
References: <20201029165019.14218-1-urezki@gmail.com>
 <20201029165019.14218-16-urezki@gmail.com>
 <20201029194724.GN3249@paulmck-ThinkPad-P72>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20201029194724.GN3249@paulmck-ThinkPad-P72>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Thu, Oct 29, 2020 at 12:47:24PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 29, 2020 at 05:50:19PM +0100, Uladzislau Rezki (Sony) wrote:
> > A CONFIG_PREEMPT_COUNT is unconditionally enabled, thus a page
> > can be obtained directly from a kvfree_rcu() path. To distinguish
> > that and take a decision the preemptable() macro is used when it
> > is save to enter allocator.
> > 
> > It means that refilling a cache is not important from timing point
> > of view. Switch to a delayed work, so the actual work is queued from
> > the timer interrupt with 1 jiffy delay. An immediate placing a task
> > on a current CPU can lead to rq->lock double lock. That is why a
> > delayed method is in place.
> > 
> > Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
> 
> Thank you, Uladzislau!
> 
> I applied this on top of v5.10-rc1 and got the following from the
> single-CPU builds:
> 
>   SYNC    include/config/auto.conf.cmd
>   DESCEND  objtool
>   CC      kernel/bounds.s
>   CALL    scripts/atomic/check-atomics.sh
>   UPD     include/generated/bounds.h
>   CC      arch/x86/kernel/asm-offsets.s
> In file included from ./include/asm-generic/atomic-instrumented.h:20:0,
>                  from ./include/linux/atomic.h:82,
>                  from ./include/linux/crypto.h:15,
>                  from arch/x86/kernel/asm-offsets.c:9:
> ./include/linux/pagemap.h: In function ‘__page_cache_add_speculative’:
> ./include/linux/build_bug.h:30:34: error: called object is not a function or function pointer
>  #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
>                                  ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/mmdebug.h:45:25: note: in expansion of macro ‘BUILD_BUG_ON_INVALID’
>  #define VM_BUG_ON(cond) BUILD_BUG_ON_INVALID(cond)
>                          ^~~~~~~~~~~~~~~~~~~~
> ./include/linux/pagemap.h:207:2: note: in expansion of macro ‘VM_BUG_ON’
>   VM_BUG_ON(preemptible())
>   ^~~~~~~~~
> scripts/Makefile.build:117: recipe for target 'arch/x86/kernel/asm-offsets.s' failed
> make[1]: *** [arch/x86/kernel/asm-offsets.s] Error 1
> Makefile:1199: recipe for target 'prepare0' failed
> make: *** [prepare0] Error 2
> 
> I vaguely recall something like this showing up in the previous series
> and that we did something or another to address it.  Could you please
> check against the old series at -rcu branch dev.2020.10.22a?  (I verified
> that the old series does run correctly in the single-CPU scenarios.)
> 
I see the same build error. Will double check if we have similar in the
previous series also. It looks like the error is caused by the Thomas series.

Will check!

--
Vlad Rezki