From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:36178 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967330AbdEWKN4 (ORCPT ); Tue, 23 May 2017 06:13:56 -0400 Date: Tue, 23 May 2017 12:13:44 +0200 From: Greg Kroah-Hartman To: Eric Biggers Cc: stable@vger.kernel.org, Theodore Ts'o , Eric Biggers Subject: Re: [PATCH 1/2] ext4 crypto: don't let data integrity writebacks fail with ENOMEM Message-ID: <20170523101344.GA28565@kroah.com> References: <20170522233752.109220-1-ebiggers3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170522233752.109220-1-ebiggers3@gmail.com> Sender: stable-owner@vger.kernel.org List-ID: On Mon, May 22, 2017 at 04:37:51PM -0700, Eric Biggers wrote: > From: Theodore Ts'o > > commit c9af28fdd44922a6c10c9f8315718408af98e315 upstream. [Please apply > to 4.4-stable. This fixes a bug which has caused problems on both > Android and Chrome OS, and this fix has already been included in a > number of ext4 encryption backports.] > > We don't want the writeback triggered from the journal commit (in > data=writeback mode) to cause the journal to abort due to > generic_writepages() returning an ENOMEM error. In addition, if > fsync() fails with ENOMEM, most applications will probably not do the > right thing. > > So if we are doing a data integrity sync, and ext4_encrypt() returns > ENOMEM, we will submit any queued I/O to date, and then retry the > allocation using GFP_NOFAIL. > > Google-Bug-Id: 27641567 > > Signed-off-by: Theodore Ts'o > Signed-off-by: Eric Biggers Thanks for both of these, now queued up. greg k-h