[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjSjuDrS9gc191PTEDDow7vHy6Kd3DKDaG+KVH0NQ3v=w@mail.gmail.com>
Date: Wed, 28 Feb 2024 14:57:00 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Tong Tiangen <tongtiangen@...wei.com>
Cc: David Howells <dhowells@...hat.com>, Jens Axboe <axboe@...nel.dk>,
Al Viro <viro@...iv.linux.org.uk>, Christoph Hellwig <hch@....de>,
Christian Brauner <christian@...uner.io>, David Laight <David.Laight@...lab.com>,
Matthew Wilcox <willy@...radead.org>, Jeff Layton <jlayton@...nel.org>, linux-fsdevel@...r.kernel.org,
linux-block@...r.kernel.org, linux-mm@...ck.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, Kefeng Wang <wangkefeng.wang@...wei.com>
Subject: Re: [bug report] dead loop in generic_perform_write() //Re: [PATCH v7
07/12] iov_iter: Convert iterate*() to inline funcs
On Wed, 28 Feb 2024 at 13:21, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Hmm. If the copy doesn't succeed and make any progress at all, then
> the code in generic_perform_write() after the "goto again"
>
> //[4]
> if (unlikely(fault_in_iov_iter_readable(i, bytes) ==
> bytes)) {
>
> should break out of the loop.
Ahh. I see the problem. Or at least part of it.
The iter is an ITER_BVEC.
And fault_in_iov_iter_readable() "knows" that an ITER_BVEC cannot
fail. Because obviously it's a kernel address, so no user page fault.
But for the machine check case, ITER_BVEC very much can fail.
This should never have worked in the first place.
What a crock.
Do we need to make iterate_bvec() always succeed fully, and make
copy_mc_to_kernel() zero out the end?
Linus
Powered by blists - more mailing lists