linux-kernel - Re: [PATCH 3/6] ipmi: use a tasklet for handling received messages

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

Message-ID: <4F2C3D25.8040909@mvista.com>
Date:	Fri, 03 Feb 2012 14:01:41 -0600
From:	Corey Minyard <cminyard@...sta.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Linux Kernel <linux-kernel@...r.kernel.org>,
	OpenIPMI Developers <openipmi-developer@...ts.sourceforge.net>
Subject: Re: [PATCH 3/6] ipmi: use a tasklet for handling received messages

On 02/03/2012 01:44 PM, Andrew Morton wrote:
> On Fri, 03 Feb 2012 09:47:56 -0600
> Corey Minyard<cminyard@...sta.com>  wrote:
>
>> The IPMI driver would release a lock, deliver a message, then relock.
>> This is obviously ugly, and this patch converts the message handler
>> interface to use a tasklet to schedule work.  This lets the receive
>> handler be called from an interrupt handler with interrupts enabled.
>>
>> ...
>>
>> +/*
>> + * If there are messages in the queue or pretimeouts, handle them.
>> + */
>> +static void handle_new_recv_msgs(ipmi_smi_t intf)
>> +{
>> +	struct ipmi_smi_msg  *smi_msg;
>> +	unsigned long        flags = 0;
>> +	int                  rv;
>> +	int                  run_to_completion = intf->run_to_completion;
>> +
>> +	/* See if any waiting messages need to be processed. */
>> +	if (!run_to_completion)
>> +		spin_lock_irqsave(&intf->waiting_msgs_lock, flags);
>> +	while (!list_empty(&intf->waiting_msgs)) {
>> +		smi_msg = list_entry(intf->waiting_msgs.next,
>> +				     struct ipmi_smi_msg, link);
>> +		list_del(&smi_msg->link);
>> +		if (!run_to_completion)
>> +			spin_unlock_irqrestore(&intf->waiting_msgs_lock, flags);
> Yikes, what's going on here?  How is the list protected if the spinlock
> isn't taken?
>
> I went to the comment over ipmi_smi.run_to_completion but it doesn't
> explain how it governs the locking strategy at all.  If there's some
> other way in which the reader is supposed to grok IPMI locking, please
> clue me in ;)
>
The "run_to_completion" mode is designed to run at panic time so that 
the watchdog timer can be extended and panic information can be stored 
in the IPMI event log.  In that case locks are irrelevant and can cause 
hangs, so they are skipped.

This is documented a little better in ipmi_si_intf.c, but you are right, 
it's not terribly complete.

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