| Message ID | 1409348550-27768-3-git-send-email-ezequiel.garcia@free-electrons.com |
|---|---|
| State | Accepted |
| Headers | show |
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.
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.
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.
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.
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.
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.
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?
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.
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+ ?
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.
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!
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; }
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(-)