CIFS has a softdep dependency generated by kmod in /lib/modules/*/modules.softdeps that goes like this:

softdep cifs gcm
softdep cifs ccm
softdep cifs aead2
softdep cifs sha512
softdep cifs sha256
softdep cifs cmac
softdep cifs aes
softdep cifs nls
softdep cifs md5
softdep cifs hmac
softdep cifs ecb

Looking at the source code in fs/cifs/cifsfs.c or fs/smb/client/cifsfs.c (kernel version 6.4 or newer), pre: nor post: is not specified.


My question is how is this interpreted by modprobe or any tool that might parse modules.softdep? Should it just be interpreted the same as having pre:?

In fs/smb/server/server.c (6.4), the dependencies are declared with pre: hinting the ones in client/cifs/cifsfs.c might have been intended to be pre::

MODULE_SOFTDEP("pre: ecb");
MODULE_SOFTDEP("pre: hmac");
MODULE_SOFTDEP("pre: md5");
MODULE_SOFTDEP("pre: nls");
MODULE_SOFTDEP("pre: aes");
MODULE_SOFTDEP("pre: cmac");
MODULE_SOFTDEP("pre: sha256");
MODULE_SOFTDEP("pre: sha512");
MODULE_SOFTDEP("pre: aead2");
MODULE_SOFTDEP("pre: ccm");
MODULE_SOFTDEP("pre: gcm");
MODULE_SOFTDEP("pre: crc32");

But I want a definite answer to this. The code in libkmod-config.c does not make it any apparent. It seems to just ignore it, but that wouldn't make sense.

  • A few tips to those who might want to look into this: it might be intended to just show that cifs has those stuff as soft dependencies but aren't to be loaded in the manner of modprobe a b c d e where c is cifs and a b are "pre" dependencies and d e are "post" dependencies. So doing a modprobe c only does modprobe c. There's also a possibility that those modules mentioned are expected to be builtin. What still just majorly confuses me is how would that list even be helpful in anything.
    – konsolebox
    Aug 15, 2023 at 7:41
  • something to shed light on it: git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/…
    – A.B
    Aug 17, 2023 at 19:46
  • @A.B Couldn't open the referred bug's page because of required authority. I'll just take it as a deliberate hack to prevent existing buggy modprobe installs from trying to load a builtin. Please convert your comment to an answer so I can give you the bounty.
    – konsolebox
    Aug 18, 2023 at 3:39
  • Done. But hopefully somebody will come with a better answer.
    – A.B
    Aug 18, 2023 at 6:56

1 Answer 1


This was introduced in this commit probably around kernel 5.5:

cifs: don't use 'pre:' for MODULE_SOFTDEP

It can cause
to fail with
modprobe: FATAL: Module is builtin.

RHBZ: 1767094

However, this bug is not publicly available.

Testing by creating this file:


softdep cifs pre: lzo xt_LED

where in my kernel lzo is built-in (as seen in /lib/modules/$(uname -r)/modules.builtin) and xt_LED is a module doesn't fail: modprobe cifs then loads xt_LED + cifs. So I wonder if this was a bug that was fixed and left an other bug around (without pre: or post: anywhere such softdep line has no effect) or if there's something else to know (a bit difficult when the reason is not available).

  • I wonder now if the error is not about when cifs is builtin and would pre-depends on modules instead. But then this wouldn't have to be triggered by modprobe. Can't test this without additional efforts.
    – A.B
    Aug 18, 2023 at 7:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .