From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753161AbcEYDVz (ORCPT <rfc822;w@1wt.eu>);
	Tue, 24 May 2016 23:21:55 -0400
Received: from zeniv.linux.org.uk ([195.92.253.2]:41946 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752237AbcEYDVy (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 24 May 2016 23:21:54 -0400
Date: Wed, 25 May 2016 04:21:49 +0100
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Matthew McClintock <mmcclint@codeaurora.org>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: Regression in 4.6.0-git - bisected to commit dd254f5a382c
Message-ID: <20160525032148.GD14480@ZenIV.linux.org.uk>
References: <5744A899.70503@lwfinger.net>
 <3988EB49-F17D-452B-A1AD-F202265B1BCA@codeaurora.org>
 <5744AD31.4090808@lwfinger.net>
 <2D6D38D9-FE06-4115-8FB2-48CB2FB19809@codeaurora.org>
 <20160524234133.GA14480@ZenIV.linux.org.uk>
 <1CDF0CFA-CCD2-440A-B956-2787BD8F2C4F@codeaurora.org>
 <20160525011036.GB14480@ZenIV.linux.org.uk>
 <52EE493C-26FF-4050-BF6F-E2346147378F@codeaurora.org>
 <20160525012805.GC14480@ZenIV.linux.org.uk>
 <20D5CE99-E85C-4D4A-97C0-7BD743FF92CD@codeaurora.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20D5CE99-E85C-4D4A-97C0-7BD743FF92CD@codeaurora.org>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, May 24, 2016 at 09:06:03PM -0500, Matthew McClintock wrote:
> 
> > On May 24, 2016, at 8:28 PM, Al Viro <viro@ZenIV.linux.org.uk> wrote:
> > 
> > The next obvious question is which binary it is and what's the return
> > address to userland; make that
> > 	if (!size)
> > 		printk(KERN_ERR "crap in %s[%x]",
> > 			current->comm,
> > 			current_pt_regs()->rip);
> > (in the same place)
> 
> This is an ARM board, no rip. Quick log without, can re-run again later tonight or maybe tomorrow:

probably ->ARM_pc, then...

> [    8.008054] crap in udevd

Indeed.  Which version of that Fine Piece Of Software is it?  Again, the
kernel-side bug is real and needs fixing, but "udev does something bogus"
is not surprising in the slightest...