linux-kernel - Nasty regression from .27.7 to .27.8: idle samba goes crazy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 08 Dec 2008 07:18:59 +0100
From:	"Holger Hoffstaette" <holger@...ards.de>
To:	linux-kernel@...r.kernel.org
Subject:  Nasty regression from .27.7 to .27.8: idle samba goes crazy

Hi,

I just encountered a nasty symptom for the second time that has started to
occur after updating my home server from vanilla 2.6.27.7 to .8 (same
config).

A while after disconnecting a samba client, the smbd samba server
process goes crazy and consumes 100% CPU. From that time on it is
unkillable (kill -9 returns but the process continues to run). The only
recourse is reboot, which works without problem (i.e. unmounting the
served filesystems is apparently possible?). I tried to attach to the
process with gdb but that just hung.

The system is a generic old single-core P4 box with a single SATA drive,
Gentoo userland and Samba is 3.0.33 (in async mode). The kernel has no
patches or binary drivers. It has been rock solid before the update and
shows no other signs of weirdness in logs or otherwise. I downgraded to .7
for now and will see what happens, but since it worked before I am certain
that this is a regression in the .8 release.

The only commonality is a log entry by samba that seems to correlate with
both occurrences:

[2008/12/08 01:02:52, 0] lib/util_sock.c:read_data(534)
  read_data: read failure for 4 bytes to client 192.168.100.128. Error = No route to host

.128 is the Windows client machine (connected via a stable GigE link),
which I shut down pretty much exactly 30 minutes before that (any 30
minute timeouts in the kernel/network stack?). Both instances of these log
entries correlate with the CPU spikes which I noticed in my MRTG graphs.

Any suspects or ideas?

thanks
Holger

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/