linux-kernel - [PATCH 000/003] Attempt to cope with device changes and delayed kobject deallocation

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:	Tue, 19 May 2015 16:13:09 +0100
From:	Richard Watts <rrw@...esim.co.uk>
To:	linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org
Subject: [PATCH 000/003] Attempt to cope with device changes and delayed kobject
 deallocation

Sometimes (eg. when a ttyACM device undergoes a usb reset) we get
into the situation where we are destroying and recreating a device
object (specifically, the tty representing the ttyACM device)
very quickly.

When CONFIG_DEBUG_KOBJECT_RELEASE=y, kobject release is delayed
and this allows the new ttyACM0 sysfs object to be linked to the
old (zero-referenced) tty sysfs object.

That object is then destroyed by the delayed kobject release and
this leads to an oops.

This patchset avoids that oops by:

  - using kref_get_unless_zero() to obtain the parent object.
  - inserting some code into sysfs_create_dir() to stop it
     complaining about duplicate directory names if the
     name we are a duplicate of has a zero reference count.

This looks like a pretty grotty way to get around it to me,
but perhaps it will prompt some discussion of what the right
way to fix this is (or indeed if we should simply leave it be
and have spurious oopses when CONFIG_DEBUG_KOBJECT_RELEASE=y).

Comments,  brickbats, etc. very welcome,

Patch against e26081808edadfd257c6c9d81014e3b25e9a6118
(master of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git )

Richard.
--
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/