inline frame. Generally, it's possible to stack allocate something
that's way too big; instead those should be allocated on the heap.
https://github.com/ClangBuiltLinux/frame-larger-than
(I haven't had time to sit down and use it to resolve all outstanding
issues, but it has worked well for me in the past)
--
Thanks,
~Nick Desaulniers
On Thu, Oct 15, 2020 at 11:13 AM Arvind Sankar wrote:
>
> Be clear about @ptr vs the variable that @ptr points to, and add some
> more details as to why the special barrier_data() macro is required.
>
> Signed-off-by: Arvind Sankar
Thanks for this distinct cleanup.
Acked-by: N
t
> > > addresses, since the first barrier_data() might have saved the address
> > > of x.
> >
> > Maybe "+m"(*ptr) : "r"(ptr) would work.
>
> Nothing that can only modify what ptr points to could avoid this, since
> that storage is dead after the barrier.
>
> > OTOH a "memory" clobber at the bottom of a function isn't going to
> > cause bloat.
> >
> > The explicit ranged memory access (without "memory") probably has its
> > uses - but only if the full "memory" clobber causes grief.
> >
> > David
> >
> > -
> > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> > 1PT, UK
> > Registration No: 1397386 (Wales)
--
Thanks,
~Nick Desaulniers
belong in compiler.h.
>
> Signed-off-by: Arvind Sankar
> Fixes: 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
> exclusive")
Thanks for the patch! Curious how you spotted this? My mistake for
missing it. Definite difference in the disassembly before/after.
Cc: st
Sorry for not reporting it sooner. It looks to me like a GNU `as` bug:
https://github.com/ClangBuiltLinux/linux/issues/1153#issuecomment-692265433
When I'm done with the three build breakages that popped up overnight I'll try
to report it to GNU binutils folks.
(We run an issue tracker out of
On Mon, Oct 12, 2020 at 8:26 PM Nathan Chancellor
wrote:
>
> On Mon, Oct 12, 2020 at 02:26:52PM -0700, Kees Cook wrote:
> > On Mon, Oct 12, 2020 at 02:22:03PM -0700, Fāng-ruì Sòng wrote:
> > > On Mon, Oct 12, 2020 at 2:11 PM 'Nick Desaulniers' via Clang Bui
b ("kbuild:
> drop support for cc-ldoption").
>
> With those, we can use $(LD_COMPAT) in cmd_ldvdso and change the flags
> from compiler linker flags to linker flags directly. We eliminate
> -mfloat-abi=soft because it is not handled by the linker.
>
> Link: https://gith
efer the older unwinder.
>From https://developer.arm.com/documentation/ihi0038/b/ (click
download in top left), section 4.4.1 "Sections" has a note:
```
Tables are not required for ABI compliance at the C/Assembler level
but are required for C++.
```
Review-by: Nick Desaulniers
Tested
Our CI went red for -next on arm64 due to c870baeede75. Thanks for sending a
fix.
Tested-by: Nick Desaulniers
https://lore.kernel.org/linux-next/20201012141032.6333-1-...@redhat.com/
karound https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
> > +# for old versions of GCC.
> > +DEBUG_CFLAGS := $(call cc-ifversion, -lt, 0500, $(call cc-option,
> > -fno-var-tracking-assignments))
Should this be wrapped in: `ifdef CONFIG_CC_IS_GCC`/`endif`?
> >
> > ifdef CONFIG_DEBUG_INFO
> > ifdef CONFIG_DEBUG_INFO_SPLIT
> > --
> > 2.18.4
> >
--
Thanks,
~Nick Desaulniers
> options in Enric's patch.
>
> Thanks,
> Guillaume
>
>
> [1]
> https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/case_closed_debugging_cr50.md
Thanks for the links, I've just now ordered one. For the open case
debugging, we have some custom daughter board with a ribbon cable.
It's...not pretty. I didn't know we had closed case debugging on
CrOS.
--
Thanks,
~Nick Desaulniers
if through selinux, seccomp or a
> different sysctl value, without this patchset applied the default
> behavior of the userfaultfd syscall for all Linux binaries running on
> Android kernels, would deviate from the upstream kernel. So even if we
> would make the pipe mutex logic more complex the deviation would
> remain. Your patchset adds much less risk of breakage than adding a
> timeout to kernel initiated userfaults and it resolves all concerns as
> well as a timeout. We'll also make better use of the "0" value this
> way. So while I'm not certain this is the best for the long term, this
> looks the sweet spot for the short term to resolve many issues at
> once.
>
> Thanks!
> Andrea
>
--
Nick Kralevich | n...@google.com
function that
contains the necessary code and this can be done once and
then used wherever the functionality is required.
Cheers
Nick
should be fixed
> > of course, but it is less important; although it may be pointing to a
> > deeper problem.)
> >
> >
> > Segher
>
--
Thanks,
~Nick Desaulniers
On Fri, Oct 2, 2020 at 1:51 PM Paul E. McKenney wrote:
>
> On Wed, Sep 30, 2020 at 01:55:48PM -0700, Nick Desaulniers wrote:
> > On Wed, Sep 30, 2020 at 1:40 PM Paul E. McKenney wrote:
> > >
> > > On Tue, Sep 29, 2020 at 12:25:49PM -0700, Nick Desaulniers wrot
On Fri, Oct 2, 2020 at 10:37 AM Randy Dunlap wrote:
>
> On 10/2/20 10:22 AM, Segher Boessenkool wrote:
> > On Fri, Oct 02, 2020 at 02:01:13PM +0200, Sedat Dilek wrote:
> >> On Thu, Oct 1, 2020 at 12:26 AM David Miller wrote:
> >>> From: Nick Desaulniers
>
_buffer.o' being
> placed in section `.ctors.65435'
>
> Include these orphans along with the regular .ctors section.
It's very curious to see different behavior based on whether one is
targeting x86_64 via native compilation vs cross compilation.
Acked-by: Nick Desaulniers
>
>
Hi Guys,
>> linux-toolcha...@vger.kernel.org
> Created.
I have been able to subscribe to this list, so it looks like thunderbirds are
go...
Cheers
Nick
> On Oct 1, 2020, at 3:18 AM, David Sterba wrote:
>
> On Wed, Sep 30, 2020 at 08:49:49PM +0000, Nick Terrell wrote:
>>> On Sep 29, 2020, at 11:53 PM, Nick Terrell wrote:
>>>
>>> From: Nick Terrell
>>
>> It has been brought to my attention tha
On Wed, Sep 30, 2020 at 3:06 PM Joe Perches wrote:
>
> On Wed, 2020-09-30 at 14:40 -0700, Nick Desaulniers wrote:
> > On Wed, Sep 30, 2020 at 12:16 PM Joe Perches wrote:
> > > Use a more generic form for __section that requires quotes to avoid
> > > complications
Or did
I miss something as to why it should remain a part of this series?
--
Thanks,
~Nick Desaulniers
otherwise).
https://lore.kernel.org/lkml/46f69161e60b802488ba8c8f3f8bbf922aa3b49b.ca...@perches.com/
--
Thanks,
~Nick Desaulniers
Known pre-existing issue. I sent a patch for this this week.
https://lore.kernel.org/lkml/20200929190701.398762-1-ndesaulni...@google.com/T/#u
On Wed, Sep 30, 2020 at 1:58 PM kernel test robot wrote:
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master
> head:
On Wed, Sep 30, 2020 at 1:40 PM Paul E. McKenney wrote:
>
> On Tue, Sep 29, 2020 at 12:25:49PM -0700, Nick Desaulniers wrote:
> > The stringification operator, `#`, in the preprocessor escapes strings.
> > For example, `# "foo"` becomes `"\"foo\"&quo
> On Sep 29, 2020, at 11:53 PM, Nick Terrell wrote:
>
> From: Nick Terrell
It has been brought to my attention that patch 3 hasn’t made it to patchwork,
likely because it is too large. I’ll include a pull request in the next cover
letter,
together with the patches (if needed).
Pl
upstream's API, to upstream's API.
-Nick
> On Tue, Sep 29, 2020 at 11:53:09PM -0700, Nick Terrell wrote:
>> From: Nick Terrell
>>
>> This patchset upgrades the zstd library to the latest upstream release. The
>> current zstd version in the kernel is a modified version
tps://groups.google.com/g/clang-built-linux/c/GLEkFKlDXfo (sorry I
didn't cc lkml sooner for a proper lore link; I myself am ~1 more bug
away from switching away from google groups forever).
--
Thanks,
~Nick Desaulniers
basis. aarch64 is relatively well
supported, but other arches not so much IME.
Do we need register local storage here?
static inline long bar(unsigned long hcall_id)
{
long result;
asm volatile("movl %1, %%r8d\n\t"
"vmcall\n\t"
: "=a" (result)
: "ir" (hcall_id)
: );
return result;
}
--
Thanks,
~Nick Desaulniers
Does anyone know who's behind postmas...@vger.kernel.org? Maybe I can
email them directly if perhaps they don't check this email often?
(Benefit of the doubt)
On Tue, Sep 15, 2020 at 1:49 PM Nick Desaulniers
wrote:
>
> Hello postmaster,
> Any thoughts on linux-toolcha...@vger.k
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Signed-off-by: Nick Terrell
---
lib/decompress_unzstd.c | 40 ++--
1 file changed, 14 insertions(+), 26 deletions(-)
diff --git a/lib
From: Nick Terrell
All callers have been transitioned to the new zstd-1.4.6 API. There are
no more callers of the zstd compatibility wrapper, so delete it.
Signed-off-by: Nick Terrell
---
include/linux/zstd_compat.h | 116
1 file changed, 116 deletions
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Signed-off-by: Nick Terrell
---
fs/btrfs/zstd.c | 48
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/fs
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Signed-off-by: Nick Terrell
---
fs/squashfs/zstd_wrapper.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/squashfs/zstd_wrapper.c b/fs
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is more efficient because it uses the single-pass API instead of
the streaming API. The streaming API is not necessary because the whole
input and output buffers are available. This saves memory because
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Signed-off-by: Nick Terrell
---
crypto/zstd.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/crypto/zstd.c b/crypto/zstd.c
From: Nick Terrell
Adds zstd_compat.h which provides the necessary functions from the
current zstd.h API. It is only active for zstd versions 1.4.6 and newer.
That means it is disabled currently, but will become active when a later
patch in this series updates the zstd library in the kernel
From: Nick Terrell
This patchset upgrades the zstd library to the latest upstream release. The
current zstd version in the kernel is a modified version of upstream zstd-1.3.1.
At the time it was integrated, zstd wasn't ready to be used in the kernel as-is.
But, it is now possible to use upstream
From: Nick Terrell
Adds decompress_sources.h which includes every .c file necessary for
zstd decompression. This is used in decompress_unzstd.c so the internal
structure of the library isn't exposed.
This allows us to upgrade the zstd library version without modifying any
callers. Instead we
Building the kernel with Clang doesn't rely on third party patches, and
has not for a few years now.
Signed-off-by: Nick Desaulniers
---
Documentation/process/programming-language.rst | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/Documentation/process/programming
On Tue, Sep 29, 2020 at 1:47 PM Arvind Sankar wrote:
>
> On Tue, Sep 29, 2020 at 01:30:22PM -0700, Nick Desaulniers wrote:
> > On Tue, Sep 29, 2020 at 1:25 PM Nick Desaulniers
> > wrote:
> > >
> > > On Tue, Sep 29, 2020 at 1:08 PM Arvind Sankar
> > >
On Tue, Sep 29, 2020 at 1:25 PM Nick Desaulniers
wrote:
>
> On Tue, Sep 29, 2020 at 1:08 PM Arvind Sankar wrote:
> >
> > On Tue, Sep 29, 2020 at 12:43:18PM -0700, Nick Desaulniers wrote:
> > > The stringification operator, `#`, in the preprocessor escapes strings.
On Tue, Sep 29, 2020 at 1:08 PM Arvind Sankar wrote:
>
> On Tue, Sep 29, 2020 at 12:43:18PM -0700, Nick Desaulniers wrote:
> > The stringification operator, `#`, in the preprocessor escapes strings.
> > For example, `# "foo"` becomes `"\"foo\"&quo
ttribute__
from compiler.h")
Signed-off-by: Nick Desaulniers
---
include/linux/compiler.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 92ef163a7479..ac45f6d40d39 100644
--- a/include/linux/compiler.h
+++ b/incl
sor stringification operator.
Link: https://bugs.llvm.org/show_bug.cgi?id=42950
Fixes: commit fe15b50cdeee ("srcu: Allocate per-CPU data for DEFINE_SRCU() in
modules")
Signed-off-by: Nick Desaulniers
---
Changes V1->V2:
* drop unrelated Kconfig changes accidentally committed in v1.
in
gah, must have had a `-a` in my `git commit --amend`...sorry, will send a v2...
On Tue, Sep 29, 2020 at 12:22 PM Nick Desaulniers
wrote:
>
> The stringification operator, `#`, in the preprocessor escapes strings.
> For example, `# "foo"` becomes `"\"foo\&quo
sor stringification operator.
Link: https://bugs.llvm.org/show_bug.cgi?id=42950
Fixes: commit fe15b50cdeee ("srcu: Allocate per-CPU data for DEFINE_SRCU() in
modules")
Signed-off-by: Nick Desaulniers
---
arch/arm/Kconfig | 1 +
arch/arm/mm/Kconfig | 11 +++
include/
c671d3 ("kbuild: simplify dependency generation for
CONFIG_TRIM_UNUSED_KSYMS")
Reported-by: kbuild test robot
Suggested-by: Kees Cook
Signed-off-by: Nick Desaulniers
---
include/linux/export.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/expo
> On Sep 28, 2020, at 11:02 AM, Nick Terrell wrote:
>
>
>
>> On Sep 28, 2020, at 1:55 AM, Feng Tang wrote:
>>
>> Hi Nick,
>>
>> 0day has found some kernel decomprssion failure case since 5.9-rc1 (X86_32
>> build), and it could be rela
n't detected by
> > > KASAN, page protections, etc.
> >
> > Well, Nick already asked this but we're marking all kernel text RO early
> > during boot. So it either is happening before that or something else
> > altogether is going on.
On Sun, Sep 27, 2
nreleased clang.
> Do we use the same clang as we use for the KMSAN instance? But this is
> not KMSAN machine, so I am not sure who/when/why updated it last to
> this revision.
> I even see we have some clang 11 version:
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce
>
> Is it possible to switch to some released version for both KMSAN and KASAN
> now?
--
Thanks,
~Nick Desaulniers
> On Sep 28, 2020, at 1:55 AM, Feng Tang wrote:
>
> Hi Nick,
>
> 0day has found some kernel decomprssion failure case since 5.9-rc1 (X86_32
> build), and it could be related with ZSTD code, though initially we bisected
> to some other commits.
&g
exas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clang-built-linux/76cae106-b643-57a9-e82e-48e46ebf1b70%40ti.com.
--
Thanks,
~Nick Desaulniers
debugging vector on this:
> The location of crashes does not seem to be completely random and
> evenly spread across kernel code. I think there are many more static
> branches (mm, net), but we have 3 crashes in vdso and 9 in paravirt
> code + these 6 crashes in perf_misc_flags which looks a bit like an
> outlier (?). What's special about paravirt/vdso?..
--
Thanks,
~Nick Desaulniers
Masahiro, would you mind picking
this up?
Reviewed-by: Nick Desaulniers
>
> Fixes: fcf1b6a35c16 ("Documentation/llvm: add documentation on building w/
> Clang/LLVM")
> Signed-off-by: Florian Fainelli
> ---
> Documentation/kbuild/llvm.rst | 4 ++--
> 1 fi
Hello maintainers,
Would you mind please picking up this patch? KernelCI has been
erroring for over a week without it.
On Thu, Sep 17, 2020 at 2:45 PM Nick Desaulniers
wrote:
>
> There is no case after the default from which to fallthrough to. Clang
> will error in this case (un
On Wed, Sep 23, 2020 at 7:28 PM kernel test robot wrote:
>
> Hi Nick,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on kdave/for-next]
> [also build test ERROR on f2fs/dev-test linus/master v5.9-rc6 next-20200923]
> [cannot apply to
t; #11 0x5570ed731639 in handle_internal_command tools/perf/perf.c:365:8
> #12 0x5570ed7323cd in run_argv tools/perf/perf.c:409:2
> #13 0x5570ed731076 in main tools/perf/perf.c:539:3
>
> Fixes: commit f5a56570a3f2 ("perf test: Fix memory leaks in parse-metric
> test&
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Signed-off-by: Nick Terrell
---
fs/squashfs/zstd_wrapper.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/squashfs/zstd_wrapper.c b/fs
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is more efficient because it uses the single-pass API instead of
the streaming API. The streaming API is not necessary because the whole
input and output buffers are available. This saves memory because
From: Nick Terrell
All callers have been transitioned to the new zstd-1.4.6 API. There are
no more callers of the zstd compatibility wrapper, so delete it.
Signed-off-by: Nick Terrell
---
include/linux/zstd_compat.h | 116
1 file changed, 116 deletions
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Signed-off-by: Nick Terrell
---
lib/decompress_unzstd.c | 40 ++--
1 file changed, 14 insertions(+), 26 deletions(-)
diff --git a/lib
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Signed-off-by: Nick Terrell
---
fs/btrfs/zstd.c | 48
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/fs
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Signed-off-by: Nick Terrell
---
crypto/zstd.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/crypto/zstd.c b/crypto/zstd.c
From: Nick Terrell
Adds decompress_sources.h which includes every .c file necessary for
zstd decompression. This is used in decompress_unzstd.c so the internal
structure of the library isn't exposed.
This allows us to upgrade the zstd library version without modifying any
callers. Instead we
From: Nick Terrell
Adds zstd_compat.h which provides the necessary functions from the
current zstd.h API. It is only active for zstd versions 1.4.6 and newer.
That means it is disabled currently, but will become active when a later
patch in this series updates the zstd library in the kernel
From: Nick Terrell
This patchset upgrades the zstd library to the latest upstream release. The
current zstd version in the kernel is a modified version of upstream zstd-1.3.1.
At the time it was integrated, zstd wasn't ready to be used in the kernel as-is.
But, it is now possible to use upstream
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Signed-off-by: Nick Terrell
---
crypto/zstd.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/crypto/zstd.c b/crypto/zstd.c
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Signed-off-by: Nick Terrell
---
fs/squashfs/zstd_wrapper.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/squashfs/zstd_wrapper.c b/fs
From: Nick Terrell
All callers have been transitioned to the new zstd-1.4.6 API. There are
no more callers of the zstd compatibility wrapper, so delete it.
Signed-off-by: Nick Terrell
---
include/linux/zstd_compat.h | 116
1 file changed, 116 deletions
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is more efficient because it uses the single-pass API instead of
the streaming API. The streaming API is not necessary because the whole
input and output buffers are available. This saves memory because
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Signed-off-by: Nick Terrell
---
lib/decompress_unzstd.c | 40 ++--
1 file changed, 14 insertions(+), 26 deletions(-)
diff --git a/lib
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Signed-off-by: Nick Terrell
---
fs/btrfs/zstd.c | 48
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/fs
From: Nick Terrell
This patchset upgrades the zstd library to the latest upstream release. The
current zstd version in the kernel is a modified version of upstream zstd-1.3.1.
At the time it was integrated, zstd wasn't ready to be used in the kernel as-is.
But, it is now possible to use upstream
From: Nick Terrell
Adds zstd_compat.h which provides the necessary functions from the
current zstd.h API. It is only active for zstd versions 1.4.6 and newer.
That means it is disabled currently, but will become active when a later
patch in this series updates the zstd library in the kernel
From: Nick Terrell
Adds decompress_sources.h which includes every .c file necessary for
zstd decompression. This is used in decompress_unzstd.c so the internal
structure of the library isn't exposed.
This allows us to upgrade the zstd library version without modifying any
callers. Instead we
On Mon, Sep 21, 2020 at 3:13 PM Borislav Petkov wrote:
>
> On Mon, Sep 21, 2020 at 01:59:43PM -0700, Nick Desaulniers wrote:
> > Right, the two sequences above look almost the same, except those 4
> > bytes of zeros (the disassembler gets confused about the rest, but
>
On Tue, Sep 22, 2020 at 9:27 AM Ian Bearman wrote:
>
> Hi, Nick. Thanks for reaching out again. I'm excited to see other groups
> taking an interest in LTO and PGO for Linux. CFI for the kernel sounds like a
> huge deal, nice!
Yes, CFI is quite nice. There are some hardwar
e IR for this file built with this
config). If this is deterministically reproducible, I suppose we
could set a watchpoint on the address being overwritten?
(Un-interestingly, I do get a panic trying to boot that config in
qemu, unless I bump the VMs RAM up.)
> >
> > Hi Boris,
> >
> > Memory corruption is definitely possible. There are hundreds of known
> > bugs that can potentially lead to silent memory corruptions, and some
> > observed to lead to silent memory corruptions.
> >
> > However, these tend to produce crash signatures with 1-2 crashes.
> > While this has 6 and they look similar and all happened on the only
> > instance that uses clang. So my bet would be on
> > something-clang-related rather than a silent memory corruption.
> > +clang-built-linux
>
>
> general protection fault in pvclock_gtod_notify (2) looks somewhat similar:
> - only clang
> - gpf in systems code
> - happened few times
>
> https://syzkaller.appspot.com/bug?extid=1dccfcb049726389379c
> https://groups.google.com/g/syzkaller-bugs/c/0eUUkjFKrBg/m/nGfTjIfCBAAJ
Dmitry,
Is there an easy way for me to get from
https://syzkaller.appspot.com/upstream to ? ctrl+f, `clang`, returns nothing on that first link; it
seems the compiler version is only included in the email?
--
Thanks,
~Nick Desaulniers
On Mon, Sep 21, 2020 at 11:47 AM Dan Williams wrote:
>
> On Mon, Sep 21, 2020 at 11:35 AM Nick Desaulniers
> wrote:
> >
> > Hello DAX maintainers,
> > I noticed our PPC64LE builds failing last night:
> > https://travis-ci.com/github/ClangBuiltLinux/continuous-int
on -next.
--
Thanks,
~Nick Desaulniers
o the redefinition of KBUILD_CFLAGS dropping -no-integrated-as),
> which has so far defaulted to not generating the GOTPCRELX
> relocations.
>
> Nick Desaulniers reports [1,2]:
> A recent change [3] to a default value of configuration variable
> (ENABLE_X86_RELAX_RE
passing --reroll-count=2 to git).
Prefer `-v2` when using `git format-patch`.
--
Thanks,
~Nick Desaulniers
ust for Android, why can't Android solve it
> >with only patch 1/2 by tweaking the seccomp filter?
>
> I would let Nick (nnk@) and Jeff (jeffv@) respond to this.
>
> The previous responses from both of them on this email thread
> (https://lore.kernel.org/lkml/CAB
series in question. In this case:
https://lore.kernel.org/lkml/cabcjkueywvnb2mqw_pcltzb8f1+sa1qolji_5qmkwdfccws...@mail.gmail.com/T/#t
is the cover letter. Then in my tree:
$ b4 am
https://lore.kernel.org/lkml/cabcjkueywvnb2mqw_pcltzb8f1+sa1qolji_5qmkwdfccws...@mail.gmail.com/T/#t
-o - | git am
--
Thanks,
~Nick Desaulniers
mask) > (typeof(_reg))~0ull, \
53 _pfx "type of reg too small for mask"); \
so the 0ULL in FIELD_PREP is important. In __BF_FIELD_CHECK, the
typeof(_reg) is unsigned long long (because 0ULL was passed). So we
have a comparison between a u32 and a u64; indeed any u32 can never be
greater than a u64 that we know has the value of ULLONG_MAX.
I did send a series splitting these up, I wonder if they'd help here:
https://lore.kernel.org/lkml/20200708230402.1644819-3-ndesaulni...@google.com/
--
Thanks,
~Nick Desaulniers
> On Sep 17, 2020, at 6:47 PM, Chao Yu wrote:
>
> On 2020/9/18 3:34, Nick Terrell wrote:
>>> On Sep 17, 2020, at 11:00 AM, Nick Terrell wrote:
>>>
>>>
>>>
>>>> On Sep 16, 2020, at 11:31 PM, Chao Yu wrote:
>>>>
>>
uot;)
Link: https://bugs.llvm.org/show_bug.cgi?id=47539
Acked-by: Gustavo A. R. Silva
Reviewed-by: Gustavo A. R. Silva
Reviewed-by: Miaohe Lin
Reviewed-by: Nathan Chancellor
Suggested-by: Joe Perches
Signed-off-by: Nick Desaulniers
---
Changes v3:
* update the commit message as per Joe.
* co
On Wed, Sep 16, 2020 at 1:19 PM Joe Perches wrote:
>
> On Wed, 2020-09-16 at 13:02 -0700, Nick Desaulniers wrote:
> > * (call of function with __attribute__(__noreturn__))
>
> I guess panic counts. I count 11 of those.
>
> Are there any other uses of functions with __n
> On Sep 17, 2020, at 11:00 AM, Nick Terrell wrote:
>
>
>
>> On Sep 16, 2020, at 11:31 PM, Chao Yu wrote:
>>
>> Hi Nick,
>>
>> On 2020/9/17 2:39, Nick Terrell wrote:
>>>> On Sep 15, 2020, at 11:31 PM, Chao Yu wrote:
>>
> On Sep 16, 2020, at 11:31 PM, Chao Yu wrote:
>
> Hi Nick,
>
> On 2020/9/17 2:39, Nick Terrell wrote:
>>> On Sep 15, 2020, at 11:31 PM, Chao Yu wrote:
>>>
>>> Hi Nick,
>>>
>>> remove not related mailing list.
>>>
n.
We're very open to improving and changing zstd to better fit the needs of the
kernel. If there are use cases that can't use the existing API, or the existing
API isn't optimal, or any other problems, we’re happy to help figure out the
best solution. Opening an issue on our upstream GitHub repo is the best way to
get our attention
-Nick
> Fixing those are probably going to be much easier if we’re close to the zstd
> upstream, again so that we can leverage testing and long term code
> maintenance done there.
>
> -chris
rap after dead end instructions), so
> expand that check to include dead end functions.
Reviewed-by: Nick Desaulniers
Tested-by: Nick Desaulniers
Reported-by: kbuild test robot
Thanks for the patch, Ilie! With this, a
defconfig+CONFIG_UBSAN+CONFIG_UBSAN_TRAP goes from 82 unreachable
inst
On Thu, Sep 17, 2020 at 6:15 AM Jing Xiangfeng wrote:
>
> Remove the superfuous break, as there is a 'return' before it.
superfluous (missed "l")
>
> Signed-off-by: Jing Xiangfeng
Reviewed-by: Nick Desaulniers
Thanks for the patch; I audited the rest of
> On Sep 16, 2020, at 1:48 AM, Christoph Hellwig wrote:
>
> On Tue, Sep 15, 2020 at 08:42:54PM -0700, Nick Terrell wrote:
>> From: Nick Terrell
>>
>> Adds zstd_compat.h which provides the necessary functions from the
>> current zstd.h API. It is only active
> On Sep 16, 2020, at 7:46 AM, Christoph Hellwig wrote:
>
> On Wed, Sep 16, 2020 at 10:43:04AM -0400, Chris Mason wrote:
>> Otherwise we just end up with drift and kernel-specific bugs that are harder
>> to debug. To the extent those APIs make us contort the kernel cod
> On Sep 15, 2020, at 8:42 PM, Nick Terrell wrote:
>
> From: Nick Terrell
>
> Upgrade to the latest upstream zstd version 1.4.6.
>
> This patch is 100% generated from upstream zstd commit c4763f087c2b [0].
>
> This patch is very large because it is transitioning fr
o use the preferred fallthrough macro")
Link: https://bugs.llvm.org/show_bug.cgi?id=47539
Suggested-by: Joe Perches
Signed-off-by: Nick Desaulniers
---
Changes v2:
* add break rather than no terminating statement as per Joe.
* add Joe's suggested by tag.
* add blurb about acceptable terminal statements
On Wed, Sep 16, 2020 at 1:46 AM Marco Elver wrote:
>
> On Wed, 16 Sep 2020 at 10:30, wrote:
> > On Tue, Sep 15, 2020 at 08:09:16PM +0200, Marco Elver wrote:
> > > On Tue, 15 Sep 2020 at 19:40, Nick Desaulniers
> > > wrote:
> > > > On Tue, Sep 1
> On Sep 15, 2020, at 11:31 PM, Chao Yu wrote:
>
> Hi Nick,
>
> remove not related mailing list.
>
> On 2020/9/16 11:43, Nick Terrell wrote:
>> From: Nick Terrell
>> Move away from the compatibility wrapper to the zstd-1.4.6 API. This
>> code is mo
the range 0–8 inclusive."
pt. 3 https://nickdesaulniers.github.io/blog/2014/04/18/lets-write-some-x86-64/
...2014, jesus...
"But you never can tell exactly what the compiler is doing. It doesn’t
always come out the way you want. Like a dusty pane or warped mirror."
Seems I'd learn more about that than I'd could have ever envisioned...
--
Thanks,
~Nick Desaulniers
601 - 700 of 9552 matches
Mail list logo
