linux-kernel - Re: How to tell whether a struct file is held by a process?

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 22 May 2009 10:53:13 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Kyle Moffett <kyle@...fetthome.net>
Cc:	Kay Sievers <kay.sievers@...y.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Al Viro <viro@...iv.linux.org.uk>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: How to tell whether a struct file is held by a process?

> the OP), is to make there be a global "prevent kernel drivers from
> autobinding to  devices on his port" flag, and manage the rest with
> lockfiles in userspace.

Your "practical example" seems to bear no relation to the other stuff,
its a separate topic altogether.

Yes a "don't probe this port" would make sense. The fact kernel space
probes the USB devices by default like the fact we probe partitions by
default and scan scsi busses by default are all really mistakes inherited
from traditional OS designs which also mess up virtualisation the same
way.

So add a skip_ports= facility to the usb core code (or a general
auto_enumerate=0 and a udev interface to trigger scanning so your udev
rules can enumerate just the ports you want). That is probably cleaner
because it makes the identification of ports rather cleaner and clearer.

Alan
--
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/