On Tue, Jun 19, 2018 at 09:42:20AM -0400, Hugo Lefeuvre wrote:
> This TODO seems to be related to this misunderstanding too:
>
> 890 /* TODO? guard against device removal before, or while,
> 891 * we issue this ioctl. --> device_get()
> 892 */
>
> Device removal
On Tue, Jun 19, 2018 at 09:42:20AM -0400, Hugo Lefeuvre wrote:
> This TODO seems to be related to this misunderstanding too:
>
> 890 /* TODO? guard against device removal before, or while,
> 891 * we issue this ioctl. --> device_get()
> 892 */
>
> Device removal
> > It would be great to get rid of this counter, indeed. But how to do it
> > properly without breaking things ? It seems to be useful to me...
>
> These things are refcounted so you can't unload the module while a file
> is open. When we do an open it does a cdev_get(). When we call the
>
> > It would be great to get rid of this counter, indeed. But how to do it
> > properly without breaking things ? It seems to be useful to me...
>
> These things are refcounted so you can't unload the module while a file
> is open. When we do an open it does a cdev_get(). When we call the
>
On Mon, Jun 18, 2018 at 11:11:36PM -0400, Hugo Lefeuvre wrote:
> Hi Dan,
>
> > We need to decrement device->users-- on the error paths as well.
> > This function was already slightly broken with respect to counting the
> > users, but let's not make it worse.
> >
> > I think it's still a tiny bit
On Mon, Jun 18, 2018 at 11:11:36PM -0400, Hugo Lefeuvre wrote:
> Hi Dan,
>
> > We need to decrement device->users-- on the error paths as well.
> > This function was already slightly broken with respect to counting the
> > users, but let's not make it worse.
> >
> > I think it's still a tiny bit
Hi Dan,
> We need to decrement device->users-- on the error paths as well.
> This function was already slightly broken with respect to counting the
> users, but let's not make it worse.
>
> I think it's still a tiny bit racy because it's not an atomic type.
Oh right, I missed that. I'll fix it
Hi Dan,
> We need to decrement device->users-- on the error paths as well.
> This function was already slightly broken with respect to counting the
> users, but let's not make it worse.
>
> I think it's still a tiny bit racy because it's not an atomic type.
Oh right, I missed that. I'll fix it
On Sun, Jun 17, 2018 at 10:24:00PM -0400, Hugo Lefeuvre wrote:
> Whenever pi433_open and pi433_remove execute concurrently, a race
> condition potentially resulting in use-after-free might happen.
>
> Let T1 and T2 be two kernel threads.
>
> 1. T1 executes pi433_open and stops before
On Sun, Jun 17, 2018 at 10:24:00PM -0400, Hugo Lefeuvre wrote:
> Whenever pi433_open and pi433_remove execute concurrently, a race
> condition potentially resulting in use-after-free might happen.
>
> Let T1 and T2 be two kernel threads.
>
> 1. T1 executes pi433_open and stops before
Whenever pi433_open and pi433_remove execute concurrently, a race
condition potentially resulting in use-after-free might happen.
Let T1 and T2 be two kernel threads.
1. T1 executes pi433_open and stops before "device->users++".
2. The pi433 device was removed inbetween, so T2 executes
Whenever pi433_open and pi433_remove execute concurrently, a race
condition potentially resulting in use-after-free might happen.
Let T1 and T2 be two kernel threads.
1. T1 executes pi433_open and stops before "device->users++".
2. The pi433 device was removed inbetween, so T2 executes
12 matches
Mail list logo
