linux-kernel - Re: [Question] Hooks for scheduler tracing (CFS)

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46A8DDD4.9090600@us.ibm.com>
Date:	Thu, 26 Jul 2007 10:45:56 -0700
From:	"David J. Wilder" <dwilder@...ibm.com>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
CC:	Ingo Molnar <mingo@...e.hu>, Ankita Garg <ankita@...ibm.com>,
	Arjan van de Ven <arjan@...radead.org>, linux@...mer.net,
	LKML <linux-kernel@...r.kernel.org>,
	RT-Users <linux-rt-users@...r.kernel.org>,
	zanussi@...ux.vnet.ibm.com
Subject: Re: [Question] Hooks for scheduler tracing (CFS)


> I guess they might have to switch to such an asynchronous delivery
> system if they want to do this properly. Simply put, your polling
> solution is exactly what I do, but I check a flag set by the writer
> instead of waking up the readers unconditionally.
>
> Mathieu
>   

Ingo's solution could call waitqueue_active() inside wakeup_readers() to 
determine if there are waiters. Right?

>   
>> 	Ingo
>>
>> ------------------------------------->
>> Subject: relay: fix timer madness
>> From: Ingo Molnar <mingo@...e.hu>
>>
>> remove timer calls (!!!) from deep within the tracing infrastructure.
>> This was totally bogus code that can cause lockups and worse.
>> Poll the buffer every 2 jiffies for now.
>>
>> Signed-off-by: Ingo Molnar <mingo@...e.hu>
>> ---
>>  kernel/relay.c |   14 +++++---------
>>  1 file changed, 5 insertions(+), 9 deletions(-)
>>
>> Index: linux-rt-rebase.q/kernel/relay.c
>> ===================================================================
>> --- linux-rt-rebase.q.orig/kernel/relay.c
>> +++ linux-rt-rebase.q/kernel/relay.c
>> @@ -319,6 +319,10 @@ static void wakeup_readers(unsigned long
>>  {
>>  	struct rchan_buf *buf = (struct rchan_buf *)data;
>>  	wake_up_interruptible(&buf->read_wait);
>> +	/*
>> +	 * Stupid polling for now:
>> +	 */
>> +	mod_timer(&buf->timer, jiffies + 1);
>>  }
>>  
>>  /**
>> @@ -336,6 +340,7 @@ static void __relay_reset(struct rchan_b
>>  		init_waitqueue_head(&buf->read_wait);
>>  		kref_init(&buf->kref);
>>  		setup_timer(&buf->timer, wakeup_readers, (unsigned long)buf);
>> +		mod_timer(&buf->timer, jiffies + 1);
>>  	} else
>>  		del_timer_sync(&buf->timer);
>>  
>> @@ -604,15 +609,6 @@ size_t relay_switch_subbuf(struct rchan_
>>  		buf->subbufs_produced++;
>>  		buf->dentry->d_inode->i_size += buf->chan->subbuf_size -
>>  			buf->padding[old_subbuf];
>> -		smp_mb();
>> -		if (waitqueue_active(&buf->read_wait))
>> -			/*
>> -			 * Calling wake_up_interruptible() from here
>> -			 * will deadlock if we happen to be logging
>> -			 * from the scheduler (trying to re-grab
>> -			 * rq->lock), so defer it.
>> -			 */
>> -			__mod_timer(&buf->timer, jiffies + 1);
>>  	}
>>  
>>  	old = buf->data;
>>     
>
>   

-
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/