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 <larry.fin...@lwfinger.net>
> > > wrote:
> > >
> > > On 05/24/2016 02:25 PM, Matthew McClintock wrote:
> > >> On May 24, 2016, at 2:16 PM, Larry Finger <larry.fin...@lwfinger.net>
> > >> 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 <sys/uio.>
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?
