Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sat, 9 Jun 2018 11:48:42 -0400
From:   Hugo Lefeuvre <hle@owl.eu.com>
To:     Valentin Vidic <Valentin.Vidic@CARNet.hr>
Cc:     devel@driverdev.osuosl.org,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org, kernelnewbies@kernelnewbies.org
Subject: Re: [PATCH v2] staging: pi433: add mutex fixing concurrency issues.
Message-ID: <20180609154842.GB1826@hle-laptop.local>
References: <20180602175649.GA2816@hle-laptop.local>
 <20180607124216.GA2329@hle-laptop.local>
 <20180609081244.GP14048@gavran.carpriv.carnet.hr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180609081244.GP14048@gavran.carpriv.carnet.hr>
User-Agent: Mutt/1.10.0 (2018-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> > After discussing this issue on the kernel newbies mailing list[0] we
> > came to the conclusion that it is very unlikely that pi433_release and
> > pi433_ioctl would ever run concurrently in this case. This is also
> > true for read/write. Unless one can find a situation where this might
> > happen, I think we should not add this potentially unnecessary lock.
> 
> Yes, so we should than drop the TODO comment on this issue?

Well, after taking a closer look it appears that I misunderstood the
TODO.

What this TODO means is that we might run into a whole world of issues
if the device is _removed_ while we're running ioctl or I guess pretty
much any function that accesses the struct pi433_device.

So the issue doesn't come from pi433_release and pi433_ioctl running
concurrently, but rather pi433_ioctl and pi433_remove. Whether this
situation is likely to happen or not is another question which I am
currently taking a look at.

Also, during my work on this driver I found what I'd consider as another
issue: In pi433_ioctl we execute

case PI433_IOC_WR_TX_CFG:
        if (copy_from_user(&instance->tx_cfg, argp,
                   sizeof(struct pi433_tx_cfg)))
            return -EFAULT;
        break;

without any synchronization. What if two ioctl syscalls are called with
command PI433_IOC_WR_TX_CFG ? instance->tx_cfg might get corrupt unless
copy_from_user provides some kind of synchronization, right ?

I have prepared a patch but couldn't test it because I don't have test
devices.

-- 
             Hugo Lefeuvre (hle)    |    www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA