Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Michal Marek]

Dne 29.11.2016 v 18:10 Linus Torvalds napsal(a):
> How about this stupid patch? It weakens modversions, but that may be
> ok for Debian, and a better alternative than just saying "we don't
> support it at all".
[...]
> - pr_warn("%s: no symbol version for %s\n", mod->name, symname);
> - return 0;
> + /* Broken toolchain. Warn once, then let it go.. */
> + pr_warn_once("%s: no symbol version for %s\n", mod->name, symname);
> + return 1;

Fine with me, if it goes with the revert of the "depends on BROKEN."

Michal

Bug#804079: [Xen-devel] Kernel panic on Xen virtualisation in Debian

[Ingo Jürgensmann]

Am 29.11.2016 um 10:08 schrieb Wei Liu :
>> http://paste.debian.net/895464/
> Entry not found -- maybe it expired... Sorry.

Here it is: 

Nov 14 09:19:52 31.172.31.251 [39677.027813] BUG: unable to handle kernel 
Nov 14 09:19:52 31.172.31.251  at 880002b4c06e
Nov 14 09:19:52 31.172.31.251 [39677.027868] IP:
Nov 14 09:19:52 31.172.31.251  [] 
ndisc_send_redirect+0x44c/0x4d0
Nov 14 09:19:52 31.172.31.251 [39677.027902] PGD 1a07067 
Nov 14 09:19:52 31.172.31.251  
Nov 14 09:19:52 31.172.31.251 [39677.027934] Oops:  [#1] 
Nov 14 09:19:52 31.172.31.251  
Nov 14 09:19:52 31.172.31.251 [39677.027956] Modules linked in:
Nov 14 09:19:52 31.172.31.251  authenc(E)
Nov 14 09:19:52 31.172.31.251  echainiv(E)
Nov 14 09:19:52 31.172.31.251  xfrm6_mode_tunnel(E)
Nov 14 09:19:52 31.172.31.251  xfrm4_mode_tunnel(E)
Nov 14 09:19:52 31.172.31.251  xt_physdev(E)
Nov 14 09:19:52 31.172.31.251  br_netfilter(E)
Nov 14 09:19:52 31.172.31.251  xen_netback(E)
Nov 14 09:19:52 31.172.31.251  tun(E)
Nov 14 09:19:52 31.172.31.251  xen_blkback(E)
Nov 14 09:19:52 31.172.31.251  xt_multiport(E)
Nov 14 09:19:52 31.172.31.251  twofish_generic(E)
Nov 14 09:19:52 31.172.31.251  twofish_avx_x86_64(E)
Nov 14 09:19:52 31.172.31.251  twofish_x86_64_3way(E)
Nov 14 09:19:52 31.172.31.251  twofish_x86_64(E)
Nov 14 09:19:52 31.172.31.251  twofish_common(E)
Nov 14 09:19:52 31.172.31.251  serpent_avx_x86_64(E)
Nov 14 09:19:52 31.172.31.251  serpent_sse2_x86_64(E)
Nov 14 09:19:52 31.172.31.251  serpent_generic(E)
Nov 14 09:19:52 31.172.31.251  blowfish_generic(E)
Nov 14 09:19:52 31.172.31.251  blowfish_x86_64(E)
Nov 14 09:19:52 31.172.31.251  blowfish_common(E)
Nov 14 09:19:52 31.172.31.251  cast5_avx_x86_64(E)
Nov 14 09:19:52 31.172.31.251  cast5_generic(E)
Nov 14 09:19:52 31.172.31.251  cast_common(E)
Nov 14 09:19:52 31.172.31.251  ctr(E)
Nov 14 09:19:52 31.172.31.251  des_generic(E)
Nov 14 09:19:52 31.172.31.251  cbc(E)
Nov 14 09:19:52 31.172.31.251  algif_skcipher(E)
Nov 14 09:19:52 31.172.31.251  camellia_generic(E)
Nov 14 09:19:52 31.172.31.251  camellia_aesni_avx_x86_64(E)
Nov 14 09:19:52 31.172.31.251  camellia_x86_64(E)
Nov 14 09:19:52 31.172.31.251  xts(E)
Nov 14 09:19:52 31.172.31.251  xcbc(E)
Nov 14 09:19:52 31.172.31.251  sha512_ssse3(E)
Nov 14 09:19:52 31.172.31.251  sha512_generic(E)
Nov 14 09:19:52 31.172.31.251  md4(E)
Nov 14 09:19:52 31.172.31.251  algif_hash(E)
Nov 14 09:19:52 31.172.31.251  af_alg(E)
Nov 14 09:19:52 31.172.31.251  xfrm_user(E)
Nov 14 09:19:52 31.172.31.251  xfrm4_tunnel(E)
Nov 14 09:19:52 31.172.31.251  tunnel4(E)
Nov 14 09:19:52 31.172.31.251  ipcomp(E)
Nov 14 09:19:52 31.172.31.251  xfrm_ipcomp(E)
Nov 14 09:19:52 31.172.31.251  esp4(E)
Nov 14 09:19:52 31.172.31.251  xen_gntdev(E)
Nov 14 09:19:52 31.172.31.251  xen_evtchn(E)
Nov 14 09:19:52 31.172.31.251  ah4(E)
Nov 14 09:19:52 31.172.31.251  xenfs(E)
Nov 14 09:19:52 31.172.31.251  af_key(E)
Nov 14 09:19:52 31.172.31.251  xfrm_algo(E)
Nov 14 09:19:52 31.172.31.251  xen_privcmd(E)
Nov 14 09:19:52 31.172.31.251  ipmi_poweroff(E)
Nov 14 09:19:52 31.172.31.251  video(E)
Nov 14 09:19:52 31.172.31.251  thermal(E)
Nov 14 09:19:52 31.172.31.251  fan(E)
Nov 14 09:19:52 31.172.31.251  ac(E)
Nov 14 09:19:52 31.172.31.251  battery(E)
Nov 14 09:19:52 31.172.31.251  ip6t_REJECT(E)
Nov 14 09:19:52 31.172.31.251  nf_reject_ipv6(E)
Nov 14 09:19:52 31.172.31.251  ip6table_filter(E)
Nov 14 09:19:52 31.172.31.251  ip6_tables(E)
Nov 14 09:19:52 31.172.31.251  ipt_REJECT(E)
Nov 14 09:19:52 31.172.31.251  nf_reject_ipv4(E)
Nov 14 09:19:52 31.172.31.251  xt_tcpudp(E)
Nov 14 09:19:52 31.172.31.251  iptable_filter(E)
Nov 14 09:19:52 31.172.31.251  ip_tables(E)
Nov 14 09:19:52 31.172.31.251  x_tables(E)
Nov 14 09:19:52 31.172.31.251  bridge(E)
Nov 14 09:19:52 31.172.31.251  stp(E)
Nov 14 09:19:52 31.172.31.251  llc(E)
Nov 14 09:19:52 31.172.31.251  ext4(E)
Nov 14 09:19:52 31.172.31.251  ecb(E)
Nov 14 09:19:52 31.172.31.251  crc16(E)
Nov 14 09:19:52 31.172.31.251  jbd2(E)
Nov 14 09:19:52 31.172.31.251  crc32c_generic(E)
Nov 14 09:19:52 31.172.31.251  mbcache(E)
Nov 14 09:19:52 31.172.31.251  fuse(E)
Nov 14 09:19:52 31.172.31.251  ipmi_devintf(E)
Nov 14 09:19:52 31.172.31.251  ipmi_watchdog(E)
Nov 14 09:19:52 31.172.31.251  w83627ehf(E)
Nov 14 09:19:52 31.172.31.251  hwmon_vid(E)
Nov 14 09:19:52 31.172.31.251  nf_conntrack_ipv4(E)
Nov 14 09:19:52 31.172.31.251  nf_defrag_ipv4(E)
Nov 14 09:19:52 31.172.31.251  nf_conntrack(E)
Nov 14 09:19:52 31.172.31.251  loop(E)
Nov 14 09:19:52 31.172.31.251  x86_pkg_temp_thermal(E)
Nov 14 09:19:52 31.172.31.251  intel_powerclamp(E)
Nov 14 09:19:52 31.172.31.251  coretemp(E)
Nov 14 09:19:52 31.172.31.251  crct10dif_pclmul(E)
Nov 14 09:19:52 31.172.31.251  crc32_pclmul(E)
Nov 14 09:19:52 31.172.31.251  ghash_clmulni_intel(E)
Nov 14 09:19:52 31.172.31.251  hmac(E)
Nov 14 09:19:52 31.172.31.251  drbg(E)
Nov 14 09:19:52 31.172.31.251  ansi_cprng(E)
Nov 14 09:19:52 31.172.31.251  aesni_intel(E)
Nov 14 09:19:52 31.172.31.251  

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Linus Torvalds]

On Tue, Nov 29, 2016 at 11:57 AM, Ben Hutchings  wrote:
>
> If the modversion is missing then the fallback should be to a full
> vermagic match, i.e. including the release string.  Something like
> this (untested):

This really seems way too complicated for this situation.

And it's wrong too. The whole point of modversions was that you didn't
want to do the full version check.

We already know there were *some* crc's (we checked that at the top of
check_version(), but we've also checked it in "same_magic()" - it's
what makes us ignore the exact version number), but this particular
symbol doesn't have a crc. Just let it through, because we have bugs
in binutils.

So your extra complexity logic seems actively wrong. It makes
MODVERSIONS not work at all, rather than limp along. You're better off
just not having MODVERSIONS.

   Linus

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Ben Hutchings]

On Tue, 2016-11-29 at 08:17 -0800, Linus Torvalds wrote:
> > On Tue, Nov 29, 2016 at 8:03 AM, Michal Marek  wrote:
> > 
> > The original and easily observable bug is that were are not generating
> > symbol checksums for the asm-exported symbols, so they default to 0.
> > This can be seen e.g. in the Module.symvers file. This seemed like a
> > minor issue, because with the functions written in asm, the type
> > checking is rather weak (this has been the case even before Al's
> > patches). However, there is another bug that with _some_ toolchains /
> > architectures, the checksums do not default to 0, but they are simply
> > missing in the ___kcrctab* sections and the module loader complains. We
> > can of course research into the details of the second bug, but we
> > already know that we are not generating the checksums while we should be.
> 
> So let's just say that "toolchain is buggy" and make a missing kcrctab
> entry mean zero (or mean "matches anything"). And just shut up the
> warning.
> 
> I do *not* want to add random bandaids for something like a broken
> toolchain issue when I'd really rather just delete the feature.

If the modversion is missing then the fallback should be to a full
vermagic match, i.e. including the release string.  Something like
this (untested):

diff --git a/init/Kconfig b/init/Kconfig
index c4fbc1e55c25..34407f15e6d3 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1945,7 +1945,6 @@ config MODULE_FORCE_UNLOAD
 
 config MODVERSIONS
bool "Module versioning support"
-   depends on BROKEN
help
  Usually, you have to use modules compiled with your kernel.
  Saying Y here makes it sometimes possible to use modules
diff --git a/kernel/module.c b/kernel/module.c
index f57dd63186e6..78d61ae50bc5 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -296,6 +296,12 @@ int unregister_module_notifier(struct notifier_block *nb)
 }
 EXPORT_SYMBOL(unregister_module_notifier);
 
+enum {
+   MAGIC_NO_MATCH,
+   MAGIC_MATCH_NEED_CRC,
+   MAGIC_MATCH_EXACT
+};
+
 struct load_info {
Elf_Ehdr *hdr;
unsigned long len;
@@ -305,6 +311,7 @@ struct load_info {
struct _ddebug *debug;
unsigned int num_debug;
bool sig_ok;
+   int magic_match;
 #ifdef CONFIG_KALLSYMS
unsigned long mod_kallsyms_init_off;
 #endif
@@ -1268,13 +1275,14 @@ static unsigned long maybe_relocated(unsigned long crc,
return crc;
 }
 
-static int check_version(Elf_Shdr *sechdrs,
-unsigned int versindex,
+static int check_version(const struct load_info *info,
 const char *symname,
 struct module *mod,
 const unsigned long *crc,
 const struct module *crc_owner)
 {
+   Elf_Shdr *sechdrs = info->sechdrs;
+   unsigned int versindex = info->index.vers;
unsigned int i, num_versions;
struct modversion_info *versions;
 
@@ -1294,6 +1302,10 @@ static int check_version(Elf_Shdr *sechdrs,
if (strcmp(versions[i].name, symname) != 0)
continue;
 
+   /* Ignore dummy zero CRC */
+   if (versions[i].crc == 0)
+   break;
+
if (versions[i].crc == maybe_relocated(*crc, crc_owner))
return 1;
pr_debug("Found checksum %lX vs module %lX\n",
@@ -1301,6 +1313,9 @@ static int check_version(Elf_Shdr *sechdrs,
goto bad_version;
}
 
+   if (info->magic_match == MAGIC_MATCH_EXACT)
+   return 1;
+
pr_warn("%s: no symbol version for %s\n", mod->name, symname);
return 0;
 
@@ -1310,8 +1325,7 @@ static int check_version(Elf_Shdr *sechdrs,
return 0;
 }
 
-static inline int check_modstruct_version(Elf_Shdr *sechdrs,
- unsigned int versindex,
+static inline int check_modstruct_version(const struct load_info *info,
  struct module *mod)
 {
const unsigned long *crc;
@@ -1327,24 +1341,24 @@ static inline int check_modstruct_version(Elf_Shdr 
*sechdrs,
BUG();
}
preempt_enable();
-   return check_version(sechdrs, versindex,
+   return check_version(info,
 VMLINUX_SYMBOL_STR(module_layout), mod, crc,
 NULL);
 }
 
-/* First part is kernel version, which we ignore if module has crcs. */
-static inline int same_magic(const char *amagic, const char *bmagic,
-bool has_crcs)
+/* First part is kernel version, which can be ignored if module has crcs. */
+static inline int compare_magic(const char *amagic, const char *bmagic)
 {
-   if (has_crcs) {
-   amagic += strcspn(amagic, " ");
-   bmagic += strcspn(bmagic, " ");
-   }
-   return strcmp(amagic, bmagic) == 0;
+   if 

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Linus Torvalds]

On Tue, Nov 29, 2016 at 9:10 AM, Linus Torvalds
 wrote:
>
> So quite frankly, I don't want to make our kernel sources worse due to
> broken shit tools getting something wrong that we shouldn't even care
> about.

And yes, I'm on binutils 2.26 (with no issues), so it could be that
it's 2.27 that triggers this.

We could make the pr_warn_once() mention "broken binutils?" so that
people know why the warning happens.

   Linus

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Linus Torvalds]

On Tue, Nov 29, 2016 at 9:05 AM, Adam Borowski  wrote:
>
> Thus, if it's indeed binutils, you'll see the breakage as soon as Fedora
> recovers from the freeze.

So quite frankly, I don't want to make our kernel sources worse due to
broken shit tools getting something wrong that we shouldn't even care
about.

How about this stupid patch? It weakens modversions, but that may be
ok for Debian, and a better alternative than just saying "we don't
support it at all".

Linus
 kernel/module.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index f57dd63186e6..0e54d5bf0097 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1301,8 +1301,9 @@ static int check_version(Elf_Shdr *sechdrs,
goto bad_version;
}
 
-   pr_warn("%s: no symbol version for %s\n", mod->name, symname);
-   return 0;
+   /* Broken toolchain. Warn once, then let it go.. */
+   pr_warn_once("%s: no symbol version for %s\n", mod->name, symname);
+   return 1;
 
 bad_version:
pr_warn("%s: disagrees about version of symbol %s\n",

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Adam Borowski]

On Tue, Nov 29, 2016 at 07:27:12AM -0800, Linus Torvalds wrote:
> On Nov 29, 2016 5:51 AM, "Adam Borowski"  wrote:
> > >
> > >  (a) tested
> >
> > By many people.
> 
> No.
> 
> I've tested the build *without* this, and it works fine.

Michal mentioned "why", let's try "where".

I have no idea what setup is required to trigger the problem, but here's a
simple sufficient one:

Current Debian unstable, amd64.
git reset --hard v4.9-rc7
git revert cd3caefb
make defconfig
CONFIG_MODVERSIONS=y
(in my case) CONFIG_BTRFS_FS=y (so I can boot)
enable a module for testing, I used CONFIG_EXT4_FS=m
make bindeb-pkg
dpkg -i linux-image_X.deb

modprobe ext4
[   63.779490] jbd2: no symbol version for memcpy
[   63.779492] jbd2: Unknown symbol memcpy (err -22)
[   63.779550] jbd2: no symbol version for phys_base
[   63.779551] jbd2: Unknown symbol phys_base (err -22)
[   63.779561] jbd2: no symbol version for memset
[   63.779562] jbd2: Unknown symbol memset (err -22)

Not sure which piece of toolchain matters here, someone said binutils.
In that case, Fedora ships 2.26.1-1.fc25, they were frozen so couldn't
update.  Debian is at 2.27.51.20161127-1, Gentoo at 2.27, same for Arch,
OpenSUSE; Ubuntu at 2.27.51.20161124-1.

Thus, if it's indeed binutils, you'll see the breakage as soon as Fedora
recovers from the freeze.


Meow!
-- 
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings.  What should the
historians do?

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Linus Torvalds]

On Tue, Nov 29, 2016 at 8:03 AM, Michal Marek  wrote:
>
> The original and easily observable bug is that were are not generating
> symbol checksums for the asm-exported symbols, so they default to 0.
> This can be seen e.g. in the Module.symvers file. This seemed like a
> minor issue, because with the functions written in asm, the type
> checking is rather weak (this has been the case even before Al's
> patches). However, there is another bug that with _some_ toolchains /
> architectures, the checksums do not default to 0, but they are simply
> missing in the ___kcrctab* sections and the module loader complains. We
> can of course research into the details of the second bug, but we
> already know that we are not generating the checksums while we should be.

So let's just say that "toolchain is buggy" and make a missing kcrctab
entry mean zero (or mean "matches anything"). And just shut up the
warning.

I do *not* want to add random bandaids for something like a broken
toolchain issue when I'd really rather just delete the feature.

 Linus

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Michal Marek]

Dne 29.11.2016 v 16:27 Linus Torvalds napsal(a):
> On Nov 29, 2016 5:51 AM, "Adam Borowski"  > wrote:
>>
> 
>> >
>> >  (a) tested
>>
>> By many people.
> 
> No.
> 
> I've tested the build *without* this, and it works fine.
> 
>> >  (b) explains it
>>
>> The actual logic is in 4efca4ed0.  It wants C prototypes defined in
>> asm/asm-prototypes.h that lists symbols defined in assembly -- genksyms
>> knows only how to read C code.
> 
> See above. I'm not taking more random patches that "fix" this when it's
> not broken for me. Not without very explicit explanations of why that
> patch is still needed for others.

The original and easily observable bug is that were are not generating
symbol checksums for the asm-exported symbols, so they default to 0.
This can be seen e.g. in the Module.symvers file. This seemed like a
minor issue, because with the functions written in asm, the type
checking is rather weak (this has been the case even before Al's
patches). However, there is another bug that with _some_ toolchains /
architectures, the checksums do not default to 0, but they are simply
missing in the ___kcrctab* sections and the module loader complains. We
can of course research into the details of the second bug, but we
already know that we are not generating the checksums while we should be.

Michal

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Linus Torvalds]

On Nov 29, 2016 5:51 AM, "Adam Borowski"  wrote:
>

> >
> >  (a) tested
>
> By many people.

No.

I've tested the build *without* this, and it works fine.

> >  (b) explains it
>
> The actual logic is in 4efca4ed0.  It wants C prototypes defined in
> asm/asm-prototypes.h that lists symbols defined in assembly -- genksyms
> knows only how to read C code.

See above. I'm not taking more random patches that "fix" this when it's not
broken for me. Not without very explicit explanations of why that patch is
still needed for others.

I suspect one of the other patches already fixed is for x86.

 Linus

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Adam Borowski]

On Tue, Nov 29, 2016 at 02:29:54PM +0100, Ingo Molnar wrote:
> * Adam Borowski  wrote:
> 
> > Here's some history:
> > The day of -rc1, multiple people immediately reported the breakage; it was
> > quickly found out that reverting 784d5699eddc fixes it.  A "going forward"
> > patch has been posted but was insufficient; when the real devs went to bed
[...]
> > For some reason the per-arch pieces were excluded; I was instructed
> > to send my part to x86 maintainers.
> > 
> > I did so; the patch later got a better description by Nick and a bunch of
> > Tested-by -- but alas, nary a comment or action from x86 guys, despite
> > pings/resends (last one: https://lkml.org/lkml/2016/11/23/706).  I guess I'm
> > lacking the secret handshake or something -- thus, it looks like it's my
> > fault, the rest of you can be blamed mostly for letting a
> > not-a-real-kernel-dev unsupervised.
> 
> My part of the story is easy to explain: the reason I skipped the 11/23 patch 
> was 
> because it was tagged 'kbuild' and because the commit that broke it was never 
> acked by (or was upstreamed via) the x86 maintainers - we never upstreamed 
> any 
> modversions changes in the past AFAIR - so I assumed it would be handled via 
> whatever path got the breakage upstream (turns out it was via the VFS tree?),
> or via the kbuild tree.

The problematic merge was 84d6984 (it brought in 22823ab4^..590abbdd).
Interesting commits have "$ARCH: move exports to definitions" in their
subjects, they indeed did not go through arch trees.

> > On Nov 24 finally Ingo responded, the discussion ended with you marking 
> > modversions as BROKEN.
> 
> Yeah, that was when my internal timer ran out: modversions breakage was 
> reported 
> against -rc1 already and it still wasn't working (a seemingly working kernel 
> build 
> resulted in an unbootable system) - due to the timeline and confusion you 
> explained.
> 
> I totally agree with marking it BROKEN: it was the simplest, most robust way 
> to 
> fix it and nobody seemed to be owning the modversions feature.

Per Ben Hutchings' objection, it doesn't look like BROKEN is an option at
least for 4.9 -- even if mainline leaves it as is, distro maintainers would
need to do the work themselves.

Architectures that look like they could be affected:
x86 alpha m68k s390 arm ppc sparc ia64
(this list might be incomplete!).

Of these, ppc and arm are already fixed, x86 is in this thread,
arm64 is not on the list which explains why it works for me.  No idea about
the rest.


Meow!
-- 
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings.  What should the
historians do?

[PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Adam Borowski]

Commit 4efca4ed ("kbuild: modversions for EXPORT_SYMBOL() for asm") adds
modversion support for symbols exported from asm files. Architectures
must include C-style declarations for those symbols in asm/asm-prototypes.h
in order for them to be versioned.

Add these declarations for x86, and an architecture-independent file that
can be used for common symbols.

User impact: kernels may fail to load modules at all when
CONFIG_MODVERSIONS=y.

Signed-off-by: Adam Borowski 
Tested-by: Kalle Valo 
Acked-by: Nicholas Piggin 
Tested-by: Peter Wu 
Tested-by: Oliver Hartkopp 
---

> So somebody send me a minimal patch that is
>
>  (a) tested

By many people.

>  (b) explains it

The actual logic is in 4efca4ed0.  It wants C prototypes defined in
asm/asm-prototypes.h that lists symbols defined in assembly -- genksyms
knows only how to read C code.

>  (c) obvious

To be honest I don't quite understand what's the real gain over code that
was removed by 784d5699eddc, this mostly brings the symbols back.  But
that's for people wiser than me to explain.

> and I'll happily re-enable modversions.


The powerpc counterpart to this patch is in mainline as 9e5f688, although a
file by that name already existed.

As for arm, it looks like it was handled the other way by 8478132.


diff --git a/arch/x86/include/asm/asm-prototypes.h 
b/arch/x86/include/asm/asm-prototypes.h
new file mode 100644
index 000..ae87224
--- /dev/null
+++ b/arch/x86/include/asm/asm-prototypes.h
@@ -0,0 +1,12 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
diff --git a/include/asm-generic/asm-prototypes.h 
b/include/asm-generic/asm-prototypes.h
new file mode 100644
index 000..df13637
--- /dev/null
+++ b/include/asm-generic/asm-prototypes.h
@@ -0,0 +1,7 @@
+#include 
+extern void *__memset(void *, int, __kernel_size_t);
+extern void *__memcpy(void *, const void *, __kernel_size_t);
+extern void *__memmove(void *, const void *, __kernel_size_t);
+extern void *memset(void *, int, __kernel_size_t);
+extern void *memcpy(void *, const void *, __kernel_size_t);
+extern void *memmove(void *, const void *, __kernel_size_t);
-- 
2.10.2

Bug#843349: (no subject)

[Alexander Kanavin]

FWIW, we had the same problem here with machines using Gigabyte X99 
motherboards. The problem was solved by updating the BIOS.


Alex

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Ingo Molnar]

* Adam Borowski  wrote:

> Here's some history:
> The day of -rc1, multiple people immediately reported the breakage; it was
> quickly found out that reverting 784d5699eddc fixes it.  A "going forward"
> patch has been posted but was insufficient; when the real devs went to bed
> the last message was
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1250370.html
> which ends with instructions and "Care to do a patch for x86?".
> 
> Then a random person (me) did the legwork, gathered affected symbols, wrote
> and tested the x86 patch.  It was then tested by multiple people; Arnd
> Bergmann wrote the ARM equivalent.  Whenever a new lkml thread reporting the
> breakage popped up, we pointed people to the patches and everyone was happy.
> As for upstreaming, there was a delay because Michal Marek was on vacation.
> 
> Michal returned and sent you the pull request, you merged it as 04e36857 on
> Nov 18.  For some reason the per-arch pieces were excluded; I was instructed
> to send my part to x86 maintainers.
> 
> I did so; the patch later got a better description by Nick and a bunch of
> Tested-by -- but alas, nary a comment or action from x86 guys, despite
> pings/resends (last one: https://lkml.org/lkml/2016/11/23/706).  I guess I'm
> lacking the secret handshake or something -- thus, it looks like it's my
> fault, the rest of you can be blamed mostly for letting a
> not-a-real-kernel-dev unsupervised.

My part of the story is easy to explain: the reason I skipped the 11/23 patch 
was 
because it was tagged 'kbuild' and because the commit that broke it was never 
acked by (or was upstreamed via) the x86 maintainers - we never upstreamed any 
modversions changes in the past AFAIR - so I assumed it would be handled via 
whatever path got the breakage upstream (turns out it was via the VFS tree?),
or via the kbuild tree.

> On Nov 24 finally Ingo responded, the discussion ended with you marking 
> modversions as BROKEN.

Yeah, that was when my internal timer ran out: modversions breakage was 
reported 
against -rc1 already and it still wasn't working (a seemingly working kernel 
build 
resulted in an unbootable system) - due to the timeline and confusion you 
explained.

I totally agree with marking it BROKEN: it was the simplest, most robust way to 
fix it and nobody seemed to be owning the modversions feature.

Thanks,

Ingo

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Adam Borowski]

On Mon, Nov 28, 2016 at 08:08:57PM -0800, Linus Torvalds wrote:
> On Mon, Nov 28, 2016 at 5:15 PM, Ben Hutchings  wrote:
> >>
> >> The modversions stuff may just be too painful to bother with. Very few
> >> people probably use it, and the ones that do likely don't have any
> >> overriding reason why.
> > [...]
> >
> > Debian has some strong reasons:
> 
> Honestly, I'd just like to see actual real patches from people who
> care about this.
> 
> The reason I disabled it entirely was simply that the discussions had
> been going on forever, but nobody actually seemed to care enough to
> just fix the damn thing. There was all the _noise_ about "look, here's
> a patch", but nothing got sent to maintainers and actually actively
> pushed as a "this fixes a regression".

Here's some history:
The day of -rc1, multiple people immediately reported the breakage; it was
quickly found out that reverting 784d5699eddc fixes it.  A "going forward"
patch has been posted but was insufficient; when the real devs went to bed
the last message was
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1250370.html
which ends with instructions and "Care to do a patch for x86?".

Then a random person (me) did the legwork, gathered affected symbols, wrote
and tested the x86 patch.  It was then tested by multiple people; Arnd
Bergmann wrote the ARM equivalent.  Whenever a new lkml thread reporting the
breakage popped up, we pointed people to the patches and everyone was happy.
As for upstreaming, there was a delay because Michal Marek was on vacation.

Michal returned and sent you the pull request, you merged it as 04e36857 on
Nov 18.  For some reason the per-arch pieces were excluded; I was instructed
to send my part to x86 maintainers.

I did so; the patch later got a better description by Nick and a bunch of
Tested-by -- but alas, nary a comment or action from x86 guys, despite
pings/resends (last one: https://lkml.org/lkml/2016/11/23/706).  I guess I'm
lacking the secret handshake or something -- thus, it looks like it's my
fault, the rest of you can be blamed mostly for letting a
not-a-real-kernel-dev unsupervised.

On Nov 24 finally Ingo responded, the discussion ended with you marking
modversions as BROKEN.


> So somebody send me a minimal patch that is
> 
>  (a) tested
>  (b) explains it
>  (c) obvious
> 
> and I'll happily re-enable modversions.

Not sure whether you guys want to revert or to go forward.  If the latter,
my piece handles x86, Arnd's ARM.  Powerpc already has the needed bits in
mainline.  I've just tried arm64 -- despite same toolchain versions as
failing x86, with CONFIG_MODVERSIONS=y it loaded a bunch of modules fine so
it appears no arch bits are needed there.  My uneducated guess is that most
other architectures should be fine without special handling, too.  It'd be
nice if someone with an actual clue could confirm.


Meow!
-- 
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings.  What should the
historians do?

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Michal Marek]

Dne 29.11.2016 v 03:31 Nicholas Piggin napsal(a):
> On Tue, 29 Nov 2016 01:15:48 +
> Ben Hutchings  wrote:
> 
>> [I've had to guess at the cc list for this, because we no longer have
>> mail archives that preserve them.]
> 
> You got it about right.
> 
>> On Fri, 2016-11-25 at 10:01 -0800, Linus Torvalds wrote:
>>> On Thu, Nov 24, 2016 at 4:40 PM, Nicholas Piggin  wrote: 
>>>  
>
> Yes, manual "marking" is never going to be a viable solution.  

 I guess it really depends on how exactly you want to use it. For distros
 that do stable ABI but rarely may have to break something for security
 reasons, it should work and give exact control.  
>>
>> This is roughly how Debian handles the kernel module ABI during a
>> stable release.
>>
>>> No. Because nobody else will care, so unless it's like a single symbol
>>> or something, it will just be a maintenance nightmare.  
>>
>> I agree with this.  We can explicitly "version" individual symbols
>> anyway by doing something like:
>>
>> -int foo(void);
>> +#define foo foo_2
>> +int foo_2(int);
> 
> Yeah... Benefit being it's very simple and everybody can see exactly
> what it does and knows how it will work.
> 
>>
 What else do people *actually* use it for? Preventing mismatched modules
 when .git version is not attached and release version of the kernel has
 not been bumped. Is that it?  
>>>
>>> It used to be very useful for avoiding loading stale modules and then
>>> wasting days on debugging something that wasn't the case when you had
>>> forgotten to do "make modules_install". Change some subtle internal
>>> ABI issue (add/remove a parameter, whatever) and it would really help.
>>>
>>> These days, for me, LOCALVERSION_AUTO and module signing are what I
>>> personally tend to use.
>>>
>>> The modversions stuff may just be too painful to bother with. Very few
>>> people probably use it, and the ones that do likely don't have any
>>> overriding reason why.  
>> [...]
>>
>> Debian has some strong reasons:

I guess many distros have similar reasons.


>> 1. Changing the release string requires any out-of-tree modules to be
>> upgraded (at least rebuilt) on end-user systems.  So we try to avoid
>> doing that during the lifetime of a stable release, i.e. we don't let
>> the release string change.  Also, the release string is reflected in
>> package names (e.g. linux-image-4.8.0-1-amd64), and introducing new
>> package names requires manual approval by the Debian archive team.
> 
> This is something I've noticed. Would it be better if the module loader
> ignores the kernel version and instead used some internal ABI version
> string to check against? Otherwise (AFAICT) you always have 4.8.0 versions
> despite being 4.8.7 kernel, and you can't upgrade a point release without
> overwriting your old kernel and modules.

The thing is - to maintain an ABI version string, you need some level of
certainty that two given ABIs are really interchangeable. Which means
you need to check whether the symbols _and_ types exposed are unchanged.
Which is a thing that genksyms, the tool behind CONFIG_MODVERSIONS, does
quite well. So yes, you could do a testbuild with CONFIG_MODVERSIONS=y
and a production build with some global ABI string, but what's the point
then.


> It would be nice to get upstream to the point where 4.9 modversions
> works if you just patch out depends BROKEN. That would require reverting
> a few more of Al's arch patches.
> 
> Then in 4.10 we can re-add all those arch patches (which are less
> controversial without the asm-prototypes.h workaround), and implement a
> simple stable ABI version string check, and then in 4.11 we can remove
> modversions.

I'd rather change the kconfig to

depends on BROKEN || 

and eventuallly remove the dependency again. PPC has the header already,
so it can be added right away. I do not know why the x86 patch has not
been merged yet.

Michal

Bug#804079: [Xen-devel] Kernel panic on Xen virtualisation in Debian

[Wei Liu]

On Mon, Nov 14, 2016 at 04:55:40PM +0100, Andreas Ziegler wrote:
> Hi,
> 
> few months later Ingo decided again to give it a try as he really
> doesn't want to keep ipv6 disabled in 2016.
> He tried Xen 4.8 - which didn't help, the crash reappeared.
> He then managed to build Xen with debug=y and soon it crashed with the
> following output, which looks a little bit longer than without debug:
> 
> http://paste.debian.net/895464/
> 

Entry not found -- maybe it expired... Sorry.

> If this still doesn't help, we would really appreciate more information
> on how to do proper debugging, the information we found online is either
> very old, confusing - or it's hidden very good?
> 

What sort of information did you find ? What do you need ?

Wei.