From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1757825AbbCCVm5 (ORCPT <rfc822;w@1wt.eu>);
	Tue, 3 Mar 2015 16:42:57 -0500
Received: from zeniv.linux.org.uk ([195.92.253.2]:54276 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1757791AbbCCVmy (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 3 Mar 2015 16:42:54 -0500
Date: Tue, 3 Mar 2015 21:42:49 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Alexander Holler <holler@ahsoftware.de>,
        Richard Weinberger <richard.weinberger@gmail.com>,
        USB list <linux-usb@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>, Felipe Balbi <balbi@ti.com>
Subject: Re: gadgetfs broken since 7f7f25e8
Message-ID: <20150303214249.GS29656@ZenIV.linux.org.uk>
References: <20150303083934.GR29656@ZenIV.linux.org.uk>
 <Pine.LNX.4.44L0.1503031042200.1655-100000@iolanthe.rowland.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44L0.1503031042200.1655-100000@iolanthe.rowland.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Mar 03, 2015 at 10:47:14AM -0500, Alan Stern wrote:
> On Tue, 3 Mar 2015, Al Viro wrote:
> 
> > Looking at that thing again...  why do they need to be dummy?  After all,
> > those methods start with get_ready_ep(), which will fail unless we have
> > ->state == STATE_EP_ENABLED.  So they'd be failing just fine until that
> > first write() anyway.  Let's do the following:
> 
> In addition to the changes you made, it looks like you will need the 
> following or something similar (also untested).  I'm not sure if this 
> is race-free, but it's better than before.

Right, ep0 has the same kind of problem...


> @@ -1240,6 +1241,10 @@ static int
>  ep0_fasync (int f, struct file *fd, int on)
>  {
>  	struct dev_data		*dev = fd->private_data;
> +
> +	if (dev->state <= STATE_DEV_OPENED)
> +		return -ENODEV;
> +

Er...  What is protecting dev->state here?  Matter of fact, what's the
point of that check at all?  Right now you have .fasync = ep0_fasync
both in ep0_io_operations and in dev_init_operations, so your delta
changes the existing semantics...