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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sat, 12 Nov 2022 07:42:49 +0800
From:   JunChao Sun <sunjunchao2870@...il.com>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     linux-ext4@...r.kernel.org, tytso@....edu,
        adilger.kernel@...ger.ca, jack@...e.cz
Subject: Re: [PATCH] ext4: replace kmem_cache_create with KMEM_CACHE

Eric Biggers <ebiggers@...nel.org> 于2022年11月10日周四 10:47写道:
>
> On Thu, Nov 10, 2022 at 08:53:26AM +0800, JunChao Sun wrote:
> > Yeah, maybe we should remove the SLAB_RECLAIM_ACCOUNT flag for static
> > slab, and 16828088f9e51815 ("ext4: use KMEM_CACHE instead of
> > kmem_cache_create") have done so. But should we remove
> > SLAB_RECLAIM_ACCOUNT in this patch or belong to a separate patch?
>
> I'd just keep the slab flags the same in this patch.  If any flags do need to be
> changed, that should be a separate patch.
>
>
> > I think SLAB_RECLAIM_ACCOUNT is meant for for things that are directly
> > reclaimable, such as struct ext4_inode_info.  Inodes are evictable, and when
> > that happens, the corresponding struct ext4_inode_info gets freed.
> >
> > bio_post_read_ctx_cache probably should use SLAB_TEMPORARY instead, since it is
> > only used for temporary structures during I/O.
How to decide whether to use SLAB_RECLAIM_ACCOUNT or not when creating
a slab cache? Is it based on whether the object is reclaimable or
evictable, or the amount of memory the object may use? If the first,
how to know whether an object is reclaimable or evictable?
Btw, I saw that ext4 called ext4_es_register_shrinker() to register
shrinker for struct extent_status, so SLAB_RECLAIM_ACCOUNT should be
used when creating ext4_es_cachep, right?
>
> That being said, SLAB_TEMPORARY is currently #define'd to SLAB_RECLAIM_ACCOUNT,
> so currently it makes no difference in practice...
>
> - Eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ