[PATCH] x86/vdso: drop implicit common-page-size linker flag

[PATCH] x86/vdso: drop implicit common-page-size linker flag

[ndesaulniers]

These are implied by the target architecture and for x86_64 match the
max-page-size. The default for non-NaCl x86_64 is 0x1000 (4096).

In bfd the common page size is defined as 0x1000 (4096) for non-NaCl
x86_64 targets:

bfd/elf64-x86-64.c:
4998:#define ELF_COMMONPAGESIZE             0x1000

For gold, the common page size is defined as 0x1000 (4096) for non-NaCl
x86_64 targets:

gold/x86_64.cc:
1413:  0x1000, // common_pagesize (overridable by -z common-page-size)
1442:  0x1000, // common_pagesize (overridable by -z common-page-size)

(ELF_COMMONPAGESIZE also defaults to ELF_MAXPAGESIZE when not set
explicitly for a target architecture in bfd/elfxx-target.h, but that's
not relevant for x86_64).

Because it's implied by the target architecture, it's of questionable
use to implement in LLD.  This patch resolves one of the issues towards
using LLD to link an x86_64 kernel.

Fixes commit 2aae950b21e4 ("x86_64: Add vDSO for x86-64 with
gettimeofday/clock_gettime/getcpu")

Link: https://bugs.llvm.org/show_bug.cgi?id=38774
Link: https://github.com/ClangBuiltLinux/linux/issues/31
Cc: Fangrui Song <maskray@google.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Andi Kleen <andi@firstfloor.org>
Reported-by: Dmitry Golovin <dima@golovin.in>
Reported-by: Bill Wendling <morbo@google.com>
Suggested-by: Dmitry Golovin <dima@golovin.in>
Suggested-by: Rui Ueyama <ruiu@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
 arch/x86/entry/vdso/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 141d415a8c80..0624bf2266fd 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -47,7 +47,7 @@ targets += $(vdso_img_sodbg) $(vdso_img-y:%=vdso%.so)
 CPPFLAGS_vdso.lds += -P -C
 
 VDSO_LDFLAGS_vdso.lds = -m elf_x86_64 -soname linux-vdso.so.1 --no-undefined \
-			-z max-page-size=4096 -z common-page-size=4096
+			-z max-page-size=4096
 
 $(obj)/vdso64.so.dbg: $(obj)/vdso.lds $(vobjs) FORCE
 	$(call if_changed,vdso)
@@ -98,7 +98,7 @@ CFLAGS_REMOVE_vvar.o = -pg
 
 CPPFLAGS_vdsox32.lds = $(CPPFLAGS_vdso.lds)
 VDSO_LDFLAGS_vdsox32.lds = -m elf32_x86_64 -soname linux-vdso.so.1 \
-			   -z max-page-size=4096 -z common-page-size=4096
+			   -z max-page-size=4096
 
 # x32-rebranded versions
 vobjx32s-y := $(vobjs-y:.o=-x32.o)
-- 
2.20.0.rc1.387.gf8505762e3-goog

Re: [PATCH] x86/vdso: drop implicit common-page-size linker flag

[Andy Lutomirski]

On Thu, Dec 6, 2018 at 11:12 AM <ndesaulniers@google.com> wrote:
>
> These are implied by the target architecture and for x86_64 match the
> max-page-size. The default for non-NaCl x86_64 is 0x1000 (4096).
>
> In bfd the common page size is defined as 0x1000 (4096) for non-NaCl
> x86_64 targets:
>
> bfd/elf64-x86-64.c:
> 4998:#define ELF_COMMONPAGESIZE             0x1000
>
> For gold, the common page size is defined as 0x1000 (4096) for non-NaCl
> x86_64 targets:
>
> gold/x86_64.cc:
> 1413:  0x1000, // common_pagesize (overridable by -z common-page-size)
> 1442:  0x1000, // common_pagesize (overridable by -z common-page-size)
>
> (ELF_COMMONPAGESIZE also defaults to ELF_MAXPAGESIZE when not set
> explicitly for a target architecture in bfd/elfxx-target.h, but that's
> not relevant for x86_64).
>
> Because it's implied by the target architecture, it's of questionable
> use to implement in LLD.  This patch resolves one of the issues towards
> using LLD to link an x86_64 kernel.

Sure.

Acked-by: Andy Lutomirski <luto@kernel.org>

Re: [PATCH] x86/vdso: drop implicit common-page-size linker flag

[Borislav Petkov]

On Thu, Dec 06, 2018 at 11:12:31AM -0800, ndesaulniers@google.com wrote:
> These are implied by the target architecture and for x86_64 match the
> max-page-size. The default for non-NaCl x86_64 is 0x1000 (4096).
> 
> In bfd the common page size is defined as 0x1000 (4096) for non-NaCl

Sodium Chloride?

> x86_64 targets:
> 
> bfd/elf64-x86-64.c:
> 4998:#define ELF_COMMONPAGESIZE             0x1000
> 
> For gold, the common page size is defined as 0x1000 (4096) for non-NaCl
> x86_64 targets:
> 
> gold/x86_64.cc:
> 1413:  0x1000, // common_pagesize (overridable by -z common-page-size)
> 1442:  0x1000, // common_pagesize (overridable by -z common-page-size)
> 
> (ELF_COMMONPAGESIZE also defaults to ELF_MAXPAGESIZE when not set
> explicitly for a target architecture in bfd/elfxx-target.h, but that's
> not relevant for x86_64).
> 
> Because it's implied by the target architecture, it's of questionable
> use to implement in LLD.  This patch resolves one of the issues towards
> using LLD to link an x86_64 kernel.

LLD?

I can only guess what this commit message is about and have to look at
the patch itself and then look at the LD(1) man page and rhyme up what
it is aiming to do.

How about rewriting it for mere mortals?

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH] x86/vdso: drop implicit common-page-size linker flag

[Nick Desaulniers]

On Fri, Dec 7, 2018 at 2:18 AM Borislav Petkov <bp@alien8.de> wrote:
>
> On Thu, Dec 06, 2018 at 11:12:31AM -0800, ndesaulniers@google.com wrote:
> > These are implied by the target architecture and for x86_64 match the
> > max-page-size. The default for non-NaCl x86_64 is 0x1000 (4096).
> >
> > In bfd the common page size is defined as 0x1000 (4096) for non-NaCl
>
> Sodium Chloride?

Google's Native Client, a technology for running native code in a web
browser.  It's since been superseded by Portable Native Client (pNaCl)
and to an extent Web Assembly.  It seems that BFD still contains code
for NaCl.

>
> > x86_64 targets:
> >
> > bfd/elf64-x86-64.c:
> > 4998:#define ELF_COMMONPAGESIZE             0x1000
> >
> > For gold, the common page size is defined as 0x1000 (4096) for non-NaCl
> > x86_64 targets:
> >
> > gold/x86_64.cc:
> > 1413:  0x1000, // common_pagesize (overridable by -z common-page-size)
> > 1442:  0x1000, // common_pagesize (overridable by -z common-page-size)
> >
> > (ELF_COMMONPAGESIZE also defaults to ELF_MAXPAGESIZE when not set
> > explicitly for a target architecture in bfd/elfxx-target.h, but that's
> > not relevant for x86_64).
> >
> > Because it's implied by the target architecture, it's of questionable
> > use to implement in LLD.  This patch resolves one of the issues towards
> > using LLD to link an x86_64 kernel.
>
> LLD?

LLD is LLVM's linker.
https://lld.llvm.org/

>
> I can only guess what this commit message is about and have to look at
> the patch itself and then look at the LD(1) man page and rhyme up what
> it is aiming to do.
>
> How about rewriting it for mere mortals?

How does this sound:
TL;DR
-z common-page-size's default value is based on the target
architecture.  arch/x86/entry/vdso/Makefile sets it to the
architecture default, which is implicit and redundant.  Drop it.

-- 
Thanks,
~Nick Desaulniers

Re: [PATCH] x86/vdso: drop implicit common-page-size linker flag

[Borislav Petkov]

On Fri, Dec 07, 2018 at 09:45:42AM -0800, Nick Desaulniers wrote:
> Google's Native Client, a technology for running native code in a web
> browser.  It's since been superseded by Portable Native Client (pNaCl)
> and to an extent Web Assembly.  It seems that BFD still contains code
> for NaCl.

Yeah, found the wikipedia page. :)

> How does this sound:
> TL;DR
> -z common-page-size's default value is based on the target
> architecture.  arch/x86/entry/vdso/Makefile sets it to the
> architecture default, which is implicit and redundant.  Drop it.

Sure. Although the longer explanation gives more insight into the whole
deal but that's fine too - the longer explanation is on the ML and we
have the Link: tags.

So no need to resend - I'll simply take the three-liner above.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH] x86/vdso: drop implicit common-page-size linker flag

[Nick Desaulniers]

On Fri, Dec 7, 2018 at 9:53 AM Borislav Petkov <bp@alien8.de> wrote:
>
> On Fri, Dec 07, 2018 at 09:45:42AM -0800, Nick Desaulniers wrote:
> > Google's Native Client, a technology for running native code in a web
> > browser.  It's since been superseded by Portable Native Client (pNaCl)
> > and to an extent Web Assembly.  It seems that BFD still contains code
> > for NaCl.
>
> Yeah, found the wikipedia page. :)
>
> > How does this sound:
> > TL;DR
> > -z common-page-size's default value is based on the target
> > architecture.  arch/x86/entry/vdso/Makefile sets it to the
> > architecture default, which is implicit and redundant.  Drop it.
>
> Sure. Although the longer explanation gives more insight into the whole
> deal but that's fine too - the longer explanation is on the ML and we
> have the Link: tags.
>
> So no need to resend - I'll simply take the three-liner above.

Thanks, it's being set to the default value again for x86 usermode
linux, arm, and for sparc.  I'll send additional clean ups for those
three.
-- 
Thanks,
~Nick Desaulniers

[tip:x86/urgent] x86/vdso: Drop implicit common-page-size linker flag

[tip-bot for Nick Desaulniers]

Commit-ID:  ac3e233d29f7f77f28243af0132057d378d3ea58
Gitweb:     https://git.kernel.org/tip/ac3e233d29f7f77f28243af0132057d378d3ea58
Author:     Nick Desaulniers <ndesaulniers@google.com>
AuthorDate: Thu, 6 Dec 2018 11:12:31 -0800
Committer:  Borislav Petkov <bp@suse.de>
CommitDate: Fri, 7 Dec 2018 18:57:38 +0100

x86/vdso: Drop implicit common-page-size linker flag

GNU linker's -z common-page-size's default value is based on the target
architecture. arch/x86/entry/vdso/Makefile sets it to the architecture
default, which is implicit and redundant. Drop it.

Fixes: 2aae950b21e4 ("x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu")
Reported-by: Dmitry Golovin <dima@golovin.in>
Reported-by: Bill Wendling <morbo@google.com>
Suggested-by: Dmitry Golovin <dima@golovin.in>
Suggested-by: Rui Ueyama <ruiu@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Andy Lutomirski <luto@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Fangrui Song <maskray@google.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20181206191231.192355-1-ndesaulniers@google.com
Link: https://bugs.llvm.org/show_bug.cgi?id=38774
Link: https://github.com/ClangBuiltLinux/linux/issues/31
---
 arch/x86/entry/vdso/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 141d415a8c80..0624bf2266fd 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -47,7 +47,7 @@ targets += $(vdso_img_sodbg) $(vdso_img-y:%=vdso%.so)
 CPPFLAGS_vdso.lds += -P -C
 
 VDSO_LDFLAGS_vdso.lds = -m elf_x86_64 -soname linux-vdso.so.1 --no-undefined \
-			-z max-page-size=4096 -z common-page-size=4096
+			-z max-page-size=4096
 
 $(obj)/vdso64.so.dbg: $(obj)/vdso.lds $(vobjs) FORCE
 	$(call if_changed,vdso)
@@ -98,7 +98,7 @@ CFLAGS_REMOVE_vvar.o = -pg
 
 CPPFLAGS_vdsox32.lds = $(CPPFLAGS_vdso.lds)
 VDSO_LDFLAGS_vdsox32.lds = -m elf32_x86_64 -soname linux-vdso.so.1 \
-			   -z max-page-size=4096 -z common-page-size=4096
+			   -z max-page-size=4096
 
 # x32-rebranded versions
 vobjx32s-y := $(vobjs-y:.o=-x32.o)

[tip:x86/build] x86/um/vdso: Drop implicit common-page-size linker flag

[tip-bot for ndesaulniers@google.com]

Commit-ID:  f4313ba52f9caccfda6a55f991c84aba6726b88f
Gitweb:     https://git.kernel.org/tip/f4313ba52f9caccfda6a55f991c84aba6726b88f
Author:     ndesaulniers@google.com <ndesaulniers@google.com>
AuthorDate: Mon, 10 Dec 2018 14:27:16 -0800
Committer:  Borislav Petkov <bp@suse.de>
CommitDate: Tue, 11 Dec 2018 13:58:57 +0100

x86/um/vdso: Drop implicit common-page-size linker flag

GNU linker's -z common-page-size's default value is based on the target
architecture. arch/x86/um/vdso/Makefile sets it to the architecture
default, which is implicit and redundant. Drop it so that one more LLVM
build issue gets addressed.

Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Richard Weinberger <richard@nod.at>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-um@lists.infradead.org
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20181206191231.192355-1-ndesaulniers@google.com
---
 arch/x86/um/vdso/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/um/vdso/Makefile b/arch/x86/um/vdso/Makefile
index 822ccdba93ad..bf94060fc06f 100644
--- a/arch/x86/um/vdso/Makefile
+++ b/arch/x86/um/vdso/Makefile
@@ -26,7 +26,7 @@ targets += vdso.so vdso.so.dbg vdso.lds $(vobjs-y)
 CPPFLAGS_vdso.lds += -P -C
 
 VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
-       -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096
+       -Wl,-z,max-page-size=4096
 
 $(obj)/vdso.o: $(src)/vdso.S $(obj)/vdso.so
 

[tip:x86/build] x86/um/vdso: Drop implicit common-page-size linker flag

[tip-bot for Nick Desaulniers]

Commit-ID:  e4f752dda0de351efd198f438b68e743029da68a
Gitweb:     https://git.kernel.org/tip/e4f752dda0de351efd198f438b68e743029da68a
Author:     Nick Desaulniers <ndesaulniers@google.com>
AuthorDate: Mon, 10 Dec 2018 14:27:16 -0800
Committer:  Borislav Petkov <bp@suse.de>
CommitDate: Tue, 11 Dec 2018 14:19:42 +0100

x86/um/vdso: Drop implicit common-page-size linker flag

GNU linker's -z common-page-size's default value is based on the target
architecture. arch/x86/um/vdso/Makefile sets it to the architecture
default, which is implicit and redundant. Drop it so that one more LLVM
build issue gets addressed.

Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Richard Weinberger <richard@nod.at>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-um@lists.infradead.org
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20181206191231.192355-1-ndesaulniers@google.com
---
 arch/x86/um/vdso/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/um/vdso/Makefile b/arch/x86/um/vdso/Makefile
index 822ccdba93ad..bf94060fc06f 100644
--- a/arch/x86/um/vdso/Makefile
+++ b/arch/x86/um/vdso/Makefile
@@ -26,7 +26,7 @@ targets += vdso.so vdso.so.dbg vdso.lds $(vobjs-y)
 CPPFLAGS_vdso.lds += -P -C
 
 VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
-       -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096
+       -Wl,-z,max-page-size=4096
 
 $(obj)/vdso.o: $(src)/vdso.S $(obj)/vdso.so
 

Re: [tip:x86/build] x86/um/vdso: Drop implicit common-page-size linker flag

[Nick Desaulniers]

On Tue, Dec 11, 2018 at 5:12 AM tip-bot for ndesaulniers@google.com
<tipbot@zytor.com> wrote:
>
> Commit-ID:  f4313ba52f9caccfda6a55f991c84aba6726b88f
> Gitweb:     https://git.kernel.org/tip/f4313ba52f9caccfda6a55f991c84aba6726b88f
> Author:     ndesaulniers@google.com <ndesaulniers@google.com>
> AuthorDate: Mon, 10 Dec 2018 14:27:16 -0800
> Committer:  Borislav Petkov <bp@suse.de>
> CommitDate: Tue, 11 Dec 2018 13:58:57 +0100
>
> x86/um/vdso: Drop implicit common-page-size linker flag
>
> GNU linker's -z common-page-size's default value is based on the target
> architecture. arch/x86/um/vdso/Makefile sets it to the architecture
> default, which is implicit and redundant. Drop it so that one more LLVM
> build issue gets addressed.
>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> Signed-off-by: Borislav Petkov <bp@suse.de>
> Acked-by: Richard Weinberger <richard@nod.at>

I missed Richard's ACK.  Did it occur off list?  I just want to
confirm there's nothing wrong with my email client.  Thank you for
taking the patch either way.

> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Jeff Dike <jdike@addtoit.com>
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: linux-um@lists.infradead.org
> Cc: x86-ml <x86@kernel.org>
> Link: https://lkml.kernel.org/r/20181206191231.192355-1-ndesaulniers@google.com
> ---
>  arch/x86/um/vdso/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/um/vdso/Makefile b/arch/x86/um/vdso/Makefile
> index 822ccdba93ad..bf94060fc06f 100644
> --- a/arch/x86/um/vdso/Makefile
> +++ b/arch/x86/um/vdso/Makefile
> @@ -26,7 +26,7 @@ targets += vdso.so vdso.so.dbg vdso.lds $(vobjs-y)
>  CPPFLAGS_vdso.lds += -P -C
>
>  VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
> -       -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096
> +       -Wl,-z,max-page-size=4096
>
>  $(obj)/vdso.o: $(src)/vdso.S $(obj)/vdso.so
>


-- 
Thanks,
~Nick Desaulniers

Re: [tip:x86/build] x86/um/vdso: Drop implicit common-page-size linker flag

[Richard Weinberger]

Am Dienstag, 11. Dezember 2018, 18:39:45 CET schrieb Nick Desaulniers:
> On Tue, Dec 11, 2018 at 5:12 AM tip-bot for ndesaulniers@google.com
> <tipbot@zytor.com> wrote:
> >
> > Commit-ID:  f4313ba52f9caccfda6a55f991c84aba6726b88f
> > Gitweb:     https://git.kernel.org/tip/f4313ba52f9caccfda6a55f991c84aba6726b88f
> > Author:     ndesaulniers@google.com <ndesaulniers@google.com>
> > AuthorDate: Mon, 10 Dec 2018 14:27:16 -0800
> > Committer:  Borislav Petkov <bp@suse.de>
> > CommitDate: Tue, 11 Dec 2018 13:58:57 +0100
> >
> > x86/um/vdso: Drop implicit common-page-size linker flag
> >
> > GNU linker's -z common-page-size's default value is based on the target
> > architecture. arch/x86/um/vdso/Makefile sets it to the architecture
> > default, which is implicit and redundant. Drop it so that one more LLVM
> > build issue gets addressed.
> >
> > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> > Signed-off-by: Borislav Petkov <bp@suse.de>
> > Acked-by: Richard Weinberger <richard@nod.at>
> 
> I missed Richard's ACK.  Did it occur off list?  I just want to
> confirm there's nothing wrong with my email client.  Thank you for
> taking the patch either way.

https://lore.kernel.org/lkml/1633144.08IGjMOzBB@blindfold/

Maybe google started to hate my mailserver (again).

Thanks,
//richard

Re: [tip:x86/build] x86/um/vdso: Drop implicit common-page-size linker flag

[Borislav Petkov]

On Tue, Dec 11, 2018 at 06:43:39PM +0100, Richard Weinberger wrote:
> https://lore.kernel.org/lkml/1633144.08IGjMOzBB@blindfold/
> 
> Maybe google started to hate my mailserver (again).

You probably need DKIM fun. It is most likely marked as spam in his
mbox.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [tip:x86/build] x86/um/vdso: Drop implicit common-page-size linker flag

[Nick Desaulniers]

On Tue, Dec 11, 2018 at 9:47 AM Borislav Petkov <bp@alien8.de> wrote:
>
> On Tue, Dec 11, 2018 at 06:43:39PM +0100, Richard Weinberger wrote:
> > https://lore.kernel.org/lkml/1633144.08IGjMOzBB@blindfold/
> >
> > Maybe google started to hate my mailserver (again).
>
> You probably need DKIM fun. It is most likely marked as spam in his
> mbox.

Indeed it was.  I'm forced to use Gmail's clients for this work
account and all that implies (no plain text responses when mobile).
Man do I miss Thunderbird properly threading responses clearly by use
of indentation.  Gmail literally did not show any responses even in
search for my patch (even from someone on the to/cc list!).  Maybe I
can file a bug about this internally...
-- 
Thanks,
~Nick Desaulniers

Re: [tip:x86/build] x86/um/vdso: Drop implicit common-page-size linker flag

[Borislav Petkov]

On Tue, Dec 11, 2018 at 09:53:49AM -0800, Nick Desaulniers wrote:
> Indeed it was.  I'm forced to use Gmail's clients for this work
> account and all that implies (no plain text responses when mobile).

Can't you access it over imap?

> Maybe I can file a bug about this internally...

FWIW, people have looked for ways to report such issues in the past...

But in this particular case, DKIM is pretty good spam protection
mechanism so enabling it is a good idea.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Re: [tip:x86/build] x86/um/vdso: Drop implicit common-page-size linker flag

[Nick Desaulniers]

On Tue, Dec 11, 2018 at 10:06 AM Borislav Petkov <bp@suse.de> wrote:
>
> On Tue, Dec 11, 2018 at 09:53:49AM -0800, Nick Desaulniers wrote:
> > Indeed it was.  I'm forced to use Gmail's clients for this work
> > account and all that implies (no plain text responses when mobile).
>
> Can't you access it over imap?

Personal gmail account, yes. Corporate gmail, no, IIUC.  There was a
pretty big internal thread where all of our kernel contributors got
cut off one day and were scrambling to figure out how to send/review
patches as their workflows were interrupted.  Something is still not
configured right when I send patches (maintainers have merged patches
with my email address but no name, I assume from working with mbox
files).

We have some internal tool that's smtp based but does the two factor
authentication.

>
> > Maybe I can file a bug about this internally...
>
> FWIW, people have looked for ways to report such issues in the past...
>
> But in this particular case, DKIM is pretty good spam protection
> mechanism so enabling it is a good idea.

Internal Gmail developers were able to help me verify that SPF was
setup correctly, but indeed there's no DKIM.  This article has more
info: https://support.google.com/mail/answer/81126?hl=en.  Richard, I
don't know if that's a lot of work on your end, but other folks using
gmail might have the same issue repeatedly with receiving emails from
your domain otherwise.

-- 
Thanks,
~Nick Desaulniers

Re: [tip:x86/build] x86/um/vdso: Drop implicit common-page-size linker flag

[Richard Weinberger]

Am Dienstag, 11. Dezember 2018, 20:08:30 CET schrieb Nick Desaulniers:
> > But in this particular case, DKIM is pretty good spam protection
> > mechanism so enabling it is a good idea.
> 
> Internal Gmail developers were able to help me verify that SPF was
> setup correctly, but indeed there's no DKIM.  This article has more
> info: https://support.google.com/mail/answer/81126?hl=en.  Richard, I
> don't know if that's a lot of work on your end, but other folks using
> gmail might have the same issue repeatedly with receiving emails from
> your domain otherwise.

Running your own mailserver is already a PITA, so adding a little more
pain does not count in much more.
Thanks for talking to Gmail guys, I'll look into adding DKIM.

Thanks,
//richard

Re: [tip:x86/build] x86/um/vdso: Drop implicit common-page-size linker flag

[Borislav Petkov]

On Tue, Dec 11, 2018 at 11:08:30AM -0800, Nick Desaulniers wrote:
> Personal gmail account, yes. Corporate gmail, no, IIUC.  There was a
> pretty big internal thread where all of our kernel contributors got
> cut off one day and were scrambling to figure out how to send/review
> patches as their workflows were interrupted.

Gotta love all those stories of kernel people and corporate mail
systems... And every company has its own strange idiosyncrasies...

> Something is still not configured right when I send patches
> (maintainers have merged patches with my email address but no name, I
> assume from working with mbox files).

Yeah, had to fix that up today too. For some reason your git setup

 X-Mailer: git-send-email 2.20.0.rc2.403.gdbc3b29805-goog

doesn't do names in From:

https://lkml.kernel.org/r/20181210222718.19926-1-ndesaulniers@google.com

> We have some internal tool that's smtp based but does the two factor
> authentication.

So some people send from !corporate mail servers but put their company's
name in brackets to keep attribution:

Signed-off-by: <First name> <Last name> (<Company>) <email@address.com>

For example. Dunno if that's something that would make sense for your
case though.

> Internal Gmail developers were able to help me verify that SPF was
> setup correctly, but indeed there's no DKIM.  This article has more
> info: https://support.google.com/mail/answer/81126?hl=en.

I know that one from my very recent past. :)

> Richard, I don't know if that's a lot of work on your end, but other
> folks using gmail might have the same issue repeatedly with receiving
> emails from your domain otherwise.

We had to do that too for our domain.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.