linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: "Paul Heidekrüger" <paul.heidekrueger@tum.de>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
	Andrea Parri <parri.andrea@gmail.com>,
	Will Deacon <will@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	David Howells <dhowells@redhat.com>,
	Jade Alglave <j.alglave@ucl.ac.uk>,
	Luc Maranget <luc.maranget@inria.fr>,
	Akira Yokosawa <akiyks@gmail.com>,
	Daniel Lustig <dlustig@nvidia.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	llvm@lists.linux.dev, Marco Elver <elver@google.com>,
	Charalampos Mainas <charalampos.mainas@gmail.com>,
	Pramod Bhatotia <pramod.bhatotia@in.tum.de>,
	Soham Shakraborty <s.s.chakraborty@tudelft.nl>,
	Martin Fink <martin.fink@in.tum.de>
Subject: Re: Broken Address Dependency in mm/ksm.c::cmp_and_merge_page()
Date: Fri, 13 Jan 2023 10:22:20 -0500	[thread overview]
Message-ID: <Y8F3LMlTnT5ZtVTq@rowland.harvard.edu> (raw)
In-Reply-To: <0EC00B0E-554A-4BF3-B012-ED1E36B12FD1@tum.de>

On Fri, Jan 13, 2023 at 12:11:25PM +0100, Paul Heidekrüger wrote:
> Hi all,
> 
> FWIW, here are two more broken address dependencies, both very similar to the
> one discussed in this thread. From what I can tell, both are protected by a
> lock, so, again, nothing to worry about right now? Would you agree?

FWIW, my opinion is that in both cases the broken dependency can be 
removed entirely.

> Comments marked with "AD:" were added by me for readability.
> 
> 1. drivers/hwtracing/stm/core.c::1050 - 1085
> 
>         /**
>          * __stm_source_link_drop() - detach stm_source from an stm device
>          * @src:	stm_source device
>          * @stm:	stm device
>          *
>          * If @stm is @src::link, disconnect them from one another and put the
>          * reference on the @stm device.
>          *
>          * Caller must hold stm::link_mutex.
>          */
>         static int __stm_source_link_drop(struct stm_source_device *src,
>                                           struct stm_device *stm)
>         {
>                 struct stm_device *link;
>                 int ret = 0;
> 
>                 lockdep_assert_held(&stm->link_mutex);
> 
>                 /* for stm::link_list modification, we hold both mutex and spinlock */
>                 spin_lock(&stm->link_lock);
>                 spin_lock(&src->link_lock);
> 
>                 /* AD: Beginning of the address dependency. */
>                 link = srcu_dereference_check(src->link, &stm_source_srcu, 1);
> 
>                 /*
>                  * The linked device may have changed since we last looked, because
>                  * we weren't holding the src::link_lock back then; if this is the
>                  * case, tell the caller to retry.
>                  */
>                 if (link != stm) {
>                         ret = -EAGAIN;
>                         goto unlock;
>                 }
> 
>                 /* AD: Compiler deduces that "link" and "stm" are exchangeable at this point. */
>                 stm_output_free(link, &src->output); list_del_init(&src->link_entry);
> 
>                 /* AD: Leads to WRITE_ONCE() to (&link->dev)->power.last_busy. */
>                 pm_runtime_mark_last_busy(&link->dev);

In both of these statements, link can safely be replaced by stm.

(There's also a control dependency which the LKMM isn't aware of.  This 
makes it all the more safe.)

> 2. kernel/locking/lockdep.c::6319 - 6348
> 
>         /*
>          * Unregister a dynamically allocated key.
>          *
>          * Unlike lockdep_register_key(), a search is always done to find a matching
>          * key irrespective of debug_locks to avoid potential invalid access to freed
>          * memory in lock_class entry.
>          */
>         void lockdep_unregister_key(struct lock_class_key *key)
>         {
>                 struct hlist_head *hash_head = keyhashentry(key);
>                 struct lock_class_key *k;
>                 struct pending_free *pf;
>                 unsigned long flags;
>                 bool found = false;
> 
>                 might_sleep();
> 
>                 if (WARN_ON_ONCE(static_obj(key)))
>                         return;
> 
>                 raw_local_irq_save(flags);
>                 lockdep_lock();
> 
>                 /* AD: Address dependency begins here with an rcu_dereference_raw() into k. */
>                 hlist_for_each_entry_rcu(k, hash_head, hash_entry) {
>                         /* AD: Compiler deduces that k and key are exchangable iff the if condition evaluates to true.
>                         if (k == key) {
>                                 /* AD: Leads to WRITE_ONCE() to (&k->hash_entry)->pprev. */
>                                 hlist_del_rcu(&k->hash_entry);

And here k could safely be replaced with key.  (And again there is a 
control dependency, but this is one that the LKMM would detect.)

Alan Stern

>                                 found = true;
>                                 break;
>                         }
>                 }
> 
> Many thanks,
> Paul

  reply	other threads:[~2023-01-13 15:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-22 10:35 Broken Address Dependency in mm/ksm.c::cmp_and_merge_page() Paul Heidekrüger
2022-04-26 20:32 ` Paul E. McKenney
2022-05-31 11:47   ` Paul Heidekrüger
2022-05-31 15:03     ` Paul E. McKenney
2023-01-13 11:11       ` Paul Heidekrüger
2023-01-13 15:22         ` Alan Stern [this message]
2023-01-18 10:42           ` Paul Heidekrüger
2023-01-18 18:09             ` Paul E. McKenney
2023-01-25 20:39             ` Boqun Feng
2023-02-01  9:04               ` Paul Heidekrüger

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=Y8F3LMlTnT5ZtVTq@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=akiyks@gmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=charalampos.mainas@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=dlustig@nvidia.com \
    --cc=elver@google.com \
    --cc=j.alglave@ucl.ac.uk \
    --cc=joel@joelfernandes.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=luc.maranget@inria.fr \
    --cc=martin.fink@in.tum.de \
    --cc=npiggin@gmail.com \
    --cc=parri.andrea@gmail.com \
    --cc=paul.heidekrueger@tum.de \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pramod.bhatotia@in.tum.de \
    --cc=s.s.chakraborty@tudelft.nl \
    --cc=will@kernel.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;
as well as URLs for NNTP newsgroup(s).