linux-kernel - Re: [PATCH] jffs2: safely remove obsolete dirent from the f->dents list

lists.openwall.net		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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1524867762.18504.89.camel@infradead.org>
Date:   Fri, 27 Apr 2018 23:22:42 +0100
From:   David Woodhouse <dwmw2@...radead.org>
To:     Yufen Yu <yuyufen@...wei.com>
Cc:     Joakim.Tjernlund@...inera.com, viro@...iv.linux.org.uk,
        linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] jffs2: safely remove obsolete dirent from the f->dents
 list

This looks a lot better than the first iteration; thank you for getting
it to this point. One last thing, I hope...
On Thu, 2018-03-29 at 20:00 +0800, Yufen Yu wrote:
> 
> --- a/fs/jffs2/jffs2_fs_i.h
> +++ b/fs/jffs2/jffs2_fs_i.h
> @@ -42,6 +42,12 @@ struct jffs2_inode_info {
>         /* Directory entries */
>         struct jffs2_full_dirent *dents;
>  
> +       /* Directory open refcount */
> +       atomic_t nr_dir_opening;
> +
> +       /* obsolete dirent count in the list of 'dents' */
> +       unsigned int obsolete_count;
> +
>         /* The target path if this is the inode of a symlink */
>         unsigned char *target;
>  

You've made JFFS2_INVALID_LIMIT 64, which is reasonable enough
(although it's a bit of a weird name and possibly wants to be more
specific — invalid *what*?).

So the maximum interesting value of ->obsolete_count is 64. Which means
it might as well be a uint8_t and sit in the padding after the
'usercompr' field.

It might be useful to look at putting the mutually exclusive fields in
struct jffs2_inode_info into a union, and then we don't need the
additional space of the atomic_t either; we'll never need that *and*
the fragtree at the same time... will we?
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)