Patchwork [2/3] UBI: block: Add support for the UBI_VOLUME_UPDATED notification

login
register
mail settings
Submitter Ezequiel Garcia
Date Aug. 29, 2014, 9:42 p.m.
Message ID <1409348550-27768-3-git-send-email-ezequiel.garcia@free-electrons.com>
Download mbox | patch
Permalink /patch/384395/
State Accepted
Headers show

Comments

Ezequiel Garcia - Aug. 29, 2014, 9:42 p.m.
Static volumes can change its 'used_bytes' when they get updated,
and so the block interface must listen to the UBI_VOLUME_UPDATED
notification to resize the block device accordingly.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/mtd/ubi/block.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)
Artem Bityutskiy - Sept. 8, 2014, 10:54 a.m.
On Fri, 2014-08-29 at 18:42 -0300, Ezequiel Garcia wrote:
> Static volumes can change its 'used_bytes' when they get updated,
> and so the block interface must listen to the UBI_VOLUME_UPDATED
> notification to resize the block device accordingly.
> 
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

Looks like a good fix. If you want this in stable, you please, let me
know and also make sure you actually tested it and verified that block
device size actually gets changed.
Ezequiel Garcia - Sept. 8, 2014, 11:18 a.m.
On 08 Sep 01:54 PM, Artem Bityutskiy wrote:
> On Fri, 2014-08-29 at 18:42 -0300, Ezequiel Garcia wrote:
> > Static volumes can change its 'used_bytes' when they get updated,
> > and so the block interface must listen to the UBI_VOLUME_UPDATED
> > notification to resize the block device accordingly.
> > 
> > Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> 
> Looks like a good fix. If you want this in stable, you please, let me
> know and also make sure you actually tested it and verified that block
> device size actually gets changed.
> 

Yes, gave this series a good test, with gluebi and ubiblock enabled,
updating/resizing a volume and then reading back the contents from the
ubi0_0, ubiblock0_0 and mtdX (gluebi) devices.

However, it would be awesome if we could get someone else to test this
and report.

Regarding -stable, I think it's worth to pull the whole series.
Artem Bityutskiy - Sept. 8, 2014, 12:47 p.m.
On Mon, 2014-09-08 at 08:18 -0300, Ezequiel Garcia wrote:
> Regarding -stable, I think it's worth to pull the whole series.

I've checked and the patches do not apply to 3.16 with many conflicts. 
Are you enthusiastic enough to try this and fined out the missing
dependencies?

The we could add the "Cc: stable@vger.kernel.org # v3.16+" tags, and
also mentioned the commits we depend on in the commit messages.

At this point I pushed your patches to the master branch. If you are
going to check the stable story, please, use this branch.
Ezequiel Garcia - Sept. 8, 2014, 6:27 p.m.
On 08 Sep 03:47 PM, Artem Bityutskiy wrote:
> On Mon, 2014-09-08 at 08:18 -0300, Ezequiel Garcia wrote:
> > Regarding -stable, I think it's worth to pull the whole series.
> 
> I've checked and the patches do not apply to 3.16 with many conflicts. 
> Are you enthusiastic enough to try this and fined out the missing
> dependencies?
> 
> The we could add the "Cc: stable@vger.kernel.org # v3.16+" tags, and
> also mentioned the commits we depend on in the commit messages.
> 
> At this point I pushed your patches to the master branch. If you are
> going to check the stable story, please, use this branch.
> 

Sure, I'll prepare the list of commits and let you know.

Meanwhile, it would be very useful to have someone test these patches.

Rafał, do you think you can do some testing? It would be nice to check these
fixes are correct, and maybe you can pick them for OpenWRT.
Artem Bityutskiy - Sept. 16, 2014, 3:15 p.m.
On Mon, 2014-09-08 at 15:27 -0300, Ezequiel Garcia wrote:
> On 08 Sep 03:47 PM, Artem Bityutskiy wrote:
> > On Mon, 2014-09-08 at 08:18 -0300, Ezequiel Garcia wrote:
> > > Regarding -stable, I think it's worth to pull the whole series.
> > 
> > I've checked and the patches do not apply to 3.16 with many conflicts. 
> > Are you enthusiastic enough to try this and fined out the missing
> > dependencies?
> > 
> > The we could add the "Cc: stable@vger.kernel.org # v3.16+" tags, and
> > also mentioned the commits we depend on in the commit messages.
> > 
> > At this point I pushed your patches to the master branch. If you are
> > going to check the stable story, please, use this branch.
> > 
> 
> Sure, I'll prepare the list of commits and let you know.

Should I wait some more or assume we won't add the stable tags and add
these patches to the 'next' branch? It is about time, I guess.
Artem Bityutskiy - Sept. 16, 2014, 3:23 p.m.
On Tue, 2014-09-16 at 18:15 +0300, Artem Bityutskiy wrote:
> On Mon, 2014-09-08 at 15:27 -0300, Ezequiel Garcia wrote:
> > On 08 Sep 03:47 PM, Artem Bityutskiy wrote:
> > > On Mon, 2014-09-08 at 08:18 -0300, Ezequiel Garcia wrote:
> > > > Regarding -stable, I think it's worth to pull the whole series.
> > > 
> > > I've checked and the patches do not apply to 3.16 with many conflicts. 
> > > Are you enthusiastic enough to try this and fined out the missing
> > > dependencies?
> > > 
> > > The we could add the "Cc: stable@vger.kernel.org # v3.16+" tags, and
> > > also mentioned the commits we depend on in the commit messages.
> > > 
> > > At this point I pushed your patches to the master branch. If you are
> > > going to check the stable story, please, use this branch.
> > > 
> > 
> > Sure, I'll prepare the list of commits and let you know.
> 
> Should I wait some more or assume we won't add the stable tags and add
> these patches to the 'next' branch? It is about time, I guess.

I've moved your patch-set to the 'ubiblock' branch so far.
Ezequiel García - Sept. 16, 2014, 3:32 p.m.
On 16 September 2014 16:15, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Mon, 2014-09-08 at 15:27 -0300, Ezequiel Garcia wrote:
>> On 08 Sep 03:47 PM, Artem Bityutskiy wrote:
>> > On Mon, 2014-09-08 at 08:18 -0300, Ezequiel Garcia wrote:
>> > > Regarding -stable, I think it's worth to pull the whole series.
>> >
>> > I've checked and the patches do not apply to 3.16 with many conflicts.
>> > Are you enthusiastic enough to try this and fined out the missing
>> > dependencies?
>> >
>> > The we could add the "Cc: stable@vger.kernel.org # v3.16+" tags, and
>> > also mentioned the commits we depend on in the commit messages.
>> >
>> > At this point I pushed your patches to the master branch. If you are
>> > going to check the stable story, please, use this branch.
>> >
>>
>> Sure, I'll prepare the list of commits and let you know.
>
> Should I wait some more or assume we won't add the stable tags and add
> these patches to the 'next' branch? It is about time, I guess.
>

Yeah, I have the list of commits ready a couple weeks ago:

4fda380 UBI: Dispatch update notification if the volume is updated
46a5b80 UBI: block: Add support for the UBI_VOLUME_UPDATED notification
db95429 UBI: block: Fix block device size setting
3170403 UBI: block: Avoid disk size integer overflow
b6c7b28 UBI: block: Set disk_capacity out of the mutex
1860e37 Linux 3.15

I just got delayed thinking if it was OK to pick so many commits into
stable. As an alternative,
we can mark only the ones on this patchset, namely:

4fda380 UBI: Dispatch update notification if the volume is updated
46a5b80 UBI: block: Add support for the UBI_VOLUME_UPDATED notification
db95429 UBI: block: Fix block device size setting

And I can provide a backport when the -stable people ask for one. Of
course, it's a bit more work
on everyone, so... what do you think?
Ezequiel García - Sept. 16, 2014, 3:35 p.m.
On 16 September 2014 16:32, Ezequiel Garcia
<ezequiel@vanguardiasur.com.ar> wrote:
> On 16 September 2014 16:15, Artem Bityutskiy <dedekind1@gmail.com> wrote:
>> On Mon, 2014-09-08 at 15:27 -0300, Ezequiel Garcia wrote:
>>> On 08 Sep 03:47 PM, Artem Bityutskiy wrote:
>>> > On Mon, 2014-09-08 at 08:18 -0300, Ezequiel Garcia wrote:
>>> > > Regarding -stable, I think it's worth to pull the whole series.
>>> >
>>> > I've checked and the patches do not apply to 3.16 with many conflicts.
>>> > Are you enthusiastic enough to try this and fined out the missing
>>> > dependencies?
>>> >
>>> > The we could add the "Cc: stable@vger.kernel.org # v3.16+" tags, and
>>> > also mentioned the commits we depend on in the commit messages.
>>> >
>>> > At this point I pushed your patches to the master branch. If you are
>>> > going to check the stable story, please, use this branch.
>>> >
>>>
>>> Sure, I'll prepare the list of commits and let you know.
>>
>> Should I wait some more or assume we won't add the stable tags and add
>> these patches to the 'next' branch? It is about time, I guess.
>>
>
> Yeah, I have the list of commits ready a couple weeks ago:
>
> 4fda380 UBI: Dispatch update notification if the volume is updated
> 46a5b80 UBI: block: Add support for the UBI_VOLUME_UPDATED notification
> db95429 UBI: block: Fix block device size setting
> 3170403 UBI: block: Avoid disk size integer overflow
> b6c7b28 UBI: block: Set disk_capacity out of the mutex
> 1860e37 Linux 3.15
>
> I just got delayed thinking if it was OK to pick so many commits into
> stable. As an alternative,
> we can mark only the ones on this patchset, namely:
>
> 4fda380 UBI: Dispatch update notification if the volume is updated
> 46a5b80 UBI: block: Add support for the UBI_VOLUME_UPDATED notification
> db95429 UBI: block: Fix block device size setting
>

Of course, the commit hashes above are all wrong.
Artem Bityutskiy - Sept. 16, 2014, 3:53 p.m.
On Tue, 2014-09-16 at 16:32 +0100, Ezequiel Garcia wrote:
> 4fda380 UBI: Dispatch update notification if the volume is updated
> 46a5b80 UBI: block: Add support for the UBI_VOLUME_UPDATED notification
> db95429 UBI: block: Fix block device size setting
> 3170403 UBI: block: Avoid disk size integer overflow
> b6c7b28 UBI: block: Set disk_capacity out of the mutex
> 1860e37 Linux 3.15
> 
> I just got delayed thinking if it was OK to pick so many commits into
> stable. As an alternative,
> we can mark only the ones on this patchset, namely:
> 
> 4fda380 UBI: Dispatch update notification if the volume is updated
> 46a5b80 UBI: block: Add support for the UBI_VOLUME_UPDATED notification
> db95429 UBI: block: Fix block device size setting

Yeah, these 3 look like the more important ones. So do we put 

Cc: stable@vger.kernel.org # v3.16+

or

Cc: stable@vger.kernel.org # v3.15+

?
Ezequiel García - Sept. 16, 2014, 3:56 p.m.
On 16 September 2014 16:53, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Tue, 2014-09-16 at 16:32 +0100, Ezequiel Garcia wrote:
>> 4fda380 UBI: Dispatch update notification if the volume is updated
>> 46a5b80 UBI: block: Add support for the UBI_VOLUME_UPDATED notification
>> db95429 UBI: block: Fix block device size setting
>> 3170403 UBI: block: Avoid disk size integer overflow
>> b6c7b28 UBI: block: Set disk_capacity out of the mutex
>> 1860e37 Linux 3.15
>>
>> I just got delayed thinking if it was OK to pick so many commits into
>> stable. As an alternative,
>> we can mark only the ones on this patchset, namely:
>>
>> 4fda380 UBI: Dispatch update notification if the volume is updated
>> 46a5b80 UBI: block: Add support for the UBI_VOLUME_UPDATED notification
>> db95429 UBI: block: Fix block device size setting
>
> Yeah, these 3 look like the more important ones. So do we put
>
> Cc: stable@vger.kernel.org # v3.16+
>
> or
>
> Cc: stable@vger.kernel.org # v3.15+
>

Cc: stable@vger.kernel.org # v3.15+

I'll backport them when -stable guys ask to.
Artem Bityutskiy - Sept. 16, 2014, 4:04 p.m.
On Tue, 2014-09-16 at 16:56 +0100, Ezequiel Garcia wrote:
> Cc: stable@vger.kernel.org # v3.15+
> 
> I'll backport them when -stable guys ask to.

OK, just did it, and pushed out, thanks!

Patch

diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c
index a29d41c..4fafd49 100644
--- a/drivers/mtd/ubi/block.c
+++ b/drivers/mtd/ubi/block.c
@@ -522,8 +522,12 @@  static int ubiblock_resize(struct ubi_volume_info *vi)
 	}
 
 	mutex_lock(&dev->dev_mutex);
-	set_capacity(dev->gd, disk_capacity);
-	ubi_msg("%s resized to %lld bytes", dev->gd->disk_name, vi->used_bytes);
+
+	if (get_capacity(dev->gd) != disk_capacity) {
+		set_capacity(dev->gd, disk_capacity);
+		ubi_msg("%s resized to %lld bytes", dev->gd->disk_name,
+			vi->used_bytes);
+	}
 	mutex_unlock(&dev->dev_mutex);
 	mutex_unlock(&devices_mutex);
 	return 0;
@@ -547,6 +551,14 @@  static int ubiblock_notify(struct notifier_block *nb,
 	case UBI_VOLUME_RESIZED:
 		ubiblock_resize(&nt->vi);
 		break;
+	case UBI_VOLUME_UPDATED:
+		/*
+		 * If the volume is static, a content update might mean the
+		 * size (i.e. used_bytes) was also changed.
+		 */
+		if (nt->vi.vol_type == UBI_STATIC_VOLUME)
+			ubiblock_resize(&nt->vi);
+		break;
 	default:
 		break;
 	}