Corey Hickey wrote:
> I just tried the Debian 2.6.26-1-686 kernel, and the slmodemd process
> was killable, but the modem didn't work: it kept responding "NO CARRIER"
> immediately after dialing.
[cut]
> I'm going to try to figure out what it is in my particular kernel
> configuration that's causing slmodemd to be unkillable, but that's going
> to take a while. Hang in there...
Ok, I have it narrowed down to CONFIG_RT_GROUP_SCHED. With this option
disabled, slmodemd is killable. The unpatched version still doesn't work
for me ("NO CARRIER" as described above), but I'll get back to that. I
think it's a related but separate problem.
As for CONFIG_RT_GROUP_SCHED:
----------------------------------------------------------------------
Group scheduling for SCHED_RR/FIFO
This feature lets you explicitly allocate real CPU bandwidth
to users or control groups (depending on the "Basis for grouping tasks"
setting below. If enabled, it will also make it impossible to
schedule realtime tasks for non-root users until you allocate
realtime bandwidth for them.
See Documentation/sched-rt-group.txt for more information.
----------------------------------------------------------------------
By default, the kernel doesn't allow non-root users to have an CPU time
for running realtime tasks. slmodemd is setting itself to SCHED_FIFO,
changing its user to Slmodemd, and then being denied any CPU time. The
kernel isn't supposed to allow processes to set themselves to SCHED_FIFO
if the user don't have any realtime CPU "bandwidth".
I can allocate "bandwidth" to the Slmodemd user and make slmodemd
killable. Alternatively, I can just use "slmodemd -n -a" to avoid
realtime scheduling, now that I know what the problem is.
I'm sure this problem could be worked around somehow in the slmodemd
code, but I think it would be nicer if the kernel behaved differently. I
found a similar problem reported about a year ago, which appears to be
fixed before the 2.6.26 kernel I tested.
bug report: http://lkml.org/lkml/2008/1/31/490
test case: http://lkml.org/lkml/2008/2/5/535
...however, the problem I'm having with slmodemd is subtly different. If
I understand the bug reported above, it relates to a process that is
either running setuid root or with an RLIMIT_RTPRIO value that allows it
to set itself realtime. slmodemd, however, sets itself realtime while
running as root, then changes to a regular user, hence bypassing the
checks added in response to that bug report.
I guess I'll try to bring this to the kernel developers' attention tomorrow.
-Corey
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
