Hi Benjamin,
On Wed, 2013-07-17 at 19:02 +0100, Benjamin ESTRABAUD wrote:
> Hi,
>
> I'm having a very strange issue after updating Linux to 3.9.10 or
> 3.10.1: Whenever I call rtslib's FabricModule "load" method on iSCSI or
> loopback fabrics, when running the "_create_in_cfs_ine('any')" step, I
> get the following exceptions:
>
> [Errno 22] Invalid argument: '/sys/kernel/config/target/iscsi'
> [Errno 22] Invalid argument: '/sys/kernel/config/target/loopback'
>
> and the following kernel trace:
>
> [ 1678.147454] request_module() failed for iscsi_target_mod.ko: -2
> [ 1678.153769] request_module() failed for tcm_loop.ko: -2
>
Mmmm, I've not seen this one before..
> All other fabric modules are loaded correctly:
>
> # ls /sys/kernel/config/target/
> core fc qla2xxx version
>
> And when running the "load_module" step from the "load" method, all
> modules including the iSCSI and loopback ones run successfully:
>
> tcm_fc 12826 - - Live 0xc1f26000
> tcm_loop 9849 - - Live 0xc1e3e000
> tcm_qla2xxx 14904 - - Live 0xc1df6000
> iscsi_target_mod 168077 - - Live 0xc1d6b000
> target_core_mod 174585 - - Live 0xc1953000
> fcoe 16888 - - Live 0xc1613000
> libfcoe 44385 - - Live 0xc15ba000
> libfc 91365 - - Live 0xc14f7000
>
So it looks like your using busybox userspace, right..?
> Looking at the error code it seems that "request_module" is given the
> wrong module name or something (maybe they have a unique id in them too)
> since "-2" should in theory correspond to "ENOENT". What I don't get is
> that the module is already loaded. Is this function used to request
> access to a running module?
After unloading all of the target related modules, what does the
following commands do..?
modprobe target_core_mod
mkdir -p /sys/kernel/config/target/iscsi
>
> I've tried on a vanilla kernel 3.10.1 from the 3.10.y branch
> (cb5d8be972cfbea114ea56fd63ed5ce1644863df) with the default config
> (except for all of the TCM modules and the FCOE ones enabled).
>
> This kernel was running on an Intel platform with an Intel MB and a Xeon
> CPU, 2GB of RAM.
> All the kernels tested were 32-bit ones.
>
> The config can be looked up here:
>
> https://www.dropbox.com/s/5wjqka859y6q9r2/linux-3.10.config
>
> The differences between the default kernel config and the one I used are
> here:
>
> http://bpaste.net/show/7zubjJeL3xEu7wHU2qhu/
>
Nothing looks out of the ordinary here.
>
> The issue does not happen when running Ubuntu 13.10 (Saucy Salamander)
> with an updated kernel from
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10.1-saucy/
> but I don't know how custom these are.
>
> Do you have any idea where the problem could come from? We have to move
> to a newer version of the kernel to avail the fixes from LIO and other
> drivers but we're trying to avoid moving to 3.7.y or 3.8.y as they are
> currently being EOL'd.
>
No idea at the moment, but I would look in the direction of busybox
running into an issue with request_module()'s usermode helper. Eg: I
suspect that any request_module() call in the kernel will end up failing
with your current setup.
FYI, these two request_module() calls in target_core_configfs.c are only
required by legacy user-space code, so if your using rtslib to load
modules + populate /sys/kernel/config/target/$FABRIC, you should be able
to safely (as a work-around), disable the two request_module() calls
within target_core_register_fabric().
--nab
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
