linux-kernel - Re: 2.6.23-mm1

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071022124642.340ff067@bree.surriel.com>
Date:	Mon, 22 Oct 2007 12:46:42 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Ian Kent <raven@...maw.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.23-mm1 - autofs broken

On Mon, 22 Oct 2007 11:45:19 +0800
Ian Kent <raven@...maw.net> wrote:

> > Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent cache
> > rwlock lock failed
> 
> This is quite strange, normally it should never fail and, in all the
> time version 5 has been available the maximum number of read locks has
> never been exceeded.
> 
> Is there anything unusual going on like a server down causing autofs
> to issue a number of mounts that are all waiting to time out?

Not that I know.  If I reboot the system into 2.6.23 or 2.6.23-git,
things work just fine though.  That makes me think the server is not
the issue.
 
> > Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error:
> > 11 at 65 in cache.c
> 
> Mmm .. if this is a genuine autofs issue maybe I need to handle EAGAIN
> returns but that would mean blocking which probably isn't good and I'd
> rather not if we can avoid it.

I do not know if this an autofs issue or the result of something
else in 2.6.23-mm1.

> > I am not sure if this is due to autofs changes or changes in some
> > other code that was merged.  If you can think of any suspicious
> > change that I should test, please let me know.
> > 
> 
> Is there anything in the log, an autofs4 kernel trace perhaps?

Nope, the only two lines that I found in the log are above...

Nothing in dmesg either.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
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/