linux-kernel - CONFIG_PREEMPT and real time kthreads

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 18 Jan 2008 12:03:32 -0600
From:	Miles Bintz <miles@...tz.net>
To:	linux-kernel@...r.kernel.org
Subject: CONFIG_PREEMPT and real time kthreads

I've been trying to find information about the effects of CONFIG_PREEMPT 
on real time kernel threads.   The description of CONFIG_PREEMPT says 
"...allow preemption of user processes that are executing system 
calls...".  Most of the discussion seems to revolve around the 
modification of the locking implementation.

Suppose:  I have two or more kernel threads using the SCHED_FIFO policy 
and they have differing priorities.  Lets pretend the high priority 
kthread is doing a down_interruptible() and the low priority kthread is 
cheerfully executing.  An interrupt fires and does an up() enabling the 
high priority kthread....  Heck, lets say there's no interrupt and the 
low priority kthread does the up().... Without compiling my kernel with 
CONFIG_PREEMPT=y, will the high priority task get scheduled during the 
up()?  Or will the low priority task run until it yields?   In general, 
I'm assuming the scheduler will always reschedule on return from 
interrupts and after the release of a synchronization primitive?

       Miles

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/