lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 6 Aug 2018 22:20:17 +0200
From:   Jan Kara <>
To:     Dmitry Vyukov <>
Cc:     Linus Torvalds <>,
        Christoph Lameter <>,
        Andrey Ryabinin <>,
        Theodore Ts'o <>, Jan Kara <>,,
        Greg Kroah-Hartman <>,
        Pablo Neira Ayuso <>,
        Jozsef Kadlecsik <>,
        Florian Westphal <>,
        David Miller <>,
        NetFilter <>,,
        Network Development <>,
        Gerrit Renker <>,,
        Jani Nikula <>,
        Joonas Lahtinen <>,
        Rodrigo Vivi <>,
        Dave Airlie <>,
        intel-gfx <>,
        DRI <>,
        Eric Dumazet <>,
        Alexey Kuznetsov <>,
        Hideaki YOSHIFUJI <>,
        Ursula Braun <>,
        linux-s390 <>,
        Linux Kernel Mailing List <>,
        Andrew Morton <>,
        linux-mm <>,
        Andrey Konovalov <>
Subject: Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4
 13/17] khwasan: add hooks implementation)

On Wed 01-08-18 10:46:35, Dmitry Vyukov wrote:
> I guess it would be useful to have such extensive comment for each
> SLAB_TYPESAFE_BY_RCU use explaining why it is needed and how all the
> tricky aspects are handled.
> For example, the one in jbd2 is interesting because it memsets the
> whole object before freeing it into SLAB_TYPESAFE_BY_RCU slab:
> memset(jh, JBD2_POISON_FREE, sizeof(*jh));
> kmem_cache_free(jbd2_journal_head_cache, jh);
> I guess there are also tricky ways how it can all work in the end
> (type-stable state is only a byte, or we check for all possible
> combinations of being overwritten with JBD2_POISON_FREE). But at first
> sight it does look fishy.

The RCU access is used from a single place:

fs/jbd2/transaction.c: jbd2_write_access_granted()

There are also quite some comments explaining why what it does is safe. The
overwrite by JBD2_POISON_FREE is much older than this RCU stuff (honestly I
didn't know about it until this moment) and has nothing to do with the
safety of RCU access.


Jan Kara <>

Powered by blists - more mailing lists