linux-kernel - Re: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct kobject source.

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 17 Oct 2008 10:39:59 -0700
From:	Greg KH <greg@...ah.com>
To:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
Cc:	Joel Becker <joel.becker@...cle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	"Linux-iSCSI.org Target Dev" 
	<linux-iscsi-target-dev@...glegroups.com>,
	SCST-Devel <scst-devel@...ts.sourceforge.net>,
	Alan Stern <stern@...land.harvard.edu>,
	Andrew Morton <akpm@...l.org>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH] [ConfigFS]: Allow symbolic links from a SysFS struct
	kobject source.

On Fri, Oct 17, 2008 at 01:22:18AM -0700, Nicholas A. Bellinger wrote:
> On Fri, 2008-10-17 at 00:44 -0700, Greg KH wrote:
> > On Thu, Oct 16, 2008 at 11:55:55PM -0700, Nicholas A. Bellinger wrote:
> > > Hi Joel, Greg and Co,
> > > 
> > > Here is the the first working code for allowing configfs to handle
> > > symlinks from sysfs struct kobject based code.  Here is the commit:
> > > passing struct kobject into generic target_core_mod subsystem plugins
> > > for locating struct block_device and struct scsi_device..  
> > 
> > Um, no.
> > 
> > You are trying to create symlinks dynamically across superblocks and
> > mount points?  As one of your #warning states, this isn't possible to do
> > correctly, nor is it even a good idea.
> > 
> > So I'd have to reject this patch, sorry.
> > 
> > What is the problem you are attempting to solve here?
> > 
> 
> So, the generic target_core_mod engine that lives
> under /sys/kernel/config/target/core needs a method to locate struct
> block_device and struct scsi_device for access via bio_submit() and
> scsi_execute_() respectively.

Then just pass the "name" of the block device into a configfs file,
nothing more is needed, right?

> Originally, target_core_mod used key echoed through configfs attributes
> like so:
> 
> export TARGET=/sys/kernel/config/target/core/
> 
> # Create $STORAGE_OBJECT of type Linux/BLOCK in generic target_core_mod
> mkdir -p $TARGET/iblock_0/lvm_test0
> # OLD METHOD to reference struct block_device
> echo iblock_major=254,iblock_minor=2 > $TARGET/iblock_0/lvm_test0/control
> echo 1 > $TARGET/iblock_0/lvm_test0/enable
> # NEW METHOD using sysfs ->configfs symlinks to reference struct block_device
> ln -s /sys/block/dm-2 $TARGET/iblock_0/lvm_test0/dm-2

No, you can't do a symlink across superblocks and expect it to work like
you are thinking internally.

> The other point is that since configfs is based on sysfs code, it only
> makes sense to provide a API through configfs to take advantage of
> kernel data structures that can be referenced using wrappers to
> container_of() in include/linux/ in a common way.

No, just because configfs looks like sysfs internally, does not mean
they are related in any manner.  We have been down this argument many
times in the past, please don't bring it up again, it has no bearing on
this at all.

thanks,

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