Seems reasonable to me.
Acked-by: Jason A. Donenfeld
On Thu, Mar 18, 2021 at 1:33 AM Yunsheng Lin wrote:
> > That offer definitely still stands. Generalization sounds like a lot of fun.
> >
> > Keep in mind though that it's an eventually consistent queue, not an
> > immediately consistent one, so that might not match all use cases. It
> > works
On 3/17/21, Toke Høiland-Jørgensen wrote:
> Cong Wang writes:
>
>> On Mon, Mar 15, 2021 at 2:07 PM Jakub Kicinski wrote:
>>>
>>> I thought pfifo was supposed to be "lockless" and this change
>>> re-introduces a lock between producer and consumer, no?
>>
>> It has never been truly lockless, it
Hey Linus,
Thanks for the patch and sorry for the delay in reviewing it. Seeing
the basic scaffolding for getting netlink notifiers working with
WireGuard is enlightening; it looks surprisingly straightforward.
There are three classes of things that are interesting to receive
notifications for:
On Wed, Mar 3, 2021 at 1:31 PM Andy Polyakov wrote:
>
> Hi,
>
> > I'm also CC'ing Andy on this, who wrote the original assembly, in case
> > he has some last minute objection.
>
> Just "what took you so long":-) On potentially related note cryptogams
> chacha-mips is as universal as
en to enable
> code for MIPSr1 ISA or newer processors only and have it available for
> all MIPS processors.
That sounds like a good solution to me. Thanks for doing the research
on it. Assuming your findings hold up:
Acked-by: Jason A. Donenfeld
I'm also CC'ing Andy on this, who wrote the
On 3/3/21, Thomas Bogendoerfer wrote:
> On Mon, Mar 01, 2021 at 05:27:46PM +0100, Jason A. Donenfeld wrote:
>> Hey Thomas,
>>
>> Would you mind sending this for 5.12 in an rc at some point, rather
>> than waiting for 5.13? I'd like to see this backported to 5.10 and
Hey Thomas,
Would you mind sending this for 5.12 in an rc at some point, rather
than waiting for 5.13? I'd like to see this backported to 5.10 and 5.4
for OpenWRT.
Thanks,
Jason
. Rozycki
Cc: Thomas Bogendoerfer
Cc: Ralf Baechle
Cc: George Cherian
Cc: Huacai Chen
Cc: Jiaxun Yang
Signed-off-by: Jason A. Donenfeld
---
arch/mips/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d89efba3d8a4..3e0e8f1d2e82
On Sat, Feb 27, 2021 at 2:41 PM Maciej W. Rozycki wrote:
>
> On Sat, 27 Feb 2021, Jason A. Donenfeld wrote:
>
> > The CPU_MIPS64 and CPU_MIPS32 variables are supposed to be able to
> > distinguish broadly between 64-bit and 32-bit MIPS CPUs. However, they
>
> Tha
This commit rectifies the issue by having CPU_MIPS64 be selected when
the missing Octeon or Loongson models are selected.
Cc: Thomas Bogendoerfer
Cc: Ralf Baechle
Cc: George Cherian
Cc: Huacai Chen
Cc: Jiaxun Yang
Signed-off-by: Jason A. Donenfeld
---
arch/mips/Kconfig | 2 +-
1 file changed, 1
On 2/18/21, Willem de Bruijn wrote:
> On Wed, Feb 17, 2021 at 5:56 PM Jason A. Donenfeld wrote:
>>
>> Hi Willem,
>>
>> On Wed, Feb 17, 2021 at 11:27 PM Willem de Bruijn
>> wrote:
>> > A vmlinux image might help. I couldn't find one for this kernel.
&g
Hi Willem,
On Wed, Feb 17, 2021 at 11:27 PM Willem de Bruijn
wrote:
> A vmlinux image might help. I couldn't find one for this kernel.
https://data.zx2c4.com/icmp_send-crash-e03b4a42-706a-43bf-bc40-1f15966b3216.tar.xz
has .debs with vmlinuz in there, which you can extract to vmlinux, as
well as
Hi Netdev & Willem,
I've received a report of stack corruption -- via the stack protector
check -- in icmp_send. I was sent a vmcore, and was able to extract
the OOPS from there. However, I've been unable to produce the bug and
I don't see where it'd be in the code. That might point to a more
On Tue, Feb 16, 2021 at 6:46 PM Jason A. Donenfeld wrote:
>
> Hi Catalin,
>
> On Tue, Feb 16, 2021 at 6:28 PM Catalin Marinas
> wrote:
> > Adding Jason and Ard. It may be a use-after-free in the wireguard
> > driver.
>
> Thanks for sending this my way. Note: to
Hi Catalin,
On Tue, Feb 16, 2021 at 6:28 PM Catalin Marinas wrote:
> Adding Jason and Ard. It may be a use-after-free in the wireguard
> driver.
Thanks for sending this my way. Note: to my knowledge, Ard doesn't
work on wireguard.
> > hlist_add_head include/linux/list.h:883 [inline]
> >
On Mon, Jan 25, 2021 at 07:54:38PM +0100, Tibor Bana wrote:
> Greetings!
>
> I don't know if it still actual, but I am strugling with this problem right
> now and searching the internet for solutions.
> I read the thread and saw that you are strugling to reproduce the problem,
> and I can
On Sun, Feb 7, 2021 at 5:00 AM Colton Booth wrote:
>
> I can't test myself since I don't have the correct hardware, BUT this change
> seems to work for him. I'm thinking he has an early version of the X1E which
> may use slightly different trackpad revision.
>
> Signed-off-by: Colton Booth
>
> int execve_parent(int parent_pidfd, int root_dirfd, int cgroup_fd, int
> namespace_fd, const char *pathname, char *const argv[], char *const
> envp[]);
A variant on the same scheme would be:
int execve_remote(int pidfd, int root_dirfd, int cgroup_fd, int
namespace_fd, const char *pathname,
Hi Andy & others,
I was reversing some NT stuff recently and marveling over how wild and
crazy things are over in Windows-land. A few things related to process
creation caught my interest:
- It's possible to create a new process with an *arbitrary parent
process*, which means it'll then inherit
Hey Linus,
My email server has been firewalled from vger.kernel.org until today,
so I didn't see the original until this v2 was sent today. My
apologies. I'll review this first thing on Monday.
Jason
In case it helps,
Reviewed-by: Jason A. Donenfeld
[resending, as my mail server got blocked from vger for a week and my
message bounced]
Hi Fatih,
Thanks for the report and the detailed test case. From what I can see,
this behavior presents itself both with the explicit ip link del and
without. When running with debugging enabled, I can see this in dmesg:
[558758.361056] wireguard: wg0: Keypair 244 destroyed for peer 21
On Wed, Dec 23, 2020 at 5:03 PM Jason A. Donenfeld wrote:
>
> Hi Peter,
>
> On Wed, Dec 23, 2020 at 5:01 PM Petr Tesarik wrote:
> > I never suggested that this should serve as a supportive argument. I was
> > just trying to be honest about our motivation
Hi Peter,
On Wed, Dec 23, 2020 at 5:01 PM Petr Tesarik wrote:
> I never suggested that this should serve as a supportive argument. I was just
> trying to be honest about our motivations.
>
> I'm a bit sad that this discussion has quickly gone back to the choice of
> algorithms and how they can
On Wed, Dec 23, 2020 at 4:26 PM Stephan Mueller wrote:
>
> Am Mittwoch, dem 23.12.2020 um 15:32 +0100 schrieb Jason A. Donenfeld:
> >
> > I would, however, be interested in a keccak-based construction. But
> > just using the keccak permutation does not automatically make
On Wed, Dec 23, 2020 at 3:17 PM Petr Tesarik wrote:
> Upfront, let me admit that SUSE has a vested interest in a FIPS-certifiable
> Linux kernel.
Sorry, but just because you have a "vested interest", or a financial
interest, or because you want it does not suddenly make it a good
idea. The idea
On Thu, Dec 10, 2020 at 9:56 AM Antonio Quartulli wrote:
>
> The definition of IS_ERR() already applies the unlikely() notation
> when checking the error status of the passed pointer. For this
> reason there is no need to have the same notation outside of
> IS_ERR() itself.
>
> Clean up code by
Hi Ard,
On Tue, Dec 1, 2020 at 1:24 PM Ard Biesheuvel wrote:
> > > > is implemented. In most cases, these are special instructions, but in
> > > > some cases, such as on ARM, we may want to back this using firmware
> > > > calls, which are considerably more expensive.
This seems fine. But I
On Mon, Nov 30, 2020 at 5:56 PM Theodore Y. Ts'o wrote:
> patches this cycle. One thing that would help me is if folks
> (especially Jason, if you would) could start with a detailed review of
> Nicolai's patches.
Sure, I'll take a look.
I am willing to maintain random.c and have intentions to have a
formally verified RNG. I've mentioned this to Ted before.
But I think Ted's reluctance to not accept the recent patches sent to
this list is mostly justified, and I have no desire to see us rush
into replacing random.c with something
g churn. If arch
> maintainers want to clean them up, please go ahead.
>
> While I was here, I also moved __must_check to compiler_attributes.h
> from compiler_types.h
For the wireguard test harness change:
Acked-by: Jason A. Donenfeld
On Tue, Nov 10, 2020 at 6:20 PM Greg KH wrote:
>
> On Tue, Nov 10, 2020 at 01:29:41PM +0100, Jason A. Donenfeld wrote:
> > Note that this requires
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=46d6c5ae953cc0be38efd0e469284df7c4328cf8
> >
Note that this requires
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=46d6c5ae953cc0be38efd0e469284df7c4328cf8
And that commit should be backported to every kernel ever, since the
bug is so old.
eed to track test_num in counter_test.c.
> But deleting the /*1*/ test_num comments means git (with the default
> threshold) no longer recognizes that the file was moved.
>
> Signed-off-by: Daniel Latypov
> Cc: Jason A. Donenfeld
> Cc: David Miller
> Cc: Brendan Higgin
After discussing this offline with Jann a bit, I have a few general
comments on the design of this.
First, the UUID communicated by the hypervisor should be consumed by
the kernel -- added as another input to the rng -- and then userspace
should be notified that it should reseed any userspace
down to
csum_partial_copy_generic()")
Cc: Al Viro
Signed-off-by: Jason A. Donenfeld
---
arch/powerpc/lib/checksum_32.S | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/lib/checksum_32.S b/arch/powerpc/lib/checksum_32.S
index ec5cd2dede35..27d9070617df 100644
--- a/arch/powerpc/lib/checksum_32.S
On Thu, Oct 15, 2020 at 12:53 AM Linus Torvalds
wrote:
>
> On Wed, Oct 14, 2020 at 3:51 PM Linus Torvalds
> wrote:
> >
> > I think it's this instruction:
> >
> > addir1,r1,16
> >
> > that should be removed from the function exit, because Al removed the
> >
> > - stwu
On Thu, Oct 15, 2020 at 12:51 AM Linus Torvalds
wrote:
>
> On Wed, Oct 14, 2020 at 3:27 PM Jason A. Donenfeld wrote:
> >
> > This patch is causing crashes in WireGuard's CI over at
> > https://www.wireguard.com/build-status/ . Apparently sending a simple
> > netw
Hi Al,
On Fri, Jul 24, 2020 at 02:25:46AM +0100, Al Viro wrote:
> From: Al Viro
>
> ... and get rid of the pointless fallback in the wrappers. On error it used
> to zero the unwritten area and calculate the csum of the entire thing. Not
> wanting to do it in assembler part had been very
Oh, this is just a copy and paste error, when the code was originally
pasted from internal_get_user_pages_fast, which assumes a current.
I'll fix this up and send a patch shortly.
Alright, the failing code seems to be in mm:
if (flags & FOLL_PIN)
atomic_set(>mm->has_pinned, 1);
Apparently you can't rely on current->mm being valid in this context;
it's null here, hence the +0x64 for has_pinned's offset.
This was added by 008cfe4418b3 ("mm:
Increasing the CC list a bit, as i915 didn't really get much churn
rc6->rc7, but mm/gup.c did, and mm has had a lot of recent changes.
On Mon, Sep 28, 2020 at 11:39 AM Jason A. Donenfeld wrote:
>
> Seeing a new crash in 5.9-rc7 I didn't have in 5.9-rc6:
>
> [ 1311.596896] B
Seeing a new crash in 5.9-rc7 I didn't have in 5.9-rc6:
[ 1311.596896] BUG: kernel NULL pointer dereference, address: 0064
[ 1311.596898] #PF: supervisor write access in kernel mode
[ 1311.596899] #PF: error_code(0x0002) - not-present page
[ 1311.596899] PGD 0 P4D 0
[ 1311.596901]
I haven't looked into the details of this patchset yet, but your
description here indicates to me that this is motivated by FIPS
certification desires, which...worries me. I would like to rewrite the
RNG at some point, and I've started to work on a bunch of designs for
this (and proving them
On Tue, Sep 8, 2020 at 8:01 PM Borislav Petkov wrote:
>
> On Tue, Sep 08, 2020 at 07:42:12PM +0200, Jason A. Donenfeld wrote:
> > Are you prepared to track down all the MSRs that might maybe do
> > something naughty?
>
> I'm not prepared - that's why this MSR filterin
On Tue, Sep 8, 2020 at 7:36 PM Borislav Petkov wrote:
>
> On Tue, Sep 08, 2020 at 07:29:11PM +0200, Jason A. Donenfeld wrote:
> > Well that's not cool.
>
> So you're saying that if someone wants to kill its box by poking at that
> MSR, we should just let her/him?
>
On Tue, Sep 8, 2020 at 7:26 PM Borislav Petkov wrote:
>
> On Tue, Sep 08, 2020 at 07:12:44PM +0200, Jason A. Donenfeld wrote:
> > > Overclocking is not architectural I/F and is supported by some special
> > > CPU skews. I can't find any public document to specify the
On Tue, Sep 8, 2020 at 7:10 PM Srinivas Pandruvada
wrote:
>
> On Mon, 2020-09-07 at 12:06 +0200, Borislav Petkov wrote:
> > + Srinivas.
> > + kitsunyan.
> >
> > On Mon, Sep 07, 2020 at 11:48:43AM +0200, Jason A. Donenfeld wrote:
> > > Popular tools, like in
On Mon, Sep 7, 2020 at 1:11 PM Borislav Petkov wrote:
>
> Hi,
>
> On Mon, Sep 07, 2020 at 12:46:35PM +0200, Jason A. Donenfeld wrote:
> > Are you sure that intel-undervolt using OC_MAILBOX from userspace is
> > actually a "misuse"? Should the kernel or kerne
Hi Borislav,
On Mon, Sep 7, 2020 at 12:06 PM Borislav Petkov wrote:
>
> + Srinivas.
> + kitsunyan.
>
> On Mon, Sep 07, 2020 at 11:48:43AM +0200, Jason A. Donenfeld wrote:
> > Popular tools, like intel-undervolt, use MSR 0x150 to control the CPU
> > voltage
the constant used throughout the kernel.
Fixes: a7e1f67ed29f ("x86/msr: Filter MSR writes")
Cc: Borislav Petkov
Signed-off-by: Jason A. Donenfeld
---
arch/x86/include/asm/msr-index.h | 2 ++
arch/x86/kernel/msr.c| 5 -
drivers/platform/x86/intel_turbo_m
On Wed, Aug 19, 2020 at 8:42 PM syzbot
wrote:
>
> syzbot has bisected this issue to:
>
> commit e7096c131e5161fa3b8e52a650d7719d2857adfd
> Author: Jason A. Donenfeld
> Date: Sun Dec 8 23:27:34 2019 +
>
> net: WireGuard secure network tunnel
&
Hey Joerg,
On Thu, Aug 6, 2020 at 9:23 PM Joerg Roedel wrote:
> Jason, can you share more details about the test setup which triggers
> this? Like the .config and the machine setup, ideally a qemu
> command-line, and how to reproduce it on that setup.
make -C
into
> p4d_alloc() and pud_alloc() to correctly pre-allocate the PGD entries.
>
> Reported-by: Jason A. Donenfeld
> Fixes: 6eb82f994026 ("x86/mm: Pre-allocate P4D/PUD pages for vmalloc area")
> Signed-off-by: Joerg Roedel
> ---
> arch/x86/mm/init_64.c | 31 +
Hi Ingo, Joerg,
On Mon, Aug 03, 2020 at 09:03:54PM +0200, Ingo Molnar wrote:
> Linus,
>
> Please pull the latest x86/mm git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-mm-2020-08-03
>
># HEAD: 2b32ab031e82a109e2c5b0d30ce563db0fe286b4 x86/mm/64: Make
>
On Tue, Jul 28, 2020 at 10:07 AM David Laight wrote:
>
> From: Christoph Hellwig
> > Sent: 27 July 2020 17:24
> >
> > On Mon, Jul 27, 2020 at 06:16:32PM +0200, Jason A. Donenfeld wrote:
> > > Maybe sockptr_advance should have some safety checks and sometimes
&g
r and copy_to_sockptr.
>
> Fixes: ba423fdaa589 ("net: add a new sockptr_t type")
> Reported-by: Jason A. Donenfeld
> Reported-by: Ido Schimmel
> Signed-off-by: Christoph Hellwig
> ---
> drivers/crypto/chelsio/chtls/chtls_main.c | 12 +---
On Mon, Jul 27, 2020 at 5:06 PM Christoph Hellwig wrote:
>
> On Mon, Jul 27, 2020 at 05:03:10PM +0200, Jason A. Donenfeld wrote:
> > Hi Christoph,
> >
> > On Thu, Jul 23, 2020 at 08:08:54AM +0200, Christoph Hellwig wrote:
> > > diff --git a/net/ipv4/ip_so
Hi Christoph,
On Thu, Jul 23, 2020 at 08:08:54AM +0200, Christoph Hellwig wrote:
> diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> index da933f99b5d517..42befbf12846c0 100644
> --- a/net/ipv4/ip_sockglue.c
> +++ b/net/ipv4/ip_sockglue.c
> @@ -1422,7 +1422,8 @@ int
On Sun, Jun 21, 2020 at 9:02 PM Jason A. Donenfeld wrote:
> This commit broke userspace. Bash uses ESPIPE to determine whether or
> not the file should be read using "unbuffered I/O", which means reading
> 1 byte at a time instead of 128 bytes at a time. I used to use bash to
There's no reason to open code this here, so instead replace it with
pr_warn_once, which amounts to exactly the same thing.
Signed-off-by: Jason A. Donenfeld
---
fs/fscache/page.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/fs/fscache/page.c b/fs/fscache
Hey Cong,
I'm wondering if the below error is related to what you've been
looking at yesterday. AFAICT, there's a simple UaF on the attrbuf
passed to the start method. I recall recently you were working on the
locking in genetlink's family buffers and wound up mallocing some
things, so it seems
On Wed, Jun 24, 2020 at 03:06:10PM -0600, Jason A. Donenfeld wrote:
> Hi Alexander,
>
> This patch introduced a behavior change around GRO_DROP:
>
> napi_skb_finish used to sometimes return GRO_DROP:
>
> > -static gro_result_t napi_skb_finish(gro_result_t ret, struct s
Hi Alexander,
This patch introduced a behavior change around GRO_DROP:
napi_skb_finish used to sometimes return GRO_DROP:
> -static gro_result_t napi_skb_finish(gro_result_t ret, struct sk_buff *skb)
> +static gro_result_t napi_skb_finish(struct napi_struct *napi,
> +
I realize 5.2 has long since sunsetted, and I really missed the boat
on speaking up about this many many months ago, but in case any
distros or organizations have a 5.2.x stable series, this should
probably be reverted from 5.2. The reason is that 7d9e5f422 was added
to 5.3, and introduced a UaF,
o determine whether or not it's
reading from a pipe.
Cc: Bruno Meneguele
Cc: pmla...@suse.com
Cc: sergey.senozhat...@gmail.com
Cc: rost...@goodmis.org
Cc: david.lai...@aculab.com
Cc: Linus Torvalds
Cc: Sergey Senozhatsky
Cc: Petr Mladek
Signed-off-by: Jason A. Donenfeld
---
Documentation/
On Wed, Jun 17, 2020 at 2:38 AM Ard Biesheuvel wrote:
>
> On Wed, 17 Jun 2020 at 00:21, Jason A. Donenfeld wrote:
> >
> > Hi Rafael, Len,
> >
> > Looks like I should have CC'd you on this patch. This is probably
> > something we should get into
Hi Rafael, Len,
Looks like I should have CC'd you on this patch. This is probably
something we should get into 5.8-rc2, so that it can then get put into
stable kernels, as some people think this is security sensitive.
Bigger picture is this:
On Tue, Jun 16, 2020 at 12:54 PM Joe Perches wrote:
>
> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> > v4:
> > - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > so that it can be backported to stable.
> > - Drop the "crypto: Remove unnecessary
to be
installed. The link in the trailer shows a PoC of how this might be
used.
Link:
https://git.zx2c4.com/american-unsigned-language/tree/american-unsigned-language-2.sh
Cc: sta...@vger.kernel.org
Signed-off-by: Jason A. Donenfeld
---
drivers/acpi/acpi_configfs.c | 6 +-
1 file changed, 5 insertions
On Tue, Jun 9, 2020 at 9:21 AM Frank Werner-Krippendorf wrote:
>
> Fixes an error condition reported by checkpatch.pl which caused by
> assigning a variable in an if condition in
> wg_noise_handshake_consume_initiation().
>
> Signed-off-by: Frank Werner-Krippendorf
Thanks. Queued up in the
On Thu, May 14, 2020 at 6:35 AM Masahiro Yamada wrote:
>
> On Thu, May 14, 2020 at 9:11 PM David Howells wrote:
> >
> > Jason A. Donenfeld wrote:
> >
> > > Your touch might be helpful here. CRYPTO_LIB_CHACHA20POLY1305 is a
> > > tristate and
Hey Masahiro,
Your touch might be helpful here. CRYPTO_LIB_CHACHA20POLY1305 is a
tristate and depends on as well as selects other things that are
tristates.
Meanwhile BIG_KEYS is a bool, which needs to select
CRYPTO_LIB_CHACHA20POLY1305. However, it gets antsy if the the symbol
its selecting has
On Tue, May 12, 2020 at 4:03 PM David Howells wrote:
>
> Jason A. Donenfeld wrote:
>
> > So long as that ->update function:
> > 1. Deletes the old on-disk data.
> > 2. Deletes the old key from the inode.
> > 3. Generates a new key using get_random_bytes.
>
Hi David,
So long as that ->update function:
1. Deletes the old on-disk data.
2. Deletes the old key from the inode.
3. Generates a new key using get_random_bytes.
4. Stores that new key in the inode.
5. Encrypts the updated data afresh with the new key.
6. Puts the updated data onto disk,
then
On Mon, May 11, 2020 at 6:05 PM Linus Torvalds
wrote:
> There's a reason -O3 isn't even offered as an option.
>
> Maybe things have changed, and maybe they've improved. But I'd like to
> see actual numbers for something like this.
>
> Not inlining as aggressively is not necessarily a bad thing.
ada
Signed-off-by: Jason A. Donenfeld
---
Changes v1->v2:
- [Oleksandr] Remove O3 dependency on ARC.
init/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index 9e22ee8fbd75..f76ec3ccc883 100644
--- a/init/Kconfig
+++ b/init/K
ustom page allocator that big_key really
doesn't need.
Cc: David Howells
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Linus Torvalds
Cc: kernel-harden...@lists.openwall.com
Reviewed-by: Eric Biggers
Signed-off-by: Jason A. Donenfeld
---
Changes v2->v3:
- [Eric] Unify kernel_read/w
On Fri, May 8, 2020 at 5:56 AM Arnd Bergmann wrote:
>
> On Fri, May 8, 2020 at 1:33 PM Oleksandr Natalenko
> wrote:
> >
> > On Fri, May 08, 2020 at 05:21:47AM -0600, Jason A. Donenfeld wrote:
> > > > Should we untangle -O3 from depending on ARC first maybe?
>
On Fri, May 8, 2020 at 3:08 AM Oleksandr Natalenko wrote:
>
> Should we untangle -O3 from depending on ARC first maybe?
Oh, hah, good point. Yes, I'll do that for a v2, but will wait another
day for feedback first.
Jason
compiles to -O3 when using gcc >= 10.
Signed-off-by: Jason A. Donenfeld
---
init/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/init/Kconfig b/init/Kconfig
index 9e22ee8fbd75..fab3f810a68d 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1245,7 +1245,8 @@ con
On Tue, May 5, 2020 at 8:54 PM Kees Cook wrote:
>
> On Tue, May 05, 2020 at 06:14:53PM -0600, Jason A. Donenfeld wrote:
> > clang-10 has a broken optimization stage that doesn't allow the
> > compiler to prove at compile time that certain memcpys are within
> > bounds, and
ers
Link: https://bugs.llvm.org/show_bug.cgi?id=45802
Signed-off-by: Jason A. Donenfeld
---
security/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/security/Kconfig b/security/Kconfig
index cd3cc7da3a55..76bcfb3eb16f 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -191,6
On Tue, May 5, 2020 at 5:22 PM Jason A. Donenfeld wrote:
>
> On Tue, May 5, 2020 at 5:19 PM Kees Cook wrote:
> >
> > On Tue, May 05, 2020 at 04:37:38PM -0600, Jason A. Donenfeld wrote:
> > > On Tue, May 5, 2020 at 4:25 PM Nathan Chancellor
> > > wrote:
&g
On Tue, May 5, 2020 at 5:19 PM Kees Cook wrote:
>
> On Tue, May 05, 2020 at 04:37:38PM -0600, Jason A. Donenfeld wrote:
> > On Tue, May 5, 2020 at 4:25 PM Nathan Chancellor
> > wrote:
> > > I believe these issues are one in the same. I did a reverse bisect
On Tue, May 5, 2020 at 4:25 PM Nathan Chancellor
wrote:
> I believe these issues are one in the same. I did a reverse bisect with
> Arnd's test case and converged on George's first patch:
>
> https://github.com/llvm/llvm-project/commit/2dd17ff08165e6118e70f00e22b2c36d2d4e0a9a
>
> I think that in
-10, we
just set __NO_FORTIFY globally, so that this issue won't be incurred.
Cc: Arnd Bergmann
Cc: LKML
Cc: clang-built-linux
Cc: Kees Cook
Cc: George Burgess
Cc: Nick Desaulniers
Link: https://bugs.llvm.org/show_bug.cgi?id=45802
Signed-off-by: Jason A. Donenfeld
---
Makefile | 7 +++
1
On Tue, May 5, 2020 at 3:48 PM Nick Desaulniers wrote:
>
> + Kees, George, who have started looking into this, too.
I have a smaller reproducer and analysis I'll send out very shortly.
As discussed on IRC, this issue here isn't specific to this file, but
rather fortify source has some serious issues on clang-10, everywhere
in the kernel, and we should probably disable it globally for this
clang version. I'll follow up with some more info in a different
patch.
On Tue, May 5, 2020 at 8:13 AM Arnd Bergmann wrote:
>
> clang points out a harmless use of uninitialized variables that
> get passed into a local function but are ignored there:
>
> In file included from drivers/net/wireguard/ratelimiter.c:223:
>
So in spite of this Syzkaller bug being unrelated in the end, I've
continued to think about the stacktrace a bit, and combined with some
other [potentially false alarm] bug reports I'm trying to wrap my head
around, I'm a bit a curious about ideal usage for the udp_tunnel API.
All the uses I've
On Sun, May 3, 2020 at 2:31 PM Chris Wilson wrote:
>
> Query whether or not we are in a legal context for using SIMD, before
> using SSE4.2 registers.
>
> Suggested-by: Jason A. Donenfeld
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_memcpy.c | 4 +
On Sun, May 3, 2020 at 2:30 PM Chris Wilson wrote:
>
> Quoting Jason A. Donenfeld (2020-04-30 23:10:16)
> > Sometimes it's not okay to use SIMD registers, the conditions for which
> > have changed subtly from kernel release to kernel release. Usually the
> > pattern is t
Thanks for this series. I like the general idea. I think it might make
sense, though, to separate things out into sha1.h and sha256.h. That
will be nice preparation work for when we eventually move obsolete
primitives into some subdirectory.
On Fri, May 1, 2020 at 12:07 PM Christoph Hellwig wrote:
>
> On Thu, Apr 30, 2020 at 04:10:16PM -0600, Jason A. Donenfeld wrote:
> > Sometimes it's not okay to use SIMD registers, the conditions for which
> > have changed subtly from kernel release to kernel release. Usual
On Fri, May 1, 2020 at 4:42 AM Sebastian Andrzej Siewior
wrote:
>Reviewed-by: Sebastian Andrzej Siewior
Thanks.
>
> May I ask how large the memcpy can be? I'm asking in case it is large
> and an explicit rescheduling point might be needed.
Yea I was worried about that too. I'm not an i915
fixes up i915's accelerated memcpy routines to fallback
to boring memcpy if may_use_simd() is false.
Cc: sta...@vger.kernel.org
Signed-off-by: Jason A. Donenfeld
---
drivers/gpu/drm/i915/i915_memcpy.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915
Hi Herbert,
This v3 patchset has a Reviewed-by from Ard for 1/2 and from Eric for
2/2, from last week. Could you submit this to Linus for rc4?
Thanks,
Jason
Hi Dave,
On Wed, Sep 25, 2019 at 12:03 PM David Miller wrote:
> I didn't say "must" anything, I suggested this as a more smoothe
> and efficient way forward.
s/must/should/g? However it's characterized, I think your jugements
and opinions are generally sound, and I intend to put them into
1 - 100 of 1705 matches
Mail list logo
