Re: [PATCH 14/16] include/linux: prefer __section from compiler_attributes.h

On Mon, Aug 12, 2019 at 11:53 PM Nick Desaulniers wrote: > > Link: https://github.com/ClangBuiltLinux/linux/issues/619 > Reported-by: Sedat Dilek > Suggested-by: Josh Poimboeuf > Signed-off-by: Nick Desaulniers Tested-by: Sedat Dilek [ Linux v5.3-rc5 ] Patchset "for-

Re: [PATCH 15/16] include/linux/compiler.h: remove unused KENTRY macro

; Signed-off-by: Nick Desaulniers Tested-by: Sedat Dilek [ Linux v5.3-rc5 ] Patchset "for-5.3/x86-section-name-escaping" (5 patches): compiler_attributes.h: add note about __section include/linux/compiler.h: remove unused KENTRY macro include/linux: prefer __section from compiler_attribute

Re: [PATCH 16/16] compiler_attributes.h: add note about __section

On Mon, Aug 12, 2019 at 11:53 PM Nick Desaulniers wrote: > > The antipattern described can be found with: > $ grep -e __section\(\" -r -e __section__\(\" > > Link: https://bugs.llvm.org/show_bug.cgi?id=42950 > Signed-off-by: Nick Desaulniers Tested-by: Sedat Dilek

Re: [PATCH 11/16] x86: prefer __section from compiler_attributes.h

On Mon, Aug 12, 2019 at 11:52 PM Nick Desaulniers wrote: > > Reported-by: Sedat Dilek > Suggested-by: Josh Poimboeuf > Signed-off-by: Nick Desaulniers Tested-by: Sedat Dilek [ Linux v5.3-rc5 ] Patchset "for-5.3/x86-section-name-escaping": include/linux/compiler.h

Re: [PATCH 13/16] include/asm-generic: prefer __section from compiler_attributes.h

On Mon, Aug 19, 2019 at 7:52 PM Naveen N. Rao wrote: > > Nick Desaulniers wrote: > > Reported-by: Sedat Dilek > > Suggested-by: Josh Poimboeuf > > Signed-off-by: Nick Desaulniers > > --- > > Acked-by: Naveen N. Rao > Tested-by: Sedat Dilek [ Linux v5

Re: x86 - clang / objtool status

On Mon, Jul 22, 2019 at 5:40 PM Sedat Dilek wrote: > > On Fri, Jul 19, 2019 at 3:48 PM Sedat Dilek wrote: > > > > > First of all I find out that it is possible to download and apply the > > > series (here: v2) from patchwork (see [1]). > > > I highly a

Re: [PATCH 1/2] drm/i915: Remove redundant user_access_end() from __copy_from_user() error path

user_access_end() in its error path adds an extra unnecessary CLAC. > > Fixes: 0b2c8f8b6b0c ("i915: fix missing user_access_end() in page fault > exception case") > Reported-by: Thomas Gleixner > Reported-by: Sedat Dilek > Acked-by: Peter Zijlstra (Intel) >

Re: [PATCH] objtool: Improve UACCESS coverage

On Wed, Jul 24, 2019 at 8:30 PM Sedat Dilek wrote: > > On Wed, Jul 24, 2019 at 6:48 PM Peter Zijlstra wrote: > > > > On Wed, Jul 24, 2019 at 04:10:40PM +0200, Peter Zijlstra wrote: > > > And that most certainly should trigger... > > > > > > Let me gd

Re: [PATCH] objtool: Improve UACCESS coverage

ool: eb_copy_relocations.isra.34()+0x0: <=== (func) > > Reported-by: Josh Poimboeuf > Reported-by: Thomas Gleixner > Signed-off-by: Peter Zijlstra (Intel) Thanks Peter Z. and Josh P.! Reported-by: Sedat Dilek Tested-by: Sedat Dilek [1] https://github.com/ClangBuiltLinux/linux/iss

Re: [PATCH -next] iwlwifi: dbg: work around clang bug by marking debug strings static

On Tue, Jul 16, 2019 at 11:15 PM Luca Coelho wrote: > > On Tue, 2019-07-16 at 10:28 -0700, Nick Desaulniers wrote: > > On Thu, Jul 11, 2019 at 7:15 PM Joe Perches wrote: > > > On Thu, 2019-07-11 at 17:17 -0700, Nick Desaulniers wrote: > > > > Commit r353569 in prerelease Clang-9 is producing a

Re: x86 - clang / objtool status

On Fri, Jul 19, 2019 at 3:48 PM Sedat Dilek wrote: > > > First of all I find out that it is possible to download and apply the > > series (here: v2) from patchwork (see [1]). > > I highly appreciate to have this in Josh's Git [2]. > > > > There it

Re: x86 - clang / objtool status

> First of all I find out that it is possible to download and apply the > series (here: v2) from patchwork (see [1]). > I highly appreciate to have this in Josh's Git [2]. > There it is. - sed@ - [1]

Re: linux-next: Tree for Jul 17

On Wed, Jul 17, 2019 at 5:33 PM Darrick J. Wong wrote: > > On Wed, Jul 17, 2019 at 05:30:47PM +0200, Sedat Dilek wrote: > > Hi Steven, Hi Darrick, > > > > Unfortunately, my build-script is not working anymore. > > > > I am using builddeb/mkdebian script

Re: linux-next: Tree for Jul 17

Hi Steven, Hi Darrick, Unfortunately, my build-script is not working anymore. I am using builddeb/mkdebian scripts. [ BUILD-LOG ] ... set -e; mkdir -p include/config/; { echo "5.2.0$(/bin/bash ./scripts/setlocalversion .)"; } > include/config/kernel.release.tmp; if [ -r

Re: [PATCH 2/2] x86: kvm: avoid constant-conversion warning

> -- > 2.20.0 > > -- > You received this message because you are subscribed to the Google Groups > "Clang Built Linux" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clang-built-linux+unsubscr...@googlegroups.com. >

Re: [PATCH] xen/trace: avoid clang warning on function pointers

ems to > be the only instance we get in the entire kernel today. > Shut up the warning by making it a void pointer in the exported > structure. > Thanks for bringing this up (again), Arnd. As this is a known CBL issue please add... Link: https://github.com/ClangBuiltLinux/linux/issues/97

Re: [PATCH -mm 1/1] signal: simplify set_user_sigmask/restore_user_sigmask

On Thu, Jun 6, 2019 at 9:28 AM Oleg Nesterov wrote: > > On 06/05, Oleg Nesterov wrote: > > > > +int set_user_sigmask(const sigset_t __user *umask, size_t sigsetsize) > > { > > - if (!usigmask) > > - return 0; > > + sigset_t *kmask; > > Typo, this obviously should be > >

[PATCH 2/2] NFC: nxp-nci: Fix recommendation for NFC_NXP_NCI_I2C Kconfig

This is a simple cleanup to the Kconfig help text as discussed in [1]. [1] https://marc.info/?t=15577443561=1=2 Suggested-by: Andy Shevchenko Suggested-by: Oleg Zhurakivskyy Signed-off-by: Sedat Dilek --- drivers/nfc/nxp-nci/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion

[PATCH 1/2] NFC: nxp-nci: Clarify on supported chips

hevchenko Suggested-by: Oleg Zhurakivskyy Signed-off-by: Sedat Dilek --- drivers/nfc/nxp-nci/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/nfc/nxp-nci/Kconfig b/drivers/nfc/nxp-nci/Kconfig index a28c4265354d..16473cfcb1d8 100644 --- a/drivers/nfc/nxp-nci/K

Re: Linux v5.1.1

On Sat, May 11, 2019 at 7:52 AM Greg Kroah-Hartman wrote: > > On Fri, May 10, 2019 at 09:47:14PM +0200, Sedat Dilek wrote: > > Hi Greg, > > > > I have seen that all other Linux-stable Git branches got a new release. > > > > What happened to Linux-stable-

Linux v5.1.1

Hi Greg, I have seen that all other Linux-stable Git branches got a new release. What happened to Linux-stable-5.1.y and v5.1.1 release? Is there a show-stopper? Thanks. Regards, - Sedat - [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/

Re: [PATCH] Makefile: Don't try to add '-fcatch-undefined-behavior' flag

On Thu, May 9, 2019 at 1:49 PM Nathan Chancellor wrote: > > This is no longer a valid option in clang, it was removed in 3.5, which > we don't support. > > https://github.com/llvm/llvm-project/commit/cb3f812b6b9fab8f3b41414f24e90222170417b4 > Cool. Can you test with -mglobal-merge (inverted

Re: [PATCH] kbuild: add some extra warning flags unconditionally

On Thu, May 9, 2019 at 8:47 AM Masahiro Yamada wrote: > > These flags are documented in the GCC 4.6 manual, and recognized by > Clang as well. Let's rip off the cc-option / cc-disable-warning switches. > BTW, is this a speedup when doing CC/LD FLAGS etc checks unconditionally? Asking in general

Re: [PATCH] kbuild: add -Wvla flag unconditionally

On Thu, May 9, 2019 at 8:46 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. > [ CC Kees who did the VLA removal/cleanup ] Looks good to me. Reviewed-by: Sedat Dilek > Signed-o

Re: [PATCH] kbuild: add most of Clang-specific flags unconditionally

Signed-off-by: Masahiro Yamada Looks good to me. Reviewed-by: Sedat Dilek Just as sidenote: I experimented with a snapshot version of clang-9 and lld-9 and could build, link and boot on bare-metal with '-mglobal-merge' on Debian/buster AMD64. But forgot to document in [1]. [1] https://github.c

Re: CBL issue #431: lld: x86_64: sysfs: cannot create duplicate filename $module/.rodata.cst{16,32}

On Mon, Apr 8, 2019 at 5:04 PM Denys Vlasenko wrote: > > On 4/8/19 4:57 PM, Sedat Dilek wrote: > > We have arch/x86/crypto/chacha-avx2-x86_64.S and > > arch/x86/crypto/chacha-avx512vl-x86_64.S: > > > > .rodata.cst32.CTR2BL > > .rodata.cst32.CTR4BL > > .ro

Re: CBL issue #431: lld: x86_64: sysfs: cannot create duplicate filename $module/.rodata.cst{16,32}

On Mon, Apr 8, 2019 at 5:04 PM Denys Vlasenko wrote: > > On 4/8/19 4:57 PM, Sedat Dilek wrote: > > We have arch/x86/crypto/chacha-avx2-x86_64.S and > > arch/x86/crypto/chacha-avx512vl-x86_64.S: > > > > .rodata.cst32.CTR2BL > > .rodata.cst32.CTR4BL > > .ro

Re: CBL issue #431: lld: x86_64: sysfs: cannot create duplicate filename $module/.rodata.cst{16,32}

We have arch/x86/crypto/chacha-avx2-x86_64.S and arch/x86/crypto/chacha-avx512vl-x86_64.S: .rodata.cst32.CTR2BL .rodata.cst32.CTR4BL .rodata.cst32.CTR2BL .rodata.cst32.CTR4BL ...and in arch/x86/crypto/sha256-avx2-asm.S and arch/x86/crypto/sha512-avx2-asm.S: .rodata.cst32.PSHUFFLE_BYTE_FLIP_MASK

Re: CBL issue #431: lld: x86_64: sysfs: cannot create duplicate filename $module/.rodata.cst{16,32}

On Mon, Apr 8, 2019 at 4:42 PM Denys Vlasenko wrote: > > On 4/8/19 4:34 PM, Sedat Dilek wrote: > > v2: > > > > sdi@iniza:~/src/linux-kernel/linux$ git --no-pager diff > > diff --git a/arch/x86/crypto/camellia-aesni-avx-asm_64.S > > b/arch/x86/crypto/c

Re: CBL issue #431: lld: x86_64: sysfs: cannot create duplicate filename $module/.rodata.cst{16,32}

On Mon, Apr 8, 2019 at 4:29 PM Denys Vlasenko wrote: > > On 4/8/19 4:23 PM, Sedat Dilek wrote: > > For the .rodata.cst16 part you mean sth. like this? > > yes, see below > > > --- a/arch/x86/crypto/camellia-aesni-avx-asm_64.S > > +++ b/arch/x86/crypto/camellia

Re: CBL issue #431: lld: x86_64: sysfs: cannot create duplicate filename $module/.rodata.cst{16,32}

On Mon, Apr 8, 2019 at 3:58 PM Denys Vlasenko wrote: > > On 4/8/19 3:56 PM, Denys Vlasenko wrote: > > I propose to change section name, append _module_ name and optionally > > a comment why this is done: > > > > /* NB: section is mergeable, all elements must be aligned 16-byte blocks > > */ >

CBL issue #431: lld: x86_64: sysfs: cannot create duplicate filename $module/.rodata.cst{16,32}

Hi Denys, I fell over your commit "crypto: x86 - make constants readonly, allow linker to merge them" [1] while digging into ClangBuiltLinux issue 431 [0]. I see the following in my dmesg-log: $ grep sysfs: dmesg_5.0.4-rc1-1-amd64-cbl-asmgoto.txt [Fri Mar 22 10:32:09 2019] sysfs: cannot create

Re: [PATCH v3] Makefile: lld: tell clang to use lld

t; Link: https://github.com/ClangBuiltLinux/linux/issues/357 > Suggested-by: Nathan Chancellor > Suggested-by: Masahiro Yamada > Signed-off-by: Nick Desaulniers Thanks for bringing this up again, Nick. Suggested-by: Sedat Dilek (see [1]). I suggest to do a separate patch on the move of &q

Re: [PATCH v4] lib/string.c: implement a basic bcmp

On Fri, Mar 22, 2019 at 8:17 AM Rasmus Villemoes wrote: > > On 21/03/2019 18.02, Nick Desaulniers wrote: > > On Wed, Mar 20, 2019 at 7:11 PM Andrew Morton > > wrote: > >> > > > > Further, I can drop some of the __GNUC__ < 4 code in > > arch/x86/include/asm/string_32.h. > > Already on its way to

Re: [PATCH RFC v2] fcoe: make use of fip_mode enum complete

On Fri, Feb 15, 2019 at 8:35 AM Hannes Reinecke wrote: > > On 2/12/19 11:42 PM, Nathan Chancellor wrote: > > On Tue, Feb 12, 2019 at 08:50:04AM +0100, Sedat Dilek wrote: > >> On Mon, Feb 11, 2019 at 6:53 PM Nathan Chancellor > >> wrote: > >>> > >&g

Re: [PATCH RFC v2] fcoe: make use of fip_mode enum complete

On Mon, Feb 11, 2019 at 6:53 PM Nathan Chancellor wrote: > > On Mon, Feb 11, 2019 at 06:07:51PM +0100, Sedat Dilek wrote: > > From: Sedat Dilek > > > > commit 1917d42d14b7 ("fcoe: use enum for fip_mode") introduces a separate > > enum for the fip_mode

[PATCH RFC v2] fcoe: make use of fip_mode enum complete

From: Sedat Dilek commit 1917d42d14b7 ("fcoe: use enum for fip_mode") introduces a separate enum for the fip_mode that shall be used during initialisation handling until it is passed to fcoe_ctrl_link_up to set the initial fip_state. That change was incomplete and gcc quietly

Re: [PATCH 3/4] Makefile: lld: tell clang to use lld

On Mon, Feb 11, 2019 at 4:33 PM Masahiro Yamada wrote: [ ... ] > > > > Link: https://github.com/ClangBuiltLinux/linux/issues/342 > > > > Suggested-by: Nathan Chancellor > > > > Signed-off-by: Nick Desaulniers > > > > --- > > > > Makefile | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > >

Re: [PATCH] fcoe: make use of fip_mode enum complete

Hi Lukas, I have tested your patch with LLVM/Clang from Git (will get version 9) with (RFC) asm-goto support. I was able to build with CONFIG_FCOE=m and CONFIG_LIBFCOE=m and boot on bare metal. Feel free to add my... Tested-by: Sedat Dilek If you want to send out a v2 please feel free

Re: [PATCH 3/4] Makefile: lld: tell clang to use lld

Hi Nick, why don't you simply check for CONFIG_LD_IS_LLD existing (when [1] applied)? If you want a specific version of ld.lld (you mentioned kernel module linking failure was fixed recently) why not transfer this into a scripts/lld-version.sh file? Greetings, - Sedat - [1]

Re: [PATCH 1/4] init/Kconfig: add config support for detecting linker

Feel free to add my... Suggested-by: Sedat Dilek (see my comment in [1]) [1] https://github.com/ClangBuiltLinux/linux/issues/341#issuecomment-459788558

Re: jump_label: move 'asm goto' support test to Kconfig

fig Git pulls were latest commits. Tested-by: Sedat Dilek [ x86 with LLVM/Clang v7 and v8 (snapshot) ] Thanks. Regards, - Sedat -

Re: [PATCH] kbuild, x86: revert macros in extended asm workarounds

not build external modules > after 'make clean') > > Patching around the build system would make the code even uglier. > > Given that this issue will be solved in a cleaner way sooner or later, > let's revert the in-kernel workarounds, and wait for GCC 9. > > Repo

Re: [PATCH v2] i2c: Remove '-Wno-deprecated-declarations' compiler warning

> Wolfram Sang hat am 24. August 2018 um 17:01 geschrieben: > > > On Fri, Aug 24, 2018 at 04:19:53PM +0200, Sedat Dilek wrote: > > > Wolfram Sang hat am 24. August 2018 um 16:07 > > > geschrieben: > > > > > > > > > > > >

Re: [PATCH v2] i2c: Remove '-Wno-deprecated-declarations' compiler warning

> Wolfram Sang hat am 24. August 2018 um 17:01 geschrieben: > > > On Fri, Aug 24, 2018 at 04:19:53PM +0200, Sedat Dilek wrote: > > > Wolfram Sang hat am 24. August 2018 um 16:07 > > > geschrieben: > > > > > > > > > > > >

Re: [PATCH v2] i2c: Remove '-Wno-deprecated-declarations' compiler warning

> Wolfram Sang hat am 24. August 2018 um 16:07 geschrieben: > > > > > will my patch go to [1]? > > It won't be needed anymore, the __deprecated function will go away until > next week. > The relict in drivers/i2/Makefile should go away, too. - sed@ - [1]

Re: [PATCH v2] i2c: Remove '-Wno-deprecated-declarations' compiler warning

> Wolfram Sang hat am 24. August 2018 um 16:07 geschrieben: > > > > > will my patch go to [1]? > > It won't be needed anymore, the __deprecated function will go away until > next week. > The relict in drivers/i2/Makefile should go away, too. - sed@ - [1]

Re: [PATCH v2] i2c: Remove '-Wno-deprecated-declarations' compiler warning

Hi Wolfram, will my patch go to [1]? Thank you, too. Regards, - Sedat - [1] https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git/log/?h=i2c/for-next > Wolfram Sang hat am 24. August 2018 um 15:01 geschrieben: > > > Sedat, > > > This can be dropped with commit

Re: [PATCH v2] i2c: Remove '-Wno-deprecated-declarations' compiler warning

Hi Wolfram, will my patch go to [1]? Thank you, too. Regards, - Sedat - [1] https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git/log/?h=i2c/for-next > Wolfram Sang hat am 24. August 2018 um 15:01 geschrieben: > > > Sedat, > > > This can be dropped with commit

[PATCH] i2c: Remove '-Wno-deprecated-declarations' compiler warning

cc-disable-warning, no-deprecated-declarations) This has the advantage to check if other compilers like GCC support this. NOTE: My compiler is a prerelease of LLVM/Clang version 7. [1] https://clang.llvm.org/docs/DiagnosticsReference.html#wdeprecated-declarations CC: Nick Desaulniers Signed-off

[PATCH] i2c: Remove '-Wno-deprecated-declarations' compiler warning

cc-disable-warning, no-deprecated-declarations) This has the advantage to check if other compilers like GCC support this. NOTE: My compiler is a prerelease of LLVM/Clang version 7. [1] https://clang.llvm.org/docs/DiagnosticsReference.html#wdeprecated-declarations CC: Nick Desaulniers Signed-off

[PATCH v2] i2c: Remove '-Wno-deprecated-declarations' compiler warning

cc-disable-warning, deprecated-declarations) This has the advantage to check if other compilers like GCC support this. NOTE: My compiler is a prerelease of LLVM/Clang version 7. [1] https://clang.llvm.org/docs/DiagnosticsReference.html#wdeprecated-declarations CC: Nick Desaulniers Signed-off-by: S

[PATCH v2] i2c: Remove '-Wno-deprecated-declarations' compiler warning

cc-disable-warning, deprecated-declarations) This has the advantage to check if other compilers like GCC support this. NOTE: My compiler is a prerelease of LLVM/Clang version 7. [1] https://clang.llvm.org/docs/DiagnosticsReference.html#wdeprecated-declarations CC: Nick Desaulniers Signed-off-by: S

Re: Merge branch 'l1tf-final' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

On Fri, Aug 17, 2018 at 10:33 AM, Vegard Nossum wrote: > On 16 August 2018 at 17:42, Richard Weinberger > wrote: >> On Thu, Aug 16, 2018 at 2:58 PM Sedat Dilek wrote: >>> >>> Hi Linus, >>> >>> I am here on Linux v4.18 and tried first to me

Re: Merge branch 'l1tf-final' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

On Fri, Aug 17, 2018 at 10:33 AM, Vegard Nossum wrote: > On 16 August 2018 at 17:42, Richard Weinberger > wrote: >> On Thu, Aug 16, 2018 at 2:58 PM Sedat Dilek wrote: >>> >>> Hi Linus, >>> >>> I am here on Linux v4.18 and tried first to me

Re: Merge branch 'l1tf-final' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

On Thu, Aug 16, 2018 at 7:14 PM, Linus Torvalds wrote: > On Thu, Aug 16, 2018 at 12:37 AM Sedat Dilek wrote: >>> >> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch. >> Unfortunately, this is no more available in the tip Git-tree. > > Ri

Re: Merge branch 'l1tf-final' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

On Thu, Aug 16, 2018 at 7:14 PM, Linus Torvalds wrote: > On Thu, Aug 16, 2018 at 12:37 AM Sedat Dilek wrote: >>> >> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch. >> Unfortunately, this is no more available in the tip Git-tree. > > Ri

Re: Merge branch 'l1tf-final' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

On Thu, Aug 16, 2018 at 5:42 PM, Richard Weinberger wrote: > On Thu, Aug 16, 2018 at 2:58 PM Sedat Dilek wrote: >> >> Hi Linus, >> >> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch. >> Unfortunately, this is no more available in t

Re: Merge branch 'l1tf-final' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

On Thu, Aug 16, 2018 at 5:42 PM, Richard Weinberger wrote: > On Thu, Aug 16, 2018 at 2:58 PM Sedat Dilek wrote: >> >> Hi Linus, >> >> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch. >> Unfortunately, this is no more available in t

Re: Merge branch 'l1tf-final' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Hi Linus, I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch. Unfortunately, this is no more available in the tip Git-tree. Then I saw Linux v4.18.1 which includes all the above stuff. I tried to 'git cherry-pick -m 1 958f338e96f874a0d29442396d6adf9c1e17aa2d'. I know

Re: Merge branch 'l1tf-final' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Hi Linus, I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch. Unfortunately, this is no more available in the tip Git-tree. Then I saw Linux v4.18.1 which includes all the above stuff. I tried to 'git cherry-pick -m 1 958f338e96f874a0d29442396d6adf9c1e17aa2d'. I know

Re: [PATCH] x86, relocs: Add __end_rodata_aligned to S_REL

@@ static const char * const sym_regex_kernel[S_NSYMTYPES] = { > "__tracedata_(start|end)|" > "__(start|stop)_notes|" > "__end_rodata|" > + "__end_rodata_aligned|" > "__initramfs_start|" > "(jiffies|jiffies_64)|" > #if ELF_BITS == 64 > -- > 2.16.4 > Tested-by: Sedat Dilek

Re: [PATCH] x86, relocs: Add __end_rodata_aligned to S_REL

@@ static const char * const sym_regex_kernel[S_NSYMTYPES] = { > "__tracedata_(start|end)|" > "__(start|stop)_notes|" > "__end_rodata|" > + "__end_rodata_aligned|" > "__initramfs_start|" > "(jiffies|jiffies_64)|" > #if ELF_BITS == 64 > -- > 2.16.4 > Tested-by: Sedat Dilek

Re: [PATCH] x86/irqflags: provide a declaration for native_save_fl

t gcc >= 4.9. >> >> Cc: sta...@vger.kernel.org # 4.17, 4.14, 4.9, 4.4 >> Reported-by: David Laight >> Reported-by: Jean Delvare >> Signed-off-by: Nick Desaulniers > > You can add my: > > Tested-by: David Laight > Tested-by: Sedat Dilek On top of Linux v4.18-rc8 with clang version 7.0.0-svn338205. - sed@ -

Re: [PATCH] x86/irqflags: provide a declaration for native_save_fl

t gcc >= 4.9. >> >> Cc: sta...@vger.kernel.org # 4.17, 4.14, 4.9, 4.4 >> Reported-by: David Laight >> Reported-by: Jean Delvare >> Signed-off-by: Nick Desaulniers > > You can add my: > > Tested-by: David Laight > Tested-by: Sedat Dilek On top of Linux v4.18-rc8 with clang version 7.0.0-svn338205. - sed@ -

[2/3] x86/build: use -std=gnu89 for proper extern inline semantics

[ CC me I'am not subscribed to LKML and linux-kbuild ] [ Unsure if this the complete CC list of the original posting [0] ] Hi, I am discovering clang's compiler flags as HPA writes in [0]... "-fgnu-inlines would be a better option. We could also simply #define inline inline

[2/3] x86/build: use -std=gnu89 for proper extern inline semantics

[ CC me I'am not subscribed to LKML and linux-kbuild ] [ Unsure if this the complete CC list of the original posting [0] ] Hi, I am discovering clang's compiler flags as HPA writes in [0]... "-fgnu-inlines would be a better option. We could also simply #define inline inline

Re: module: x86/modules: Skipping invalid relocation target, existing value is nonzero for type 1

On Fri, Jun 1, 2018 at 6:01 PM, Sedat Dilek wrote: > Hi, > > can someone tell me what this exactly means? > > What is the root cause for this? > GNU binutils/ld? > Compiler? > Curently I test with clang-7. > VirtualBox and compiler incompatible? > > Steps to

Re: module: x86/modules: Skipping invalid relocation target, existing value is nonzero for type 1

On Fri, Jun 1, 2018 at 6:01 PM, Sedat Dilek wrote: > Hi, > > can someone tell me what this exactly means? > > What is the root cause for this? > GNU binutils/ld? > Compiler? > Curently I test with clang-7. > VirtualBox and compiler incompatible? > > Steps to

module: x86/modules: Skipping invalid relocation target, existing value is nonzero for type 1

Hi, can someone tell me what this exactly means? What is the root cause for this? GNU binutils/ld? Compiler? Curently I test with clang-7. VirtualBox and compiler incompatible? Steps to reproduce the failure... root# modprobe -v vboxdrv insmod

module: x86/modules: Skipping invalid relocation target, existing value is nonzero for type 1

Hi, can someone tell me what this exactly means? What is the root cause for this? GNU binutils/ld? Compiler? Curently I test with clang-7. VirtualBox and compiler incompatible? Steps to reproduce the failure... root# modprobe -v vboxdrv insmod

Re: [clang] stack protector and f1f029c7bf

plan to push patches from the 1st solution to Linus uptream? [ LLVM/Clang side ] What about backporting "no_stack_protector" to LLVM/Clang v6.0.1? Thanks to all involved people. Sunshiny greetings from North-West Germany, - Sedat - From c68cef9048e96af1211a57bd7a5f6ca6efdfc7b2 Mon Sep 17 0

Re: [clang] stack protector and f1f029c7bf

hes from the 1st solution to Linus uptream? [ LLVM/Clang side ] What about backporting "no_stack_protector" to LLVM/Clang v6.0.1? Thanks to all involved people. Sunshiny greetings from North-West Germany, - Sedat - From c68cef9048e96af1211a57bd7a5f6ca6efdfc7b2 Mon Sep 17 00:00:00 2001 Fro

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

Just for the records... [ OBJDUMP irq_work_tick() ] $ objdump -d -S --start-address=0x$(grep irq_work_tick System.map | sed -e "s/ \+.*//") vmlinux | less [ OBJDUMP native_save_fl() ] $ objdump -d -S --start-address=0x$(grep native_save_fl System.map | sed -e "s/ \+.*//") vmlinux | less -

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

Just for the records... [ OBJDUMP irq_work_tick() ] $ objdump -d -S --start-address=0x$(grep irq_work_tick System.map | sed -e "s/ \+.*//") vmlinux | less [ OBJDUMP native_save_fl() ] $ objdump -d -S --start-address=0x$(grep native_save_fl System.map | sed -e "s/ \+.*//") vmlinux | less -

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

For the sake of completeness... [ CLANG VERSION ] # dpkg -l | grep clang-7 ii clang-7 1:7~svn332830-1~exp1+0~20180521091322.1776~1.gbp198359 amd64C, C++ and Objective-C compiler [ OBJDUMP native_save_fl() ] $ objdump -d -S --start-address=0x$(grep native_save_fl System.map | sed -e

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

For the sake of completeness... [ CLANG VERSION ] # dpkg -l | grep clang-7 ii clang-7 1:7~svn332830-1~exp1+0~20180521091322.1776~1.gbp198359 amd64C, C++ and Objective-C compiler [ OBJDUMP native_save_fl() ] $ objdump -d -S --start-address=0x$(grep native_save_fl System.map | sed -e

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

xen_mc_entry(mc_entry_size); args = mcs.args; args->op.arg2.vcpumask = to_cpumask(args->mask); -- 2.17.0 From 81eceff6658d6e750c7c0d0810ec3d6e66a0cd51 Mon Sep 17 00:00:00 2001 From: Sedat Dilek <sedat.di...@credativ.de> Date: Tue, 22 May 2018 12:00:56 +0200 Subject: [PATCH 3/4] co

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

mcs = xen_mc_entry(mc_entry_size); args = mcs.args; args->op.arg2.vcpumask = to_cpumask(args->mask); -- 2.17.0 From 81eceff6658d6e750c7c0d0810ec3d6e66a0cd51 Mon Sep 17 00:00:00 2001 From: Sedat Dilek Date: Tue, 22 May 2018 12:00:56 +0200 Subject: [PATCH 3/4] compiler-clang.h: Add __n

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

On Tue, May 22, 2018 at 10:04 AM, Sedat Dilek <sedat.di...@gmail.com> wrote: > On Tue, May 22, 2018 at 9:39 AM, Sedat Dilek <sedat.di...@gmail.com> wrote: >> On Sat, May 19, 2018 at 12:54 AM, Nick Desaulniers >> <nick.desaulni...@gmail.com> wrote: >>>

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

On Tue, May 22, 2018 at 10:04 AM, Sedat Dilek wrote: > On Tue, May 22, 2018 at 9:39 AM, Sedat Dilek wrote: >> On Sat, May 19, 2018 at 12:54 AM, Nick Desaulniers >> wrote: >>> Sedat, >>> Thanks for the report. We have a fix ready in >>> https://bug

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

On Tue, May 22, 2018 at 9:39 AM, Sedat Dilek <sedat.di...@gmail.com> wrote: > On Sat, May 19, 2018 at 12:54 AM, Nick Desaulniers > <nick.desaulni...@gmail.com> wrote: >> Sedat, >> Thanks for the report. We have a fix ready in >> https://bugs.llvm.org/show_bu

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

On Tue, May 22, 2018 at 9:39 AM, Sedat Dilek wrote: > On Sat, May 19, 2018 at 12:54 AM, Nick Desaulniers > wrote: >> 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

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

On Sat, May 19, 2018 at 12:54 AM, Nick Desaulniers wrote: > 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?

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

On Sat, May 19, 2018 at 12:54 AM, Nick Desaulniers wrote: > 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, Can you give

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

On Sat, May 19, 2018 at 12:54 AM, Nick Desaulniers wrote: > 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?

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

On Sat, May 19, 2018 at 12:54 AM, Nick Desaulniers wrote: > 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, Hi Nick,

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

On Mon, May 7, 2018 at 7:49 PM, Matthias Kaehlcke <m...@chromium.org> wrote: > On Sun, May 06, 2018 at 09:42:09AM +0200, Sedat Dilek wrote: >> On Wed, Apr 25, 2018 at 1:06 AM, Matthias Kaehlcke <m...@chromium.org> wrote: >> > On Tue, Apr 24, 2018 at 01:54:29PM +020

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

On Mon, May 7, 2018 at 7:49 PM, Matthias Kaehlcke wrote: > On Sun, May 06, 2018 at 09:42:09AM +0200, Sedat Dilek wrote: >> On Wed, Apr 25, 2018 at 1:06 AM, Matthias Kaehlcke wrote: >> > On Tue, Apr 24, 2018 at 01:54:29PM +0200, Sedat Dilek wrote: >> >> Hi Matthia

Re: [linux-firmware] Version in WHENCE file

On Sun, May 6, 2018 at 3:07 PM, Luciano Coelho <luciano.coe...@intel.com> wrote: > On Sun, 2018-05-06 at 14:46 +0200, Sedat Dilek wrote: >> Hi Luca, >> >> I hope I catched the correct MLs (not sure if linux-firmware has a >> ML, >> I did not found any in t

Re: [linux-firmware] Version in WHENCE file

On Sun, May 6, 2018 at 3:07 PM, Luciano Coelho wrote: > On Sun, 2018-05-06 at 14:46 +0200, Sedat Dilek wrote: >> Hi Luca, >> >> I hope I catched the correct MLs (not sure if linux-firmware has a >> ML, >> I did not found any in the MAINTAINERS file). >>

[linux-firmware] Version in WHENCE file

mware.git/commit/?id=1f4dbd8cb94ec37497e58627a127058d53c5968f From 576d30ace8140ca7b5c8a276f67da1cb2ebfb0c2 Mon Sep 17 00:00:00 2001 From: Sedat Dilek <sedat.di...@credativ.de> Date: Sun, 6 May 2018 14:44:54 +0200 Subject: [PATCH] WHENCE: Fix typo

[linux-firmware] Version in WHENCE file

mware.git/commit/?id=1f4dbd8cb94ec37497e58627a127058d53c5968f From 576d30ace8140ca7b5c8a276f67da1cb2ebfb0c2 Mon Sep 17 00:00:00 2001 From: Sedat Dilek Date: Sun, 6 May 2018 14:44:54 +0200 Subject: [PATCH] WHENCE: Fix typo Version --- WHENCE | 58 +-

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

[...] > Moreover, a test-case can be helpful, e.g. "Is clang clobbering RCX?" > when it's a clang-bug. > > I tried to find some suitable test-case myself. > > The clang-source has a test-dir, but this is new to me. > > I tried to run a single test like test/Sema/asm.c in [1] with > llvm-tools

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

[...] > Moreover, a test-case can be helpful, e.g. "Is clang clobbering RCX?" > when it's a clang-bug. > > I tried to find some suitable test-case myself. > > The clang-source has a test-dir, but this is new to me. > > I tried to run a single test like test/Sema/asm.c in [1] with > llvm-tools

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

On Sun, May 6, 2018 at 9:41 AM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Sun, May 6, 2018 at 8:35 AM, Sedat Dilek <sedat.di...@gmail.com> wrote: >> On Mon, Apr 23, 2018 at 7:42 PM, Matthias Kaehlcke <m...@chromium.org> wrote: >> [...] >>>> [ A

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

On Sun, May 6, 2018 at 9:41 AM, Dmitry Vyukov wrote: > On Sun, May 6, 2018 at 8:35 AM, Sedat Dilek wrote: >> On Mon, Apr 23, 2018 at 7:42 PM, Matthias Kaehlcke wrote: >> [...] >>>> [ ASM-GOTO ] >>>> >>>> Foremore, I have seen you have a "r

Re: [PATCH] Makefile: Fix typo s/HOST_LOADLIBES/HOST_LOADLIBS

> Masahiro Yamada <yamada.masah...@socionext.com> hat am 24. April 2018 um > 17:51 geschrieben: > > > 2018-04-24 17:44 GMT+09:00 Sedat Dilek <sedat.di...@credativ.de>: > > Signed-off-by: Sedat Dilek <sedat.di...@credativ.de> > > --- > > Makefi

Re: [PATCH] Makefile: Fix typo s/HOST_LOADLIBES/HOST_LOADLIBS

> Masahiro Yamada hat am 24. April 2018 um > 17:51 geschrieben: > > > 2018-04-24 17:44 GMT+09:00 Sedat Dilek : > > Signed-off-by: Sedat Dilek > > --- > > Makefile | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff

Re: Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

On Tue, Apr 24, 2018 at 5:22 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Apr 24, 2018 at 6:28 AM, Sedat Dilek <sedat.di...@gmail.com> wrote: >> >> $ objdump -S clang-eflag.o >> >> Does this now look good? > > Looks fine to m

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