Processed: tagging 825024

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 825024 - pending
Bug #825024 [src:linux] linux: add MIPS r6 and N32 support
Removed tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
825024: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825024
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: limit source to linux, tagging 839616

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> limit source linux
Limiting to bugs with field 'source' containing at least one of 'linux'
Limit currently set to 'source':'linux'

> tags 839616 + pending
Bug #839616 [src:linux] linux: add support for chaoskey
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
839616: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839616
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#845302: systemd: 232-6:Failed to boot, makes kernel panic when starting /sbin/init.

[Ben Hutchings]

On Wed, 23 Nov 2016 14:30:36 +0100 Michael Biebl  wrote:
> Control: reassign -1 initramfs-tools 0.125
> 
> 
> Am 23.11.2016 um 11:25 schrieb K.Ohta:
> > Not mounted /usr and made kernel panic still longer sleep.
> > 
> > Then booting with "init=/bin/bash" , check dmesg (attached).
> > Below message was wrote when trying to mount /usr :
> >> [   15.958645] EXT4-fs (sde3): Unrecognized mount option "auto" or missing 
> >> value
> > 
> > If this message is correct, mount program included by initramfs
> > has not recognized "auto" (or some another) option(s), regardless
> > /bin/mount (or /sbin/mount/ext4) recognize this option(s) :-(
> 
> 
> I'm going to reassign this to initramfs-tools as it uses mount
> implementations from either klibc-utils or busybox which are both
> incomplete and as a result, fail to mount /usr.
> 
> I decided against reassigning this to busybox and klibc-utils.
> I think it's preferable, if initramfs-tools simply uses the mount
> implementation from the real systemd, i.e. util-linux. This guarantees
> that we won't run into such problems again in the future.
> 
> The mount utility is tiny, all its library dependencies are already in
> the initramfs. Rebuilding the initramfs with mount from u-l increases
> the size by 17K.

I see.  fsck already pulls in libmount, so indeed there is little extra
cost to including mount.

> We would also have to make sure to use mount --move in
> /usr/share/initramfs-tools/init for /run, /sys and /proc
> 
> Ben, what's your take on this?

I'd like to sort out the busybox and klibc-utils implementations of
mount, but I must admit there isn't much point in using them any more.

Ben.
 
-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson



signature.asc
Description: This is a digitally signed message part

Bug#843128: partially solved

[Ricardo Fabian Peliquero]

On Fri, Dec 09, 2016 at 01:03:44PM +, Ben Hutchings wrote:
> On Fri, 2016-12-09 at 01:18 -0300, Ricardo Fabian Peliquero wrote:
> >  from: linux-image-4.8.0-1-amd64-unsigned:amd64 (4.8.5-1)
> >    to: linux-image-4.9.0-rc8-amd64-unsigned:amd64 (4.9~rc8-1~exp1)
> > and installing mingetty(8)
> > the system is booting well (e.g. without kernel panic).
> > 
> > But the following errors appeared for ttys using these lines in 
> > /etc/inittab:
> > 
> > 2:23:respawn:/sbin/fgetty tty2
> > # Produces error. Output:
> >  [   14.741345] fgetty[1309] vsyscall attempted with vsyscall=none 
> > ip:ff600400 cs:33 sp:7ffcb7dbade0 ax:ff[   14.753469] fgetty[1309]: 
> > segfault at ff600400 ip ff600400 sp 7ffcb7dbade0 error 
> > 15
> > ...
> >  INIT: Id "2" respawning too fast: disabled for 5 minutes
> > 
> > 3:23:respawn:/sbin/ngetty 3
> > # Produces error. Output:
> >  [   14.670134] ngetty-helper[1311] vsyscall attempted with vsyscall=none 
> > ip:ff600400 cs:33 sp:7ffca011e1a[   14.684298] ngetty-helper[1311]: 
> > segfault at ff600400 ip ff600400 sp 7ffca011e1a0 error 
> > 15
> 
> fgetty uses dietlibc, and the stable version of dietlibc still uses the
> vsyscall feature which is now disabled by default.  You can make it
> work again by adding 'vsyscall=emulate' to the kernel command line.
> 
> I'll have to reconsider whether to revert the configuration change now
> that I know dietlibc is a problem.

Your suggestion worked here.

I will be using vsyscall emulation option appended to lilo.conf until better 
resolution.

Thank you!

Ricardo

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

[Don Zickus]

On Fri, Dec 09, 2016 at 01:50:41PM +1000, Nicholas Piggin wrote:
> > 
> > We have plenty of customers with 10 year old drivers, where the expertise
> > has long left the company.  The engineers still around, recompile and make
> > tweaks to get things working on the latest RHEL.  Verify it passes testing
> > and release it.  Then they hope to not touch it again for a few years until
> > the next RHEL comes along.
> > 
> > Scary, huh? :-)
> 
> Oh yeah my aim here is not to make distro or out of tree module vendors
> life harder, actually the opposite. If it turns out modversions really is
> the best approach, I'm not in a position to complain about its complexity
> because we have Suse and Redhat people maintaining the build and module
> systems :) I just want to see if we can do things better.

Hi Nick,

I think we are in pretty good agreement here.  We can do better than
modversions.  On the flip side, I would hate to see modversions ripped out
until we have an alternate path forward as it does get us by for now. :-)

Cheers,
Don

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

[Nicholas Piggin]

On Fri, 09 Dec 2016 15:21:33 +
Ian Campbell  wrote:

> On Fri, 2016-12-09 at 13:33 +1000, Nicholas Piggin wrote:
> > 
> > Well I simply tested the outcome. If you have:
> > 
> > struct blah {
> >   int x;
> > };
> > int foo(struct blah *blah)
> > {
> >   return blah->x;
> > }
> > EXPORT(foo);
> > 
> > $ nm vmlinux | grep __crc_foo
> > a0cf13a0 A __crc_foo
> > 
> > Now change to
> > 
> > struct blah {
> >   int y;
> >   int x;
> > };
> > 
> > $ nm vmlinux | grep __crc_foo
> > a0cf13a0 A __crc_foo
> > 
> > It just doesn't catch these things.  
> 
> I found the same when I just added your snippet to init/main.c.
> 
> _But_ when I moved the struct into include/types.h (which happened to
> be included by init/main.c) then, with just x in the struct:
> 
> $ make -s init/main.{o,symtypes} && grep -E foo\|blah init/main.symtypes 
> && nm init/main.o  | grep __crc_foo
> s#blah struct blah { int x ; } 
> foo int foo ( s#blah * ) 
> 0cd0312e A __crc_foo
> 
> but adding y:
> 
> $ make -s init/main.{o,symtypes} && grep -E foo\|blah init/main.symtypes 
> && nm init/main.o  | grep __crc_foo
> s#blah struct blah { int x ; int y ; } 
> foo int foo ( s#blah * ) 
> eda220c6 A __crc_foo
> 
> So it does catch things in that case.
> 
> With struct blah inline in main.c it was:
> 
> $ make -s init/main.{o,symtypes} && grep -E foo\|blah init/main.symtypes 
> && nm init/main.o  | grep __crc_foo
> s#blah struct blah { UNKNOWN } 
> foo int foo ( s#blah * ) 
> a0cf13a0 A __crc_foo
> 
> So I suppose it only cares about structs which are in headers, which I
> guess makes sense. I think it is working in at least one of the
> important cases.

Aha thanks, well that's my mistake. Clever little bugger, isn't it? Okay
it's not so useless as I first thought!

That said, a dwarf based checker tool should be able to do as good a job
(maybe a bit better because report is very informative and it may pick up
compiler alignments or padding options). So I still think it's worth
looking at those if we can remove modversions.

Thanks,
Nick

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

[Greg Kroah-Hartman]

On Sat, Dec 10, 2016 at 01:56:53AM +1000, Nicholas Piggin wrote:
> On Fri, 9 Dec 2016 15:36:04 +0100
> Stanislav Kozina  wrote:
> 
> >  The question is how to provide a similar guarantee if a different way? 
> >   
> > >>> As a tool to aid distro reviewers, modversions has some value, but the
> > >>> debug info parsing tools that have been mentioned in this thread seem
> > >>> superior (not that I've tested them).  
> > >> On the other hand the big advantage of modversions is that it also
> > >> verifies the checksum during runtime (module loading). In other words, I
> > >> believe that any other solution should still generate some form of
> > >> checksum/watermark which can be easily checked for compatibility on
> > >> module load.
> > >> It should not be hard to add to the DWARF based tools though. We'd just
> > >> parse DWARF data instead of the C code.  
> > > A runtime check is still done, with per-module vermagic which distros
> > > can change when they bump the ABI version. Is it really necessary to
> > > have more than that (i.e., per-symbol versioning)?  
> > 
> >  From my point of view, it is. We need to allow changing ABI for some 
> > modules while maintaining it for others.
> > In fact I think that there should be version not only for every exported 
> > symbol (in the EXPORT_SYMBOL() sense), but also for every public type 
> > (in the sense of eg. structure defined in the public header file).
> 
> Well the distro can just append _v2, _v3 to the name of the function
> or type if it has to break compat for some reason. Would that be enough?

There are other ways that distros can work around when upstream "breaks"
the ABI, sometimes they can rename functions, and others they can
"preload" structures with padding in anticipation for when/if fields get
added to them.  But that's all up to the distros, no need for us to
worry about that at all :)

thanks,

greg k-h

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

[Nicholas Piggin]

On Fri, 9 Dec 2016 15:36:04 +0100
Stanislav Kozina  wrote:

>  The question is how to provide a similar guarantee if a different way?  
> >>> As a tool to aid distro reviewers, modversions has some value, but the
> >>> debug info parsing tools that have been mentioned in this thread seem
> >>> superior (not that I've tested them).  
> >> On the other hand the big advantage of modversions is that it also
> >> verifies the checksum during runtime (module loading). In other words, I
> >> believe that any other solution should still generate some form of
> >> checksum/watermark which can be easily checked for compatibility on
> >> module load.
> >> It should not be hard to add to the DWARF based tools though. We'd just
> >> parse DWARF data instead of the C code.  
> > A runtime check is still done, with per-module vermagic which distros
> > can change when they bump the ABI version. Is it really necessary to
> > have more than that (i.e., per-symbol versioning)?  
> 
>  From my point of view, it is. We need to allow changing ABI for some 
> modules while maintaining it for others.
> In fact I think that there should be version not only for every exported 
> symbol (in the EXPORT_SYMBOL() sense), but also for every public type 
> (in the sense of eg. structure defined in the public header file).

Well the distro can just append _v2, _v3 to the name of the function
or type if it has to break compat for some reason. Would that be enough?

Thanks,
Nick

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

[Ian Campbell]

On Fri, 2016-12-09 at 13:33 +1000, Nicholas Piggin wrote:
> 
> Well I simply tested the outcome. If you have:
> 
> struct blah {
>   int x;
> };
> int foo(struct blah *blah)
> {
>   return blah->x;
> }
> EXPORT(foo);
> 
> $ nm vmlinux | grep __crc_foo
> a0cf13a0 A __crc_foo
> 
> Now change to
> 
> struct blah {
>   int y;
>   int x;
> };
> 
> $ nm vmlinux | grep __crc_foo
> a0cf13a0 A __crc_foo
> 
> It just doesn't catch these things.

I found the same when I just added your snippet to init/main.c.

_But_ when I moved the struct into include/types.h (which happened to
be included by init/main.c) then, with just x in the struct:

$ make -s init/main.{o,symtypes} && grep -E foo\|blah init/main.symtypes && 
nm init/main.o  | grep __crc_foo
s#blah struct blah { int x ; } 
foo int foo ( s#blah * ) 
0cd0312e A __crc_foo

but adding y:

$ make -s init/main.{o,symtypes} && grep -E foo\|blah init/main.symtypes && 
nm init/main.o  | grep __crc_foo
s#blah struct blah { int x ; int y ; } 
foo int foo ( s#blah * ) 
eda220c6 A __crc_foo

So it does catch things in that case.

With struct blah inline in main.c it was:

$ make -s init/main.{o,symtypes} && grep -E foo\|blah init/main.symtypes && 
nm init/main.o  | grep __crc_foo
s#blah struct blah { UNKNOWN } 
foo int foo ( s#blah * ) 
a0cf13a0 A __crc_foo

So I suppose it only cares about structs which are in headers, which I
guess makes sense. I think it is working in at least one of the
important cases.

Ian.

Bug#847570: linux-image-4.9.0-rc8-amd64-unsigned: AMDGPU not build with support for GCN1.0 and GCN1.1 VGAs

[Ferdinand Pöll]

Package: linux-image-4.9.0-rc8-amd64-unsigned
Version: 4.9~rc8-1~exp1
Severity: wishlist
Tags: patch

Dear Maintainer,

I have an AMD Radeon R9 270X and I'd like to use the new amdgpu driver with it.
Since 4.9, linux includes experimental support for GCN 1.0 VGAs, but it's not
enabled in the debian builds as well as the support for GCN 1.1 cards (which
isn't new in the kernel anymore). In the kernel build config, you just need to
set CONFIG_DRM_AMDGPU_SI=Y (for GCN1.0-based cards) and CONFIG_DRM_AMDGPU_CIK=Y
(for GCN1.1-based cards). To use amdgpu if it is built into the kernel with the
old gpus users just need to blacklist radeon and upon the next reboot linux
will load amdgpu and users can install amdgpu-pro if they want to or just stick
with the newest free graphics driver.

The kernel in my system info below is built from source with the options
mentioned above enabled.



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 
'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-rc8 (SMP w/12 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

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

[Stanislav Kozina]

The question is how to provide a similar guarantee if a different way?

As a tool to aid distro reviewers, modversions has some value, but the
debug info parsing tools that have been mentioned in this thread seem
superior (not that I've tested them).

On the other hand the big advantage of modversions is that it also
verifies the checksum during runtime (module loading). In other words, I
believe that any other solution should still generate some form of
checksum/watermark which can be easily checked for compatibility on
module load.
It should not be hard to add to the DWARF based tools though. We'd just
parse DWARF data instead of the C code.

A runtime check is still done, with per-module vermagic which distros
can change when they bump the ABI version. Is it really necessary to
have more than that (i.e., per-symbol versioning)?


From my point of view, it is. We need to allow changing ABI for some 
modules while maintaining it for others.
In fact I think that there should be version not only for every exported 
symbol (in the EXPORT_SYMBOL() sense), but also for every public type 
(in the sense of eg. structure defined in the public header file).


Thanks,
-Stanislav

Bug#843128: partially solved

[Ben Hutchings]

On Fri, 2016-12-09 at 01:18 -0300, Ricardo Fabian Peliquero wrote:
> Dear Maintainer,
> 
> After upgrading
> 
>  from: linux-image-4.8.0-1-amd64-unsigned:amd64 (4.8.5-1)
>    to: linux-image-4.9.0-rc8-amd64-unsigned:amd64 (4.9~rc8-1~exp1)
> 
> and installing mingetty(8)
> 
> the system is booting well (e.g. without kernel panic).
> 
> But the following errors appeared for ttys using these lines in /etc/inittab:
> 
> 2:23:respawn:/sbin/fgetty tty2
> # Produces error. Output:
>  [   14.741345] fgetty[1309] vsyscall attempted with vsyscall=none 
> ip:ff600400 cs:33 sp:7ffcb7dbade0 ax:ff[   14.753469] fgetty[1309]: 
> segfault at ff600400 ip ff600400 sp 7ffcb7dbade0 error 15
>  [   14.761442] fgetty[1314] vsyscall attempted with vsyscall=none 
> ip:ff600400 cs:33 sp:7ffc57494eb0 ax:ff[   14.774655] fgetty[1314]: 
> segfault at ff600400 ip ff600400 sp 7ffc57494eb0 error 15
>  [   14.783045] fgetty[1315] vsyscall attempted with vsyscall=none 
> ip:ff600400 cs:33 sp:7fff4cd23c40 ax:ff[   14.797132] fgetty[1315]: 
> segfault at ff600400 ip ff600400 sp 7fff4cd23c40 error 15
>  [   14.805678] fgetty[1316] vsyscall attempted with vsyscall=none 
> ip:ff600400 cs:33 sp:7ffebc275580 ax:ff[   14.820255] fgetty[1316]: 
> segfault at ff600400 ip ff600400 sp 7ffebc275580 error 15
>  [   14.829085] fgetty[1317] vsyscall attempted with vsyscall=none 
> ip:ff600400 cs:33 sp:7ffdf2ba87d0 ax:ff[   14.846203] fgetty[1317]: 
> segfault at ff600400 ip ff600400 sp 7ffdf2ba87d0 error 15
>  [   14.855785] fgetty[1318] vsyscall attempted with vsyscall=none 
> ip:ff600400 cs:33 sp:7fff05d8bca0 ax:ff[   14.873951] fgetty[1318]: 
> segfault at ff600400 ip ff600400 sp 7fff05d8bca0 error 15
>  [   14.883984] fgetty[1319] vsyscall attempted with vsyscall=none 
> ip:ff600400 cs:33 sp:7ffdb25fe940 ax:ff[   14.903582] fgetty[1319]: 
> segfault at ff600400 ip ff600400 sp 7ffdb25fe940 error 15
>  [   14.914209] fgetty[1320] vsyscall attempted with vsyscall=none 
> ip:ff600400 cs:33 sp:7ffe39d6bda0 ax:ff[   14.934960] fgetty[1320]: 
> segfault at ff600400 ip ff600400 sp 7ffe39d6bda0 error 15
>  [   14.946825] fgetty[1321] vsyscall attempted with vsyscall=none 
> ip:ff600400 cs:33 sp:7fff000656c0 ax:ff[   14.968608] fgetty[1321]: 
> segfault at ff600400 ip ff600400 sp 7fff000656c0 error 15
>  [   14.981397] fgetty[1322] vsyscall attempted with vsyscall=none 
> ip:ff600400 cs:33 sp:7fffa6d94100 ax:ff[   15.004560] fgetty[1322]: 
> segfault at ff600400 ip ff600400 sp 7fffa6d94100 error 15
>  INIT: Id "2" respawning too fast: disabled for 5 minutes
> 
> 3:23:respawn:/sbin/ngetty 3
> # Produces error. Output:
>  [   14.670134] ngetty-helper[1311] vsyscall attempted with vsyscall=none 
> ip:ff600400 cs:33 sp:7ffca011e1a[   14.684298] ngetty-helper[1311]: 
> segfault at ff600400 ip ff600400 sp 7ffca011e1a0 error 15
> 
> 
> Please let me know if you consider these errors should be reported to fgetty 
> and ngetty maintainers.

fgetty uses dietlibc, and the stable version of dietlibc still uses the
vsyscall feature which is now disabled by default.  You can make it
work again by adding 'vsyscall=emulate' to the kernel command line.

I'll have to reconsider whether to revert the configuration change now
that I know dietlibc is a problem.

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky



signature.asc
Description: This is a digitally signed message part

Bug#847557: /usr/sbin/exportfs: exportfs cannot handle IPv6 addresses

[Bjoern Laessig]

Package: nfs-kernel-server
Version: 1:1.2.8-9.2
Severity: important
File: /usr/sbin/exportfs
Tags: ipv6

Dear Maintainer,

 when trying to export/unexport a path i cannot give IPv6 addresses to
 exportfs.

# showmount -e 
Export list for testhost:
/path/sub fe80::%eth0/10

# exportfs -u [fe80::%eth0]/10:/path/sub
exportfs: Invalid exporting option: [fe80

When removing the [] i get the same error (without [)
When using something like 2001:0db8:1234::/64 the same error occurs.

-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
151   udp  59414  mountd
151   tcp  55223  mountd
152   udp  44480  mountd
152   tcp  53745  mountd
153   udp  41426  mountd
153   tcp  55737  mountd
132   tcp   2049  nfs
133   tcp   2049  nfs
134   tcp   2049  nfs
1002272   tcp   2049
1002273   tcp   2049
132   udp   2049  nfs
133   udp   2049  nfs
134   udp   2049  nfs
1002272   udp   2049
1002273   udp   2049
1000211   udp  37459  nlockmgr
1000213   udp  37459  nlockmgr
1000214   udp  37459  nlockmgr
1000211   tcp  34145  nlockmgr
1000213   tcp  34145  nlockmgr
1000214   tcp  34145  nlockmgr
-- /etc/default/nfs-kernel-server --
RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS="--manage-gids"
NEED_SVCGSSD=""
RPCSVCGSSDOPTS=""
-- /etc/exports --
/path/sub   
fe80::%eth0/10(rw,no_subtree_check,no_root_squash)

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nfs-kernel-server depends on:
ii  init-system-helpers  1.46
ii  keyutils 1.5.9-9
ii  libblkid12.29-1
ii  libc62.24-7
ii  libcap2  1:2.25-1
ii  libsqlite3-0 3.15.2-1
ii  libtirpc10.2.5-1
ii  libwrap0 7.6.q-25
ii  lsb-base 9.20161125
ii  netbase  5.3
ii  nfs-common   1:1.2.8-9.2
ii  ucf  3.0036

nfs-kernel-server recommends no packages.

nfs-kernel-server suggests no packages.

-- no debconf information

Bug#846941: linux-image-4.8.0-1-amd64-unsigned: ThinkPad X220: hibernating with screen turned off (screensaver) causes it to remain off until reboot

[Ivan Krylov]

On 04.12.2016 17:02, Ivan Krylov wrote:
> Surprisingly, hibernate works with s2disk from uswsusp, but sometimes on 
> resume system resets right after loading the image.

I had temporarily disabled screen power management in XScreenSaver and
have been hibernating via `echo disk > /sys/power/state` for a while.
After a few hibernate-resume cycles the system rebooted instead of
properly waking up after loading the image, so that's not uswsusp's bug.
However, it might deserve a separate bug report.

Also, the only reason s2disk doesn't cause the system to wake up with
screen disbaled is that it switches to another console before
snapshotting the system, forcibly turning the screen on.

-- 
Best regards,
Ivan

Bug#847549: kernel bug dcache.c 2373 invalid opcode 0000 d_materialise_unique

[Daniel Pocock]

Package: linux
Version: 3.16.36-1+deb8u1
Severity: important

The system is an NFS server running linux-image-3.16.0-4-amd64

At times of heavy load on NFS, such as "git checkout some-branch" in a
large repository, the system crashes (dmesg output attached).  It has
been happening regularly since the upgrade to jessie and with every
kernel released through stable updates.  I don't recall seeing this in
wheezy.

I've installed kdump-tools.  Sometimes it captures the dmesg output, a
recent example from a crash on 2016-12-02 is attached.  I'm not sure if
the crashes without /var/crash logs are the same bug.

The same crash was reported[1] on linux-fsdevel by another Debian user.

I don't mind trying a backports kernel as a workaround, but can anybody
comment on whether the backports kernel 4.7.8-1~bpo8+1 will match with
the NFS user space packages in jessie, or do I need to update some of
those packages too?

Having seen various crashes without stack dumps, I also tried checking
the RAM in the machine.  memtest86+ did not report any errors, either
using 8GB (upgraded) or the original 2GB from the vendor.  The machine
had 8GB when it crashed on 2016-12-02 and it had only 2GB when it
crashed again 2016-12-07

Regards,

Daniel


1. http://www.spinics.net/lists/linux-fsdevel/msg98540.html
[322559.833066] [ cut here ]
[322559.833185] kernel BUG at 
/build/linux-EZT6bx/linux-3.16.36/fs/dcache.c:2373!
[322559.833346] invalid opcode:  [#1] SMP 
[322559.833449] Modules linked in: cpufreq_conservative cpufreq_stats 
cpufreq_powersave cpufreq_userspace 8021q garp stp mrp llc binfmt_misc 
xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfr
m_algo nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc evdev 
radeon kvm_amd kvm ttm drm_kms_helper drm edac_mce_amd edac_core k10temp 
i2c_algo_bit pcspkr shpchp acpi_cpufreq sp5100_tco tpm_infineon tpm_tis tpm 
button i2c_piix4 i2c_core processor thermal_sys loop fuse parport_pc ppdev lp 
parport autofs4 ext4 crc16 mbcache jbd2 crc32c_generic btrfs xor raid6_pq 
hid_generic usbhid hid dm_mod raid1 md_mod sg sd_mod crc_t10dif 
crct10dif_generic crct10dif_common ata_generic usb_storage ohci_pci pata_atiixp 
ahci libahci ehci_pci tg3 ohci_hcd ehci_hcd ptp pps_core libphy libata scsi_mod
[322559.835542]  usbcore usb_common
[322559.835598] CPU: 0 PID: 1762 Comm: nfsd Not tainted 3.16.0-4-amd64 #1 
Debian 3.16.36-1+deb8u1
[322559.835787] Hardware name: HP ProLiant MicroServer, BIOS O41 01/17/2011
[322559.835944] task: 8800d5ab0ca0 ti: 88020e388000 task.ti: 
88020e388000
[322559.836110] RIP: 0010:[]  [] 
__d_rehash+0x53/0x60
[322559.836298] RSP: 0018:88020e38bb58  EFLAGS: 00010282
[322559.836416] RAX: 000eb87f RBX: 8800a2471990 RCX: 
000c
[322559.836575] RDX: c901 RSI: c976c3f8 RDI: 
8800b9ba3498
[322559.836733] RBP: 8800b9ba3498 R08: 8800b9ba3410 R09: 
6cf0c77314797b26
[322559.836892] R10:  R11:  R12: 
8800b9ba33d8
[322559.837052] R13: 8800b9ba34f0 R14: 88001ebfb6d8 R15: 
88020e38bc58
[322559.837212] FS:  7f376c212700() GS:88021fc0() 
knlGS:
[322559.837389] CS:  0010 DS:  ES:  CR0: 8005003b
[322559.837518] CR2: 7f98951a5650 CR3: 000215be1000 CR4: 
07f0
[322559.837676] Stack:
[322559.837723]  811c1bac 88001ebfb6d8 8800b9ba33d8 
88001ebfb6d8
[322559.837911]  88001ebfb6d8 880214978560 88001ebfb6d8 
88020e38bc58
[322559.838097]  811b3739 880214978560  
811b3fcf
[322559.838284] Call Trace:
[322559.838348]  [] ? d_materialise_unique+0x7c/0x3b0
[322559.838493]  [] ? lookup_real+0x19/0x50
[322559.838617]  [] ? __lookup_hash+0x2f/0x40
[322559.838744]  [] ? lookup_one_len+0xcd/0x120
[322559.838877]  [] ? reconnect_path+0x10a/0x2c0
[322559.839021]  [] ? nfsd_proc_getattr+0xa0/0xa0 [nfsd]
[322559.839173]  [] ? exportfs_decode_fh+0xef/0x2c0
[322559.839319]  [] ? expkey_match+0x36/0x40 [nfsd]
[322559.839470]  [] ? cache_check+0xf4/0x3b0 [sunrpc]
[322559.839620]  [] ? exp_find+0xe1/0x190 [nfsd]
[322559.839754]  [] ? pick_next_task_fair+0x6e1/0x820
[322559.839897]  [] ? __switch_to+0xde/0x5a0
[322559.840028]  [] ? fh_verify+0x2e5/0x5c0 [nfsd]
[322559.840173]  [] ? unix_gid_show+0x110/0x110 [sunrpc]
[322559.840328]  [] ? nfsd3_proc_getattr+0x63/0xe0 [nfsd]
[322559.840484]  [] ? nfsd_dispatch+0xb2/0x200 [nfsd]
[322559.840635]  [] ? svc_process_common+0x41b/0x670 [sunrpc]
[322559.840798]  [] ? nfsd_destroy+0x70/0x70 [nfsd]
[322559.840945]  [] ? svc_process+0x10c/0x160 [sunrpc]
[322559.841097]  [] ? nfsd+0xbf/0x130 [nfsd]
[322559.841227]  [] ? kthread+0xbd/0xe0
[322559.841344]  [] ? kthread_create_on_node+0x180/0x180
[322559.841492]  [] ? ret_from_fork+0x58/0x90
[322559.841625]  [] ? kthread_create_on_node+0x180/0x180
[322559.841770] Code: 89 47 08 74 04 48 89 50 08 48 89 77 10 48 83 

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

[Nicholas Piggin]

On Fri, 9 Dec 2016 08:55:51 +0100
Stanislav Kozina  wrote:

> >> The question is how to provide a similar guarantee if a different way?  
> > As a tool to aid distro reviewers, modversions has some value, but the
> > debug info parsing tools that have been mentioned in this thread seem
> > superior (not that I've tested them).  
> 
> On the other hand the big advantage of modversions is that it also 
> verifies the checksum during runtime (module loading). In other words, I 
> believe that any other solution should still generate some form of 
> checksum/watermark which can be easily checked for compatibility on 
> module load.
> It should not be hard to add to the DWARF based tools though. We'd just 
> parse DWARF data instead of the C code.

A runtime check is still done, with per-module vermagic which distros
can change when they bump the ABI version. Is it really necessary to
have more than that (i.e., per-symbol versioning)?

Thanks,
Nick

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

[Stanislav Kozina]

The question is how to provide a similar guarantee if a different way?

As a tool to aid distro reviewers, modversions has some value, but the
debug info parsing tools that have been mentioned in this thread seem
superior (not that I've tested them).


On the other hand the big advantage of modversions is that it also 
verifies the checksum during runtime (module loading). In other words, I 
believe that any other solution should still generate some form of 
checksum/watermark which can be easily checked for compatibility on 
module load.
It should not be hard to add to the DWARF based tools though. We'd just 
parse DWARF data instead of the C code.


Regards,
-Stanislav