* Re: mmotm 2020-01-23-21-12 uploaded (efi) [not found] ` <1ccf26d9-9420-fc33-ad96-c3daedb1c487@infradead.org> @ 2020-01-25 7:06 ` Ard Biesheuvel 2020-01-28 6:15 ` Qian Cai 0 siblings, 1 reply; 6+ messages in thread From: Ard Biesheuvel @ 2020-01-25 7:06 UTC (permalink / raw) To: Randy Dunlap Cc: Andrew Morton, Mark Brown, linux-fsdevel, Linux Kernel Mailing List, Linux-MM, Linux-Next Mailing List, mhocko, mm-commits, Stephen Rothwell, Ard Biesheuvel, linux-efi On Sat, 25 Jan 2020 at 01:09, Randy Dunlap <rdunlap@infradead.org> wrote: > > On 1/23/20 9:13 PM, akpm@linux-foundation.org wrote: > > The mm-of-the-moment snapshot 2020-01-23-21-12 has been uploaded to > > > > http://www.ozlabs.org/~akpm/mmotm/ > > > > mmotm-readme.txt says > > > > README for mm-of-the-moment: > > > > http://www.ozlabs.org/~akpm/mmotm/ > > > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > > more than once a week. > > > > on x86_64: > CONFIG_X86_UV is not set/enabled. > > from linux-next.patch (in mmotm): > > ld: arch/x86/platform/efi/efi_64.o: in function `efi_set_virtual_address_map': > efi_64.c:(.init.text+0x11aa): undefined reference to `efi_uv1_memmap_phys_prolog' > ld: efi_64.c:(.init.text+0x123c): undefined reference to `efi_uv1_memmap_phys_epilog' > > > Full randconfig file is attached. > Should be fixed by https://lore.kernel.org/linux-efi/20200121093912.5246-1-ardb@kernel.org/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mmotm 2020-01-23-21-12 uploaded (efi) 2020-01-25 7:06 ` mmotm 2020-01-23-21-12 uploaded (efi) Ard Biesheuvel @ 2020-01-28 6:15 ` Qian Cai 2020-01-28 6:25 ` Dmitry Vyukov 0 siblings, 1 reply; 6+ messages in thread From: Qian Cai @ 2020-01-28 6:15 UTC (permalink / raw) To: Ard Biesheuvel Cc: Randy Dunlap, Andrew Morton, Mark Brown, linux-fsdevel, Linux Kernel Mailing List, Linux-MM, Linux-Next Mailing List, mhocko, mm-commits, Stephen Rothwell, Ard Biesheuvel, linux-efi, kasan-dev > On Jan 25, 2020, at 2:06 AM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > > Should be fixed by > > https://lore.kernel.org/linux-efi/20200121093912.5246-1-ardb@kernel.org/ Cc kasan-devel@ If everyone has to disable KASAN for the whole subdirectories like this, I am worried about we are losing testing coverage fairly quickly. Is there a bug in compiler? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mmotm 2020-01-23-21-12 uploaded (efi) 2020-01-28 6:15 ` Qian Cai @ 2020-01-28 6:25 ` Dmitry Vyukov 2020-01-28 7:33 ` Ard Biesheuvel 0 siblings, 1 reply; 6+ messages in thread From: Dmitry Vyukov @ 2020-01-28 6:25 UTC (permalink / raw) To: Qian Cai Cc: Ard Biesheuvel, Randy Dunlap, Andrew Morton, Mark Brown, linux-fsdevel, Linux Kernel Mailing List, Linux-MM, Linux-Next Mailing List, Michal Hocko, mm-commits, Stephen Rothwell, Ard Biesheuvel, linux-efi, kasan-dev On Tue, Jan 28, 2020 at 7:15 AM Qian Cai <cai@lca.pw> wrote: > > Should be fixed by > > > > https://lore.kernel.org/linux-efi/20200121093912.5246-1-ardb@kernel.org/ > > Cc kasan-devel@ > > If everyone has to disable KASAN for the whole subdirectories like this, I am worried about we are losing testing coverage fairly quickly. Is there a bug in compiler? My understanding is that this is invalid C code in the first place, no? It just happened to compile with some compilers, some options and probably only with high optimization level. There is a known, simple fix that is used throughout the kernel - provide empty static inline stub, or put whole calls under ifdef. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mmotm 2020-01-23-21-12 uploaded (efi) 2020-01-28 6:25 ` Dmitry Vyukov @ 2020-01-28 7:33 ` Ard Biesheuvel 2020-01-28 9:08 ` Dmitry Vyukov 0 siblings, 1 reply; 6+ messages in thread From: Ard Biesheuvel @ 2020-01-28 7:33 UTC (permalink / raw) To: Dmitry Vyukov Cc: Qian Cai, Randy Dunlap, Andrew Morton, Mark Brown, linux-fsdevel, Linux Kernel Mailing List, Linux-MM, Linux-Next Mailing List, Michal Hocko, mm-commits, Stephen Rothwell, Ard Biesheuvel, linux-efi, kasan-dev On Tue, 28 Jan 2020 at 07:26, Dmitry Vyukov <dvyukov@google.com> wrote: > > On Tue, Jan 28, 2020 at 7:15 AM Qian Cai <cai@lca.pw> wrote: > > > Should be fixed by > > > > > > https://lore.kernel.org/linux-efi/20200121093912.5246-1-ardb@kernel.org/ > > > > Cc kasan-devel@ > > > > If everyone has to disable KASAN for the whole subdirectories like this, I am worried about we are losing testing coverage fairly quickly. Is there a bug in compiler? > > My understanding is that this is invalid C code in the first place, > no? It just happened to compile with some compilers, some options and > probably only with high optimization level. No, this is not true. The whole point of favoring IS_ENABLED(...) over #ifdef ... has always been that the code remains visible to the compiler, regardless of whether the option is selected or not, but that it gets optimized away entirely. The linker errors prove that there is dead code remaining in the object files, which means we can no longer rely on IS_ENABLED() to work as intended. > There is a known, simple fix that is used throughout the kernel - > provide empty static inline stub, or put whole calls under ifdef. No, sorry, that doesn't work for me. I think it is great that we have diagnostic features that are as powerful as KASAN, but if they require code changes beyond enable/disable, I am not going to rely on them. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mmotm 2020-01-23-21-12 uploaded (efi) 2020-01-28 7:33 ` Ard Biesheuvel @ 2020-01-28 9:08 ` Dmitry Vyukov 2020-01-28 9:17 ` Ard Biesheuvel 0 siblings, 1 reply; 6+ messages in thread From: Dmitry Vyukov @ 2020-01-28 9:08 UTC (permalink / raw) To: Ard Biesheuvel Cc: Qian Cai, Randy Dunlap, Andrew Morton, Mark Brown, linux-fsdevel, Linux Kernel Mailing List, Linux-MM, Linux-Next Mailing List, Michal Hocko, mm-commits, Stephen Rothwell, Ard Biesheuvel, linux-efi, kasan-dev On Tue, Jan 28, 2020 at 8:33 AM Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > > > > Should be fixed by > > > > > > > > https://lore.kernel.org/linux-efi/20200121093912.5246-1-ardb@kernel.org/ > > > > > > Cc kasan-devel@ > > > > > > If everyone has to disable KASAN for the whole subdirectories like this, I am worried about we are losing testing coverage fairly quickly. Is there a bug in compiler? > > > > My understanding is that this is invalid C code in the first place, > > no? It just happened to compile with some compilers, some options and > > probably only with high optimization level. > > No, this is not true. The whole point of favoring IS_ENABLED(...) over > #ifdef ... has always been that the code remains visible to the > compiler, regardless of whether the option is selected or not, but > that it gets optimized away entirely. The linker errors prove that > there is dead code remaining in the object files, which means we can > no longer rely on IS_ENABLED() to work as intended. I agree that exposing more code to compiler is good, I prefer to do it as well. But I don't see how this proves anything wrt this particular code being invalid C. Called functions still need to be defined. There is no notion of dead code in C. Yes, this highly depends on compiler, options, optimization level, etc. Some combinations may work, some won't. E.g. my compiler compiles it just fine (clang 10) without disabling instrumentation... what does it prove? I don't know. To clarify: I completely don't object to patching this case in gcc with -O2, it just may be hard to find anybody willing to do this work if we are talking about fixing compilation of invalid code. > > There is a known, simple fix that is used throughout the kernel - > > provide empty static inline stub, or put whole calls under ifdef. > > No, sorry, that doesn't work for me. I think it is great that we have > diagnostic features that are as powerful as KASAN, but if they require > code changes beyond enable/disable, I am not going to rely on them. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mmotm 2020-01-23-21-12 uploaded (efi) 2020-01-28 9:08 ` Dmitry Vyukov @ 2020-01-28 9:17 ` Ard Biesheuvel 0 siblings, 0 replies; 6+ messages in thread From: Ard Biesheuvel @ 2020-01-28 9:17 UTC (permalink / raw) To: Dmitry Vyukov Cc: Qian Cai, Randy Dunlap, Andrew Morton, Mark Brown, linux-fsdevel, Linux Kernel Mailing List, Linux-MM, Linux-Next Mailing List, Michal Hocko, mm-commits, Stephen Rothwell, Ard Biesheuvel, linux-efi, kasan-dev On Tue, 28 Jan 2020 at 10:08, Dmitry Vyukov <dvyukov@google.com> wrote: > > On Tue, Jan 28, 2020 at 8:33 AM Ard Biesheuvel > <ard.biesheuvel@linaro.org> wrote: > > > > > Should be fixed by > > > > > > > > > > https://lore.kernel.org/linux-efi/20200121093912.5246-1-ardb@kernel.org/ > > > > > > > > Cc kasan-devel@ > > > > > > > > If everyone has to disable KASAN for the whole subdirectories like this, I am worried about we are losing testing coverage fairly quickly. Is there a bug in compiler? > > > > > > My understanding is that this is invalid C code in the first place, > > > no? It just happened to compile with some compilers, some options and > > > probably only with high optimization level. > > > > No, this is not true. The whole point of favoring IS_ENABLED(...) over > > #ifdef ... has always been that the code remains visible to the > > compiler, regardless of whether the option is selected or not, but > > that it gets optimized away entirely. The linker errors prove that > > there is dead code remaining in the object files, which means we can > > no longer rely on IS_ENABLED() to work as intended. > > I agree that exposing more code to compiler is good, I prefer to do it > as well. But I don't see how this proves anything wrt this particular > code being invalid C. Called functions still need to be defined. There > is no notion of dead code in C. Yes, this highly depends on compiler, > options, optimization level, etc. Some combinations may work, some > won't. E.g. my compiler compiles it just fine (clang 10) without > disabling instrumentation... what does it prove? I don't know. > > To clarify: I completely don't object to patching this case in gcc > with -O2, it just may be hard to find anybody willing to do this work > if we are talking about fixing compilation of invalid code. > I don't mind simply disabling KASAN altogether for this code if nobody can be bothered to fix the compiler. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-01-28 9:17 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20200124051332.DoQFo8kO9%akpm@linux-foundation.org> [not found] ` <1ccf26d9-9420-fc33-ad96-c3daedb1c487@infradead.org> 2020-01-25 7:06 ` mmotm 2020-01-23-21-12 uploaded (efi) Ard Biesheuvel 2020-01-28 6:15 ` Qian Cai 2020-01-28 6:25 ` Dmitry Vyukov 2020-01-28 7:33 ` Ard Biesheuvel 2020-01-28 9:08 ` Dmitry Vyukov 2020-01-28 9:17 ` Ard Biesheuvel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).