it
worked around was apparently fixed in less back in June 2007.
So remove the hack from here as well.
Signed-off-by: Arvind Sankar
---
tools/lib/subcmd/pager.c | 17 -
tools/lib/subcmd/run-command.c | 2 --
tools/lib/subcmd/run-command.h | 1 -
3 files changed, 20 deletion
23, 2018 at 07:38:37PM -0500, Arvind Sankar wrote:
> > > We inherited this hack with the original code from the Git project. The
> > > select call is invalid as the two fd_set pointers should not be aliased.
> > >
> > > We could fix it, but the Git project remo
On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote:
> On 01/31/2018 04:07 PM, Mimi Zohar wrote:
> > On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I
> > configured in tmpfs and am using rootfs but I want that
> rootfs
> >> to be ramfs, not tmpfs" code doesn't seem to be
or suspend callback as well.
Also move a couple of defines into the appropriate header file instead
of inline in the .c file.
Fixes: fb29f76cc566 ("igb: Fix an issue that PME is not enabled during runtime
suspend")
Signed-off-by: Arvind Sankar
---
.../net/ethernet/intel/igb/e10
Desaulniers wrote:
> > > > Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
> > > > explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
> > > > way that's forward compatible with existing configs, and makes adding
> > &g
On Thu, Feb 04, 2021 at 11:51:55AM +0100, Borislav Petkov wrote:
> On Wed, Feb 03, 2021 at 09:29:18PM +0100, Ard Biesheuvel wrote:
> > I think we have agreement on the approach but it is unclear who is
> > going to write the patch.
>
> How's that below?
>
> And frankly, I'd even vote for removing
On Thu, Feb 04, 2021 at 11:13:18PM +0100, Borislav Petkov wrote:
> On Thu, Feb 04, 2021 at 04:43:58PM -0500, Arvind Sankar wrote:
> > This should check EFI_VA_END instead of EFI_VA_START, and maybe throw in
> > a BUG_ON if EFI_VA_END >= EFI_VA_START.
>
> No need:
On Mon, May 18, 2020 at 10:09:34PM -0700, Joe Perches wrote:
> On Mon, 2020-05-18 at 20:44 -0700, Andrew Morton wrote:
> > On Tue, 19 May 2020 11:29:46 +0800 王程刚 wrote:
> >
> > > Function pr_notice print max length maybe less than the command line
> > > length,
> > > need more times to print all
On Wed, Jul 29, 2020 at 03:04:43PM -0700, Kees Cook wrote:
> On Fri, Jul 17, 2020 at 04:17:54PM -0400, Arvind Sankar wrote:
> > Same as v5 previously posted, but rebased onto next-20200717.
> >
> > v5:
> > https://lore.kernel.org/lkml/20200715004133.1430068-1-nive
On Tue, Jul 28, 2020 at 06:57:01PM -0400, Arvind Sankar wrote:
> v2->v3:
> - Fix the first patch: command line size should be strlen + 1 to account
> for terminating NUL. Avoid calling add_identity_map if cmdline was
> NULL, though it should do nothing in that case anyway.
Hi
.entrytext
>>> .bsdata range is [0x1FF, 0x398]
>>> .entrytext range is [0x26C, 0x2D3]
Explicitly pull .text.startup into the .text output section to avoid
this.
Signed-off-by: Arvind Sankar
---
arch/x86/boot/setup.ld | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
ut it seems like
a good idea to explicitly include .text.startup anyway.
Arvind Sankar (1):
x86/boot: Add .text.startup to setup.ld
arch/x86/boot/setup.ld | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.26.2
On Wed, May 20, 2020 at 06:56:53PM -0400, Arvind Sankar wrote:
> arch/x86/boot/setup.elf currently has an orphan section .text.startup,
> and lld git as of ebf14d9b6d8b is breaking on 64-bit due to what seems
> to be a change in behavior on orphan section placement (details in patch
On Thu, May 21, 2020 at 02:31:17PM +0200, Petr Mladek wrote:
> On Wed 2020-05-20 21:40:07, Andrew Morton wrote:
> > On Thu, 21 May 2020 13:36:28 +0900 Sergey Senozhatsky
> > wrote:
> >
> > > On (20/05/20 18:00), Andrew Morton wrote:
> > > [..]
> > > > I'm wondering if we shold add a kernel puts(
On Wed, May 20, 2020 at 07:12:17PM -0700, Fangrui Song wrote:
> On 2020-05-20, Arvind Sankar wrote:
> >On Wed, May 20, 2020 at 06:56:53PM -0400, Arvind Sankar wrote:
> >> arch/x86/boot/setup.elf currently has an orphan section .text.startup,
> >> and lld git as of ebf
verlaps with
.entrytext
>>> .bsdata range is [0x1FF, 0x398]
>>> .entrytext range is [0x26C, 0x2D3]
Explicitly pull .text.startup into the .text output section to avoid
this.
[1] https://reviews.llvm.org/D75225
Signed-off-by: Arvind Sankar
Reviewed-by: Fangrui Song
On Tue, May 19, 2020 at 12:42:35PM -0700, Joe Perches wrote:
> ARM may have its longest possible command line larger than the longest
> possible printk.
>
> If necessary, emit the commend line on multiple lines.
>
> Signed-off-by: Joe Perches
> ---
>
> compiled, untested
>
> init/main.c | 31
org/lkml/20200807194100.3570838-1-ndesaulni...@google.com/
[2] https://github.com/ClangBuiltLinux/linux/issues/1121
[3] https://reviews.llvm.org/rGc41a18cf61790fc898dcda1055c3efbf442c14c0
[4] https://lore.kernel.org/lkml/20200731202738.2577854-1-nived...@alum.mit.edu/
Signed-off-by: Arvind Sankar
Reported-
On Tue, Aug 11, 2020 at 10:58:40AM -0700, Nick Desaulniers wrote:
> > Cc: sta...@vger.kernel.org # 4.19.x
>
> Thanks Arvind, good write up. Just curious about this stable tag, how
> come you picked 4.19? I can see boot failures in our CI for x86+LLD
> back to 4.9. Can we amend that tag to use `
On Tue, Aug 11, 2020 at 04:04:40PM -0700, Nick Desaulniers wrote:
> On Tue, Aug 11, 2020 at 3:44 PM Arvind Sankar wrote:
> >
> > On Tue, Aug 11, 2020 at 10:58:40AM -0700, Nick Desaulniers wrote:
> > > > Cc: sta...@vger.kernel.org # 4.19.x
> > >
> > >
On Tue, Aug 11, 2020 at 04:51:23PM -0700, Nick Desaulniers wrote:
> On Tue, Aug 11, 2020 at 4:43 PM Arvind Sankar wrote:
> >
> > On Tue, Aug 11, 2020 at 04:04:40PM -0700, Nick Desaulniers wrote:
> > > On Tue, Aug 11, 2020 at 3:44 PM Arvind Sankar
> > > wrot
.mit.edu/
Signed-off-by: Arvind Sankar
Reported-by: Nick Desaulniers
Reviewed-by: Nick Desaulniers
Tested-by: Nick Desaulniers
Cc: sta...@vger.kernel.org
Signed-off-by: Arvind Sankar
---
arch/x86/boot/compressed/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/boot/co
On Fri, Jul 24, 2020 at 04:25:20PM -0700, Kees Cook wrote:
> On Sat, Jul 18, 2020 at 08:44:50AM +0300, Ard Biesheuvel wrote:
> > On Fri, 17 Jul 2020 at 21:17, Nick Desaulniers
> > wrote:
> > >
> > > On Fri, Jul 17, 2020 at 6:46 AM Arvind Sankar
> > > w
both .rel.dyn and .rela.dyn, instead of just
one per arch.
Ard Biesheuvel (3):
x86/boot/compressed: Move .got.plt entries out of the .got section
x86/boot/compressed: Force hidden visibility for all symbol references
x86/boot/compressed: Get rid of GOT fixup code
Arvind Sankar (4):
x86/bo
.
While at it, drop the KEEP() from the linker script, as it has no effect
on the contents of output sections that are created by the linker itself.
Tested-by: Nick Desaulniers
Tested-by: Sedat Dilek
Reviewed-by: Kees Cook
Signed-off-by: Ard Biesheuvel
Acked-by: Arvind Sankar
Signed-off-by
erlaps with
.entrytext
>>> .bsdata range is [0x1FF, 0x398]
>>> .entrytext range is [0x26C, 0x2D3]
Add .text.* to the .text output section to fix this, and also prevent
any future surprises if the compiler decides to create other such
sections.
[1] https://reviews.llvm.org/
unless startup_32 is in the same section
as the code. Move efi32_pe_entry into .head.text so that it can use
the same method to avoid relocations.
Tested-by: Nick Desaulniers
Tested-by: Sedat Dilek
Reviewed-by: Kees Cook
Reviewed-by: Ard Biesheuvel
Reviewed-by: Fangrui Song
Signed-off-by:
: Arvind Sankar
Signed-off-by: Arvind Sankar
From: Ard Biesheuvel
Link: https://lore.kernel.org/r/20200523120021.34996-3-a...@kernel.org
---
arch/x86/boot/compressed/Makefile | 1 +
arch/x86/boot/compressed/vmlinux.lds.S | 1 +
drivers/firmware/efi/libstub/Makefile | 2 +-
drivers
versions (as well as
clang and lld).
Tested-by: Nick Desaulniers
Tested-by: Sedat Dilek
Reviewed-by: Kees Cook
Reviewed-by: Ard Biesheuvel
Reviewed-by: Fangrui Song
Signed-off-by: Arvind Sankar
---
arch/x86/boot/compressed/Makefile | 28 +++---
arch/x86/boot/compressed
Kees Cook
Reviewed-by: Ard Biesheuvel
Reviewed-by: Fangrui Song
Signed-off-by: Arvind Sankar
---
arch/x86/boot/compressed/Makefile | 12 ++--
arch/x86/boot/compressed/head_32.S | 17 -
arch/x86/boot/compressed/head_64.S | 4 ++--
arch/x86/boot/compressed/mkpiggy.c
Nick Desaulniers
Tested-by: Sedat Dilek
Reviewed-by: Kees Cook
Signed-off-by: Ard Biesheuvel
Acked-by: Arvind Sankar
Signed-off-by: Arvind Sankar
From: Ard Biesheuvel
Link: https://lore.kernel.org/r/20200523120021.34996-2-a...@kernel.org
---
arch/x86/boot/compressed/vmlinux.lds.S
On Fri, Jul 31, 2020 at 04:08:16PM -0700, Kees Cook wrote:
> For readability, move the zero-sized sections to the end after DISCARDS
> and mark them NOLOAD for good measure.
>
> Signed-off-by: Kees Cook
> ---
> arch/x86/boot/compressed/vmlinux.lds.S | 42 +++---
> 1 file chan
On Fri, Jul 31, 2020 at 04:08:13PM -0700, Kees Cook wrote:
> The .got.plt section should always be zero (or filled only with the
> linker-generated lazy dispatch entry). Enforce this with an assert and
> mark the section as NOLOAD. This is more sensitive than just blindly
> discarding the section.
On Fri, Jul 31, 2020 at 09:47:55PM -0400, Arvind Sankar wrote:
> On Fri, Jul 31, 2020 at 04:08:16PM -0700, Kees Cook wrote:
> > For readability, move the zero-sized sections to the end after DISCARDS
> > and mark them NOLOAD for good measure.
> >
> > Signed-off-by: K
On Fri, Jul 31, 2020 at 04:07:57PM -0700, Kees Cook wrote:
> From: Nick Desaulniers
>
> Basically, consider .text.{hot|unlikely|unknown}.* part of .text, too.
>
> When compiling with profiling information (collected via PGO
> instrumentations or AutoFDO sampling), Clang will separate code into
>
On Fri, Jul 31, 2020 at 10:35:14PM -0700, Kees Cook wrote:
> On Fri, Jul 31, 2020 at 09:47:55PM -0400, Arvind Sankar wrote:
> > On Fri, Jul 31, 2020 at 04:08:16PM -0700, Kees Cook wrote:
> > > For readability, move the zero-sized sections to the end after DISCARDS
> > &g
On Fri, Jul 31, 2020 at 10:36:00PM -0700, Kees Cook wrote:
> On Fri, Jul 31, 2020 at 10:53:25PM -0400, Arvind Sankar wrote:
> > On Fri, Jul 31, 2020 at 09:47:55PM -0400, Arvind Sankar wrote:
> > > On Fri, Jul 31, 2020 at 04:08:16PM -0700, Kees Cook wrote:
> > > >
On Fri, Jul 31, 2020 at 11:18:02PM -0700, Kees Cook wrote:
> On Fri, Jul 31, 2020 at 11:51:28PM -0400, Arvind Sankar wrote:
> >
> > This also changes the ordering to place all hot resp unlikely sections
> > separate
> > from other text, while currently it places th
On Fri, Feb 07, 2020 at 02:46:03PM -0500, Steven Rostedt wrote:
>
> diff --git a/init/main.c b/init/main.c
> index 491f1cdb3105..113c8244e5f0 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -142,6 +142,15 @@ static char *extra_command_line;
> /* Extra init arguments */
> static char *extra_i
strnlen is safer in case the command line is not NUL-terminated.
Signed-off-by: Arvind Sankar
---
arch/x86/boot/compressed/kaslr.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 903ccdca0551
Hi,
I'd like to add one more patch to the series if that's ok.
Thanks.
Arvind Sankar (1):
x86/kaslr: Replace strlen with strnlen
arch/x86/boot/compressed/kaslr.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
--
2.26.2
On Tue, Aug 04, 2020 at 12:03:45AM +0900, Masami Hiramatsu wrote:
> On Sat, 1 Aug 2020 22:33:18 -0400
> Arvind Sankar wrote:
> >
> > I came across this as I was poking around some of the command line
> > parsing. AFAICT, initargs_found will never be set to true here
On Wed, Aug 19, 2020 at 11:35:11AM -0700, Nick Desaulniers wrote:
> On Wed, Aug 19, 2020 at 7:08 AM Arvind Sankar wrote:
> >
> > gcc can transform the loop in a naive implementation of memset/memcpy
> > etc into a call to the function itself. This optimization is enabl
On Wed, Aug 19, 2020 at 12:16:53PM -0700, Nick Desaulniers wrote:
> We're reverting
> commit 5f074f3e192f ("lib/string.c: implement a basic bcmp")
> in favor of -fno-builtin-bcmp. Remove the additional definition here,
> too.
>
> arch/x86/purgatory/Makefile uses -ffreestanding, so there's no risk
On Thu, Aug 20, 2020 at 12:44:06PM +0200, Thomas Gleixner wrote:
> On Thu, Aug 13 2020 at 14:09, Arvind Sankar wrote:
> > On Thu, Aug 13, 2020 at 10:37:01AM -0700, Paul E. McKenney wrote:
> >> > Let me ask (hopefully) useful questions this time:
> >> >
> >
On Thu, Aug 20, 2020 at 04:56:02PM +0200, Rasmus Villemoes wrote:
> On 18/08/2020 23.41, Arvind Sankar wrote:
> >
> > Note that -fno-builtin-foo seems to mean slightly different things in
> > clang and gcc. From experimentation, clang will neither optimize a call
>
On Thu, Aug 20, 2020 at 03:41:33PM -0700, H. Peter Anvin wrote:
>
> I would prefer this to be a #pragma for a header file, rather than
> having a very long command line for everything...
>
> -hpa
>
There is @option_file, though.
On Thu, Aug 06, 2020 at 02:19:53PM +0300, Andy Shevchenko wrote:
> On Tue, May 26, 2020 at 03:14:11PM -0400, Arvind Sankar wrote:
>
> Side question: are you going to submit a v3 of this?
> Or i.o.w. what is the status of this series?
>
> --
> With Best Regards,
> An
On Fri, Aug 07, 2020 at 11:12:29AM -0700, Nick Desaulniers wrote:
> On Fri, Jul 31, 2020 at 4:08 PM Kees Cook wrote:
> >
> > From: Arvind Sankar
> >
> > The BFD linker generates run-time relocations for z_input_len and
> > z_output_len, even though they are
On Fri, Aug 07, 2020 at 12:41:00PM -0700, Nick Desaulniers wrote:
> A recent change to a default value of configuration variable
> (ENABLE_X86_RELAX_RELOCATIONS OFF -> ON) in LLVM now causes Clang's
> integrated assembler to emit R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX
> relocations. LLD will rel
On Fri, Aug 07, 2020 at 02:54:39PM -0700, Nick Desaulniers wrote:
> On Fri, Aug 7, 2020 at 2:29 PM Arvind Sankar wrote:
> >
> > On Fri, Aug 07, 2020 at 12:41:00PM -0700, Nick Desaulniers wrote:
> > > A recent change to a default value of configuration variable
> > &
On Tue, Aug 18, 2020 at 12:13:22PM -0700, Linus Torvalds wrote:
> On Tue, Aug 18, 2020 at 12:03 PM H. Peter Anvin wrote:
> >
> > I'm not saying "change the semantics", nor am I saying that playing
> > whack-a-mole *for a limited time* is unreasonable. But I would like to go
> > back
> > to the co
On Tue, Aug 18, 2020 at 01:58:51PM -0700, Nick Desaulniers wrote:
> On Tue, Aug 18, 2020 at 1:27 PM Nick Desaulniers
> wrote:
> >
> > On Tue, Aug 18, 2020 at 1:24 PM Arvind Sankar wrote:
> > >
> > > On Tue, Aug 18, 2020 at 12:13:22PM -0700, Linus Torvalds wr
On Mon, Aug 17, 2020 at 03:02:08PM -0700, Nick Desaulniers wrote:
> -ffreestanding typically inhibits "libcall optimizations" where calls to
> certain library functions can be replaced by the compiler in certain
> cases to calls to other library functions that may be more efficient.
> This can be p
, so also add a flag to explicitly disable
it.
[0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
Signed-off-by: Arvind Sankar
---
lib/Makefile | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/lib/Makefile b/lib/Makefile
index e290fc5707ea..80edea49613f 100644
On Tue, Aug 18, 2020 at 03:59:45PM -0700, Nick Desaulniers wrote:
> On Tue, Aug 18, 2020 at 3:25 PM Arvind Sankar wrote:
> >
> > Another thing that needs to be fixed is that at least lib/string.c needs
> > to be compiled with -ffreestanding.
> >
> > gc
On Tue, Aug 18, 2020 at 03:59:45PM -0700, Nick Desaulniers wrote:
> On Tue, Aug 18, 2020 at 3:25 PM Arvind Sankar wrote:
> >
> > Another thing that needs to be fixed is that at least lib/string.c needs
> > to be compiled with -ffreestanding.
> >
> > gc
On Tue, Aug 18, 2020 at 05:44:03PM -0700, Linus Torvalds wrote:
> On Tue, Aug 18, 2020 at 4:43 PM Arvind Sankar wrote:
> >
> > This by itself is insufficient for gcc if the optimization was
> > explicitly enabled by CFLAGS, so also add a flag to explicitly disable
> &g
On Tue, Aug 18, 2020 at 08:32:58PM -0700, Linus Torvalds wrote:
> On Tue, Aug 18, 2020 at 8:04 PM Arvind Sankar wrote:
>
> > Might be worth optimizing strnlen etc with the word-at-a-time thing though.
>
> Yeah, possibly. Except the kernel almost never uses strnlen for
>
versions.
Add -ffreestanding, which implicitly disables this optimization with
gcc. It is unclear whether clang performs such optimizations, but
hopefully it will also not do so in a freestanding environment.
[0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
Signed-off-by: Arvind Sankar
On Sat, Dec 05, 2020 at 08:36:02PM +0100, Ard Biesheuvel wrote:
> On Fri, 4 Dec 2020 at 19:02, James Bottomley
> wrote:
> >
> > On Fri, 2020-12-04 at 18:07 +0100, Ard Biesheuvel wrote:
> > > On Fri, 4 Dec 2020 at 18:06,
> > > wrote:
> > > > From: Francis Laniel
> > > >
> > > > The two functions
On Thu, Dec 10, 2020 at 03:18:45PM -0800, Nick Desaulniers wrote:
> On Fri, Dec 4, 2020 at 9:06 AM Arvind Sankar wrote:
> >
> > Why? Does this actually cause any problems?
> >
> > It seems like the options for gcc can actually be very straightforward:
> > you just
On Fri, Dec 11, 2020 at 09:45:15AM +, David Laight wrote:
> From: Arvind Sankar
> > Sent: 10 December 2020 18:14
> ...
> > I wasn't aware of str_has_prefix() at the time. It does seem useful to
> > eliminate the duplication of the string literal, I like the
>
On Mon, Dec 21, 2020 at 11:14:39AM -0800, Nick Desaulniers wrote:
> On Wed, Sep 2, 2020 at 7:31 PM Arvind Sankar wrote:
> >
> > When CONFIG_RETPOLINE is disabled, Clang uses a jump table for the
> > switch statement in cmdline_find_option (jump tables are disabled when
&g
On Mon, Jan 18, 2021 at 09:24:09PM +0100, Borislav Petkov wrote:
> > > > As a matter of fact, it seems like the four assertions could be combined
> > > > into:
> > > > BUILD_BUG_ON((EFI_VA_END & P4D_MASK) != (MODULES_END & P4D_MASK));
> > > > BUILD_BUG_ON((EFI_VA_START & P4D_MASK) != (E
the time-related functions")
> >
> > Hi Randy,
> > Thanks for the patch, it looks good to me. I only had a question on
> > the commit message.
> >
> > Is this also related to:
> > commit 3347acc6fcd4 ("compiler.h: fix barrier_data() on clang&qu
On Sun, Nov 15, 2020 at 08:35:30PM -0800, Nick Desaulniers wrote:
> The kernel uses `-include` to include include/linux/compiler_types.h
> into all translation units (see scripts/Makefile.lib), which #includes
> compiler_attributes.h.
>
> arch/powerpc/boot/ uses different compiler flags from the r
On Tue, Nov 03, 2020 at 04:53:42PM -0800, Nick Desaulniers wrote:
> Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
> explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
> way that's forward compatible with existing configs, and makes adding
> future versions
On Thu, Dec 03, 2020 at 03:28:14PM -0800, Nick Desaulniers wrote:
> On Thu, Dec 3, 2020 at 3:22 PM Nick Desaulniers
> wrote:
> >
> > On Tue, Nov 24, 2020 at 9:28 AM Arvind Sankar wrote:
> > >
> > > On Tue, Nov 03, 2020 at 04:53:43PM -0800, Nick Desaulniers w
On Mon, Nov 23, 2020 at 06:33:57PM -0600, Segher Boessenkool wrote:
> On Mon, Nov 23, 2020 at 06:22:10PM -0500, Arvind Sankar wrote:
> > Btw, is -gsplit-dwarf at all useful for assembler files?
>
> If you invoke the assembler via the compiler, with that flag it still
> creat
On Tue, Nov 03, 2020 at 04:53:43PM -0800, Nick Desaulniers wrote:
> DWARF v5 is the latest standard of the DWARF debug info format.
>
> Feature detection of DWARF5 is onerous, especially given that we've
> removed $(AS), so we must query $(CC) for DWARF5 assembler directive
> support. GNU `as` on
On Wed, Dec 02, 2020 at 11:58:15AM -0600, Tom Lendacky wrote:
> On 11/27/20 11:27 AM, Borislav Petkov wrote:
> > On Fri, Nov 27, 2020 at 12:13:24PM -0500, Arvind Sankar wrote:
> >> Commit
> >>26bfa5f89486 ("x86, amd: Cleanup init_amd")
> >> moved
On Thu, Dec 03, 2020 at 09:48:57AM +0100, Borislav Petkov wrote:
> On Wed, Dec 02, 2020 at 05:32:32PM -0500, Arvind Sankar wrote:
> > The pfn_range_is_mapped() call just checks whether it is mapped at all
> > in the direct mapping. Is the TSEG range supposed to be marked as
> >
On Wed, Jan 20, 2021 at 03:09:53PM -0800, Nick Desaulniers wrote:
> On Tue, Jan 19, 2021 at 1:35 PM Arnd Bergmann wrote:
> >
> > On Tue, Jan 19, 2021 at 10:18 PM 'Nick Desaulniers' via Clang Built
> > Linux wrote:
> > >
> > > On Tue, Jan 19, 2021 at 5:17 AM Adrian Ratiu
> > > wrote:
> > > > dif
On Thu, Jan 07, 2021 at 11:34:15PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> When 5-level page tables are enabled, clang triggers a BUILD_BUG_ON():
>
> x86_64-linux-ld: arch/x86/platform/efi/efi_64.o: in function
> `efi_sync_low_kernel_mappings':
> efi_64.c:(.text+0x22c): undefined
On Fri, Jan 15, 2021 at 08:07:29PM +0100, Borislav Petkov wrote:
> On Fri, Jan 15, 2021 at 11:32:03AM -0700, Nathan Chancellor wrote:
> > I triggered it with CONFIG_UBSAN=y + CONFIG_UBSAN_UNSIGNED_OVERFLOW=y
> > (it can be exposed with an allyesconfig/allmodconfig on mainline
> > currently).
>
> Y
On Fri, Jan 15, 2021 at 08:54:18PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 15, 2021 at 8:18 PM Borislav Petkov wrote:
> >
> > On Fri, Jan 15, 2021 at 02:11:25PM -0500, Arvind Sankar wrote:
> > > That's how build-time assertions work: they are _supposed_ to be
&g
On Fri, Jan 15, 2021 at 02:07:51PM -0500, Arvind Sankar wrote:
> On Thu, Jan 07, 2021 at 11:34:15PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > When 5-level page tables are enabled, clang triggers a BUILD_BUG_ON():
> >
> > x86_64-linux-ld: a
On Fri, Jan 15, 2021 at 03:12:25PM -0500, Arvind Sankar wrote:
> On Fri, Jan 15, 2021 at 08:54:18PM +0100, Arnd Bergmann wrote:
> > On Fri, Jan 15, 2021 at 8:18 PM Borislav Petkov wrote:
> > >
> > > On Fri, Jan 15, 2021 at 02:11:25PM -0500, Arvind Sankar wrote:
&g
On Tue, Dec 22, 2020 at 07:31:24PM +0800, Pan Zhang wrote:
> When the kernel is loading,
> the load address of the kernel needs to be calculated firstly.
>
> If the kernel address space layout randomization(`kaslr`) is enabled,
> the memory range reserved by the memmap parameter will be excluded
>
On Tue, Jan 05, 2021 at 09:54:52AM +0100, Ard Biesheuvel wrote:
> (cc Arvind)
>
> On Tue, 5 Jan 2021 at 09:54, Lin Feng wrote:
> >
> > On efi64 x86_64 system, the EFI_CONVENTIONAL_MEMORY regions will not
> > be mapped when making EFI runtime calls. So kexec-tools can not get
> > these from /sys/f
On Wed, Nov 11, 2020 at 11:09:46AM -0500, Arvind Sankar wrote:
> _PAGE_PAT_LARGE is already defined next to _PAGE_PAT. Remove the
> duplicate.
>
> Signed-off-by: Arvind Sankar
> Fixes: 4efb56649132 ("x86/mm: Tabulate the page table encoding definitions")
>
e cpu support was added two years ago. Remove it from there as
well.
Signed-off-by: Arvind Sankar
---
arch/x86/kernel/cpu/amd.c | 21 -
arch/x86/kernel/cpu/hygon.c | 20
2 files changed, 41 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/ke
On Fri, Nov 20, 2020 at 12:46:26PM +0100, Juergen Gross wrote:
> PVOP_VCALL4() is only used for Xen PV, while PVOP_CALL4() isn't used
> at all. Keep PVOP_CALL4() for 64 bits due to symmetry reasons.
>
> This allows to remove the 32-bit definitions of those macros leading
> to a substantial simplif
Hi Greg, I'm seeing what looks like an extra commit [1] in the 5.3.y branch
post the 5.3.2 tag, bumping version in the Makefile to 5.3.3.
Historically the version bump has only happened once all the stable
patches have been applied and the new version is getting tagged -- is
this a mistake or inten
On Thu, Oct 03, 2019 at 11:12:37AM -0400, Arvind Sankar wrote:
> Hi Greg, I'm seeing what looks like an extra commit [1] in the 5.3.y branch
> post the 5.3.2 tag, bumping version in the Makefile to 5.3.3.
> Historically the version bump has only happened once all the stable
>
On Sat, Sep 28, 2019 at 12:41:29PM +, Ingo Molnar wrote:
>
> * Randy Dunlap wrote:
>
> > On 9/3/19 8:50 AM, Andreas Smas wrote:
> > > Hi,
> > >
> > > For me, kernels built including this commit
> > > b059f801a937 (x86/purgatory: Use CFLAGS_REMOVE rather than reset
> > > KBUILD_CFLAGS)
> >
On Mon, Oct 07, 2019 at 09:34:48AM +0200, Christoph Hellwig wrote:
> Hi Arvind,
>
> can you try the patch below?
>
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 3f974919d3bd..52b709bf2b55 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-
On Mon, Oct 07, 2019 at 10:56:30AM -0700, Christoph Hellwig wrote:
> On Mon, Oct 07, 2019 at 07:55:28PM +0200, Christoph Hellwig wrote:
> > On Mon, Oct 07, 2019 at 01:54:32PM -0400, Arvind Sankar wrote:
> > > It doesn't boot with the patch. Won't it go
&
On Mon, Oct 07, 2019 at 01:58:57PM -0400, Arvind Sankar wrote:
> On Mon, Oct 07, 2019 at 10:56:30AM -0700, Christoph Hellwig wrote:
> > On Mon, Oct 07, 2019 at 07:55:28PM +0200, Christoph Hellwig wrote:
> > > On Mon, Oct 07, 2019 at 01:54:32PM -0400, Arvind Sankar wrote:
>
On Mon, Oct 07, 2019 at 10:31:49PM +0200, Hans de Goede wrote:
> HI,
>
> On 07-10-2019 22:05, Nathan Chancellor wrote:
> > On Mon, Oct 07, 2019 at 07:55:46PM +0200, Hans de Goede wrote:
> >> Since we link purgatory.ro with -r aka we enable "incremental linking"
> >> no checks for unresolved symbol
On Mon, Oct 07, 2019 at 08:47:54PM +0200, Christoph Hellwig wrote:
> On Mon, Oct 07, 2019 at 02:32:07PM -0400, Arvind Sankar wrote:
> > On Mon, Oct 07, 2019 at 01:58:57PM -0400, Arvind Sankar wrote:
> > > On Mon, Oct 07, 2019 at 10:56:30AM -0700, Christoph Hellwig wrote:
>
On Mon, Oct 07, 2019 at 06:10:55PM -0400, Arvind Sankar wrote:
> On Mon, Oct 07, 2019 at 08:47:54PM +0200, Christoph Hellwig wrote:
> > On Mon, Oct 07, 2019 at 02:32:07PM -0400, Arvind Sankar wrote:
> > > On Mon, Oct 07, 2019 at 01:58:57PM -0400, Arvind Sankar wrote:
> >
On Tue, Oct 08, 2019 at 09:32:10AM +0200, Christoph Hellwig wrote:
> On Mon, Oct 07, 2019 at 07:54:02PM -0400, Arvind Sankar wrote:
> > > Do you want me to resend the patch as its own mail, or do you just take
> > > it with a Tested-by: from me? If the former, I ass
("dma-mapping: provide a better default
->get_required_mask")
Reported-by: Arvind Sankar
Tested-by: Arvind Sankar
Originally-by: Christoph Hellwig
Signed-off-by: Christoph Hellwig
Fixed-by: Arvind Sankar
Signed-off-by: Arvind Sankar
---
drivers/iommu/intel-iommu.c | 10 +-
On Tue, Oct 08, 2019 at 07:51:03AM -0400, Arvind Sankar wrote:
> On Tue, Oct 08, 2019 at 09:32:10AM +0200, Christoph Hellwig wrote:
> > On Mon, Oct 07, 2019 at 07:54:02PM -0400, Arvind Sankar wrote:
> > > > Do you want me to resend the patch as its own mail, or do you just t
On Wed, Oct 09, 2019 at 08:50:43AM +0200, Christoph Hellwig wrote:
> On Tue, Oct 08, 2019 at 11:47:31AM -0400, Arvind Sankar wrote:
> > Ok, I see that almost nothing actually uses dma_get_required_mask. So if
> > something did need >4Gb space, the IOMMU would allocate it anyway
Hi,
Commit 249baa547901 ("dma-mapping: provide a better default
->get_required_mask") causes an error on ehci-pci for me.
Either reverting the commit or disabling iommu=pt seems to fix this.
[9.81] usb 1-1: new high-speed USB device number 2 using ehci-pci
[9.000755] ehci-pci :00:
Hi, arch/x86/purgatory/purgatory.ro has an undefined symbol
memzero_explicit. This has come from commit 906a4bb97f5d ("crypto:
sha256 - Use get/put_unaligned_be32 to get input, memzero_explicit")
according to git bisect.
The patch mentions that it impacts purgatory code, but I don't see any
change
19, 10:55:01 CEST schrieb Hans de Goede:
> > >
> > > Hi Hans,
> > >
> > >> The purgatory code now uses the shared lib/crypto/sha256.c sha256
> > >> implementation. This needs memzero_explicit, implement this.
> > >>
> > >> Report
1 - 100 of 630 matches
Mail list logo
