Project

General

Profile

Bug #4122

do_sysfile_cmd colon-separates the module path, and then we can't parse it

Added by Rich Lowe about 6 years ago. Updated about 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
kernel
Start date:
2013-09-09
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:

Description

I'm a bit tentative about this, because it seems such an exceptionally silly and longstanding bug.

The kernel module path is a space separated string. However, 'moddir' in /etc/system creates a colon-separated path. Which we'll then, it seems, treat as a single, always invalid, entry. That seems to mean that any /etc/system file with a 'moddir' entry creates a brick.

History

#1

Updated by Rich Lowe about 6 years ago

We do at least somewhat support a colon-separated default_path, in for eg kobj_open_path().

I haven't yet found where we're botching this (though I've not looked hard). I can confirm though if you let /etc/system set a modpath with :'s in it, we hang continually trying to load cl_bootstrap from /misc (note the actual /misc, not a modpath relative /misc). If you replace the colons in the /etc/system generated moddpath with spaces, we boot.

#2

Updated by Rich Lowe about 6 years ago

  • Assignee set to Rich Lowe
#3

Updated by Rich Lowe about 6 years ago

  • Subject changed from do_sysfile_cmd colon-separates the module path to do_sysfile_cmd colon-separates the module path, and then we can't parse it

kobj_open_path() only half supports colons as separators, it'll walk up-to the next colon, to form each element, but it'll only consume trailing spaces, not colons, so we go:

/foo:/bar:/baz -->
      :/bar:/baz -->
      :/bar:/baz

Thus why we're trying to load from /misc not /something/misc, we're seeing a null element in the path.

#4

Updated by Rich Lowe about 6 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100
  • Tags deleted (needs-triage)

Resolved in b2940a7

Also available in: Atom PDF