From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752172AbcEXAS7 (ORCPT ); Mon, 23 May 2016 20:18:59 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:52082 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750800AbcEXAS6 (ORCPT ); Mon, 23 May 2016 20:18:58 -0400 Date: Tue, 24 May 2016 01:18:54 +0100 From: Al Viro To: Larry Finger Cc: LKML Subject: Re: Regression in 4.6.0-git - bisected to commit dd254f5a382c Message-ID: <20160524001854.GW14480@ZenIV.linux.org.uk> References: <57437683.30008@lwfinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57437683.30008@lwfinger.net> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 23, 2016 at 04:30:43PM -0500, Larry Finger wrote: > The mainline kernels past 4.6.0 fail hang when logging in. There are no > error messages, and the machine seems to be waiting for some event that > never happens. > > The problem has been bisected to commit dd254f5a382c ("fold checks into > iterate_and_advance()"). The bisection has been verified. > > The problem is the call from iov_iter_advance(). When I reinstated the old > macro with a new name and used it in that routine, the system works. > Obviously, the call that seems to be incorrect has some benefits. My > quich-and-dirty patch is attached. > > I will be willing to test any patch you prepare. Hangs where and how? A reproducer, please... This is really weird - the only change there is in the cases when * iov_iter_advance(i, n) is called with n greater than the remaining amount. It's a bug, plain and simple - old variant would've been left in seriously buggered state and at the very least we want to catch any such places for the sake of backports * iov_iter_advance(i, 0) - both old and new code leave *i unchanged, but the old one dereferences i->iov[0], which be pointing beyond the end of array by that point. The value read from there was not used by the old code, at that. Could you slap WARN_ON(size > i->count) in the very beginning of iov_iter_advance() (the mainline variant) and see what triggers on your reproducer?