| Message ID | 20221230-kmap-x86-v1-0-15f1ecccab50@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | COVER: Remove memcpy_page_flushcache() | expand |
On 3/15/23 16:20, Ira Weiny wrote: > Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray > callbacks") removed the calls to memcpy_page_flushcache(). > > kmap_atomic() is deprecated and used in the x86 version of > memcpy_page_flushcache(). > > Remove the unnecessary memcpy_page_flushcache() call from all arch's. Hi Ira, Since the common code user is already gone these three patches seem quite independent. It seems like the right thing to do is have individual arch maintainers cherry pick their arch patch and carry it independently. Is there a compelling reason to have someone pick up and carry these all together that I'm missing?
Dave Hansen wrote: > On 3/15/23 16:20, Ira Weiny wrote: > > Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray > > callbacks") removed the calls to memcpy_page_flushcache(). > > > > kmap_atomic() is deprecated and used in the x86 version of > > memcpy_page_flushcache(). > > > > Remove the unnecessary memcpy_page_flushcache() call from all arch's. > > Hi Ira, > > Since the common code user is already gone these three patches seem > quite independent. It seems like the right thing to do is have > individual arch maintainers cherry pick their arch patch and carry it > independently. Yes. > > Is there a compelling reason to have someone pick up and carry these all > together that I'm missing? No reason. Would you like me to submit them individually? Sorry, submitting them separately crossed my mind when I wrote them but I kind of forgot as they were all on the same branch and I was waiting for after the merge window to submit them. Ira
Ira Weiny <ira.weiny@intel.com> writes: > Dave Hansen wrote: >> On 3/15/23 16:20, Ira Weiny wrote: >> > Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray >> > callbacks") removed the calls to memcpy_page_flushcache(). >> > >> > kmap_atomic() is deprecated and used in the x86 version of >> > memcpy_page_flushcache(). >> > >> > Remove the unnecessary memcpy_page_flushcache() call from all arch's. >> >> Hi Ira, >> >> Since the common code user is already gone these three patches seem >> quite independent. It seems like the right thing to do is have >> individual arch maintainers cherry pick their arch patch and carry it >> independently. > > Yes. > >> >> Is there a compelling reason to have someone pick up and carry these all >> together that I'm missing? > > No reason. Would you like me to submit them individually? I'll just grab the powerpc one from the thread, no need to resend. > Sorry, submitting them separately crossed my mind when I wrote them but I > kind of forgot as they were all on the same branch and I was waiting for > after the merge window to submit them. It's also much easier to run git-send-email HEAD^^^, rather than running it three separate times, let alone if it's a 20 patch series. I wonder if we could come up with some convention to indicate that a series is made up of independent patches, and maintainers are free to pick them individually - but still sent as a single series. cheers
+ Konstantin Michael Ellerman wrote: > Ira Weiny <ira.weiny@intel.com> writes: > > Dave Hansen wrote: > >> On 3/15/23 16:20, Ira Weiny wrote: > >> > Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray > >> > callbacks") removed the calls to memcpy_page_flushcache(). > >> > > >> > kmap_atomic() is deprecated and used in the x86 version of > >> > memcpy_page_flushcache(). > >> > > >> > Remove the unnecessary memcpy_page_flushcache() call from all arch's. > >> > >> Hi Ira, > >> > >> Since the common code user is already gone these three patches seem > >> quite independent. It seems like the right thing to do is have > >> individual arch maintainers cherry pick their arch patch and carry it > >> independently. > > > > Yes. > > > >> > >> Is there a compelling reason to have someone pick up and carry these all > >> together that I'm missing? > > > > No reason. Would you like me to submit them individually? > > I'll just grab the powerpc one from the thread, no need to resend. Thanks. > > > Sorry, submitting them separately crossed my mind when I wrote them but I > > kind of forgot as they were all on the same branch and I was waiting for > > after the merge window to submit them. > > It's also much easier to run git-send-email HEAD^^^, rather than running > it three separate times, let alone if it's a 20 patch series. Exactly. And I'm using b4 which would have forced me to create a separate branch for each of the patches to track. So I was keeping them around in a single branch to let 0day run after the merge window. Then I forgot about the idea of splitting them because b4 had it all packaged up nice! > > I wonder if we could come up with some convention to indicate that a > series is made up of independent patches, and maintainers are free to > pick them individually - but still sent as a single series. Maybe. But perhaps b4 could have a send option which would split them out? I'll see about adding an option to b4 but I've Cc'ed Konstantin as well for the idea. Thanks for picking this up! Ira > > cheers
Ira Weiny <ira.weiny@intel.com> writes: > + Konstantin > > Michael Ellerman wrote: >> Ira Weiny <ira.weiny@intel.com> writes: >> > Dave Hansen wrote: >> >> On 3/15/23 16:20, Ira Weiny wrote: >> >> > Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray >> >> > callbacks") removed the calls to memcpy_page_flushcache(). >> >> > >> >> > kmap_atomic() is deprecated and used in the x86 version of >> >> > memcpy_page_flushcache(). >> >> > >> >> > Remove the unnecessary memcpy_page_flushcache() call from all arch's. >> >> >> >> Hi Ira, >> >> >> >> Since the common code user is already gone these three patches seem >> >> quite independent. It seems like the right thing to do is have >> >> individual arch maintainers cherry pick their arch patch and carry it >> >> independently. >> > >> > Yes. >> > >> >> >> >> Is there a compelling reason to have someone pick up and carry these all >> >> together that I'm missing? >> > >> > No reason. Would you like me to submit them individually? >> >> I'll just grab the powerpc one from the thread, no need to resend. > > Thanks. > >> >> > Sorry, submitting them separately crossed my mind when I wrote them but I >> > kind of forgot as they were all on the same branch and I was waiting for >> > after the merge window to submit them. >> >> It's also much easier to run git-send-email HEAD^^^, rather than running >> it three separate times, let alone if it's a 20 patch series. > > Exactly. And I'm using b4 which would have forced me to create a separate > branch for each of the patches to track. So I was keeping them around in > a single branch to let 0day run after the merge window. Then I forgot > about the idea of splitting them because b4 had it all packaged up nice! > >> >> I wonder if we could come up with some convention to indicate that a >> series is made up of independent patches, and maintainers are free to >> pick them individually - but still sent as a single series. > > Maybe. But perhaps b4 could have a send option which would split them > out? I'll see about adding an option to b4 but I've Cc'ed Konstantin as > well for the idea. Yes you're right that's probably a better idea. b4 to the rescue! cheers
On Thu, Mar 16, 2023 at 09:16:34AM -0700, Ira Weiny wrote: > > It's also much easier to run git-send-email HEAD^^^, rather than running > > it three separate times, let alone if it's a 20 patch series. > > Exactly. And I'm using b4 which would have forced me to create a separate > branch for each of the patches to track. So I was keeping them around in > a single branch to let 0day run after the merge window. Then I forgot > about the idea of splitting them because b4 had it all packaged up nice! > > > > > I wonder if we could come up with some convention to indicate that a > > series is made up of independent patches, and maintainers are free to > > pick them individually - but still sent as a single series. > > Maybe. But perhaps b4 could have a send option which would split them > out? I'll see about adding an option to b4 but I've Cc'ed Konstantin as > well for the idea. Yes, I plan to introduce the concept of "bundles" in addition to "series". The distinction is that when you send a bundle, each patch is sent as individual submission and we generate the change-id for each patch. It's a bit more work to send a v2 of some patch (you have to do a "prep -n --from-thread <msgid>"), but it's not insurmountable and should help with queuing up individual patches for sending post merge-window, like in your case. -K
On Wed, 15 Mar 2023 16:20:53 -0700, Ira Weiny wrote: > Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray > callbacks") removed the calls to memcpy_page_flushcache(). > > kmap_atomic() is deprecated and used in the x86 version of > memcpy_page_flushcache(). > > Remove the unnecessary memcpy_page_flushcache() call from all arch's. > > [...] Applied arm64 patch to arm64 (for-next/mm), thanks! [3/3] arm: uaccess: Remove memcpy_page_flushcache() https://git.kernel.org/arm64/c/7cae569e6209 Cheers,
On Wed, 15 Mar 2023 16:20:53 -0700, Ira Weiny wrote: > Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray > callbacks") removed the calls to memcpy_page_flushcache(). > > kmap_atomic() is deprecated and used in the x86 version of > memcpy_page_flushcache(). > > Remove the unnecessary memcpy_page_flushcache() call from all arch's. > > [...] Patch 2 applied to powerpc/next. [2/3] powerpc: Remove memcpy_page_flushcache() https://git.kernel.org/powerpc/c/0398abca61482ae47a41ae8f2401338aea366327 cheers
Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray callbacks") removed the calls to memcpy_page_flushcache(). kmap_atomic() is deprecated and used in the x86 version of memcpy_page_flushcache(). Remove the unnecessary memcpy_page_flushcache() call from all arch's. Signed-off-by: Ira Weiny <ira.weiny@intel.com> --- Ira Weiny (3): x86, uaccess: Remove memcpy_page_flushcache() powerpc: Remove memcpy_page_flushcache() arm: uaccess: Remove memcpy_page_flushcache() arch/arm64/include/asm/uaccess.h | 2 -- arch/arm64/lib/uaccess_flushcache.c | 6 ------ arch/powerpc/include/asm/uaccess.h | 2 -- arch/powerpc/lib/pmem.c | 7 ------- arch/x86/include/asm/uaccess_64.h | 2 -- arch/x86/lib/usercopy_64.c | 9 --------- 6 files changed, 28 deletions(-) --- base-commit: 6015b1aca1a233379625385feb01dd014aca60b5 change-id: 20221230-kmap-x86-bfda7e1f07ee Best regards,