Linux-kernel mailing list archive 2000-07,: Re: One more boobytrap needed for 2.2.15pre ?

# Re: One more boobytrap needed for 2.2.15pre ?

Manfred Spraul (manfreds@colorfullife.com)
Wed, 16 Feb 2000 09:20:00 +0100

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Alex Buell: "Re: HARDWARE HELL - POSSIBLE LINUX BUG AND/OR HARDWARE FAILURE ?"
- Previous message: H. Peter Anvin: "Re: [patch-2.3.46-p2] P6 microcode update support"
- Maybe in reply to: Andris Pavenis: "One more boobytrap needed for 2.2.15pre ?"
- Next in thread: Manfred Spraul: "Re: One more boobytrap needed for 2.2.15pre ?"

This is a multi-part message in MIME format.
--------------3F400B3376F161C01B0C0013
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alan Cox wrote:
>
> > Ok, but now the question is: which interrupt changes current->state? Perhaps
> > a special boobytrap in the interrupt handlers could detect that?
>
> Numerous interrupt handlers change task->state. Every interrupt handler that
> does a wake_up_interruptible() for example. It could easily be 'current'
>
I've written such a bobbytrap, it's attached. I'm using it right now,
but as I've expected, I receive no messages. Either a specific hardware
driver calls "__set_current_state()/ set_current_state()/
current->state==NULL", or my theory is wrong.

Andris, could you apply my patch, and check if it reports any messages?

    --
    	Manfred
    --------------3F400B3376F161C01B0C0013
    Content-Type: text/plain; charset=us-ascii;
     name="patch-b"
    Content-Transfer-Encoding: 7bit
    Content-Disposition: inline;
     filename="patch-b"

    --- 2.2/kernel/sched.c	Tue Jan  4 22:23:55 2000
    +++ build-2.2/kernel/sched.c	Wed Feb 16 08:37:23 2000
    @@ -441,6 +441,7 @@
      * "current->state = TASK_RUNNING" to mark yourself runnable
      * without the overhead of this.
      */
    +extern unsigned char woken[NR_CPUS];
     void wake_up_process(struct task_struct * p)
     {
     	unsigned long flags;
    @@ -453,6 +454,8 @@
     	if (p->next_run)
     		goto out;
     	add_to_runqueue(p);
    +	if(p==current)
    +		woken[smp_processor_id()] = 1;
     	spin_unlock_irqrestore(&runqueue_lock, flags);

     	reschedule_idle(p);
    --- 2.2/arch/i386/kernel/irq.c	Wed Oct 20 16:59:36 1999
    +++ build-2.2/arch/i386/kernel/irq.c	Wed Feb 16 08:48:49 2000
    @@ -803,6 +803,7 @@
      * SMP cross-CPU interrupts have their own specific
      * handlers).
      */
    +unsigned char woken[NR_CPUS];
     asmlinkage void do_IRQ(struct pt_regs regs)
     {
     	/*
    @@ -817,11 +818,24 @@
     	 */
     	int irq = regs.orig_eax & 0xff; /* subtle, see irq.h */
     	int cpu = smp_processor_id();
    +	unsigned long state;
    +	int checking = 0;
    +	woken[cpu]=0;
    +	state = current->state;

     	kstat.irqs[cpu][irq]++;
     	irq_desc[irq].handler->handle(irq, &regs);

    -	/*
    +	if(woken[cpu]==0) {
    +		if(current->state != state) {
    +static int limit=20;
    +			if(limit>0) {
    +				limit--;
    +				printk("do_IRQ: bad state change in irq %d.\n",irq);
    +			}
    +		}
    +		current->state = state;
    +	}	/*
     	 * This should be conditional: we should really get
     	 * a return code from the irq handler to tell us
     	 * whether the handler wants us to do software bottom
    @@ -830,6 +844,16 @@
     	if (1) {
     		if (bh_active & bh_mask)
     			do_bottom_half();
    +	}
    +	if(woken[cpu]==0) {
    +		if(current->state != state) {
    +static int limit=20;
    +			if(limit>0) {
    +				limit--;
    +				printk("do_IRQ: bad state change in bh.\n");
    +			}
    +		}
    +		current->state = state;
     	}
     }

    --------------3F400B3376F161C01B0C0013--

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

- Next message: Alex Buell: "Re: HARDWARE HELL - POSSIBLE LINUX BUG AND/OR HARDWARE FAILURE ?"
- Previous message: H. Peter Anvin: "Re: [patch-2.3.46-p2] P6 microcode update support"
- Maybe in reply to: Andris Pavenis: "One more boobytrap needed for 2.2.15pre ?"
- Next in thread: Manfred Spraul: "Re: One more boobytrap needed for 2.2.15pre ?"