Bug 724920

Summary: Udev lost support for autoloading loop kernel module
Product: [Fedora] Fedora Reporter: Zdenek Kabelac <zkabelac>
Component: udevAssignee: udev-maint
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: harald, jonathan, kay, kzak, mbroz
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-21 05:57:21 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Zdenek Kabelac 2011-07-22 06:15:23 EDT
Description of problem:

It seems like someone decided that using  loop device as a kernel module is no longer supported in Fedora.  My kernel is build with loop device as kernel module - and after today's upgrade I no longer see  /dev/loop[0..7] on default boot.

Looking into  udev  git repo - I could see now:

commit c28cf5922cc6d9b2978e28d49509f3a1ba68cf61
Author: Harald Hoyer <harald@redhat.com>
Date:   Wed Jul 20 13:58:40 2011 +0200

"removed loop devices (should be compiled in the kernel)"

@@ -248,14 +248,6 @@ rm -rf $RPM_BUILD_ROOT
 %attr(0755,root,root) %dir %{_sysconfdir}/udev/rules.d/
 %attr(0755,root,root) %dir %{udev_scriptdir}/
 %attr(0755,root,root) %dir %{udev_scriptdir}/devices/
-%attr(640,root,disk) %dev(b,7,0)      %{udev_scriptdir}/devices/loop0
-%attr(640,root,disk) %dev(b,7,1)      %{udev_scriptdir}/devices/loop1
-%attr(640,root,disk) %dev(b,7,2)      %{udev_scriptdir}/devices/loop2
-%attr(640,root,disk) %dev(b,7,3)      %{udev_scriptdir}/devices/loop3
-%attr(640,root,disk) %dev(b,7,4)      %{udev_scriptdir}/devices/loop4
-%attr(640,root,disk) %dev(b,7,5)      %{udev_scriptdir}/devices/loop5
-%attr(640,root,disk) %dev(b,7,6)      %{udev_scriptdir}/devices/loop6
-%attr(640,root,disk) %dev(b,7,7)      %{udev_scriptdir}/devices/loop7
   

Who decided this - and why ?

How would I be able to freely change the amount of loop device in runtime if I would have this compiled in kernel ? (not to mentioning Fedora Rawhide kernels are extremely slow these days). With loop as a module I could easily reinsert module with different  'max_loop' parameter.

Also  /lib/module/kernel.x.y.z/modules.devname does not mention loop as on-demand module - thus I see the current idea of this removal as premature - and this change should be reverted. 

As a workaround I've added modprobe loop into my sysconfig dir.

Version-Release number of selected component (if applicable):
udev-172-2.fc16.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Kay Sievers 2011-07-22 06:48:56 EDT
If you run your own kernels, you can put the parameter in a
/etc/modprobe.d/ config file, and do the mknod loop0 in
/lib/udev/devices/ yourself.

This will load the module and create as many devices as specified
in the config.

Compiled-in loop can be configured on the kernel command line.

I'm currently trying to fix loop to support auto-loading
out-of-the-box, and support proper on-demand creation of loop
devices, so all that should be history pretty soon, if things
work out like planned.
Comment 2 Milan Broz 2011-07-22 07:14:05 EDT
(In reply to comment #1)
> I'm currently trying to fix loop to support auto-loading
> out-of-the-box, and support proper on-demand creation of loop
> devices, so all that should be history pretty soon, if things
> work out like planned.

That would be nice but note there are some magic loops hardcoded when searching for free loop devices which expects /dev/loop* exist. I am not sure why loop must behave differently here than other block devices though.  But it is reality.

Anyway, please keep loop module working with udev (no problem with minor config change like modprobe.d line, just please do not hardcode assuption that loop is compiled in kernel).

Some people are still using patched loop modules as well.
Comment 3 Kay Sievers 2011-07-24 19:19:31 EDT
(In reply to comment #2)
> Anyway, please keep loop module working with udev.

We can not safely create dead device nodes besides /dev/loop0, that's
why the hack in the spec file got removed. If loop devices are configured
to support partitions, they will look like:
  $ ls -l /dev/loop*
  brw-rw---- 1 root disk  7,   0 Jul 25 01:10 /dev/loop0
  brw-rw---- 1 root disk  7,  32 Jul 25 01:10 /dev/loop1
  brw-rw---- 1 root disk  7,  64 Jul 25 01:10 /dev/loop2

Nothing besides /dev/loop0 must ever be created by userspace, we can not
to that properly. Unconditionally created devices nodes, which are not
controlled by the kernel, just don't really work on today's systems.

I have a patch now that introduces /dev/loop-control now, and losetup will be
able to request new devices there. Also /sys/module/loop/parameters/min_loop
can be increased. Access of /dev/loop-control will trigger the auto-loading
of the loop module.
Comment 4 Kay Sievers 2011-07-26 08:04:37 EDT
Kernel patch for /dev/loop-control posted:
  https://lkml.org/lkml/2011/7/26/148

If things work out, we will make mount(8) and losetp(8) use the new
interface, and loop does not even be loaded before calling any of these
tools.
Comment 5 Milan Broz 2011-07-26 09:12:15 EDT
Thanks, I have patch for crypsetup as well, LOOP_CTL_GET_FREE works fine for me (and autoload of module too).
Comment 6 Zdenek Kabelac 2011-07-26 09:20:00 EDT
I should probably mention here when the  loop module is removed - the /dev/loop-control is removed.  IMHO it seems like udev  should not be removing nodes which have been created from modules.devname parsing - but I could be wrong here - it does not seem to be documented.  (The same issue happens with dm_mod removal - however lvm tools are able to go around when control device is missing.
Comment 7 Kay Sievers 2011-07-26 09:38:29 EDT
Right, it's a known limitation. If something decides to remove a module,
all nodes belonging to that module get removed by the kernel itself or
by udev. We could probably teach udev about it, but if the kernel has
created it we can not really do anything.

Udev creates the 'dead' autoload-nodes only at startup. Currently we
only support auto-loading the first time after bootup, but not after
manual module removal.

Does anything depend on removed modules, or does something else than
an admin calls rmmod? Removing modules is not really supported officially,
it's mainly a developer or debug tool, and should never be done by
anything automatically.
Comment 8 Zdenek Kabelac 2011-08-03 07:41:40 EDT
(In reply to comment #7)
> Right, it's a known limitation. If something decides to remove a module,
> all nodes belonging to that module get removed by the kernel itself or
> by udev. We could probably teach udev about it, but if the kernel has
> created it we can not really do anything.
> 
> Udev creates the 'dead' autoload-nodes only at startup. Currently we
> only support auto-loading the first time after bootup, but not after
> manual module removal.
> 
> Does anything depend on removed modules, or does something else than
> an admin calls rmmod? Removing modules is not really supported officially,
> it's mainly a developer or debug tool, and should never be done by
> anything automatically.

Well IMHO udev then 'kills' 'the good old' behaviour, when /dev contained static nodes and kernel module auto-loading was working well all the time.

With current udev implementation you get different behaviour from the boot time and from the runtime after the first module removal.

I know it's not the top urgent problem, but I would prefer, udev would keep the list of nodes it has created on the startup and would preserve such nodes on module unload.
Comment 9 Kay Sievers 2011-08-03 08:06:29 EDT
As said, we don't support module unload at the moment. If a user unloads a
module, he can not expect module auto-loading to work any more. He needs
to re-load it manually just like he unloaded it manually. Module unload
in general is not supported setup.

I know what you mean, it would be useful and less surprising, but it isn't
entirely trivial to make udev preserve the static nodes, because we don't
have any, and we can not create a udev database entry for these nodes
before the device is known by the kernel.

We could maybe add hacks like adding the 'sticky' bit to the device node
at udev startup, and skip the removal of all file with the sticky bit set. :)
Comment 10 Kay Sievers 2011-08-14 13:25:52 EDT
Works now in udev-git. We set the 'sticky' bit on these nodes, and
'remove' events will not delete the nodes:
  # ls -l /dev/loop*; modprobe loop; rmmod loop; ls -l /dev/loop*;
  crw------T 1 root root 10, 237 Aug 14 19:03 /dev/loop-control
  crw------T 1 root root 10, 237 Aug 14 19:04 /dev/loop-control
Comment 11 Fedora Admin XMLRPC Client 2011-10-20 12:08:01 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 12 Fedora Admin XMLRPC Client 2011-10-20 12:09:59 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 13 Fedora Admin XMLRPC Client 2011-10-20 12:12:28 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 14 Fedora Admin XMLRPC Client 2011-10-20 12:16:55 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.