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
this patch 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/drive
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
action
Hi folks,
I'm at the Kernel Recipes conference now and got a chance to talk with
DaveM a bit about WireGuard upstreaming. His viewpoint has recently
solidified: in order to go upstream, WireGuard must port to the
existing crypto API, and handle the Zinc project separately. As DaveM
is the upstream
et traffic without routing loops. The test case added here
causes the reference underflow by causing packets to evaluate a suppress
rule.
Cc: sta...@vger.kernel.org
Fixes: 7d9e5f422150 ("ipv6: convert major tx path to use
RT6_LOOKUP_F_DST_NOREF")
Signed-off-by: Jason A. Donenfeld
---
n
On Tue, Sep 24, 2019 at 3:30 PM David Miller wrote
> I'm asking you to make a non-wireguard test that triggers the problem.
Oh, gotcha. No problem.
>
> Or would you like a situation you're interested in to break from time
> to time.
My test suite should catch it in the future now that it's there,
On Tue, Sep 24, 2019 at 2:53 PM David Miller wrote:
> Please make such test cases integratabe into the selftests area for networking
> and submit it along with this fix.
That link is for a WireGuard test-case. When we get that upstream,
those will all live in selftests/ all the same as you'd like
Hey Wei,
I meant to CC you but slipped up. Sorry about that. Take a look at
this thread if you have a chance.
Thanks,
Jason
On Tue, Sep 24, 2019 at 10:03 AM Jason A. Donenfeld wrote:
>
> Commit 7d9e5f422150 removed references from certain dsts, but accounting
> for this never transl
Proper warnings with stack traces make it much easier to figure out
what's doing the double free and create more meaningful bug reports from
users.
Signed-off-by: Jason A. Donenfeld
---
net/core/dst.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/dst.c
:
https://git.zx2c4.com/WireGuard/commit/?id=ad66532000f7a20b149e47c5eb3a957362c8e161
Signed-off-by: Jason A. Donenfeld
---
net/ipv6/fib6_rules.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/fib6_rules.c b/net/ipv6/fib6_rules.c
index d22b6c140f23..f9e8fe3ff0c5 1
Apparently even with this (certainly correct) patch attached, users
are still experiencing problems. Bug hunting continues, and I'll
report back if I figure something out.
sult in the use-after-free users are seeing. This commit changes
the `|` to the proper `&` test.
Cc: sta...@vger.kernel.org
Fixes: 7d30a7f6424e ("Merge branch
'ipv6-avoid-taking-refcnt-on-dst-during-route-lookup'")
Signed-off-by: Jason A. Donenfeld
---
net/ipv6/ip6_fib
bytes suitable for casting a struct. Then people can create
their usual casting macros for accessing strongly typed members of a
struct.
As a plus, this also gives us the same amount of space on 32bit and 64bit.
Signed-off-by: Jason A. Donenfeld
Cc: Johannes Berg
---
include/linux/netlink
Previously there was no analogue to get proper ktime_t versions of the
fast variety of ktime invocations. This commit makes the interface
uniform with the other accessors.
Signed-off-by: Jason A. Donenfeld
Cc: Arnd Bergmann
Cc: Thomas Gleixner
---
Documentation/core-api/timekeeping.rst | 7
The _fast_ family of functions put the _fast_ modifier in the wrong
place and confuse tai with clocktai and boot with boottime. Also, no
other functions use _mono, making that the default unlabeled one.
This commit normalizes these to match the rest of timekeeping.h.
Signed-off-by: Jason A
tweaks, I'm happy to do so.
Thanks,
Jason
Jason A. Donenfeld (2):
timekeeping: add missing non-_ns functions for fast accessors
timekeeping: rename fast getter functions to be consistent
Documentation/core-api/timekeeping.rst | 15 ---
Documentation/trace/ftrace.rst | 2 +-
dr
Commit-ID: d48e0cd8fcaf314175a15d3076d7a1e71bd4e628
Gitweb: https://git.kernel.org/tip/d48e0cd8fcaf314175a15d3076d7a1e71bd4e628
Author: Jason A. Donenfeld
AuthorDate: Mon, 24 Jun 2019 11:15:39 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 25 Jun 2019 08:54:51 +0200
timekeeping
Somewhere in all the patchsets before, this cleanup got lost.
Signed-off-by: Jason A. Donenfeld
Cc: Arnd Bergmann
Cc: Thomas Gleixner
---
Documentation/core-api/timekeeping.rst | 2 +-
include/linux/timekeeping.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
Commit-ID: 4c54294d01e605a9f992361b924c5d8b12822a6d
Gitweb: https://git.kernel.org/tip/4c54294d01e605a9f992361b924c5d8b12822a6d
Author: Jason A. Donenfeld
AuthorDate: Fri, 21 Jun 2019 22:32:49 +0200
Committer: Thomas Gleixner
CommitDate: Sat, 22 Jun 2019 12:11:28 +0200
timekeeping
Commit-ID: 9285ec4c8b61d4930a575081abeba2cd4f449a74
Gitweb: https://git.kernel.org/tip/9285ec4c8b61d4930a575081abeba2cd4f449a74
Author: Jason A. Donenfeld
AuthorDate: Fri, 21 Jun 2019 22:32:48 +0200
Committer: Thomas Gleixner
CommitDate: Sat, 22 Jun 2019 12:11:27 +0200
timekeeping
Commit-ID: 0354c1a3cdf31f44b035cfad14d32282e815a572
Gitweb: https://git.kernel.org/tip/0354c1a3cdf31f44b035cfad14d32282e815a572
Author: Jason A. Donenfeld
AuthorDate: Fri, 21 Jun 2019 22:32:47 +0200
Committer: Thomas Gleixner
CommitDate: Sat, 22 Jun 2019 12:11:27 +0200
timekeeping
from the API originally, so this fills this oversight.
Signed-off-by: Jason A. Donenfeld
Cc: Arnd Bergmann
Cc: Thomas Gleixner
---
Documentation/core-api/timekeeping.rst | 10 +++---
include/linux/timekeeping.h| 27 ++
2 files changed, 34 insertions(+), 3
While this doesn't actually amount to a real difference, since the macro
evaluates to the same thing, every place else operates on ktime_t using
these functions, so let's not break the pattern.
Fixes: e3ff9c3678b4 ("timekeeping: Repair ktime_get_coarse*() granularity")
Si
This makes boot uniformly boottime and tai uniformly clocktai, to
address the remaining oversights.
Signed-off-by: Jason A. Donenfeld
Cc: Arnd Bergmann
Cc: Thomas Gleixner
---
Documentation/core-api/timekeeping.rst | 2 +-
arch/x86/kvm/pmu.c
/ktime_get_tai_ns/ktime_get_clocktai_ns/g
s/ktime_get_\([^_]\+\)_coarse/ktime_get_coarse_\1/g
This does not, however, apply:
s/ktime_get_\([^_]\+\)_fast/ktime_get_fast_\1/g
Signed-off-by: Jason A. Donenfeld
Reported-by: Arnd Bergmann
Cc: Arnd Bergmann
Cc: Thomas Gleixner
---
Documentation/core
from the API originally, so this fills this oversight.
Signed-off-by: Jason A. Donenfeld
Cc: Arnd Bergmann
Cc: Thomas Gleixner
---
Documentation/core-api/timekeeping.rst | 10 +++---
include/linux/timekeeping.h| 27 ++
2 files changed, 34 insertions(+), 3
Previously there was no analogue to get proper ktime_t versions of the
fast variety of ktime invocations. This commit makes the interface
uniform with the other accessors.
Signed-off-by: Jason A. Donenfeld
Cc: Arnd Bergmann
Cc: Thomas Gleixner
---
Documentation/core-api/timekeeping.rst | 7
While this doesn't actually amount to a real difference, since the macro
evaluates to the same thing, every place else operates on ktime_t using
these functions, so let's not break the pattern.
Fixes: e3ff9c3678b4 ("timekeeping: Repair ktime_get_coarse*() granularity")
Si
On Fri, Jun 21, 2019 at 4:58 PM Arnd Bergmann wrote:
> I care less about these since ktime_get_real_fast_ns() already
> exists. My preference would be leaving alons the _fast_ns()
> functions for now, but making everything else consistent instead.
>
> Thomas created the _fast_ns() accessors with a
/ktime_get_tai_ns/ktime_get_clocktai_ns/g
s/ktime_get_\([^_]\+\)_coarse/ktime_get_coarse_\1/g
s/ktime_get_\([^_]\+\)_fast/ktime_get_fast_\1/g
Signed-off-by: Jason A. Donenfeld
Reported-by: Arnd Bergmann
Cc: Arnd Bergmann
Cc: Thomas Gleixner
---
Documentation/core-api/timekeeping.rst| 24
from the API originally, so this fills this oversight.
Signed-off-by: Jason A. Donenfeld
Cc: Arnd Bergmann
Cc: Thomas Gleixner
---
Documentation/core-api/timekeeping.rst | 10 +++---
include/linux/timekeeping.h| 27 ++
2 files changed, 34 insertions(+), 3
While this doesn't actually amount to a real difference, since the macro
evaluates to the same thing, every place else operates on ktime_t using
these functions, so let's not break the pattern.
Fixes: e3ff9c3678b4 ("timekeeping: Repair ktime_get_coarse*() granularity")
Si
Previously there was no analogue to get proper ktime_t versions of the
fast variety of ktime invocations. This commit makes the interface
uniform with the other accessors.
Signed-off-by: Jason A. Donenfeld
Cc: Arnd Bergmann
Cc: Thomas Gleixner
---
Documentation/core-api/timekeeping.rst | 7
On Fri, Jun 21, 2019 at 4:45 PM Arnd Bergmann wrote:
> I would prefer the 'coarse' on the other side, i.e.
> ktime_get_coarse_real_ns instead of ktime_get_real_coarse_ns,
> as this is what we already have with ktime_get_coarse_real_ts64.
>
> I originally went with that order to avoid the function
On Fri, Jun 21, 2019 at 4:29 PM Arnd Bergmann wrote:
> Typo: you have the same function names listed twice here,
> one of them should be ktime_get_mono_fast() instead of
> ktime_get_mono_fast_ns().
Nice catch. Vim twitches gone crazy.
> Also, we might want to rename ktime_get_boot_fast_ns()
> to
While this doesn't actually amount to a real difference, since the macro
evaluates to the same thing, every place else operates on ktime_t using
these functions, so let's not break the pattern.
Fixes: e3ff9c3678b4 ("timekeeping: Repair ktime_get_coarse*() granularity")
Si
Previously there was no analogue to get proper ktime_t versions of the
fast variety of ktime invocations. This commit makes the interface
uniform with the other accessors.
Signed-off-by: Jason A. Donenfeld
Cc: Arnd Bergmann
Cc: Thomas Gleixner
---
Documentation/core-api/timekeeping.rst | 7
from the API originally, so this fills this oversight.
Signed-off-by: Jason A. Donenfeld
Cc: Arnd Bergmann
Cc: Thomas Gleixner
---
Documentation/core-api/timekeeping.rst | 10 +++---
include/linux/timekeeping.h| 27 ++
2 files changed, 34 insertions(+), 3
On Wed, Jun 19, 2019 at 10:57 PM Arnd Bergmann wrote:
>
> On Wed, Jun 19, 2019 at 10:07 PM Jason A. Donenfeld wrote:
> >
> > On Wed, Jun 19, 2019 at 10:02 PM Arnd Bergmann wrote:
> > > > get_jiffies_boot_64 26
> > > > ktime_get_coarse_boottime 26
On Wed, Jun 19, 2019 at 10:02 PM Arnd Bergmann wrote:
> > get_jiffies_boot_64 26
> > ktime_get_coarse_boottime 26
> > ktime_get_boot_fast_ns with tsc 70
> > ktime_get_boot_fast_ns with hpet 4922
> > ktime_get_boot_fast_ns with acpi_pm 1884
> >
> > As expected, hpet is really quite painful.
>
> I w
Hi Arnd,
On Wed, Jun 19, 2019 at 5:08 PM Arnd Bergmann wrote:
> Can you quantify how much this gains you over ktime_get_coarse_boottime
> in practice? You are effectively adding yet another abstraction for time,
> which is something I'd hope to avoid unless you have a strong reason other
> than i
s, which may be invoked early in system resumption before the
offset is updated.
Signed-off-by: Jason A. Donenfeld
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Arnd Bergmann
Cc: Andrew Morton
Cc; John Stultz
---
include/linux/jiffies.h | 1 +
include/linux/timekeeper_internal.h
Hi Peter,
On Wed, Jun 12, 2019 at 2:29 PM Peter Zijlstra wrote:
> > and the comment at the top mentions explicit sleep hooks. I wasn't
> > sure which function to use from here, though.
>
> Either local_clock() or cpu_clock(cpu). The sleep hooks are not
> something the consumer has to worry about.
Hi Thomas,
On Fri, Jun 14, 2019 at 11:50 AM Thomas Gleixner wrote:
> jiffies64 uses a seqcount on 32bit as well.
Right, but not 64-bit, which is some sort of improvement I suppose.
> Hrm, I'm not a great fan of these shortcuts which cut corners based on
> 'somewhat rarely, so it should not matt
-ish div_u64 on each
query.
Signed-off-by: Jason A. Donenfeld
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Arnd Bergmann
---
include/linux/timekeeper_internal.h | 2 ++
include/linux/timekeeping.h | 2 ++
kernel/time/timekeeping.c | 12
3 files changed, 16
Hey Thomas,
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> } while (read_seqcount_retry(&tk_core.seq, seq));
>
> - return base;
> -
> + return base + nsecs;
The rest of the file seems to use `ktime_add_ns(base, nsecs)`. I
realize, of course, that these d
Hey Masahiro,
Considering ARM big endian userland is pretty badly broken without
this, we should probably have this merged in the next rc or rather
soon. Was there additional information you needed? Would you prefer
Russell queues up my patch or did you want to make further build
system changes?
Or in case that's not clear enough:
int __init mod_init(void)
{
u64 j1 = 0, j2, k1 = 0, k2, l1 = 0, l2;
for (;;) {
j2 = jiffies64_to_nsecs(get_jiffies_64());
k2 = ktime_get_coarse_boottime();
l2 = local_clock();
pr_err("%llu %llu %llu\n", j2 - j1, k2 - k1, l2 - l1);
j1 = j2
On Thu, Jun 13, 2019 at 6:26 PM Thomas Gleixner wrote:
> That does not make sense. The coarse time getters use
> tk->tkr_mono.base. base is updated every tick (or if the machine is
> completely idle right when the first CPU wakes up again).
Sense or not, it seems to be happening, at least on 5.2-
Hey Arnd,
On Thu, Jun 13, 2019 at 5:40 PM Arnd Bergmann wrote:
> A seqlock is a very cheap synchronization primitive, I would actually
> guess that this is faster than most implementations of sched_clock()
> that access a hardware register for reading the time.
It appears to me that ktime_get_co
Hey Arnd, Peter,
On Wed, Jun 12, 2019 at 4:01 PM Arnd Bergmann wrote:
> Documentation/core-api/timekeeping.rst describes the timekeeping
> interfaces. I think what you want here is ktime_get_coarse_boottime().
>
> Note that "coarse" means "don't access the hardware clocksource"
> here, which is f
Hi Peter,
Thanks for the explanation.
On Wed, Jun 12, 2019 at 2:29 PM Peter Zijlstra wrote:
> Either local_clock() or cpu_clock(cpu). The sleep hooks are not
> something the consumer has to worry about.
Alright. Just so long as it *is* tracking sleep, then that's fine. If
it isn't some importan
Hey Peter,
On Wed, Jun 12, 2019 at 11:03 AM Peter Zijlstra wrote:
> How quasi? Do the comments in kernel/sched/clock.c look like something
> you could use?
>
> As already mentioned in the other tasks, anything ktime will be
> horrifically crap when it ends up using the HPET, the code in
> kernel/
Hey Thomas,
After some discussions here prior about the different clocks
available, WireGuard uses ktime_get_boot_fast_ns() pretty extensively.
The requirement is for a quasi-accurate monotonic counter that takes
into account sleep time, and this seems to fit the bill pretty well.
Sultan (CC'd) re
Hey Masahiro,
I'm not sure exactly. I did just notice another place --be8 is being added:
ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
LDFLAGS_vmlinux += --be8
KBUILD_LDFLAGS_MODULE += --be8
endif
I suppose it's possible that this is kbuild related where one of those
isn't winding up in the right place.
generated be32 code, making the VDSO generate SIGILL when called by
userspace.
This commit passes --be8 if CONFIG_CPU_ENDIAN_BE8 is enabled.
Signed-off-by: Jason A. Donenfeld
Cc: Masahiro Yamada
Cc: Russell King
Cc: Arnd Bergmann
Cc: Ard Biesheuvel
---
arch/arm/vdso/Makefile | 5 +++-
On Mon, May 27, 2019 at 4:07 PM Theodore Ts'o wrote:
>
> This is guaranteed to cause the system to fail for systems using
> systemd. (Unless you are running an x86 with random.trust_cpu=1 ---
> in which case, this patch/config is pointless.) And many embedded
> systems *do* use systemd. I know
s.
>
> Cc: Jason A. Donenfeld
> Cc: Gustavo A. R. Silva
> Cc: Kees Cook
> Signed-off-by: Stephen Rothwell
Looks good to me, thanks for this.
Reviewed-by: Jason A. Donenfeld
Perhaps Greg can take it through his tree?
I generally use a slightly simpler algorithm in various different projects:
//[0, bound)
static unsigned long random_bounded(unsigned long bound)
{
unsigned long ret;
const unsigned long max_mod_bound = (1 + ~bound) % bound;
if (bound < 2)
return 0;
do
; }
> @@ -454,9 +485,14 @@ u32 __hsiphash_unaligned(const void *data, size_t len,
> v0 ^= m;
> }
> switch (left) {
> - case 3: b |= ((u32)end[2]) << 16;
> - case 2: b |= get_unaligned_le16(end); break;
> - case 1: b |= end[0];
> + case 3:
> + b |= ((u32)end[2]) << 16;
> + /* fall through */
> + case 2:
> + b |= get_unaligned_le16(end);
> + break;
> + case 1:
> + b |= end[0];
> }
> HPOSTAMBLE
> }
> --
> 2.20.1
Reviewed-by: Jason A. Donenfeld
Greg - would you take this through your tree?
Jason
Conceptually this seems pretty reasonable. Though, style-wise, perhaps
you might want to put those breaks on the next line too, i.e. s/;
break;/;\n\t\tbreak;/?
i.o: in function
`pSeries_final_fixup':
pci.c:(.init.text+0x1b0): undefined reference to `pnv_npu2_init'
This commit therefore wraps that line in an ifdef, so that PCI works
without PowerNV.
Signed-off-by: Jason A. Donenfeld
Fixes: 0e759bd75285 ("powerpc/powernv/npu: Move OPAL calls
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
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(-)
Thanks for the clarification Joe. I'll adjust my codebase to roll with
checkpatch's conventions.
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
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
On Tue, Oct 2, 2018 at 3:54 PM Arnd Bergmann wrote:
> Please add this to Russell's patch tracker for inclusion at
> http://www.arm.linux.org.uk/developer/patches/
Wild! And done:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8801/1
rtain cryptography code from working that uses instructions
like umull. Fortunately there's also -march=armv3m that does support
those, making it possible to continue assembling optimized cryptography
routines for our beloved RiscPC.
Signed-off-by: Jason A. Donenfeld
Cc: Ard Biesheuvel
Cc: Ru
Hey Ard,
On Tue, Oct 2, 2018 at 3:10 PM Ard Biesheuvel wrote:
>
> It builds but it doesn't run, at least not when built into the kernel
> proper (which will be the case after random.c moves to this library)
>
> Your toolchain is implicitly passing --fix-v4bx to the assembler,
> which causes it to
Hi Arnd,
On Tue, Oct 2, 2018 at 9:58 AM Arnd Bergmann wrote:
> > I think we're going to wind up playing whack-a-mole in silly ways. The
> > fact of the matter is that the ARM assembly I'm adding to the tree is
> > for ARMv4 and up, and not for ARMv3.
>
> I don't see what issues remain. The 'reteq
Hi Russell,
> On 1 October 2018 at 19:56, Russell King - ARM Linux
> wrote:
> We could argue that the ARMv3 assembly files are now stable, so the
> chances of ldrh/strh being introduced is low, which would make this
> change tolerable, but the commit message needs to spell out that
> we lose thi
Hi Ard,
On Tue, Oct 2, 2018 at 5:54 AM Ard Biesheuvel wrote:
> So Arnd's suggestion to switch to armv3-m would actually be feasible
> then? The code in question does not use ldrh only umull, and so it
> should build with armv3m as well. And we will even generate some
> better code for RiscPC if w
Hi Arnd,
Apologies for the delay in getting back to you. I had some MTA issues
and stupidly assumed ARM developers were taking the day off instead...
On Tue, Oct 2, 2018 at 5:33 AM Arnd Bergmann wrote:
> -arch-$(CONFIG_CPU_32v3)=-D__LINUX_ARM_ARCH__=3 -march=armv3
> +arch-$(CONFI
armv4 to the assembler in those cases, so that code
written for ARMv4 will continue to compile and run fine, without needing
module-specific asflags-y overrides.
[1]
https://lore.kernel.org/lkml/CAKv+Gu9FoFQymp2-=rueh14ckukon389oce7stycofwkzpa...@mail.gmail.com/
Signed-off-by: Jason A. Donenfel
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 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
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 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
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
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
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
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
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
clude/zinc/poly1305.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+/*
+ * Copyright (C) 2015-2018 Jason A. Donenfeld . All Rights
Reserved.
+ */
+
+#ifndef _ZINC_POLY1305_H
+#define _ZINC_POLY1305_H
+
+#include
+#include
+
+enum poly1305_lengths {
+ POLY1305_BLOCK_SIZE
It turns out that KASAN in general will bloat stack frames in unexpected
ways, not just KASAN_EXTRA. So, this patch trivially changes that
default to be associated with KASAN instead of KASAN_EXTRA.
Signed-off-by: Jason A. Donenfeld
---
lib/Kconfig.debug | 2 +-
1 file changed, 1 insertion
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:
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:
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
---
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
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
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:
Now that Poly1305 is in Zinc, we can have the crypto API code simply
call into it. We have to do a little bit of book keeping here, because
the crypto API receives the key in the first few calls to update.
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc
Now that ChaCha20 is in Zinc, we can have the crypto API code simply
call into it. The crypto API expects to have a stored key per instance
and independent nonces, so we follow suite and store the key and
initialize the nonce independently.
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc
,[x1] // write result
ret
+ENDPROC(poly1305_emit_neon)
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
---
lib/zinc/Makefile
On Thu, Sep 13, 2018 at 7:03 AM Kevin Easton wrote:
> Yes. It's also how most get/put APIs already work in the kernel, eg
> kref_get/put (mostly because they tend to be 'getting/putting' an
> already-initialized object, though).
Right; in this case the object wouldn't be initialized yet, which
m
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
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)
{
101 - 200 of 936 matches
Mail list logo
