From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754489AbcEYO2R (ORCPT ); Wed, 25 May 2016 10:28:17 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:33950 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752416AbcEYO2O (ORCPT ); Wed, 25 May 2016 10:28:14 -0400 Subject: Re: Regression in 4.6.0-git - bisected to commit dd254f5a382c To: Al Viro , Matthew McClintock References: <57437683.30008@lwfinger.net> <20160524001854.GW14480@ZenIV.linux.org.uk> <57447CE1.9020207@lwfinger.net> <6E57F7A4-59B0-46EA-9FFF-D0A4BA2D8E51@codeaurora.org> <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> <20160525062434.GE14480@ZenIV.linux.org.uk> Cc: LKML From: Larry Finger Message-ID: <5745B67B.6040901@lwfinger.net> Date: Wed, 25 May 2016 09:28:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160525062434.GE14480@ZenIV.linux.org.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/25/2016 01:24 AM, Al Viro wrote: > On Wed, May 25, 2016 at 12:41:33AM +0100, Al Viro wrote: >> On Tue, May 24, 2016 at 05:31:51PM -0500, Matthew McClintock wrote: >>> >>>> On May 24, 2016, at 2:36 PM, Larry Finger wrote: >>>> >>>> On 05/24/2016 02:25 PM, Matthew McClintock wrote: >>>>> On May 24, 2016, at 2:16 PM, Larry Finger wrote: >>>>>> >>>>>> On 05/24/2016 02:13 PM, Matthew McClintock wrote: >>>>>>> I’m seeing this too, same commit if you want another person to test/reproduce. >>>>>> >>>>>> If you do a pull today, does that fix your problem? >>>>> >>>>> Hmm, no. Which commit am I looking for? I’m on a56f489502e28caac56c8a0735549740f0ae0711 >>>> >>>> Commit 84787c572d402644dca4874aba73324d9f8e3948 is working for me. I have a fixup in lib/iov_iter.c with a dump_stack() call if the fixup was needed. That dump is not triggered. I do not seem to have a56f489502e yet. >>> >>> Still seeing the issue on top of tree and the above commit. Re-ran bisection just to be sure. >> >> Guys, the bug is real and definitely still there. >> char c; >> struct iovec v[2] = {{&c, 0}, {&c, 1}}; >> readv(0, v, 2); >> will trigger it just fine with stdin on e.g. tty. It needs fixing and I'll >> post a fix as soon as it gets through the local testing. In the meanwhile, >> I would like to know what in userland is doing that kind of call - kernel >> certainly shouldn't end up in an infinite loop on that, but it's bloody odd >> and I wonder what's going on in userland code to result in that call. >> >> Again, I understand what's going on kernel-side; the only tricky part is how >> to fix it without bringing the nasal daemons back. I think I have a solution >> and I'm going to post it tonight if it survives the local beating. In any >> case, the testcase above deserves being added to LTP - it's a real regression. > > FWIW, the reproducer is > #include > main() > { > char c; > struct iovec v[2] = {{&c,0},{&c,1}}; > readv(0, v, 2); > } > ran with stdin from tty. Fix for that is simply > > diff --git a/lib/iov_iter.c b/lib/iov_iter.c > index 28cb431..0cd5227 100644 > --- a/lib/iov_iter.c > +++ b/lib/iov_iter.c > @@ -101,7 +101,7 @@ > #define iterate_and_advance(i, n, v, I, B, K) { \ > if (unlikely(i->count < n)) \ > n = i->count; \ > - if (n) { \ > + if (i->count) { \ > size_t skip = i->iov_offset; \ > if (unlikely(i->type & ITER_BVEC)) { \ > const struct bio_vec *bvec; \ > > Could you see if your reproducer is fixed by that? Yes, that change fixes my reproducer. If this is the final fix, you may add a Tested-by: to the commit. Larry >