Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751418AbdH2SzZ (ORCPT ); Tue, 29 Aug 2017 14:55:25 -0400 Received: from mail-io0-f170.google.com ([209.85.223.170]:34905 "EHLO mail-io0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751186AbdH2SzW (ORCPT ); Tue, 29 Aug 2017 14:55:22 -0400 X-Google-Smtp-Source: ADKCNb7v6JCeDh32+yHDWR4gLWx5j0J6ajLdft7SXsveSdFetoJ+QHA1KGOGHThwL3P8M9G3iPcuMDQVLlhUsnIsv94= MIME-Version: 1.0 In-Reply-To: <20170829081453.GA10196@infradead.org> References: <1503956111-36652-1-git-send-email-keescook@chromium.org> <1503956111-36652-16-git-send-email-keescook@chromium.org> <20170829081453.GA10196@infradead.org> From: Kees Cook Date: Tue, 29 Aug 2017 11:55:20 -0700 X-Google-Sender-Auth: RTBm5fy-riJIwn_FJr4DR0lG_Eg Message-ID: Subject: Re: [PATCH v2 15/30] xfs: Define usercopy region in xfs_inode slab cache To: Christoph Hellwig Cc: LKML , David Windsor , "Darrick J. Wong" , linux-xfs@vger.kernel.org, Linux-MM , "kernel-hardening@lists.openwall.com" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 932 Lines: 22 On Tue, Aug 29, 2017 at 1:14 AM, Christoph Hellwig wrote: > One thing I've been wondering is wether we should actually just > get rid of the online area. Compared to reading an inode from > disk a single additional kmalloc is negligible, and not having the > inline data / extent list would allow us to reduce the inode size > significantly. > > Kees/David: how many of these patches are file systems with some > sort of inline data? Given that it's only about 30 patches declaring > allocations either entirely valid for user copy or not might end up > being nicer in many ways than these offsets. 9 filesystems use some form of inline data: xfs, vxfs, ufs, orangefs, exofs, befs, jfs, ext2, and ext4. How much of each slab is whitelisted varies by filesystem (e.g. ext2/4 uses i_data for other things, but ufs and orangefs and have a dedicate field for symlink names). -Kees -- Kees Cook Pixel Security