Message ID | 20230323100204.0917cecf@canb.auug.org.au |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:604a:0:0:0:0:0 with SMTP id j10csp2619336wrt; Wed, 22 Mar 2023 16:11:01 -0700 (PDT) X-Google-Smtp-Source: AK7set+REGgMDeW9Cc9j8TcU8tPzOvjx+NNXXkIHwfQ7bVvBgffhvAgNlglRbYUjFWWSjJUfwqOg X-Received: by 2002:a17:907:6e8e:b0:923:c55d:efd2 with SMTP id sh14-20020a1709076e8e00b00923c55defd2mr10695570ejc.68.1679526661264; Wed, 22 Mar 2023 16:11:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679526661; cv=none; d=google.com; s=arc-20160816; b=LoWvfG3ZAkzdYhNXwlOLdokNN1KTOJciPQ5scDJtZDz+WDs4K+akIUemPhxGk1HzQa zSL0tsqWwFep1VN32K+Hc/nknws5Wq5GV3IE3B1uImO41E1UIA5T2HfOheB1NbVFZ0Hf g50SB5lzYOF6avUkltuGra6ytq/ajirsSFbbvSStkhLglt5h4TL5h8QFfcOvvVLjZgCW mPIYCnDr996F0h4D3eeEAoO0GhNoeg7Yz95yVzA7Fnp/pA8LYbdvwvcwrf/orOH64Y8o sxzIAEPvkouLQPiX+Ru712p3r8X+TFXR6UPPOhhKhBFRPgunwBjAcdBYL3ZRZeauklVE lTgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:subject:cc:to:from:date :dkim-signature; bh=rsjvqVJpvHhn9wRdeV5pStst41E897IWLfvCHN97eSk=; b=hbrTgfNI41ePmUx3U2JW/6ikXx8n2ivzM1+EhLlq0uhXd57wGclxSYYCkKmn53OYPs y3dorSPzw4qgi0Q+F+t5pmcNI9Xo/22VWAS4MUCZA7icn28IqEXdM99Qb2viWhpoKoWW 8EShfuHYHg/tf2GwS0i9nPxkSAWG/dzZKT1NgelMAJghoqqIldX3TAp5ShjuvXQacCEN QGkt2ZtFcf1gdqQvSz5aTWKElMjfZaIbfn3fLZiz3yVkRkwmJDMQ0yvrCYM4E+c5moBE NEt+nLu/LZe/AZjcZ2jngIkaUPiZlvJtK5SOorEf3YhUS7fe5WUiR1BKOdBvMkRytk7m mH4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@canb.auug.org.au header.s=201702 header.b="b/1l+aN6"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=auug.org.au Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i19-20020a170906851300b008ccf9fd2186si14849748ejx.867.2023.03.22.16.10.34; Wed, 22 Mar 2023 16:11:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@canb.auug.org.au header.s=201702 header.b="b/1l+aN6"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=auug.org.au Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229529AbjCVXCL (ORCPT <rfc822;ezelljr.billy@gmail.com> + 99 others); Wed, 22 Mar 2023 19:02:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229497AbjCVXCJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 22 Mar 2023 19:02:09 -0400 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7AB7B6588; Wed, 22 Mar 2023 16:02:07 -0700 (PDT) Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4PhkWK5Wy0z4wgv; Thu, 23 Mar 2023 10:02:05 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canb.auug.org.au; s=201702; t=1679526126; bh=rsjvqVJpvHhn9wRdeV5pStst41E897IWLfvCHN97eSk=; h=Date:From:To:Cc:Subject:From; b=b/1l+aN6FdtzsGnJeU4vZ6zfMymHuKX1qf4TrxKM93Q1oH0DApKA9+8YbQlCYOcP8 XUqBXrZhkanYla8b7fc8hw2YrwE6BQiZImi7723RXJU2SKTCgZplo2koP6LVFL9hqc CfxZxGcuGxXgFqsi2DEyZs88cXLhesPj8hdiqyuPPB5EvM48fIouujekuu+TwjadFc AYWiZ8IlRYLuySQmur8TpFcQ7aOjSzFV5y5NvzHV096sQfWb8c4I/PXPLtIzKI9J/F vCB00TtLdLu8X5hXAQoCyBAHqIYLhtk0xrtd+DhCeWMIRTl5iBVT3fX4gxV7q77N5s bBnFoVxRB0zrw== Date: Thu, 23 Mar 2023 10:02:04 +1100 From: Stephen Rothwell <sfr@canb.auug.org.au> To: Jens Axboe <axboe@kernel.dk>, Andrew Morton <akpm@linux-foundation.org> Cc: David Howells <dhowells@redhat.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux Next Mailing List <linux-next@vger.kernel.org>, Lorenzo Stoakes <lstoakes@gmail.com> Subject: linux-next: manual merge of the block tree with the mm tree Message-ID: <20230323100204.0917cecf@canb.auug.org.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/F_Hox9gVbvq./rE=fe37W1n"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,SPF_HELO_PASS,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761111348211612566?= X-GMAIL-MSGID: =?utf-8?q?1761111348211612566?= |
Series |
linux-next: manual merge of the block tree with the mm tree
|
|
Commit Message
Stephen Rothwell
March 22, 2023, 11:02 p.m. UTC
Hi all, Today's linux-next merge of the block tree got a conflict in: lib/iov_iter.c between commit: c4cf24ce34b7 ("iov_iter: add copy_page_to_iter_atomic()") from the mm tree and commit: a53f5dee3448 ("iov_iter: Kill ITER_PIPE") from the block tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts.
Comments
Stephen Rothwell <sfr@canb.auug.org.au> wrote: > + if (unlikely(iov_iter_is_pipe(i))) { > + copied = copy_page_to_iter_pipe(page, offset, bytes, i); > + goto out; > + } This bit would need to be removed from copy_page_to_iter_atomic() as the two functions it calls should be removed by the patch in the block tree. David
On 3/22/23 5:13 PM, David Howells wrote: > Stephen Rothwell <sfr@canb.auug.org.au> wrote: > >> + if (unlikely(iov_iter_is_pipe(i))) { >> + copied = copy_page_to_iter_pipe(page, offset, bytes, i); >> + goto out; >> + } > > This bit would need to be removed from copy_page_to_iter_atomic() as the two > functions it calls should be removed by the patch in the block tree. Maybe it'd be better to consolidate rather than split the changes over two trees?
On Wed, 22 Mar 2023 17:15:48 -0600 Jens Axboe <axboe@kernel.dk> wrote: > On 3/22/23 5:13 PM, David Howells wrote: > > Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > >> + if (unlikely(iov_iter_is_pipe(i))) { > >> + copied = copy_page_to_iter_pipe(page, offset, bytes, i); > >> + goto out; > >> + } > > > > This bit would need to be removed from copy_page_to_iter_atomic() as the two > > functions it calls should be removed by the patch in the block tree. > > Maybe it'd be better to consolidate rather than split the changes over > two trees? fyi, Lorenzo has sent out v7 of this series. I'll be pushing this in an hour or so. After which I suggest Stephen removes those (now) two lines and sends out one of his "build fix" emails which can be the basis for Linus's resolution. Or I can just steal "iov_iter: Kill ITER_PIPE"... From: Lorenzo Stoakes <lstoakes@gmail.com> Subject: iov_iter: add copy_page_to_iter_nofault() Date: Wed, 22 Mar 2023 18:57:03 +0000 Provide a means to copy a page to user space from an iterator, aborting if a page fault would occur. This supports compound pages, but may be passed a tail page with an offset extending further into the compound page, so we cannot pass a folio. This allows for this function to be called from atomic context and _try_ to user pages if they are faulted in, aborting if not. The function does not use _copy_to_iter() in order to not specify might_fault(), this is similar to copy_page_from_iter_atomic(). This is being added in order that an iteratable form of vread() can be implemented while holding spinlocks. Link: https://lkml.kernel.org/r/19734729defb0f498a76bdec1bef3ac48a3af3e8.1679511146.git.lstoakes@gmail.com Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Baoquan He <bhe@redhat.com> Cc: David Hildenbrand <david@redhat.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Liu Shixin <liushixin2@huawei.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- --- a/include/linux/uio.h~iov_iter-add-copy_page_to_iter_nofault +++ a/include/linux/uio.h @@ -173,6 +173,8 @@ static inline size_t copy_folio_to_iter( { return copy_page_to_iter(&folio->page, offset, bytes, i); } +size_t copy_page_to_iter_nofault(struct page *page, unsigned offset, + size_t bytes, struct iov_iter *i); static __always_inline __must_check size_t copy_to_iter(const void *addr, size_t bytes, struct iov_iter *i) --- a/lib/iov_iter.c~iov_iter-add-copy_page_to_iter_nofault +++ a/lib/iov_iter.c @@ -172,6 +172,18 @@ static int copyout(void __user *to, cons return n; } +static int copyout_nofault(void __user *to, const void *from, size_t n) +{ + long res; + + if (should_fail_usercopy()) + return n; + + res = copy_to_user_nofault(to, from, n); + + return res < 0 ? n : res; +} + static int copyin(void *to, const void __user *from, size_t n) { size_t res = n; @@ -734,6 +746,42 @@ size_t copy_page_to_iter(struct page *pa } EXPORT_SYMBOL(copy_page_to_iter); +size_t copy_page_to_iter_nofault(struct page *page, unsigned offset, size_t bytes, + struct iov_iter *i) +{ + size_t res = 0; + + if (!page_copy_sane(page, offset, bytes)) + return 0; + if (WARN_ON_ONCE(i->data_source)) + return 0; + if (unlikely(iov_iter_is_pipe(i))) + return copy_page_to_iter_pipe(page, offset, bytes, i); + page += offset / PAGE_SIZE; // first subpage + offset %= PAGE_SIZE; + while (1) { + void *kaddr = kmap_local_page(page); + size_t n = min(bytes, (size_t)PAGE_SIZE - offset); + + iterate_and_advance(i, n, base, len, off, + copyout_nofault(base, kaddr + offset + off, len), + memcpy(base, kaddr + offset + off, len) + ) + kunmap_local(kaddr); + res += n; + bytes -= n; + if (!bytes || !n) + break; + offset += n; + if (offset == PAGE_SIZE) { + page++; + offset = 0; + } + } + return res; +} +EXPORT_SYMBOL(copy_page_to_iter_nofault); + size_t copy_page_from_iter(struct page *page, size_t offset, size_t bytes, struct iov_iter *i) {
Hi all, On Wed, 22 Mar 2023 16:26:38 -0700 Andrew Morton <akpm@linux-foundation.org> wrote: > > fyi, Lorenzo has sent out v7 of this series. I'll be pushing this in > an hour or so. After which I suggest Stephen removes those (now) two > lines and sends out one of his "build fix" emails which can be the > basis for Linus's resolution. I have not picked up v7 (I will get that tomorrow), but I have gone back in today's tree and changed the merge resolution to be as below.
Andrew Morton <akpm@linux-foundation.org> wrote:
> Or I can just steal "iov_iter: Kill ITER_PIPE"...
You'd need to steal the eight patches before it too.
https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/log/?h=for-6.4/splice
iov_iter: Kill ITER_PIPE
cifs: Use generic_file_splice_read()
splice: Do splice read from a file without using ITER_PIPE
tty, proc, kernfs, random: Use direct_splice_read()
coda: Implement splice-read
overlayfs: Implement splice-read
shmem: Implement splice-read
splice: Make do_splice_to() generic and export it
splice: Clean up direct_splice_read() a bit
David
On 3/22/23 5:26?PM, Andrew Morton wrote: > On Wed, 22 Mar 2023 17:15:48 -0600 Jens Axboe <axboe@kernel.dk> wrote: > >> On 3/22/23 5:13?PM, David Howells wrote: >>> Stephen Rothwell <sfr@canb.auug.org.au> wrote: >>> >>>> + if (unlikely(iov_iter_is_pipe(i))) { >>>> + copied = copy_page_to_iter_pipe(page, offset, bytes, i); >>>> + goto out; >>>> + } >>> >>> This bit would need to be removed from copy_page_to_iter_atomic() as the two >>> functions it calls should be removed by the patch in the block tree. >> >> Maybe it'd be better to consolidate rather than split the changes over >> two trees? > > fyi, Lorenzo has sent out v7 of this series. I'll be pushing this in > an hour or so. After which I suggest Stephen removes those (now) two > lines and sends out one of his "build fix" emails which can be the > basis for Linus's resolution. > > Or I can just steal "iov_iter: Kill ITER_PIPE"... Or how about we just make sure to queue up items that touch them same stuff in the same tree? I've already had this queued for a week, and seems pretty silly to shuffle things around because some thing got posted in 4 iterations today and then queued up right after. Plus the build is now broken, so maybe a bit more diligence would be required here than the drive-by-merging.
diff --cc lib/iov_iter.c index 48ca1c5dfc04,fad95e4cf372..000000000000 --- a/lib/iov_iter.c