| Message ID | 20210514100106.3404011-1-arnd@kernel.org |
|---|---|
| Headers | show |
| Series | Unify asm/unaligned.h around struct helper | expand |
On Fri, May 14, 2021 at 3:02 AM Arnd Bergmann <arnd@kernel.org> wrote: > > I've included this version in the asm-generic tree for 5.14 already, > addressing the few issues that were pointed out in the RFC. If there > are any remaining problems, I hope those can be addressed as follow-up > patches. This continues to look great to me, and now has the even simpler remaining implementation. I'd be tempted to just pull it in for 5.13, but I guess we don't actually have any _outstanding_ bug in this area (the bug was in our zlib code, required -O3 to trigger, has been fixed now, and the biggy case didn't even use "get_unaligned()"). So I guess your 5.14 timing is the right thing to do. Linus
On 5/14/21 10:32 AM, Linus Torvalds wrote: > On Fri, May 14, 2021 at 3:02 AM Arnd Bergmann <arnd@kernel.org> wrote: >> I've included this version in the asm-generic tree for 5.14 already, >> addressing the few issues that were pointed out in the RFC. If there >> are any remaining problems, I hope those can be addressed as follow-up >> patches. > This continues to look great to me, and now has the even simpler > remaining implementation. > > I'd be tempted to just pull it in for 5.13, but I guess we don't > actually have any _outstanding_ bug in this area (the bug was in our > zlib code, required -O3 to trigger, has been fixed now, Wasn't the new zlib code slated for 5.14. I don't see it in your master yet > and the biggy > case didn't even use "get_unaligned()"). Indeed this series is sort of orthogonal to that bug, but IMO that bug still exists in 5.13 for -O3 build, granted that is not enabled for !ARC. -Vineet > > So I guess your 5.14 timing is the right thing to do. > > Linus
On Fri, May 14, 2021 at 11:52 AM Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote: > > Wasn't the new zlib code slated for 5.14. I don't see it in your master yet You're right, I never actually committed it, since it was specific to ARC and -O3 and I wasn't entirely happy with the amount of testing it got (with Heiko pointing out that the s390 stuff needed more fixes for the change). So in fact it's not even queued up for 5.14 due to this all, I just dropped it. > > and the biggy > > case didn't even use "get_unaligned()"). > > Indeed this series is sort of orthogonal to that bug, but IMO that bug > still exists in 5.13 for -O3 build, granted that is not enabled for !ARC. Right, the zlib bug is still there. But Arnd's series wouldn't even fix it: right now inffast has its own - ugly and slow - special 2-byte-only version of "get_unaligned()", called "get_unaligned16()". And because it's ugly and slow, it's not actually used for CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS. Vineet - maybe the fix is to not take my patch to update to a newer zlib, but to just fix inffast to use the proper get_unaligned(). Then Arnd's series _would_ actually fix all this.. Linus
On 5/14/21 12:22 PM, Linus Torvalds wrote: > On Fri, May 14, 2021 at 11:52 AM Vineet Gupta > <Vineet.Gupta1@synopsys.com> wrote: >> Wasn't the new zlib code slated for 5.14. I don't see it in your master yet > You're right, I never actually committed it, since it was specific to > ARC and -O3 Well, not really, the issue manifested in ARC O3 testing, but I showed the problem existed for arm64 gcc too. > and I wasn't entirely happy with the amount of testing it > got (with Heiko pointing out that the s390 stuff needed more fixes for > the change). With his addon patch everything seemed hunky dory. > The patch below is required on top of your patch to make it compile > for s390 as well. > Tested with kernel image decompression, and also btrfs with file > compression; both software and hardware compression. > Everything seems to work. > So in fact it's not even queued up for 5.14 due to this all, I just dropped it. But Why. Can't we throw it in linux-next for 5.14. I promise to test it - and will likely hit any corner cases. Also for the time being we could force just that file/files to build for -O3 to stress test the aspects that were fragile. >>> and the biggy >>> case didn't even use "get_unaligned()"). >> Indeed this series is sort of orthogonal to that bug, but IMO that bug >> still exists in 5.13 for -O3 build, granted that is not enabled for !ARC. > Right, the zlib bug is still there. > > But Arnd's series wouldn't even fix it: right now inffast has its own > - ugly and slow - special 2-byte-only version of "get_unaligned()", > called "get_unaligned16()". I know that's why said they are orthogonal. > And because it's ugly and slow, it's not actually used for > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS. > > Vineet - maybe the fix is to not take my patch to update to a newer > zlib, but to just fix inffast to use the proper get_unaligned(). Then > Arnd's series _would_ actually fix all this.. OK if you say so. -Vineet
On Fri, May 14, 2021 at 12:45 PM Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote: > > Well, not really, the issue manifested in ARC O3 testing, but I showed > the problem existed for arm64 gcc too. .. but not with a supported kernel configuration. > > So in fact it's not even queued up for 5.14 due to this all, I just dropped it. > > But Why. I just didn't have time to deal with it during the merge window. If you keep it alive, that's all fine and good. Linus
From: Arnd Bergmann <arnd@arndb.de> The get_unaligned()/put_unaligned() helpers are traditionally architecture specific, with the two main variants being the "access-ok.h" version that assumes unaligned pointer accesses always work on a particular architecture, and the "le-struct.h" version that casts the data to a byte aligned type before dereferencing, for architectures that cannot always do unaligned accesses in hardware. Based on the discussion linked below, it appears that the access-ok version is not realiable on any architecture, but the struct version probably has no downsides. This series changes the code to use the same implementation on all architectures, addressing the few exceptions separately. I've included this version in the asm-generic tree for 5.14 already, addressing the few issues that were pointed out in the RFC. If there are any remaining problems, I hope those can be addressed as follow-up patches. Arnd Link: https://lore.kernel.org/lkml/75d07691-1e4f-741f-9852-38c0b4f520bc@synopsys.com/ Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 Link: https://lore.kernel.org/lkml/20210507220813.365382-14-arnd@kernel.org/ Link: git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git unaligned-rework-v2 Arnd Bergmann (13): asm-generic: use asm-generic/unaligned.h for most architectures openrisc: always use unaligned-struct header sh: remove unaligned access for sh4a m68k: select CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS powerpc: use linux/unaligned/le_struct.h on LE power7 asm-generic: unaligned: remove byteshift helpers asm-generic: unaligned always use struct helpers partitions: msdos: fix one-byte get_unaligned() apparmor: use get_unaligned() only for multi-byte words mwifiex: re-fix for unaligned accesses netpoll: avoid put_unaligned() on single character asm-generic: uaccess: 1-byte access is always aligned asm-generic: simplify asm/unaligned.h arch/alpha/include/asm/unaligned.h | 12 -- arch/arm/include/asm/unaligned.h | 27 --- arch/ia64/include/asm/unaligned.h | 12 -- arch/m68k/Kconfig | 1 + arch/m68k/include/asm/unaligned.h | 26 --- arch/microblaze/include/asm/unaligned.h | 27 --- arch/mips/crypto/crc32-mips.c | 2 +- arch/openrisc/include/asm/unaligned.h | 47 ----- arch/parisc/include/asm/unaligned.h | 6 +- arch/powerpc/include/asm/unaligned.h | 22 --- arch/sh/include/asm/unaligned-sh4a.h | 199 -------------------- arch/sh/include/asm/unaligned.h | 13 -- arch/sparc/include/asm/unaligned.h | 11 -- arch/x86/include/asm/unaligned.h | 15 -- arch/xtensa/include/asm/unaligned.h | 29 --- block/partitions/ldm.h | 2 +- block/partitions/msdos.c | 2 +- drivers/net/wireless/marvell/mwifiex/pcie.c | 10 +- include/asm-generic/uaccess.h | 4 +- include/asm-generic/unaligned.h | 141 +++++++++++--- include/linux/unaligned/access_ok.h | 68 ------- include/linux/unaligned/be_byteshift.h | 71 ------- include/linux/unaligned/be_memmove.h | 37 ---- include/linux/unaligned/be_struct.h | 37 ---- include/linux/unaligned/generic.h | 115 ----------- include/linux/unaligned/le_byteshift.h | 71 ------- include/linux/unaligned/le_memmove.h | 37 ---- include/linux/unaligned/le_struct.h | 37 ---- include/linux/unaligned/memmove.h | 46 ----- net/core/netpoll.c | 4 +- security/apparmor/policy_unpack.c | 2 +- 31 files changed, 131 insertions(+), 1002 deletions(-) delete mode 100644 arch/alpha/include/asm/unaligned.h delete mode 100644 arch/arm/include/asm/unaligned.h delete mode 100644 arch/ia64/include/asm/unaligned.h delete mode 100644 arch/m68k/include/asm/unaligned.h delete mode 100644 arch/microblaze/include/asm/unaligned.h delete mode 100644 arch/openrisc/include/asm/unaligned.h delete mode 100644 arch/powerpc/include/asm/unaligned.h delete mode 100644 arch/sh/include/asm/unaligned-sh4a.h delete mode 100644 arch/sh/include/asm/unaligned.h delete mode 100644 arch/sparc/include/asm/unaligned.h delete mode 100644 arch/x86/include/asm/unaligned.h delete mode 100644 arch/xtensa/include/asm/unaligned.h delete mode 100644 include/linux/unaligned/access_ok.h delete mode 100644 include/linux/unaligned/be_byteshift.h delete mode 100644 include/linux/unaligned/be_memmove.h delete mode 100644 include/linux/unaligned/be_struct.h delete mode 100644 include/linux/unaligned/generic.h delete mode 100644 include/linux/unaligned/le_byteshift.h delete mode 100644 include/linux/unaligned/le_memmove.h delete mode 100644 include/linux/unaligned/le_struct.h delete mode 100644 include/linux/unaligned/memmove.h