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: Sat, 16 Nov 2019 00:11:03 +1100 [thread overview]
Message-ID: <87a78xgu8o.fsf@dja-thinkpad.axtens.net> (raw)
In-Reply-To: <CANpmjNOCxTxTpbB_LwUQS5jzfQ_2zbZVAc4nKf0FRXmrwO-7sA@mail.gmail.com>
> test_bit() is an atomic bitop. I assume it was meant to be in
> instrumented-atomic.h?
Hmm, interesting.
I was tricked by the generic version doing just a simple read, with only
a volatile attribute to ensure the read occurs more-or-less as written:
/**
* test_bit - Determine whether a bit is set
* @nr: bit number to test
* @addr: Address to start counting from
*/
static inline int test_bit(int nr, const volatile unsigned long *addr)
{
return 1UL & (addr[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
}
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.
Sadly, only x86 and s390 specify an arch_test_bit, which will make moving it
into instumented-atomic.h break powerpc :(
I'll have a crack at something next week, probably with a similar trick
to arch_clear_bit_unlock_is_negative_byte.
Regards,
Daniel
>
> Thanks,
> -- Marco
>
>> >> +
>> >> +#endif /* _ASM_GENERIC_BITOPS_INSTRUMENTED_NON_ATOMIC_H */
>> >> --
>> >> 2.20.1
>>
>> --
>> You received this message because you are subscribed to the Google Groups "kasan-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/878sp57z44.fsf%40dja-thinkpad.axtens.net.
next prev parent reply other threads:[~2019-11-15 13:13 UTC|newest]
Thread overview: 13+ 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 ` [PATCH v2 2/2] powerpc: support KASAN instrumentation of bitops Daniel Axtens
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-30 5:11 ` Daniel Axtens
2019-10-28 13:56 ` Daniel Axtens
2019-11-14 20:56 ` Marco Elver
2019-11-15 13:11 ` Daniel Axtens [this message]
2019-11-20 7:42 ` Daniel Axtens
2019-11-20 8:32 ` Marco Elver
2019-12-03 13:04 ` Michael Ellerman
2019-12-03 13:36 ` Marco Elver
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=87a78xgu8o.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;
as well as URLs for NNTP newsgroup(s).