linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Yang Shi <shy828301@gmail.com>
To: paulmck@kernel.org
Cc: David Hildenbrand <david@redhat.com>,
	Peter Xu <peterx@redhat.com>,
	 kernel test robot <oliver.sang@intel.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	 Vivek Kasireddy <vivek.kasireddy@intel.com>,
	Rik van Riel <riel@surriel.com>,
	oe-lkp@lists.linux.dev,  lkp@intel.com,
	linux-kernel@vger.kernel.org,
	 Andrew Morton <akpm@linux-foundation.org>,
	Matthew Wilcox <willy@infradead.org>,
	 Christopher Lameter <cl@linux.com>,
	linux-mm@kvack.org
Subject: Re: [linus:master] [mm] efa7df3e3b: kernel_BUG_at_include/linux/page_ref.h
Date: Tue, 4 Jun 2024 10:35:04 -0700	[thread overview]
Message-ID: <CAHbLzkpuZx7cHoY6vLyetJ9T+KJrTKi1vt=wFv8YMhab7awDxQ@mail.gmail.com> (raw)
In-Reply-To: <821cf1d6-92b9-4ac4-bacc-d8f2364ac14f@paulmck-laptop>

> >
> > I chased it further to:
> >
> > commit 8375ad98cc1defc36adf4a77d9ea1e71db51a371
> > Author: Paul E. McKenney <paulmck@kernel.org>
> > Date:   Mon Apr 29 15:06:13 2013 -0700
> >
> >     vm: adjust ifdef for TINY_RCU
> >     There is an ifdef in page_cache_get_speculative() that checks for !SMP
> >     and TREE_RCU, which has been an impossible combination since the advent
> >     of TINY_RCU.  The ifdef enables a fastpath that is valid when preemption
> >     is disabled by rcu_read_lock() in UP systems, which is the case when
> >     TINY_RCU is enabled.  This commit therefore adjusts the ifdef to
> >     generate the fastpath when TINY_RCU is enabled.
> >
> >
> > Where Paul explicitly restored that fastpath for TINY_RCU instead of removing that code.
> >
> > So maybe Paul can comment if that is still worth having. CCing him.
>
> It is currently an atomic operation either way, though the folio_ref_add()
> avoids full ordering, but that is immaterial on x86.  Some say that it is
> in the noise on server-class ARMv8 as well, though they have also said
> a great many things in the past.  But if that is true, the big benefit
> of the TINY_RCU check is that folio_ref_try_add_rcu() is guaranted not
> to fail in that case (single CPU with preemption disabled).  Except that
> everyone has to check the return value anyway, right?
>
> So the usual advice, unsatisfying though it might be, is to remove that
> #ifdef and see if anyone notices.
>
> After all, both 2013 and 2008 were quite some time ago.  ;-)

Thanks, Paul.

I will submit a patch to remove the #ifdef as the fix for the bug
report. And do the clean up in a separate patch which is preferred by
David.

>
>                                                         Thanx, Paul


      reply	other threads:[~2024-06-04 17:35 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-31  8:24 kernel test robot
2024-05-31 16:50 ` Yang Shi
     [not found]   ` <890e5a79-8574-4a24-90ab-b9888968d5e5@redhat.com>
2024-05-31 18:07     ` Yang Shi
2024-05-31 18:13       ` Yang Shi
2024-05-31 18:24         ` David Hildenbrand
2024-05-31 18:30           ` Yang Shi
2024-05-31 18:38             ` David Hildenbrand
2024-05-31 19:06               ` Yang Shi
2024-05-31 20:57                 ` Yang Shi
2024-06-03 14:02                   ` Oliver Sang
2024-06-03 16:54                     ` Yang Shi
2024-06-04 23:53                       ` Yang Shi
2024-06-06  2:15                         ` Oliver Sang
2024-06-06  3:44                           ` Yang Shi
2024-06-12  6:01                             ` Oliver Sang
2024-06-25 20:34                               ` Yang Shi
2024-06-25 20:41                                 ` David Hildenbrand
2024-06-25 20:53                                   ` Yang Shi
2024-05-31 23:24     ` Peter Xu
2024-06-01  0:01       ` Yang Shi
2024-06-01  0:59         ` Yang Shi
     [not found]           ` <0edfcfed-e8c4-4c46-bbce-528c07084792@redhat.com>
2024-06-03 15:08             ` Peter Xu
     [not found]               ` <8da12503-839d-459f-a2fa-4abd6d21935d@redhat.com>
     [not found]                 ` <Zl4m-sAhZknHOHdb@x1n>
2024-06-03 20:37                   ` David Hildenbrand
2024-06-03 20:44                     ` Yang Shi
2024-06-03 21:01                       ` David Hildenbrand
     [not found]                     ` <Zl4vlGJsbHiahYil@x1n>
2024-06-03 21:05                       ` David Hildenbrand
2024-06-03 22:43                         ` Paul E. McKenney
2024-06-04 17:35                           ` Yang Shi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHbLzkpuZx7cHoY6vLyetJ9T+KJrTKi1vt=wFv8YMhab7awDxQ@mail.gmail.com' \
    --to=shy828301@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=david@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=oe-lkp@lists.linux.dev \
    --cc=oliver.sang@intel.com \
    --cc=paulmck@kernel.org \
    --cc=peterx@redhat.com \
    --cc=riel@surriel.com \
    --cc=vivek.kasireddy@intel.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox