[PATCH] netlink: put module reference if dump start fails

ounter back to zero, especially since module.c still uses atomic_inc instead of refcount_inc. This patch expands the error path to simply call module_put if cb->start() fails. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- This probably should be queued up for stable. net/netli

[PATCH] netlink: put module reference if dump start fails

ounter back to zero, especially since module.c still uses atomic_inc instead of refcount_inc. This patch expands the error path to simply call module_put if cb->start() fails. Signed-off-by: Jason A. Donenfeld --- This probably should be queued up for stable. net/netlink/af_netlink.c | 4 +++

Re: [PATCH] random: always fill buffer in get_random_bytes_wait

Hi Ted, Can you apply this? Thanks, Jason

Re: [PATCH] random: always fill buffer in get_random_bytes_wait

Hi Ted, Can you apply this? Thanks, Jason

[PATCH] random: always fill buffer in get_random_bytes_wait

n the case of an interruption. This is both a defense in depth measure against inevitable programming bugs, as well as a means of making the API a bit more useful. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- include/linux/random.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff

[PATCH] random: always fill buffer in get_random_bytes_wait

n the case of an interruption. This is both a defense in depth measure against inevitable programming bugs, as well as a means of making the API a bit more useful. Signed-off-by: Jason A. Donenfeld --- include/linux/random.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/include/linux/

Re: [kernel-hardening] Re: [PATCH v2] cpu: do not leak vulnerabilities to unprivileged users

On Fri, Jan 26, 2018 at 5:43 PM, Alan Cox wrote: > a) The info is already trivially accessible via /proc/cpuinfo No, /proc/cpuinfo shows if the CPU itself has these bugs, but doesn't show whether or not the kernel has gone to lengths to mitigate these bugs. # grep -o

Re: [kernel-hardening] Re: [PATCH v2] cpu: do not leak vulnerabilities to unprivileged users

On Fri, Jan 26, 2018 at 5:43 PM, Alan Cox wrote: > a) The info is already trivially accessible via /proc/cpuinfo No, /proc/cpuinfo shows if the CPU itself has these bugs, but doesn't show whether or not the kernel has gone to lengths to mitigate these bugs. # grep -o 'bugs.*cpu_meltdown' -m1

[PATCH v2] cpu: do not leak vulnerabilities to unprivileged users

to target. So, this patch changes the permissions to 0400 to make the attacker's job slightly less easy. While we're at it, we clean up the leak in dmesg too. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- v2 handles dmesg too. arch/x86/kernel/cpu/bugs.c | 1 - drivers/base

[PATCH v2] cpu: do not leak vulnerabilities to unprivileged users

to target. So, this patch changes the permissions to 0400 to make the attacker's job slightly less easy. While we're at it, we clean up the leak in dmesg too. Signed-off-by: Jason A. Donenfeld --- v2 handles dmesg too. arch/x86/kernel/cpu/bugs.c | 1 - drivers/base/cpu.c | 6 +++--- 2 files

Re: [kernel-hardening] Re: [PATCH] cpu: do not leak vulnerabilities to unprivileged users

On Thu, Jan 25, 2018 at 2:34 PM, Alan Cox wrote: > As you observe any attacker can already trivially ascertain whether > protection is on, so there is no point pretending file permissions > magically stop that. In fact the information is already in cpuinfo. Actually

Re: [kernel-hardening] Re: [PATCH] cpu: do not leak vulnerabilities to unprivileged users

On Thu, Jan 25, 2018 at 2:34 PM, Alan Cox wrote: > As you observe any attacker can already trivially ascertain whether > protection is on, so there is no point pretending file permissions > magically stop that. In fact the information is already in cpuinfo. Actually the other place it leaks is

[PATCH] cpu: do not leak vulnerabilities to unprivileged users

to target. So, this patch changes the permissions to 0400 to make the attacker's job slightly less easy. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- drivers/base/cpu.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c

[PATCH] cpu: do not leak vulnerabilities to unprivileged users

to target. So, this patch changes the permissions to 0400 to make the attacker's job slightly less easy. Signed-off-by: Jason A. Donenfeld --- drivers/base/cpu.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c index d99038487a0d

[PATCH] arm64: support __int128 with clang

same type of makefile conditional used elsewhere in the tree. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- arch/arm64/Makefile | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index b481b4a7c011..16c2e8b58546 100644 --- a/arch/arm6

[PATCH] arm64: support __int128 with clang

same type of makefile conditional used elsewhere in the tree. Signed-off-by: Jason A. Donenfeld --- arch/arm64/Makefile | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index b481b4a7c011..16c2e8b58546 100644 --- a/arch/arm64/Makefile +++ b/

[PATCH] arch/um: compile with modern headers

Recent libcs have gotten a bit more strict, so we actually need to include the right headers and use the right types. This enables UML to compile again. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: sta...@vger.kernel.org --- Rebased on linux-next, by request. arch/um/os-Linux/

[PATCH] arch/um: compile with modern headers

Recent libcs have gotten a bit more strict, so we actually need to include the right headers and use the right types. This enables UML to compile again. Signed-off-by: Jason A. Donenfeld Cc: sta...@vger.kernel.org --- Rebased on linux-next, by request. arch/um/os-Linux/file.c | 1 + arch/um

[PATCH] arch/um: compile with modern headers

Recent libcs have gotten a bit more strict, so we actually need to include the right headers and use the right types. This enables UML to compile again. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: sta...@vger.kernel.org --- arch/um/os-Linux/file.c | 1 + arch/um/os-Linux/si

[PATCH] arch/um: compile with modern headers

Recent libcs have gotten a bit more strict, so we actually need to include the right headers and use the right types. This enables UML to compile again. Signed-off-by: Jason A. Donenfeld Cc: sta...@vger.kernel.org --- arch/um/os-Linux/file.c | 1 + arch/um/os-Linux/signal.c | 3 ++- arch/x86

Re: WireGuard Upstreaming Roadmap (November 2017)

Hi Dave, On Fri, Dec 8, 2017 at 4:38 PM, David Miller wrote: > Sorry, you cannot force the discussion of a feature which will be submitted > upstream to occur on a private mailing list. > > It is _ABSOLUTELY_ appropriate to discss this on netdev since it is the > netdev

Re: WireGuard Upstreaming Roadmap (November 2017)

Hi Dave, On Fri, Dec 8, 2017 at 4:38 PM, David Miller wrote: > Sorry, you cannot force the discussion of a feature which will be submitted > upstream to occur on a private mailing list. > > It is _ABSOLUTELY_ appropriate to discss this on netdev since it is the > netdev community which must

Re: WireGuard Upstreaming Roadmap (November 2017)

On Thu, Dec 7, 2017 at 11:22 AM, Stefan Tatschner wrote: > I have a question which is related to the involved crypto. As far as I > have understood the protocol and the concept of wireguard > What's your opinion on this? This thread has been picked up on the WireGuard

Re: WireGuard Upstreaming Roadmap (November 2017)

On Thu, Dec 7, 2017 at 11:22 AM, Stefan Tatschner wrote: > I have a question which is related to the involved crypto. As far as I > have understood the protocol and the concept of wireguard > What's your opinion on this? This thread has been picked up on the WireGuard mailing list, not here.

Essential get_user fix missing from 3.10 aarch64

Hi stable/arm/Willy, 1f65c13efef69b6dc908e588f91a133641d8475c is an important commit, because it involves evaluation of pointers from userspace. I'm running into issues with RNDADDTOENTCNT reading bogus values, because p is incremented twice as much as it should in this random.c block:

Essential get_user fix missing from 3.10 aarch64

Hi stable/arm/Willy, 1f65c13efef69b6dc908e588f91a133641d8475c is an important commit, because it involves evaluation of pointers from userspace. I'm running into issues with RNDADDTOENTCNT reading bogus values, because p is incremented twice as much as it should in this random.c block:

[PATCH v2] arm: detect buggy binutils when in thumb2 mode

; DATA XREF: sys_syscall-6BA↓o .text:0002 LDR.W R2, [R9,#8] .text:0006 CMP.W R2, #0xBF00 Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Russell King <li...@armlinux.org.uk> Cc: ni...@redhat.com Cc: s

[PATCH v2] arm: detect buggy binutils when in thumb2 mode

; DATA XREF: sys_syscall-6BA↓o .text:0002 LDR.W R2, [R9,#8] .text:0006 CMP.W R2, #0xBF00 Signed-off-by: Jason A. Donenfeld Cc: Russell King Cc: ni...@redhat.com Cc: sta...@vger.kernel.org --- Had the file mode wr

[PATCH] arm: detect buggy binutils when in thumb2 mode

; DATA XREF: sys_syscall-6BA↓o .text:0002 LDR.W R2, [R9,#8] .text:0006 CMP.W R2, #0xBF00 Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Russell King <li...@armlinux.org.uk> Cc: ni...@redhat.com Cc

[PATCH] arm: detect buggy binutils when in thumb2 mode

; DATA XREF: sys_syscall-6BA↓o .text:0002 LDR.W R2, [R9,#8] .text:0006 CMP.W R2, #0xBF00 Signed-off-by: Jason A. Donenfeld Cc: Russell King Cc: ni...@redhat.com Cc: sta...@vger.kernel.org --- arch/arm/Makefile

Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils

hout adding additional runtime instructions, which isn't acceptable for us. Details are included in the thread below. Thanks, Jason Forwarded conversation Subject: [PATCH] arm: ensure symbol is a thumb symbol in new binutils From: Jason A. Donenfeld <ja...@zx2c4.com>

Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils

hout adding additional runtime instructions, which isn't acceptable for us. Details are included in the thread below. Thanks, Jason Forwarded conversation Subject: [PATCH] arm: ensure symbol is a thumb symbol in new binutils From: Jason A. Donenfeld Date: Tue, Nov 21, 2017

Re: objtool - what if I want to clobber rbp?

Hi Josh, On Wed, Nov 22, 2017 at 4:31 AM, Josh Poimboeuf wrote: > - Make your feature conflict with CONFIG_FRAME_POINTER on x86_64. The > ORC unwinder is now the default anyway for 4.15, and we renamed the > configs, so most people will be actively switching to ORC. >

Re: objtool - what if I want to clobber rbp?

Hi Josh, On Wed, Nov 22, 2017 at 4:31 AM, Josh Poimboeuf wrote: > - Make your feature conflict with CONFIG_FRAME_POINTER on x86_64. The > ORC unwinder is now the default anyway for 4.15, and we renamed the > configs, so most people will be actively switching to ORC. > BTW, since

objtool - what if I want to clobber rbp?

Hi Josh, We're working on some highly optimized assembly crypto primitive implementations for WireGuard. The last 24 hours have been spent trying to make objtool happy with a variety of tricks, some more unfortunate than others. There's still one issue remaining, however, and I just can't figure

objtool - what if I want to clobber rbp?

Hi Josh, We're working on some highly optimized assembly crypto primitive implementations for WireGuard. The last 24 hours have been spent trying to make objtool happy with a variety of tricks, some more unfortunate than others. There's still one issue remaining, however, and I just can't figure

Re: [GIT PULL] usercopy whitelisting for v4.15-rc1

Hi Linus, On Fri, Nov 17, 2017 at 10:13 PM, Linus Torvalds wrote: > As a security person, you need to repeat this mantra: > > "security problems are just bugs" > > and you need to _internalize_ it, instead of scoff at it. It might be news to you that actually

Re: [GIT PULL] usercopy whitelisting for v4.15-rc1

Hi Linus, On Fri, Nov 17, 2017 at 10:13 PM, Linus Torvalds wrote: > As a security person, you need to repeat this mantra: > > "security problems are just bugs" > > and you need to _internalize_ it, instead of scoff at it. It might be news to you that actually some security people scoff at

Re: [PATCH] fork: fix incorrect fput of ->exe_file causing use-after-free

Hey Eric, This is a pretty late response to the thread, but in case you're curious, since Ubuntu forgot to backport this (I already emailed them about it), I actually experienced a set of boxes that hit this bug in the wild and were crashing every 2 weeks or so, when under highload. It's pretty

Re: [PATCH] fork: fix incorrect fput of ->exe_file causing use-after-free

Hey Eric, This is a pretty late response to the thread, but in case you're curious, since Ubuntu forgot to backport this (I already emailed them about it), I actually experienced a set of boxes that hit this bug in the wild and were crashing every 2 weeks or so, when under highload. It's pretty

Re: [PATCH v4] af_netlink: ensure that NLMSG_DONE never fails in dumps

On Sat, Nov 11, 2017 at 11:18 PM, Johannes Berg wrote: > >> > If you're handling this by forcing another read() to procude the >> > NLMSG_DONE, then you have no reason to WARN_ON() here. >> > >> > In fact you are adding a WARN_ON() which is trivially triggerable by >> >

Re: [PATCH v4] af_netlink: ensure that NLMSG_DONE never fails in dumps

On Sat, Nov 11, 2017 at 11:18 PM, Johannes Berg wrote: > >> > If you're handling this by forcing another read() to procude the >> > NLMSG_DONE, then you have no reason to WARN_ON() here. >> > >> > In fact you are adding a WARN_ON() which is trivially triggerable by >> > any user. >> >> I added

WireGuard Upstreaming Roadmap (November 2017)

Hi folks, This relates to WireGuard [0]. Following a very nice conference with the Linux kernel networking subsystem community [1,2], I thought it might be a good idea to spell out the roadmap for the coming months and the trajectory into upstream, based on my discussions with several developers

WireGuard Upstreaming Roadmap (November 2017)

Hi folks, This relates to WireGuard [0]. Following a very nice conference with the Linux kernel networking subsystem community [1,2], I thought it might be a good idea to spell out the roadmap for the coming months and the trajectory into upstream, based on my discussions with several developers

Re: [PATCH v4] af_netlink: ensure that NLMSG_DONE never fails in dumps

On Sat, Nov 11, 2017 at 11:37 AM, David Miller wrote: > Jason I'm already pushing my luck as-is with the pull request I made > yesterday. > > I've seen your original requst to get this in, you don't have to say > it multiple times. > > We can get this into the merge window

Re: [PATCH v4] af_netlink: ensure that NLMSG_DONE never fails in dumps

On Sat, Nov 11, 2017 at 11:37 AM, David Miller wrote: > Jason I'm already pushing my luck as-is with the pull request I made > yesterday. > > I've seen your original requst to get this in, you don't have to say > it multiple times. > > We can get this into the merge window and submit it for

Re: [PATCH v4] af_netlink: ensure that NLMSG_DONE never fails in dumps

IIRC, 4.14 comes tomorrow-ish? If possible, it would be nice to get this in 4.14 before then, so it doesn't have to take time to trickle down through stable. Jason On Thu, Nov 9, 2017 at 1:04 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > The way people generally use net

Re: [PATCH v4] af_netlink: ensure that NLMSG_DONE never fails in dumps

IIRC, 4.14 comes tomorrow-ish? If possible, it would be nice to get this in 4.14 before then, so it doesn't have to take time to trickle down through stable. Jason On Thu, Nov 9, 2017 at 1:04 PM, Jason A. Donenfeld wrote: > The way people generally use netlink_dump is that they fill in the

[PATCH v4] af_netlink: ensure that NLMSG_DONE never fails in dumps

to the brim. This requires keeping track of the errno from ->dump() across calls. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- Can we get this into 4.14? Is there still time? It should also be queued up for stable. Changes v3->v4: - I like long lines. The kernel does not. Wrapp

[PATCH v4] af_netlink: ensure that NLMSG_DONE never fails in dumps

to the brim. This requires keeping track of the errno from ->dump() across calls. Signed-off-by: Jason A. Donenfeld --- Can we get this into 4.14? Is there still time? It should also be queued up for stable. Changes v3->v4: - I like long lines. The kernel does not. Wrapped at 80 now. net/n

Re: [PATCH v3] af_netlink: ensure that NLMSG_DONE never fails in dumps

On Thu, Nov 9, 2017 at 11:02 AM, Johannes Berg wrote: > nit: I think your line got a little long here :) Ack. For v4. > and here Ack. For v4. > >> + nlk->dump_done_errno = INT_MAX; > > I guess positive values aren't really returned from dump? When a positive

Re: [PATCH v3] af_netlink: ensure that NLMSG_DONE never fails in dumps

On Thu, Nov 9, 2017 at 11:02 AM, Johannes Berg wrote: > nit: I think your line got a little long here :) Ack. For v4. > and here Ack. For v4. > >> + nlk->dump_done_errno = INT_MAX; > > I guess positive values aren't really returned from dump? When a positive value is returned, the API

[PATCH v3] af_netlink: ensure that NLMSG_DONE never fails in dumps

to the brim. This requires keeping track of the errno from ->dump() across calls. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- Can we get this into 4.14? Is there still time? It should also be queued up for stable. Changes v2->v3: - Johannes didn't like the subject line of t

[PATCH v3] af_netlink: ensure that NLMSG_DONE never fails in dumps

to the brim. This requires keeping track of the errno from ->dump() across calls. Signed-off-by: Jason A. Donenfeld --- Can we get this into 4.14? Is there still time? It should also be queued up for stable. Changes v2->v3: - Johannes didn't like the subject line of the patch, so the only

[PATCH v2] af_netlink: give correct bounds to dump skb for NLMSG_DONE

to the brim. This requires keeping track of the errno from ->dump() across calls. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- Changes v1->v2: - This implements things without having to twiddle with the skb, at the expense of potentially having an extra back-and-forth and qui

[PATCH v2] af_netlink: give correct bounds to dump skb for NLMSG_DONE

to the brim. This requires keeping track of the errno from ->dump() across calls. Signed-off-by: Jason A. Donenfeld --- Changes v1->v2: - This implements things without having to twiddle with the skb, at the expense of potentially having an extra back-and-forth and quite a bit of

Re: [PATCH] af_netlink: give correct bounds to dump skb for NLMSG_DONE

Erf, your patch doesn't handle what happens if len comes back negative, but I'll fix it up and send a v2 using this approach. I think I really prefer v1 though. Jason

Re: [PATCH] af_netlink: give correct bounds to dump skb for NLMSG_DONE

Erf, your patch doesn't handle what happens if len comes back negative, but I'll fix it up and send a v2 using this approach. I think I really prefer v1 though. Jason

Re: [PATCH] af_netlink: give correct bounds to dump skb for NLMSG_DONE

Hi Johannes, Yes indeed. It sacrifices 24 bytes for making things much less complex. However, if you prefer increasing the complexity of the state machine a bit instead, I suppose we could roll with this approach instead... Jason

Re: [PATCH] af_netlink: give correct bounds to dump skb for NLMSG_DONE

Hi Johannes, Yes indeed. It sacrifices 24 bytes for making things much less complex. However, if you prefer increasing the complexity of the state machine a bit instead, I suppose we could roll with this approach instead... Jason

Re: [PATCH] af_netlink: give correct bounds to dump skb for NLMSG_DONE

By the way, in case you're curious, here's the {up,down,cross}stream WireGuard commit that works around it via its compat layer (a rat's nest of hideous backports for all the weird kernels people want WireGuard to run on, which I cannot wait to remove):

Re: [PATCH] af_netlink: give correct bounds to dump skb for NLMSG_DONE

By the way, in case you're curious, here's the {up,down,cross}stream WireGuard commit that works around it via its compat layer (a rat's nest of hideous backports for all the weird kernels people want WireGuard to run on, which I cannot wait to remove):

[PATCH] af_netlink: give correct bounds to dump skb for NLMSG_DONE

-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- See you all at netdevconf tomorrow! net/netlink/af_netlink.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c index b93148e8e9fb..b2d0a2fb1939 100644 --- a/net/netlink/af_netlink.c +++

[PATCH] af_netlink: give correct bounds to dump skb for NLMSG_DONE

-off-by: Jason A. Donenfeld --- See you all at netdevconf tomorrow! net/netlink/af_netlink.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c index b93148e8e9fb..b2d0a2fb1939 100644 --- a/net/netlink/af_netlink.c +++ b/net/netlink

Re: [PATCH v4] arm64: support __int128 on gcc 5+

Hi Will, On Tue, Nov 7, 2017 at 11:13 AM, Will Deacon wrote: > So I pushed a fixup patch on top of for-next/core, but I suggest we > temporarily revert the- DCONFIG_ARCH_SUPPORTS_INT128 option if any other > issues crop up. The fixup looks good to me. If there are

Re: [PATCH v4] arm64: support __int128 on gcc 5+

Hi Will, On Tue, Nov 7, 2017 at 11:13 AM, Will Deacon wrote: > So I pushed a fixup patch on top of for-next/core, but I suggest we > temporarily revert the- DCONFIG_ARCH_SUPPORTS_INT128 option if any other > issues crop up. The fixup looks good to me. If there are additional problems, I'm

Re: [PATCH v4] arm64: support __int128 on gcc 5+

On Tue, Nov 7, 2017 at 1:55 AM, Ard Biesheuvel wrote: > It appears your v4 adds __ashlti3() and __ashrti3, whereas the error > is about __lshrti3() being undefined. Whoopsie. v5 adds the final missing function. Looks like it now compiles for -next with the config you

Re: [PATCH v4] arm64: support __int128 on gcc 5+

On Tue, Nov 7, 2017 at 1:55 AM, Ard Biesheuvel wrote: > It appears your v4 adds __ashlti3() and __ashrti3, whereas the error > is about __lshrti3() being undefined. Whoopsie. v5 adds the final missing function. Looks like it now compiles for -next with the config you provided me.

[PATCH v5] arm64: support __int128 on gcc 5+

, and __lshrti3 which require libgcc, which is fine. Rather than linking to libgcc, we simply provide them ourselves, since they're not that complicated. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- Changes v4->v5: - Add implementation of __lshrti3. (Note that

[PATCH v5] arm64: support __int128 on gcc 5+

, and __lshrti3 which require libgcc, which is fine. Rather than linking to libgcc, we simply provide them ourselves, since they're not that complicated. Signed-off-by: Jason A. Donenfeld --- Changes v4->v5: - Add implementation of __lshrti3. (Note that __lshlti3 is not a function.) a

[PATCH v4] arm64: support __int128 on gcc 5+

, which require libgcc, which is fine. Rather than linking to libgcc, we simply provide them ourselves, since they're not that complicated. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- Changes v3->v4: - Typo in comment - Relabel second function arch/arm64/Makefile

[PATCH v4] arm64: support __int128 on gcc 5+

, which require libgcc, which is fine. Rather than linking to libgcc, we simply provide them ourselves, since they're not that complicated. Signed-off-by: Jason A. Donenfeld --- Changes v3->v4: - Typo in comment - Relabel second function arch/arm64/Makefile | 2 ++ arch/arm64/

[PATCH v3] arm64: support __int128 on gcc 5+

, which require libgcc, which is fine. Rather than linking to libgcc, we simply provide them ourselves, since they're not that complicated. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- Changes v2->v3: - We now just provide trivial implementations for the missing function

[PATCH v3] arm64: support __int128 on gcc 5+

, which require libgcc, which is fine. Rather than linking to libgcc, we simply provide them ourselves, since they're not that complicated. Signed-off-by: Jason A. Donenfeld --- Changes v2->v3: - We now just provide trivial implementations for the missing functions, rather than link

Re: [PATCH v2] arm64: support __int128 on gcc 5+

On Fri, Nov 3, 2017 at 2:42 PM, Will Deacon wrote: > We used to link against libgcc way back when, but that dependency was > removed in commit d67703a8a69e ("arm64: kill off the libgcc dependency") > and I'm really not keen to add it back. I also think that there might > be

Re: [PATCH v2] arm64: support __int128 on gcc 5+

On Fri, Nov 3, 2017 at 2:42 PM, Will Deacon wrote: > We used to link against libgcc way back when, but that dependency was > removed in commit d67703a8a69e ("arm64: kill off the libgcc dependency") > and I'm really not keen to add it back. I also think that there might > be licensing concerns if

Re: [PATCH] arm64: support __int128 on gcc 5+

Hi Will, Nice catch. I posted a v2 that addresses that. Thanks, Jason

Re: [PATCH] arm64: support __int128 on gcc 5+

Hi Will, Nice catch. I posted a v2 that addresses that. Thanks, Jason

[PATCH v2] arm64: support __int128 on gcc 5+

and __ashrti3, that require libgcc, which is fine. So, we also link to libgcc for these functions when needed, which is what several other architectures already have been doing for a long time. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- arch/arm64/Makefile | 4 +++- 1 file chan

[PATCH v2] arm64: support __int128 on gcc 5+

and __ashrti3, that require libgcc, which is fine. So, we also link to libgcc for these functions when needed, which is what several other architectures already have been doing for a long time. Signed-off-by: Jason A. Donenfeld --- arch/arm64/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1

Re: [PATCH v7] printk: hash addresses printed with %p

On Mon, Oct 30, 2017 at 9:22 PM, Steven Rostedt wrote: > How quickly do you need static_branch_disable() executed? You could > always pass the work off to a worker thread (that can schedule). > > random_ready_callback -> initiates worker thread -> enables the static branch I

Re: [PATCH v7] printk: hash addresses printed with %p

On Mon, Oct 30, 2017 at 9:22 PM, Steven Rostedt wrote: > How quickly do you need static_branch_disable() executed? You could > always pass the work off to a worker thread (that can schedule). > > random_ready_callback -> initiates worker thread -> enables the static branch I had already

Re: [PATCH] arm64: support __int128 on gcc 5+

On Tue, Oct 31, 2017 at 1:17 PM, Will Deacon wrote: > > Sure, I'll wait for your patch that matches the relevant compiler versions. That's the patch in this thread: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-October/539943.html As mentioned in there, gcc

Re: [PATCH] arm64: support __int128 on gcc 5+

On Tue, Oct 31, 2017 at 1:17 PM, Will Deacon wrote: > > Sure, I'll wait for your patch that matches the relevant compiler versions. That's the patch in this thread: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-October/539943.html As mentioned in there, gcc does the right thing for

Re: [PATCH] arm64: support __int128 on gcc 5+

Hi Will, On Tue, Oct 31, 2017 at 12:51 PM, Will Deacon wrote: > Which code in the kernel actually uses 128-bit types directly? I know we > have some unfortunate occurences in our headers (including uapi) for the > vector registers, but I thought we generally used asm or copy

Re: [PATCH] arm64: support __int128 on gcc 5+

Hi Will, On Tue, Oct 31, 2017 at 12:51 PM, Will Deacon wrote: > Which code in the kernel actually uses 128-bit types directly? I know we > have some unfortunate occurences in our headers (including uapi) for the > vector registers, but I thought we generally used asm or copy routines to > access

[PATCH] arm64: support __int128 on gcc 5+

last enable this option and receive the speedups. The gcc commit that added proper Aarch64 support is: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d1ae7bb994f49316f6f63e6173f2931e837a351d This commit appears to be part of the gcc 5 release. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.

[PATCH] arm64: support __int128 on gcc 5+

last enable this option and receive the speedups. The gcc commit that added proper Aarch64 support is: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d1ae7bb994f49316f6f63e6173f2931e837a351d This commit appears to be part of the gcc 5 release. Signed-off-by: Jason A. Donenfeld --- arch/arm64

Re: CONFIG_ARCH_SUPPORTS_INT128 for AArch64

Hi Mark, On Tue, Oct 31, 2017 at 11:43 AM, Mark Rutland wrote: > Judging by Documentation/kbuild/makefiles.txt, we could do something > like the below in the arm64 Makefile: > > cflags-y += $(call cc-ifversion, -ge, 0500, -DCONFIG_ARCH_SUPPORTS_INT128) Okay, in that case,

Re: CONFIG_ARCH_SUPPORTS_INT128 for AArch64

Hi Mark, On Tue, Oct 31, 2017 at 11:43 AM, Mark Rutland wrote: > Judging by Documentation/kbuild/makefiles.txt, we could do something > like the below in the arm64 Makefile: > > cflags-y += $(call cc-ifversion, -ge, 0500, -DCONFIG_ARCH_SUPPORTS_INT128) Okay, in that case, I'll re-research the

CONFIG_ARCH_SUPPORTS_INT128 for AArch64

Hi folks, Older versions of gcc are horrible for int128_t on aarch64, emitting a __multi3 call, which is slow and defeats the purpose. However, more recent versions of gcc (since 5, IIRC), do the right thing and produce the proper inlined instructions. Do we have the infrastructure available to

CONFIG_ARCH_SUPPORTS_INT128 for AArch64

Hi folks, Older versions of gcc are horrible for int128_t on aarch64, emitting a __multi3 call, which is slow and defeats the purpose. However, more recent versions of gcc (since 5, IIRC), do the right thing and produce the proper inlined instructions. Do we have the infrastructure available to

Re: [PATCH V8 2/2] printk: hash addresses printed with %p

On Thu, Oct 26, 2017 at 4:53 AM, Tobin C. Harding wrote: > +static bool have_filled_random_ptr_key; __read_mostly

Re: [PATCH V8 2/2] printk: hash addresses printed with %p

On Thu, Oct 26, 2017 at 4:53 AM, Tobin C. Harding wrote: > +static bool have_filled_random_ptr_key; __read_mostly

Re: [PATCH v7] printk: hash addresses printed with %p

On Thu, Oct 26, 2017 at 12:27 AM, Tobin C. Harding wrote: > How good is unlikely()? It places that branch way at the bottom of the function so that it's less likely to pollute the icache. > It doesn't _feel_ right adding a check on every call to printk just to > check for a

Re: [PATCH v7] printk: hash addresses printed with %p

On Thu, Oct 26, 2017 at 12:27 AM, Tobin C. Harding wrote: > How good is unlikely()? It places that branch way at the bottom of the function so that it's less likely to pollute the icache. > It doesn't _feel_ right adding a check on every call to printk just to > check for a condition that was

Re: [PATCH] iscsi-target: Convert timers to use timer_setup()

On Wed, Oct 25, 2017 at 12:01 PM, Kees Cook wrote: > sess->time2retain_timer.expires = > (get_jiffies_64() + sess->sess_ops->DefaultTime2Retain * HZ); > add_timer(>time2retain_timer); > cmd->dataout_timer.expires = (get_jiffies_64() +

Re: [PATCH] iscsi-target: Convert timers to use timer_setup()

On Wed, Oct 25, 2017 at 12:01 PM, Kees Cook wrote: > sess->time2retain_timer.expires = > (get_jiffies_64() + sess->sess_ops->DefaultTime2Retain * HZ); > add_timer(>time2retain_timer); > cmd->dataout_timer.expires = (get_jiffies_64() + na->dataout_timeout >

Re: [PATCH v7] printk: hash addresses printed with %p

On Wed, Oct 25, 2017 at 5:49 AM, Tobin C. Harding wrote: > static_branch_disable(_ptr_secret) : Doesn't sleep, just atomic read > and set and maybe a WARN_ONCE. Are you sure about that? I just looked myself, and though there is a !HAVE_JUMP_LABEL ifdef that does what you

Re: [PATCH v7] printk: hash addresses printed with %p

On Wed, Oct 25, 2017 at 5:49 AM, Tobin C. Harding wrote: > static_branch_disable(_ptr_secret) : Doesn't sleep, just atomic read > and set and maybe a WARN_ONCE. Are you sure about that? I just looked myself, and though there is a !HAVE_JUMP_LABEL ifdef that does what you described, there's also

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