On Fri, Aug 23, 2013 at 8:18 PM, Henrique de Moraes Holschuh
wrote:
> NACK. This we won't do. It is a LED misuse, and it will get in the way
> when we finally put that LED to its proper use.
Agreed. Please see my response to mjg.
--
To unsubscribe from this list: send the line "unsubscribe linu
ff-by: Jason A. Donenfeld
---
drivers/input/keyboard/atkbd.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index 2626773..15061bf 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/key
Thinkpads with a micmute LED do not have a capslock LED. The micmute LED
is currently not used by any piece of Linux kernel land or user land. It
seems reasonable to hook it up to caps lock, at least by default, so
users can have some degree of functionality.
Signed-off-by: Jason A. Donenfeld
The micmute LED is currently unused. This patch allows it to be hooked
up to various LED triggers.
Signed-off-by: Jason A. Donenfeld
---
drivers/platform/x86/thinkpad_acpi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers
On Thu, Aug 22, 2013 at 5:39 PM, Matthew Garrett wrote:
> I think there's a risk of user confusion here, in that it's now possible
> for the mic mute light to be lit despite the internal microphone still
> being active. That seems like surprising behaviour.
Yeah, that is a legitimate concern. Pat
From: "Jason A. Donenfeld"
If statp is NULL, "NULL - ptr_value" will be computed, which is
undefined behavior:
When two pointers are subtracted, both shall point to elements of
the same array object, or one past the last element of the array
object; the result
Hi Thomas,
Thomas Gleixner writes:
> We now have implicit batching in the timer wheel. The slack is not longer
> used. Remove it.
> - set_timer_slack(&ev->dwork.timer, intv / 4);
> - set_timer_slack(&host->timeout_timer, HZ);
> - set_timer_slack(&di->work.timer, poll_interval * HZ / 4);
> - set_t
Hi Thomas,
On Fri, Jul 22, 2016 at 3:04 PM, Thomas Gleixner wrote:
>
> Well, this really depends on the TIMEOUT value you have. The code now does
> implicit batching for larger timeouts by queueing the timers into wheels with
> coarse grained granularity. As long as your new TIMEOUT value ends up
On Fri, Jul 22, 2016 at 5:18 PM, Jason A. Donenfeld wrote:
> Hi Thomas,
>
> On Fri, Jul 22, 2016 at 3:04 PM, Thomas Gleixner wrote:
>>
>> Well, this really depends on the TIMEOUT value you have. The code now does
>> implicit batching for larger timeouts by queueing
On Wed, Sep 14, 2016 at 8:37 PM, Martin K. Petersen
> How do they signal that they support the passthrough?
Through the usual SCSI ATA-passthrough interface, "SAT" (SCSI-ATA
Command Translation) -- ATA PASS THROUGH SCSI (16) and ATA PASS
THROUGH SCSI (12).
I can use hdparm to treat /dev/sdb as
Hey Ted,
On Tue, Jun 20, 2017 at 02:03:44AM -0400, Theodore Ts'o wrote:
> I actually had set up an earlier version of your patch for on Saturday
> while I was in Beijing. (Like Linus, I'm attending the LinuxCon China
> conference Monday and Tuesday.) I had even created the signed tag,
> I've sin
On Tue, Jun 20, 2017 at 10:33 AM, Jeffrey Walton wrote:
> I think it is a bad idea to suppress all messages from a security
> engineering point of view.
>
> Many folks don't run debug kernels. Most of the users who want or need
> to know of the issues won't realize its happening. Consider, the
> r
On Tue, Jun 20, 2017 at 11:36 AM, Theodore Ts'o wrote:
>> But I think there's another camp that would mutiny in the face of this
>> kind of hubris.
>
> Blocking the boot for hours and hours until we have enough entropy to
> initialize the CRNG is ***not*** an acceptable way of making the
> warning
On Tue, Jun 20, 2017 at 8:14 PM, Kees Cook wrote:
> How about doing this:
>
>default DEBUG_KERNEL
>
> Most distro kernel select DEBUG_KERNEL because it unhides a bunch of
> other useful configs. Since it doesn't strictly _depend_ on
> DEBUG_KERNEL, I think it's probably a mistake to enforce a
On Wed, Jun 21, 2017 at 1:38 AM, Theodore Ts'o wrote:
> The punch was in response to this statement, which I personally found
> fairly infuriating:
>
>>> I more or less agree with you that we should just turn this on for all
>>> users and they'll just have to live with the spam and report odd
>>>
DEBUG_KERNEL`. This will ensure that the
curious see the messages while others don't have to.
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Theodore Ts'o
---
Hi Ted,
This patch is meant to replace d06bfd1989fe97623b32d6df4ffa6e4338c99dc8,
which is currently in your dev tree. It switc
e with that architecture
> or subarchitecture. To see all uses of unseeded randomness,
> developers can enable CONFIG_WARN_ALL_UNSEEDED_RANDOM.
Seems fine to me.
Acked-by: Jason A. Donenfeld
Jason
Hi Tobin,
Many comments in line below.
On Tue, Oct 17, 2017 at 6:52 AM, Tobin C. Harding wrote:
>
> diff --git a/include/linux/siphash.h b/include/linux/siphash.h
> index fa7a6b9cedbf..a9392568c8b8 100644
> --- a/include/linux/siphash.h
> +++ b/include/linux/siphash.h
> @@ -26,6 +26,8 @@ u64 __s
Hi Tobin,
You submitted v3 without replying to my v2 comments. I'll give a
condensed version of those here for convenience.
> diff --git a/include/linux/siphash.h b/include/linux/siphash.h
> +unsigned long siphash_1ulong(const unsigned long a, const siphash_key_t
> *key);
Don't add this functio
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
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
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 suggested
__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
Hi Will,
Nice catch. I posted a v2 that addresses that.
Thanks,
Jason
On Tue, Oct 24, 2017 at 2:31 AM, Tobin C. Harding wrote:
> On Tue, Oct 24, 2017 at 01:00:03AM +0200, Jason A. Donenfeld wrote:
>> Provided you've tested this and the static_key guard stuff actually
>> works as intended,
>
> I tested by inserting a simple module that call
On Wed, Oct 25, 2017 at 5:49 AM, Tobin C. Harding wrote:
> static_branch_disable(&no_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 als
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(&sess->time2retain_timer);
> cmd->dataout_timer.expires = (get_jiffies_64() + na->dataout_timeo
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 on
On Thu, Oct 26, 2017 at 4:53 AM, Tobin C. Harding wrote:
> +static bool have_filled_random_ptr_key;
__read_mostly
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 thi
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 y
, 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 li
, 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/a
On Wed, Oct 18, 2017 at 11:30 PM, Tobin C. Harding wrote:
> +static siphash_key_t ptr_secret __read_mostly;
> +static atomic_t have_key = ATOMIC_INIT(0);
> +
> +static void initialize_ptr_secret(void)
> +{
> + if (atomic_read(&have_key) == 1)
> + return;
> +
> + get_rando
On Thu, Oct 19, 2017 at 3:31 AM, Sergey Senozhatsky
wrote:
> On (10/19/17 03:03), Jason A. Donenfeld wrote:
> [..]
>> 1) Go back to the spinlock yourself.
>
> so we ruled out NMI deadlocks?
Oh, right. No, I haven't thought through this enough to rule it out.
Indeed if tha
A small detail carried over from the other thread:
>
> but a bigger problem might the following thing:
>
> vscnprintf()
> pointer()
> ptr_to_id()
>initialize_ptr_secret()
> get_random_bytes()
> _get_random_bytes()
> extract_crng()
>_extract_crng()
> spin_lock_
> Tangent: why is the random_ready API designed with -EALREADY? Couldn't
> add_random_ready_callback() just perform the call itself and avoid
> needing all the callers to check for -EALREADY?
Absolutely. I can submit a patch for this soon, though to avoid merge
dependencies, and given the usual de
As this interface becomes more heavily used, it will be painful for
callers to always need to check for -EALREADY.
Signed-off-by: Jason A. Donenfeld
---
drivers/char/random.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/char/random.c b
We now structure things in a way that assumes the seeding function is
always eventually called.
Signed-off-by: Jason A. Donenfeld
---
crypto/drbg.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 70018397e59a
These are mostly untested, but I wanted to spec it out for a taste of
what it looks like.
On Thu, Oct 19, 2017 at 10:42 PM, Kees Cook wrote:
> Maybe a stupid question, but is this function ultimately used by any
> crypto that expects it to be constant-time for safety?
Indeed constant time functions for crypto are important. But in this
case, it's unlikely this function would ever be u
Good tips, thanks. I'll wait for more comments before resubmitting v2,
but in-progress changes live here:
https://git.zx2c4.com/linux-dev/log/?h=jd/cleaner-add-random-ready
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 t
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 gc
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
from
eth_skb_pad fails, if a network device is transmitting repeatedly, this
bug could lead to rapidly leaking memory that could only be recovered by
a reboot or crash.
Signed-off-by: Jason A. Donenfeld
---
drivers/net/ethernet/intel/e1000/e1000_main.c | 4 +++-
1 file changed, 3 insertions(
s that darn .bc file?".
On Tue, Jul 14, 2015 at 7:24 PM, Jason A. Donenfeld wrote:
> Signed-off-by: Jason A. Donenfeld
> ---
> kernel/time/timeconst.bc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/time/timeconst.bc b/kernel/time/timeconst
You're right. Sorry for the noise Please ignore.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hey Andy, Eric, & all,
I've started the work of separating this out into 16 individual
commits, have addressed numerous other things brought up like the
ifdef maze, and have begun rewriting (parts of) the original commit
message. It's still a work in progress, and I still have some work to
do, but
Printing "err 0" to the user in the warning message is not particularly
useful, especially when this gets transformed into a -ENOENT for the
remainder of the call chain.
Signed-off-by: Jason A. Donenfeld
---
kernel/module.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
di
: f9e13c0a5a33 ("slab, slub: skip unnecessary kasan_cache_shutdown()")
Cc: Shakeel Butt
Cc: David Rientjes
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: Joonsoo Kim
Cc: Andrew Morton
Cc: Andrey Ryabinin
Cc:
Cc:
Cc:
Signed-off-by: Jason A. Donenfeld
---
lib/Kconfig.kasan | 1 +
1 file
Hi,
In my driver, I am constantly concerned with determining for how long
a certain object has been alive, in real time, because the lifetime
needs to be more or less synchronized with others on a network. For
this, I'm generally using a formulation like:
void foobar_create(struct foobar *f)
{
ing which vectors 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
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 in
ck annotation.
- Rebased against latest upstream ipsec changes.
Jason A. Donenfeld (5):
skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow
ipsec: check return value of skb_to_sgvec always
rxrpc: check return value of skb_to_sgvec always
macsec: check return value of skb_to_sgvec always
Signed-off-by: Jason A. Donenfeld
Cc: Steffen Klassert
Cc: Herbert Xu
Cc: "David S. Miller"
---
net/ipv4/ah4.c | 8 ++--
net/ipv4/esp4.c | 20 +---
net/ipv6/ah6.c | 8 ++--
net/ipv6/esp6.c | 20 +---
4 files changed, 38 insertions(+), 18
Signed-off-by: Jason A. Donenfeld
Cc: Sabrina Dubroca
---
drivers/net/macsec.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index cdc347be68f2..dfcb1e9d2ab2 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net
Signed-off-by: Jason A. Donenfeld
Cc: David Howells
---
net/rxrpc/rxkad.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
index 1bb9b2ccc267..ecab9334e3c1 100644
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@ -227,7
rted the recent MIPS
changes that give it a separate IRQ stack, so that I could experience
some worst-case situations. I found that limiting it to 24 layers deep
yielded a good stack usage with room for safety, as well as being much
deeper than any driver actually ever creates.
Signed-off-by: Ja
Signed-off-by: Jason A. Donenfeld
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
---
drivers/net/virtio_net.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 9320d96a1632..13fbe4b349c2 100644
--- a/d
On Thu, May 11, 2017 at 6:22 PM, Florian Fainelli wrote:
> What you are looking for can be done using ipset-dns from Jason:
>
> https://git.zx2c4.com/ipset-dns/about/
Funny to see this project coming up. I actually ported this
functionality into dnsmasq directly a few weeks after writing
ipset-dn
ing which vectors 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
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 /pr
Hi Linus,
On Tue, Feb 13, 2018 at 6:25 PM, Linus Torvalds
wrote:
> So let's try to fix the iscsi and ipsec issues. Not that anybody sane
> should use that overly complex ipsec thing, and I think we should
> strive to merge WireGuard and get people moved over to that instead,
> but I haven't heard
This architecture, used for running in QEMU, runs just fine when
compiled in big-endian mode. So enable it. This is enabled in exactly
the same way that it is for other platforms (such as vexpress) that also
support big-endian mode in QEMU successfully.
Signed-off-by: Jason A. Donenfeld
Hi Thomas,
I'm trying to optimize this for crypto performance while still taking
into account preemption concerns. I'm having a bit of trouble figuring
out a way to determine numerically what the upper bounds for this
stuff looks like. I'm sure I could pick a pretty sane number that's
arguably oka
Hey again Thomas,
On Thu, Sep 27, 2018 at 3:26 PM Jason A. Donenfeld wrote:
>
> Hi Thomas,
>
> I'm trying to optimize this for crypto performance while still taking
> into account preemption concerns. I'm having a bit of trouble figuring
> out a way to determine numer
On Thu, Sep 27, 2018 at 6:27 PM Andy Lutomirski wrote:
> I would add another consideration: if you can get better latency with
> negligible overhead (0.1%? 0.05%), then that might make sense too. For
> example, it seems plausible that checking need_resched() every few blocks
> adds basically no
Hi Eric,
On Thu, Sep 27, 2018 at 8:29 PM Eric Biggers wrote:
> Why is Herbert Xu's existing crypto tree being circumvented, especially for
> future patches (the initial merge isn't quite as important as that's a
> one-time
> event)? I like being able to check out cryptodev to test upcoming cryp
Hi Andrew,
Thanks for following up with this.
On Thu, Sep 27, 2018 at 3:15 AM Andrew Lunn wrote:
> I know you have been concentrating on the crypto code, so i'm not
> expecting too many changes at the moment in the network code.
I should be addressing things in parallel, actually, so I'm happy
On Fri, Sep 28, 2018 at 12:37 AM Jason A. Donenfeld wrote:
> Will do. v7 will include the wg_ prefix.
$ nm *.o | while read a b c; do [[ $b == T ]] && echo $c; done | grep -v ^wg_
cleanup_module
init_module
Success.
Hi Arnd,
On Fri, Sep 28, 2018 at 5:59 PM Arnd Bergmann wrote:
> Applied for 4.20 with subject line changed s/arm/ARM/, thanks!
Thanks.
> I think most people just build a 'defconfig' kernel, which includes
> multiple platforms that use ARCH_SUPPORTS_BIG_ENDIAN.
Right, that's what it looked like
Hey Arnd,
On Fri, Sep 28, 2018 at 9:19 PM Arnd Bergmann wrote:
> You can probably work around it by enabling ARCH_HIGHBANK,
> which is a minimal platform with no other requirements, so it
> should only add a few milliseconds to the build.
Nice hack, thanks for the suggestion. Committed here:
htt
Hi Herbert,
On Mon, Nov 19, 2018 at 6:25 AM Herbert Xu wrote:
> My proposal is to merge the zinc interface as is, but to invert
> how we place the algorithm implementations. IOW the implementations
> should stay where they are now, with in the crypto API. However,
> we will provide direct acces
On Sun, Nov 11, 2018 at 10:02 PM Wanpeng Li wrote:
> On Thu, 8 Nov 2018 at 03:55, Sebastian Andrzej Siewior
> wrote:
> >
> > This is a refurbished series originally started by by Rik van Riel. The
> > goal is load the FPU registers on return to userland and not on every
> > context switch. By thi
On Mon, Jun 18, 2018 at 11:44 AM Peter Zijlstra wrote:
>
> On Fri, Jun 15, 2018 at 10:30:46PM +0200, Jason A. Donenfeld wrote:
> > On Fri, Jun 15, 2018 at 9:34 PM Peter Zijlstra wrote:
> > > Didn't we recently do a bunch of crypto patches to help with this?
> &
return true;
} else if (ret)
atomic_set(&rng_state, 0);
return false;
}
return false;
}
Signed-off-by: Jason A. Donenfeld
---
drivers/char/random.c | 15 +++
include/linux/random.h | 1 +
2 files changed, 16 insertions(+)
diff --git a/drivers/char/random.c b/drivers/
Hello Shakeel,
It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has
introduced a regression. I've bisected a failing test to this commit,
and after staring at the my code for a long time, I'm unable to find a
bug that this commit might have unearthed. Rather, it looks like this
com
On Tue, Jun 19, 2018 at 5:59 AM Shakeel Butt wrote:
> Hi Jason, yes please do send me the test suite with the kernel config.
$ git clone https://git.zx2c4.com/WireGuard
$ cd WireGuard/src
$ [[ $(gcc -v 2>&1) =~ gcc\ version\ 8\.1\.0 ]] || echo crash needs 8.1
$ export DEBUG_KERNEL=yes
$ export KE
HI Dimitry,
On Tue, Jun 19, 2018 at 6:55 AM Dmitry Vyukov wrote:
> Your code frees all entries before freeing the cache, right? If you
> add total_entries check before freeing the cache, it does not fire,
> right?
Yes, certainly.
> Are you using SLAB or SLUB? We stress kernel pretty heavily, bu
On Tue, Jun 19, 2018 at 7:06 AM Shakeel Butt wrote:
> Currently refcnt in your
> code can underflow, through it does not seem like the selftest will
> cause the underflow but still you should fix it.
Indeed, and if this happened this would be a bug in the caller, not
the ratelimiter itself, kind
On Tue, Jun 19, 2018 at 3:31 PM Dmitry Vyukov wrote:
> Since I already looked at the code, if init and uninit can be called
> concurrently, I think there is a prominent race condition between init
> and uninit: a concurrent uninit can run concurrnetly with the next
> init and this will totally mes
On Tue, Jun 19, 2018 at 5:08 PM Shakeel Butt wrote:
> > > Are you using SLAB or SLUB? We stress kernel pretty heavily, but with
> > > SLAB, and I suspect Shakeel may also be using SLAB. So if you are
> > > using SLUB, there is significant chance that it's a bug in the SLUB
> > > part of the change
Hi Andrey,
On Tue, Jun 19, 2018 at 7:33 PM Andrey Ryabinin wrote:
> What's the status of CONFIG_SLUB_DEBUG in your config?
>
> AFAICS __kmem_cache_empty() is broken for CONFIG_SLUB_DEBUG=n. We use
> slabs_node() there
> which is always 0 for CONFIG_SLUB_DEBUG=n.
>
> The problem seems not limited
Hi Shakeel,
On Tue, Jun 19, 2018 at 9:21 PM Shakeel Butt wrote:
> Jason, can you try the following patch?
Your patch also fixed the problem, which was also fixed by enabling
CONFIG_SLUB_DEBUG, per the other email. I haven't checked to see if
your patch is simply a subset of what SLUB_DEBUG is do
ary kasan_cache_shutdown()")
> Signed-off-by: Shakeel Butt
> Reported-by: Jason A . Donenfeld
> Cc: Christoph Lameter
> Cc: Pekka Enberg
> Cc: David Rientjes
> Cc: Joonsoo Kim
> Cc: Andrew Morton
> Cc:
> ---
> mm/slub.c | 16 +++-
> 1 file
Hi Andy & folks,
Lots of crypto routines look like this:
kernel_fpu_begin();
encrypt();
kernel_fpu_end();
If you call such a routine twice, you get:
kernel_fpu_begin();
encrypt();
kernel_fpu_end();
kernel_fpu_begin();
encrypt();
kernel_fpu_end();
In a loop this looks like:
for (thing) {
ker
On Fri, Jun 15, 2018 at 8:53 PM Andy Lutomirski wrote:
>
> On Fri, Jun 15, 2018 at 11:50 AM Dave Hansen
> wrote:
> Even with the modified optimization, kernel_fpu_end() still needs to
> reload the state that was trashed by the kernel FPU use. If the
> kernel is using something like AVX512 state,
On Fri, Jun 15, 2018 at 9:34 PM Peter Zijlstra wrote:
> Didn't we recently do a bunch of crypto patches to help with this?
>
> I think they had the pattern:
>
> kernel_fpu_begin();
> for (units-of-work) {
> do_unit_of_work();
> if (need_resched()) {
On Fri, Jun 15, 2018 at 8:32 PM Andy Lutomirski wrote:
> quite in the form you imagined. The idea that we've tossed around is
> to restore FPU state on return to user mode. Roughly, we'd introduce
> a new thread flag TIF_FPU_UNLOADED (name TBD).
> prepare_exit_to_usermode() would notice this fla
On Fri, Jun 15, 2018 at 10:27 PM Jason A. Donenfeld wrote:
> AVX512 - Intel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz
> Inside: 634415672
> Outside: 286698960
> Percent speedup: 121
More realistic results, with turbo turned off:
Inside: 616851298
Outside: 339606790
Percent speedup: 81
St
Hi Andrew,
On Sun, Oct 7, 2018 at 6:48 PM Andrew Lunn wrote:
> Hi Jason
>
> This is the sort of thing you should state in the patchset version
> history. It is O.K. to say i will address this later, but you need to
> communicate that. Otherwise reviewers just get frustrated that
> comments are ge
Hi Joe, Miguel, others,
The shiny new .clang-format file lists a number of nice iterators in
the ForEachMacros category, the consequence being that there is a
space between the iterator name and the opening parenthesis. This
strikes me as the right thing to do.
However, checkpatch.pl complains ab
Thanks for the clarification Joe. I'll adjust my codebase to roll with
checkpatch's conventions.
cast truncates bits from constant value
(8003 becomes 3)
This works around the issue by detecting when we're going to shift by
the size of the variable and treat that as always zero.
Signed-off-by: Jason A. Donenfeld
---
parse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Greetings Mr. Ro Bot,
Another one of your robot friends also caught this, and the offending
code has been removed for v5.
Thanks for botting,
Jason
Hey Martin,
Thanks for running these and pointing this out. I've replicated the
results with tcrypt and fixed some issues, and the next patch series
should be a lot closer to what you'd expect, instead of the regression
you noticed. Most of the slowdown happened as a result of over-eager
XSAVEs, w
o/snuffle/xsalsa-20081128.pdf
[6] https://cr.yp.to/mac.html
[7] https://blake2.net/
[8] https://tools.ietf.org/html/rfc8439
[9] https://github.com/google/wycheproof
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
---
with contributions (upstream) from Samuel Neves and me,
in addition to further changes in the kernel implementation from us.
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Armando Faz-Hernández
Cc: Thomas Gleixner
Cc:
This comes from Dan Bernstein and Peter Schwabe's public domain NEON
code, and has been modified to be friendly for kernel space, as well as
removing some qhasm strangeness to be more idiomatic.
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc:
1 - 100 of 945 matches
Mail list logo
