| title: | Re RFC 02 22 configfs Add struct configfs |
|
On Fri, 2010-09-10 at 08:28 -0700, Joel Becker wrote:
On Wed, Sep 08, 2010 at 01:53:27PM -0700, Nicholas A. Bellinger wrote:
On Wed, 2010-09-08 at 12:26 -0700, Joel Becker wrote:
So after re-running this again, I was a bit off about where the OOOPs is
actually occuring. So, the OOPs does not occur during in the simple
example here with the first unlink(2):
unlink sub_child/group1/src_0/src_link
but rather after the second unlink(2) is called after the first for
src_link occurs:
unlink sub_child/group2/dst_0/dst_link
So back to the OOPs with the current TCM code example, on v2.6.36-rc3
this actually triggers a SLUB warning "Object already free" from inside
of TCM code. This is attributed to the releasing a specific LUN ACLs
from the second unlink(2)s struct config_item_operations- drop_link(),
that the first unlink had already released. This is because the first
unlink(2) will currently assume that the remaining LUN ACLs are safe to
release because, it still assumes the disabled check_link call.
The trivial solution is to refcount your ACLs. You get both
allow_link() calls, so you should be able to increment a counter there,
and then drop them when the last drop_link() call is made. That will
keep your consumer structures around until all links are exhausted.
Hi Joel,
So I am a bit confused wrt to this last response.. The - check_link()
patch and its use in the fabric independent code within
target_core_fabric_configfs.c does exactly this for the MappedLUN
symlink case, eg: requires the consumer to do the allow_link() +
drop_link() refcounting, and add the
API check into fs/configfs/symlink.c:configfs_unlink()
Is there another form of configfs consumer refcounting that you had in
mind beyond using an atomic_t for this with - check_link() here..?
rel="nofollow" git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=blob;f=drivers/target/target_core_fabric_configfs.c;hb=refs/heads/lio-4.0#l675 git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=blob;f=drivers/target/target_core_fabric_configfs.c;hb=refs/heads/lio-4.0#l675
So beyond a configfs consumer solution, what do you think about checking
for the sub_child/group2/dst_0/dst_link style of symlink
in fs/configfs/symlink.c:configfs_symlink() in order to add some form of
internal refcount when the symlink source is within the same consumer
LKM, but outside of the parent struct config_group..?
This would involve the conversion of fs/configfs/symlink.c:
configfs_unlink() path to check for the existence of this internal
refcount and returning -EPERM when any sub_child/group2/dst_0/dst_link
exist when unlink sub_child/group1/src_0/src_link is attempted.
What do you think..?
Thanks!
--nab
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at rel="nofollow" vger.kernel.org/majordomo-info.html vger.kernel.org/majordomo-info.html
|
