public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Axtens <dja@axtens.net>
To: Marco Elver <elver@google.com>
Cc: linux-s390@vger.kernel.org,
	the arch/x86 maintainers <x86@kernel.org>,
	kasan-dev <kasan-dev@googlegroups.com>,
	linux-arch <linux-arch@vger.kernel.org>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 1/2] kasan: support instrumented bitops combined with generic bitops
Date: Wed, 20 Nov 2019 18:42:50 +1100	[thread overview]
Message-ID: <87y2wbf0xx.fsf@dja-thinkpad.axtens.net> (raw)
In-Reply-To: <87a78xgu8o.fsf@dja-thinkpad.axtens.net>

> But the docs do seem to indicate that it's atomic (for whatever that
> means for a single read operation?), so you are right, it should live in
> instrumented-atomic.h.

Actually, on further inspection, test_bit has lived in
bitops/non-atomic.h since it was added in 4117b02132d1 ("[PATCH] bitops:
generic __{,test_and_}{set,clear,change}_bit() and test_bit()")

So to match that, the wrapper should live in instrumented-non-atomic.h
too.

If test_bit should move, that would need to be a different patch. But I
don't really know if it makes too much sense to stress about a read
operation, as opposed to a read/modify/write...

Regards,
Daniel

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Axtens <dja@axtens.net>
To: Marco Elver <elver@google.com>
Cc: christophe.leroy@c-s.fr, linux-s390@vger.kernel.org,
	linux-arch <linux-arch@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	linuxppc-dev@lists.ozlabs.org,
	kasan-dev <kasan-dev@googlegroups.com>
Subject: Re: [PATCH v2 1/2] kasan: support instrumented bitops combined with generic bitops
Date: Wed, 20 Nov 2019 18:42:50 +1100	[thread overview]
Message-ID: <87y2wbf0xx.fsf@dja-thinkpad.axtens.net> (raw)
Message-ID: <20191120074250.bWx1gCzzLtcUXSyjtfp5InsrVtHNHmJFvAg7u04rLIQ@z> (raw)
In-Reply-To: <87a78xgu8o.fsf@dja-thinkpad.axtens.net>

> But the docs do seem to indicate that it's atomic (for whatever that
> means for a single read operation?), so you are right, it should live in
> instrumented-atomic.h.

Actually, on further inspection, test_bit has lived in
bitops/non-atomic.h since it was added in 4117b02132d1 ("[PATCH] bitops:
generic __{,test_and_}{set,clear,change}_bit() and test_bit()")

So to match that, the wrapper should live in instrumented-non-atomic.h
too.

If test_bit should move, that would need to be a different patch. But I
don't really know if it makes too much sense to stress about a read
operation, as opposed to a read/modify/write...

Regards,
Daniel

  parent reply	other threads:[~2019-11-20  7:42 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-20  2:49 [PATCH v2 1/2] kasan: support instrumented bitops combined with generic bitops Daniel Axtens
2019-08-20  2:49 ` Daniel Axtens
2019-08-20  2:49 ` [PATCH v2 2/2] powerpc: support KASAN instrumentation of bitops Daniel Axtens
2019-08-20  2:49   ` Daniel Axtens
2019-08-20 16:34   ` Christophe Leroy
2019-08-20 16:34     ` Christophe Leroy
2019-08-20  9:55 ` [PATCH v2 1/2] kasan: support instrumented bitops combined with generic bitops Marco Elver
2019-08-20  9:55   ` Marco Elver
2019-08-30  5:11 ` Daniel Axtens
2019-08-30  5:11   ` Daniel Axtens
2019-10-28 13:56   ` Daniel Axtens
2019-10-28 13:56     ` Daniel Axtens
2019-11-14 20:56     ` Marco Elver
2019-11-14 20:56       ` Marco Elver
2019-11-15 13:11       ` Daniel Axtens
2019-11-15 13:11         ` Daniel Axtens
2019-11-20  7:42         ` Daniel Axtens [this message]
2019-11-20  7:42           ` Daniel Axtens
2019-11-20  8:32           ` Marco Elver
2019-11-20  8:32             ` Marco Elver
2019-12-03 13:04             ` Michael Ellerman
2019-12-03 13:04               ` Michael Ellerman
2019-12-03 13:36               ` Marco Elver
2019-12-03 13:36                 ` Marco Elver
2019-12-03 23:39               ` Daniel Axtens
2019-12-03 23:39                 ` Daniel Axtens

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=87y2wbf0xx.fsf@dja-thinkpad.axtens.net \
    --to=dja@axtens.net \
    --cc=elver@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=x86@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