From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965409AbcIPUDo (ORCPT ); Fri, 16 Sep 2016 16:03:44 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:58168 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965377AbcIPUDX (ORCPT ); Fri, 16 Sep 2016 16:03:23 -0400 Date: Fri, 16 Sep 2016 21:03:20 +0100 From: Al Viro To: Guenter Roeck Cc: linux-kernel@vger.kernel.org, Yoshinori Sato , linux-sh@vger.kernel.org, Rich Felker Subject: Re: Runtime failure running sh:qemu in -next due to 'sh: fix copy_from_user()' Message-ID: <20160916200320.GZ2356@ZenIV.linux.org.uk> References: <20160916191218.GA12104@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160916191218.GA12104@roeck-us.net> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 16, 2016 at 12:12:18PM -0700, Guenter Roeck wrote: > Hi, > > I see the following runtime failure when running a 'sh' image with qemu in -next. > > [ ... ] > > sd 0:0:0:0: [sda] Attached SCSI disk > EXT2-fs (sda): warning: mounting unchecked fs, running e2fsck is recommended > VFS: Mounted root (ext2 filesystem) on device 8:0. > Freeing unused kernel memory: 124K (8c48a000 - 8c4a9000) > This architecture does not have kernel memory protection. > random: fast init done > Starting logging: OK > usb 1-1: new full-speed USB device number 2 using sm501-usb > Initializing random number generator... done. > Starting network... > ip: OVERRUN: Invalid argument > ip: OVERRUN: Bad address > ip: OVERRUN: Bad address > ip: OVERRUN: Bad address > ip: OVERRUN: Bad address > [repeats until the test aborts] > > Bisect points to commit 6e050503a150 ("sh: fix copy_from_user()"). Bisect log is > attached. BTW, could you post your .config and information about your userland? E.g. is that ip(8) a busybox one, etc. If it's busybox, this smells like EINVAL and EFAULT resp. coming from recvmsg() on netlink sockets, with nothing extraordinary in iovecs, AFAICS...