Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1542142 > unrolled thread

Re: [PATCH v2 01/46] mtdpart: Propagate _get/put_device()

Started byKarl Beldan <karl.beldan@gmail.com>
First post2016-12-14 20:30 +0100
Last post2016-12-28 20:00 +0100
Articles 7 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 01/46] mtdpart: Propagate _get/put_device() Karl Beldan <karl.beldan@gmail.com> - 2016-12-14 20:30 +0100
    Re: [PATCH v2 01/46] mtdpart: Propagate _get/put_device() Brian Norris <computersforpeace@gmail.com> - 2016-12-14 22:20 +0100
      Re: [PATCH v2 01/46] mtdpart: Propagate _get/put_device() Richard Weinberger <richard@nod.at> - 2016-12-14 22:20 +0100
        Re: [PATCH v2 01/46] mtdpart: Propagate _get/put_device() Brian Norris <computersforpeace@gmail.com> - 2016-12-15 00:50 +0100
      Re: [PATCH v2 01/46] mtdpart: Propagate _get/put_device() Karl Beldan <karl.beldan@gmail.com> - 2016-12-15 08:10 +0100
        Re: [PATCH v2 01/46] mtdpart: Propagate _get/put_device() Richard Weinberger <richard@nod.at> - 2016-12-15 09:00 +0100
          Re: [PATCH v2 01/46] mtdpart: Propagate _get/put_device() Karl Beldan <karl.beldan@gmail.com> - 2016-12-28 20:00 +0100

#1542142 — Re: [PATCH v2 01/46] mtdpart: Propagate _get/put_device()

FromKarl Beldan <karl.beldan@gmail.com>
Date2016-12-14 20:30 +0100
SubjectRe: [PATCH v2 01/46] mtdpart: Propagate _get/put_device()
Message-ID<sOnpv-2DO-7@gated-at.bofh.it>
On Wed, Sep 28, 2016 at 8:16 PM, Brian Norris
<computersforpeace@gmail.com> wrote:
> On Wed, Sep 21, 2016 at 12:15:31PM +0200, Boris Brezillon wrote:
>> On Wed, 21 Sep 2016 11:43:56 +0200
>> Daniel Walter <dwalter@sigma-star.at> wrote:
>>
>> > From: Richard Weinberger <richard@nod.at>
>> >
>> > If the master device has callbacks for _get/put_device()
>> > and this MTD has slaves a get_mtd_device() call on paritions
>> > will never issue the registered callbacks.
>> > Fix this by propagating _get/put_device() down.
>>
>> Brian, can we have this one queued for 4.9? I can't take it in my tree
>> if you want, but it's probably better if it's in the mtd tree.
>
> Applied this patch to l2-mtd.git
>

I think this should also go into -stable.

[toc] | [next] | [standalone]

#1542202

FromBrian Norris <computersforpeace@gmail.com>
Date2016-12-14 22:20 +0100
Message-ID<sOp7X-4Gu-1@gated-at.bofh.it>
In reply to#1542142
On Wed, Dec 14, 2016 at 07:24:46PM +0000, Karl Beldan wrote:
> On Wed, Sep 28, 2016 at 8:16 PM, Brian Norris
> <computersforpeace@gmail.com> wrote:
> > On Wed, Sep 21, 2016 at 12:15:31PM +0200, Boris Brezillon wrote:
> >> On Wed, 21 Sep 2016 11:43:56 +0200
> >> Daniel Walter <dwalter@sigma-star.at> wrote:
> >>
> >> > From: Richard Weinberger <richard@nod.at>
> >> >
> >> > If the master device has callbacks for _get/put_device()
> >> > and this MTD has slaves a get_mtd_device() call on paritions
> >> > will never issue the registered callbacks.
> >> > Fix this by propagating _get/put_device() down.
> >>
> >> Brian, can we have this one queued for 4.9? I can't take it in my tree
> >> if you want, but it's probably better if it's in the mtd tree.
> >
> > Applied this patch to l2-mtd.git
> >
> 
> I think this should also go into -stable.

Why? Do you have real use cases that are broken by this? I understand
this is a problem, but I'm curious on how this satisfies the stable
rules.

Also, note that this isn't a regression; it's been broken forever and
apparently no one noticed. IMO that raises the bar a bit (but not
impossibly so) for -stable.

Anyway, if we decide to do this, you'll also want to include the git
hash and applicable kernel versions, per Option 2 [1].

Brian

[1] Documentation/stable_kernel_rules.txt.

[toc] | [prev] | [next] | [standalone]

#1542203

FromRichard Weinberger <richard@nod.at>
Date2016-12-14 22:20 +0100
Message-ID<sOp7Y-4Gu-29@gated-at.bofh.it>
In reply to#1542202
Hi!

On 14.12.2016 22:09, Brian Norris wrote:
> On Wed, Dec 14, 2016 at 07:24:46PM +0000, Karl Beldan wrote:
>> On Wed, Sep 28, 2016 at 8:16 PM, Brian Norris
>> <computersforpeace@gmail.com> wrote:
>>> On Wed, Sep 21, 2016 at 12:15:31PM +0200, Boris Brezillon wrote:
>>>> On Wed, 21 Sep 2016 11:43:56 +0200
>>>> Daniel Walter <dwalter@sigma-star.at> wrote:
>>>>
>>>>> From: Richard Weinberger <richard@nod.at>
>>>>>
>>>>> If the master device has callbacks for _get/put_device()
>>>>> and this MTD has slaves a get_mtd_device() call on paritions
>>>>> will never issue the registered callbacks.
>>>>> Fix this by propagating _get/put_device() down.
>>>>
>>>> Brian, can we have this one queued for 4.9? I can't take it in my tree
>>>> if you want, but it's probably better if it's in the mtd tree.
>>>
>>> Applied this patch to l2-mtd.git
>>>
>>
>> I think this should also go into -stable.
> 
> Why? Do you have real use cases that are broken by this? I understand
> this is a problem, but I'm curious on how this satisfies the stable
> rules.
> 
> Also, note that this isn't a regression; it's been broken forever and
> apparently no one noticed. IMO that raises the bar a bit (but not
> impossibly so) for -stable.

Yes. AFAICT you can only trigger it using my "new" nandsim
which is not mainline so far.

Thanks,
//richard

[toc] | [prev] | [next] | [standalone]

#1542348

FromBrian Norris <computersforpeace@gmail.com>
Date2016-12-15 00:50 +0100
Message-ID<sOrt7-6MP-9@gated-at.bofh.it>
In reply to#1542203
On Wed, Dec 14, 2016 at 10:12:42PM +0100, Richard Weinberger wrote:
> On 14.12.2016 22:09, Brian Norris wrote:
> > Also, note that this isn't a regression; it's been broken forever and
> > apparently no one noticed. IMO that raises the bar a bit (but not
> > impossibly so) for -stable.
> 
> Yes. AFAICT you can only trigger it using my "new" nandsim
> which is not mainline so far.

Ah, OK. So the only current _{get,put}_device() implementor in mainline
is gluebi, so far. And it's OK for now to just have the master device be
refcounted, and just rely on the partitions being removed before the
master, right?

In that case, no, this shouldn't go to -stable.

Brian

[toc] | [prev] | [next] | [standalone]

#1542524

FromKarl Beldan <karl.beldan@gmail.com>
Date2016-12-15 08:10 +0100
Message-ID<sOykV-2PN-9@gated-at.bofh.it>
In reply to#1542202
On Wed, Dec 14, 2016 at 9:09 PM, Brian Norris
<computersforpeace@gmail.com> wrote:
> On Wed, Dec 14, 2016 at 07:24:46PM +0000, Karl Beldan wrote:
>> On Wed, Sep 28, 2016 at 8:16 PM, Brian Norris
>> <computersforpeace@gmail.com> wrote:
>> > On Wed, Sep 21, 2016 at 12:15:31PM +0200, Boris Brezillon wrote:
>> >> On Wed, 21 Sep 2016 11:43:56 +0200
>> >> Daniel Walter <dwalter@sigma-star.at> wrote:
>> >>
>> >> > From: Richard Weinberger <richard@nod.at>
>> >> >
>> >> > If the master device has callbacks for _get/put_device()
>> >> > and this MTD has slaves a get_mtd_device() call on paritions
>> >> > will never issue the registered callbacks.
>> >> > Fix this by propagating _get/put_device() down.
>> >>
>> >> Brian, can we have this one queued for 4.9? I can't take it in my tree
>> >> if you want, but it's probably better if it's in the mtd tree.
>> >
>> > Applied this patch to l2-mtd.git
>> >
>>
>> I think this should also go into -stable.
>
> Why? Do you have real use cases that are broken by this? I understand

I do, some code adding partitions on a gluebi master.

> this is a problem, but I'm curious on how this satisfies the stable
> rules.
>
> Also, note that this isn't a regression; it's been broken forever and
> apparently no one noticed. IMO that raises the bar a bit (but not
> impossibly so) for -stable.
>

I just encountered the bug yesterday and yes it is obvious it has been
broken forever.
I don't have strong opinion about these things so no worries.

Karl

> Anyway, if we decide to do this, you'll also want to include the git
> hash and applicable kernel versions, per Option 2 [1].
>
> Brian
>
> [1] Documentation/stable_kernel_rules.txt.

[toc] | [prev] | [next] | [standalone]

#1542536

FromRichard Weinberger <richard@nod.at>
Date2016-12-15 09:00 +0100
Message-ID<sOz7k-35K-5@gated-at.bofh.it>
In reply to#1542524
On 15.12.2016 08:09, Karl Beldan wrote:
>>> I think this should also go into -stable.
>>
>> Why? Do you have real use cases that are broken by this? I understand
> 
> I do, some code adding partitions on a gluebi master.

What exactly are you doing?

>> this is a problem, but I'm curious on how this satisfies the stable
>> rules.
>>
>> Also, note that this isn't a regression; it's been broken forever and
>> apparently no one noticed. IMO that raises the bar a bit (but not
>> impossibly so) for -stable.
>>
> 
> I just encountered the bug yesterday and yes it is obvious it has been
> broken forever.
> I don't have strong opinion about these things so no worries.

If existing stuff is broken, and you can trigger it. Please let us
know. Then it should go into -stable.

Thanks,
//richard

[toc] | [prev] | [next] | [standalone]

#1548040

FromKarl Beldan <karl.beldan@gmail.com>
Date2016-12-28 20:00 +0100
Message-ID<sTrC9-3J4-1@gated-at.bofh.it>
In reply to#1542536
On Thu, Dec 15, 2016 at 08:51:06AM +0100, Richard Weinberger wrote:
> On 15.12.2016 08:09, Karl Beldan wrote:
> >>> I think this should also go into -stable.
> >>
> >> Why? Do you have real use cases that are broken by this? I understand
> > 
> > I do, some code adding partitions on a gluebi master.
> 
> What exactly are you doing?
> 
> >> this is a problem, but I'm curious on how this satisfies the stable
> >> rules.
> >>
> >> Also, note that this isn't a regression; it's been broken forever and
> >> apparently no one noticed. IMO that raises the bar a bit (but not
> >> impossibly so) for -stable.
> >>
> > 
> > I just encountered the bug yesterday and yes it is obvious it has been
> > broken forever.
> > I don't have strong opinion about these things so no worries.
> 
> If existing stuff is broken, and you can trigger it. Please let us
> know. Then it should go into -stable.
> 

I thought that's what I already did.

Anyways, it didn't require much imagination to come up with a script
triggering the issue so here you are:

#{{

modprobe nandsim
modprobe gluebi
ubiattach -p /dev/mtd1 -b 1
ubimkvol /dev/ubi0 -S 4 -N vol_0
mtdpart add /dev/mtd2 vol_0_0 0 0x1000
tail -F /dev/mtd2 &
while :; do dd bs=1 count=1 if=/dev/mtd3 >/dev/null 2>&1 || break; done
kill -9 %1 # Oops

#}}

 
Karl

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web