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:	Tue, 9 Sep 2008 12:28:45 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Elias Oltmanns <eo@...ensachen.de>
Cc:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org
Subject: Re: Block: Trouble with kobject initialisation for blk_cmd_filter

On Fri, Sep 05 2008, Elias Oltmanns wrote:
> Hi all,
> 
> current usage of the kobject in struct blk_cmd_filter is flawed. Doing
> # modprobe -r sd-mod && modprobe sd-mod
> while, for instance, a usb-stick is plugged in currently results in
> nasty warnings and a dump_stack(). Since blk_cmd_filter is embedded in
> struct request_queue, I don't see the need for a kobject anyway. What
> about the much simpler option of a struct attribute_group in this
> particular case?
> 
> This would imply that the cmd_filter subdirectory would appear under
> sda/queue/ rather than sda/ (which is probably the right place) but,
> alas, we have to keep compatibility in mind. So I've made some changes
> to sysfs along the way in order to provide a legacy symlink. I'd have to
> seperate these two changes for submission but I wanted to know your
> opinion about it all first.
> 
> Thinking about it now makes me wonder whether this is too much for a rc
> patch and whether we should just allocate the struct blk_cmd_filter
> dynamically and have done with it. Anyway, tell me what you think.

I think this patch is a step in the right direction, lets get rid of
that pesky kobject just for the cmdfilter. Can you resend the patch
_without_ the sysfs changes and link support? We haven't released a
kernel with cmd filter support yet, so we can change the location still
and not have to worry about compatability.

-- 
Jens Axboe

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