Skip to contentSkip to conversation

for-4.8/drivers and Linus' tree + staging conflicts?

PATCH Konrad Rzeszutek Wilk 2 participants 4 messages Jul 15, 2016 – Jul 21, 2016

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

Hey Jens,

I have some patches for Xen block driver that are based on Linus's tree which has:
7b427a5 xen-blkfront: save uncompleted reqs in blkfront_resume()

That particular patch conflicts with your for-4.8/driver branch.

What I was wondering is if:

1) Do you want me to create a branh for you to pull in your for-4.8/drivers that has the above patch (and a resolution)? And along with that the rest of the patches I've for 4.8?

2) Or if you are going rebase your 'for-4.8/drivers' branch on top of v4.7-rc7 (which will pull in the above commit?)

3) Stash the patches I've in the Xen tip tree (which is based on 4.7-rc7) for 4.8 with me putting your Ack on them? See below log and the full diff.

Thanks!

Jan Beulich (4):
xen-blkback: really don't leak mode property
xen-blkback: prefer xenbus_scanf() over xenbus_gather()
xen-blkfront: prefer xenbus_scanf() over xenbus_gather()
xen-blkback: constify instance of "struct attribute_group"

drivers/block/xen-blkback/xenbus.c +11 -9
index 3355f1c..4a24121 100644
@@ -379,7 +379,7 @@ static struct attribute *xen_vbdstat_attrs[] = {
 	NULL
 };
 
-static struct attribute_group xen_vbdstat_group = {
+static const struct attribute_group xen_vbdstat_group = {
 	.name = "statistics",
 	.attrs = xen_vbdstat_attrs,
 };
@@ -715,8 +715,11 @@ static void backend_changed(struct xenbus_watch *watch,
 
 	/* Front end dir is a number, which is used as the handle. */
 	err = kstrtoul(strrchr(dev->otherend, '/') + 1, 0, &handle);
-	if (err)
+	if (err) {
+		kfree(be->mode);
+		be->mode = NULL;
 		return;
+	}
 
 	be->major = major;
 	be->minor = minor;
@@ -1022,9 +1025,9 @@ static int connect_ring(struct backend_info *be)
 	pr_debug("%s %s\n", __func__, dev->otherend);
 
 	be->blkif->blk_protocol = BLKIF_PROTOCOL_DEFAULT;
-	err = xenbus_gather(XBT_NIL, dev->otherend, "protocol",
-			    "%63s", protocol, NULL);
-	if (err)
+	err = xenbus_scanf(XBT_NIL, dev->otherend, "protocol",
+			   "%63s", protocol);
+	if (err <= 0)
 		strcpy(protocol, "unspecified, assuming default");
 	else if (0 == strcmp(protocol, XEN_IO_PROTO_ABI_NATIVE))
 		be->blkif->blk_protocol = BLKIF_PROTOCOL_NATIVE;
@@ -1036,10 +1039,9 @@ static int connect_ring(struct backend_info *be)
 		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
 		return -ENOSYS;
 	}
-	err = xenbus_gather(XBT_NIL, dev->otherend,
-			    "feature-persistent", "%u",
-			    &pers_grants, NULL);
-	if (err)
+	err = xenbus_scanf(XBT_NIL, dev->otherend,
+			   "feature-persistent", "%u", &pers_grants);
+	if (err <= 0)
 		pers_grants = 0;
 
 	be->blkif->vbd.feature_gnt_persistent = pers_grants;
drivers/block/xen-blkfront.c +19 -24

76 lines not on this page · raw message

#1 lore raw
Quoted 1 line · Konrad Rzeszutek Wilk

Hey Jens,

+your kernel address.

A very gently ping.

Quoted 164 lines

I have some patches for Xen block driver that are based on Linus's tree which has:
7b427a5 xen-blkfront: save uncompleted reqs in blkfront_resume()

That particular patch conflicts with your for-4.8/driver branch.

What I was wondering is if:

1) Do you want me to create a branh for you to pull in your for-4.8/drivers that has the above patch (and a resolution)? And along with that the rest of the patches I've for 4.8?

2) Or if you are going rebase your 'for-4.8/drivers' branch on top of v4.7-rc7 (which will pull in the above commit?)

3) Stash the patches I've in the Xen tip tree (which is based on 4.7-rc7) for 4.8 with me putting your Ack on them? See below log and the full diff.

Thanks!

Jan Beulich (4):
xen-blkback: really don't leak mode property
xen-blkback: prefer xenbus_scanf() over xenbus_gather()
xen-blkfront: prefer xenbus_scanf() over xenbus_gather()
xen-blkback: constify instance of "struct attribute_group"

drivers/block/xen-blkback/xenbus.c +11 -9
index 3355f1c..4a24121 100644
@@ -379,7 +379,7 @@ static struct attribute *xen_vbdstat_attrs[] = {
 	NULL
 };
 
-static struct attribute_group xen_vbdstat_group = {
+static const struct attribute_group xen_vbdstat_group = {
 	.name = "statistics",
 	.attrs = xen_vbdstat_attrs,
 };
@@ -715,8 +715,11 @@ static void backend_changed(struct xenbus_watch *watch,
 
 	/* Front end dir is a number, which is used as the handle. */
 	err = kstrtoul(strrchr(dev->otherend, '/') + 1, 0, &handle);
-	if (err)
+	if (err) {
+		kfree(be->mode);
+		be->mode = NULL;
 		return;
+	}
 
 	be->major = major;
 	be->minor = minor;
@@ -1022,9 +1025,9 @@ static int connect_ring(struct backend_info *be)
 	pr_debug("%s %s\n", __func__, dev->otherend);
 
 	be->blkif->blk_protocol = BLKIF_PROTOCOL_DEFAULT;
-	err = xenbus_gather(XBT_NIL, dev->otherend, "protocol",
-			    "%63s", protocol, NULL);
-	if (err)
+	err = xenbus_scanf(XBT_NIL, dev->otherend, "protocol",
+			   "%63s", protocol);
+	if (err <= 0)
 		strcpy(protocol, "unspecified, assuming default");
 	else if (0 == strcmp(protocol, XEN_IO_PROTO_ABI_NATIVE))
 		be->blkif->blk_protocol = BLKIF_PROTOCOL_NATIVE;
@@ -1036,10 +1039,9 @@ static int connect_ring(struct backend_info *be)
 		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
 		return -ENOSYS;
 	}
-	err = xenbus_gather(XBT_NIL, dev->otherend,
-			    "feature-persistent", "%u",
-			    &pers_grants, NULL);
-	if (err)
+	err = xenbus_scanf(XBT_NIL, dev->otherend,
+			   "feature-persistent", "%u", &pers_grants);
+	if (err <= 0)
 		pers_grants = 0;
 
 	be->blkif->vbd.feature_gnt_persistent = pers_grants;
drivers/block/xen-blkfront.c +19 -24
index fcc5b4e..6672b80 100644
@@ -2197,10 +2197,9 @@ static void blkfront_setup_discard(struct blkfront_info *info)
 		info->discard_granularity = discard_granularity;
 		info->discard_alignment = discard_alignment;
 	}
-	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
-		    "discard-secure", "%d", &discard_secure,
-		    NULL);
-	if (!err)
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "discard-secure", "%u", &discard_secure);
+	if (err > 0)
 		info->feature_secdiscard = !!discard_secure;
 }
 
@@ -2299,9 +2298,8 @@ static void blkfront_gather_backend_features(struct blkfront_info *info)
 
 	info->feature_flush = 0;
 
-	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
-			"feature-barrier", "%d", &barrier,
-			NULL);
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "feature-barrier", "%d", &barrier);
 
 	/*
 	 * If there's no "feature-barrier" defined, then it means
@@ -2310,38 +2308,35 @@ static void blkfront_gather_backend_features(struct blkfront_info *info)
 	 *
 	 * If there are barriers, then we use flush.
 	 */
-	if (!err && barrier)
+	if (err > 0 && barrier)
 		info->feature_flush = REQ_FLUSH | REQ_FUA;
 	/*
 	 * And if there is "feature-flush-cache" use that above
 	 * barriers.
 	 */
-	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
-			"feature-flush-cache", "%d", &flush,
-			NULL);
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "feature-flush-cache", "%d", &flush);
 
-	if (!err && flush)
+	if (err > 0 && flush)
 		info->feature_flush = REQ_FLUSH;
 
-	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
-			"feature-discard", "%d", &discard,
-			NULL);
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "feature-discard", "%d", &discard);
 
-	if (!err && discard)
+	if (err > 0 && discard)
 		blkfront_setup_discard(info);
 
-	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
-			"feature-persistent", "%u", &persistent,
-			NULL);
-	if (err)
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "feature-persistent", "%d", &persistent);
+	if (err <= 0)
 		info->feature_persistent = 0;
 	else
 		info->feature_persistent = persistent;
 
-	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
-			    "feature-max-indirect-segments", "%u", &indirect_segments,
-			    NULL);
-	if (err)
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "feature-max-indirect-segments", "%u",
+			   &indirect_segments);
+	if (err <= 0)
 		info->max_indirect_segments = 0;
 	else
 		info->max_indirect_segments = min(indirect_segments,
#2 lore raw
In reply to Konrad Rzeszutek Wilk
Quoted 6 lines · Konrad Rzeszutek Wilk

Hey Jens,

I have some patches for Xen block driver that are based on Linus's tree which has:
7b427a5 xen-blkfront: save uncompleted reqs in blkfront_resume()

Quoted 7 lines

That particular patch conflicts with your for-4.8/driver branch.

What I was wondering is if:

1) Do you want me to create a branh for you to pull in your for-4.8/drivers that has the above patch (and a resolution)? And along with that the rest of the patches I've for 4.8?

No, I don't want a lot of extra gunk.

Quoted 2 lines

2) Or if you are going rebase your 'for-4.8/drivers' branch on top of v4.7-rc7 (which will pull in the above commit?)

Or that, I never rebase those branches.

Quoted 3 lines

3) Stash the patches I've in the Xen tip tree (which is based on 4.7-rc7) for 4.8 with me putting your Ack on them? See below log and the full diff.

We can do that, or I can stage them for post initial merge (essentially my for-linus, which I could base on 4.7-rc7 now). I'm fine with either.

Signature · 1 line
Jens Axboe
#3 lore raw
Quoted 20 lines · Jens Axboe
Quoted 6 lines · Konrad Rzeszutek Wilk

Hey Jens,

I have some patches for Xen block driver that are based on Linus's tree which has:
7b427a5 xen-blkfront: save uncompleted reqs in blkfront_resume()

Quoted 7 lines

That particular patch conflicts with your for-4.8/driver branch.

What I was wondering is if:

1) Do you want me to create a branh for you to pull in your for-4.8/drivers that has the above patch (and a resolution)? And along with that the rest of the patches I've for 4.8?

No, I don't want a lot of extra gunk.

Quoted 2 lines

2) Or if you are going rebase your 'for-4.8/drivers' branch on top of v4.7-rc7 (which will pull in the above commit?)

Quoted 8 lines

Or that, I never rebase those branches.

Quoted 3 lines

3) Stash the patches I've in the Xen tip tree (which is based on 4.7-rc7) for 4.8 with me putting your Ack on them? See below log and the full diff.

We can do that, or I can stage them for post initial merge (essentially my for-linus, which I could base on 4.7-rc7 now). I'm fine with either.

OK, lets go with this one and we will stick them in xen-tip.

Thanks Jens!

Quoted 4 lines
Signature · 2 lines
-- 
Jens Axboe