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] [day] [month] [year] [list]
Message-ID: <52A830BE.8080604@linutronix.de>
Date:	Wed, 11 Dec 2013 10:30:38 +0100
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	Greg KH <gregkh@...uxfoundation.org>
CC:	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
	jic23@...nel.org, lars@...afoo.de
Subject: Re: [PATCH v2] debugobject: add support for kref

On 12/11/2013 07:45 AM, Greg KH wrote:
> I need an ack from Thomas or some other debugobjects-knowledgable
> developer before I can take this...

I have a v3 which I haven't posted yet. Basically the whole thing seems
to work. "Seems" means that I get a bunch of backtraces which I haven't
checked to see if it is a kref-accounting bug (something that should be
fixed) or something that is correct but kref isn't used properly.

One example is serial port init via tty_port_init(): It initializes
&port->kref. To use that kref you need to use tty_port_get()/put() and
more importantly dynamically allocate tty_port _or_ provide
port->ops->destruct callback. This seems not be done by everyone, for
instance gs_port_alloc() [0]. The question is this a bug and should be
fixed (and kref's debugobject is right here) or it is "legal" behavior.

I get another backtrace on "rmmod sg" which shows
ODEBUG: free active (active state 0) object type: kref hint:
kset_init+0xe/0x30
[<c112fec8>] kfree+0x128/0x280
[<c13784c2>] ? class_release+0x22/0x30
[<c13784c2>] class_release+0x22/0x30
[<c12da3bd>] kobject_cleanup+0x2d/0x70
[<c12da2c7>] kobject_put+0x67/0xa0
[<c12da34f>] kset_unregister+0xf/0x20
[<c13787b3>] class_destroy+0x23/0x30
[<f850ee62>] exit_sg+0x17/0x3c [sg]

so it is triggered by class_destory() and I haven't have the time check
what is wrong here.

Based on this I would like to know what could be the best way forward
here. Post v3 and work on this backtraces before it gets merged or
after it gets merged.

[0] drivers/usb/gadget/u_serial.c

> thanks,
> 
> greg k-h
> 
Sebastian
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ