Re: autofs4 module reference count

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2012-05-04 at 16:55 +0400, Michael Tokarev wrote:
> On 04.05.2012 16:48, Ian Kent wrote:
> > On Thu, 2012-05-03 at 09:32 +0400, Michael Tokarev wrote:
> >> Ping?  Any news on this?  Unfortunately I
> >> don't have much understanding in kernel
> >> internals to look at this...
> > 
> > I haven't looked at it yet.
> 
> Oh.  No problem, I just wanted to be sure if my email actually
> made to somewhere..  We all have our time constraints... :)
> 
> Especially now when the main issue with autofs has been fixed
> (in a very interesting way!), this refcount issue becomes much
> less urgent.  It was very annoying for me to have to reboot
> each time I wanted to try a new variant of autofs4.ko with
> another version of the fix.
> 
> > I don't think it is the module, most likely something elsewhere.
> > How have you established that the count is negative?
> 
> $ lsmod | grep auto
> autofs4                22422  2147483647
> 
> This is on my system with last fix from Linus, I wanted to
> check behavour of some other program with pre-fixed version
> but wasn't able to and had no time to reboot, and later was
> distracted by something else.
> 
> That happens on normal /etc/init.d/autofs stop.  When I kill
> the daemon manually with -9 and umount the filesystem, the
> usage count becomes 0 wich is how it should be.
> 
> Note that 2147483647 is not really -1, it is 0x7fffffff, so
> it might not be negative after all.  But this definitely
> prevents the module from being unloaded.

Right, but over the years I've done exactly what you describe, possibly,
thousands of times. It's curious that it suddenly starts happening like
this.

When I get some time I'll try and reproduce the problem.

> 
> Thank you!
> 
> /mjt


--
To unsubscribe from this list: send the line "unsubscribe autofs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux Ext4]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux