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]
Date:	Fri, 3 Feb 2012 11:44:14 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Corey Minyard <cminyard@...sta.com>
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 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 ;)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ