LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Juri Lelli <juri.lelli@redhat.com>
Cc: linux-rt-users <linux-rt-users@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Ahmed S. Darwish" <a.darwish@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RT v5.11-rt7] WARNING at include/linux/seqlock.h:271 nft_counter_eval
Date: Tue, 23 Feb 2021 15:21:18 +0100	[thread overview]
Message-ID: <20210223142118.u22yhw3ku4ttx5hq@linutronix.de> (raw)
In-Reply-To: <YDUI5M5FQLycOd33@localhost.localdomain>

On 2021-02-23 14:53:40 [+0100], Juri Lelli wrote:
> 
> So, I'm a bit confused and I'm very likely missing details (still
> digesting the seqprop_ magic), but write_seqcount_being() has
> 
>  if (seqprop_preemptible(s))
>      preempt_disable();
> 
> which in this case (no lock associated) is defined to return false, 
> while it should return true on RT (or in some occasions)? Or maybe this
> is what you are saying already.

write_seqcount_begin() has seqprop_assert() at the very beginning which
ends in __seqprop_assert() in your case (seqcount_t). Your warning.


> Also, the check for preemption been disabled happens before we can
> actually potentially disable it, no?

That seqprop_preemptible() is true for !RT for mutex/ww_mutex locks. On
RT it is always false since it does lock()+unlock() of the lock that is
part of the seqcount.

But back to the original issue: at write_seqcount_begin() preemption is
disabled !RT implicit by local_bh_disable(). Therefore no warning.
On RT local_bh_disable() disables BH on the CPUs so locking wise (since
it is a per-CPU seqcount it should work. Preemption remains enabled so
we have a warning.

I have no idea what annotation would be best here. Having a
local_bh_disable() type of a lock and the seqcount is not part of the data
structure it protects is less than ideal.
However, if I understand this correct then this nft_counter_percpu_priv
exists once per nft rule. The seqcount exists once per-CPU since it is
unlikely to modify two counters at once on a single CPU :) So there is
that.

While looking at it, there is nft_counter_reset() which modifies the
values without a seqcount write lock. This might be okay.

> Thanks for the quick reply!
> 
> Best,
> Juri

Sebastian

      parent reply	other threads:[~2021-02-23 14:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-23 10:49 Juri Lelli
2021-02-23 11:00 ` Sebastian Andrzej Siewior
2021-02-23 13:53   ` Juri Lelli
2021-02-23 14:20     ` Ahmed S. Darwish
2021-02-23 14:21     ` Sebastian Andrzej Siewior [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=20210223142118.u22yhw3ku4ttx5hq@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=a.darwish@linutronix.de \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --subject='Re: [RT v5.11-rt7] WARNING at include/linux/seqlock.h:271 nft_counter_eval' \
    /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

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox