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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 24 Aug 2011 02:16:02 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Dave Chinner <david@...morbit.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-mm@...ck.org, khlebnikov@...nvz.org
Subject: Re: [PATCH 01/13] fs: Use a common define for inode slab caches

On Tue, Aug 23, 2011 at 07:20:41PM +1000, Dave Chinner wrote:
> > Why do we keep the SLAB_HWCACHE_ALIGN flag for some filesystems?
> 
> I didn't touch that one, mainly because I think that there are
> different reasons for wanting cacheline alignment. e.g. a filesystem
> aimed primarily at embedded systms with slow CPUs and little memory
> doesn't want to waste memory on cacheline alignment....

A little grepping shows jffs2 is a counter example, because it exactly
wants SLAB_HWCACHE_ALIGN to avoid issues with mtd dma.

I'm fine with defering this for now, but the state of using
SLAB_HWCACHE_ALIGN or not is just as much as mess as the rest of the
inode slab flags was.  I'd go as far as calling the whole existance of
most slab flags an utter mess, but that is another fight.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ