Re: [PATCH] parisc: prefer _THIS_IP_ and _RET_IP_ statement expressions

Dave, thanks for the quick review! On Wed, Aug 1, 2018 at 1:10 PM John David Anglin wrote: > > On 2018-08-01 2:22 PM, Nick Desaulniers wrote: > > As part of the effort to reduce the code duplication between _THIS_IP_ > > and current_text_addr(), let's consolidate callers o

[PATCH] x86/kexec: prefer _THIS_IP_ to current_text_addr

As part of the effort to reduce the code duplication between _THIS_IP_ and current_text_addr(), let's consolidate callers of current_text_addr() to use _THIS_IP_. Signed-off-by: Nick Desaulniers --- arch/x86/include/asm/kexec.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

Re: [PATCH] parisc: prefer _THIS_IP_ and _RET_IP_ statement expressions

On Wed, Aug 1, 2018 at 2:27 PM John David Anglin wrote: > > On 2018-08-01 4:52 PM, Nick Desaulniers wrote: > > Dave, thanks for the quick review! > > > > On Wed, Aug 1, 2018 at 1:10 PM John David Anglin > > wrote: > >> On 2018-08-01 2:22 PM, Nick Desauln

Re: [PATCH v2] sh: prefer _THIS_IP_ to current_text_addr

On Wed, Aug 1, 2018 at 2:55 PM Andrew Morton wrote: > > On Wed, 1 Aug 2018 11:53:31 -0700 Nick Desaulniers > wrote: > > > As part of the effort to reduce the code duplication between _THIS_IP_ > > and current_text_addr(), let's consolidate callers of > > c

Re: [PATCH] parisc: prefer _THIS_IP_ and _RET_IP_ statement expressions

On Wed, Aug 1, 2018 at 3:12 PM John David Anglin wrote: > > On 2018-08-01 5:49 PM, Nick Desaulniers wrote: > > Thoughts? Idea being there's only one call site in your tree that has > > this requirement (and the other one in > > include/net/inet_connection_sock.h

Re: [PATCH] tracing: do not leak kernel addresses

On Wed, Jul 25, 2018 at 1:23 PM Mark Salyzyn wrote: > > From: Nick Desaulniers > Signed-off-by: Mark Salyzyn > Thanks for sending. You should take credit/authorship, and add my Reviewed-by: Nick Desaulniers -- Thanks, ~Nick Desaulniers

[PATCH v2] zsmalloc: use U suffix for negative literals being shifted

Fixes warnings about shifting unsigned literals being undefined behavior. Suggested-by: Minchan Kim Signed-off-by: Nick Desaulniers --- Changes since v1: * Use L suffix in addition to U, as suggested (link->next is unsigned long). mm/zsmalloc.c | 2 +- 1 file changed, 1 insertion(+)

Re: [PATCH v2] kasan: don't emit builtin calls when sanitization is off

Hmm... I had mentioned this patch to some coworkers who have much more knowledge about LLVM than me. They had concern that LLVM needs memset to be defined, and that there were discussions on the llvm mailing list about this. I'm digging through trying to find anything relevant, maybe this one abo

Re: [PATCH v2] kasan: don't emit builtin calls when sanitization is off

sorry, for new people I just cc'ed: https://patchwork.kernel.org/patch/10175831/ On Fri, Jan 19, 2018 at 2:06 PM, Nick Desaulniers wrote: > Hmm... I had mentioned this patch to some coworkers who have much more > knowledge about LLVM than me. They had concern that LLVM needs mem

Re: [PATCH v2] kasan: don't emit builtin calls when sanitization is off

On Mon, Jan 22, 2018 at 12:22 PM, Andrey Konovalov wrote: > On Fri, Jan 19, 2018 at 8:06 PM, Nick Desaulniers > wrote: >> Hmm... I had mentioned this patch to some coworkers who have much more >> knowledge about LLVM than me. They had concern that LLVM needs memset >>

Re: [Xen-devel] [PATCH] x86/xen/time: fix section mismatch for xen_init_time_ops()

On Tue, Jan 2, 2018 at 7:00 AM, Boris Ostrovsky wrote: > On 01/02/2018 09:32 AM, Andrew Cooper wrote: >> On 02/01/18 14:24, Juergen Gross wrote: >>> On 02/01/18 15:18, Boris Ostrovsky wrote: >>>> On 12/23/2017 09:50 PM, Nick Desaulniers wrote: >>>>> Th

Re: [PATCH] zsmalloc: use U suffix for negative literals being shifted

Hello, What are the next steps for this patch? Note: the MAINTAINERS file does not contain a T: (tree) entry for ZSMALLOC, so I can't check to see if this has already been merged or not. Unless you work out of the mm tree?

[PATCH v2] x86: xen: remove the use of VLAIS

Gross Signed-off-by: Nick Desaulniers --- Changes in v2: * Change mask to us DECLARE_BITMAP instead of pointer, as suggested. * Update commit message to remove mention of pointer. * Update sizeof calculation to work with array rather than pointer. arch/x86/xen/mmu_pv.c | 8 +++- 1 file chang

[PATCH] Input: synaptics-rmi4 - prevent UAF reported by KASAN

fb fb fb [ 311.424384] ^ [ 311.424387] 88041fd61100: fc fc fc fc fb fb fb fb fb fb fb fb fc fc fc fc [ 311.424391] 88041fd61180: fb fb fb fb fb fb fb fb fc fc fc fc fb fb fb fb Cc: sta...@vger.kernel.org Signed-off-by: Nick Desau

Re: [PATCH] zsmalloc: use U suffix for negative literals being shifted

On Sun, Jan 7, 2018 at 7:04 AM, Minchan Kim wrote: > Sorry for the delay. I have missed this until now. ;-( No worries, figured patches would need a post holiday bump for review. > > On Sun, Dec 24, 2017 at 11:33 AM, Nick Desaulniers > wrote: >> -

Re: [PATCH] mm/vmscan: fix unsequenced modification and access warning

pre commit f2f43e566a0, or is .reclaim_idx supposed to be different between try_to_free_pages() and __node_reclaim()? On Wed, May 10, 2017 at 12:15 AM, Michal Hocko wrote: > On Tue 09-05-17 23:53:28, Nick Desaulniers wrote: >> Clang flags this file with the -Wunsequenced error that G

Re: [PATCH] arm/arm64: smccc: Use xN for arm64 register constraints with clang

.else where the conditional negated is kind of funny. -- Thanks, ~Nick Desaulniers

Re: [PATCH v3 2/2] kbuild: Don't mess with the .cache.mk when root

t .cache.mk, but I don't think anyone has actually experienced the > problems listed in the CL description. >/bin/sh: ./.cache.mk: Permission denied I feel like I've definitely seen that permission error before. Is there any issue if I: $ make clean $ make $ sudo make install $ make Or it's only a problem if: $ make clean $ sudo make install $ make -- Thanks, ~Nick Desaulniers

Re: [PATCH] staging: rtl8723bs: Mark ACPI table declaration as maybe unused

ug in Clang: https://bugs.llvm.org/show_bug.cgi?id=39088 As Nathan notes in this comment in V1: https://lore.kernel.org/lkml/20180926064437.GA29417@flashbox/ having additional references to the static array is enough to keep it around. When there are no other references, then it should not be marked static, in order to still be emitted. We can work around this by removing `static` from struct definitions that no other references than being passed to the MODULE_DEVICE_TABLE macro. GCC and Clang will then both emit references to both identifiers. -- Thanks, ~Nick Desaulniers

Re: [PATCH v2] compiler.h: give up __compiletime_assert_fallback()

On Wed, Sep 26, 2018 at 11:00 AM Matthias Kaehlcke wrote: > > On Fri, Aug 31, 2018 at 09:46:02AM -0700, Nick Desaulniers wrote: > > On Tue, Aug 28, 2018 at 4:00 PM Nick Desaulniers > > wrote: > > > > > > On Mon, Aug 27, 2018 at 1:42 PM Daniel Santos >

Re: [PATCH] staging: rtl8723bs: Mark ACPI table declaration as maybe unused

On Wed, Sep 26, 2018 at 10:55 AM Nick Desaulniers wrote: > > On Wed, Sep 26, 2018 at 12:41 AM Nathan Chancellor > wrote: > > > > On Wed, Sep 26, 2018 at 09:13:59AM +0200, Greg Kroah-Hartman wrote: > > > On Wed, Sep 26, 2018 at 12:02:09AM -0700, Nathan Chancellor

Re: [PATCH v2] compiler.h: give up __compiletime_assert_fallback()

hiro, yes? For linux-next, maybe it can go via -mm? > > Either is fine with me, as long as it isn't one of my trees :) > > thanks, > > greg k-h Besides, I think we want the v2: https://lkml.org/lkml/2018/8/25/103 -- Thanks, ~Nick Desaulniers

Re: [PATCH] staging: rtl8723bs: Mark ACPI table declaration as maybe unused

On Wed, Sep 26, 2018 at 11:39 AM Greg KH wrote: > > On Wed, Sep 26, 2018 at 11:28:46AM -0700, Nick Desaulniers wrote: > > On Wed, Sep 26, 2018 at 10:55 AM Nick Desaulniers > > wrote: > > > > > > On Wed, Sep 26, 2018 at 12:41 AM Nathan Chancellor > > >

Re: [PATCH v2] drm/amd/display: Use proper enums in process_channel_reply

_operation_result' to different enumeration type 'enum > > aux_transaction_reply' [-Wenum-conversion] > > reply->status = AUX_CHANNEL_OPERATION_FAILED_HPD_DISCON; > > ~ ^~~ > > > > The cu

Re: [PATCH] staging: rtl8723bs: Mark ACPI table declaration as used

; > > $ nm -S drivers/staging/rtl8723bs/os_dep/sdio_intf.o | grep acpi > > 0040 R __mod_acpi__acpi_ids_device_table > > > > Link: https://github.com/ClangBuiltLinux/linux/issues/169 > > Suggested-by: Nick Desaulniers > > Signed-off-by: Nathan Chancellor

Re: [PATCH] staging: rtl8723bs: Mark ACPI table declaration as used

On Thu, Sep 27, 2018 at 1:05 PM Nick Desaulniers wrote: > > On Wed, Sep 26, 2018 at 10:16 PM Greg Kroah-Hartman > wrote: > > > > On Wed, Sep 26, 2018 at 04:20:55PM -0700, Nathan Chancellor wrote: > > > Clang emits the following warning: > > > > > >

Re: [PATCH] IB/mlx4: Avoid implicit enumerated type conversion

On Wed, Sep 26, 2018 at 9:48 PM Jason Gunthorpe wrote: > > On Wed, Sep 26, 2018 at 06:08:03PM -0700, Nathan Chancellor wrote: > > On Mon, Sep 24, 2018 at 08:37:22PM -0600, Jason Gunthorpe wrote: > > > On Mon, Sep 24, 2018 at 03:29:38PM -0700, Nick Desaulniers wrote: > &g

Re: [PATCH v3] IB/rxe: Remove unnecessary enum values

ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU); > ~~ ^~~~~~~ > 5 warnings generated. > > Use the appropriate values from the expected enumerated type so no > conversion needs to happen then remove the unneeded definition

Re: [PATCH] RDMA/qedr: Explicitly cast pkt->tx_dest to qed_ll2_tx_dest

ion to the Loopback */ 67 QED_LL2_TX_DEST_DROP, /* Light L2 Drop the TX packet */ 68 QED_LL2_TX_DEST_MAX 69 }; Maybe the maintainers can clarify? > > Reported-by: Nick Desaulniers > Signed-off-by: Nathan Chancellor > --- > drivers/infiniband/hw/qedr/qedr_roce_c

Re: [PATCH] IB/mlx4: Avoid implicit enumerated type conversion

On Thu, Sep 27, 2018 at 1:28 PM Nathan Chancellor wrote: > > On Thu, Sep 27, 2018 at 01:13:31PM -0700, Nick Desaulniers wrote: > > On Wed, Sep 26, 2018 at 9:48 PM Jason Gunthorpe wrote: > > > > > > On Wed, Sep 26, 2018 at 06:08:03PM -0700, Nathan Chancellor wrote: &

Re: [PATCH] RDMA/qedr: Explicitly cast pkt->tx_dest to qed_ll2_tx_dest

On Thu, Sep 27, 2018 at 1:35 PM Nathan Chancellor wrote: > > On Thu, Sep 27, 2018 at 01:28:12PM -0700, Nick Desaulniers wrote: > > On Wed, Sep 26, 2018 at 6:18 PM Nathan Chancellor > > wrote: > > > > > > Clang warns when one enumerated type is explicitly conve

Re: [PATCH v2] IB/mlx4: Avoid implicit enumerated type conversion

~ ^ > > The type mlx4_ib_qp_flags explicitly provides supplemental values to the > type ib_qp_create_flags. Make that clear to Clang by changing the > create_flags type to int. > > Reported-by: Nick Desaulniers > Signed-off-by: Nathan Chancellor >

Re: [PATCH v2] x86/boot: define CC_HAVE_ASM_GOTO

ssed/ include > > arch/x86/boot/compressed/misc.h AND > > arch/x86/boot/compressed/Makefile happens to redefine KBUILD_CFLAGS, > > which set these variables in the top level MAKEFILE. > > > > Suggested-by: Borislav Petkov > > Signed-off-by: Nick Desaulniers > &

Re: [PATCH v2] RDMA/qedr: Remove enumerated type qed_roce_ll2_tx_dest

used once in the whole tree and QED_ROCE_LL2_TX_DEST_MAX is used > nowhere. Remove them and use the equivalent values from qed_ll2_tx_dest > in their place. > > Reported-by: Nick Desaulniers > Signed-off-by: Nathan Chancellor > --- > > v1 -> v2: > > * Rather tha

Re: [PATCH] IB/mlx4: Avoid implicit enumerated type conversion

On Thu, Sep 27, 2018 at 3:33 PM Bart Van Assche wrote: > > On Thu, 2018-09-27 at 16:28 -0600, Jason Gunthorpe wrote: > > On Thu, Sep 27, 2018 at 01:34:16PM -0700, Nick Desaulniers wrote: > > > > > > Neither ib_qp_create_flags nor mlx4_ib_qp_flags have negative

Re: [PATCH] scsi: bfa: Avoid implicit enum conversion in bfad_im_post_vendor_event

struct bfad_s *drv, int cnt, > enum bfa_aen_category cat, > - enum bfa_ioc_aen_event evt) > +int evt) > { > struct timespec64 ts; > > -- > 2.19.0 > -- Thanks, ~Nick Desaulniers

Re: [PATCH] IB/mlx4: Avoid implicit enumerated type conversion

On Thu, Sep 27, 2018 at 3:58 PM Jason Gunthorpe wrote: > > On Thu, Sep 27, 2018 at 03:42:24PM -0700, Nick Desaulniers wrote: > > On Thu, Sep 27, 2018 at 3:33 PM Bart Van Assche wrote: > > > > > > On Thu, 2018-09-27 at 16:28 -0600, Jason Gunthorpe wrote: > > &g

Re: [PATCH v3 3/3] build_bug.h: remove most of dummy BUILD_BUG_ON stubs for sparse

ich GCC is fine with: > > > > static const int x = 0; > > int y = BUILD_BUG_ON_ZERO(x); > > > > Signed-off-by: Masahiro Yamada > > Acked-by: Kees Cook > > Reviewed-by: Luc Van Oostenryck Clang builds not affected. Tested a quick arm64 defconfig build with Clang + this patch. Reviewed-by: Nick Desaulniers Tested-by: Nick Desaulniers -- Thanks, ~Nick Desaulniers

Re: [PATCH v3 2/3] build_bug.h: remove negative-array fallback for BUILD_BUG_ON()

error, which is harder to > - * track down. > */ > -#ifndef __OPTIMIZE__ > -#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)])) > -#else > #define BUILD_BUG_ON(condition) \ > BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condi

[PATCH] arm64: io: specify asm operand width for __iormb()

ous-integration/issues/78 Suggested-by: Nathan Chancellor Reviewed-by: Nathan Chancellor Signed-off-by: Nick Desaulniers --- Side note: is it not correct to cite SHAs from linux-next in "Fixes commit ..." lines? I guess we can drop it. Link to regression build: https://travis-ci.c

Re: [PATCH v2 1/2] Makefile: Export clang toolchain variables

`-no-integrated-as` is set? Either way, I think it would be clearer to export this after all the relevant flags are set. > KBUILD_CFLAGS += $(CLANG_FLAGS) > KBUILD_AFLAGS += $(CLANG_FLAGS) > -- > 2.19.1 > -- Thanks, ~Nick Desaulniers

Re: [PATCH] rtc: omap: Use define directive for PIN_CONFIG_ACTIVE_HIGH

FIG_END + 1, > -}; > +#define PIN_CONFIG_ACTIVE_HIGH (PIN_CONFIG_END + 1) > > static const struct pinconf_generic_params rtc_params[] = { > {"ti,active-high", PIN_CONFIG_ACTIVE_HIGH, 0}, > -- > 2.19.1 > Bumping for review -- Thanks, ~Nick Desaulniers

Re: [PATCH] Compiler Attributes: move kernel-only attributes into __KERNEL__

redefining the semantics of `inline` for those programs (unexpectedly). Admittedly, gnu_inline kind of an edge case so most users might not notice, but that may be an argument for `-f gnu_inline` rather than redefining `inline` in a header. > > Cheers, > Miguel -- Thanks, ~Nick Desaulniers

Re: [PATCH 1/2] ARM: Remove '-p' from LDFLAGS

d had removed -p's implementation a long time ago, but kept the flag as a no-op for compatibility. I asked that the patch be extended to arm as well, but don't think a v2 was ever cut. Thanks for sending this Nathan. Reviewed-by: Nick Desaulniers > > Signed-off-by: Nathan Ch

Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option

; > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > > > > index e2a0baf36766..4fab2aa29570 100644 > > > > --- a/arch/arm/Makefile > > > > +++ b/arch/arm/Makefile > > > > @@ -10,7 +10,7 @@ > > > > # > > > > # Copyright (C) 1995-2001 by Russell King > > > > > > > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer > > > > +LDFLAGS_vmlinux:= --no-undefined -X $(call > > > > ld-option,--pic-veneer) > > > > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y) > > > > LDFLAGS_vmlinux+= --be8 > > > > KBUILD_LDFLAGS_MODULE += --be8 > > > > -- > > > > 2.20.0.rc1 > > > > -- Thanks, ~Nick Desaulniers

Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option

ow_bug.cgi?id=39886 > > > > > > Thanks for the quick reply, > > > Nathan > > > > > > > > --- > > > > > arch/arm/Makefile | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > &

Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option

300018: e1a0300dmov r3, sp > > c030001c: e1a0f003 mov pc, r3 > > > > Thanks Nate. > > So these functions no longer appear to reside far away from each > other, so there no veneer has been emitted. > > What we're looking for are veneers, i.e., snippets inserted by the > linker that serve as a trampoline so a branch target that is far away > can be reached. > > If no symbols exist with 'veneer' in their name *, it might make sense > to rebuild the kernel as Thumb2, which has a branching range of only 8 > MB (as opposed to 16 MB for ARM mode) Heh, Arnd and I were just talking about this yesterday. Is there a config that sets Thumb2 mode for the kernel? > > * I have no idea whether lld names its veneers like this, or even at all -- Thanks, ~Nick Desaulniers

Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option

On Wed, Dec 5, 2018 at 2:59 PM Stefan Agner wrote: > > On 05.12.2018 19:41, Nick Desaulniers wrote: > > On Wed, Dec 5, 2018 at 10:40 AM Ard Biesheuvel > > wrote: > >> > >> On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor > >> wrote: > >>

Re: [PATCH] x86/vdso: drop implicit common-page-size linker flag

rewriting it for mere mortals? How does this sound: TL;DR -z common-page-size's default value is based on the target architecture. arch/x86/entry/vdso/Makefile sets it to the architecture default, which is implicit and redundant. Drop it. -- Thanks, ~Nick Desaulniers

Re: [PATCH] x86/vdso: drop implicit common-page-size linker flag

On Fri, Dec 7, 2018 at 9:53 AM Borislav Petkov wrote: > > On Fri, Dec 07, 2018 at 09:45:42AM -0800, Nick Desaulniers wrote: > > Google's Native Client, a technology for running native code in a web > > browser. It's since been superseded by Portable Native Client (pNa

Re: [PATCH] arm64: drop linker script hack to hide __efistub_ symbols

linker script to emit them as absolute symbols. > > Cc: Nick Desaulniers > Signed-off-by: Ard Biesheuvel Tested-by: Nick Desaulniers Tested linking with bfd and booting in qemu. Thanks Ard! lld still has some further bugs for us to work out, but this should help simplify things for

Re: [PATCH v2] kvm: x86: mmu: Add cast to negated bitmasks in update_permission_bitmask()

o 'u8' > > (aka 'unsigned char') changes value from -205 to 51 [-Werror, > > -Wconstant-conversion] > > u8 wf = (pfec & PFERR_WRITE_MASK) ? ~w : 0; > >~~ ^~ > > > > (gcc also raises a w

Re: [PATCH v2] kvm: x86: mmu: Add cast to negated bitmasks in update_permission_bitmask()

On Mon, Jun 25, 2018 at 1:05 PM Joe Perches wrote: > > On Mon, 2018-06-25 at 12:47 -0400, Nick Desaulniers wrote: > > On Mon, Jun 25, 2018 at 12:05 PM Paolo Bonzini wrote: > > > > > > On 19/06/2018 21:25, Matthias Kaehlcke wrote: > > > > update_permissi

Re: [PATCH v2] kvm: x86: mmu: Add cast to negated bitmasks in update_permission_bitmask()

on > +warning-3 += $(call cc-option -Wconstant-conversion) > warning-3 += -Wpacked > warning-3 += -Wpadded > warning-3 += -Wpointer-arith I prefer that to turning off the warning outright. -- Thanks, ~Nick Desaulniers

Re: [PATCH] arm64: remove no-op -p linker flag

ile?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 So nothing in the kernel commit history to hint at what it was ever used for. As long as you have a version of binutils that not 14 years old, you should be good. Reviewed-by: Nick Desaulniers -- Thanks, ~Nick Desaulniers

Re: [clang] stack protector and f1f029c7bf

*bare metal* (Lenovo ThinkPad T470). preping a patch in https://bugs.llvm.org/show_bug.cgi?id=37512 will send shortly. -- Thanks, ~Nick Desaulniers

Re: [clang] stack protector and f1f029c7bf

o: arch/x86/kernel/paravirt.c:326 325 __visible struct pv_irq_ops pv_irq_ops = { 326 .save_fl = __PV_IS_CALLEE_SAVE(native_save_fl), see comparison of disassembly attached in: https://bugs.llvm.org/attachment.cgi?id=20338 -- Thanks, ~Nick Desaulniers

Re: [clang] stack protector and f1f029c7bf

ace it, reading and writing the flags should be builtins, exactly because it has to do stack operations, which really means the compiler should be involved. I'm happy to propose that as a feature request to llvm+gcc. -- Thanks, ~Nick Desaulniers

Re: [clang] stack protector and f1f029c7bf

On Thu, May 24, 2018 at 1:26 PM Nick Desaulniers wrote: > On Thu, May 24, 2018 at 11:59 AM wrote: > > Issue 3: Let's face it, reading and writing the flags should be builtins, > exactly because it has to do stack operations, which really means the > compiler should be invol

Re: [clang] stack protector and f1f029c7bf

On Thu, May 24, 2018 at 1:52 PM Nick Desaulniers wrote: > On Thu, May 24, 2018 at 1:26 PM Nick Desaulniers > wrote: > > On Thu, May 24, 2018 at 11:59 AM wrote: > > > Issue 3: Let's face it, reading and writing the flags should be > builtins, > > exactly be

Re: [clang] stack protector and f1f029c7bf

On Thu, May 24, 2018 at 2:12 PM Nick Desaulniers wrote: > On Thu, May 24, 2018 at 1:52 PM Nick Desaulniers > wrote: > > On Thu, May 24, 2018 at 1:26 PM Nick Desaulniers < ndesaulni...@google.com> > > wrote: > > > On Thu, May 24, 2018 at 11:59 AM wrote: > &

Re: [clang] stack protector and f1f029c7bf

t should go in an existing .S file or a new one (and if so where/what shall I call it?). -- Thanks, ~Nick Desaulniers

Re: [clang] stack protector and f1f029c7bf

On Thu, May 24, 2018 at 3:43 PM wrote: > On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers wrote: > >On Thu, May 24, 2018 at 3:05 PM H. Peter Anvin wrote: > >> COMPILER AR: "=rm" should NEVER generate worse code than "=r". That > >is > >&

Re: [clang] stack protector and f1f029c7bf

On Fri, May 25, 2018 at 9:33 AM wrote: > On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers wrote: > >On Thu, May 24, 2018 at 3:43 PM wrote: > >> On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers > > > >wrote: > >> >On Thu, May 24, 2018 at 3:05 PM H.

Re: [clang] stack protector and f1f029c7bf

On Fri, May 25, 2018 at 9:53 AM wrote: > On May 25, 2018 9:46:42 AM PDT, Nick Desaulniers wrote: > >On Fri, May 25, 2018 at 9:33 AM wrote: > >> On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers > > wrote: > >When you say > > > >> It still shoul

Re: [clang] stack protector and f1f029c7bf

On Fri, May 25, 2018 at 10:35 AM Tom Stellard wrote: > On 05/25/2018 10:31 AM, Nick Desaulniers wrote: > > On Fri, May 25, 2018 at 9:53 AM wrote: > >> On May 25, 2018 9:46:42 AM PDT, Nick Desaulniers < ndesaulni...@google.com> > > wrote: > >>> On Fri,

Re: [clang] stack protector and f1f029c7bf

On Fri, May 25, 2018 at 10:49 AM Nick Desaulniers wrote: > gcc 8.1 and trunk inserts a `ud2` instruction (what?!) (let me see if I can > repro outside of godbolt, and will file a bug report). Filed: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85927 -- Thanks, ~Nick Desaulniers

Re: [clang] stack protector and f1f029c7bf

er directives (which I also don't know). I'm beginning to think that what you'd like to see cannot be expressed (at least via `extern inline`). -- Thanks, ~Nick Desaulniers

Re: [clang] stack protector and f1f029c7bf

On Fri, May 25, 2018 at 2:06 PM H. Peter Anvin wrote: > On 05/25/18 13:36, Nick Desaulniers wrote: > > On Fri, May 25, 2018 at 10:56 AM wrote: > >> You need the extern inline in the .h file and the out-of-line .S file > > I don't see how you can specify to the lin

Re: Clang arm64 build is broken

7;t sound like a good justification for adding > new issues :) > However in this case I do believe that this is more of a bug in clang > that should be fixed. Just to follow up with this thread; Support for "S" constraints is being (re-)added to Clang in: https://reviews.llvm.org/D46745 -- Thanks, ~Nick Desaulniers

Re: [PATCH] kvm: x86: mmu: Add cast to negated bitmasks in update_permission_bitmask()

On Tue, Jun 19, 2018 at 8:19 AM Paolo Bonzini wrote: > > On 15/06/2018 20:45, Nick Desaulniers wrote: > >> > >>> In any case I think it it preferable to fix the code over disabling > >>> the warning, unless the warning is bogus or there are just

Re: [clang] stack protector and f1f029c7bf

On Fri, May 25, 2018 at 3:38 PM Nick Desaulniers wrote: > > On Fri, May 25, 2018 at 2:06 PM H. Peter Anvin wrote: > > On 05/25/18 13:36, Nick Desaulniers wrote: > > > On Fri, May 25, 2018 at 10:56 AM wrote: > > >> You need the extern inline in the .h file an

Re: [clang] stack protector and f1f029c7bf

On Wed, May 30, 2018 at 11:50 PM Nick Desaulniers wrote: > Will do further testing and cut a patch set tomorrow. https://lkml.org/lkml/2018/6/1/679 (sorry, should have re-cc-ed everyone from this thread, will try to re-add when there's feedback) -- Thanks, ~Nick Desaulniers

Re: [PATCH] kvm: x86: mmu: Add cast to negated bitmasks in update_permission_bitmask()

godbolt.org/g/ynAoeJ See also: https://wiki.sei.cmu.edu/confluence/display/c/EXP14-C.+Beware+of+integer+promotion+when+performing+bitwise+operations+on+integer+types+smaller+than+int Reviewed-by: Nick Desaulniers -- Thanks, ~Nick Desaulniers

Re: [PATCH] kvm: x86: mmu: Add cast to negated bitmasks in update_permission_bitmask()

On Fri, Jun 15, 2018 at 11:40 AM Joe Perches wrote: > > On Fri, 2018-06-15 at 11:29 -0700, Matthias Kaehlcke wrote: > > On Fri, Jun 15, 2018 at 11:18:12AM -0700, Joe Perches wrote: > > > On Fri, 2018-06-15 at 11:04 -0700, Nick Desaulniers wrote: > > > > On Fri,

Re: [PATCH] arm64: kvm: use -fno-jump-tables with clang

tead of using relative addressing? It seems like if there's requirements that only relative addressing be used, then the compiler should be told explicitly about this restriction, no? -- Thanks, ~Nick Desaulniers

Re: [PATCH] arm64: kvm: use -fno-jump-tables with clang

+ Andrey (who reported testing this patch in https://github.com/ClangBuiltLinux/linux/issues/11) On Fri, May 18, 2018 at 10:40 AM Nick Desaulniers wrote: > On Fri, May 18, 2018 at 10:30 AM Marc Zyngier wrote: > > I'm going to ask the question I've asked before when this p

Re: [PATCH] arm64: kvm: use -fno-jump-tables with clang

+ Andrey On Fri, May 18, 2018 at 10:45 AM Marc Zyngier wrote: > On 18/05/18 18:40, Nick Desaulniers wrote: > > On Fri, May 18, 2018 at 10:30 AM Marc Zyngier wrote: > >> I'm going to ask the question I've asked before when this patch cropped > >> up (mus

Re: [PATCH] arm64: kvm: use -fno-jump-tables with clang

ompletely outlandish. These are all reasonable. Thanks for the feedback. -- Thanks, ~Nick Desaulniers

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

Sedat, Thanks for the report. We have a fix ready in https://bugs.llvm.org/show_bug.cgi?id=37512. Can you report what version of clang you were using and if earlier versions of clang have this issue? Thanks, ~Nick

Re: [RFC PATCH] compiler.h: give up __compiletime_assert_fallback()

letime_assert on > > old > > - * versions of GCC (e.g. 4.2.4), so hide the array from sparse altogether. > > - */ > > -# ifndef __CHECKER__ > > -# define __compiletime_error_fallback(condition) \ > > - do { ((void)sizeof(char[1 - 2 * condition])); } while (0) Note that there are a few definitions of BUILD_BUG_ON that still use this negative array size trick. Should that pattern be removed from them as well? See: * arch/x86/boot/boot.h#L33 * include/linux/build_bug.h#L66 * tools/include/linux/kernel.h#L38 Reviewed-by: Nick Desaulniers -- Thanks, ~Nick Desaulniers

Re: [RFC PATCH] compiler.h: give up __compiletime_assert_fallback()

On Sun, Aug 19, 2018 at 1:28 PM Linus Torvalds wrote: > > On Sun, Aug 19, 2018 at 1:25 PM Nick Desaulniers > wrote: > > > > + gbiv who wrote this cool paste (showing alternatives to > > _Static_assert, which is supported by both compilers in -std=gnu89, > &

Re: Build failures with gcc 4.5 and older

I think we should take Joe's patch. Reviewed-by: Nick Desaulniers (sorry for the lack of context, trying out the reply instructions from: https://lore.kernel.org/lkml/4cdd4ab9ddd16f1fb168266643264595782fd890.ca...@perches.com/)

Re: [PATCH v2] Compiler Attributes: don't pollute userspace with macro definitions

about the function signature, which does not change between our definitions of inline. Acked-by: Nick Desaulniers -- Thanks, ~Nick Desaulniers

Re: [PATCH] drm/i915: Disable -Wuninitialized for intel_breadcrumbs.o

nfig and allyesconfig > without any warnings with tip-of-tree Clang. Also, please let us know about any other bugs found via testing with Clang: https://github.com/ClangBuiltLinux/linux/issues We're happy to take a look! -- Thanks, ~Nick Desaulniers

Re: [PATCH v3] Compiler Attributes: don't pollute userspace with macro definitions

atch only affects what userspace sees. > > 2. __must_check (when !CONFIG_ENABLE_MUST_CHECK) and noinline_for_stack > > were once defined in __KERNEL__ only, but we believe that they can > > be put into !__ASSEMBLY__ too. > > > > Acked-by: Nick Desaulniers &

Re: [PATCH v2] Compiler Attributes: don't pollute userspace with macro definitions

On Fri, Dec 14, 2018 at 2:02 AM Miguel Ojeda wrote: > > On Thu, Dec 13, 2018 at 11:25 PM Nick Desaulniers > wrote: > > > > Moving the __KERNEL__ guard should not affect the kernel, only what > > userspace sees. __gnu_inline only affects which > > implementati

Re: [PATCH 3/3] kbuild: add -Werror=implicit-int flag unconditionally

On Fri, Dec 14, 2018 at 12:06 AM Masahiro Yamada wrote: > > This flag is documented in the GCC 4.6 manual, and recognized by > Clang as well. Let's rip off the cc-option switch. > > Signed-off-by: Masahiro Yamada LGTM: https://godbolt.org/z/1Z3aG2 Reviewed-

Re: [PATCH 1/3] kbuild: add -fno-PIE flag unconditionally

27; > ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC) > $(KBUILD_CFLAGS)), y) >CC_HAVE_ASM_GOTO := 1 > -- > 2.7.4 > -- Thanks, ~Nick Desaulniers

Re: [PATCH 2/3] kbuild: add -Werror=strict-prototype flag unconditionally

updating the commit message (and subject), then: Reviewed-by: Nick Desaulniers > > Let's add -Werror=strict-prototypes unconditionally because it is > supported by GCC 4.6, and also by Clang. > > Signed-off-by: Masahiro Yamada > --- > > Makefile | 5 + > 1

Re: [tip:x86/build] x86/um/vdso: Drop implicit common-page-size linker flag

so/Makefile sets it to the architecture > default, which is implicit and redundant. Drop it so that one more LLVM > build issue gets addressed. > > Signed-off-by: Nick Desaulniers > Signed-off-by: Borislav Petkov > Acked-by: Richard Weinberger I missed Richard's ACK. Did

Re: [tip:x86/build] x86/um/vdso: Drop implicit common-page-size linker flag

l literally did not show any responses even in search for my patch (even from someone on the to/cc list!). Maybe I can file a bug about this internally... -- Thanks, ~Nick Desaulniers

Re: [tip:x86/build] x86/um/vdso: Drop implicit common-page-size linker flag

On Tue, Dec 11, 2018 at 10:06 AM Borislav Petkov wrote: > > On Tue, Dec 11, 2018 at 09:53:49AM -0800, Nick Desaulniers wrote: > > Indeed it was. I'm forced to use Gmail's clients for this work > > account and all that implies (no plain text responses when mobile).

Re: [PATCH] drm/amd/display: Pass app_tf by value rather than by reference

e callsite of `mod_freesync_build_vrr_infopacket` in drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#4949: - NULL, + transfer_func_unknown, Maybe at that point the `if (app_tf != NULL)` could be replaced with `if (

Re: [PATCH] drm/amd/display: Pass app_tf by value rather than by reference

On Tue, Dec 11, 2018 at 1:42 PM Nathan Chancellor wrote: > > On Tue, Dec 11, 2018 at 01:25:00PM -0800, Nick Desaulniers wrote: > > On Mon, Dec 10, 2018 at 3:42 PM Nathan Chancellor > > wrote: > > > > > > Clang warns when an expression that equals zero is used

Re: [PATCH] x86/pgtable: Always inline p4d_index

ch or even the tree could still disappear, or history gets rewritten (hopefully not on a master branch, but I've seen it happen accidentally (Firefox OS))). This doesn't look like an invasive change to me, though I'm curious about the usefulness of CONFIG_NO_AUTO_INLINE if the kernel is still c

Re: [PATCH] crypto: ux500 - Use proper enum in cryp_set_dma_transfer

DEV_TO_MEM = 2 > > Signed-off-by: Nathan Chancellor Deja vu! These particular enums get mixed up ALL THE TIME. Thanks for fixing probably every instance of this bug (via patches before this one). Reviewed-by: Nick Desaulniers > --- > drivers/crypto/ux500/cryp/cryp_core.c | 4 ++--

Re: [PATCH] crypto: ux500 - Use proper enum in hash_set_dma_transfer

ns. (I'm beginning to think we should change the values of the enum members so that things break when aliased as such. Unfortunately, that would result in runtime bugs rather than strong type system based compile time checks; but this warning from Clang helps). Reviewed-by: Nick Desaulniers >

Re: [PATCH] ACPI / tables: Add an ifdef around amlcode and dsdt_amlcode

CPI_CUSTOM_DSDT > > static void *amlcode __attribute__ ((weakref("AmlCode"))); > > static void *dsdt_amlcode __attribute__ ((weakref("dsdt_aml_code"))); > > +#endif Thanks for this patch Nathan. I'm curious if rather than adding a second set of preprocessor guards, we could simply move the declaration of these 2 variables closer to their use, putting them in the existing preprocessor guards from 82e4eb4e9653? -- Thanks, ~Nick Desaulniers

Re: [PATCH] ARM: Ensure that NEON code always compiles with Clang

ang. This doesn't functionally change anything because > that code will only run where NEON is supported, which is implicitly > armv7. > > Link: https://github.com/ClangBuiltLinux/linux/issues/287 > Suggested-by: Ard Biesheuvel > Signed-off-by: Nathan Chancellor N

<    1   2   3   4   5   6   7   8   9   10   >