linux-kernel - Re: next-20130117 - kernel BUG with aio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 05 Feb 2013 12:48:23 -0500
From:	Valdis.Kletnieks@...edu
To:	Kent Overstreet <koverstreet@...gle.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Hillf Danton <dhillf@...il.com>,
	Benjamin LaHaise <bcrl@...ck.org>,
	linux-kernel@...r.kernel.org, linux-aio@...ck.org
Subject: Re: next-20130117 - kernel BUG with aio

On Tue, 05 Feb 2013 09:20:15 -0800, Kent Overstreet said:
> On Tue, Feb 05, 2013 at 10:53:00AM -0500, Valdis.Kletnieks@...edu wrote:
> > On Thu, 31 Jan 2013 16:37:27 -0800, Kent Overstreet said:
> > > On Thu, Jan 31, 2013 at 01:59:52PM -0800, Andrew Morton wrote:
> > > > Did this get fixed?
> >
> > > With the patches I sent you, yes - not seeing a new linux-next tree yet?
> >
> > Well, it's a mixed bag at my end.  Finally got a chance to do some more
> > testing, and:
> >
> > 1) next-20130128 didn't show anything in dmesg, but my VirtualBox Windows 7
> > images appear to livelock on the way up - the Windows throbber would keep
> > going, but it never made any actual progress towards booting. (Part of the
> > delay was fixing a next-20121224 environment, and then discovering it
> > took Windows *two* reboot cycles to get its act back together after getting
> > into that hung state).
> >
> > 2_ next-20130128 plus the following 3 patches:
> >
> > Subject: [PATCH 1/3] aio: Fix a null pointer deref in batch_complete_aio
> > Subject: [PATCH 3/3] aio-use-cancellation-list-lazily-fix
> > Subject: [PATCH 2/3] aio-kill-ki_retry-fix-fix
>
> The "smoosh struct kiocb" patch also needs to be dropped. That causes
> aio_rw_vect_retry() to check ki_nbytes/ki_left after they've been
> overwritten by aio_complete(), which causes it to return an error when
> it shouldn't have, which causes aio_run_iocb() to double complete the
> iocb causing put_reqs_available() to be called twice and the count
> screwed up.

Unfortunately, that's not a clean slam-dunk revert:

[/usr/src/linux-next] patch -p1 -R --dry-run < ~/Downloads/32-32-aio-Smoosh-struct-kiocb.patch
checking file fs/aio.c
Hunk #1 FAILED at 570.
Hunk #2 FAILED at 634.
Hunk #3 FAILED at 1246.
3 out of 3 hunks FAILED
checking file include/linux/aio.h
Hunk #1 succeeded at 31 (offset 11 lines).

Looks like the above 3 patches introduce conflicts. Not sure what the proper
resolution is for some of it. For the first hunk, the smoosh patch has near
line 590:

-       atomic_set(&req->ki_users, 1);
+       memset(req, 0, offsetof(struct kiocb, ki_ctx));
        req->ki_ctx = ctx;
+       atomic_set(&req->ki_users, 1);
        return req;

but after the 3 patches, I have:

        memset(req, 0, offsetof(struct kiocb, ki_ctx));
        req->ki_ctx = ctx;
        atomic_set(&req->ki_users, 2);
        return req;

Easy to fix, except that '2' is too magical for me to understand, so I'm
not sure I want to smash it to a 1 to make the revert easier. :)

Content of type "application/pgp-signature" skipped