From: Hartley Sweeten <HartleyS@visionengravers.com>
To: Ian Abbott <abbotti@mev.co.uk>,
        "driverdev-devel@linuxdriverproject.org" 
	<driverdev-devel@linuxdriverproject.org>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 4/7] staging: comedi: don't allow read() on async
 command set up for "write"
Thread-Topic: [PATCH 4/7] staging: comedi: don't allow read() on async
 command set up for "write"
Thread-Index: AQHP9D8MkQ4h3yYEcUmBaoU/Io570pxI7omAgACeMID//4rPcA==
Date: Thu, 30 Oct 2014 20:45:53 +0000
Message-ID: <DC148C5AA1CEBA4E87973D432B1C2D8826017050@P3PWEX4MB008.ex4.secureserver.net>
References: <1414672952-1587-1-git-send-email-abbotti@mev.co.uk>
 <1414672952-1587-5-git-send-email-abbotti@mev.co.uk>
 <DC148C5AA1CEBA4E87973D432B1C2D882600D340@P3PWEX4MB008.ex4.secureserver.net>
 <54529F35.1060108@mev.co.uk>
In-Reply-To: <54529F35.1060108@mev.co.uk>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org

On Thursday, October 30, 2014 1:28 PM, Ian Abbott wrote:
> On 30/10/14 18:05, Hartley Sweeten wrote:
>> On Thursday, October 30, 2014 5:42 AM, Ian Abbott wrote:
>  [snip]
>>>   	add_wait_queue(&async->wait_head, &wait);
>>>   	while (nbytes > 0 && !retval) {
>>> @@ -2249,6 +2253,10 @@ static ssize_t comedi_read(struct file *file, char __user *buf, size_t nbytes,
>>>   				retval = -EACCES;
>>>   				break;
>>>   			}
>>> +			if (async->cmd.flags & CMDF_WRITE) {
>>> +				retval = -EINVAL;
>>> +				break;
>>> +			}
>>
>> Is this second test really needed in the while() loop?
>>
>> For that matter, are the s->busy tests needed in the while() loop?
>
> To answer your second question, some other thread using the same file 
> object might have cancelled the asynchronous command, causing the 
> current thread to see that the command is no longer active when it wakes up.
>
> To answer your first question, that other thread might have managed to 
> set up another asynchronous command in before we wake up, and it might 
> have been set up as a "write" command (if the subdevice supports 
> commands in both directions).  This doesn't detect the case when the 
> other thread has managed to set up another "read" command, but since the 
> current read() call hasn't read any data yet, we can just pretend we 
> didn't know about the original command and read data from the new 
> command instead.  (After all, the calling thread can't prove the read() 
> started before the first command was cancelled, so we can just pretend 
> it didn't.)

But when the command is first started by do_cmd_ioctl() we have this sequence:

	if (s->busy)
		return -EBUSY;
	...
	s->busy = file;
	ret = s->do_cmd(dev, s);

>From then on the s->busy pointer can only be cleared in do_become_nonbusy()
(by way of a (*cancel)). So another command cannot be started until the current
command is completed.

The user could do a (*do_cmdtest) while a command is running but that does not
effect the read/write of the async buffer.

Hartley


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