Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 6 Sep 2018 08:41:44 -0700
From:   Guenter Roeck <linux@roeck-us.net>
To:     "Theodore Y. Ts'o" <tytso@mit.edu>,
        David Howells <dhowells@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Widespread crashes in next-20180906
Message-ID: <20180906154144.GA13745@roeck-us.net>
References: <2e8e31f5-4db5-4907-2d09-f6444bc78ede@roeck-us.net>
 <20180906140413.GA5098@thunk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180906140413.GA5098@thunk.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Sep 06, 2018 at 10:04:13AM -0400, Theodore Y. Ts'o wrote:
> On Thu, Sep 06, 2018 at 06:45:15AM -0700, Guenter Roeck wrote:
> > Build results:
> > 	total: 134 pass: 133 fail: 1
> > Failed builds:
> > 	sparc32:allmodconfig
> > Qemu test results:
> > 	total: 311 pass: 76 fail: 235
> > Failed builds:
> > 	<pretty much everything trying to boot from disk>
> > 
> > Error message is always something like
> > 
> > Filesystem requires source device
> > VFS: Cannot open root device "hda" or unknown-block(3,0): error -2
> > 
> > The only variance is the boot device. Logs in full glory are available
> > at https://kerneltests.org/builders/, in the "next" column.
> > 
> > I did not run bisect, but the recent filesystem changes are a definite suspect.
> 
> Yes, this is the vm_fault_t changes.  See the other thread on LKML.
> The guilty commit was: 83c0adddcc6e: fs: convert return type int to
> vm_fault_t
> 
That thing is just asking for trouble. Why not leave return type
and value alone and add vm_fault_t * (assuming it really adds value)
as another parameter ? Is it really a good idea to deviate from "return
well defined error as integer" as used everywhere else in the kernel ?
Do we really need "my_favored_error_return_t" in every subsystem going
forward ? Oh well, I guess (hope) that is all discussed in the other
thread.

> This is the *second* time vm_fault_t patches have broken things.  The
> first time it went through the ext4 tree, and I NACK'ed it after
> running a 60 second smoke test showed it was broken.  The seocnd time
> the problem was supposedly fixed, but it went through the mm tree, and
> so I didn't have a chance regression test or stop it...
> 
Looking at the patch, NACK seems like the proper response to me, maybe
augmented with "please refrain from shooting yourself (and everyone else)
in the foot".

Guenter