From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941687AbdAGTYs (ORCPT ); Sat, 7 Jan 2017 14:24:48 -0500 Received: from imap.thunk.org ([74.207.234.97]:50772 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750978AbdAGTYr (ORCPT ); Sat, 7 Jan 2017 14:24:47 -0500 Date: Sat, 7 Jan 2017 14:24:06 -0500 From: "Theodore Ts'o" To: Eric Biggers Cc: Richard Weinberger , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, jaegeuk@kernel.org, hch@infradead.org, arnd@arndb.de, dedekind1@gmail.com, linux-mtd@lists.infradead.org, adrian.hunter@intel.com, linux-ext4@vger.kernel.org, ebiggers@google.com, rdunlap@infradead.org, david@sigma-star.at Subject: Re: [PATCH v2] fscrypt: Factor out bio specific functions Message-ID: <20170107192406.56p7ppbdfkjii4vy@thunk.org> Mail-Followup-To: Theodore Ts'o , Eric Biggers , Richard Weinberger , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, jaegeuk@kernel.org, hch@infradead.org, arnd@arndb.de, dedekind1@gmail.com, linux-mtd@lists.infradead.org, adrian.hunter@intel.com, linux-ext4@vger.kernel.org, ebiggers@google.com, rdunlap@infradead.org, david@sigma-star.at References: <20161219103929.GA16197@infradead.org> <20161219112532.18863-1-richard@nod.at> <20170101214725.g67msbedmpx27waz@thunk.org> <20170103142836.no7rp3hphj3czjto@thunk.org> <20170104201043.GA21696@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170104201043.GA21696@gmail.com> User-Agent: NeoMutt/20161126 (1.7.1) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 04, 2017 at 12:10:43PM -0800, Eric Biggers wrote: > > I thought you're supposed to be able to build the kernel no matter how it's > configured. If this patch is really too large for 4.10 then perhaps we should > make FS_ENCRYPTION select CONFIG_BLOCK instead? We already have FS_ENCRYPTIOn depending on BLOCK, so this is *not* fixing a build break. Given that, it's a bit harder to claim this is a must-have bug fix for the stable branch? - Ted