Skip to contentSkip to conversation

Source code review around jump label usage

PATCH In review SF Markus Elfring 114 participants 1,410 messages Dec 11, 2015 – Jan 5, 2024 2 messages not in the archive Page 5 of 6

Subsystems (101)
lore
Share & tools
lore
#953 lore raw

cover drm/amdgpu: Fine-tuning for several function implementations

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sun, 18 Sep 2016 18:38:48 +0200

Some update suggestions were taken into account
from static source code analysis.

Markus Elfring (5):
Use kmalloc_array() in amdgpu_debugfs_gca_config_read() Improve determination of sizes in two functions Rename a jump label in amdgpu_debugfs_regs_read() Rename a jump label in amdgpu_device_init() Adjust checks for null pointers in nine functions

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 68 +++++++++++++++---------------
 1 file changed, 33 insertions(+), 35 deletions(-)
Signature · 1 line
2.10.0
#954 lore raw

PATCH 1/5 drm/amdgpu: Use kmalloc_array() in amdgpu_debugfs_gca_config_read()

From: Markus Elfring <[email protected]>
Date: Sun, 18 Sep 2016 17:00:52 +0200

A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +1 -1
index df7ab245..2709ebd 100644
@@ -2438,7 +2438,7 @@ static ssize_t amdgpu_debugfs_gca_config_read(struct file *f, char __user *buf,
 	if (size & 0x3 || *pos & 0x3)
 		return -EINVAL;
 
-	config = kmalloc(256 * sizeof(*config), GFP_KERNEL);
+	config = kmalloc_array(256, sizeof(*config), GFP_KERNEL);
 	if (!config)
 		return -ENOMEM;
 
Signature · 1 line
2.10.0
Applied
#955 lore raw

Re: [PATCH 1/5] drm/amdgpu: Use kmalloc_array() in amdgpu_debugfs_gca_config_read()

Quoted 10 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sun, 18 Sep 2016 17:00:52 +0200

A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

Applied. thanks.

Quoted 24 lines
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +1 -2
index df7ab245..2709ebd 100644
@@ -2438,7 +2438,7 @@ static ssize_t amdgpu_debugfs_gca_config_read(struct file *f, char __user *buf,
        if (size & 0x3 || *pos & 0x3)
                return -EINVAL;
 
-       config = kmalloc(256 * sizeof(*config), GFP_KERNEL);
+       config = kmalloc_array(256, sizeof(*config), GFP_KERNEL);
        if (!config)
                return -ENOMEM;
 
--

2.10.0

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#956 lore raw

PATCH 2/5 drm/amdgpu: Improve determination of sizes in two functions

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sun, 18 Sep 2016 17:24:47 +0200

Replace the specification of data structures by pointer dereferences as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +3 -1
index 2709ebd..96a2457 100644
@@ -855,7 +855,7 @@ static void amdgpu_atombios_fini(struct amdgpu_device *adev)
 static int amdgpu_atombios_init(struct amdgpu_device *adev)
 {
 	struct card_info *atom_card_info -	    kzalloc(sizeof(struct card_info), GFP_KERNEL);
+	    kzalloc(sizeof(*atom_card_info), GFP_KERNEL);
 
 	if (!atom_card_info)
 		return -ENOMEM;
@@ -1224,7 +1224,8 @@ static int amdgpu_early_init(struct amdgpu_device *adev)
 	}
 
 	adev->ip_block_status = kcalloc(adev->num_ip_blocks,
-					sizeof(struct amdgpu_ip_block_status), GFP_KERNEL);
+					sizeof(*adev->ip_block_status),
+					GFP_KERNEL);
 	if (adev->ip_block_status = NULL)
 		return -ENOMEM;
 
Signature · 1 line
2.10.0
#957 lore raw

PATCH 3/5 drm/amdgpu: Rename a jump label in amdgpu_debugfs_regs_read()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sun, 18 Sep 2016 17:35:24 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +3 -4
index 96a2457..2b8ba97 100644
@@ -2208,13 +2208,13 @@ static ssize_t amdgpu_debugfs_regs_read(struct file *f, char __user *buf,
 		uint32_t value;
 
 		if (*pos > adev->rmmio_size)
-			goto end;
+			goto check_bank;
 
 		value = RREG32(*pos >> 2);
 		r = put_user(value, (uint32_t *)buf);
 		if (r) {
 			result = r;
-			goto end;
+			goto check_bank;
 		}
 
 		result += 4;
@@ -2222,8 +2222,7 @@ static ssize_t amdgpu_debugfs_regs_read(struct file *f, char __user *buf,
 		*pos += 4;
 		size -= 4;
 	}
-
-end:
+ check_bank:
 	if (use_bank) {
 		amdgpu_gfx_select_se_sh(adev, 0xffffffff, 0xffffffff, 0xffffffff);
 		mutex_unlock(&adev->grbm_idx_mutex);
Signature · 1 line
2.10.0
#958 lore raw

PATCH 4/5 drm/amdgpu: Rename a jump label in amdgpu_device_init()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sun, 18 Sep 2016 17:50:09 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +10 -11
index 2b8ba97..fed4854 100644
@@ -1566,18 +1566,18 @@ int amdgpu_device_init(struct amdgpu_device *adev,
 	/* Read BIOS */
 	if (!amdgpu_get_bios(adev)) {
 		r = -EINVAL;
-		goto failed;
+		goto check_runtime;
 	}
 	/* Must be an ATOMBIOS */
 	if (!adev->is_atom_bios) {
 		dev_err(adev->dev, "Expecting atombios for GPU\n");
 		r = -EINVAL;
-		goto failed;
+		goto check_runtime;
 	}
 	r = amdgpu_atombios_init(adev);
 	if (r) {
 		dev_err(adev->dev, "amdgpu_atombios_init failed\n");
-		goto failed;
+		goto check_runtime;
 	}
 
 	/* See if the asic supports SR-IOV */
@@ -1595,7 +1595,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
 		if (!adev->bios) {
 			dev_err(adev->dev, "Card not posted and no BIOS - ignoring\n");
 			r = -EINVAL;
-			goto failed;
+			goto check_runtime;
 		}
 		DRM_INFO("GPU not posted. posting now...\n");
 		amdgpu_atom_asic_init(adev->mode_info.atom_context);
@@ -1605,7 +1605,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
 	r = amdgpu_atombios_get_clock_info(adev);
 	if (r) {
 		dev_err(adev->dev, "amdgpu_atombios_get_clock_info failed\n");
-		goto failed;
+		goto check_runtime;
 	}
 	/* init i2c buses */
 	amdgpu_atombios_i2c_init(adev);
@@ -1614,7 +1614,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
 	r = amdgpu_fence_driver_init(adev);
 	if (r) {
 		dev_err(adev->dev, "amdgpu_fence_driver_init failed\n");
-		goto failed;
+		goto check_runtime;
 	}
 
 	/* init the mode config */
@@ -1624,7 +1624,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
 	if (r) {
 		dev_err(adev->dev, "amdgpu_init failed\n");
 		amdgpu_fini(adev);
-		goto failed;
+		goto check_runtime;
 	}
 
 	adev->accel_working = true;
@@ -1634,7 +1634,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
 	r = amdgpu_ib_pool_init(adev);
 	if (r) {
 		dev_err(adev->dev, "IB initialization failed (%d).\n", r);
-		goto failed;
+		goto check_runtime;
 	}
 
 	r = amdgpu_ib_ring_tests(adev);
@@ -1682,12 +1682,11 @@ int amdgpu_device_init(struct amdgpu_device *adev,
 	r = amdgpu_late_init(adev);
 	if (r) {
 		dev_err(adev->dev, "amdgpu_late_init failed\n");
-		goto failed;
+		goto check_runtime;
 	}
 
 	return 0;
-
-failed:
+ check_runtime:
 	if (runtime)
 		vga_switcheroo_fini_domain_pm_ops(adev->dev);
 	return r;
Signature · 1 line
2.10.0
#959 lore raw

RE: [PATCH 4/5] drm/amdgpu: Rename a jump label in amdgpu_device_init()

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTRiBNYXJrdXMgRWxmcmluZyBb bWFpbHRvOmVsZnJpbmdAdXNlcnMuc291cmNlZm9yZ2UubmV0XQ0KPiBTZW50OiBTdW5kYXksIFNl cHRlbWJlciAxOCwgMjAxNiAxMjo1MyBQTQ0KPiBUbzogZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNr dG9wLm9yZzsgRGV1Y2hlciwgQWxleGFuZGVyOyBLb2VuaWcsIENocmlzdGlhbjsNCj4gWmhvdSwg RGF2aWQoQ2h1bk1pbmcpOyBEYXZpZCBBaXJsaWU7IExpdSwgTW9uazsgU3REZW5pcywgVG9tDQo+ IENjOiBMS01MOyBrZXJuZWwtamFuaXRvcnNAdmdlci5rZXJuZWwub3JnOyBKdWxpYSBMYXdhbGwN Cj4gU3ViamVjdDogW1BBVENIIDQvNV0gZHJtL2FtZGdwdTogUmVuYW1lIGEganVtcCBsYWJlbCBp bg0KPiBhbWRncHVfZGV2aWNlX2luaXQoKQ0KPiANCj4gRnJvbTogTWFya3VzIEVsZnJpbmcgPGVs ZnJpbmdAdXNlcnMuc291cmNlZm9yZ2UubmV0Pg0KPiBEYXRlOiBTdW4sIDE4IFNlcCAyMDE2IDE3 OjUwOjA5ICswMjAwDQo+IA0KPiBBZGp1c3QganVtcCBsYWJlbHMgYWNjb3JkaW5nIHRvIHRoZSBj dXJyZW50IExpbnV4IGNvZGluZyBzdHlsZSBjb252ZW50aW9uLg0KPiANCj4gU2lnbmVkLW9mZi1i eTogTWFya3VzIEVsZnJpbmcgPGVsZnJpbmdAdXNlcnMuc291cmNlZm9yZ2UubmV0Pg0KPiAtLS0N Cj4gIGRyaXZlcnMvZ3B1L2RybS9hbWQvYW1kZ3B1L2FtZGdwdV9kZXZpY2UuYyB8IDIxICsrKysr KysrKystLS0tLS0tLS0tDQo+IC0NCj4gIDEgZmlsZSBjaGFuZ2VkLCAxMCBpbnNlcnRpb25zKCsp LCAxMSBkZWxldGlvbnMoLSkNCj4gDQo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2dwdS9kcm0vYW1k L2FtZGdwdS9hbWRncHVfZGV2aWNlLmMNCj4gYi9kcml2ZXJzL2dwdS9kcm0vYW1kL2FtZGdwdS9h bWRncHVfZGV2aWNlLmMNCj4gaW5kZXggMmI4YmE5Ny4uZmVkNDg1NCAxMDA2NDQNCj4gLS0tIGEv ZHJpdmVycy9ncHUvZHJtL2FtZC9hbWRncHUvYW1kZ3B1X2RldmljZS5jDQo+ICsrKyBiL2RyaXZl cnMvZ3B1L2RybS9hbWQvYW1kZ3B1L2FtZGdwdV9kZXZpY2UuYw0KPiBAQCAtMTU2NiwxOCArMTU2 NiwxOCBAQCBpbnQgYW1kZ3B1X2RldmljZV9pbml0KHN0cnVjdCBhbWRncHVfZGV2aWNlDQo+ICph ZGV2LA0KPiAgCS8qIFJlYWQgQklPUyAqLw0KPiAgCWlmICghYW1kZ3B1X2dldF9iaW9zKGFkZXYp KSB7DQo+ICAJCXIgPSAtRUlOVkFMOw0KPiAtCQlnb3RvIGZhaWxlZDsNCj4gKwkJZ290byBjaGVj a19ydW50aW1lOw0KDQpOQUNLLiAgRmFpbGVkIGlzIGEgbW9yZSBhcHByb3ByaWF0ZSBsYWJlbCBo ZXJlLiAgVGhlIHJ1bnRpbWUgY2hlY2sgaXMganVzdCBwYXJ0IG9mIHRoZSBmYWlsdXJlIGNsZWFu dXAuDQoNCkFsZXgNCg0KPiAgCX0NCj4gIAkvKiBNdXN0IGJlIGFuIEFUT01CSU9TICovDQo+ICAJ aWYgKCFhZGV2LT5pc19hdG9tX2Jpb3MpIHsNCj4gIAkJZGV2X2VycihhZGV2LT5kZXYsICJFeHBl Y3RpbmcgYXRvbWJpb3MgZm9yIEdQVVxuIik7DQo+ICAJCXIgPSAtRUlOVkFMOw0KPiAtCQlnb3Rv IGZhaWxlZDsNCj4gKwkJZ290byBjaGVja19ydW50aW1lOw0KPiAgCX0NCj4gIAlyID0gYW1kZ3B1 X2F0b21iaW9zX2luaXQoYWRldik7DQo+ICAJaWYgKHIpIHsNCj4gIAkJZGV2X2VycihhZGV2LT5k ZXYsICJhbWRncHVfYXRvbWJpb3NfaW5pdCBmYWlsZWRcbiIpOw0KPiAtCQlnb3RvIGZhaWxlZDsN Cj4gKwkJZ290byBjaGVja19ydW50aW1lOw0KPiAgCX0NCj4gDQo+ICAJLyogU2VlIGlmIHRoZSBh c2ljIHN1cHBvcnRzIFNSLUlPViAqLw0KPiBAQCAtMTU5NSw3ICsxNTk1LDcgQEAgaW50IGFtZGdw dV9kZXZpY2VfaW5pdChzdHJ1Y3QgYW1kZ3B1X2RldmljZQ0KPiAqYWRldiwNCj4gIAkJaWYgKCFh ZGV2LT5iaW9zKSB7DQo+ICAJCQlkZXZfZXJyKGFkZXYtPmRldiwgIkNhcmQgbm90IHBvc3RlZCBh bmQgbm8gQklPUyAtDQo+IGlnbm9yaW5nXG4iKTsNCj4gIAkJCXIgPSAtRUlOVkFMOw0KPiAtCQkJ Z290byBmYWlsZWQ7DQo+ICsJCQlnb3RvIGNoZWNrX3J1bnRpbWU7DQo+ICAJCX0NCj4gIAkJRFJN X0lORk8oIkdQVSBub3QgcG9zdGVkLiBwb3N0aW5nIG5vdy4uLlxuIik7DQo+ICAJCWFtZGdwdV9h dG9tX2FzaWNfaW5pdChhZGV2LT5tb2RlX2luZm8uYXRvbV9jb250ZXh0KTsNCj4gQEAgLTE2MDUs NyArMTYwNSw3IEBAIGludCBhbWRncHVfZGV2aWNlX2luaXQoc3RydWN0IGFtZGdwdV9kZXZpY2UN Cj4gKmFkZXYsDQo+ICAJciA9IGFtZGdwdV9hdG9tYmlvc19nZXRfY2xvY2tfaW5mbyhhZGV2KTsN Cj4gIAlpZiAocikgew0KPiAgCQlkZXZfZXJyKGFkZXYtPmRldiwgImFtZGdwdV9hdG9tYmlvc19n ZXRfY2xvY2tfaW5mbw0KPiBmYWlsZWRcbiIpOw0KPiAtCQlnb3RvIGZhaWxlZDsNCj4gKwkJZ290 byBjaGVja19ydW50aW1lOw0KPiAgCX0NCj4gIAkvKiBpbml0IGkyYyBidXNlcyAqLw0KPiAgCWFt ZGdwdV9hdG9tYmlvc19pMmNfaW5pdChhZGV2KTsNCj4gQEAgLTE2MTQsNyArMTYxNCw3IEBAIGlu dCBhbWRncHVfZGV2aWNlX2luaXQoc3RydWN0IGFtZGdwdV9kZXZpY2UNCj4gKmFkZXYsDQo+ICAJ ciA9IGFtZGdwdV9mZW5jZV9kcml2ZXJfaW5pdChhZGV2KTsNCj4gIAlpZiAocikgew0KPiAgCQlk ZXZfZXJyKGFkZXYtPmRldiwgImFtZGdwdV9mZW5jZV9kcml2ZXJfaW5pdCBmYWlsZWRcbiIpOw0K PiAtCQlnb3RvIGZhaWxlZDsNCj4gKwkJZ290byBjaGVja19ydW50aW1lOw0KPiAgCX0NCj4gDQo+ ICAJLyogaW5pdCB0aGUgbW9kZSBjb25maWcgKi8NCj4gQEAgLTE2MjQsNyArMTYyNCw3IEBAIGlu dCBhbWRncHVfZGV2aWNlX2luaXQoc3RydWN0IGFtZGdwdV9kZXZpY2UNCj4gKmFkZXYsDQo+ICAJ aWYgKHIpIHsNCj4gIAkJZGV2X2VycihhZGV2LT5kZXYsICJhbWRncHVfaW5pdCBmYWlsZWRcbiIp Ow0KPiAgCQlhbWRncHVfZmluaShhZGV2KTsNCj4gLQkJZ290byBmYWlsZWQ7DQo+ICsJCWdvdG8g Y2hlY2tfcnVudGltZTsNCj4gIAl9DQo+IA0KPiAgCWFkZXYtPmFjY2VsX3dvcmtpbmcgPSB0cnVl Ow0KPiBAQCAtMTYzNCw3ICsxNjM0LDcgQEAgaW50IGFtZGdwdV9kZXZpY2VfaW5pdChzdHJ1Y3Qg YW1kZ3B1X2RldmljZQ0KPiAqYWRldiwNCj4gIAlyID0gYW1kZ3B1X2liX3Bvb2xfaW5pdChhZGV2 KTsNCj4gIAlpZiAocikgew0KPiAgCQlkZXZfZXJyKGFkZXYtPmRldiwgIklCIGluaXRpYWxpemF0 aW9uIGZhaWxlZCAoJWQpLlxuIiwgcik7DQo+IC0JCWdvdG8gZmFpbGVkOw0KPiArCQlnb3RvIGNo ZWNrX3J1bnRpbWU7DQo+ICAJfQ0KPiANCj4gIAlyID0gYW1kZ3B1X2liX3JpbmdfdGVzdHMoYWRl dik7DQo+IEBAIC0xNjgyLDEyICsxNjgyLDExIEBAIGludCBhbWRncHVfZGV2aWNlX2luaXQoc3Ry dWN0IGFtZGdwdV9kZXZpY2UNCj4gKmFkZXYsDQo+ICAJciA9IGFtZGdwdV9sYXRlX2luaXQoYWRl dik7DQo+ICAJaWYgKHIpIHsNCj4gIAkJZGV2X2VycihhZGV2LT5kZXYsICJhbWRncHVfbGF0ZV9p bml0IGZhaWxlZFxuIik7DQo+IC0JCWdvdG8gZmFpbGVkOw0KPiArCQlnb3RvIGNoZWNrX3J1bnRp bWU7DQo+ICAJfQ0KPiANCj4gIAlyZXR1cm4gMDsNCj4gLQ0KPiAtZmFpbGVkOg0KPiArIGNoZWNr X3J1bnRpbWU6DQo+ICAJaWYgKHJ1bnRpbWUpDQo+ICAJCXZnYV9zd2l0Y2hlcm9vX2ZpbmlfZG9t YWluX3BtX29wcyhhZGV2LT5kZXYpOw0KPiAgCXJldHVybiByOw0KPiAtLQ0KPiAyLjEwLjANCg0K

#960 lore raw

PATCH 5/5 drm/amdgpu: Adjust checks for null pointers in nine functions

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sun, 18 Sep 2016 18:32:28 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* The script "checkpatch.pl" can point information out like the following.

Comparison to NULL could be written !…

Thus fix the affected source code places.

* Do also not use curly brackets at corresponding source code places where a single statement should be sufficient.

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 33 +++++++++++++++---------------
 1 file changed, 16 insertions(+), 17 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +16 -17
index fed4854..b5b7cfb 100644
@@ -251,7 +251,7 @@ static int amdgpu_vram_scratch_init(struct amdgpu_device *adev)
 {
 	int r;
 
-	if (adev->vram_scratch.robj == NULL) {
+	if (!adev->vram_scratch.robj) {
 		r = amdgpu_bo_create(adev, AMDGPU_GPU_PAGE_SIZE,
 				     PAGE_SIZE, true, AMDGPU_GEM_DOMAIN_VRAM,
 				     AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED,
@@ -283,9 +283,9 @@ static void amdgpu_vram_scratch_fini(struct amdgpu_device *adev)
 {
 	int r;
 
-	if (adev->vram_scratch.robj == NULL) {
+	if (!adev->vram_scratch.robj)
 		return;
-	}
+
 	r = amdgpu_bo_reserve(adev->vram_scratch.robj, false);
 	if (likely(r == 0)) {
 		amdgpu_bo_kunmap(adev->vram_scratch.robj);
@@ -359,9 +359,9 @@ static int amdgpu_doorbell_init(struct amdgpu_device *adev)
 		return -EINVAL;
 
 	adev->doorbell.ptr = ioremap(adev->doorbell.base, adev->doorbell.num_doorbells * sizeof(u32));
-	if (adev->doorbell.ptr == NULL) {
+	if (!adev->doorbell.ptr)
 		return -ENOMEM;
-	}
+
 	DRM_INFO("doorbell mmio base: 0x%08X\n", (uint32_t)adev->doorbell.base);
 	DRM_INFO("doorbell mmio size: %u\n", (unsigned)adev->doorbell.size);
 
@@ -456,7 +456,7 @@ static int amdgpu_wb_init(struct amdgpu_device *adev)
 {
 	int r;
 
-	if (adev->wb.wb_obj == NULL) {
+	if (!adev->wb.wb_obj) {
 		r = amdgpu_bo_create(adev, AMDGPU_MAX_WB * 4, PAGE_SIZE, true,
 				     AMDGPU_GEM_DOMAIN_GTT, 0,  NULL, NULL,
 				     &adev->wb.wb_obj);
@@ -657,7 +657,7 @@ int amdgpu_dummy_page_init(struct amdgpu_device *adev)
 	if (adev->dummy_page.page)
 		return 0;
 	adev->dummy_page.page = alloc_page(GFP_DMA32 | GFP_KERNEL | __GFP_ZERO);
-	if (adev->dummy_page.page == NULL)
+	if (!adev->dummy_page.page)
 		return -ENOMEM;
 	adev->dummy_page.addr = pci_map_page(adev->pdev, adev->dummy_page.page,
 					0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
@@ -679,7 +679,7 @@ int amdgpu_dummy_page_init(struct amdgpu_device *adev)
  */
 void amdgpu_dummy_page_fini(struct amdgpu_device *adev)
 {
-	if (adev->dummy_page.page == NULL)
+	if (!adev->dummy_page.page)
 		return;
 	pci_unmap_page(adev->pdev, adev->dummy_page.addr,
 			PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
@@ -1226,10 +1226,10 @@ static int amdgpu_early_init(struct amdgpu_device *adev)
 	adev->ip_block_status = kcalloc(adev->num_ip_blocks,
 					sizeof(*adev->ip_block_status),
 					GFP_KERNEL);
-	if (adev->ip_block_status == NULL)
+	if (!adev->ip_block_status)
 		return -ENOMEM;
 
-	if (adev->ip_blocks == NULL) {
+	if (!adev->ip_blocks) {
 		DRM_ERROR("No IP blocks found!\n");
 		return r;
 	}
@@ -1525,9 +1525,9 @@ int amdgpu_device_init(struct amdgpu_device *adev,
 	adev->rmmio_base = pci_resource_start(adev->pdev, 5);
 	adev->rmmio_size = pci_resource_len(adev->pdev, 5);
 	adev->rmmio = ioremap(adev->rmmio_base, adev->rmmio_size);
-	if (adev->rmmio == NULL) {
+	if (!adev->rmmio)
 		return -ENOMEM;
-	}
+
 	DRM_INFO("register mmio base: 0x%08X\n", (uint32_t)adev->rmmio_base);
 	DRM_INFO("register mmio size: %u\n", (unsigned)adev->rmmio_size);
 
@@ -1542,7 +1542,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
 			break;
 		}
 	}
-	if (adev->rio_mem == NULL)
+	if (!adev->rio_mem)
 		DRM_ERROR("Unable to find PCI I/O BAR\n");
 
 	/* early init functions */
@@ -1758,9 +1758,8 @@ int amdgpu_suspend_kms(struct drm_device *dev, bool suspend, bool fbcon)
 	struct drm_connector *connector;
 	int r;
 
-	if (dev == NULL || dev->dev_private == NULL) {
+	if (!dev || !dev->dev_private)
 		return -ENODEV;
-	}
 
 	adev = dev->dev_private;
 
@@ -1791,9 +1790,9 @@ int amdgpu_suspend_kms(struct drm_device *dev, bool suspend, bool fbcon)
 			}
 		}
 
-		if (rfb == NULL || rfb->obj == NULL) {
+		if (!rfb || !rfb->obj)
 			continue;
-		}
+
 		robj = gem_to_amdgpu_bo(rfb->obj);
 		/* don't unpin kernel fb objects */
 		if (!amdgpu_fbdev_robj_is_fb(adev, robj)) {
Signature · 1 line
2.10.0
#961 lore raw

Re: [PATCH 0/5] drm/amdgpu: Fine-tuning for several function implementations

In reply to SF Markus Elfring
Quoted 12 lines

Date: Sun, 18 Sep 2016 18:38:48 +0200

Some update suggestions were taken into account
from static source code analysis.

Markus Elfring (5):
Use kmalloc_array() in amdgpu_debugfs_gca_config_read() Improve determination of sizes in two functions Rename a jump label in amdgpu_debugfs_regs_read() Rename a jump label in amdgpu_device_init() Adjust checks for null pointers in nine functions

Quoted 2 lines
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 68 +++++++++++++++---------------
 1 file changed, 33 insertions(+), 35 deletions(-)

Is this patch series still in review queues?

Regards,
Markus

#962 lore raw

Re: [PATCH 0/5] drm/amdgpu: Fine-tuning for several function implementations

Quoted 13 lines · Markus Elfring
Quoted 13 lines

Date: Sun, 18 Sep 2016 18:38:48 +0200

Some update suggestions were taken into account
from static source code analysis.

Markus Elfring (5):
Use kmalloc_array() in amdgpu_debugfs_gca_config_read() Improve determination of sizes in two functions Rename a jump label in amdgpu_debugfs_regs_read() Rename a jump label in amdgpu_device_init() Adjust checks for null pointers in nine functions

Quoted 4 lines
Quoted 2 lines
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 68 +++++++++++++++---------------
 1 file changed, 33 insertions(+), 35 deletions(-)

Is this patch series still in review queues?

Doesn't look like I ever received it. Can you resend?

Alex

Quoted 3 lines

Regards,
Markus

#963 lore raw

cover GPU-DRM: Fine-tuning for four function implementations

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Mon, 19 Sep 2016 17:47:37 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (5):
Use kmalloc_array() in drm_legacy_addbufs_pci()
Replace two kzalloc() calls by kcalloc() in drm_legacy_addbufs_pci() Replace a kzalloc() call by kcalloc() in drm_legacy_addbufs_agp() Replace a kzalloc() call by kcalloc() in drm_legacy_addbufs_sg() Rename a jump label in drm_legacy_mapbufs()

 drivers/gpu/drm/drm_bufs.c | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)
Signature · 1 line
2.10.0
#964 lore raw

PATCH 1/5 GPU-DRM: Use kmalloc_array() in drm_legacy_addbufs_pci()

From: Markus Elfring <[email protected]>
Date: Mon, 19 Sep 2016 17:07:06 +0200

A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

---
 drivers/gpu/drm/drm_bufs.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/gpu/drm/drm_bufs.c +3 -2
index 3219151..ed33f43 100644
@@ -923,8 +923,9 @@ int drm_legacy_addbufs_pci(struct drm_device *dev,
 	/* Keep the original pagelist until we know all the allocations
 	 * have succeeded
 	 */
-	temp_pagelist = kmalloc((dma->page_count + (count << page_order)) *
-			       sizeof(*dma->pagelist), GFP_KERNEL);
+	temp_pagelist = kmalloc_array(dma->page_count + (count << page_order),
+				      sizeof(*dma->pagelist),
+				      GFP_KERNEL);
 	if (!temp_pagelist) {
 		kfree(entry->buflist);
 		kfree(entry->seglist);
Signature · 1 line
2.10.0
#965 lore raw

PATCH 2/5 GPU-DRM: Replace two kzalloc() calls by kcalloc() in drm_legacy_addbufs_pci()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Mon, 19 Sep 2016 17:17:34 +0200

The script "checkpatch.pl" can point information out like the following.

WARNING: Prefer kcalloc over kzalloc with multiply

Thus fix the affected source code places.

---
 drivers/gpu/drm/drm_bufs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/drm_bufs.c +2 -2
index ed33f43..8a31dac 100644
@@ -905,14 +905,14 @@ int drm_legacy_addbufs_pci(struct drm_device *dev,
 		return -EINVAL;
 	}
 
-	entry->buflist = kzalloc(count * sizeof(*entry->buflist), GFP_KERNEL);
+	entry->buflist = kcalloc(count, sizeof(*entry->buflist), GFP_KERNEL);
 	if (!entry->buflist) {
 		mutex_unlock(&dev->struct_mutex);
 		atomic_dec(&dev->buf_alloc);
 		return -ENOMEM;
 	}
 
-	entry->seglist = kzalloc(count * sizeof(*entry->seglist), GFP_KERNEL);
+	entry->seglist = kcalloc(count, sizeof(*entry->seglist), GFP_KERNEL);
 	if (!entry->seglist) {
 		kfree(entry->buflist);
 		mutex_unlock(&dev->struct_mutex);
Signature · 1 line
2.10.0
#966 lore raw

PATCH 3/5 GPU-DRM: Replace a kzalloc() call by kcalloc() in drm_legacy_addbufs_agp()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Mon, 19 Sep 2016 17:24:20 +0200

The script "checkpatch.pl" can point information out like the following.

WARNING: Prefer kcalloc over kzalloc with multiply

Thus fix the affected source code place.

---
 drivers/gpu/drm/drm_bufs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/drm_bufs.c +1 -1
index 8a31dac..36dd685 100644
@@ -755,7 +755,7 @@ int drm_legacy_addbufs_agp(struct drm_device *dev,
 		return -EINVAL;
 	}
 
-	entry->buflist = kzalloc(count * sizeof(*entry->buflist), GFP_KERNEL);
+	entry->buflist = kcalloc(count, sizeof(*entry->buflist), GFP_KERNEL);
 	if (!entry->buflist) {
 		mutex_unlock(&dev->struct_mutex);
 		atomic_dec(&dev->buf_alloc);
Signature · 1 line
2.10.0
#967 lore raw

PATCH 4/5 GPU-DRM: Replace a kzalloc() call by kcalloc() in drm_legacy_addbufs_sg()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Mon, 19 Sep 2016 17:30:31 +0200

The script "checkpatch.pl" can point information out like the following.

WARNING: Prefer kcalloc over kzalloc with multiply

Thus fix the affected source code place.

---
 drivers/gpu/drm/drm_bufs.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/gpu/drm/drm_bufs.c +1 -2
index 36dd685..adb1dd7 100644
@@ -1117,8 +1117,7 @@ static int drm_legacy_addbufs_sg(struct drm_device *dev,
 		return -EINVAL;
 	}
 
-	entry->buflist = kzalloc(count * sizeof(*entry->buflist),
-				GFP_KERNEL);
+	entry->buflist = kcalloc(count, sizeof(*entry->buflist), GFP_KERNEL);
 	if (!entry->buflist) {
 		mutex_unlock(&dev->struct_mutex);
 		atomic_dec(&dev->buf_alloc);
Signature · 1 line
2.10.0
#968 lore raw

Re: [PATCH 4/5] GPU-DRM: Replace a kzalloc() call by kcalloc() in drm_legacy_addbufs_sg()

Quoted 10 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Mon, 19 Sep 2016 17:30:31 +0200

The script "checkpatch.pl" can point information out like the following.

WARNING: Prefer kcalloc over kzalloc with multiply

Thus fix the affected source code place.

Merged patches 1-4. I agree with Jani that changing jump labels is a pure bikeshed, so didn't apply them.

Also I'll repeat that imo checkpatch patches are great to get started, but it's much better to do more involved work. Both since that tends to be more interesting, and fixing all the checkpatch issues will rob the next newbies of some great starting opportunity. Which means from now on I'll only selectively apply your checkpatch patches.

We have todo list with some ideas at:

https://www.x.org/wiki/DRMJanitors/

Thanks, Daniel

Quoted 25 lines
---
 drivers/gpu/drm/drm_bufs.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/gpu/drm/drm_bufs.c +1 -2
index 36dd685..adb1dd7 100644
@@ -1117,8 +1117,7 @@ static int drm_legacy_addbufs_sg(struct drm_device *dev,
 		return -EINVAL;
 	}
 
-	entry->buflist = kzalloc(count * sizeof(*entry->buflist),
-				GFP_KERNEL);
+	entry->buflist = kcalloc(count, sizeof(*entry->buflist), GFP_KERNEL);
 	if (!entry->buflist) {
 		mutex_unlock(&dev->struct_mutex);
 		atomic_dec(&dev->buf_alloc);
Signature · 6 lines
2.10.0

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Signature · 3 lines
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
#969 lore raw

PATCH 5/5 GPU-DRM: Rename a jump label in drm_legacy_mapbufs()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Mon, 19 Sep 2016 17:37:27 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/gpu/drm/drm_bufs.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)
drivers/gpu/drm/drm_bufs.c +7 -7
index adb1dd7..0d5ee1e 100644
@@ -1476,7 +1476,7 @@ int drm_legacy_mapbufs(struct drm_device *dev, void *data,
 
 			if (!map) {
 				retcode = -EINVAL;
-				goto done;
+				goto status_indication;
 			}
 			virtual = vm_mmap(file_priv->filp, 0, map->size,
 					  PROT_READ | PROT_WRITE,
@@ -1490,7 +1490,7 @@ int drm_legacy_mapbufs(struct drm_device *dev, void *data,
 		if (virtual > -1024UL) {
 			/* Real error */
 			retcode = (signed long)virtual;
-			goto done;
+			goto status_indication;
 		}
 		request->virtual = (void __user *)virtual;
 
@@ -1499,28 +1499,28 @@ int drm_legacy_mapbufs(struct drm_device *dev, void *data,
 					 &dma->buflist[i]->idx,
 					 sizeof(request->list[0].idx))) {
 				retcode = -EFAULT;
-				goto done;
+				goto status_indication;
 			}
 			if (copy_to_user(&request->list[i].total,
 					 &dma->buflist[i]->total,
 					 sizeof(request->list[0].total))) {
 				retcode = -EFAULT;
-				goto done;
+				goto status_indication;
 			}
 			if (copy_to_user(&request->list[i].used,
 					 &zero, sizeof(zero))) {
 				retcode = -EFAULT;
-				goto done;
+				goto status_indication;
 			}
 			address = virtual + dma->buflist[i]->offset;	/* *** */
 			if (copy_to_user(&request->list[i].address,
 					 &address, sizeof(address))) {
 				retcode = -EFAULT;
-				goto done;
+				goto status_indication;
 			}
 		}
 	}
-      done:
+ status_indication:
 	request->count = dma->buf_count;
 	DRM_DEBUG("%d buffers, retcode = %d\n", request->count, retcode);
 
Signature · 1 line
2.10.0
#970 lore raw

cover GPU-DRM-GMA500: Fine-tuning for two function implementations

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 20 Sep 2016 10:48:04 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (6):
Use kmalloc_array() in mid_get_vbt_data_r10()
Rename a jump label in mid_get_vbt_data_r10()
Move a variable assignment in mid_get_vbt_data_r10()
Fix indentation for a function call parameter in mid_get_vbt_data_r10() One error message less for a GCT revision mismatch in mid_get_vbt_data() Rename a jump label in mid_get_vbt_data()

 drivers/gpu/drm/gma500/mid_bios.c | 26 ++++++++++++++------------
 1 file changed, 14 insertions(+), 12 deletions(-)
Signature · 1 line
2.10.0
#971 lore raw

PATCH 1/6 GPU-DRM-GMA500: Use kmalloc_array() in mid_get_vbt_data_r10()

From: Markus Elfring <[email protected]>
Date: Tue, 20 Sep 2016 08:54:07 +0200

A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

---
 drivers/gpu/drm/gma500/mid_bios.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/gma500/mid_bios.c +1 -1
index d75ecb3..a833568 100644
@@ -235,7 +235,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr)
 	if (read_vbt_r10(addr, &vbt))
 		return -1;
 
-	gct = kmalloc(sizeof(*gct) * vbt.panel_count, GFP_KERNEL);
+	gct = kmalloc_array(vbt.panel_count, sizeof(*gct), GFP_KERNEL);
 	if (!gct)
 		return -1;
 
Signature · 1 line
2.10.0
#972 lore raw

Re: [PATCH 1/6] GPU-DRM-GMA500: Use kmalloc_array() in mid_get_vbt_data_r10()

Quoted 8 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 20 Sep 2016 08:54:07 +0200

A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

Did you test this running on the hardware?

BR,
Jani.

Quoted 18 lines
---
 drivers/gpu/drm/gma500/mid_bios.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/gma500/mid_bios.c +1 -1
index d75ecb3..a833568 100644
@@ -235,7 +235,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr)
 	if (read_vbt_r10(addr, &vbt))
 		return -1;
 
-	gct = kmalloc(sizeof(*gct) * vbt.panel_count, GFP_KERNEL);
+	gct = kmalloc_array(vbt.panel_count, sizeof(*gct), GFP_KERNEL);
 	if (!gct)
 		return -1;
Signature · 1 line
Jani Nikula, Intel Open Source Technology Center
#973 lore raw

Re: GPU-DRM-GMA500: Use kmalloc_array() in mid_get_vbt_data_r10()

Quoted 7 lines
Quoted 5 lines

A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

Did you test this running on the hardware?

No. - My "test computer" does not provide the corresponding hardware for the affected driver source files.

Regards,
Markus

#974 lore raw

PATCH 2/6 GPU-DRM-GMA500: Rename a jump label in mid_get_vbt_data_r10()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 20 Sep 2016 09:09:10 +0200

Adjust a jump label according to the current Linux coding style convention.

---
 drivers/gpu/drm/gma500/mid_bios.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/gma500/mid_bios.c +2 -2
index a833568..cf4e605 100644
@@ -242,7 +242,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr)
 	gct_virtual = ioremap(addr + sizeof(vbt),
 			sizeof(*gct) * vbt.panel_count);
 	if (!gct_virtual)
-		goto out;
+		goto free_gct;
 	memcpy_fromio(gct, gct_virtual, sizeof(*gct));
 	iounmap(gct_virtual);
 
@@ -270,7 +270,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr)
 	dp_ti->vsync_pulse_width_lo = ti->vsync_pulse_width_lo;
 
 	ret = 0;
-out:
+ free_gct:
 	kfree(gct);
 	return ret;
 }
Signature · 1 line
2.10.0
#975 lore raw

Re: [PATCH 2/6] GPU-DRM-GMA500: Rename a jump label in mid_get_vbt_data_r10()

Quoted 4 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 20 Sep 2016 09:09:10 +0200

Adjust a jump label according to the current Linux coding style convention.

Generally, please don't send patches to fix checkpatch issues in existing code. Moreover, this particular "convention" is just something someone sneaked into CodingStyle, it's subjective, and it's probably going to be removed soon.

NAK.

BR,
Jani.

Quoted 28 lines
---
 drivers/gpu/drm/gma500/mid_bios.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/gma500/mid_bios.c +2 -2
index a833568..cf4e605 100644
@@ -242,7 +242,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr)
 	gct_virtual = ioremap(addr + sizeof(vbt),
 			sizeof(*gct) * vbt.panel_count);
 	if (!gct_virtual)
-		goto out;
+		goto free_gct;
 	memcpy_fromio(gct, gct_virtual, sizeof(*gct));
 	iounmap(gct_virtual);
 
@@ -270,7 +270,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr)
 	dp_ti->vsync_pulse_width_lo = ti->vsync_pulse_width_lo;
 
 	ret = 0;
-out:
+ free_gct:
 	kfree(gct);
 	return ret;
 }
Signature · 1 line
Jani Nikula, Intel Open Source Technology Center
#976 lore raw

PATCH 3/6 GPU-DRM-GMA500: Move a variable assignment in mid_get_vbt_data_r10()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 20 Sep 2016 10:32:12 +0200

One local variable was set to an error code before a concrete error situation was detected. Thus move the corresponding assignment into an if branch to indicate a software failure there.

---
 drivers/gpu/drm/gma500/mid_bios.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/gpu/drm/gma500/mid_bios.c +4 -2
index cf4e605..3caee42 100644
@@ -230,7 +230,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr)
 	struct gct_r10 *gct;
 	struct oaktrail_timing_info *dp_ti = &dev_priv->gct_data.DTD;
 	struct gct_r10_timing_info *ti;
-	int ret = -1;
+	int ret;
 
 	if (read_vbt_r10(addr, &vbt))
 		return -1;
@@ -241,8 +241,10 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr)
 
 	gct_virtual = ioremap(addr + sizeof(vbt),
 			sizeof(*gct) * vbt.panel_count);
-	if (!gct_virtual)
+	if (!gct_virtual) {
+		ret = -1;
 		goto free_gct;
+	}
 	memcpy_fromio(gct, gct_virtual, sizeof(*gct));
 	iounmap(gct_virtual);
 
Signature · 1 line
2.10.0
#977 lore raw

PATCH 4/6 GPU-DRM-GMA500: Fix indentation for a function call parameter in mid_get_vbt_data_r10()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 20 Sep 2016 10:34:28 +0200

Adjust the indentation for a single function call parameter here.

---
 drivers/gpu/drm/gma500/mid_bios.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/gma500/mid_bios.c +1 -1
index 3caee42..9004d30 100644
@@ -240,7 +240,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr)
 		return -1;
 
 	gct_virtual = ioremap(addr + sizeof(vbt),
-			sizeof(*gct) * vbt.panel_count);
+			      sizeof(*gct) * vbt.panel_count);
 	if (!gct_virtual) {
 		ret = -1;
 		goto free_gct;
Signature · 1 line
2.10.0
#978 lore raw

PATCH 5/6 GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 20 Sep 2016 10:36:19 +0200

A single error message should be sufficient to inform about the detection of an unknown GCT revision at the end. Thus return after the logging call in this case directly.

---
 drivers/gpu/drm/gma500/mid_bios.c | 1 +
 1 file changed, 1 insertion(+)
drivers/gpu/drm/gma500/mid_bios.c +1 -0
index 9004d30..e5cece0 100644
@@ -320,6 +320,7 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv)
 		break;
 	default:
 		dev_err(dev->dev, "Unknown revision of GCT!\n");
+		return;
 	}
 
 out:
Signature · 1 line
2.10.0
#979 lore raw

Re: [PATCH 5/6] GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

Quoted 6 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 20 Sep 2016 10:36:19 +0200

A single error message should be sufficient to inform about the detection of an unknown GCT revision at the end. Thus return after the logging call in this case directly.

Did you test this?

BR,
Jani.

Quoted 18 lines
---
 drivers/gpu/drm/gma500/mid_bios.c | 1 +
 1 file changed, 1 insertion(+)
drivers/gpu/drm/gma500/mid_bios.c +1 -0
index 9004d30..e5cece0 100644
@@ -320,6 +320,7 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv)
 		break;
 	default:
 		dev_err(dev->dev, "Unknown revision of GCT!\n");
+		return;
 	}
 
 out:
Signature · 1 line
Jani Nikula, Intel Open Source Technology Center
#980 lore raw

Re: GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

Quoted 5 lines
Quoted 3 lines

A single error message should be sufficient to inform about the detection of an unknown GCT revision at the end. Thus return after the logging call in this case directly.

Did you test this?

What is your software development opinion for this update suggestion?

Regards,
Markus

#981 lore raw

Re: [PATCH 5/6] GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

In reply to Jani Nikula
Quoted 10 lines · Jani Nikula
Quoted 6 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 20 Sep 2016 10:36:19 +0200

A single error message should be sufficient to inform about the detection of an unknown GCT revision at the end. Thus return after the logging call in this case directly.

Did you test this?

Don't be a dummy... This is easy to review an it fixes a bug.

I'm fine with you NAKing all these patches based on who they are from. I mostly just delete these without responding because the guy has history of introducing bugs and never listens to feedback. But asking pointless rhetorical questions is not helpful.

A lot of people are CC'd and you're wasting everyone's time by asking questions where you know the answer.

regards,
dan carpenter

#982 lore raw

Re: GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

Quoted 8 lines
Quoted 6 lines
Quoted 3 lines

A single error message should be sufficient to inform about the detection of an unknown GCT revision at the end. Thus return after the logging call in this case directly.

Did you test this?

Don't be a dummy... This is easy to review an it fixes a bug.

Thanks for this kind of constructive feedback.

Quoted 1 line

I'm fine with you NAKing all these patches based on who they are from.

Would you like to clarify such an information a bit more?

Quoted 2 lines

I mostly just delete these without responding because the guy has history of introducing bugs and never listens to feedback.

I admit that I'll stumble on programming mistakes again occasionally as another ordinary free software developer who is struggling various open issues.

I am listening to various feedback. My responses might not be pleasing enough for you. Are you looking for any special information to improve
a corresponding discussion?

Regards,
Markus

#983 lore raw

Re: GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

Quoted 2 lines · SF Markus Elfring

Are you looking for any special information to improve a corresponding discussion?

If you restricted yourself to only sending bug fixes and not sending any more cleanups that would be good.

Please stop sending clean up patches.

regards,
dan carpenter

#984 lore raw

Re: GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

Quoted 2 lines

If you restricted yourself to only sending bug fixes and not sending any more cleanups that would be good.

Thanks for another bit of constructive feedback.

Quoted 1 line

Please stop sending clean up patches.

This will not happen for a while.

I am in the process of informing various developers about some software update opportunities. The proposed changes will belong to a mixture of error categories as you observe them so far usually.

The involved static source code analysis will point more details out for further considerations, won't it?

Regards,
Markus

#985 lore raw

Re: [PATCH 5/6] GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

In reply to Dan Carpenter
Quoted 9 lines · Dan Carpenter

Don't be a dummy... This is easy to review an it fixes a bug.

I'm fine with you NAKing all these patches based on who they are from. I mostly just delete these without responding because the guy has history of introducing bugs and never listens to feedback. But asking pointless rhetorical questions is not helpful.

A lot of people are CC'd and you're wasting everyone's time by asking questions where you know the answer.

Fair enough, sorry for the noise.

To be honest, I did only look at the patches, not who they were from. We have CI for drm/i915, but I don't think it's constructive to keep changing drivers like this where the upstream isn't actively developed and tested. But I digress. It's up to Patrik anyway.

BR,
Jani.

Signature · 1 line
Jani Nikula, Intel Open Source Technology Center
maintainer
#986 lore raw

Re: [PATCH 5/6] GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

Quoted 2 lines · Jani Nikula
Quoted 1 line · Dan Carpenter

Don't be a dummy... This is easy to review an it fixes a bug.

In this particular case it might not be clear that an unknown GCT version causes a complete GCT failure so both messages are useful.

Quoted 9 lines
Quoted 8 lines

I'm fine with you NAKing all these patches based on who they are from. I mostly just delete these without responding because the guy has history of introducing bugs and never listens to feedback. But asking pointless rhetorical questions is not helpful.

A lot of people are CC'd and you're wasting everyone's time by asking questions where you know the answer.

Quoted 6 lines

Fair enough, sorry for the noise.

To be honest, I did only look at the patches, not who they were from. We have CI for drm/i915, but I don't think it's constructive to keep changing drivers like this where the upstream isn't actively developed and tested. But I digress. It's up to Patrik anyway.

Nothing in this series is very helpful so NAK. In general I'm not fond of trivial changes like this since it's hard to say what motivates the author. In theory it shouldn't matter but so far it's been directly related to the quality of the patches. I can help test changes for gma500 if needed but please make it worth my while.

Best regards
Patrik

Quoted 8 lines

BR,
Jani.

--
Jani Nikula, Intel Open Source Technology Center

#987 lore raw

PATCH 6/6 GPU-DRM-GMA500: Rename a jump label in mid_get_vbt_data()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 20 Sep 2016 10:40:22 +0200

* Adjust a jump target.

* Delete the explicit initialisation for the local variable "ret" which became unnecessary with this refactoring.

---
 drivers/gpu/drm/gma500/mid_bios.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)
drivers/gpu/drm/gma500/mid_bios.c +5 -6
index e5cece0..602d16f 100644
@@ -284,7 +284,7 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv)
 	u8 __iomem *vbt_virtual;
 	struct mid_vbt_header vbt_header;
 	struct pci_dev *pci_gfx_root = pci_get_bus_and_slot(0, PCI_DEVFN(2, 0));
-	int ret = -1;
+	int ret;
 
 	/* Get the address of the platform config vbt */
 	pci_read_config_dword(pci_gfx_root, 0xFC, &addr);
@@ -293,18 +293,18 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv)
 	dev_dbg(dev->dev, "drm platform config address is %x\n", addr);
 
 	if (!addr)
-		goto out;
+		goto report_failure;
 
 	/* get the virtual address of the vbt */
 	vbt_virtual = ioremap(addr, sizeof(vbt_header));
 	if (!vbt_virtual)
-		goto out;
+		goto report_failure;
 
 	memcpy_fromio(&vbt_header, vbt_virtual, sizeof(vbt_header));
 	iounmap(vbt_virtual);
 
 	if (memcmp(&vbt_header.signature, "$GCT", 4))
-		goto out;
+		goto report_failure;
 
 	dev_dbg(dev->dev, "GCT revision is %02x\n", vbt_header.revision);
 
@@ -322,9 +322,8 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv)
 		dev_err(dev->dev, "Unknown revision of GCT!\n");
 		return;
 	}
-
-out:
 	if (ret)
+ report_failure:
 		dev_err(dev->dev, "Unable to read GCT!");
 	else
 		dev_priv->has_gct = true;
Signature · 1 line
2.10.0
#988 lore raw

Re: [PATCH 6/6] GPU-DRM-GMA500: Rename a jump label in mid_get_vbt_data()

Quoted 4 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 20 Sep 2016 10:40:22 +0200

* Adjust a jump target.

Please don't.

BR,
Jani.

Quoted 55 lines

* Delete the explicit initialisation for the local variable "ret" which became unnecessary with this refactoring.

---
 drivers/gpu/drm/gma500/mid_bios.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)
drivers/gpu/drm/gma500/mid_bios.c +5 -6
index e5cece0..602d16f 100644
@@ -284,7 +284,7 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv)
 	u8 __iomem *vbt_virtual;
 	struct mid_vbt_header vbt_header;
 	struct pci_dev *pci_gfx_root = pci_get_bus_and_slot(0, PCI_DEVFN(2, 0));
-	int ret = -1;
+	int ret;
 
 	/* Get the address of the platform config vbt */
 	pci_read_config_dword(pci_gfx_root, 0xFC, &addr);
@@ -293,18 +293,18 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv)
 	dev_dbg(dev->dev, "drm platform config address is %x\n", addr);
 
 	if (!addr)
-		goto out;
+		goto report_failure;
 
 	/* get the virtual address of the vbt */
 	vbt_virtual = ioremap(addr, sizeof(vbt_header));
 	if (!vbt_virtual)
-		goto out;
+		goto report_failure;
 
 	memcpy_fromio(&vbt_header, vbt_virtual, sizeof(vbt_header));
 	iounmap(vbt_virtual);
 
 	if (memcmp(&vbt_header.signature, "$GCT", 4))
-		goto out;
+		goto report_failure;
 
 	dev_dbg(dev->dev, "GCT revision is %02x\n", vbt_header.revision);
 
@@ -322,9 +322,8 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv)
 		dev_err(dev->dev, "Unknown revision of GCT!\n");
 		return;
 	}
-
-out:
 	if (ret)
+ report_failure:
 		dev_err(dev->dev, "Unable to read GCT!");
 	else
 		dev_priv->has_gct = true;
Signature · 1 line
Jani Nikula, Intel Open Source Technology Center
#989 lore raw

Re: [PATCH 6/6] GPU-DRM-GMA500: Rename a jump label in mid_get_vbt_data()

Quoted 8 lines · Jani Nikula
Quoted 4 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 20 Sep 2016 10:40:22 +0200

* Adjust a jump target.

Please don't.

Also there is nothing in CodingStyle that prohibits out: labels. I wrote that section and I wrote it in a deliberately way because no one wants to see a bunch of "cleanup" patches that change the label names for no reason.

People have been complaining about this in the kernel-summit mailing list as if CodingStyle bans out labels and that it's my fault. Neither of these complaints are accurate.

regards,
dan carpenter

#990 lore raw

cover GPU-DRM-OMAP: Fine-tuning for several function implementations

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 18:28:38 +0200

Several update suggestions were taken into account from static source code analysis.

Markus Elfring (14):
Use kmalloc_array() in tiler_map_show()
Replace another kmalloc() call by kmalloc_array() in tiler_map_show() Less function calls in tiler_map_show() after error detection Delete an unnecessary variable initialisation in tiler_map_show() Improve a size determination in dmm_txn_append()
Improve a size determination in omap_dmm_probe()
Rename a jump label in omap_dmm_probe()
Rename a jump label in dmm_txn_commit()
Delete an unnecessary variable initialisation in dmm_txn_commit() Use kmalloc_array() in omap_gem_attach_pages()
Replace a kzalloc() call by kcalloc() in omap_gem_attach_pages() Move a variable assignment in omap_gem_attach_pages() Rename a jump label in omap_gem_new_dmabuf()
Rename a jump label in four functions

 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 58 ++++++++++++++++----------------
 drivers/gpu/drm/omapdrm/omap_gem.c       | 44 +++++++++++-------------
 2 files changed, 49 insertions(+), 53 deletions(-)
Signature · 1 line
2.10.0
#991 lore raw

PATCH 1/14 GPU-DRM-OMAP: Use kmalloc_array() in tiler_map_show()

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 12:23:46 +0200

A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +1 -2
index 4ceed7a9..7b32dd3 100644
@@ -917,8 +917,7 @@ int tiler_map_show(struct seq_file *s, void *arg)
 
 	h_adj = omap_dmm->container_height / ydiv;
 	w_adj = omap_dmm->container_width / xdiv;
-
-	map = kmalloc(h_adj * sizeof(*map), GFP_KERNEL);
+	map = kmalloc_array(h_adj, sizeof(*map), GFP_KERNEL);
 	global_map = kmalloc((w_adj + 1) * h_adj, GFP_KERNEL);
 
 	if (!map || !global_map)
Signature · 1 line
2.10.0
#992 lore raw

PATCH 2/14 GPU-DRM-OMAP: Replace another kmalloc() call by kmalloc_array() in tiler_map_show()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 12:54:07 +0200

A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array" at another place.

---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +1 -2
index 7b32dd3..3a4f91b 100644
@@ -918,8 +918,7 @@ int tiler_map_show(struct seq_file *s, void *arg)
 	h_adj = omap_dmm->container_height / ydiv;
 	w_adj = omap_dmm->container_width / xdiv;
 	map = kmalloc_array(h_adj, sizeof(*map), GFP_KERNEL);
-	global_map = kmalloc((w_adj + 1) * h_adj, GFP_KERNEL);
-
+	global_map = kmalloc_array(h_adj, w_adj + 1, GFP_KERNEL);
 	if (!map || !global_map)
 		goto error;
 
Signature · 1 line
2.10.0
#993 lore raw

PATCH 3/14 GPU-DRM-OMAP: Less function calls in tiler_map_show() after error detection

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 13:16:20 +0200

The kfree() function was called in up to two cases by the tiler_map_show() function during error handling even if the passed variable contained a null pointer.

* Adjust jump targets according to the Linux coding style convention.

* Split a condition check for memory allocation failures so that each pointer from these function calls will be checked immediately.

See also background information:
Topic "CWE-754: Improper check for unusual or exceptional conditions"

* Return directly after a call of the function "kmalloc_array" failed at the beginning.

* Move an assignment for the local variable "w_adj" behind the first memory allocation.

---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +8 -6
index 3a4f91b..60beeb9 100644
@@ -916,11 +916,14 @@ int tiler_map_show(struct seq_file *s, void *arg)
 	}
 
 	h_adj = omap_dmm->container_height / ydiv;
-	w_adj = omap_dmm->container_width / xdiv;
 	map = kmalloc_array(h_adj, sizeof(*map), GFP_KERNEL);
+	if (!map)
+		return 0;
+
+	w_adj = omap_dmm->container_width / xdiv;
 	global_map = kmalloc_array(h_adj, w_adj + 1, GFP_KERNEL);
-	if (!map || !global_map)
-		goto error;
+	if (!global_map)
+		goto free_map;
 
 	for (lut_idx = 0; lut_idx < omap_dmm->num_lut; lut_idx++) {
 		memset(map, 0, h_adj * sizeof(*map));
@@ -982,10 +985,9 @@ int tiler_map_show(struct seq_file *s, void *arg)
 		}
 	}
 
-error:
-	kfree(map);
 	kfree(global_map);
-
+ free_map:
+	kfree(map);
 	return 0;
 }
 #endif
Signature · 1 line
2.10.0
#994 lore raw

PATCH 4/14 GPU-DRM-OMAP: Delete an unnecessary variable initialisation in tiler_map_show()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 13:31:45 +0200

The local variable "map" will be set to an appropriate pointer a bit later. Thus omit the explicit initialisation at the beginning.

---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +1 -1
index 60beeb9..c262ef5 100644
@@ -896,7 +896,7 @@ static void map_2d_info(char **map, int xdiv, int ydiv, char *nice,
 int tiler_map_show(struct seq_file *s, void *arg)
 {
 	int xdiv = 2, ydiv = 1;
-	char **map = NULL, *global_map;
+	char **map, *global_map;
 	struct tiler_block *block;
 	struct tcm_area a, p;
 	int i;
Signature · 1 line
2.10.0
#995 lore raw

PATCH 4/14 GPU-DRM-OMAP: Delete an unnecessary variable initialisation in tiler_map_show()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 13:31:45 +0200

The local variable "map" will be set to an appropriate pointer a bit later. Thus omit the explicit initialisation at the beginning.

---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +1 -1
index 60beeb9..c262ef5 100644
@@ -896,7 +896,7 @@ static void map_2d_info(char **map, int xdiv, int ydiv, char *nice,
 int tiler_map_show(struct seq_file *s, void *arg)
 {
 	int xdiv = 2, ydiv = 1;
-	char **map = NULL, *global_map;
+	char **map, *global_map;
 	struct tiler_block *block;
 	struct tcm_area a, p;
 	int i;
Signature · 1 line
2.10.0
#996 lore raw

PATCH 5/14 GPU-DRM-OMAP: Improve a size determination in dmm_txn_append()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 13:53:11 +0200

Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +1 -1
index c262ef5..f110965 100644
@@ -224,7 +224,7 @@ static void dmm_txn_append(struct dmm_txn *txn, struct pat_area *area,
 	int rows = (1 + area->y1 - area->y0);
 	int i = columns*rows;
 
-	pat = alloc_dma(txn, sizeof(struct pat), &pat_pa);
+	pat = alloc_dma(txn, sizeof(*pat), &pat_pa);
 
 	if (txn->last_pat)
 		txn->last_pat->next_pa = (uint32_t)pat_pa;
Signature · 1 line
2.10.0
#997 lore raw

PATCH 6/14 GPU-DRM-OMAP: Improve a size determination in omap_dmm_probe()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 17:21:57 +0200

Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +2 -1
index f110965..c6a7197 100644
@@ -735,7 +735,8 @@ static int omap_dmm_probe(struct platform_device *dev)
 
 	/* alloc engines */
 	omap_dmm->engines = kcalloc(omap_dmm->num_engines,
-				    sizeof(struct refill_engine), GFP_KERNEL);
+				    sizeof(*omap_dmm->engines),
+				    GFP_KERNEL);
 	if (!omap_dmm->engines) {
 		ret = -ENOMEM;
 		goto fail;
Signature · 1 line
2.10.0
#998 lore raw

PATCH 7/14 GPU-DRM-OMAP: Rename a jump label in omap_dmm_probe()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 17:30:25 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +12 -13
index c6a7197..5f6f21b 100644
@@ -624,7 +624,7 @@ static int omap_dmm_probe(struct platform_device *dev)
 
 	omap_dmm = kzalloc(sizeof(*omap_dmm), GFP_KERNEL);
 	if (!omap_dmm)
-		goto fail;
+		goto check_dmm_removal;
 
 	/* initialize lists */
 	INIT_LIST_HEAD(&omap_dmm->alloc_head);
@@ -648,20 +648,20 @@ static int omap_dmm_probe(struct platform_device *dev)
 	mem = platform_get_resource(dev, IORESOURCE_MEM, 0);
 	if (!mem) {
 		dev_err(&dev->dev, "failed to get base address resource\n");
-		goto fail;
+		goto check_dmm_removal;
 	}
 
 	omap_dmm->base = ioremap(mem->start, SZ_2K);
 
 	if (!omap_dmm->base) {
 		dev_err(&dev->dev, "failed to get dmm base address\n");
-		goto fail;
+		goto check_dmm_removal;
 	}
 
 	omap_dmm->irq = platform_get_irq(dev, 0);
 	if (omap_dmm->irq < 0) {
 		dev_err(&dev->dev, "failed to get IRQ resource\n");
-		goto fail;
+		goto check_dmm_removal;
 	}
 
 	omap_dmm->dev = &dev->dev;
@@ -699,7 +699,7 @@ static int omap_dmm_probe(struct platform_device *dev)
 		dev_err(&dev->dev, "couldn't register IRQ %d, error %d\n",
 			omap_dmm->irq, ret);
 		omap_dmm->irq = -1;
-		goto fail;
+		goto check_dmm_removal;
 	}
 
 	/* Enable all interrupts for each refill engine except
@@ -714,13 +714,13 @@ static int omap_dmm_probe(struct platform_device *dev)
 	if (!omap_dmm->dummy_page) {
 		dev_err(&dev->dev, "could not allocate dummy page\n");
 		ret = -ENOMEM;
-		goto fail;
+		goto check_dmm_removal;
 	}
 
 	/* set dma mask for device */
 	ret = dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
 	if (ret)
-		goto fail;
+		goto check_dmm_removal;
 
 	omap_dmm->dummy_pa = page_to_phys(omap_dmm->dummy_page);
 
@@ -730,7 +730,7 @@ static int omap_dmm_probe(struct platform_device *dev)
 					   &omap_dmm->refill_pa, GFP_KERNEL);
 	if (!omap_dmm->refill_va) {
 		dev_err(&dev->dev, "could not allocate refill memory\n");
-		goto fail;
+		goto check_dmm_removal;
 	}
 
 	/* alloc engines */
@@ -739,7 +739,7 @@ static int omap_dmm_probe(struct platform_device *dev)
 				    GFP_KERNEL);
 	if (!omap_dmm->engines) {
 		ret = -ENOMEM;
-		goto fail;
+		goto check_dmm_removal;
 	}
 
 	for (i = 0; i < omap_dmm->num_engines; i++) {
@@ -758,7 +758,7 @@ static int omap_dmm_probe(struct platform_device *dev)
 				GFP_KERNEL);
 	if (!omap_dmm->tcm) {
 		ret = -ENOMEM;
-		goto fail;
+		goto check_dmm_removal;
 	}
 
 	/* init containers */
@@ -772,7 +772,7 @@ static int omap_dmm_probe(struct platform_device *dev)
 		if (!omap_dmm->tcm[i]) {
 			dev_err(&dev->dev, "failed to allocate container\n");
 			ret = -ENOMEM;
-			goto fail;
+			goto check_dmm_removal;
 		}
 
 		omap_dmm->tcm[i]->lut_id = i;
@@ -812,8 +812,7 @@ static int omap_dmm_probe(struct platform_device *dev)
 	dev_info(omap_dmm->dev, "initialized all PAT entries\n");
 
 	return 0;
-
-fail:
+ check_dmm_removal:
 	if (omap_dmm_remove(dev))
 		dev_err(&dev->dev, "cleanup failed\n");
 	return ret;
Signature · 1 line
2.10.0
#999 lore raw

PATCH 8/14 GPU-DRM-OMAP: Rename a jump label in dmm_txn_commit()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 17:32:42 +0200

Adjust a jump target so that redundant checks can be avoided at the end.

---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +3 -3
index 5f6f21b..c8ced158 100644
@@ -269,7 +269,7 @@ static int dmm_txn_commit(struct dmm_txn *txn, bool wait)
 	if (!txn->last_pat) {
 		dev_err(engine->dmm->dev, "need at least one txn\n");
 		ret = -EINVAL;
-		goto cleanup;
+		goto release_engine;
 	}
 
 	txn->last_pat->next_pa = 0;
@@ -281,7 +281,7 @@ static int dmm_txn_commit(struct dmm_txn *txn, bool wait)
 	ret = wait_status(engine, DMM_PATSTATUS_READY);
 	if (ret) {
 		ret = -EFAULT;
-		goto cleanup;
+		goto release_engine;
 	}
 
 	/* mark whether it is async to denote list management in IRQ handler */
@@ -301,9 +301,9 @@ static int dmm_txn_commit(struct dmm_txn *txn, bool wait)
 		}
 	}
 
-cleanup:
 	/* only place engine back on list if we are done with it */
 	if (ret || wait)
+ release_engine:
 		release_engine(engine);
 
 	return ret;
Signature · 1 line
2.10.0
#1000 lore raw

PATCH 9/14 GPU-DRM-OMAP: Delete an unnecessary variable initialisation in dmm_txn_commit()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 17:34:40 +0200

The local variable "ret" will be set to an appropriate value a bit later. Thus omit the explicit initialisation at the beginning.

---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +1 -1
index c8ced158..c5c3793 100644
@@ -262,7 +262,7 @@ static void dmm_txn_append(struct dmm_txn *txn, struct pat_area *area,
  */
 static int dmm_txn_commit(struct dmm_txn *txn, bool wait)
 {
-	int ret = 0;
+	int ret;
 	struct refill_engine *engine = txn->engine_handle;
 	struct dmm *dmm = engine->dmm;
 
Signature · 1 line
2.10.0
#1001 lore raw

PATCH 10/14 GPU-DRM-OMAP: Use kmalloc_array() in omap_gem_attach_pages()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 17:37:04 +0200

A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

---
 drivers/gpu/drm/omapdrm/omap_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/omapdrm/omap_gem.c +1 -1
index 505dee0..e4f1924 100644
@@ -259,7 +259,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj)
 	 * DSS, GPU, etc. are not cache coherent:
 	 */
 	if (omap_obj->flags & (OMAP_BO_WC|OMAP_BO_UNCACHED)) {
-		addrs = kmalloc(npages * sizeof(*addrs), GFP_KERNEL);
+		addrs = kmalloc_array(npages, sizeof(*addrs), GFP_KERNEL);
 		if (!addrs) {
 			ret = -ENOMEM;
 			goto free_pages;
Signature · 1 line
2.10.0
#1002 lore raw

PATCH 11/14 GPU-DRM-OMAP: Replace a kzalloc() call by kcalloc() in omap_gem_attach_pages()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 17:40:20 +0200

The script "checkpatch.pl" can point information out like the following.

WARNING: Prefer kcalloc over kzalloc with multiply

Thus fix the affected source code place.

---
 drivers/gpu/drm/omapdrm/omap_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/omapdrm/omap_gem.c +1 -1
index e4f1924..26f1212 100644
@@ -283,7 +283,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj)
 			}
 		}
 	} else {
-		addrs = kzalloc(npages * sizeof(*addrs), GFP_KERNEL);
+		addrs = kcalloc(npages, sizeof(*addrs), GFP_KERNEL);
 		if (!addrs) {
 			ret = -ENOMEM;
 			goto free_pages;
Signature · 1 line
2.10.0
#1003 lore raw

PATCH 12/14 GPU-DRM-OMAP: Move a variable assignment in omap_gem_attach_pages()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 17:42:28 +0200

Move one assignment for the local variable "npages" so that its setting will only be performed after a call of the function "drm_gem_get_pages" succeeded by this function.

---
 drivers/gpu/drm/omapdrm/omap_gem.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/gpu/drm/omapdrm/omap_gem.c +3 -1
index 26f1212..3c49ad9 100644
@@ -243,7 +243,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj)
 	struct drm_device *dev = obj->dev;
 	struct omap_gem_object *omap_obj = to_omap_bo(obj);
 	struct page **pages;
-	int npages = obj->size >> PAGE_SHIFT;
+	int npages;
 	int i, ret;
 	dma_addr_t *addrs;
 
@@ -255,6 +255,8 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj)
 		return PTR_ERR(pages);
 	}
 
+	npages = obj->size >> PAGE_SHIFT;
+
 	/* for non-cached buffers, ensure the new pages are clean because
 	 * DSS, GPU, etc. are not cache coherent:
 	 */
Signature · 1 line
2.10.0
#1004 lore raw

PATCH 13/14 GPU-DRM-OMAP: Rename a jump label in omap_gem_new_dmabuf()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 17:45:04 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/gpu/drm/omapdrm/omap_gem.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)
drivers/gpu/drm/omapdrm/omap_gem.c +4 -5
index 3c49ad9..92510de 100644
@@ -1442,7 +1442,7 @@ struct drm_gem_object *omap_gem_new_dmabuf(struct drm_device *dev, size_t size,
 	obj = omap_gem_new(dev, gsize, OMAP_BO_MEM_DMABUF | OMAP_BO_WC);
 	if (!obj) {
 		obj = ERR_PTR(-ENOMEM);
-		goto done;
+		goto unlock;
 	}
 
 	omap_obj = to_omap_bo(obj);
@@ -1462,7 +1462,7 @@ struct drm_gem_object *omap_gem_new_dmabuf(struct drm_device *dev, size_t size,
 		if (!pages) {
 			omap_gem_free_object(obj);
 			obj = ERR_PTR(-ENOMEM);
-			goto done;
+			goto unlock;
 		}
 
 		omap_obj->pages = pages;
@@ -1476,11 +1476,10 @@ struct drm_gem_object *omap_gem_new_dmabuf(struct drm_device *dev, size_t size,
 		if (WARN_ON(i != npages)) {
 			omap_gem_free_object(obj);
 			obj = ERR_PTR(-ENOMEM);
-			goto done;
+			goto unlock;
 		}
 	}
-
-done:
+ unlock:
 	mutex_unlock(&dev->struct_mutex);
 	return obj;
 }
Signature · 1 line
2.10.0
#1005 lore raw

PATCH 14/14 GPU-DRM-OMAP: Rename a jump label in four functions

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 18:00:23 +0200

Adjust jump labels according to the current Linux coding style convention. Thus replace the identifier "fail" by "unlock" for this refactoring.

---
 drivers/gpu/drm/omapdrm/omap_gem.c | 27 +++++++++++----------------
 1 file changed, 11 insertions(+), 16 deletions(-)
drivers/gpu/drm/omapdrm/omap_gem.c +11 -16
index 92510de..ea7ad1c 100644
@@ -549,7 +549,7 @@ int omap_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 	/* if a shmem backed object, make sure we have pages attached now */
 	ret = get_pages(obj, &pages);
 	if (ret)
-		goto fail;
+		goto unlock;
 
 	/* where should we do corresponding put_pages().. we are mapping
 	 * the original page, rather than thru a GART, so we can't rely
@@ -561,9 +561,7 @@ int omap_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 		ret = fault_2d(obj, vma, vmf);
 	else
 		ret = fault_1d(obj, vma, vmf);
-
-
-fail:
+ unlock:
 	mutex_unlock(&dev->struct_mutex);
 	switch (ret) {
 	case 0:
@@ -682,14 +680,13 @@ int omap_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
 	obj = drm_gem_object_lookup(file, handle);
 	if (obj == NULL) {
 		ret = -ENOENT;
-		goto fail;
+		goto unlock;
 	}
 
 	*offset = omap_gem_mmap_offset(obj);
 
 	drm_gem_object_unreference_unlocked(obj);
-
-fail:
+ unlock:
 	return ret;
 }
 
@@ -719,13 +716,12 @@ int omap_gem_roll(struct drm_gem_object *obj, uint32_t roll)
 		struct page **pages;
 		ret = get_pages(obj, &pages);
 		if (ret)
-			goto fail;
+			goto unlock;
 		ret = tiler_pin(omap_obj->block, pages, npages, roll, true);
 		if (ret)
 			dev_err(obj->dev->dev, "could not repin: %d\n", ret);
 	}
-
-fail:
+ unlock:
 	mutex_unlock(&obj->dev->struct_mutex);
 
 	return ret;
@@ -825,7 +821,7 @@ int omap_gem_get_paddr(struct drm_gem_object *obj,
 
 			ret = get_pages(obj, &pages);
 			if (ret)
-				goto fail;
+				goto unlock;
 
 			if (omap_obj->flags & OMAP_BO_TILED) {
 				block = tiler_reserve_2d(fmt,
@@ -839,7 +835,7 @@ int omap_gem_get_paddr(struct drm_gem_object *obj,
 				ret = PTR_ERR(block);
 				dev_err(obj->dev->dev,
 					"could not remap: %d (%d)\n", ret, fmt);
-				goto fail;
+				goto unlock;
 			}
 
 			/* TODO: enable async refill.. */
@@ -849,7 +845,7 @@ int omap_gem_get_paddr(struct drm_gem_object *obj,
 				tiler_release(block);
 				dev_err(obj->dev->dev,
 						"could not pin: %d\n", ret);
-				goto fail;
+				goto unlock;
 			}
 
 			omap_obj->paddr = tiler_ssptr(block);
@@ -865,10 +861,9 @@ int omap_gem_get_paddr(struct drm_gem_object *obj,
 		*paddr = omap_obj->paddr;
 	} else {
 		ret = -EINVAL;
-		goto fail;
+		goto unlock;
 	}
-
-fail:
+ unlock:
 	mutex_unlock(&obj->dev->struct_mutex);
 
 	return ret;
Signature · 1 line
2.10.0
#1006 lore raw

Re: [PATCH 00/14] GPU-DRM-OMAP: Fine-tuning for several function implementations

In reply to SF Markus Elfring
Quoted 5 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 18:28:38 +0200

Several update suggestions were taken into account from static source code analysis.

For the next pile of driver patches _please_ talk with driver maintainers before starting to create&submit patches. Like I said I won't take them, and many of your changes are not clear-cut at all, so I expect many driver maintaines also won't take them. Again, your contributions are welcome, but blindly following suggestions from code checkers in drivers you cant test isn't really all that useful. At the scale you're doing it, I think it's mostly wasting everyone's time :( I'd like to avoid that.

Thanks, Daniel

Quoted 28 lines

Markus Elfring (14):
Use kmalloc_array() in tiler_map_show()
Replace another kmalloc() call by kmalloc_array() in tiler_map_show() Less function calls in tiler_map_show() after error detection Delete an unnecessary variable initialisation in tiler_map_show() Improve a size determination in dmm_txn_append()
Improve a size determination in omap_dmm_probe()
Rename a jump label in omap_dmm_probe()
Rename a jump label in dmm_txn_commit()
Delete an unnecessary variable initialisation in dmm_txn_commit() Use kmalloc_array() in omap_gem_attach_pages()
Replace a kzalloc() call by kcalloc() in omap_gem_attach_pages() Move a variable assignment in omap_gem_attach_pages() Rename a jump label in omap_gem_new_dmabuf()
Rename a jump label in four functions

 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 58 ++++++++++++++++----------------
 drivers/gpu/drm/omapdrm/omap_gem.c       | 44 +++++++++++-------------
 2 files changed, 49 insertions(+), 53 deletions(-)
Signature · 6 lines
2.10.0

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Signature · 3 lines
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
maintainer
#1007 lore raw

Re: [PATCH 00/14] GPU-DRM-OMAP: Fine-tuning for several function implementations

Quoted 7 lines · On Thursday 22 Sep 2016 08:45:01 Daniel Vetter wrote:
Quoted 5 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 21 Sep 2016 18:28:38 +0200

Several update suggestions were taken into account from static source code analysis.

Quoted 7 lines

For the next pile of driver patches _please_ talk with driver maintainers before starting to create&submit patches. Like I said I won't take them, and many of your changes are not clear-cut at all, so I expect many driver maintaines also won't take them. Again, your contributions are welcome, but blindly following suggestions from code checkers in drivers you cant test isn't really all that useful. At the scale you're doing it, I think it's mostly wasting everyone's time :( I'd like to avoid that.

I second that. After a very quick review, I see that the series splits related changes in multiple patches. I've already commented in reply to another series submitted by Markus that patches should then be combined. I will thus ignore this series completely for the time being.

Quoted 19 lines
Quoted 19 lines

Markus Elfring (14):
Use kmalloc_array() in tiler_map_show()
Replace another kmalloc() call by kmalloc_array() in tiler_map_show() Less function calls in tiler_map_show() after error detection Delete an unnecessary variable initialisation in tiler_map_show() Improve a size determination in dmm_txn_append()
Improve a size determination in omap_dmm_probe()
Rename a jump label in omap_dmm_probe()
Rename a jump label in dmm_txn_commit()
Delete an unnecessary variable initialisation in dmm_txn_commit() Use kmalloc_array() in omap_gem_attach_pages()
Replace a kzalloc() call by kcalloc() in omap_gem_attach_pages() Move a variable assignment in omap_gem_attach_pages() Rename a jump label in omap_gem_new_dmabuf()
Rename a jump label in four functions

 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 58 +++++++++++++--------------
 drivers/gpu/drm/omapdrm/omap_gem.c       | 44 +++++++++++-------------
 2 files changed, 49 insertions(+), 53 deletions(-)
Signature · 3 lines
Regards,

Laurent Pinchart
#1008 lore raw

Re: GPU-DRM-OMAP: Fine-tuning for several function implementations

Quoted 2 lines
Quoted 2 lines

For the next pile of driver patches _please_ talk with driver maintainers before starting to create&submit patches.

Did the software development discussion start a bit here?

Would you like to support an other "talking style" on a conference like in Berlin next month?

Quoted 1 line
Quoted 1 line

Like I said I won't take them,

It's a pity.

Quoted 1 line
Quoted 1 line

and many of your changes are not clear-cut at all,

I know that specific update suggestions could be interpreted as controversial.

Quoted 1 line
Quoted 1 line

so I expect many driver maintaines also won't take them.

I am curious on useful responses.

Quoted 1 line
Quoted 1 line

Again, your contributions are welcome,

Thanks for another bit of constructive feedback.

Quoted 1 line
Quoted 1 line

but blindly following suggestions from code checkers in drivers

I propose to dare another look at corresponding information sources.

Quoted 1 line
Quoted 1 line

you cant test isn't really all that useful.

I have got an other impression.

How many improvements can still be achieved by usual (advanced) collaboration techniques for free software development?

Quoted 1 line
Quoted 1 line

At the scale you're doing it, I think it's mostly wasting everyone's time

I hope not.

Quoted 1 line

:( I'd like to avoid that.

I am going to point more update opportunities out also for various Linux software.

Quoted 1 line

I second that.

Thanks for your opinion on this issue.

Quoted 2 lines

After a very quick review, I see that the series splits related changes in multiple patches.

I chose a specific patch granularity for this proposal.

Quoted 2 lines

I've already commented in reply to another series submitted by Markus that patches should then be combined.

Will such a combination depend on any more agreements between the involved contributors?

Quoted 1 line

I will thus ignore this series completely for the time being.

I hope that you can give similar ideas a second chance somehow.

Regards,
Markus

#1009 lore raw

cover GPU-DRM-TILCDC: Fine-tuning for two function implementations

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 10:25:43 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (4):
Use kmalloc_array()
Return directly after a failed kfree_table_init() in tilcdc_convert_slave_node() Less function calls in tilcdc_convert_slave_node() after error detection Delete unnecessary variable initialisations

 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 36 +++++++++++++++-------------
 1 file changed, 20 insertions(+), 16 deletions(-)
Signature · 1 line
2.10.0
#1010 lore raw

PATCH 1/4 GPU-DRM-TILCDC: Use kmalloc_array() in kfree_table_init()

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 09:05:14 +0200

A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

---
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c +1 -2
index f9c79da..8faa28f 100644
@@ -32,8 +32,7 @@ static int __init kfree_table_init(struct kfree_table *kft)
 {
 	kft->total = 32;
 	kft->num = 0;
-	kft->table = kmalloc(kft->total * sizeof(*kft->table),
-			     GFP_KERNEL);
+	kft->table = kmalloc_array(kft->total, sizeof(*kft->table), GFP_KERNEL);
 	if (!kft->table)
 		return -ENOMEM;
 
Signature · 1 line
2.10.0
#1011 lore raw

Re: [PATCH 1/4] GPU-DRM-TILCDC: Use kmalloc_array() in kfree_table_init()

Quoted 19 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 09:05:14 +0200

A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

---
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c +0 -0
index f9c79da..8faa28f 100644

drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c static int __init kfree_table_init(struct kfree_table *kft) · line 35

Quoted 6 lines
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c +1 -2
@@ -32,8 +32,7 @@ static int __init kfree_table_init(struct kfree_table *kft)
 {
 	kft->total = 32;
 	kft->num = 0;
-	kft->table = kmalloc(kft->total * sizeof(*kft->table),
-			     GFP_KERNEL);
+	kft->table = kmalloc_array(kft->total, sizeof(*kft->table), GFP_KERNEL);

I was not sure if it is Ok to call kremalloc() for a pointer that was previously allocated with kmalloc_array(). And at least it felt pointless.

But if you can confirm that it is ok, then sure I can take the patch.

Thanks,
Jyri

Quoted 4 lines
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c +0 -0
 	if (!kft->table)
 		return -ENOMEM;
 
#1012 lore raw

PATCH 2/4 GPU-DRM-TILCDC: Return directly after a failed kfree_table_init() in tilcdc_convert_slave_node()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 09:29:23 +0200

Return directly after a memory allocation failed in this function at the beginning.

---
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c +1 -1
index 8faa28f..6204405 100644
@@ -206,7 +206,7 @@ void __init tilcdc_convert_slave_node(void)
 	int ret;
 
 	if (kfree_table_init(&kft))
-		goto out;
+		return;
 
 	lcdc = of_find_matching_node(NULL, tilcdc_of_match);
 	slave = of_find_matching_node(NULL, tilcdc_slave_of_match);
Signature · 1 line
2.10.0
#1013 lore raw

Re: [PATCH 2/4] GPU-DRM-TILCDC: Return directly after a failed kfree_table_init() in tilcdc_convert_slave_node()

This one is actually a bug fix... But finding bug fixes in this series is like looking for kernels of edible corn in piles of monkey poop.

Also, classic "One Err" bug.

regards,
dan carpenter

#1014 lore raw

Re: [PATCH 2/4] GPU-DRM-TILCDC: Return directly after a failed kfree_table_init() in tilcdc_convert_slave_node()

In reply to SF Markus Elfring
Quoted 17 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 09:29:23 +0200

Return directly after a memory allocation failed in this function at the beginning.

---
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c +0 -0
index 8faa28f..6204405 100644

drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c void __init tilcdc_convert_slave_node(void) · line 212

Quoted 8 lines
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c +1 -1
@@ -206,7 +206,7 @@ void __init tilcdc_convert_slave_node(void)
 	int ret;
 
 	if (kfree_table_init(&kft))
-		goto out;
+		return;
 
 	lcdc = of_find_matching_node(NULL, tilcdc_of_match);
 	slave = of_find_matching_node(NULL, tilcdc_slave_of_match);

Thanks,
This is a real bug. I'll pick this up, but with your permission I change the commit subject to follow the current convention.

Best regards,
Jyri

#1015 lore raw

Re: GPU-DRM-TILCDC: Return directly after a failed kfree_table_init() in tilcdc_convert_slave_node()

Quoted 2 lines

I'll pick this up, but with your permission I change the commit subject to follow the current convention.

I guess that I can accept the integration of this update suggestion
also with an adjusted prefix in the commit title. ;-)

Regards,
Markus

#1016 lore raw

PATCH 3/4 GPU-DRM-TILCDC: Less function calls in tilcdc_convert_slave_node() after error detection

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 10:06:50 +0200

The of_node_put() function was called in some cases
by the tilcdc_convert_slave_node() function during error handling even if the passed variable contained a null pointer.

* Adjust jump targets according to the Linux coding style convention.

* Split a condition check for resource detection failures so that each pointer from these function calls will be checked immediately.

See also background information:
Topic "CWE-754: Improper check for unusual or exceptional conditions"

---
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c +17 -11
index 6204405..6ee5865 100644
@@ -209,25 +209,27 @@ void __init tilcdc_convert_slave_node(void)
 		return;
 
 	lcdc = of_find_matching_node(NULL, tilcdc_of_match);
-	slave = of_find_matching_node(NULL, tilcdc_slave_of_match);
+	if (!of_device_is_available(lcdc))
+		goto free_table;
 
-	if (!slave || !of_device_is_available(lcdc))
-		goto out;
+	slave = of_find_matching_node(NULL, tilcdc_slave_of_match);
+	if (!slave)
+		goto put_node_lcdc;
 
 	i2c = of_parse_phandle(slave, "i2c", 0);
 	if (!i2c) {
 		pr_err("%s: Can't find i2c node trough phandle\n", __func__);
-		goto out;
+		goto put_node_slave;
 	}
 
 	overlay = tilcdc_get_overlay(&kft);
 	if (!overlay)
-		goto out;
+		goto put_node_i2c;
 
 	encoder = of_find_matching_node(overlay, tilcdc_tda998x_of_match);
 	if (!encoder) {
 		pr_err("%s: Failed to find tda998x node\n", __func__);
-		goto out;
+		goto put_node_i2c;
 	}
 
 	tilcdc_copy_props(slave, encoder, tilcdc_slave_props, &kft);
@@ -238,10 +240,10 @@ void __init tilcdc_convert_slave_node(void)
 			continue;
 		if (!strncmp("i2c", (char *)prop->value, prop->length))
 			if (tilcdc_prop_str_update(prop, i2c->full_name, &kft))
-				goto out;
+				goto put_node_fragment;
 		if (!strncmp("lcdc", (char *)prop->value, prop->length))
 			if (tilcdc_prop_str_update(prop, lcdc->full_name, &kft))
-				goto out;
+				goto put_node_fragment;
 	}
 
 	tilcdc_node_disable(slave);
@@ -252,12 +254,16 @@ void __init tilcdc_convert_slave_node(void)
 	else
 		pr_info("%s: ti,tilcdc,slave node successfully converted\n",
 			__func__);
-out:
-	kfree_table_free(&kft);
+ put_node_fragment:
+	of_node_put(fragment);
+ put_node_i2c:
 	of_node_put(i2c);
+ put_node_slave:
 	of_node_put(slave);
+ put_node_lcdc:
 	of_node_put(lcdc);
-	of_node_put(fragment);
+ free_table:
+	kfree_table_free(&kft);
 }
 
 int __init tilcdc_slave_compat_init(void)
Signature · 1 line
2.10.0
#1017 lore raw

Re: [PATCH 3/4] GPU-DRM-TILCDC: Less function calls in tilcdc_convert_slave_node() after error detection

Quoted 7 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 10:06:50 +0200

The of_node_put() function was called in some cases
by the tilcdc_convert_slave_node() function during error handling even if the passed variable contained a null pointer.

Quoted 9 lines

* Adjust jump targets according to the Linux coding style convention.

* Split a condition check for resource detection failures so that each pointer from these function calls will be checked immediately.

See also background information:
Topic "CWE-754: Improper check for unusual or exceptional conditions"

I don't really agree with this patch. There is no harm in calling of_node_put() with NULL as an argument and because of that there is no point in making the function more complex and harder to maintain.

Best regards,
Jyri

Quoted 77 lines
---
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c +17 -11
index 6204405..6ee5865 100644
@@ -209,25 +209,27 @@ void __init tilcdc_convert_slave_node(void)
 		return;
 
 	lcdc = of_find_matching_node(NULL, tilcdc_of_match);
-	slave = of_find_matching_node(NULL, tilcdc_slave_of_match);
+	if (!of_device_is_available(lcdc))
+		goto free_table;
 
-	if (!slave || !of_device_is_available(lcdc))
-		goto out;
+	slave = of_find_matching_node(NULL, tilcdc_slave_of_match);
+	if (!slave)
+		goto put_node_lcdc;
 
 	i2c = of_parse_phandle(slave, "i2c", 0);
 	if (!i2c) {
 		pr_err("%s: Can't find i2c node trough phandle\n", __func__);
-		goto out;
+		goto put_node_slave;
 	}
 
 	overlay = tilcdc_get_overlay(&kft);
 	if (!overlay)
-		goto out;
+		goto put_node_i2c;
 
 	encoder = of_find_matching_node(overlay, tilcdc_tda998x_of_match);
 	if (!encoder) {
 		pr_err("%s: Failed to find tda998x node\n", __func__);
-		goto out;
+		goto put_node_i2c;
 	}
 
 	tilcdc_copy_props(slave, encoder, tilcdc_slave_props, &kft);
@@ -238,10 +240,10 @@ void __init tilcdc_convert_slave_node(void)
 			continue;
 		if (!strncmp("i2c", (char *)prop->value, prop->length))
 			if (tilcdc_prop_str_update(prop, i2c->full_name, &kft))
-				goto out;
+				goto put_node_fragment;
 		if (!strncmp("lcdc", (char *)prop->value, prop->length))
 			if (tilcdc_prop_str_update(prop, lcdc->full_name, &kft))
-				goto out;
+				goto put_node_fragment;
 	}
 
 	tilcdc_node_disable(slave);
@@ -252,12 +254,16 @@ void __init tilcdc_convert_slave_node(void)
 	else
 		pr_info("%s: ti,tilcdc,slave node successfully converted\n",
 			__func__);
-out:
-	kfree_table_free(&kft);
+ put_node_fragment:
+	of_node_put(fragment);
+ put_node_i2c:
 	of_node_put(i2c);
+ put_node_slave:
 	of_node_put(slave);
+ put_node_lcdc:
 	of_node_put(lcdc);
-	of_node_put(fragment);
+ free_table:
+	kfree_table_free(&kft);
 }
 
 int __init tilcdc_slave_compat_init(void)
#1018 lore raw

Re: GPU-DRM-TILCDC: Less function calls in tilcdc_convert_slave_node() after error detection

Quoted 9 lines
Quoted 9 lines

The of_node_put() function was called in some cases
by the tilcdc_convert_slave_node() function during error handling even if the passed variable contained a null pointer.

* Adjust jump targets according to the Linux coding style convention.

* Split a condition check for resource detection failures so that each pointer from these function calls will be checked immediately.

Quoted 6 lines
Quoted 4 lines

See also background information:
Topic "CWE-754: Improper check for unusual or exceptional conditions"

I don't really agree with this patch.

This kind of feedback can be fine at first glance.

Quoted 1 line

There is no harm in calling of_node_put() with NULL as an argument

The cost of additional function calls will be eventually not noticed just because they belong to an exception handling implementation so far.

Quoted 1 line

and because of that there is no point in making the function more complex

There is inherent software complexity involved.

Quoted 1 line

and harder to maintain.

How do you think about to discuss this aspect a bit more?

I suggest to reconsider this design detail if it is really acceptable for the safe implementation of such a software module.

* How much will it matter in general that one function call was performed in this use case without checking its return value immediately?

* Should it usually be determined quicker if a required resource could be acquired before trying the next allocation?

Regards,
Markus

#1019 lore raw

Re: GPU-DRM-TILCDC: Less function calls in tilcdc_convert_slave_node() after error detection

Quoted 21 lines · SF Markus Elfring
Quoted 9 lines
Quoted 9 lines

The of_node_put() function was called in some cases
by the tilcdc_convert_slave_node() function during error handling even if the passed variable contained a null pointer.

* Adjust jump targets according to the Linux coding style convention.

* Split a condition check for resource detection failures so that each pointer from these function calls will be checked immediately.

Quoted 6 lines
Quoted 4 lines

See also background information:
Topic "CWE-754: Improper check for unusual or exceptional conditions"

I don't really agree with this patch.

This kind of feedback can be fine at first glance.

Quoted 1 line

There is no harm in calling of_node_put() with NULL as an argument

Quoted 8 lines

The cost of additional function calls will be eventually not noticed just because they belong to an exception handling implementation so far.

Quoted 1 line

and because of that there is no point in making the function more complex

There is inherent software complexity involved.

I think the "if (node)" in the of_node_put() is there on purpose, because it potentially saves the caller one extra if()-statement and keeps the caller code simpler.

Quoted 5 lines
Quoted 2 lines

and harder to maintain.

How do you think about to discuss this aspect a bit more?

Keeping the goto labels in right order needs precision and can lead to subtle errors. Sometimes there is no way to avoid that, but here there is.

Best regards,
Jyri

#1020 lore raw

Re: GPU-DRM-TILCDC: Less function calls in tilcdc_convert_slave_node() after error detection

Quoted 1 line

I think the "if (node)" in the of_node_put() is there on purpose,

Yes, of course.

Does such an implementation detail correspond to a general software design pattern?

Quoted 1 line

because it potentially saves the caller one extra if()-statement

This can occasionally happen.

Quoted 1 line

and keeps the caller code simpler.

A special view on software simplicity can also lead to questionable intermediate function implementation, can't it?

Quoted 1 line

Keeping the goto labels in right order needs precision

I can agree to this view.

Quoted 1 line

and can lead to subtle errors.

The management of jump labels is just another software development challenge as usual, isn't it?

Quoted 1 line

Sometimes there is no way to avoid that,

How do you think about to clarify the constraints which you imagine a bit more?

Quoted 1 line

but here there is.

I disagree to this conclusion.

Would you like to care a bit more for efficiency and software correctness around the discussed exception handling?

Regards,
Markus

#1021 lore raw

Re: GPU-DRM-TILCDC: Less function calls in tilcdc_convert_slave_node() after error detection

Quoted 6 lines · SF Markus Elfring
Quoted 1 line

I think the "if (node)" in the of_node_put() is there on purpose,

Yes, of course.

Does such an implementation detail correspond to a general software design pattern?

Yes it does. For instance standard malloc()/free() implementation [1].

Quoted 11 lines
Quoted 2 lines

because it potentially saves the caller one extra if()-statement

This can occasionally happen.

Quoted 1 line

and keeps the caller code simpler.

A special view on software simplicity can also lead to questionable intermediate function implementation, can't it?

I don't really follow. But in any case I do not see anything questionable in the current tilcdc_convert_slave_node() implementation.

Quoted 11 lines
Quoted 2 lines

Keeping the goto labels in right order needs precision

I can agree to this view.

Quoted 1 line

and can lead to subtle errors.

The management of jump labels is just another software development challenge as usual, isn't it?

Yes. But usually it pays of to avoid complexity when possible.

Quoted 5 lines
Quoted 2 lines

Sometimes there is no way to avoid that,

How do you think about to clarify the constraints which you imagine a bit more?

If the the of_node_put() behaviour would not be specified with null pointer as parameter, there would be such a constraint.

I am beginning to have a feeling that this discussion is not going anywhere.

Quoted 8 lines
Quoted 2 lines

but here there is.

I disagree to this conclusion.

Would you like to care a bit more for efficiency and software correctness around the discussed exception handling?

No, I would not. I think we have reached the bottom of this discussion. For the moment I have more important tasks to do.

Best regards,
Jyri

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/free.html

#1022 lore raw

Re: GPU-DRM-TILCDC: Less function calls in tilcdc_convert_slave_node() after error detection

Quoted 5 lines
Quoted 2 lines

A special view on software simplicity can also lead to questionable intermediate function implementation, can't it?

I don't really follow. But in any case I do not see anything questionable in the current tilcdc_convert_slave_node() implementation.

I identified update candidates there like the following.

1. Delayed checking for null pointers
…

	if (!slave || !of_device_is_available(lcdc))

…

2. Usage of a single jump label for (too many?) cases …

		goto out;

…

Can the corresponding exception handling become also a bit more efficient?

Quoted 4 lines
Quoted 2 lines

Would you like to care a bit more for efficiency and software correctness around the discussed exception handling?

No, I would not.

Thanks for this information.

I hope that the software situation can also be improved around this design aspect somehow.

Quoted 1 line

For the moment I have more important tasks to do.

I know also that various open issues are competing for your software development attention as usual.

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#1023 lore raw

Re: GPU-DRM-TILCDC: Less function calls in tilcdc_convert_slave_node() after error detection

In reply to SF Markus Elfring
Quoted 16 lines · SF Markus Elfring
Quoted 9 lines
Quoted 9 lines

The of_node_put() function was called in some cases
by the tilcdc_convert_slave_node() function during error handling even if the passed variable contained a null pointer.

* Adjust jump targets according to the Linux coding style convention.

* Split a condition check for resource detection failures so that each pointer from these function calls will be checked immediately.

Quoted 6 lines
Quoted 4 lines

See also background information:
Topic "CWE-754: Improper check for unusual or exceptional conditions"

I don't really agree with this patch.

Quoted 7 lines

This kind of feedback can be fine at first glance.

Quoted 1 line

There is no harm in calling of_node_put() with NULL as an argument

The cost of additional function calls will be eventually not noticed just because they belong to an exception handling implementation so far.

iirc, there are Coccinelle rules that find code with unnecessary null checks and removes them..

Although you probably made this complex enough that cocinelle would not find it. That is not a complement. One should not make error handling/cleanup more complex than needed.

BR,
-R

Quoted 26 lines
Quoted 2 lines

and because of that there is no point in making the function more complex

There is inherent software complexity involved.

Quoted 1 line

and harder to maintain.

How do you think about to discuss this aspect a bit more?

I suggest to reconsider this design detail if it is really acceptable for the safe implementation of such a software module.

* How much will it matter in general that one function call was performed in this use case without checking its return value immediately?

* Should it usually be determined quicker if a required resource could be acquired before trying the next allocation?

Regards,
Markus
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#1024 lore raw

Re: GPU-DRM-TILCDC: Less function calls in tilcdc_convert_slave_node() after error detection

Quoted 2 lines

iirc, there are Coccinelle rules that find code with unnecessary null checks and removes them.

This kind of software change is not needed here.

I find that a corresponding return value check happens one function call too late.

Quoted 2 lines

Although you probably made this complex enough that cocinelle would not find it. That is not a complement.

I imagine that scripts for the semantic patch language can find more source code places where questionable disjunctions are used so far. Would you dare to split any more condition checks?

Quoted 1 line

One should not make error handling/cleanup more complex than needed.

I see a need to improve not only correctness there but also a bit of software efficiency.

Regards,
Markus

#1025 lore raw

Re: GPU-DRM-TILCDC: Less function calls in tilcdc_convert_slave_node() after error detection

Quoted 8 lines · SF Markus Elfring
Quoted 2 lines

iirc, there are Coccinelle rules that find code with unnecessary null checks and removes them.

This kind of software change is not needed here.

I find that a corresponding return value check happens one function call too late.

I think you misunderstand my point.. which is that additional conditional checks wrapping a function call to something that already checks for null should be removed.. not introduced.

Quoted 9 lines
Quoted 3 lines

Although you probably made this complex enough that cocinelle would not find it. That is not a complement.

I imagine that scripts for the semantic patch language can find more source code places where questionable disjunctions are used so far. Would you dare to split any more condition checks?

Quoted 4 lines
Quoted 1 line

One should not make error handling/cleanup more complex than needed.

I see a need to improve not only correctness there but also a bit of software efficiency.

If you can measure any performance difference and present some results (esp. considering that this is something that just happens when the driver is loaded), then we'll talk. Until then, please don't send this sort of patch. Thank you.

BR,
-R

Quoted 2 lines

Regards,
Markus

#1026 lore raw

Re: GPU-DRM-TILCDC: Less function calls in tilcdc_convert_slave_node() after error detection

Quoted 6 lines
Quoted 2 lines

I see a need to improve not only correctness there but also a bit of software efficiency.

If you can measure any performance difference and present some results (esp. considering that this is something that just happens when the driver is loaded), then we'll talk.

Are you really interested to increase your software development attention for a quicker exception handling implementation in this function?

Quoted 1 line

Until then, please don't send this sort of patch. Thank you.

Will benchmark statistics change such a change rejection ever?

Regards,
Markus

#1027 lore raw

Re: GPU-DRM-TILCDC: Less function calls in tilcdc_convert_slave_node() after error detection

Quoted 10 lines · SF Markus Elfring
Quoted 6 lines
Quoted 2 lines

I see a need to improve not only correctness there but also a bit of software efficiency.

If you can measure any performance difference and present some results (esp. considering that this is something that just happens when the driver is loaded), then we'll talk.

Are you really interested to increase your software development attention for a quicker exception handling implementation in this function?

No one is interested in making error handling more complex for a non-existent benefit ;-)

Quoted 4 lines
Quoted 2 lines

Until then, please don't send this sort of patch. Thank you.

Will benchmark statistics change such a change rejection ever?

If you could demonstrate a real benefit to additional complexity for something that actually matters (ie. not something like this that runs once at bootup) I would care.

I don't recommend that you waste your time, since there is approximately nothing in modesetting path that happens with a high enough frequency to benefit from such a micro-optimization. Especially not initialization code that runs once at boot up.

Fixing actual bugs is useful and valuable. Premature "optimization" at the expense of extra complexity is very much not useful.

BR,
-R

Quoted 2 lines

Regards,
Markus

#1028 lore raw

PATCH 4/4 GPU-DRM-TILCDC: Delete unnecessary variable initialisations in tilcdc_convert_slave_node()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 10:15:36 +0200

Four local variables will be set to an appropriate pointer a bit later. Thus omit the explicit initialisation which became unnecessary with a previous update step.

---
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c +1 -2
index 6ee5865..ae90728 100644
@@ -196,8 +196,7 @@ static const char * const tilcdc_slave_props[] __initconst = {
 
 void __init tilcdc_convert_slave_node(void)
 {
-	struct device_node *slave = NULL, *lcdc = NULL;
-	struct device_node *i2c = NULL, *fragment = NULL;
+	struct device_node *slave, *lcdc, *i2c, *fragment;
 	struct device_node *overlay, *encoder;
 	struct property *prop;
 	/* For all memory needed for the overlay tree. This memory can
Signature · 1 line
2.10.0
#1029 lore raw

cover GPU-DRM-TTM: Fine-tuning for several function implementations

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 19:00:01 +0200

Several update suggestions were taken into account from static source code analysis.

Markus Elfring (14):
Use kmalloc_array() in two functions
Rename a jump label in ttm_alloc_new_pages()
Rename jump labels in ttm_page_pool_free()
Rename a jump label in ttm_page_pool_get_pages()
Use kmalloc_array() in two more functions
Rename a jump label in ttm_dma_pool_alloc_new_pages()
Rename jump labels in ttm_dma_page_pool_free()
Rename a jump label in ttm_dma_pool_shrink_scan()
Return directly after a failed kzalloc() in ttm_dma_page_alloc_init() Return directly after a failed kobject_init_and_add() in ttm_dma_page_alloc_init() Return an error code only as a constant in ttm_dma_pool_init()
Less function calls in ttm_dma_pool_init() after error detection Delete unnecessary variable initialisations in ttm_dma_pool_init() Mark an array of text strings as "const" in ttm_dma_pool_init()

 drivers/gpu/drm/ttm/ttm_page_alloc.c     | 30 ++++++++---------
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 58 +++++++++++++++-----------------
 2 files changed, 42 insertions(+), 46 deletions(-)
Signature · 1 line
2.10.0
#1030 lore raw

PATCH 1/14 GPU-DRM-TTM: Use kmalloc_array() in two functions

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 14:00:31 +0200

* Multiplications for the size determination of memory allocations indicated that array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

* Replace the specification of data types by pointer dereferences to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/gpu/drm/ttm/ttm_page_alloc.c +6 -4
index a37de5d..bfc51cb 100644
@@ -315,8 +315,9 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, unsigned nr_free,
 	if (use_static)
 		pages_to_free = static_buf;
 	else
-		pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
-					GFP_KERNEL);
+		pages_to_free = kmalloc_array(npages_to_free,
+					      sizeof(*pages_to_free),
+					      GFP_KERNEL);
 	if (!pages_to_free) {
 		pr_err("Failed to allocate memory for pool free operation\n");
 		return 0;
@@ -501,8 +502,9 @@ static int ttm_alloc_new_pages(struct list_head *pages, gfp_t gfp_flags,
 			(unsigned)(PAGE_SIZE/sizeof(struct page *)));
 
 	/* allocate array for page caching change */
-	caching_array = kmalloc(max_cpages*sizeof(struct page *), GFP_KERNEL);
-
+	caching_array = kmalloc_array(max_cpages,
+				      sizeof(*caching_array),
+				      GFP_KERNEL);
 	if (!caching_array) {
 		pr_err("Unable to allocate table for new pages\n");
 		return -ENOMEM;
Signature · 1 line
2.10.0
#1031 lore raw

PATCH 2/14 GPU-DRM-TTM: Rename a jump label in ttm_alloc_new_pages()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 14:16:05 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/gpu/drm/ttm/ttm_page_alloc.c +3 -3
index bfc51cb..13fdd19 100644
@@ -527,7 +527,7 @@ static int ttm_alloc_new_pages(struct list_head *pages, gfp_t gfp_flags,
 						caching_array, cpages);
 			}
 			r = -ENOMEM;
-			goto out;
+			goto free_array;
 		}
 
 #ifdef CONFIG_HIGHMEM
@@ -546,7 +546,7 @@ static int ttm_alloc_new_pages(struct list_head *pages, gfp_t gfp_flags,
 					ttm_handle_caching_state_failure(pages,
 						ttm_flags, cstate,
 						caching_array, cpages);
-					goto out;
+					goto free_array;
 				}
 				cpages = 0;
 			}
@@ -562,7 +562,7 @@ static int ttm_alloc_new_pages(struct list_head *pages, gfp_t gfp_flags,
 					ttm_flags, cstate,
 					caching_array, cpages);
 	}
-out:
+ free_array:
 	kfree(caching_array);
 
 	return r;
Signature · 1 line
2.10.0
#1032 lore raw

PATCH 3/14 GPU-DRM-TTM: Rename jump labels in ttm_page_pool_free()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 14:30:12 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)
drivers/gpu/drm/ttm/ttm_page_alloc.c +4 -6
index 13fdd19..f33f6f6 100644
@@ -322,8 +322,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, unsigned nr_free,
 		pr_err("Failed to allocate memory for pool free operation\n");
 		return 0;
 	}
-
-restart:
+ lock_restart:
 	spin_lock_irqsave(&pool->lock, irq_flags);
 
 	list_for_each_entry_reverse(p, &pool->list, lru) {
@@ -356,14 +355,13 @@ restart:
 
 			/* free all so restart the processing */
 			if (nr_free)
-				goto restart;
+				goto lock_restart;
 
 			/* Not allowed to fall through or break because
 			 * following context is inside spinlock while we are
 			 * outside here.
 			 */
-			goto out;
-
+			goto check_pages_to_free;
 		}
 	}
 
@@ -379,7 +377,7 @@ restart:
 
 	if (freed_pages)
 		ttm_pages_put(pages_to_free, freed_pages);
-out:
+ check_pages_to_free:
 	if (pages_to_free != static_buf)
 		kfree(pages_to_free);
 	return nr_free;
Signature · 1 line
2.10.0
#1033 lore raw

PATCH 4/14 GPU-DRM-TTM: Rename a jump label in ttm_page_pool_get_pages()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 14:36:47 +0200

Adjust a jump label according to the current Linux coding style convention.

---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/ttm/ttm_page_alloc.c +2 -2
index f33f6f6..3dd603f 100644
@@ -646,7 +646,7 @@ static unsigned ttm_page_pool_get_pages(struct ttm_page_pool *pool,
 		list_splice_init(&pool->list, pages);
 		count -= pool->npages;
 		pool->npages = 0;
-		goto out;
+		goto unlock;
 	}
 	/* find the last pages to include for requested number of pages. Split
 	 * pool to begin and halve it to reduce search space. */
@@ -667,7 +667,7 @@ static unsigned ttm_page_pool_get_pages(struct ttm_page_pool *pool,
 	list_cut_position(pages, &pool->list, p);
 	pool->npages -= count;
 	count = 0;
-out:
+ unlock:
 	spin_unlock_irqrestore(&pool->lock, irq_flags);
 	return count;
 }
Signature · 1 line
2.10.0
#1034 lore raw

PATCH 5/14 GPU-DRM-TTM: Use kmalloc_array() in two more functions

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 14:48:39 +0200

* Multiplications for the size determination of memory allocations indicated that array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

* Replace the specification of data types by pointer dereferences to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +6 -4
index bef9f6f..194818d 100644
@@ -439,8 +439,9 @@ static unsigned ttm_dma_page_pool_free(struct dma_pool *pool, unsigned nr_free,
 	if (use_static)
 		pages_to_free = static_buf;
 	else
-		pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
-					GFP_KERNEL);
+		pages_to_free = kmalloc_array(npages_to_free,
+					      sizeof(*pages_to_free),
+					      GFP_KERNEL);
 
 	if (!pages_to_free) {
 		pr_err("%s: Failed to allocate memory for pool free operation\n",
@@ -726,8 +727,9 @@ static int ttm_dma_pool_alloc_new_pages(struct dma_pool *pool,
 			(unsigned)(PAGE_SIZE/sizeof(struct page *)));
 
 	/* allocate array for page caching change */
-	caching_array = kmalloc(max_cpages*sizeof(struct page *), GFP_KERNEL);
-
+	caching_array = kmalloc_array(max_cpages,
+				      sizeof(*caching_array),
+				      GFP_KERNEL);
 	if (!caching_array) {
 		pr_err("%s: Unable to allocate table for new pages\n",
 		       pool->dev_name);
Signature · 1 line
2.10.0
#1035 lore raw

PATCH 6/14 GPU-DRM-TTM: Rename a jump label in ttm_dma_pool_alloc_new_pages()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 14:54:12 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +3 -3
index 194818d..9dc1632 100644
@@ -758,7 +758,7 @@ static int ttm_dma_pool_alloc_new_pages(struct dma_pool *pool,
 						cpages);
 			}
 			r = -ENOMEM;
-			goto out;
+			goto free_array;
 		}
 		p = dma_p->p;
 #ifdef CONFIG_HIGHMEM
@@ -777,7 +777,7 @@ static int ttm_dma_pool_alloc_new_pages(struct dma_pool *pool,
 					ttm_dma_handle_caching_state_failure(
 						pool, d_pages, caching_array,
 						cpages);
-					goto out;
+					goto free_array;
 				}
 				cpages = 0;
 			}
@@ -791,7 +791,7 @@ static int ttm_dma_pool_alloc_new_pages(struct dma_pool *pool,
 			ttm_dma_handle_caching_state_failure(pool, d_pages,
 					caching_array, cpages);
 	}
-out:
+ free_array:
 	kfree(caching_array);
 	return r;
 }
Signature · 1 line
2.10.0
#1036 lore raw

PATCH 7/14 GPU-DRM-TTM: Rename jump labels in ttm_dma_page_pool_free()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 15:32:32 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +4 -5
index 9dc1632..ce3d361 100644
@@ -449,7 +449,7 @@ static unsigned ttm_dma_page_pool_free(struct dma_pool *pool, unsigned nr_free,
 		return 0;
 	}
 	INIT_LIST_HEAD(&d_pages);
-restart:
+ lock_restart:
 	spin_lock_irqsave(&pool->lock, irq_flags);
 
 	/* We picking the oldest ones off the list */
@@ -489,14 +489,13 @@ restart:
 
 			/* free all so restart the processing */
 			if (nr_free)
-				goto restart;
+				goto lock_restart;
 
 			/* Not allowed to fall through or break because
 			 * following context is inside spinlock while we are
 			 * outside here.
 			 */
-			goto out;
-
+			goto check_pages_to_free;
 		}
 	}
 
@@ -510,7 +509,7 @@ restart:
 
 	if (freed_pages)
 		ttm_dma_pages_put(pool, &d_pages, pages_to_free, freed_pages);
-out:
+ check_pages_to_free:
 	if (pages_to_free != static_buf)
 		kfree(pages_to_free);
 	return nr_free;
Signature · 1 line
2.10.0
#1037 lore raw

PATCH 8/14 GPU-DRM-TTM: Rename a jump label in ttm_dma_pool_shrink_scan()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 16:02:36 +0200

Adjust a jump label according to the current Linux coding style convention.

---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +2 -2
index ce3d361..e3f5542 100644
@@ -1025,7 +1025,7 @@ ttm_dma_pool_shrink_scan(struct shrinker *shrink, struct shrink_control *sc)
 	if (!mutex_trylock(&_manager->lock))
 		return SHRINK_STOP;
 	if (!_manager->npools)
-		goto out;
+		goto unlock;
 	pool_offset = ++start_pool % _manager->npools;
 	list_for_each_entry(p, &_manager->pools, pools) {
 		unsigned nr_free;
@@ -1046,7 +1046,7 @@ ttm_dma_pool_shrink_scan(struct shrinker *shrink, struct shrink_control *sc)
 			 p->pool->dev_name, p->pool->name, current->pid,
 			 nr_free, shrink_pages);
 	}
-out:
+ unlock:
 	mutex_unlock(&_manager->lock);
 	return freed;
 }
Signature · 1 line
2.10.0
#1038 lore raw

PATCH 9/14 GPU-DRM-TTM: Return directly after a failed kzalloc() in ttm_dma_page_alloc_init()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 16:16:36 +0200

* Return directly after a memory allocation failed in this function at the beginning.

* Delete the explicit initialisation for the local variable "ret" which became unnecessary with this refactoring.

---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +2 -2
index e3f5542..feba278 100644
@@ -1080,7 +1080,7 @@ static void ttm_dma_pool_mm_shrink_fini(struct ttm_pool_manager *manager)
 
 int ttm_dma_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
 {
-	int ret = -ENOMEM;
+	int ret;
 
 	WARN_ON(_manager);
 
@@ -1088,7 +1088,7 @@ int ttm_dma_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
 
 	_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
 	if (!_manager)
-		goto err;
+		return -ENOMEM;
 
 	mutex_init(&_manager->lock);
 	INIT_LIST_HEAD(&_manager->pools);
Signature · 1 line
2.10.0
#1039 lore raw

PATCH 10/14 GPU-DRM-TTM: Return directly after a failed kobject_init_and_add() in ttm_dma_page_alloc_init()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 16:24:43 +0200

* Return directly after a call of the function "kobject_init_and_add" failed here.

* Delete the jump target "err" which became unnecessary with this refactoring.

---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +1 -3
index feba278..c21f45f 100644
@@ -1102,12 +1102,10 @@ int ttm_dma_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
 				   &glob->kobj, "dma_pool");
 	if (unlikely(ret != 0)) {
 		kobject_put(&_manager->kobj);
-		goto err;
+		return ret;
 	}
 	ttm_dma_pool_mm_shrink_init(_manager);
 	return 0;
-err:
-	return ret;
 }
 
 void ttm_dma_page_alloc_fini(void)
Signature · 1 line
2.10.0
#1040 lore raw

PATCH 11/14 GPU-DRM-TTM: Return an error code only as a constant in ttm_dma_pool_init()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 17:17:19 +0200

* Return an error code without storing it in a local variable.

* Delete the local variable "ret" which became unnecessary with this refactoring.

---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +1 -4
index c21f45f..d5f41ed 100644
@@ -579,7 +579,6 @@ static struct dma_pool *ttm_dma_pool_init(struct device *dev, gfp_t flags,
 	struct device_pools *sec_pool = NULL;
 	struct dma_pool *pool = NULL, **ptr;
 	unsigned i;
-	int ret = -ENODEV;
 	char *p;
 
 	if (!dev)
@@ -589,8 +588,6 @@ static struct dma_pool *ttm_dma_pool_init(struct device *dev, gfp_t flags,
 	if (!ptr)
 		return NULL;
 
-	ret = -ENOMEM;
-
 	pool = kmalloc_node(sizeof(struct dma_pool), GFP_KERNEL,
 			    dev_to_node(dev));
 	if (!pool)
@@ -644,7 +641,7 @@ err_mem:
 	devres_free(ptr);
 	kfree(sec_pool);
 	kfree(pool);
-	return ERR_PTR(ret);
+	return ERR_PTR(-ENOMEM);
 }
 
 static struct dma_pool *ttm_dma_find_pool(struct device *dev,
Signature · 1 line
2.10.0
#1041 lore raw

PATCH 12/14 GPU-DRM-TTM: Less function calls in ttm_dma_pool_init() after error detection

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 17:30:52 +0200

The kfree() function was called in up to two cases by the ttm_dma_pool_init() function during error handling even if the passed variable contained a null pointer.

Adjust jump targets according to the Linux coding style convention.

---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +5 -5
index d5f41ed..4c50196 100644
@@ -591,12 +591,12 @@ static struct dma_pool *ttm_dma_pool_init(struct device *dev, gfp_t flags,
 	pool = kmalloc_node(sizeof(struct dma_pool), GFP_KERNEL,
 			    dev_to_node(dev));
 	if (!pool)
-		goto err_mem;
+		goto free_devres;
 
 	sec_pool = kmalloc_node(sizeof(struct device_pools), GFP_KERNEL,
 				dev_to_node(dev));
 	if (!sec_pool)
-		goto err_mem;
+		goto free_pool;
 
 	INIT_LIST_HEAD(&sec_pool->pools);
 	sec_pool->dev = dev;
@@ -637,10 +637,10 @@ static struct dma_pool *ttm_dma_pool_init(struct device *dev, gfp_t flags,
 	devres_add(dev, ptr);
 
 	return pool;
-err_mem:
-	devres_free(ptr);
-	kfree(sec_pool);
+ free_pool:
 	kfree(pool);
+ free_devres:
+	devres_free(ptr);
 	return ERR_PTR(-ENOMEM);
 }
 
Signature · 1 line
2.10.0
#1042 lore raw

PATCH 13/14 GPU-DRM-TTM: Delete unnecessary variable initialisations in ttm_dma_pool_init()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 17:37:24 +0200

Two local variables will be set to an appropriate pointer a bit later. Thus omit the explicit initialisation which became unnecessary with a previous update step.

---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +2 -2
index 4c50196..aa1679d 100644
@@ -576,8 +576,8 @@ static struct dma_pool *ttm_dma_pool_init(struct device *dev, gfp_t flags,
 {
 	char *n[] = {"wc", "uc", "cached", " dma32", "unknown",};
 	enum pool_type t[] = {IS_WC, IS_UC, IS_CACHED, IS_DMA32, IS_UNDEFINED};
-	struct device_pools *sec_pool = NULL;
-	struct dma_pool *pool = NULL, **ptr;
+	struct device_pools *sec_pool;
+	struct dma_pool *pool, **ptr;
 	unsigned i;
 	char *p;
 
Signature · 1 line
2.10.0
#1043 lore raw

PATCH 14/14 GPU-DRM-TTM: Mark an array of text strings as "const" in ttm_dma_pool_init()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 18:46:01 +0200

The local variable "n" was not modified after it was initialized with a few text strings.
Thus express this detail also by the data type qualifier "const".

---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +1 -1
index aa1679d..e21c1b3 100644
@@ -574,7 +574,7 @@ static int ttm_dma_pool_match(struct device *dev, void *res, void *match_data)
 static struct dma_pool *ttm_dma_pool_init(struct device *dev, gfp_t flags,
 					  enum pool_type type)
 {
-	char *n[] = {"wc", "uc", "cached", " dma32", "unknown",};
+	char const * const n[] = {"wc", "uc", "cached", " dma32", "unknown",};
 	enum pool_type t[] = {IS_WC, IS_UC, IS_CACHED, IS_DMA32, IS_UNDEFINED};
 	struct device_pools *sec_pool;
 	struct dma_pool *pool, **ptr;
Signature · 1 line
2.10.0
maintainer
#1044 lore raw

Re: [PATCH 14/14] GPU-DRM-TTM: Mark an array of text strings as "const" in ttm_dma_pool_init()

Quoted 3 lines · SF Markus Elfring

The local variable "n" was not modified after it was initialized with a few text strings.
Thus express this detail also by the data type qualifier "const".

[]

drivers/gpu/drm/ttm/ttm_page_alloc_dma.c

Quoted 1 line
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +0 -0

[]

drivers/gpu/drm/ttm/ttm_page_alloc_dma.c static int ttm_dma_pool_match(struct device *dev, void *res, void *match_data) · line 578

Quoted 7 lines
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +1 -1
@@ -574,7 +574,7 @@ static int ttm_dma_pool_match(struct device *dev, void *res, void *match_data)
 static struct dma_pool *ttm_dma_pool_init(struct device *dev, gfp_t flags,
 					  enum pool_type type)
 {
-	char *n[] = {"wc", "uc", "cached", " dma32", "unknown",};
+	char const * const n[] = {"wc", "uc", "cached", " dma32", "unknown",};
 	enum pool_type t[] = {IS_WC, IS_UC, IS_CACHED, IS_DMA32, IS_UNDEFINED};

Please think a little deeper about what you are changing here and look at the line immediately below it too.

Both should be static const to avoid unnecessary reload.

#1045 lore raw

Re: [PATCH 00/14] GPU-DRM-TTM: Fine-tuning for several function implementations

In reply to SF Markus Elfring

First of all please stop sending your patches as a reply to an earlier and completely unrelated series.

Second please prefix all TTM related patches with "drm/ttm:".

Additional to that I don't really see the point in renaming some of the jump labels, if you call it "restart" or "lock_restart" doesn't make much difference.

Regards,
Christian.

Am 22.09.2016 um 19:32 schrieb SF Markus Elfring:

Quoted 26 lines

From: Markus Elfring <[email protected]>
Date: Thu, 22 Sep 2016 19:00:01 +0200

Several update suggestions were taken into account from static source code analysis.

Markus Elfring (14):
Use kmalloc_array() in two functions
Rename a jump label in ttm_alloc_new_pages()
Rename jump labels in ttm_page_pool_free()
Rename a jump label in ttm_page_pool_get_pages()
Use kmalloc_array() in two more functions
Rename a jump label in ttm_dma_pool_alloc_new_pages()
Rename jump labels in ttm_dma_page_pool_free()
Rename a jump label in ttm_dma_pool_shrink_scan()
Return directly after a failed kzalloc() in ttm_dma_page_alloc_init() Return directly after a failed kobject_init_and_add() in ttm_dma_page_alloc_init() Return an error code only as a constant in ttm_dma_pool_init()
Less function calls in ttm_dma_pool_init() after error detection Delete unnecessary variable initialisations in ttm_dma_pool_init() Mark an array of text strings as "const" in ttm_dma_pool_init()

  drivers/gpu/drm/ttm/ttm_page_alloc.c     | 30 ++++++++---------
  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 58 +++++++++++++++-----------------
  2 files changed, 42 insertions(+), 46 deletions(-)
#1046 lore raw

Re: GPU-DRM-TTM: Fine-tuning for several function implementations

Quoted 1 line

Additional to that I don't really see the point in renaming some of the jump labels,

I am suggesting changes for another collateral software evolution.

Quoted 1 line

if you call it "restart" or "lock_restart" doesn't make much difference.

Do other identifiers fit better to a specification from the document "CodingStyle" like the following?

"…
Choose label names which say what the goto does or why the goto exists. …"

Does this wording need any more adjustments?

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#1047 lore raw

Re: GPU-DRM-TTM: Fine-tuning for several function implementations

Am 23.09.2016 um 12:20 schrieb SF Markus Elfring:

Quoted 7 lines
Quoted 1 line

Additional to that I don't really see the point in renaming some of the jump labels,

I am suggesting changes for another collateral software evolution.

Quoted 1 line

if you call it "restart" or "lock_restart" doesn't make much difference.

Do other identifiers fit better to a specification from the document "CodingStyle" like the following?

No, not really.

Quoted 7 lines

"…
Choose label names which say what the goto does or why the goto exists. …"

Does this wording need any more adjustments?

Of hand I can't find any better wording.

It's just the names like "out" or "restart" perfectly explain why the labels exists. So they fulfill this requirement from the coding style as far as I can see.

So why do you want to change them?

Regards,
Christian.

Quoted 3 lines

Regards,
Markus

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#1048 lore raw

Re: GPU-DRM-TTM: Fine-tuning for several function implementations

Quoted 1 line

It's just the names like "out" or "restart" perfectly explain why the labels exists.

I have got an other impression.

Quoted 1 line

So they fulfill this requirement from the coding style as far as I can see.

Short identifiers might look more convenient in some cases because they are quicker to type.

Quoted 1 line

So why do you want to change them?

1. I suggest to select identifiers also for jump labels which are more meaningful and eventually unique for some function implementations.

2. How do you think about to add a single space character before any label?

Regards,
Markus

#1049 lore raw

Re: GPU-DRM-TTM: Fine-tuning for several function implementations

Am 23.09.2016 um 13:07 schrieb SF Markus Elfring:

Quoted 4 lines
Quoted 1 line

It's just the names like "out" or "restart" perfectly explain why the labels exists.

I have got an other impression.

Quoted 8 lines
Quoted 1 line

So they fulfill this requirement from the coding style as far as I can see.

Short identifiers might look more convenient in some cases because they are quicker to type.

Quoted 1 line

So why do you want to change them?

1. I suggest to select identifiers also for jump labels which are more meaningful and eventually unique for some function implementations.

I completely disagree. A longer identifier is not necessarily more meaningful than a shorter one.

The difference between calling a label "retry" and "lock_retry" is negligible, doesn't improve readability as far as I can see and is actually incorrect because the main meaning of the label is that we don't take the lock but rather that we restart the allocation operation.

Calling the label "unlock" instead of "out" is arguable a little better, but nothing I would call a major improvement either.

So that is a clear NAK to all those patches.

Quoted 1 line

2. How do you think about to add a single space character before any label?

Bad as well. Why would anybody want to do this?

Christian.

Quoted 3 lines

Regards,
Markus

#1050 lore raw

Re: GPU-DRM-TTM: Fine-tuning for several function implementations

Quoted 1 line

Calling the label "unlock" instead of "out" is arguable a little better,

Thanks that you can follow a renaming for this direction in principle.

Quoted 1 line

but nothing I would call a major improvement either.

This was not my intention for such an use case.

I am proposing some small software updates according to such a design pattern.

Quoted 1 line

So that is a clear NAK to all those patches.

Do you reject also update steps like the following then?

* drm/ttm: Use kmalloc_array() in two (or four?) functions"

* drm/ttm: Less function calls in ttm_dma_pool_init() after error detection

* Would you like to improve the usage of the variables "n" and "t" in the function "ttm_dma_pool_init" any further as Joe Perches suggested it?

Quoted 3 lines
Quoted 1 line

2. How do you think about to add a single space character before any label?

Bad as well. Why would anybody want to do this?

Do you find another software evolution interesting according to a recent commit?

"docs: Remove space-before-label guidance from CodingStyle"
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?idyc70c304b0b443429b2a0019518532c5162817a

Regards,
Markus

#1051 lore raw

Re: GPU-DRM-TTM: Fine-tuning for several function implementations

Am 23.09.2016 um 13:49 schrieb SF Markus Elfring:

Quoted 10 lines
Quoted 1 line

Calling the label "unlock" instead of "out" is arguable a little better,

Thanks that you can follow a renaming for this direction in principle.

Quoted 1 line

but nothing I would call a major improvement either.

This was not my intention for such an use case.

I am proposing some small software updates according to such a design pattern.

Quoted 6 lines
Quoted 1 line

So that is a clear NAK to all those patches.

Do you reject also update steps like the following then?

* drm/ttm: Use kmalloc_array() in two (or four?) functions"

* drm/ttm: Less function calls in ttm_dma_pool_init() after error detection

The reason behind the advise to use kmalloc_array() is to avoid overruns when one of the parameters come from an IOCTL and so are controllable by user space.

Those overruns where the source of numerous security problems, but in this case the parameters don't come from an IOCTL and aren't user space controllable.

So this change actually doesn't make to much sense either, but I'm leaning towards accepting them for coding style consistency.

Regards,
Christian.

Quoted 14 lines

* Would you like to improve the usage of the variables "n" and "t" in the function "ttm_dma_pool_init" any further as Joe Perches suggested it?

Quoted 2 lines
Quoted 1 line

2. How do you think about to add a single space character before any label?

Bad as well. Why would anybody want to do this?

Do you find another software evolution interesting according to a recent commit?

"docs: Remove space-before-label guidance from CodingStyle"
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?idyc70c304b0b443429b2a0019518532c5162817a

Regards,
Markus

#1052 lore raw

Re: GPU-DRM-TTM: Fine-tuning for several function implementations

In reply to SF Markus Elfring
Quoted 11 lines · SF Markus Elfring
Quoted 1 line

if you call it "restart" or "lock_restart" doesn't make much difference.

Do other identifiers fit better to a specification from the document "CodingStyle" like the following?

"…
Choose label names which say what the goto does or why the goto exists. …"

Does this wording need any more adjustments?

No. I wrote that and "restart" seems like a pretty clear name to me. I never wrote that you should harrass people with your nonsense patches. In fact, I have asked you over and over again to stop.

regards,
dan carpenter

#1053 lore raw

Re: GPU-DRM-TTM: Fine-tuning for several function implementations

Quoted 11 lines
Quoted 9 lines

Do other identifiers fit better to a specification from the document "CodingStyle" like the following?

"…
Choose label names which say what the goto does or why the goto exists. …"

Does this wording need any more adjustments?

No.

I have got an other impression.

The terse description can trigger disagreements about the "what" and "why", can't it?

Quoted 1 line

I wrote that and "restart" seems like a pretty clear name to me.

This identifier might be good enough to some degree.
I imagined that it would become better by the addition of a bit of information from the jump target.

Quoted 1 line

I never wrote that you should harrass people with your nonsense patches.

This is true in principle.

But your adjustment for the document "CodingStyle" supported also a reconsideration of the corresponding identifier selection.

Some developers disagreed with a proposed renaming while others reacted in a positive way.

Quoted 1 line

In fact, I have asked you over and over again to stop.

This happened under different software update contexts occasionally.

Regards,
Markus

#1054 lore raw

cover i2c-dev: Fine-tuning for four function implementations

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Fri, 23 Sep 2016 21:38:21 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (4):
Use kmalloc_array() in i2cdev_ioctl_rdwr() Improve another size determination in i2cdev_ioctl_rdwr() Rename jump labels in i2cdev_attach_adapter() Adjust checks for null pointers in three functions

 drivers/i2c/i2c-dev.c | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)
Signature · 1 line
2.10.0
#1055 lore raw

PATCH 1/4 i2c-dev: Use kmalloc_array() in i2cdev_ioctl_rdwr()

From: Markus Elfring <[email protected]>
Date: Fri, 23 Sep 2016 20:30:07 +0200

* A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

* Replace the specification of a data type by a pointer dereference to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/i2c/i2c-dev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/i2c/i2c-dev.c +3 -1
index 66f323f..6d8226d 100644
@@ -260,7 +260,9 @@ static noinline int i2cdev_ioctl_rdwr(struct i2c_client *client,
 	if (IS_ERR(rdwr_pa))
 		return PTR_ERR(rdwr_pa);
 
-	data_ptrs = kmalloc(rdwr_arg.nmsgs * sizeof(u8 __user *), GFP_KERNEL);
+	data_ptrs = kmalloc_array(rdwr_arg.nmsgs,
+				  sizeof(*data_ptrs),
+				  GFP_KERNEL);
 	if (data_ptrs = NULL) {
 		kfree(rdwr_pa);
 		return -ENOMEM;
Signature · 1 line
2.10.0
#1056 lore raw

PATCH 2/4 i2c-dev: Improve another size determination in i2cdev_ioctl_rdwr()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Fri, 23 Sep 2016 20:45:40 +0200

Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/i2c/i2c-dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/i2c/i2c-dev.c +1 -1
index 6d8226d..a6e35ce 100644
@@ -256,7 +256,7 @@ static noinline int i2cdev_ioctl_rdwr(struct i2c_client *client,
 		return -EINVAL;
 
 	rdwr_pa = memdup_user(rdwr_arg.msgs,
-			      rdwr_arg.nmsgs * sizeof(struct i2c_msg));
+			      rdwr_arg.nmsgs * sizeof(*rdwr_pa));
 	if (IS_ERR(rdwr_pa))
 		return PTR_ERR(rdwr_pa);
 
Signature · 1 line
2.10.0
#1057 lore raw

PATCH 3/4 i2c-dev: Rename jump labels in i2cdev_attach_adapter()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Fri, 23 Sep 2016 21:21:39 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/i2c/i2c-dev.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/i2c/i2c-dev.c +4 -4
index a6e35ce..7d3e3ca 100644
@@ -555,7 +555,7 @@ static int i2cdev_attach_adapter(struct device *dev, void *dummy)
 	i2c_dev->cdev.owner = THIS_MODULE;
 	res = cdev_add(&i2c_dev->cdev, MKDEV(I2C_MAJOR, adap->nr), 1);
 	if (res)
-		goto error_cdev;
+		goto put_i2c;
 
 	/* register this i2c device with the driver core */
 	i2c_dev->dev = device_create(i2c_dev_class, &adap->dev,
@@ -563,15 +563,15 @@ static int i2cdev_attach_adapter(struct device *dev, void *dummy)
 				     "i2c-%d", adap->nr);
 	if (IS_ERR(i2c_dev->dev)) {
 		res = PTR_ERR(i2c_dev->dev);
-		goto error;
+		goto delete_cdev;
 	}
 
 	pr_debug("i2c-dev: adapter [%s] registered as minor %d\n",
 		 adap->name, adap->nr);
 	return 0;
-error:
+delete_cdev:
 	cdev_del(&i2c_dev->cdev);
-error_cdev:
+put_i2c:
 	put_i2c_dev(i2c_dev);
 	return res;
 }
Signature · 1 line
2.10.0
#1058 lore raw

PATCH 4/4 i2c-dev: Adjust checks for null pointers in three functions

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Fri, 23 Sep 2016 21:30:20 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The script "checkpatch.pl" can point information out like the following.

Comparison to NULL could be written !…

Thus fix the affected source code places.

---
 drivers/i2c/i2c-dev.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/i2c/i2c-dev.c +3 -3
index 7d3e3ca..8f7eddd 100644
@@ -147,7 +147,7 @@ static ssize_t i2cdev_read(struct file *file, char __user *buf, size_t count,
 		count = 8192;
 
 	tmp = kmalloc(count, GFP_KERNEL);
-	if (tmp = NULL)
+	if (!tmp)
 		return -ENOMEM;
 
 	pr_debug("i2c-dev: i2c-%d reading %zu bytes.\n",
@@ -263,7 +263,7 @@ static noinline int i2cdev_ioctl_rdwr(struct i2c_client *client,
 	data_ptrs = kmalloc_array(rdwr_arg.nmsgs,
 				  sizeof(*data_ptrs),
 				  GFP_KERNEL);
-	if (data_ptrs = NULL) {
+	if (!data_ptrs) {
 		kfree(rdwr_pa);
 		return -ENOMEM;
 	}
@@ -374,7 +374,7 @@ static noinline int i2cdev_ioctl_smbus(struct i2c_client *client,
 				      client->flags, data_arg.read_write,
 				      data_arg.command, data_arg.size, NULL);
 
-	if (data_arg.data = NULL) {
+	if (!data_arg.data) {
 		dev_dbg(&client->adapter->dev,
 			"data is NULL pointer in ioctl I2C_SMBUS.\n");
 		return -EINVAL;
Signature · 6 lines
2.10.0

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#1059 lore raw

cover iio: Fine-tuning for several function implementations

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 24 Sep 2016 08:10:08 +0200

Some update suggestions were taken into account
from static source code analysis.

Markus Elfring (7):
Use kmalloc_array() in iio_scan_mask_set() Rename a jump label in iio_buffer_store_watermark() Rename a jump label in iio_buffer_store_enable() Rename a jump label in iio_buffer_write_length() Rename a jump label in iio_scan_el_ts_store() Rename a jump label in iio_scan_el_store() Adjust checks for null pointers in six functions

 drivers/iio/industrialio-buffer.c | 55 ++++++++++++++++++---------------------
 1 file changed, 26 insertions(+), 29 deletions(-)
Signature · 1 line
2.10.0
#1060 lore raw

PATCH 1/7 iio: Use kmalloc_array() in iio_scan_mask_set()

From: Markus Elfring <[email protected]>
Date: Fri, 23 Sep 2016 22:30:32 +0200

A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

---
 drivers/iio/industrialio-buffer.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
drivers/iio/industrialio-buffer.c +3 -4
index 49bf9c5..7a4d9499 100644
@@ -307,10 +307,9 @@ static int iio_scan_mask_set(struct iio_dev *indio_dev,
 	const unsigned long *mask;
 	unsigned long *trialmask;
 
-	trialmask = kmalloc(sizeof(*trialmask)*
-			    BITS_TO_LONGS(indio_dev->masklength),
-			    GFP_KERNEL);
-
+	trialmask = kmalloc_array(BITS_TO_LONGS(indio_dev->masklength),
+				  sizeof(*trialmask),
+				  GFP_KERNEL);
 	if (trialmask = NULL)
 		return -ENOMEM;
 	if (!indio_dev->masklength) {
Signature · 1 line
2.10.0
maintainer Applied
#1061 lore raw

Re: [PATCH 1/7] iio: Use kmalloc_array() in iio_scan_mask_set()

Quoted 10 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Fri, 23 Sep 2016 22:30:32 +0200

A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

Applied to the togreg branch of iio.git - initially pushed out as testing for the autobuilders to play with it.

Thanks,

Jonathan

Quoted 23 lines
---
 drivers/iio/industrialio-buffer.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
drivers/iio/industrialio-buffer.c +3 -4
index 49bf9c5..7a4d9499 100644
@@ -307,10 +307,9 @@ static int iio_scan_mask_set(struct iio_dev *indio_dev,
 	const unsigned long *mask;
 	unsigned long *trialmask;
 
-	trialmask = kmalloc(sizeof(*trialmask)*
-			    BITS_TO_LONGS(indio_dev->masklength),
-			    GFP_KERNEL);
-
+	trialmask = kmalloc_array(BITS_TO_LONGS(indio_dev->masklength),
+				  sizeof(*trialmask),
+				  GFP_KERNEL);
 	if (trialmask = NULL)
 		return -ENOMEM;
 	if (!indio_dev->masklength) {
#1062 lore raw

Re: [PATCH 1/7] iio: Use kmalloc_array() in iio_scan_mask_set()

Quoted 2 lines

Applied to the togreg branch of iio.git - initially pushed out as testing for the autobuilders to play with it.

Thanks for your positive response.

Do you see any need to improve the software situation around the macro "BITS_TO_LONGS" further?

Do you fiddle with a programming interface like "bitmap_alloc" occasionally?

Regards,
Markus

maintainer
#1063 lore raw

Re: [PATCH 1/7] iio: Use kmalloc_array() in iio_scan_mask_set()

Quoted 10 lines · SF Markus Elfring
Quoted 2 lines

Applied to the togreg branch of iio.git - initially pushed out as testing for the autobuilders to play with it.

Thanks for your positive response.

Do you see any need to improve the software situation around the macro "BITS_TO_LONGS" further?

Do you fiddle with a programming interface like "bitmap_alloc" occasionally?

It might be clearer than having an array allocation as we do after this patch. Obviously the representation is an array, but it is a little ugly as it stands!

Quoted 8 lines

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#1064 lore raw

PATCH 2/7 iio: Rename a jump label in iio_buffer_store_watermark()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 24 Sep 2016 06:54:49 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/iio/industrialio-buffer.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/iio/industrialio-buffer.c +3 -3
index 7a4d9499..a865af8 100644
@@ -1028,16 +1028,16 @@ static ssize_t iio_buffer_store_watermark(struct device *dev,
 
 	if (val > buffer->length) {
 		ret = -EINVAL;
-		goto out;
+		goto unlock;
 	}
 
 	if (iio_buffer_is_active(indio_dev->buffer)) {
 		ret = -EBUSY;
-		goto out;
+		goto unlock;
 	}
 
 	buffer->watermark = val;
-out:
+unlock:
 	mutex_unlock(&indio_dev->mlock);
 
 	return ret ? ret : len;
Signature · 1 line
2.10.0
maintainer
#1065 lore raw

Re: [PATCH 2/7] iio: Rename a jump label in iio_buffer_store_watermark()

Quoted 6 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 24 Sep 2016 06:54:49 +0200

Adjust jump labels according to the current Linux coding style convention.

I'm not necessarily against this change which does perhaps clarify the code ever so slightly, but I am interested to know where
'current Linux coding style convention' comes from?

Jonathan

Quoted 29 lines
---
 drivers/iio/industrialio-buffer.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/iio/industrialio-buffer.c +3 -3
index 7a4d9499..a865af8 100644
@@ -1028,16 +1028,16 @@ static ssize_t iio_buffer_store_watermark(struct device *dev,
 
 	if (val > buffer->length) {
 		ret = -EINVAL;
-		goto out;
+		goto unlock;
 	}
 
 	if (iio_buffer_is_active(indio_dev->buffer)) {
 		ret = -EBUSY;
-		goto out;
+		goto unlock;
 	}
 
 	buffer->watermark = val;
-out:
+unlock:
 	mutex_unlock(&indio_dev->mlock);
 
 	return ret ? ret : len;
#1066 lore raw

Re: iio: Rename a jump label in iio_buffer_store_watermark()

Quoted 2 lines

I'm not necessarily against this change which does perhaps clarify the code ever so slightly,

Thanks for another bit of positive feedback.

Quoted 1 line

but I am interested to know where 'current Linux coding style convention' comes from?

How often do you check the status of a document like "CodingStyle" for example? ;-)

How do you think about information from a commit like
"docs: Remove space-before-label guidance from CodingStyle" (on 2016-09-21)?
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?idyc70c304b0b443429b2a0019518532c5162817a

Regards,
Markus

maintainer
#1067 lore raw

Re: iio: Rename a jump label in iio_buffer_store_watermark()

Quoted 9 lines · SF Markus Elfring
Quoted 2 lines

I'm not necessarily against this change which does perhaps clarify the code ever so slightly,

Thanks for another bit of positive feedback.

Quoted 1 line

but I am interested to know where 'current Linux coding style convention' comes from?

How often do you check the status of a document like "CodingStyle" for example? ;-)

Every time I see a patch doing a style change I don't remember being there last time I looked ;)

I'm not seeing this one in there. Which tool is spitting it out? Or is the test yours?

Quoted 4 lines

How do you think about information from a commit like
"docs: Remove space-before-label guidance from CodingStyle" (on 2016-09-21)?
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?idyc70c304b0b443429b2a0019518532c5162817a

Yeah, I saw the discussion / flame war that resulted in that revert...

Quoted 4 lines

Regards,
Markus

#1068 lore raw

Re: iio: Rename a jump label in iio_buffer_store_watermark()

Quoted 1 line

I'm not seeing this one in there.

How much do you care about selection of appropriate identifiers in source files?

Quoted 1 line

Which tool is spitting it out?

Are you looking for any special tool?

Quoted 1 line

Or is the test yours?

Which test do you mean?

Quoted 1 line

Yeah, I saw the discussion / flame war that resulted in that revert...

Would you like to share any more constructive ideas for this software evolution?

Regards,
Markus

maintainer
#1069 lore raw

Re: iio: Rename a jump label in iio_buffer_store_watermark()

Quoted 3 lines · SF Markus Elfring
Quoted 1 line

I'm not seeing this one in there.

How much do you care about selection of appropriate identifiers in source files?

It's not an inappropriate identifier as it stands. The point is that it could be better.

Quoted 5 lines
Quoted 3 lines

Which tool is spitting it out?

Are you looking for any special tool?

I was wondering how you identified these particular issues as I wanted to know the logic behind the test.

Quoted 5 lines
Quoted 3 lines

Or is the test yours?

Which test do you mean?

Whatever you used to find these jump labels (the patch series description suggested it was a static checker).

Quoted 5 lines
Quoted 3 lines

Yeah, I saw the discussion / flame war that resulted in that revert...

Would you like to share any more constructive ideas for this software evolution?

Not a lot of time at the moment, sorry.

Jonathan

Quoted 4 lines

Regards,
Markus

#1070 lore raw

Re: iio: Rename a jump label in iio_buffer_store_watermark()

Quoted 2 lines

It's not an inappropriate identifier as it stands. The point is that it could be better.

Thanks for your interest in clarifying further improvement possibilities.

Quoted 5 lines
Quoted 3 lines
Quoted 1 line

Which tool is spitting it out?

Are you looking for any special tool?

I was wondering how you identified these particular issues as I wanted to know the logic behind the test.

Do you get any related ideas from information in a message like "Source code review around jump label usage" (from 2015-12-11)?

https://lkml.org/lkml/2015/12/11/378
https://lkml.kernel.org/r/<[email protected]>

Quoted 2 lines
Quoted 1 line

Which test do you mean?

Whatever you used to find these jump labels

There is a general possibility that dedicated scripts for the semantic patch language can also adjust jump labels as I suggested it for five functions in this software.

Quoted 1 line

(the patch series description suggested it was a static checker).

The corresponding five patches are just a result of a source code review by the means of a current text editor wit extra support for programming.

How do you think about to improve the capabilities of tools for advanced static source code analysis any further?

Regards,
Markus

maintainer
#1071 lore raw

Re: iio: Rename a jump label in iio_buffer_store_watermark()

Quoted 27 lines · SF Markus Elfring
Quoted 2 lines

It's not an inappropriate identifier as it stands. The point is that it could be better.

Thanks for your interest in clarifying further improvement possibilities.

Quoted 5 lines
Quoted 3 lines
Quoted 1 line

Which tool is spitting it out?

Are you looking for any special tool?

I was wondering how you identified these particular issues as I wanted to know the logic behind the test.

Do you get any related ideas from information in a message like "Source code review around jump label usage" (from 2015-12-11)?

https://lkml.org/lkml/2015/12/11/378
https://lkml.kernel.org/r/<[email protected]>

Quoted 2 lines
Quoted 1 line

Which test do you mean?

Whatever you used to find these jump labels

There is a general possibility that dedicated scripts for the semantic patch language can also adjust jump labels as I suggested it for five functions in this software.

Quoted 4 lines
Quoted 1 line

(the patch series description suggested it was a static checker).

The corresponding five patches are just a result of a source code review by the means of a current text editor wit extra support for programming.

To my mind there is a divide between the cost of making changes like this as a result of initial review and that of doing it on existing code.

I don't think this one is worth while for existing code.

Quoted 11 lines

How do you think about to improve the capabilities of tools for advanced static source code analysis any further?

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#1072 lore raw

Re: iio: Rename a jump label in iio_buffer_store_watermark()

Quoted 2 lines

To my mind there is a divide between the cost of making changes like this as a result of initial review and that of doing it on existing code.

I can follow this view.

Quoted 1 line

I don't think this one is worth while for existing code.

How do you think about once more to increase the usage of the jump label "unlock" also for this software module?

Regards,
Markus

#1073 lore raw

PATCH 3/7 iio: Rename a jump label in iio_buffer_store_enable()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 24 Sep 2016 07:11:32 +0200

Adjust a jump label according to the current Linux coding style convention.

---
 drivers/iio/industrialio-buffer.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/iio/industrialio-buffer.c +2 -3
index a865af8..6509f0f 100644
@@ -982,7 +982,7 @@ static ssize_t iio_buffer_store_enable(struct device *dev,
 	inlist = iio_buffer_is_active(indio_dev->buffer);
 	/* Already in desired state */
 	if (inlist = requested_state)
-		goto done;
+		goto unlock;
 
 	if (requested_state)
 		ret = __iio_update_buffers(indio_dev,
@@ -990,8 +990,7 @@ static ssize_t iio_buffer_store_enable(struct device *dev,
 	else
 		ret = __iio_update_buffers(indio_dev,
 					 NULL, indio_dev->buffer);
-
-done:
+unlock:
 	mutex_unlock(&indio_dev->mlock);
 	return (ret < 0) ? ret : len;
 }
Signature · 1 line
2.10.0
#1074 lore raw

PATCH 4/7 iio: Rename a jump label in iio_buffer_write_length()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 24 Sep 2016 07:17:44 +0200

Adjust a jump label according to the current Linux coding style convention.

---
 drivers/iio/industrialio-buffer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/iio/industrialio-buffer.c +2 -2
index 6509f0f..376101f 100644
@@ -505,10 +505,10 @@ static ssize_t iio_buffer_write_length(struct device *dev,
 		ret = 0;
 	}
 	if (ret)
-		goto out;
+		goto unlock;
 	if (buffer->length && buffer->length < buffer->watermark)
 		buffer->watermark = buffer->length;
-out:
+unlock:
 	mutex_unlock(&indio_dev->mlock);
 
 	return ret ? ret : len;
Signature · 1 line
2.10.0
#1075 lore raw

PATCH 5/7 iio: Rename a jump label in iio_scan_el_ts_store()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 24 Sep 2016 07:27:26 +0200

Adjust a jump label according to the current Linux coding style convention.

---
 drivers/iio/industrialio-buffer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/iio/industrialio-buffer.c +2 -2
index 376101f..4b8f313 100644
@@ -409,10 +409,10 @@ static ssize_t iio_scan_el_ts_store(struct device *dev,
 	mutex_lock(&indio_dev->mlock);
 	if (iio_buffer_is_active(indio_dev->buffer)) {
 		ret = -EBUSY;
-		goto error_ret;
+		goto unlock;
 	}
 	indio_dev->buffer->scan_timestamp = state;
-error_ret:
+unlock:
 	mutex_unlock(&indio_dev->mlock);
 
 	return ret ? ret : len;
Signature · 1 line
2.10.0
#1076 lore raw

PATCH 6/7 iio: Rename a jump label in iio_scan_el_store()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 24 Sep 2016 07:40:59 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/iio/industrialio-buffer.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)
drivers/iio/industrialio-buffer.c +5 -6
index 4b8f313..57e201a 100644
@@ -363,22 +363,21 @@ static ssize_t iio_scan_el_store(struct device *dev,
 	mutex_lock(&indio_dev->mlock);
 	if (iio_buffer_is_active(indio_dev->buffer)) {
 		ret = -EBUSY;
-		goto error_ret;
+		goto unlock;
 	}
 	ret = iio_scan_mask_query(indio_dev, buffer, this_attr->address);
 	if (ret < 0)
-		goto error_ret;
+		goto unlock;
 	if (!state && ret) {
 		ret = iio_scan_mask_clear(buffer, this_attr->address);
 		if (ret)
-			goto error_ret;
+			goto unlock;
 	} else if (state && !ret) {
 		ret = iio_scan_mask_set(indio_dev, buffer, this_attr->address);
 		if (ret)
-			goto error_ret;
+			goto unlock;
 	}
-
-error_ret:
+unlock:
 	mutex_unlock(&indio_dev->mlock);
 
 	return ret < 0 ? ret : len;
Signature · 1 line
2.10.0
#1077 lore raw

PATCH 7/7 iio: Adjust checks for null pointers in six functions

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 24 Sep 2016 08:00:07 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The script "checkpatch.pl" can point information out like the following.

Comparison to NULL could be written !…

Thus fix the affected source code places.

---
 drivers/iio/industrialio-buffer.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)
drivers/iio/industrialio-buffer.c +9 -9
index 57e201a..6893639 100644
@@ -310,7 +310,7 @@ static int iio_scan_mask_set(struct iio_dev *indio_dev,
 	trialmask = kmalloc_array(BITS_TO_LONGS(indio_dev->masklength),
 				  sizeof(*trialmask),
 				  GFP_KERNEL);
-	if (trialmask = NULL)
+	if (!trialmask)
 		return -ENOMEM;
 	if (!indio_dev->masklength) {
 		WARN(1, "Trying to set scanmask prior to registering buffer\n");
@@ -711,7 +711,7 @@ static int iio_verify_update(struct iio_dev *indio_dev,
 	/* What scan mask do we actually have? */
 	compound_mask = kcalloc(BITS_TO_LONGS(indio_dev->masklength),
 				sizeof(long), GFP_KERNEL);
-	if (compound_mask = NULL)
+	if (!compound_mask)
 		return -ENOMEM;
 
 	scan_timestamp = false;
@@ -736,7 +736,7 @@ static int iio_verify_update(struct iio_dev *indio_dev,
 				    compound_mask,
 				    strict_scanmask);
 		kfree(compound_mask);
-		if (scan_mask = NULL)
+		if (!scan_mask)
 			return -EINVAL;
 	} else {
 	    scan_mask = compound_mask;
@@ -940,7 +940,7 @@ int iio_update_buffers(struct iio_dev *indio_dev,
 		goto out_unlock;
 	}
 
-	if (indio_dev->info = NULL) {
+	if (!indio_dev->info) {
 		ret = -ENODEV;
 		goto out_unlock;
 	}
@@ -1130,11 +1130,11 @@ int iio_buffer_alloc_sysfs_and_mask(struct iio_dev *indio_dev)
 				indio_dev->scan_index_timestamp  					channels[i].scan_index;
 		}
-		if (indio_dev->masklength && buffer->scan_mask = NULL) {
+		if (indio_dev->masklength && !buffer->scan_mask) {
 			buffer->scan_mask = kcalloc(BITS_TO_LONGS(indio_dev->masklength),
 						    sizeof(*buffer->scan_mask),
 						    GFP_KERNEL);
-			if (buffer->scan_mask = NULL) {
+			if (!buffer->scan_mask) {
 				ret = -ENOMEM;
 				goto error_cleanup_dynamic;
 			}
@@ -1146,7 +1146,7 @@ int iio_buffer_alloc_sysfs_and_mask(struct iio_dev *indio_dev)
 	buffer->scan_el_group.attrs = kcalloc(attrcount + 1,
 					      sizeof(buffer->scan_el_group.attrs[0]),
 					      GFP_KERNEL);
-	if (buffer->scan_el_group.attrs = NULL) {
+	if (!buffer->scan_el_group.attrs) {
 		ret = -ENOMEM;
 		goto error_free_scan_mask;
 	}
@@ -1291,7 +1291,7 @@ static int iio_buffer_add_demux(struct iio_buffer *buffer,
 		(*p)->length += length;
 	} else {
 		*p = kmalloc(sizeof(**p), GFP_KERNEL);
-		if (*p = NULL)
+		if (!*p)
 			return -ENOMEM;
 		(*p)->from = in_loc;
 		(*p)->to = out_loc;
@@ -1356,7 +1356,7 @@ static int iio_buffer_update_demux(struct iio_dev *indio_dev,
 		in_loc += length;
 	}
 	buffer->demux_bounce = kzalloc(out_loc, GFP_KERNEL);
-	if (buffer->demux_bounce = NULL) {
+	if (!buffer->demux_bounce) {
 		ret = -ENOMEM;
 		goto error_clear_mux_table;
 	}
Signature · 6 lines
2.10.0

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
maintainer
#1078 lore raw

Re: [PATCH 7/7] iio: Adjust checks for null pointers in six functions

Quoted 6 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 24 Sep 2016 08:00:07 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Quoted 7 lines

The script "checkpatch.pl" can point information out like the following.

Comparison to NULL could be written !…

Thus fix the affected source code places.

This is a more worthwhile change in my mind to the jump label changes. Would you mind resending with it not based on top of those?

Thanks,

Jonathan

Quoted 77 lines
---
 drivers/iio/industrialio-buffer.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)
drivers/iio/industrialio-buffer.c +8 -8
index 57e201a..6893639 100644
@@ -310,7 +310,7 @@ static int iio_scan_mask_set(struct iio_dev *indio_dev,
 	trialmask = kmalloc_array(BITS_TO_LONGS(indio_dev->masklength),
 				  sizeof(*trialmask),
 				  GFP_KERNEL);
-	if (trialmask = NULL)
+	if (!trialmask)
 		return -ENOMEM;
 	if (!indio_dev->masklength) {
 		WARN(1, "Trying to set scanmask prior to registering buffer\n");
@@ -711,7 +711,7 @@ static int iio_verify_update(struct iio_dev *indio_dev,
 	/* What scan mask do we actually have? */
 	compound_mask = kcalloc(BITS_TO_LONGS(indio_dev->masklength),
 				sizeof(long), GFP_KERNEL);
-	if (compound_mask = NULL)
+	if (!compound_mask)
 		return -ENOMEM;
 
 	scan_timestamp = false;
@@ -736,7 +736,7 @@ static int iio_verify_update(struct iio_dev *indio_dev,
 				    compound_mask,
 				    strict_scanmask);
 		kfree(compound_mask);
-		if (scan_mask = NULL)
+		if (!scan_mask)
 			return -EINVAL;
 	} else {
 	    scan_mask = compound_mask;
@@ -940,7 +940,7 @@ int iio_update_buffers(struct iio_dev *indio_dev,
 		goto out_unlock;
 	}
 
-	if (indio_dev->info = NULL) {
+	if (!indio_dev->info) {
 		ret = -ENODEV;
 		goto out_unlock;
 	}
@@ -1130,11 +1130,11 @@ int iio_buffer_alloc_sysfs_and_mask(struct iio_dev *indio_dev)
 				indio_dev->scan_index_timestamp >  					channels[i].scan_index;
 		}
-		if (indio_dev->masklength && buffer->scan_mask = NULL) {
+		if (indio_dev->masklength && !buffer->scan_mask) {
 			buffer->scan_mask = kcalloc(BITS_TO_LONGS(indio_dev->masklength),
 						    sizeof(*buffer->scan_mask),
 						    GFP_KERNEL);
-			if (buffer->scan_mask = NULL) {
+			if (!buffer->scan_mask) {
 				ret = -ENOMEM;
 				goto error_cleanup_dynamic;
 			}
@@ -1146,7 +1146,7 @@ int iio_buffer_alloc_sysfs_and_mask(struct iio_dev *indio_dev)
 	buffer->scan_el_group.attrs = kcalloc(attrcount + 1,
 					      sizeof(buffer->scan_el_group.attrs[0]),
 					      GFP_KERNEL);
-	if (buffer->scan_el_group.attrs = NULL) {
+	if (!buffer->scan_el_group.attrs) {
 		ret = -ENOMEM;
 		goto error_free_scan_mask;
 	}
@@ -1291,7 +1291,7 @@ static int iio_buffer_add_demux(struct iio_buffer *buffer,
 		(*p)->length += length;
 	} else {
 		*p = kmalloc(sizeof(**p), GFP_KERNEL);
-		if (*p = NULL)
+		if (!*p)
 			return -ENOMEM;
 		(*p)->from = in_loc;
 		(*p)->to = out_loc;

drivers/iio/industrialio-buffer.c static int iio_buffer_update_demux(struct iio_dev *indio_dev, · line 1362

Quoted 8 lines
drivers/iio/industrialio-buffer.c +1 -1
@@ -1356,7 +1356,7 @@ static int iio_buffer_update_demux(struct iio_dev *indio_dev,
 		in_loc += length;
 	}
 	buffer->demux_bounce = kzalloc(out_loc, GFP_KERNEL);
-	if (buffer->demux_bounce = NULL) {
+	if (!buffer->demux_bounce) {
 		ret = -ENOMEM;
 		goto error_clear_mux_table;
 	}

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#1079 lore raw

Re: iio: Adjust checks for null pointers in six functions

Quoted 1 line

This is a more worthwhile change in my mind to the jump label changes.

Thanks for another bit of positive feedback for this refactoring.

Quoted 1 line

Would you mind resending with it not based on top of those?

Is a resend really needed?

Does the tool "Git" let you also apply this update step before the other suggestions?

Would you dare a reordering of items according to your change preferences?

Regards,
Markus

maintainer
#1080 lore raw

Re: iio: Adjust checks for null pointers in six functions

Quoted 8 lines · SF Markus Elfring
Quoted 1 line

This is a more worthwhile change in my mind to the jump label changes.

Thanks for another bit of positive feedback for this refactoring.

Quoted 1 line

Would you mind resending with it not based on top of those?

Is a resend really needed?

It's a question of time. Maintainers regularly push back stuff they could fix up themselves purely to save their time.

Also, I'm afraid I don't care enough to put the time in for this one. I care enough to review / apply the patch though.

Quoted 3 lines

Does the tool "Git" let you also apply this update step before the other suggestions?

It rarely copes with this sort of reordering as it doesn't have the semantic knowledge of what matters in the other patches.

Quoted 6 lines

Would you dare a reordering of items according to your change preferences?

Regards,
Markus

#1081 lore raw

Re: iio: Adjust checks for null pointers in six functions

Quoted 1 line

Also, I'm afraid I don't care enough to put the time in for this one.

It's a pity.

Quoted 4 lines
Quoted 2 lines

Does the tool "Git" let you also apply this update step before the other suggestions?

It rarely copes with this sort of reordering as it doesn't have the semantic knowledge of what matters in the other patches.

I assume that the involved software developers got a specific impression about the discussed patch series for this software module so that a few relevant dependencies became clearer eventually.

I proposed some update steps where I chose a specific patch granularity once more. So I imagine that a bit of variation in the patch order could be supported already.

Will it be possible to apply also this one a bit later just because the patch hunk contexts might be still valid in the (near) future?

Regards,
Markus

#1082 lore raw

Re: iio: Adjust checks for null pointers in six functions

Quoted 10 lines · SF Markus Elfring

I assume that the involved software developers got a specific impression about the discussed patch series for this software module so that a few relevant dependencies became clearer eventually.

I proposed some update steps where I chose a specific patch granularity once more. So I imagine that a bit of variation in the patch order could be supported already.

Will it be possible to apply also this one a bit later just because the patch hunk contexts might be still valid in the (near) future?

I wonder if you realize that your postings _reek_ with the Strong Programme intellectual offal... Are you, by any chance, some kind of sociology grad? You can't study development purely on the process level, ignoring the actual usefulness of contributions and the fact that there are objective criteria of their worth.

#1083 lore raw

Re: iio: Adjust checks for null pointers in six functions

Quoted 1 line

Are you, by any chance, some kind of sociology grad?

Not yet. ;-) - It looks also unlikely at the moment that my life will evolve
in such direction.

Quoted 1 line

You can't study development purely on the process level,

I find that I am not studying this topic. Am I practically contributing small improvements to free software (including Linux) for years?

Quoted 1 line

ignoring the actual usefulness of contributions

I guess their usefulness is varying over time.

Quoted 1 line

and the fact that there are objective criteria of their worth.

Are there any source code quality goals left over which would be nice to achieve also for this software module?

Regards,
Markus

#1084 lore raw

cover Input-evdev: Fine-tuning for three function implementations

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 24 Sep 2016 13:03:13 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
Use kmalloc_array()
Rename a jump label in two functions

 drivers/input/evdev.c | 20 +++++++-------------
 1 file changed, 7 insertions(+), 13 deletions(-)
Signature · 1 line
2.10.0
#1085 lore raw

PATCH 1/2 Input-evdev: Use kmalloc_array() in evdev_handle_get_val()

From: Markus Elfring <[email protected]>
Date: Sat, 24 Sep 2016 12:42:45 +0200

* A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

* Replace the specification of a data type by a pointer dereference to make the corresponding size determination a bit safer according to the Linux coding style convention.

* Delete the local variable "len" which became unnecessary with this refactoring.

---
 drivers/input/evdev.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)
drivers/input/evdev.c +2 -6
index e9ae3d5..83fcfd6 100644
@@ -919,18 +919,14 @@ static int evdev_handle_get_val(struct evdev_client *client,
 {
 	int ret;
 	unsigned long *mem;
-	size_t len;
 
-	len = BITS_TO_LONGS(maxbit) * sizeof(unsigned long);
-	mem = kmalloc(len, GFP_KERNEL);
+	mem = kmalloc_array(BITS_TO_LONGS(maxbit), sizeof(*mem), GFP_KERNEL);
 	if (!mem)
 		return -ENOMEM;
 
 	spin_lock_irq(&dev->event_lock);
 	spin_lock(&client->buffer_lock);
-
-	memcpy(mem, bits, len);
-
+	memcpy(mem, bits, sizeof(*mem) * BITS_TO_LONGS(maxbit));
 	spin_unlock(&dev->event_lock);
 
 	__evdev_flush_queue(client, type);
Signature · 1 line
2.10.0
maintainer
#1086 lore raw

Re: [PATCH 1/2] Input-evdev: Use kmalloc_array() in evdev_handle_get_val()

Quoted 7 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 24 Sep 2016 12:42:45 +0200

* A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array".

Quoted 8 lines

This issue was detected by using the Coccinelle software.

* Replace the specification of a data type by a pointer dereference to make the corresponding size determination a bit safer according to the Linux coding style convention.

* Delete the local variable "len" which became unnecessary with this refactoring.

So we have to multiply twice now, once in kmalloc_array, the second time in memcpy(). No, thank you.

Also, please note that we do not really treat the allocated "mem" as an array, but rather area of memory that holds all bits that we need to transfer, and so I consider using kmalloc_array() actually wrong here.

Please do not blindly follow checkpatch and coccinelle suggestions. They are just that: suggestions and not hared rules.

Thanks.

Signature · 1 line
Dmitry
#1087 lore raw

Re: Input-evdev: Use kmalloc_array() in evdev_handle_get_val()

Quoted 2 lines

So we have to multiply twice now, once in kmalloc_array, the second time in memcpy().

It looks so in the source code after the suggested refactoring.

Quoted 1 line

No, thank you.

Would you like to check any further if a specific compiler implementation will still optimise common subexpressions as you desired it?

Quoted 3 lines

Also, please note that we do not really treat the allocated "mem" as an array, but rather area of memory that holds all bits that we need to transfer, and so I consider using kmalloc_array() actually wrong here.

Thanks for your explanation.

Quoted 2 lines

Please do not blindly follow checkpatch and coccinelle suggestions. They are just that: suggestions and not hared rules.

I am curious on how to clarify corresponding deviations further.

Would you like to suggest any other details so that the evolving scripts can become better and safer for static source code analysis?

Do you know any special properties which should be additionally checked at call sites which are similar to the discussed place?

Regards,
Markus

maintainer
#1088 lore raw

Re: Input-evdev: Use kmalloc_array() in evdev_handle_get_val()

Quoted 22 lines · SF Markus Elfring
Quoted 2 lines

So we have to multiply twice now, once in kmalloc_array, the second time in memcpy().

It looks so in the source code after the suggested refactoring.

Quoted 1 line

No, thank you.

Would you like to check any further if a specific compiler implementation will still optimise common subexpressions as you desired it?

Quoted 3 lines

Also, please note that we do not really treat the allocated "mem" as an array, but rather area of memory that holds all bits that we need to transfer, and so I consider using kmalloc_array() actually wrong here.

Thanks for your explanation.

Quoted 2 lines

Please do not blindly follow checkpatch and coccinelle suggestions. They are just that: suggestions and not hared rules.

Quoted 8 lines

I am curious on how to clarify corresponding deviations further.

Would you like to suggest any other details so that the evolving scripts can become better and safer for static source code analysis?

Do you know any special properties which should be additionally checked at call sites which are similar to the discussed place?

If you are asking for some formal rules then no.

Again, what is the purpose of the changes? Are you working on the code and the fact that the driver is older-style hinders your progress? Or there are runtime improvements from your changes? Correctness issues?

I do not very much appreciate changes just to satisfy checkpatch rule du jour.

Thanks.

Signature · 1 line
Dmitry
#1089 lore raw

Re: Input-evdev: Use kmalloc_array() in evdev_handle_get_val()

Quoted 1 line

Again, what is the purpose of the changes?

I came also along a few source code places where their maintainers requested the usage of a function like "kmalloc_array".

How do you think about to clarify the consistent use of programming interfaces for Linux a bit more?

Quoted 1 line

Are you working on the code

I am trying to improve various free software (including Linux).

Quoted 1 line

and the fact that the driver is older-style hinders your progress?

Not for me directly.

Quoted 1 line

Or there are runtime improvements from your changes?

It depends on some factors.

Can an array memory allocator organise the desired data in a safer and more efficient way than a "default approach"?

Quoted 1 line

Correctness issues?

This can be.

Do you care for source code annotations?

Quoted 2 lines

I do not very much appreciate changes just to satisfy checkpatch rule du jour.

Do these rules contain knowledge which you give a significant value?

Regards,
Markus

#1090 lore raw

PATCH 2/2 Input-evdev: Rename a jump label in two functions

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 24 Sep 2016 12:50:31 +0200

Adjust a jump label according to the current Linux coding style convention. Thus replace the identifier "out" by "unlock".

---
 drivers/input/evdev.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)
drivers/input/evdev.c +5 -7
index 83fcfd6..548874d 100644
@@ -545,22 +545,21 @@ static ssize_t evdev_write(struct file *file, const char __user *buffer,
 
 	if (!evdev->exist || client->revoked) {
 		retval = -ENODEV;
-		goto out;
+		goto unlock;
 	}
 
 	while (retval + input_event_size() <= count) {
 
 		if (input_event_from_user(buffer + retval, &event)) {
 			retval = -EFAULT;
-			goto out;
+			goto unlock;
 		}
 		retval += input_event_size();
 
 		input_inject_event(&evdev->handle,
 				   event.type, event.code, event.value);
 	}
-
- out:
+unlock:
 	mutex_unlock(&evdev->mutex);
 	return retval;
 }
@@ -1292,12 +1291,11 @@ static long evdev_ioctl_handler(struct file *file, unsigned int cmd,
 
 	if (!evdev->exist || client->revoked) {
 		retval = -ENODEV;
-		goto out;
+		goto unlock;
 	}
 
 	retval = evdev_do_ioctl(file, cmd, p, compat_mode);
-
- out:
+unlock:
 	mutex_unlock(&evdev->mutex);
 	return retval;
 }
Signature · 1 line
2.10.0
maintainer
#1091 lore raw

Re: [PATCH 2/2] Input-evdev: Rename a jump label in two functions

Quoted 5 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 24 Sep 2016 12:50:31 +0200

Adjust a jump label according to the current Linux coding style convention. Thus replace the identifier "out" by "unlock".

No, just no.

Quoted 54 lines
---
 drivers/input/evdev.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)
drivers/input/evdev.c +5 -8
index 83fcfd6..548874d 100644
@@ -545,22 +545,21 @@ static ssize_t evdev_write(struct file *file, const char __user *buffer,
 
        if (!evdev->exist || client->revoked) {
                retval = -ENODEV;
-               goto out;
+               goto unlock;
        }
 
        while (retval + input_event_size() <= count) {
 
                if (input_event_from_user(buffer + retval, &event)) {
                        retval = -EFAULT;
-                       goto out;
+                       goto unlock;
                }
                retval += input_event_size();
 
                input_inject_event(&evdev->handle,
                                   event.type, event.code, event.value);
        }
-
- out:
+unlock:
        mutex_unlock(&evdev->mutex);
        return retval;
 }
@@ -1292,12 +1291,11 @@ static long evdev_ioctl_handler(struct file *file, unsigned int cmd,
 
        if (!evdev->exist || client->revoked) {
                retval = -ENODEV;
-               goto out;
+               goto unlock;
        }
 
        retval = evdev_do_ioctl(file, cmd, p, compat_mode);
-
- out:
+unlock:
        mutex_unlock(&evdev->mutex);
        return retval;
 }
--

2.10.0

Signature · 1 line
Dmitry
#1092 lore raw

cover ISDN-Gigaset: Fine-tuning for three function implementations

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Mon, 26 Sep 2016 17:27:17 +0200

Some update suggestions were taken into account
from static source code analysis.

Markus Elfring (5):
Use kmalloc_array() in two functions
Improve another size determination in gigaset_initcs() Delete an error message for a failed memory allocation Release memory in gigaset_initcs() after an allocation failure Enclose two expressions for the sizeof operator by parentheses

 drivers/isdn/gigaset/common.c | 31 ++++++++++++++++---------------
 1 file changed, 16 insertions(+), 15 deletions(-)
Signature · 1 line
2.10.0
#1093 lore raw

PATCH 1/5 ISDN-Gigaset: Use kmalloc_array() in two functions

From: Markus Elfring <[email protected]>
Date: Sun, 25 Sep 2016 22:22:04 +0200

* Multiplications for the size determination of memory allocations indicated that array data structures should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

* Replace the specification of a data structure by a pointer dereference to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/isdn/gigaset/common.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/isdn/gigaset/common.c +2 -4
index 7c78144..cecbb6a 100644
@@ -709,8 +709,7 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
 
 	cs->mode = M_UNKNOWN;
 	cs->mstate = MS_UNINITIALIZED;
-
-	cs->bcs = kmalloc(channels * sizeof(struct bc_state), GFP_KERNEL);
+	cs->bcs = kmalloc_array(channels, sizeof(*cs->bcs), GFP_KERNEL);
 	cs->inbuf = kmalloc(sizeof(struct inbuf_t), GFP_KERNEL);
 	if (!cs->bcs || !cs->inbuf) {
 		pr_err("out of memory\n");
@@ -1089,8 +1088,7 @@ struct gigaset_driver *gigaset_initdriver(unsigned minor, unsigned minors,
 	drv->ops = ops;
 	drv->owner = owner;
 	INIT_LIST_HEAD(&drv->list);
-
-	drv->cs = kmalloc(minors * sizeof *drv->cs, GFP_KERNEL);
+	drv->cs = kmalloc_array(minors, sizeof(*drv->cs), GFP_KERNEL);
 	if (!drv->cs)
 		goto error;
 
Signature · 1 line
2.10.0
#1094 lore raw

Re: [PATCH 1/5] ISDN-Gigaset: Use kmalloc_array() in two functions

Quoted 3 lines · SF Markus Elfring

* Multiplications for the size determination of memory allocations indicated that array data structures should be processed. Thus use the corresponding function "kmalloc_array".

Was the current code incorrect? What makes kmalloc_array() better? None of this is obvious to me.

I'm not going to change code just because some checker suggests to do so.

Quoted 1 line

  This issue was detected by using the Coccinelle software.

So? And which coccinelle script was actually used? I couldn't spot a coccinelle script doing that in the current tree.

Quoted 3 lines

* Replace the specification of a data structure by a pointer dereference to make the corresponding size determination a bit safer according to the Linux coding style convention.

I'm not happy with you mixing this with the above, less trivial, change.

Quoted 9 lines
drivers/isdn/gigaset/common.c +0 -0
@@ -709,8 +709,7 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,


  cs->mode = M_UNKNOWN;
  cs->mstate = MS_UNINITIALIZED;
-

Unrelated whitespace change.

drivers/isdn/gigaset/common.c struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels, · line 712

Quoted 2 lines
drivers/isdn/gigaset/common.c +1 -1
-	cs->bcs = kmalloc(channels * sizeof(struct bc_state), GFP_KERNEL);
+	cs->bcs = kmalloc_array(channels, sizeof(*cs->bcs), GFP_KERNEL);

For the record: "channels" is basically hardcoded in the three gigaset hardware drivers.

drivers/isdn/gigaset/common.c struct gigaset_driver · line 1093

Quoted 9 lines

  cs->inbuf = kmalloc(sizeof(struct inbuf_t), GFP_KERNEL); if (!cs->bcs || !cs->inbuf) {
  pr_err("out of memory\n");

drivers/isdn/gigaset/common.c +0 -1
@@ -1089,8 +1088,7 @@ struct gigaset_driver
 *gigaset_initdriver(unsigned minor, unsigned minors,
  	drv->ops = ops;
  	drv->owner = owner;
  	INIT_LIST_HEAD(&drv->list);
-

Again unrelated whitespace change.

drivers/isdn/gigaset/common.c struct gigaset_driver *gigaset_initdriver(unsigned minor, unsigned minors, · line 1091

Quoted 2 lines
drivers/isdn/gigaset/common.c +1 -1
-	drv->cs = kmalloc(minors * sizeof *drv->cs, GFP_KERNEL);
+	drv->cs = kmalloc_array(minors, sizeof(*drv->cs), GFP_KERNEL);

For "minors" the same holds as for "channels", above.

And you snuck in a parentheses change. That should have probably been merged with 5/5.

drivers/isdn/gigaset/common.c struct gigaset_driver *gigaset_initdriver(unsigned minor, unsigned minors, · line 1093

Quoted 2 lines
drivers/isdn/gigaset/common.c +0 -0
  	if (!drv->cs)
  		goto error;

Paul Bolle

#1095 lore raw

Re: [PATCH 1/5] ISDN-Gigaset: Use kmalloc_array() in two functions

Quoted 5 lines
Quoted 3 lines

* Multiplications for the size determination of memory allocations indicated that array data structures should be processed. Thus use the corresponding function "kmalloc_array".

Was the current code incorrect?

I suggest to use a safer interface for array allocations.

Quoted 1 line

What makes kmalloc_array() better?

1. How do you think about the safety checks that this function provides?

2. Will you be also affected by further software evolution here? 2016-07-26
mm: faster kmalloc_array(), kcalloc()
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id‘c6a05f72a996bee5133e76374ab3ad7d3b9b72

Quoted 1 line

I'm not going to change code just because some checker suggests to do so.

The script "checkpatch.pl" can point information out like the following.

WARNING: Prefer kmalloc_array over kmalloc with multiply

Quoted 3 lines
Quoted 1 line

This issue was detected by using the Coccinelle software.

So? And which coccinelle script was actually used?

How do you think about to look into related information sources?
https://github.com/coccinelle/coccinelle/issues/81

Would you like to experiment any further with an excerpt?

@replacement1@
expression count, target;
type T;
@@
target - kmalloc(sizeof(T) * (count)
+ kmalloc_array(count, sizeof(T)

                        , ...);

@replacement2@
expression count, pointer, target;
@@
target - kmalloc(sizeof(*pointer) * (count)
+ kmalloc_array(count, sizeof(*pointer)

                        , ...);
Quoted 1 line

I couldn't spot a coccinelle script doing that in the current tree.

This is true for such a software update opportunity.

Quoted 5 lines
Quoted 3 lines

* Replace the specification of a data structure by a pointer dereference to make the corresponding size determination a bit safer according to the Linux coding style convention.

I'm not happy with you mixing this with the above, less trivial, change.

I find that it is a useful combination. - A parameter is adjusted together with a special function name.

Quoted 7 lines

drivers/isdn/gigaset/common.c struct gigaset_driver *gigaset_initdriver(unsigned minor, unsigned minors, · line 1091

Quoted 2 lines
drivers/isdn/gigaset/common.c +1 -1
-	drv->cs = kmalloc(minors * sizeof *drv->cs, GFP_KERNEL);
+	drv->cs = kmalloc_array(minors, sizeof(*drv->cs), GFP_KERNEL);

For "minors" the same holds as for "channels", above.

And you snuck in a parentheses change. That should have probably been merged with 5/5.

Would you prefer to add them in another update step?

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#1096 lore raw

Re: [PATCH 1/5] ISDN-Gigaset: Use kmalloc_array() in two functions

Quoted 7 lines · SF Markus Elfring
Quoted 2 lines

I'm not going to change code just because some checker suggests to do so.

The script "checkpatch.pl" can point information out like the following.

WARNING: Prefer kmalloc_array over kmalloc with multiply

Am I being trolled?

Paul Bolle

#1097 lore raw

PATCH 2/5 ISDN-Gigaset: Improve another size determination in gigaset_initcs()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sun, 25 Sep 2016 22:32:14 +0200

Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/isdn/gigaset/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/isdn/gigaset/common.c +1 -1
index cecbb6a..f505b42 100644
@@ -710,7 +710,7 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
 	cs->mode = M_UNKNOWN;
 	cs->mstate = MS_UNINITIALIZED;
 	cs->bcs = kmalloc_array(channels, sizeof(*cs->bcs), GFP_KERNEL);
-	cs->inbuf = kmalloc(sizeof(struct inbuf_t), GFP_KERNEL);
+	cs->inbuf = kmalloc(sizeof(*cs->inbuf), GFP_KERNEL);
 	if (!cs->bcs || !cs->inbuf) {
 		pr_err("out of memory\n");
 		goto error;
Signature · 1 line
2.10.0
#1098 lore raw

PATCH 3/5 ISDN-Gigaset: Delete an error message for a failed memory allocation

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Mon, 26 Sep 2016 15:35:47 +0200

Omit an extra message for a memory allocation failure in this function.

---
 drivers/isdn/gigaset/common.c | 1 -
 1 file changed, 1 deletion(-)
drivers/isdn/gigaset/common.c +0 -1
index f505b42..c05a2a4 100644
@@ -712,7 +712,6 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
 	cs->bcs = kmalloc_array(channels, sizeof(*cs->bcs), GFP_KERNEL);
 	cs->inbuf = kmalloc(sizeof(*cs->inbuf), GFP_KERNEL);
 	if (!cs->bcs || !cs->inbuf) {
-		pr_err("out of memory\n");
 		goto error;
 	}
 	++cs->cs_init;
Signature · 1 line
2.10.0
#1099 lore raw

Re: [PATCH 3/5] ISDN-Gigaset: Delete an error message for a failed memory allocation

Quoted 9 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Mon, 26 Sep 2016 15:35:47 +0200

Omit an extra message for a memory allocation failure in this function.

Link:
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf

The patch is fine but the link in the commit message is irrelevant. Please remove it.
(Yes, I read through the whole presentation to verify that. It was fun, even.)

Signature · 2 lines
Tilman Schmidt
[email protected]
#1100 lore raw

Re: [PATCH 3/5] ISDN-Gigaset: Delete an error message for a failed memory allocation

Quoted 8 lines · Tilman Schmidt
Quoted 7 lines · SF Markus Elfring

Omit an extra message for a memory allocation failure in this function.

Link:
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-R
efactor_Strings-WSang_0.pdf

Quoted 6 lines
Quoted 1 line

The patch is fine but the link in the commit message is irrelevant. Please remove it.
(Yes, I read through the whole presentation to verify that. It was fun, even.)

Agree.

Except this patch assumes the superfluous braces would be removed in 4/5. But it turns out that other patch must be dropped. It would have been better to remove the braces in this patch.

Paul Bolle

#1101 lore raw

PATCH 4/5 ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Mon, 26 Sep 2016 16:30:50 +0200

Memory was not released (as it would be expected) when one call of further resource reservations failed.

* Split a condition check for memory allocation failures so that each pointer from these function calls will be checked immediately.

See also background information:
Topic "CWE-754: Improper check for unusual or exceptional conditions"

* Adjust jump targets according to the Linux coding style convention.

---
 drivers/isdn/gigaset/common.c | 20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)
drivers/isdn/gigaset/common.c +12 -8
index c05a2a4..2e9382f 100644
@@ -710,10 +710,13 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
 	cs->mode = M_UNKNOWN;
 	cs->mstate = MS_UNINITIALIZED;
 	cs->bcs = kmalloc_array(channels, sizeof(*cs->bcs), GFP_KERNEL);
+	if (!cs->bcs)
+		goto report_failure;
+
 	cs->inbuf = kmalloc(sizeof(*cs->inbuf), GFP_KERNEL);
-	if (!cs->bcs || !cs->inbuf) {
-		goto error;
-	}
+	if (!cs->inbuf)
+		goto free_bcs;
+
 	++cs->cs_init;
 
 	gig_dbg(DEBUG_INIT, "setting up at_state");
@@ -737,14 +740,14 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
 	gig_dbg(DEBUG_INIT, "setting up iif");
 	if (gigaset_isdn_regdev(cs, modulename) < 0) {
 		pr_err("error registering ISDN device\n");
-		goto error;
+		goto free_bcs;
 	}
 
 	make_valid(cs, VALID_ID);
 	++cs->cs_init;
 	gig_dbg(DEBUG_INIT, "setting up hw");
 	if (cs->ops->initcshw(cs) < 0)
-		goto error;
+		goto free_bcs;
 
 	++cs->cs_init;
 
@@ -759,7 +762,7 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
 		gig_dbg(DEBUG_INIT, "setting up bcs[%d]", i);
 		if (gigaset_initbcs(cs->bcs + i, cs, i) < 0) {
 			pr_err("could not allocate channel %d data\n", i);
-			goto error;
+			goto free_bcs;
 		}
 	}
 
@@ -772,8 +775,9 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
 
 	gig_dbg(DEBUG_INIT, "cs initialized");
 	return cs;
-
-error:
+free_bcs:
+	kfree(cs->bcs);
+report_failure:
 	gig_dbg(DEBUG_INIT, "failed");
 	gigaset_freecs(cs);
 	return NULL;
Signature · 1 line
2.10.0
#1102 lore raw

Re: [PATCH 4/5] ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

Markus,

Quoted 2 lines · SF Markus Elfring

Memory was not released (as it would be expected) when one call of further resource reservations failed.

This was the only thing in this series that triggered more than a, very uninspired, "meh" on first read.

Quoted 6 lines

* Split a condition check for memory allocation failures so that each pointer from these function calls will be checked immediately.

  See also background information:
  Topic "CWE-754: Improper check for unusual or exceptional conditions"

A quick scan of that link suggests we can do without the above "background information" in the commit explanation.

Quoted 1 line

* Adjust jump targets according to the Linux coding style convention.

Another "meh".

Quoted 62 lines

---
 drivers/isdn/gigaset/common.c | 20 ++++++++++++--------

 1 file changed, 12 insertions(+), 8 deletions(-)
drivers/isdn/gigaset/common.c +6 -3
index c05a2a4..2e9382f 100644
@@ -710,10 +710,13 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
  	cs->mode = M_UNKNOWN;
  	cs->mstate = MS_UNINITIALIZED;
 	cs->bcs = kmalloc_array(channels, sizeof(*cs->bcs), GFP_KERNEL);
+	if (!cs->bcs)
+		goto report_failure;
+
  	cs->inbuf = kmalloc(sizeof(*cs->inbuf), GFP_KERNEL);
-	if (!cs->bcs || !cs->inbuf) {
-		goto error;
-	}
+	if (!cs->inbuf)
+		goto free_bcs;
+
  	++cs->cs_init;


  gig_dbg(DEBUG_INIT, "setting up at_state");

drivers/isdn/gigaset/common.c +1 -1
@@ -737,14 +740,14 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
  	gig_dbg(DEBUG_INIT, "setting up iif");
  	if (gigaset_isdn_regdev(cs, modulename) < 0) {
  		pr_err("error registering ISDN device\n");
-		goto error;
+		goto free_bcs;
  	}


  make_valid(cs, VALID_ID);
  ++cs->cs_init;
  gig_dbg(DEBUG_INIT, "setting up hw");
  if (cs->ops->initcshw(cs) < 0)

drivers/isdn/gigaset/common.c +1 -1
-		goto error;
+		goto free_bcs;


  ++cs->cs_init;

drivers/isdn/gigaset/common.c +1 -1
@@ -759,7 +762,7 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
  		gig_dbg(DEBUG_INIT, "setting up bcs[%d]", i);
  		if (gigaset_initbcs(cs->bcs + i, cs, i) < 0) {
 			pr_err("could not allocate channel %d data\n", i);
-			goto error;
+			goto free_bcs;
  		}
  	}

drivers/isdn/gigaset/common.c +0 -0
@@ -772,8 +775,9 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,


  gig_dbg(DEBUG_INIT, "cs initialized");
  return cs;

drivers/isdn/gigaset/common.c +3 -2
-
-error:
+free_bcs:
+	kfree(cs->bcs);
+report_failure:
Quoted 2 lines

  gig_dbg(DEBUG_INIT, "failed");
  gigaset_freecs(cs);

gigaset_freecs() is not a function I look at for the fun of it. But still, in it we find:

	case 0: /* error in basic setup */
		[...]
		kfree(cs->inbuf);
		kfree(cs->bcs);

As far as I can tell we will call those two kfree()'s if we jump to "error". So, contrary to your analysis, I don't think we leak cs->bcs.

Quoted 1 line

  return NULL;

Paul Bolle

#1103 lore raw

Re: ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

Quoted 5 lines
Quoted 2 lines

Memory was not released (as it would be expected) when one call of further resource reservations failed.

This was the only thing in this series that triggered more than a, very uninspired, "meh" on first read.

Will it matter here if the function "kfree" will be called for the data structure members "bcs" and "inbuf" after a later function call failed within the implementation of "gigaset_initcs"?

Regards,
Markus

#1104 lore raw

Re: ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

Quoted 3 lines · SF Markus Elfring

Will it matter here if the function "kfree" will be called for the data structure members "bcs" and "inbuf" after a later function call failed within the implementation of "gigaset_initcs"?

My translation of this question is: could you please hold my hand while I read the code of a driver I do not use - a driver for hardware that I don't even have, and therefor cannot really test - after I submitted a patch that appears to be broken?

My answer to that question is: no, sorry, I won't do that.

Paul Bolle

#1105 lore raw

Re: ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

Quoted 8 lines
Quoted 3 lines

Will it matter here if the function "kfree" will be called for the data structure members "bcs" and "inbuf" after a later function call failed within the implementation of "gigaset_initcs"?

My translation of this question is: could you please hold my hand while I read the code of a driver I do not use - a driver for hardware that I don't even have, and therefor cannot really test - after I submitted a patch that appears to be broken?

I got the impression that the exception handling was incomplete in the implementation of the function "gigaset_initcs".
Does anybody (besides me) care for improving the software situation there?

Quoted 1 line

My answer to that question is: no, sorry, I won't do that.

I find that the process has just started once more to clarify in which directions this software module could evolve.

Do we discuss a potential memory leak under special conditions here?

Regards,
Markus

#1107 lore raw

Re: [Gigaset307x-common] ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

In reply to SF Markus Elfring

Hi,

as longtime maintainer of the code in question I feel compelled to chime in at this point.

Quoted 11 lines · SF Markus Elfring
Quoted 8 lines
Quoted 3 lines

Will it matter here if the function "kfree" will be called for the data structure members "bcs" and "inbuf" after a later function call failed within the implementation of "gigaset_initcs"?

My translation of this question is: could you please hold my hand while I read the code of a driver I do not use - a driver for hardware that I don't even have, and therefor cannot really test - after I submitted a patch that appears to be broken?

I got the impression that the exception handling was incomplete in the implementation of the function "gigaset_initcs".

That impression is wrong. Careful reading of the code will confirm that.

Quoted 2 lines

Does anybody (besides me) care for improving the software situation there?

There's no urgent need for improvement. The code is stable and there's no demonstrated bug to be fixed.
You could improve the coding style, but that is of secondary importance, and if you want to do that, as a minimum you have to make sure that you don't introduce new bugs.

Thanks,
Tilman

Signature · 2 lines
Tilman Schmidt
[email protected]
#1108 lore raw

Re: [Gigaset307x-common] ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

Quoted 4 lines
Quoted 2 lines

I got the impression that the exception handling was incomplete in the implementation of the function "gigaset_initcs".

That impression is wrong. Careful reading of the code will confirm that.

* Is it still correct nowadays that the function "gigaset_initcs" did not call the function "kfree" after a later function call failed?

* Do you expect that allocated memory will be automatically reclaimed after it would return a null pointer?

Regards,
Markus

#1109 lore raw

Re: [Gigaset307x-common] ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

Quoted 7 lines · SF Markus Elfring
Quoted 4 lines
Quoted 2 lines

I got the impression that the exception handling was incomplete in the implementation of the function "gigaset_initcs".

That impression is wrong. Careful reading of the code will confirm that.

* Is it still correct nowadays that the function "gigaset_initcs" did not call the function "kfree" after a later function call failed?

Wrong premise. That statement was never correct.

Quoted 2 lines

* Do you expect that allocated memory will be automatically reclaimed after it would return a null pointer?

No. Should I? Do you?

Regards,
Tilman

Signature · 2 lines
Tilman Schmidt
[email protected]
#1110 lore raw

Re: [Gigaset307x-common] ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

In reply to SF Markus Elfring

Am 27.09.2016 um 13:32 schrieb SF Markus Elfring:

Quoted 8 lines
Quoted 4 lines
Quoted 2 lines

I got the impression that the exception handling was incomplete in the implementation of the function "gigaset_initcs".

That impression is wrong. Careful reading of the code will confirm that.

* Is it still correct nowadays that the function "gigaset_initcs" did not call the function "kfree" after a later function call failed?

Yes, if it is handled in another place, Paul already did show you the place.

Quoted 3 lines

* Do you expect that allocated memory will be automatically reclaimed after it would return a null pointer?

Of course not

Best regards
Karsten

#1111 lore raw

Re: [Gigaset307x-common] ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

Quoted 4 lines
Quoted 2 lines

* Is it still correct nowadays that the function "gigaset_initcs" did not call the function "kfree" after a later function call failed?

Yes, if it is handled in another place, Paul already did show you the place.

To which source code place do you refer here?

Quoted 4 lines
Quoted 3 lines

* Do you expect that allocated memory will be automatically reclaimed after it would return a null pointer?

Of course not

Thanks for this acknowledgement.

Regards,
Markus

#1112 lore raw

Re: [Gigaset307x-common] ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

Quoted 6 lines · SF Markus Elfring
Quoted 4 lines
Quoted 2 lines

* Is it still correct nowadays that the function "gigaset_initcs" did not call the function "kfree" after a later function call failed?

Yes, if it is handled in another place, Paul already did show you the place.

To which source code place do you refer here?

Obviously the one Paul pointed out to you in detail in his mail dated Mon, 26 Sep 2016 23:13:54 +0200.

HTH,
Tilman

Signature · 2 lines
Tilman Schmidt
[email protected]
#1113 lore raw

Re: [PATCH 4/5] ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

In reply to Paul Bolle

Ah well... Someone else discovered the double free bug first and gave it away. Reassuring, I guess.

regards,
dan carpenter

#1114 lore raw

Re: [PATCH 4/5] ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

In reply to Paul Bolle
Quoted 15 lines

drivers/isdn/gigaset/common.c struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels, · line 782

Quoted 11 lines
drivers/isdn/gigaset/common.c +3 -2
@@ -772,8 +775,9 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
 
 	gig_dbg(DEBUG_INIT, "cs initialized");
 	return cs;
-
-error:
+free_bcs:
+	kfree(cs->bcs);
+report_failure:
 	gig_dbg(DEBUG_INIT, "failed");
 	gigaset_freecs(cs);

gigaset_freecs() is not a function I look at for the fun of it. But still, in it we find:

Quoted 7 lines
	case 0: /* error in basic setup */
		[...]
		kfree(cs->inbuf);
		kfree(cs->bcs);

As far as I can tell we will call those two kfree()'s if we jump to "error". So, contrary to your analysis, I don't think we leak cs->bcs.

You are right.

Thanks that you pointed this source code place out again.

I imagined that the exception handling implementation could be more direct somehow for a while. But this function takes extra care for data synchronisation by a mutex.

Now I recognise also that this proposed update step "4" was inappropriate. I'm sorry for the confusion I introduced here.

Regards,
Markus

#1115 lore raw

Re: [PATCH 4/5] ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

In reply to SF Markus Elfring

This patch creates new bugs.

I have a policy of not telling Markus where the bug is, because otherwise he'll just resend the patch and I have told him many times to stop sending these cleanup patches that just introduce bugs and waste maintainer time.

regards,
dan carpenter

#1116 lore raw

Re: ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

Quoted 1 line

This patch creates new bugs.

Thanks for your information.

Quoted 1 line

I have a policy of not telling Markus where the bug is,

I find this kind of response strange.

Quoted 1 line

because otherwise he'll just resend the patch

This can also happen when the other contributors request it.

Quoted 1 line

and I have told him many times to stop sending these cleanup patches

Software "cleanups" seem to stress the review process to some degree.

Quoted 1 line

that just introduce bugs and waste maintainer time.

I guess that the situation is mixed depending on the subsystem or concrete software module, isn't it?

Regards,
Markus

#1117 lore raw

PATCH 5/5 ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Mon, 26 Sep 2016 17:03:56 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The script "checkpatch.pl" can point information out like the following.

WARNING: sizeof … should be sizeof(…)

Thus fix the affected source code places.

---
 drivers/isdn/gigaset/common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/isdn/gigaset/common.c +2 -2
index 2e9382f..d901ed7 100644
@@ -53,7 +53,7 @@ void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg,
 {
 	unsigned char outbuf[80];
 	unsigned char c;
-	size_t space = sizeof outbuf - 1;
+	size_t space = sizeof(outbuf - 1);
 	unsigned char *out = outbuf;
 	size_t numin = len;
 
@@ -1079,7 +1079,7 @@ struct gigaset_driver *gigaset_initdriver(unsigned minor, unsigned minors,
 	unsigned long flags;
 	unsigned i;
 
-	drv = kmalloc(sizeof *drv, GFP_KERNEL);
+	drv = kmalloc(sizeof(*drv), GFP_KERNEL);
 	if (!drv)
 		return NULL;
 
Signature · 6 lines
2.10.0

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#1118 lore raw

RE: [PATCH 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

From: SF Markus Elfring

Quoted 1 line

Sent: 26 September 2016 16:45

...

Quoted 3 lines

The script "checkpatch.pl" can point information out like the following.

WARNING: sizeof … should be sizeof(…)

...

Quoted 9 lines
---
 drivers/isdn/gigaset/common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/isdn/gigaset/common.c +0 -0
index 2e9382f..d901ed7 100644

drivers/isdn/gigaset/common.c void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg, · line 56

Quoted 5 lines
drivers/isdn/gigaset/common.c +1 -1
@@ -53,7 +53,7 @@ void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg,
 {
 	unsigned char outbuf[80];
 	unsigned char c;
-	size_t space = sizeof outbuf - 1;
+	size_t space = sizeof(outbuf - 1);

wrong ...
think that is 7 instead of 79.

David

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

maintainer
#1119 lore raw

Re: [PATCH 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

Quoted 5 lines · David Laight

From: SF Markus Elfring Sent: 26 September 2016 16:45

Quoted 2 lines

The script "checkpatch.pl" can point information out like the following.
WARNING: sizeof … should be sizeof(…)

[]

drivers/isdn/gigaset/common.c

Quoted 1 line
drivers/isdn/gigaset/common.c +0 -0

[]

Quoted 9 lines

drivers/isdn/gigaset/common.c void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg, · line 56

Quoted 6 lines
drivers/isdn/gigaset/common.c +1 -1
@@ -53,7 +53,7 @@ void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg,
  {
  	unsigned char outbuf[80];
  	unsigned char c;
-	size_t space = sizeof outbuf - 1;
+	size_t space = sizeof(outbuf - 1);

wrong ...
think that is 7 instead of 79.

Well, it's sizeof(pointer) so either 4 or 8, but still, what Markus proposes here is _wrong_.

Markus, do you know the script probably has a lower style conversion defect introduction rate than you do when doing these mechanical things.

Please use it to verify what you are doing before submitting more defective patches.

Excuses and apologies aren't good enough at this point.

#1120 lore raw

Re: [PATCH 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

Quoted 11 lines
Quoted 9 lines

drivers/isdn/gigaset/common.c void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg, · line 56

Quoted 6 lines
drivers/isdn/gigaset/common.c +1 -1
@@ -53,7 +53,7 @@ void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg,
 {
 	unsigned char outbuf[80];
 	unsigned char c;
-	size_t space = sizeof outbuf - 1;
+	size_t space = sizeof(outbuf - 1);

wrong ...
think that is 7 instead of 79.

Quoted 2 lines

Well, it's sizeof(pointer) so either 4 or 8, but still, what Markus proposes here is _wrong_.

You are right at this place.

Quoted 3 lines

Markus, do you know the script probably has a lower style conversion defect introduction rate than you do when doing these mechanical things.

Would it be nice if the script "checkpatch.pl" could avoid to point such a false positive out anyhow?

Quoted 2 lines

Please use it to verify what you are doing before submitting more defective patches.

Do you expect a resend for this update step so that an other statement in the function "gigaset_initdriver" would eventually be adjusted?

Regards,
Markus

#1121 lore raw

Re: [PATCH 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

Quoted 17 lines · SF Markus Elfring
Quoted 11 lines
Quoted 9 lines

drivers/isdn/gigaset/common.c void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg, · line 56

Quoted 6 lines
drivers/isdn/gigaset/common.c +1 -1
@@ -53,7 +53,7 @@ void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg,
 {
 	unsigned char outbuf[80];
 	unsigned char c;
-	size_t space = sizeof outbuf - 1;
+	size_t space = sizeof(outbuf - 1);

wrong ...
think that is 7 instead of 79.

Quoted 2 lines

Well, it's sizeof(pointer) so either 4 or 8, but still, what Markus proposes here is _wrong_.

You are right at this place.

Quoted 6 lines
Quoted 3 lines

Markus, do you know the script probably has a lower style conversion defect introduction rate than you do when doing these mechanical things.

Would it be nice if the script "checkpatch.pl" could avoid to point such a false positive out anyhow?

checkpatch reports:

WARNING: sizeof outbuf should be sizeof(outbuf)
#56: FILE: drivers/isdn/gigaset/common.c:56:
+ size_t space = sizeof outbuf - 1;

There is nothing wrong with the report,

julia

Quoted 15 lines
Quoted 4 lines

Please use it to verify what you are doing before submitting more defective patches.

Do you expect a resend for this update step so that an other statement in the function "gigaset_initdriver" would eventually be adjusted?

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#1122 lore raw

PATCH v2 5/5 ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

In reply to Joe Perches

From: Markus Elfring <[email protected]>
Date: Mon, 26 Sep 2016 19:34:27 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The script "checkpatch.pl" can point information out like the following.

WARNING: sizeof … should be sizeof(…)

Thus fix the affected source code places.

---

v2: Position the desired closing parenthesis behind the variable name for
a character buffer.

 drivers/isdn/gigaset/common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/isdn/gigaset/common.c +2 -2
index 2e9382f..dba44e1 100644
@@ -53,7 +53,7 @@ void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg,
 {
 	unsigned char outbuf[80];
 	unsigned char c;
-	size_t space = sizeof outbuf - 1;
+	size_t space = sizeof(outbuf) - 1;
 	unsigned char *out = outbuf;
 	size_t numin = len;
 
@@ -1079,7 +1079,7 @@ struct gigaset_driver *gigaset_initdriver(unsigned minor, unsigned minors,
 	unsigned long flags;
 	unsigned i;
 
-	drv = kmalloc(sizeof *drv, GFP_KERNEL);
+	drv = kmalloc(sizeof(*drv), GFP_KERNEL);
 	if (!drv)
 		return NULL;
 
Signature · 1 line
2.10.0
#1123 lore raw

Re: [PATCH v2 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

Quoted 2 lines · SF Markus Elfring

v2: Position the desired closing parenthesis behind the variable name for a character buffer.

Please wait a reasonable amount of time (say a week or two) to collect all feedback on all patches of a series. If there's feedback you should resend the entire series (minus those patches that have been NAK-ed, of course) as an update (v2, v3, etc.).

Don't resubmit one single patch of a series (within hours!) as you did here.

I hope to have a look at your series within a few days. Show some patience.

Thanks,

Paul Bolle

#1124 lore raw

Re: [PATCH v2 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

Quoted 2 lines

Don't resubmit one single patch of a series (within hours!) as you did here.

I hope that I could reduce the confusion a bit which I introduced with a change in the last step of my questionable update suggestion.

Quoted 2 lines

I hope to have a look at your series within a few days. Show some patience.

Yes, of course.

Regards,
Markus

maintainer
#1125 lore raw

Re: [PATCH v2 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

In reply to SF Markus Elfring

When you need to make changes to patches that are part of a series, you must resubmit the entire series, not just the things that are changes.

#1126 lore raw

Re: [PATCH v2 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

Quoted 2 lines

When you need to make changes to patches that are part of a series, you must resubmit the entire series,

I imagine that will happen when the patch review time passed by a bit more as Paul Bolle requested it yesterday.

Quoted 1 line

not just the things that are changes.

Thanks for your reminder.

Regards,
Markus

#1127 lore raw

Re: [PATCH 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

In reply to SF Markus Elfring

Hello.

Quoted 22 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Mon, 26 Sep 2016 17:03:56 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The script "checkpatch.pl" can point information out like the following.

WARNING: sizeof … should be sizeof(…)

Thus fix the affected source code places.

---
 drivers/isdn/gigaset/common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/isdn/gigaset/common.c +0 -0
index 2e9382f..d901ed7 100644

drivers/isdn/gigaset/common.c void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg, · line 56

Quoted 5 lines
drivers/isdn/gigaset/common.c +1 -1
@@ -53,7 +53,7 @@ void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg,
 {
 	unsigned char outbuf[80];
 	unsigned char c;
-	size_t space = sizeof outbuf - 1;
+	size_t space = sizeof(outbuf - 1);

What?! Does that compile?

[...]

MBR, Sergei

#1128 lore raw

Re: ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

Quoted 8 lines

drivers/isdn/gigaset/common.c void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg, · line 56

Quoted 6 lines
drivers/isdn/gigaset/common.c +1 -1
@@ -53,7 +53,7 @@ void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg,
 {
     unsigned char outbuf[80];
     unsigned char c;
-    size_t space = sizeof outbuf - 1;
+    size_t space = sizeof(outbuf - 1);

What?! Does that compile?

Yes, of course. - The calculated value will be lower than intended.

Unfortunately, I stumbled on one of my own programming mistakes once again.

I sent a corrected update suggestion for further considerations a few minutes ago.

Regards,
Markus

#1129 lore raw

Re: ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

Where did the [PATCH 5/5] part of the subject go? You didn't drop it, did you? Because that's surprisingly annoying.

Paul Bolle

#1130 lore raw

Re: [PATCH 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

In reply to Sergei Shtylyov
Quoted 10 lines · Sergei Shtylyov

drivers/isdn/gigaset/common.c void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg, · line 56

Quoted 6 lines
drivers/isdn/gigaset/common.c +1 -1
@@ -53,7 +53,7 @@ void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg,
 {
 	unsigned char outbuf[80];
 	unsigned char c;
-	size_t space = sizeof outbuf - 1;
+	size_t space = sizeof(outbuf - 1);

What?! Does that compile?

[...]

It prints a Smatch warning. Smatch ignores these if they happen inside a macro where you pass a pointer and it takes the sizeof() the argument.

regards,
dan carpenter

#1131 lore raw

Re: [PATCH 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

Quoted 10 lines · Dan Carpenter
Quoted 9 lines · Sergei Shtylyov

drivers/isdn/gigaset/common.c void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg, · line 56

Quoted 6 lines
drivers/isdn/gigaset/common.c +1 -1
@@ -53,7 +53,7 @@ void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg,
 {
 	unsigned char outbuf[80];
 	unsigned char c;
-	size_t space = sizeof outbuf - 1;
+	size_t space = sizeof(outbuf - 1);

What?! Does that compile?

Quoted 4 lines
Quoted 1 line

[...]

It prints a Smatch warning. Smatch ignores these if they happen inside a macro where you pass a pointer and it takes the sizeof() the argument.

Reading that again, I realize it's not clear. Smatch ignores these any time they happen in a macro whether they're valid or not. (Many times they are valid).

regards,
dan carpenter

#1132 lore raw

Re: [PATCH 0/5] ISDN-Gigaset: Fine-tuning for three function implementations

In reply to SF Markus Elfring
Quoted 11 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Mon, 26 Sep 2016 17:27:17 +0200

Some update suggestions were taken into account
from static source code analysis.

Markus Elfring (5):
  Use kmalloc_array() in two functions
  Improve another size determination in gigaset_initcs() Delete an error message for a failed memory allocation Release memory in gigaset_initcs() after an allocation failure

Which "static source code analysis" was used for that discovery?

Quoted 4 lines

  Enclose two expressions for the sizeof operator by parentheses

 drivers/isdn/gigaset/common.c | 31 ++++++++++++++++---------------

 1 file changed, 16 insertions(+), 15 deletions(-)

Paul Bolle

#1133 lore raw

Re: ISDN-Gigaset: Fine-tuning for three function implementations

Quoted 6 lines
Quoted 4 lines

Use kmalloc_array() in two functions
Improve another size determination in gigaset_initcs() Delete an error message for a failed memory allocation Release memory in gigaset_initcs() after an allocation failure

Which "static source code analysis" was used for that discovery?

Are you eventually asking more for the development tools which were involved here?

* Coccinelle software

* Script "checkpatch.pl"

* My own eyes with help of a current text editor and its programming support

Regards,
Markus

#1134 lore raw

Re: [PATCH 0/5] ISDN-Gigaset: Fine-tuning for three function implementations

In reply to SF Markus Elfring
Quoted 10 lines · SF Markus Elfring

Some update suggestions were taken into account
from static source code analysis.

Markus Elfring (5):
  Use kmalloc_array() in two functions
  Improve another size determination in gigaset_initcs() Delete an error message for a failed memory allocation Release memory in gigaset_initcs() after an allocation failure Enclose two expressions for the sizeof operator by parentheses

Quoted 2 lines

 drivers/isdn/gigaset/common.c | 31 ++++++++++++++++---------------

 1 file changed, 16 insertions(+), 15 deletions(-)

Two of the five patches introduced bugs. The rest of the series isn't free of various nits either. Of course, I was in no mood to be lenient when I looked at those three patches.

I won't take any of these patches, sorry.

Paul Bolle

#1135 lore raw

Re: ISDN-Gigaset: Fine-tuning for three function implementations

Quoted 5 lines

Two of the five patches introduced bugs. The rest of the series isn't free of various nits either. Of course, I was in no mood to be lenient when I looked at those three patches.

I won't take any of these patches, sorry.

Would you like to look once more into an improved patch series for this software module a bit later?

Regards,
Markus

#1136 lore raw

Re: ISDN-Gigaset: Fine-tuning for three function implementations

Quoted 2 lines · SF Markus Elfring

Would you like to look once more into an improved patch series for this software module a bit later?

I'm afraid I'm not looking forward to receiving an update of this series, sorry.

Thanks,

Paul Bolle

#1137 lore raw

cover md/bitmap: Fine-tuning for several function implementations

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 18:29:08 +0200

Several update suggestions were taken into account from static source code analysis.

Markus Elfring (16):
Use kmalloc_array() in bitmap_storage_alloc()
Move an assignment for the variable "offset" in bitmap_storage_alloc() Delete an unnecessary variable initialisation in bitmap_storage_alloc() Improve another size determination in bitmap_storage_alloc() Return directly after a failed bitmap_storage_alloc() in bitmap_resize() Return directly after a failed kzalloc() in bitmap_resize() Replace a kzalloc() call by kcalloc() in bitmap_resize() Rename a jump label in location_store()
Rename a jump label in bitmap_copy_from_slot()
Rename a jump label in bitmap_create()
Rename a jump label in bitmap_init_from_disk()
One check less in read_page() at the end
Adjust checks for null pointers in 11 functions
Delete unnecessary braces in bitmap_resize()
Add spaces around three comparison operators
Delete an unwanted space in read_sb_page()

 drivers/md/bitmap.c | 110 +++++++++++++++++++++++++---------------------------
 1 file changed, 52 insertions(+), 58 deletions(-)
Signature · 1 line
2.10.0
#1138 lore raw

PATCH 1/16 md/bitmap: Use kmalloc_array() in bitmap_storage_alloc()

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 13:01:07 +0200

* A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

* Replace the specification of a data type by a pointer dereference to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/md/bitmap.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/md/bitmap.c +3 -3
index 13041ee..8cfb02c 100644
@@ -760,9 +760,9 @@ static int bitmap_storage_alloc(struct bitmap_storage *store,
 
 	num_pages = DIV_ROUND_UP(bytes, PAGE_SIZE);
 	offset = slot_number * num_pages;
-
-	store->filemap = kmalloc(sizeof(struct page *)
-				 * num_pages, GFP_KERNEL);
+	store->filemap = kmalloc_array(num_pages,
+				       sizeof(*store->filemap),
+				       GFP_KERNEL);
 	if (!store->filemap)
 		return -ENOMEM;
 
Signature · 1 line
2.10.0
#1139 lore raw

Re: [PATCH 01/16] md/bitmap: Use kmalloc_array() in bitmap_storage_alloc()

Quoted 23 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 13:01:07 +0200

* A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

* Replace the specification of a data type by a pointer dereference to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/md/bitmap.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/md/bitmap.c +0 -0
index 13041ee..8cfb02c 100644

drivers/md/bitmap.c static int bitmap_storage_alloc(struct bitmap_storage *store, · line 765

Quoted 9 lines
drivers/md/bitmap.c +3 -3
@@ -760,9 +760,9 @@ static int bitmap_storage_alloc(struct bitmap_storage *store,
 
 	num_pages = DIV_ROUND_UP(bytes, PAGE_SIZE);
 	offset = slot_number * num_pages;
-
-	store->filemap = kmalloc(sizeof(struct page *)
-				 * num_pages, GFP_KERNEL);
+	store->filemap = kmalloc_array(num_pages,
+				       sizeof(*store->filemap),
+				       GFP_KERNEL);

If you have to make cosmetic changes for the sake of it, then at least use the 80 characters per line that you have available.

This one makes the code uglier.

Jes

#1140 lore raw

PATCH 2/16 md/bitmap: Move an assignment for the variable "offset" in bitmap_storage_alloc()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 13:10:05 +0200

Move the assignment for the local variable "offset" behind the source code for memory allocations by this function.

---
 drivers/md/bitmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/bitmap.c +1 -1
index 8cfb02c..78512c6 100644
@@ -759,7 +759,6 @@ static int bitmap_storage_alloc(struct bitmap_storage *store,
 		bytes += sizeof(bitmap_super_t);
 
 	num_pages = DIV_ROUND_UP(bytes, PAGE_SIZE);
-	offset = slot_number * num_pages;
 	store->filemap = kmalloc_array(num_pages,
 				       sizeof(*store->filemap),
 				       GFP_KERNEL);
@@ -772,6 +771,7 @@ static int bitmap_storage_alloc(struct bitmap_storage *store,
 			return -ENOMEM;
 	}
 
+	offset = slot_number * num_pages;
 	pnum = 0;
 	if (store->sb_page) {
 		store->filemap[0] = store->sb_page;
Signature · 1 line
2.10.0
#1141 lore raw

PATCH 3/16 md/bitmap: Delete an unnecessary variable initialisation in bitmap_storage_alloc()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 13:20:23 +0200

The local variable "offset" will be set to an appropriate value a bit later. Thus omit the explicit initialisation at the beginning.

---
 drivers/md/bitmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/bitmap.c +1 -1
index 78512c6..9b3f723 100644
@@ -750,7 +750,7 @@ static int bitmap_storage_alloc(struct bitmap_storage *store,
 				unsigned long chunks, int with_super,
 				int slot_number)
 {
-	int pnum, offset = 0;
+	int pnum, offset;
 	unsigned long num_pages;
 	unsigned long bytes;
 
Signature · 1 line
2.10.0
#1142 lore raw

PATCH 4/16 md/bitmap: Improve another size determination in bitmap_storage_alloc()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 14:19:00 +0200

Replace the specification of a data type by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/md/bitmap.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/md/bitmap.c +3 -3
index 9b3f723..c278865 100644
@@ -791,9 +791,9 @@ static int bitmap_storage_alloc(struct bitmap_storage *store,
 
 	/* We need 4 bits per page, rounded up to a multiple
 	 * of sizeof(unsigned long) */
-	store->filemap_attr = kzalloc(
-		roundup(DIV_ROUND_UP(num_pages*4, 8), sizeof(unsigned long)),
-		GFP_KERNEL);
+	store->filemap_attr = kzalloc(roundup(DIV_ROUND_UP(num_pages * 4, 8),
+					      sizeof(*store->filemap_attr)),
+				      GFP_KERNEL);
 	if (!store->filemap_attr)
 		return -ENOMEM;
 
Signature · 1 line
2.10.0
#1143 lore raw

PATCH 5/16 md/bitmap: Return directly after a failed bitmap_storage_alloc() in bitmap_resize()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 14:47:29 +0200

Return directly after a memory allocation failed in this function at the beginning.

---
 drivers/md/bitmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/bitmap.c +1 -1
index c278865..5092bc0 100644
@@ -2032,7 +2032,7 @@ int bitmap_resize(struct bitmap *bitmap, sector_t blocks,
 					   mddev_is_clustered(bitmap->mddev)
 					   ? bitmap->cluster_slot : 0);
 	if (ret)
-		goto err;
+		return ret;
 
 	pages = DIV_ROUND_UP(chunks, PAGE_COUNTER_RATIO);
 
Signature · 1 line
2.10.0
#1144 lore raw

PATCH 6/16 md/bitmap: Return directly after a failed kzalloc() in bitmap_resize()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 15:21:23 +0200

* Return directly after a call of the function "kzalloc" failed here.

* Delete two assignments for the local variable "ret" and the jump target "err" which became unnecessary with this refactoring.

---
 drivers/md/bitmap.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)
drivers/md/bitmap.c +1 -4
index 5092bc0..2d30c83 100644
@@ -2037,10 +2037,9 @@ int bitmap_resize(struct bitmap *bitmap, sector_t blocks,
 	pages = DIV_ROUND_UP(chunks, PAGE_COUNTER_RATIO);
 
 	new_bp = kzalloc(pages * sizeof(*new_bp), GFP_KERNEL);
-	ret = -ENOMEM;
 	if (!new_bp) {
 		bitmap_file_unmap(&store);
-		goto err;
+		return -ENOMEM;
 	}
 
 	if (!init)
@@ -2160,8 +2159,6 @@ int bitmap_resize(struct bitmap *bitmap, sector_t blocks,
 		bitmap_unplug(bitmap);
 		bitmap->mddev->pers->quiesce(bitmap->mddev, 0);
 	}
-	ret = 0;
-err:
 	return ret;
 }
 EXPORT_SYMBOL_GPL(bitmap_resize);
Signature · 1 line
2.10.0
#1145 lore raw

PATCH 7/16 md/bitmap: Replace a kzalloc() call by kcalloc() in bitmap_resize()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 15:26:51 +0200

The script "checkpatch.pl" can point information out like the following.

WARNING: Prefer kcalloc over kzalloc with multiply

Thus fix the affected source code place.

---
 drivers/md/bitmap.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/md/bitmap.c +1 -2
index 2d30c83..41d99fd 100644
@@ -2035,8 +2035,7 @@ int bitmap_resize(struct bitmap *bitmap, sector_t blocks,
 		return ret;
 
 	pages = DIV_ROUND_UP(chunks, PAGE_COUNTER_RATIO);
-
-	new_bp = kzalloc(pages * sizeof(*new_bp), GFP_KERNEL);
+	new_bp = kcalloc(pages, sizeof(*new_bp), GFP_KERNEL);
 	if (!new_bp) {
 		bitmap_file_unmap(&store);
 		return -ENOMEM;
Signature · 1 line
2.10.0
#1146 lore raw

PATCH 8/16 md/bitmap: Rename a jump label in location_store()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 15:46:22 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/md/bitmap.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)
drivers/md/bitmap.c +9 -9
index 41d99fd..22fa09a 100644
@@ -2187,11 +2187,11 @@ location_store(struct mddev *mddev, const char *buf, size_t len)
 	if (mddev->pers) {
 		if (!mddev->pers->quiesce) {
 			rv = -EBUSY;
-			goto out;
+			goto unlock;
 		}
 		if (mddev->recovery || mddev->sync_thread) {
 			rv = -EBUSY;
-			goto out;
+			goto unlock;
 		}
 	}
 
@@ -2200,7 +2200,7 @@ location_store(struct mddev *mddev, const char *buf, size_t len)
 		/* bitmap already configured.  Only option is to clear it */
 		if (strncmp(buf, "none", 4) != 0) {
 			rv = -EBUSY;
-			goto out;
+			goto unlock;
 		}
 		if (mddev->pers) {
 			mddev->pers->quiesce(mddev, 1);
@@ -2221,23 +2221,23 @@ location_store(struct mddev *mddev, const char *buf, size_t len)
 		else if (strncmp(buf, "file:", 5) = 0) {
 			/* Not supported yet */
 			rv = -EINVAL;
-			goto out;
+			goto unlock;
 		} else {
 			if (buf[0] = '+')
 				rv = kstrtoll(buf+1, 10, &offset);
 			else
 				rv = kstrtoll(buf, 10, &offset);
 			if (rv)
-				goto out;
+				goto unlock;
 			if (offset = 0) {
 				rv = -EINVAL;
-				goto out;
+				goto unlock;
 			}
 			if (mddev->bitmap_info.external = 0 &&
 			    mddev->major_version = 0 &&
 			    offset != mddev->bitmap_info.default_offset) {
 				rv = -EINVAL;
-				goto out;
+				goto unlock;
 			}
 			mddev->bitmap_info.offset = offset;
 			if (mddev->pers) {
@@ -2255,7 +2255,7 @@ location_store(struct mddev *mddev, const char *buf, size_t len)
 				mddev->pers->quiesce(mddev, 0);
 				if (rv) {
 					bitmap_destroy(mddev);
-					goto out;
+					goto unlock;
 				}
 			}
 		}
@@ -2268,7 +2268,7 @@ location_store(struct mddev *mddev, const char *buf, size_t len)
 		md_wakeup_thread(mddev->thread);
 	}
 	rv = 0;
-out:
+unlock:
 	mddev_unlock(mddev);
 	if (rv)
 		return rv;
Signature · 1 line
2.10.0
#1147 lore raw

Re: [PATCH 08/16] md/bitmap: Rename a jump label in location_store()

Quoted 9 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 15:46:22 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/md/bitmap.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

Sorry but this patch is just plain ridiculous. It does not improve the code in any shape or form.

'out' as a label is perfectly legitimate and just as good as 'unlock'.

Jes

Quoted 73 lines
drivers/md/bitmap.c +9 -9
index 41d99fd..22fa09a 100644
@@ -2187,11 +2187,11 @@ location_store(struct mddev *mddev, const char *buf, size_t len)
 	if (mddev->pers) {
 		if (!mddev->pers->quiesce) {
 			rv = -EBUSY;
-			goto out;
+			goto unlock;
 		}
 		if (mddev->recovery || mddev->sync_thread) {
 			rv = -EBUSY;
-			goto out;
+			goto unlock;
 		}
 	}
 
@@ -2200,7 +2200,7 @@ location_store(struct mddev *mddev, const char *buf, size_t len)
 		/* bitmap already configured.  Only option is to clear it */
 		if (strncmp(buf, "none", 4) != 0) {
 			rv = -EBUSY;
-			goto out;
+			goto unlock;
 		}
 		if (mddev->pers) {
 			mddev->pers->quiesce(mddev, 1);
@@ -2221,23 +2221,23 @@ location_store(struct mddev *mddev, const char *buf, size_t len)
 		else if (strncmp(buf, "file:", 5) = 0) {
 			/* Not supported yet */
 			rv = -EINVAL;
-			goto out;
+			goto unlock;
 		} else {
 			if (buf[0] = '+')
 				rv = kstrtoll(buf+1, 10, &offset);
 			else
 				rv = kstrtoll(buf, 10, &offset);
 			if (rv)
-				goto out;
+				goto unlock;
 			if (offset = 0) {
 				rv = -EINVAL;
-				goto out;
+				goto unlock;
 			}
 			if (mddev->bitmap_info.external = 0 &&
 			    mddev->major_version = 0 &&
 			    offset != mddev->bitmap_info.default_offset) {
 				rv = -EINVAL;
-				goto out;
+				goto unlock;
 			}
 			mddev->bitmap_info.offset = offset;
 			if (mddev->pers) {
@@ -2255,7 +2255,7 @@ location_store(struct mddev *mddev, const char *buf, size_t len)
 				mddev->pers->quiesce(mddev, 0);
 				if (rv) {
 					bitmap_destroy(mddev);
-					goto out;
+					goto unlock;
 				}
 			}
 		}
@@ -2268,7 +2268,7 @@ location_store(struct mddev *mddev, const char *buf, size_t len)
 		md_wakeup_thread(mddev->thread);
 	}
 	rv = 0;
-out:
+unlock:
 	mddev_unlock(mddev);
 	if (rv)
 		return rv;
#1148 lore raw

Re: [PATCH 08/16] md/bitmap: Rename a jump label in location_store()

Quoted 6 lines · Jes Sorensen
Quoted 5 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 15:46:22 +0200

Adjust jump labels according to the current Linux coding style convention.

Quoted 8 lines
Quoted 4 lines
---
  drivers/md/bitmap.c | 18 +++++++++---------
  1 file changed, 9 insertions(+), 9 deletions(-)

Sorry but this patch is just plain ridiculous. It does not improve the code in any shape or form.

'out' as a label is perfectly legitimate and just as good as 'unlock'.

Agree, I also curious which document recorded the coding style convention.

Thanks,
Guoqing

#1149 lore raw

PATCH 9/16 md/bitmap: Rename a jump label in bitmap_copy_from_slot()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 15:55:01 +0200

Adjust a jump label according to the current Linux coding style convention.

---
 drivers/md/bitmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/md/bitmap.c +2 -2
index 22fa09a..5125186 100644
@@ -1910,7 +1910,7 @@ int bitmap_copy_from_slot(struct mddev *mddev, int slot,
 
 	rv = bitmap_init_from_disk(bitmap, 0);
 	if (rv)
-		goto err;
+		goto free_bitmap;
 
 	counts = &bitmap->counts;
 	for (j = 0; j < counts->chunks; j++) {
@@ -1937,7 +1937,7 @@ int bitmap_copy_from_slot(struct mddev *mddev, int slot,
 	bitmap_unplug(mddev->bitmap);
 	*low = lo;
 	*high = hi;
-err:
+free_bitmap:
 	bitmap_free(bitmap);
 	return rv;
 }
Signature · 1 line
2.10.0
#1150 lore raw

PATCH 10/16 md/bitmap: Rename a jump label in bitmap_create()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 16:06:35 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/md/bitmap.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/md/bitmap.c +4 -4
index 5125186..1f7f1e1 100644
@@ -1818,22 +1818,22 @@ struct bitmap *bitmap_create(struct mddev *mddev, int slot)
 			err = -EINVAL;
 	}
 	if (err)
-		goto error;
+		goto free_bitmap;
 
 	bitmap->daemon_lastrun = jiffies;
 	err = bitmap_resize(bitmap, blocks, mddev->bitmap_info.chunksize, 1);
 	if (err)
-		goto error;
+		goto free_bitmap;
 
 	printk(KERN_INFO "created bitmap (%lu pages) for device %s\n",
 	       bitmap->counts.pages, bmname(bitmap));
 
 	err = test_bit(BITMAP_WRITE_ERROR, &bitmap->flags) ? -EIO : 0;
 	if (err)
-		goto error;
+		goto free_bitmap;
 
 	return bitmap;
- error:
+free_bitmap:
 	bitmap_free(bitmap);
 	return ERR_PTR(err);
 }
Signature · 1 line
2.10.0
#1151 lore raw

PATCH 11/16 md/bitmap: Rename a jump label in bitmap_init_from_disk()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 16:12:47 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/md/bitmap.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)
drivers/md/bitmap.c +4 -5
index 1f7f1e1..c186e5d 100644
@@ -1064,7 +1064,7 @@ static int bitmap_init_from_disk(struct bitmap *bitmap, sector_t start)
 		       bmname(bitmap),
 		       (unsigned long) i_size_read(file->f_mapping->host),
 		       store->bytes);
-		goto err;
+		goto report_failure;
 	}
 
 	oldindex = ~0L;
@@ -1098,7 +1098,7 @@ static int bitmap_init_from_disk(struct bitmap *bitmap, sector_t start)
 					index + node_offset, count);
 
 			if (ret)
-				goto err;
+				goto report_failure;
 
 			oldindex = index;
 
@@ -1116,7 +1116,7 @@ static int bitmap_init_from_disk(struct bitmap *bitmap, sector_t start)
 				ret = -EIO;
 				if (test_bit(BITMAP_WRITE_ERROR,
 					     &bitmap->flags))
-					goto err;
+					goto report_failure;
 			}
 		}
 		paddr = kmap_atomic(page);
@@ -1143,8 +1143,7 @@ static int bitmap_init_from_disk(struct bitmap *bitmap, sector_t start)
 	       bit_cnt, chunks);
 
 	return 0;
-
- err:
+report_failure:
 	printk(KERN_INFO "%s: bitmap initialisation failed: %d\n",
 	       bmname(bitmap), ret);
 	return ret;
Signature · 1 line
2.10.0
#1152 lore raw

PATCH 12/16 md/bitmap: One check less in read_page() at the end

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 16:30:25 +0200

* Adjust a jump target.

* Delete a repeated check which became unnecessary with this refactoring.

---
 drivers/md/bitmap.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/md/bitmap.c +5 -5
index c186e5d..e7a7fc8 100644
@@ -367,7 +367,7 @@ static int read_page(struct file *file, unsigned long index,
 	bh = alloc_page_buffers(page, 1<<inode->i_blkbits, 0);
 	if (!bh) {
 		ret = -ENOMEM;
-		goto out;
+		goto report_failure;
 	}
 	attach_page_buffers(page, bh);
 	block = index << (PAGE_SHIFT - inode->i_blkbits);
@@ -379,7 +379,7 @@ static int read_page(struct file *file, unsigned long index,
 			if (bh->b_blocknr = 0) {
 				/* Cannot use this file! */
 				ret = -EINVAL;
-				goto out;
+				goto report_failure;
 			}
 			bh->b_bdev = inode->i_sb->s_bdev;
 			if (count < (1<<inode->i_blkbits))
@@ -401,14 +401,14 @@ static int read_page(struct file *file, unsigned long index,
 
 	wait_event(bitmap->write_wait,
 		   atomic_read(&bitmap->pending_writes)=0);
-	if (test_bit(BITMAP_WRITE_ERROR, &bitmap->flags))
+	if (test_bit(BITMAP_WRITE_ERROR, &bitmap->flags)) {
 		ret = -EIO;
-out:
-	if (ret)
+report_failure:
 		printk(KERN_ALERT "md: bitmap read error: (%dB @ %llu): %d\n",
 			(int)PAGE_SIZE,
 			(unsigned long long)index << PAGE_SHIFT,
 			ret);
+	}
 	return ret;
 }
 
Signature · 1 line
2.10.0
#1153 lore raw

Re: [PATCH 12/16] md/bitmap: One check less in read_page() at the end

This makes the code ugly.

regards,
dan carpenter

#1154 lore raw

PATCH 13/16 md/bitmap: Adjust checks for null pointers in 11 functions

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 17:40:12 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The script "checkpatch.pl" can point information out like the following.

Comparison to NULL could be written !…

Thus fix the affected source code places.

---
 drivers/md/bitmap.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)
drivers/md/bitmap.c +12 -12
index e7a7fc8..f8900cc 100644
@@ -88,7 +88,7 @@ __acquires(bitmap->lock)
 	mappage = kzalloc(PAGE_SIZE, GFP_NOIO);
 	spin_lock_irq(&bitmap->lock);
 
-	if (mappage = NULL) {
+	if (!mappage) {
 		pr_debug("md/bitmap: map page allocation failed, hijacking\n");
 		/* We don't support hijack for cluster raid */
 		if (no_hijack)
@@ -186,7 +186,7 @@ static struct md_rdev *next_active_rdev(struct md_rdev *rdev, struct mddev *mdde
 	 * list_for_each_entry_continue_rcu() to find the first entry.
 	 */
 	rcu_read_lock();
-	if (rdev = NULL)
+	if (!rdev)
 		/* start at the beginning */
 		rdev = list_entry(&mddev->disks, struct md_rdev, same_set);
 	else {
@@ -284,7 +284,7 @@ static void write_page(struct bitmap *bitmap, struct page *page, int wait)
 {
 	struct buffer_head *bh;
 
-	if (bitmap->storage.file = NULL) {
+	if (!bitmap->storage.file) {
 		switch (write_sb_page(bitmap, page, wait)) {
 		case -EINVAL:
 			set_bit(BITMAP_WRITE_ERROR, &bitmap->flags);
@@ -493,7 +493,7 @@ static int bitmap_new_disk_sb(struct bitmap *bitmap)
 	unsigned long chunksize, daemon_sleep, write_behind;
 
 	bitmap->storage.sb_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
-	if (bitmap->storage.sb_page = NULL)
+	if (!bitmap->storage.sb_page)
 		return -ENOMEM;
 	bitmap->storage.sb_page->index = 0;
 
@@ -767,7 +767,7 @@ static int bitmap_storage_alloc(struct bitmap_storage *store,
 
 	if (with_super && !store->sb_page) {
 		store->sb_page = alloc_page(GFP_KERNEL|__GFP_ZERO);
-		if (store->sb_page = NULL)
+		if (!store->sb_page)
 			return -ENOMEM;
 	}
 
@@ -1209,7 +1209,7 @@ void bitmap_daemon_work(struct mddev *mddev)
 	 */
 	mutex_lock(&mddev->bitmap_info.mutex);
 	bitmap = mddev->bitmap;
-	if (bitmap = NULL) {
+	if (!bitmap) {
 		mutex_unlock(&mddev->bitmap_info.mutex);
 		return;
 	}
@@ -1336,7 +1336,7 @@ __acquires(bitmap->lock)
 	err = bitmap_checkpage(bitmap, page, create, 0);
 
 	if (bitmap->bp[page].hijacked ||
-	    bitmap->bp[page].map = NULL)
+	    !bitmap->bp[page].map)
 		csize = ((sector_t)1) << (bitmap->chunkshift +
 					  PAGE_COUNTER_SHIFT - 1);
 	else
@@ -1481,7 +1481,7 @@ static int __bitmap_start_sync(struct bitmap *bitmap, sector_t offset, sector_t
 {
 	bitmap_counter_t *bmc;
 	int rv;
-	if (bitmap = NULL) {/* FIXME or bitmap set as 'failed' */
+	if (!bitmap) {/* FIXME or bitmap set as 'failed' */
 		*blocks = 1024;
 		return 1; /* always resync if no bitmap */
 	}
@@ -1533,13 +1533,13 @@ void bitmap_end_sync(struct bitmap *bitmap, sector_t offset, sector_t *blocks, i
 	bitmap_counter_t *bmc;
 	unsigned long flags;
 
-	if (bitmap = NULL) {
+	if (!bitmap) {
 		*blocks = 1024;
 		return;
 	}
 	spin_lock_irqsave(&bitmap->counts.lock, flags);
 	bmc = bitmap_get_counter(&bitmap->counts, offset, blocks, 0);
-	if (bmc = NULL)
+	if (!bmc)
 		goto unlock;
 	/* locked */
 	if (RESYNC(*bmc)) {
@@ -2455,7 +2455,7 @@ static ssize_t can_clear_show(struct mddev *mddev, char *page)
 
 static ssize_t can_clear_store(struct mddev *mddev, const char *buf, size_t len)
 {
-	if (mddev->bitmap = NULL)
+	if (!mddev->bitmap)
 		return -ENOENT;
 	if (strncmp(buf, "false", 5) = 0)
 		mddev->bitmap->need_sync = 1;
@@ -2476,7 +2476,7 @@ behind_writes_used_show(struct mddev *mddev, char *page)
 {
 	ssize_t ret;
 	spin_lock(&mddev->lock);
-	if (mddev->bitmap = NULL)
+	if (!mddev->bitmap)
 		ret = sprintf(page, "0\n");
 	else
 		ret = sprintf(page, "%lu\n",
Signature · 6 lines
2.10.0

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#1155 lore raw

PATCH 14/16 md/bitmap: Delete unnecessary braces in bitmap_resize()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 17:53:07 +0200

Do not use curly brackets at one source code place where a single statement should be sufficient.

---
 drivers/md/bitmap.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/md/bitmap.c +1 -2
index f8900cc..9d77f16 100644
@@ -2075,9 +2075,8 @@ int bitmap_resize(struct bitmap *bitmap, sector_t blocks,
 				unsigned long k;
 
 				/* deallocate the page memory */
-				for (k = 0; k < page; k++) {
+				for (k = 0; k < page; k++)
 					kfree(new_bp[k].map);
-				}
 
 				/* restore some fields from old_counts */
 				bitmap->counts.bp = old_counts.bp;
Signature · 1 line
2.10.0
#1156 lore raw

PATCH 15/16 md/bitmap: Add spaces around three comparison operators

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 18:08:04 +0200

The script "checkpatch.pl" can point information out like the following.

ERROR: spaces required around that '=' (ctx:VxV)

Thus fix the affected source code places.

---
 drivers/md/bitmap.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/md/bitmap.c +3 -3
index 9d77f16..d029576 100644
@@ -303,7 +303,7 @@ static void write_page(struct bitmap *bitmap, struct page *page, int wait)
 
 		if (wait)
 			wait_event(bitmap->write_wait,
-				   atomic_read(&bitmap->pending_writes)=0);
+				   atomic_read(&bitmap->pending_writes) = 0);
 	}
 	if (test_bit(BITMAP_WRITE_ERROR, &bitmap->flags))
 		bitmap_file_kick(bitmap);
@@ -400,7 +400,7 @@ static int read_page(struct file *file, unsigned long index,
 	page->index = index;
 
 	wait_event(bitmap->write_wait,
-		   atomic_read(&bitmap->pending_writes)=0);
+		   atomic_read(&bitmap->pending_writes) = 0);
 	if (test_bit(BITMAP_WRITE_ERROR, &bitmap->flags)) {
 		ret = -EIO;
 report_failure:
@@ -1003,7 +1003,7 @@ void bitmap_unplug(struct bitmap *bitmap)
 	}
 	if (bitmap->storage.file)
 		wait_event(bitmap->write_wait,
-			   atomic_read(&bitmap->pending_writes)=0);
+			   atomic_read(&bitmap->pending_writes) = 0);
 	else
 		md_super_wait(bitmap->mddev);
 
Signature · 1 line
2.10.0
#1157 lore raw

PATCH 16/16 md/bitmap: Delete an unwanted space in read_sb_page()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Tue, 27 Sep 2016 18:18:16 +0200

The script "checkpatch.pl" can point information out like the following.

ERROR: space prohibited after that '!' (ctx:BxW)

Thus fix the affected source code place.

---
 drivers/md/bitmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/bitmap.c +1 -1
index d029576..c6a6d59 100644
@@ -154,7 +154,7 @@ static int read_sb_page(struct mddev *mddev, loff_t offset,
 	sector_t target;
 
 	rdev_for_each(rdev, mddev) {
-		if (! test_bit(In_sync, &rdev->flags)
+		if (!test_bit(In_sync, &rdev->flags)
 		    || test_bit(Faulty, &rdev->flags))
 			continue;
 
Signature · 1 line
2.10.0
#1158 lore raw

cover md/dm-crypt: Fine-tuning for five function implementations

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 28 Sep 2016 17:25:17 +0200

Some update suggestions were taken into account
from static source code analysis.

Markus Elfring (10):
Use kcalloc() in crypt_alloc_tfms()
Reduce the scope for a variable in crypt_alloc_tfms()
Rename a jump label in crypt_message()
Delete an unnecessary variable initialisation in crypt_message() Rename a jump label in crypt_set_key()
Delete an unnecessary variable initialisation in crypt_set_key() Rename a jump label in crypt_iv_tcw_whitening()
Return directly after a failed crypto_alloc_ahash() in crypt_iv_essiv_ctr() Two checks and one function call less in crypt_iv_essiv_ctr() after error detection Delete unnecessary variable initialisations in crypt_iv_essiv_ctr()

 drivers/md/dm-crypt.c | 51 ++++++++++++++++++++++-----------------------------
 1 file changed, 22 insertions(+), 29 deletions(-)
Signature · 1 line
2.10.0
#1159 lore raw

PATCH 1/10 md/dm-crypt: Use kcalloc() in crypt_alloc_tfms()

From: Markus Elfring <[email protected]>
Date: Wed, 28 Sep 2016 13:26:22 +0200

* A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus reuse the corresponding function "kcalloc".

This issue was detected by using the Coccinelle software.

* Replace the specification of a data type by a pointer dereference to make the corresponding size determination a bit safer according to the Linux coding style convention.

Fixes 5d0be84ec0cacfc7a6d6ea548afdd07d481324cd ("dm crypt: fix free of bad values after tfm allocation failure")
---
 drivers/md/dm-crypt.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/md/dm-crypt.c +1 -2
index a276883..68971a2 100644
@@ -1454,8 +1454,7 @@ static int crypt_alloc_tfms(struct crypt_config *cc, char *ciphermode)
 	unsigned i;
 	int err;
 
-	cc->tfms = kzalloc(cc->tfms_count * sizeof(struct crypto_skcipher *),
-			   GFP_KERNEL);
+	cc->tfms = kcalloc(cc->tfms_count, sizeof(*cc->tfms), GFP_KERNEL);
 	if (!cc->tfms)
 		return -ENOMEM;
 
Signature · 1 line
2.10.0
#1160 lore raw

Re: [PATCH 00/10] md/dm-crypt: Fine-tuning for five function implementations

In reply to SF Markus Elfring
Quoted 18 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 28 Sep 2016 17:25:17 +0200

Some update suggestions were taken into account
from static source code analysis.

Markus Elfring (10):
Use kcalloc() in crypt_alloc_tfms()
Reduce the scope for a variable in crypt_alloc_tfms()
Rename a jump label in crypt_message()
Delete an unnecessary variable initialisation in crypt_message() Rename a jump label in crypt_set_key()
Delete an unnecessary variable initialisation in crypt_set_key() Rename a jump label in crypt_iv_tcw_whitening()
Return directly after a failed crypto_alloc_ahash() in crypt_iv_essiv_ctr() Two checks and one function call less in crypt_iv_essiv_ctr() after error detection Delete unnecessary variable initialisations in crypt_iv_essiv_ctr()

Quoted 2 lines
 drivers/md/dm-crypt.c | 51 ++++++++++++++++++++++-----------------------------
 1 file changed, 22 insertions(+), 29 deletions(-)

These are _not_ the kind of changes I want to be seeing. Churn in the name of "fine-tuning".

Nack.

#1161 lore raw

PATCH 2/10 md/dm-crypt: Reduce the scope for a variable in crypt_alloc_tfms()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 28 Sep 2016 14:05:25 +0200

Move the definition for the variable "err" (including its declaration) into an if branch (so that the corresponding setting will only be performed if a call of the function "crypto_alloc_skcipher" failed as before this refactoring).

---
 drivers/md/dm-crypt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/md/dm-crypt.c +2 -2
index 68971a2..88a3b62 100644
@@ -1452,7 +1452,6 @@ static void crypt_free_tfms(struct crypt_config *cc)
 static int crypt_alloc_tfms(struct crypt_config *cc, char *ciphermode)
 {
 	unsigned i;
-	int err;
 
 	cc->tfms = kcalloc(cc->tfms_count, sizeof(*cc->tfms), GFP_KERNEL);
 	if (!cc->tfms)
@@ -1461,7 +1460,8 @@ static int crypt_alloc_tfms(struct crypt_config *cc, char *ciphermode)
 	for (i = 0; i < cc->tfms_count; i++) {
 		cc->tfms[i] = crypto_alloc_skcipher(ciphermode, 0, 0);
 		if (IS_ERR(cc->tfms[i])) {
-			err = PTR_ERR(cc->tfms[i]);
+			int err = PTR_ERR(cc->tfms[i]);
+
 			crypt_free_tfms(cc);
 			return err;
 		}
Signature · 1 line
2.10.0
#1162 lore raw

PATCH 3/10 md/dm-crypt: Rename a jump label in crypt_message()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 28 Sep 2016 14:54:39 +0200

Adjust a jump label according to the current Linux coding style convention.

---
 drivers/md/dm-crypt.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/md/dm-crypt.c +2 -3
index 88a3b62..08e3de2 100644
@@ -2016,7 +2016,7 @@ static int crypt_message(struct dm_target *ti, unsigned argc, char **argv)
 	int ret = -EINVAL;
 
 	if (argc < 2)
-		goto error;
+		goto show_warning;
 
 	if (!strcasecmp(argv[0], "key")) {
 		if (!test_bit(DM_CRYPT_SUSPENDED, &cc->flags)) {
@@ -2040,8 +2040,7 @@ static int crypt_message(struct dm_target *ti, unsigned argc, char **argv)
 			return crypt_wipe_key(cc);
 		}
 	}
-
-error:
+show_warning:
 	DMWARN("unrecognised message received.");
 	return -EINVAL;
 }
Signature · 1 line
2.10.0
#1163 lore raw

Re: [dm-devel] [PATCH 03/10] md/dm-crypt: Rename a jump label in crypt_message()

Quoted 4 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 28 Sep 2016 14:54:39 +0200

Adjust a jump label according to the current Linux coding style convention.

In what bizzaro world is the "current Linux coding style convention"

drivers/md/dm-crypt.c static int crypt_message(struct dm_target *ti, unsigned argc, char **argv) · line 2046

Quoted 6 lines
drivers/md/dm-crypt.c +1 -2
-
-error:
+show_warning:
 	DMWARN("unrecognised message received.");
 	return -EINVAL;
 }

"show_warning" is better than "error" when the net result of the goto is that the function returns -EINVAL?!?

Please give it up with these drive-by shooting of auto-generated patches. You're just embarassing yourself.

- Ted

#1164 lore raw

Re: [dm-devel] [PATCH 03/10] md/dm-crypt: Rename a jump label in crypt_message()

Quoted 1 line

In what bizzaro world is the "current Linux coding style convention"

Do you look at the evolution for a document like "CodingStyle"?

Quoted 8 lines

drivers/md/dm-crypt.c static int crypt_message(struct dm_target *ti, unsigned argc, char **argv) · line 2046

Quoted 6 lines
drivers/md/dm-crypt.c +1 -2
-
-error:
+show_warning:
 	DMWARN("unrecognised message received.");
 	return -EINVAL;
 }

"show_warning" is better than "error"

I got such an impression.

Quoted 1 line

when the net result of the goto is that the function returns -EINVAL?!?

Do other identifiers fit better for the desired description of "what" and "why" by jump labels?

Quoted 1 line

Please give it up with these drive-by shooting of auto-generated patches.

This update step was not auto-generated.

There are further change possibilities where special analysis tools can help in the corresponding software development.

Quoted 1 line

You're just embarassing yourself.

Do you find any of my update suggestions worth for further considerations?

Regards,
Markus

#1165 lore raw

Re: [dm-devel] [PATCH 03/10] md/dm-crypt: Rename a jump label in crypt_message()

Quoted 4 lines · SF Markus Elfring
Quoted 1 line

In what bizzaro world is the "current Linux coding style convention"

Do you look at the evolution for a document like "CodingStyle"?

Again, I wrote the paragraph in CodingStyle. I just said that it's a good idea to think about label names instead of using GW-BASIC style numbered labels, I didn't say go around bothering everyone with waste of time cleanup patches.

I specifically did not say that "out:" or "error:" labels are bad names. Those are common style in the kernel.

Please stop sending these patches.

regards,
dan carpenter

#1166 lore raw

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

Quoted 1 line

Again, I wrote the paragraph in CodingStyle.

This is obvious from the corresponding commit "add some more error handling guidelines" (ea04036032edda6f771c1381d03832d2ed0f6c31 on 2014-12-02).

Quoted 1 line

I just said that it's a good idea to think about label names

I agree also to such a desire.

Quoted 1 line

instead of using GW-BASIC style numbered labels,

Is this kind of wording another weakness in the discussed document? How many guidance do programmers get from such a software specification?

I came a few source code places along where I proposed corresponding changes.

Quoted 1 line

I didn't say

You did not say anything about some details as it is often easier to express several aspects in vague and general terms.

Quoted 1 line

go around bothering everyone with waste of time cleanup patches.

I find it still debatable if the shown software development efforts are really "wasted".

It seems that also the Linux development community is mixed about related interpretations.

Quoted 1 line

I specifically did not say that "out:" or "error:" labels are bad names.

Did you inform me once that you had also a special opinion about an identifier like "out"?

The C compiler will accept them as usual. But do we occasionally prefer to express implementation details a bit better there?

Quoted 1 line

Those are common style in the kernel.

* Which impressions can you get from a statement like "goto fail;" or "goto error;"?

* Do any exception handling implementations should be reconsidered at such places?

Quoted 1 line

Please stop sending these patches.

Could it happen that the change acceptance will increase also for
the suggested renaming of jump labels if maintainers from other subsystems would dare to respond once more in a positive way for such a software refactoring?

Regards,
Markus

maintainer
#1167 lore raw

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

Quoted 4 lines · SF Markus Elfring
Quoted 1 line

go around bothering everyone with waste of time cleanup patches.

I find it still debatable if the shown software development efforts are really "wasted".

When someone tells you that you are wasting their time, then that is not a subject for further discussion.

Bjørn

#1168 lore raw

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

Quoted 1 line

When someone tells you that you are wasting their time,

This information can be useful to some degree

Quoted 1 line

then that is not a subject for further discussion.

I got an other impression. I guess that there are constraints for such a response which can become interesting for further considerations.

Is it just usual that other software changes are more welcome?

Regards,
Markus

maintainer
#1169 lore raw

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

Quoted 3 lines · SF Markus Elfring
Quoted 1 line

When someone tells you that you are wasting their time,

This information can be useful to some degree

Yes. If you continue discussing after that point, then you make a clear statement that it isn't an accident. You are deliberately wasting their time.

A lot of people already know this. But you're right that it would be useful to make it even clearer. Maybe you could add a note about it to each patch? Something along "I will not listen. I will not change. Nothing you tell me will ever make it worth your time to do so"?

Just an idea...

Bjørn

#1170 lore raw

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

Quoted 1 line

If you continue discussing after that point,

I guess that such a condition is not needed.

Quoted 1 line

then you make a clear statement that it isn't an accident.

I hope that most of my software development activities are not "an accident". Is the intent for any update suggestion (like the renaming of a jump label in this case) reasonable to some degree?

Quoted 1 line

You are deliberately wasting their time.

I imagine that I do not really try to "waste" others time. But I am trying also to change some "things".
There are circumstances when these contributions are interpreted as "wasted efforts". Is the change acceptance usually higher for other update patterns?

Quoted 1 line

Something along "I will not listen.

I am listening while my responses might not fit to your current expectations.

Quoted 1 line

I will not change.

I have got also some personal change opportunities.

Quoted 1 line

Nothing you tell me will ever make it worth your time to do so"?

While you can be so clear about a rejection for this software module at the moment, other contributors showed occasionally more positive information.

Regards,
Markus

#1171 lore raw

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

In reply to SF Markus Elfring
Quoted 4 lines · SF Markus Elfring
Quoted 1 line

I specifically did not say that "out:" or "error:" labels are bad names.

Did you inform me once that you had also a special opinion about an identifier like "out"?

I don't like out labels, but that's my opinion. There is nothing in CodingStyle which says you can't do it.

regards,
dan carpenter

#1172 lore raw

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

Quoted 1 line

I don't like out labels, but that's my opinion.

Thanks for this acknowledgement that you have still got a special opinion about such an identifier.

Quoted 1 line

There is nothing in CodingStyle which says you can't do it.

Does the terse description there try to suggest also to choose better identifiers for source code places?

Does the meaning of such a coding style specification include also the selection of a more pleasing identifier than "error" for this software module?

Regards,
Markus

#1173 lore raw

PATCH 4/10 md/dm-crypt: Delete an unnecessary variable initialisation in crypt_message()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 28 Sep 2016 15:06:05 +0200

The local variable "ret" will be set to an appropriate value in if branches. Thus omit the explicit initialisation at the beginning.

---
 drivers/md/dm-crypt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/dm-crypt.c +1 -1
index 08e3de2..7778e9b 100644
@@ -2013,7 +2013,7 @@ static void crypt_resume(struct dm_target *ti)
 static int crypt_message(struct dm_target *ti, unsigned argc, char **argv)
 {
 	struct crypt_config *cc = ti->private;
-	int ret = -EINVAL;
+	int ret;
 
 	if (argc < 2)
 		goto show_warning;
Signature · 1 line
2.10.0
#1174 lore raw

PATCH 5/10 md/dm-crypt: Rename a jump label in crypt_set_key()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 28 Sep 2016 15:21:18 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/md/dm-crypt.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)
drivers/md/dm-crypt.c +4 -5
index 7778e9b..7e0fd82 100644
@@ -1496,20 +1496,19 @@ static int crypt_set_key(struct crypt_config *cc, char *key)
 
 	/* The key size may not be changed. */
 	if (cc->key_size != (key_string_len >> 1))
-		goto out;
+		goto set_memory;
 
 	/* Hyphen (which gives a key_size of zero) means there is no key. */
 	if (!cc->key_size && strcmp(key, "-"))
-		goto out;
+		goto set_memory;
 
 	if (cc->key_size && crypt_decode_key(cc->key, key, cc->key_size) < 0)
-		goto out;
+		goto set_memory;
 
 	set_bit(DM_CRYPT_KEY_VALID, &cc->flags);
 
 	r = crypt_setkey_allcpus(cc);
-
-out:
+set_memory:
 	/* Hex key string not needed after here, so wipe it. */
 	memset(key, '0', key_string_len);
 
Signature · 1 line
2.10.0
#1175 lore raw

Re: [dm-devel] [PATCH 05/10] md/dm-crypt: Rename a jump label in crypt_set_key()

drivers/md/dm-crypt.c static int crypt_set_key(struct crypt_config *cc, char *key) · line 1513

Quoted 10 lines · SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 28 Sep 2016 15:21:18 +0200

Adjust jump labels according to the current Linux coding style convention.

drivers/md/dm-crypt.c +1 -2
-
-out:
+set_memory:
 	/* Hex key string not needed after here, so wipe it. */
 	memset(key, '0', key_string_len);

Also not "current Linux coding style convetion".

- Ted

#1176 lore raw

PATCH 6/10 md/dm-crypt: Delete an unnecessary variable initialisation in crypt_set_key()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 28 Sep 2016 15:24:13 +0200

The local variable "r" will be set to an appropriate value a bit later. Thus omit the explicit initialisation at the beginning.

---
 drivers/md/dm-crypt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/dm-crypt.c +1 -1
index 7e0fd82..3bc54c1 100644
@@ -1491,7 +1491,7 @@ static int crypt_setkey_allcpus(struct crypt_config *cc)
 
 static int crypt_set_key(struct crypt_config *cc, char *key)
 {
-	int r = -EINVAL;
+	int r;
 	int key_string_len = strlen(key);
 
 	/* The key size may not be changed. */
Signature · 1 line
2.10.0
#1177 lore raw

PATCH 7/10 md/dm-crypt: Rename a jump label in crypt_iv_tcw_whitening()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 28 Sep 2016 15:32:15 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/md/dm-crypt.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/md/dm-crypt.c +4 -4
index 3bc54c1..c457b5e 100644
@@ -698,13 +698,13 @@ static int crypt_iv_tcw_whitening(struct crypt_config *cc,
 	for (i = 0; i < 4; i++) {
 		r = crypto_shash_init(desc);
 		if (r)
-			goto out;
+			goto zero_memory;
 		r = crypto_shash_update(desc, &buf[i * 4], 4);
 		if (r)
-			goto out;
+			goto zero_memory;
 		r = crypto_shash_final(desc, &buf[i * 4]);
 		if (r)
-			goto out;
+			goto zero_memory;
 	}
 	crypto_xor(&buf[0], &buf[12], 4);
 	crypto_xor(&buf[4], &buf[8], 4);
@@ -712,7 +712,7 @@ static int crypt_iv_tcw_whitening(struct crypt_config *cc,
 	/* apply whitening (8 bytes) to whole sector */
 	for (i = 0; i < ((1 << SECTOR_SHIFT) / 8); i++)
 		crypto_xor(data + i * 8, buf, 8);
-out:
+zero_memory:
 	memzero_explicit(buf, sizeof(buf));
 	return r;
 }
Signature · 1 line
2.10.0
#1178 lore raw

PATCH 8/10 md/dm-crypt: Return directly after a failed crypto_alloc_ahash() in crypt_iv_essiv_ctr()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 28 Sep 2016 15:55:47 +0200

Return directly after a call of the function "crypto_alloc_ahash" failed here.

---
 drivers/md/dm-crypt.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/md/dm-crypt.c +1 -2
index c457b5e..47f6265 100644
@@ -375,8 +375,7 @@ static int crypt_iv_essiv_ctr(struct crypt_config *cc, struct dm_target *ti,
 	hash_tfm = crypto_alloc_ahash(opts, 0, CRYPTO_ALG_ASYNC);
 	if (IS_ERR(hash_tfm)) {
 		ti->error = "Error initializing ESSIV hash";
-		err = PTR_ERR(hash_tfm);
-		goto bad;
+		return PTR_ERR(hash_tfm);
 	}
 
 	salt = kzalloc(crypto_ahash_digestsize(hash_tfm), GFP_KERNEL);
Signature · 1 line
2.10.0
#1179 lore raw

PATCH 9/10 md/dm-crypt: Two checks and one function call less in crypt_iv_essiv_ctr() after error detection

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 28 Sep 2016 16:38:37 +0200

The kfree() function was called in one case by the crypt_iv_essiv_ctr() function during error handling even if the passed variable "salt" contained a null pointer.

* Adjust a jump target according to the Linux coding style convention.

* Delete this function call and a condition check which became unnecessary with this refactoring.

---
 drivers/md/dm-crypt.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)
drivers/md/dm-crypt.c +3 -6
index 47f6265..53a9155 100644
@@ -382,7 +382,7 @@ static int crypt_iv_essiv_ctr(struct crypt_config *cc, struct dm_target *ti,
 	if (!salt) {
 		ti->error = "Error kmallocing salt storage in ESSIV";
 		err = -ENOMEM;
-		goto bad;
+		goto free_hash;
 	}
 
 	cc->iv_gen_private.essiv.salt = salt;
@@ -397,11 +397,8 @@ static int crypt_iv_essiv_ctr(struct crypt_config *cc, struct dm_target *ti,
 	cc->iv_private = essiv_tfm;
 
 	return 0;
-
-bad:
-	if (hash_tfm && !IS_ERR(hash_tfm))
-		crypto_free_ahash(hash_tfm);
-	kfree(salt);
+free_hash:
+	crypto_free_ahash(hash_tfm);
 	return err;
 }
 
Signature · 1 line
2.10.0
#1180 lore raw

PATCH 10/10 md/dm-crypt: Delete unnecessary variable initialisations in crypt_iv_essiv_ctr()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 28 Sep 2016 16:44:32 +0200

Three local variables will be set to an appropriate pointer a bit later. Thus omit the explicit initialisation which became unnecessary with a previous update step.

---
 drivers/md/dm-crypt.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/md/dm-crypt.c +3 -3
index 53a9155..d27716e 100644
@@ -361,9 +361,9 @@ static void crypt_iv_essiv_dtr(struct crypt_config *cc)
 static int crypt_iv_essiv_ctr(struct crypt_config *cc, struct dm_target *ti,
 			      const char *opts)
 {
-	struct crypto_cipher *essiv_tfm = NULL;
-	struct crypto_ahash *hash_tfm = NULL;
-	u8 *salt = NULL;
+	struct crypto_cipher *essiv_tfm;
+	struct crypto_ahash *hash_tfm;
+	u8 *salt;
 	int err;
 
 	if (!opts) {
Signature · 1 line
2.10.0
#1181 lore raw

cover dm snapshot: Fine-tuning for several function implementations

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 29 Sep 2016 10:35:43 +0200

Some update suggestions were taken into account
from static source code analysis.

Markus Elfring (10):
Use kmalloc_array() in init_origin_hash()
Delete two error messages for a failed memory allocation
Delete an unnecessary variable initialisation in snapshot_map() Rename a jump label in pending_complete()
Delete unnecessary variable initialisations in pending_complete() Delete an unnecessary variable initialisation in snapshot_ctr() Delete an unnecessary variable initialisation in merge_callback() Delete an unnecessary variable initialisation in remove_single_exception_chunk() Combine substrings for seven error messages
Delete five unwanted spaces behind "list_for_each_entry"

 drivers/md/dm-snap.c | 69 +++++++++++++++++++++++-----------------------------
 1 file changed, 30 insertions(+), 39 deletions(-)
Signature · 1 line
2.10.0
#1182 lore raw

PATCH 1/10 dm snapshot: Use kmalloc_array() in init_origin_hash()

From: Markus Elfring <[email protected]>
Date: Wed, 28 Sep 2016 22:20:08 +0200

* Multiplications for the size determination of memory allocations indicated that array data structures should be processed. Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

* Replace the specification of data structures by pointer dereferences to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/md/dm-snap.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/md/dm-snap.c +6 -4
index c65feea..f262f7e 100644
@@ -326,8 +326,9 @@ static int init_origin_hash(void)
 {
 	int i;
 
-	_origins = kmalloc(ORIGIN_HASH_SIZE * sizeof(struct list_head),
-			   GFP_KERNEL);
+	_origins = kmalloc_array(ORIGIN_HASH_SIZE,
+				 sizeof(*_origins),
+				 GFP_KERNEL);
 	if (!_origins) {
 		DMERR("unable to allocate memory for _origins");
 		return -ENOMEM;
@@ -335,8 +336,9 @@ static int init_origin_hash(void)
 	for (i = 0; i < ORIGIN_HASH_SIZE; i++)
 		INIT_LIST_HEAD(_origins + i);
 
-	_dm_origins = kmalloc(ORIGIN_HASH_SIZE * sizeof(struct list_head),
-			      GFP_KERNEL);
+	_dm_origins = kmalloc_array(ORIGIN_HASH_SIZE,
+				    sizeof(*_dm_origins),
+				    GFP_KERNEL);
 	if (!_dm_origins) {
 		DMERR("unable to allocate memory for _dm_origins");
 		kfree(_origins);
Signature · 1 line
2.10.0
#1183 lore raw

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

Andy, Joe,

Quoted 5 lines · SF Markus Elfring

* Multiplications for the size determination of memory allocations indicated that array data structures should be processed. Thus use the corresponding function "kmalloc_array".

  This issue was detected by using the Coccinelle software.

We have no hope of fixing Markus' homegrown coccinelle script. But we could try to fix the checkpatch false positive here. Something like:

scripts/checkpatch.pl +1 -1
index 206a6b3..b47201d 100755
@@ -5693,7 +5693,7 @@ sub process {
 				$r2 = $a1;
 			}
 			if ($r1 !~ /^sizeof\b/ && $r2 =~ /^sizeof\s*\S/ &&
-			    !($r1 =~ /^$Constant$/ || $r1 =~ /^[A-Z_][A-Z0-9_]*$/)) {
+			    !($r1 =~ /^$Constant$/ || $r1 =~ /^[A-Z_][A-Z0-9_]*\b/)) {
 				if (WARN("ALLOC_WITH_MULTIPLY",
 					 "Prefer $newfunc over $oldfunc with multiply\n" . $herecurr) &&
 				    $fix) {

Does that work for you too?

Quoted 23 lines
drivers/md/dm-snap.c +0 -0
@@ -326,8 +326,9 @@ static int init_origin_hash(void)
  {
  	int i;

drivers/md/dm-snap.c +3 -2
-	_origins = kmalloc(ORIGIN_HASH_SIZE * sizeof(struct list_head),
-			   GFP_KERNEL);
+	_origins = kmalloc_array(ORIGIN_HASH_SIZE,
+				 sizeof(*_origins),
+				 GFP_KERNEL);

  if (!_origins) {
  DMERR("unable to allocate memory for _origins"); return -ENOMEM;

drivers/md/dm-snap.c +0 -0
@@ -335,8 +336,9 @@ static int init_origin_hash(void)
  	for (i = 0; i < ORIGIN_HASH_SIZE; i++)
  		INIT_LIST_HEAD(_origins + i);

drivers/md/dm-snap.c +3 -2
-	_dm_origins = kmalloc(ORIGIN_HASH_SIZE * sizeof(struct list_head),
-			      GFP_KERNEL);
+	_dm_origins = kmalloc_array(ORIGIN_HASH_SIZE,
+				    sizeof(*_dm_origins),
+				    GFP_KERNEL);
Quoted 3 lines

  if (!_dm_origins) {
  DMERR("unable to allocate memory for _dm_origins"); kfree(_origins);

Thanks,

Paul Bolle

maintainer
#1184 lore raw

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

Quoted 7 lines · Paul Bolle

Andy, Joe,

Quoted 4 lines · SF Markus Elfring

* Multiplications for the size determination of memory allocations indicated that array data structures should be processed. Thus use the corresponding function "kmalloc_array".

Quoted 5 lines
Quoted 1 line

  This issue was detected by using the Coccinelle software.

We have no hope of fixing Markus' homegrown coccinelle script. But we could try to fix the checkpatch false positive here.

What's the false positive?

I get:

$ ./scripts/checkpatch.pl -f drivers/md/dm-snap.c --show-types --types=alloc_with_multiply
WARNING:ALLOC_WITH_MULTIPLY: Prefer kmalloc_array over kmalloc with multiply
#329: FILE: drivers/md/dm-snap.c:329:
+	_origins = kmalloc(ORIGIN_HASH_SIZE * sizeof(struct list_head),

WARNING:ALLOC_WITH_MULTIPLY: Prefer kmalloc_array over kmalloc with multiply #338: FILE: drivers/md/dm-snap.c:338:
+ _dm_origins = kmalloc(ORIGIN_HASH_SIZE * sizeof(struct list_head),

total: 0 errors, 2 warnings, 2490 lines checked

NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace.

drivers/md/dm-snap.c has style problems, please review.

NOTE: Used message types: ALLOC_WITH_MULTIPLY

NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS.

#1185 lore raw

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

Quoted 18 lines · Joe Perches

What's the false positive?

I get:

$ ./scripts/checkpatch.pl -f drivers/md/dm-snap.c --show-types --types=alloc_with_multiply
WARNING:ALLOC_WITH_MULTIPLY: Prefer kmalloc_array over kmalloc with multiply
#329: FILE: drivers/md/dm-snap.c:329:
(quoted diff) +1 -0
+	_origins = kmalloc(ORIGIN_HASH_SIZE * sizeof(struct list_head),

WARNING:ALLOC_WITH_MULTIPLY: Prefer kmalloc_array over kmalloc with multiply #338: FILE: drivers/md/dm-snap.c:338:

(quoted diff) +1 -0
+	_dm_origins = kmalloc(ORIGIN_HASH_SIZE * sizeof(struct list_head),

total: 0 errors, 2 warnings, 2490 lines checked

NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace.

Quoted 6 lines

drivers/md/dm-snap.c has style problems, please review.

NOTE: Used message types: ALLOC_WITH_MULTIPLY

NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS.

It seems it was intended to be silent about multiplying with constants, where things that look like preprocessor defines are also considered constants. Or did I misread that test?

Paul Bolle

#1186 lore raw

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

Quoted 1 line · Paul Bolle

Or did I misread that test?

I finally did some digging: commit e367455a9f25 ("checkpatch: emit fewer kmalloc_array/kcalloc conversion warnings") shows I didn't.

Paul Bolle

maintainer
#1187 lore raw

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

Quoted 4 lines · Paul Bolle
Quoted 1 line · Paul Bolle

Or did I misread that test?

I finally did some digging: commit e367455a9f25 ("checkpatch: emit fewer kmalloc_array/kcalloc conversion warnings") shows I didn't.

You still misread it a little.
I think it's fine as-is.

$Constant there is any number and the match regex is any upper case variable.

#1188 lore raw

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

Quoted 2 lines · Joe Perches

$Constant there is any number and the match regex is any upper case variable.

Why doesn't that regex match on "ORIGIN_HASH_SIZE"?

Paul Bolle

maintainer
#1189 lore raw

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

Quoted 4 lines · Paul Bolle
Quoted 2 lines · Joe Perches

$Constant there is any number and the match regex is any upper case variable.

Why doesn't that regex match on "ORIGIN_HASH_SIZE"?

It does match.

Did you see my earlier email?

$ ./scripts/checkpatch.pl -f drivers/md/dm-snap.c --show-types --types=alloc_with_multiply
WARNING:ALLOC_WITH_MULTIPLY: Prefer kmalloc_array over kmalloc with multiply
#329: FILE: drivers/md/dm-snap.c:329:
+       _origins = kmalloc(ORIGIN_HASH_SIZE * sizeof(struct list_head),

WARNING:ALLOC_WITH_MULTIPLY: Prefer kmalloc_array over kmalloc with multiply #338: FILE: drivers/md/dm-snap.c:338:
+       _dm_origins = kmalloc(ORIGIN_HASH_SIZE * sizeof(struct list_head),

total: 0 errors, 2 warnings, 2490 lines checked

#1190 lore raw

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

Quoted 4 lines · Joe Perches
Quoted 1 line · Paul Bolle

Why doesn't that regex match on "ORIGIN_HASH_SIZE"?

It does match.

If that regex does match, it being part of a negative test, the specific checkpatch rule should be silent, shouldn't it?

Paul Bolle

maintainer
#1191 lore raw

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

Quoted 6 lines · Paul Bolle
Quoted 3 lines · Joe Perches
Quoted 1 line · Paul Bolle

Why doesn't that regex match on "ORIGIN_HASH_SIZE"?

It does match.

If that regex does match, it being part of a negative test, the specific checkpatch rule should be silent, shouldn't it?

'cause I forgot to trim() the original $4 and $10 matches.

Oh well.

It doesn't matter match either way to me.

The case for the unnecessary multiply with <= gcc 4.8 was removed with:

commit 91c6a05f72a996bee5133e76374ab3ad7d3b9b72

Author: Alexey Dobriyan <[email protected]>
Date:   Tue Jul 26 15:22:08 2016 -0700

mm: faster kmalloc_array(), kcalloc()

When both arguments to kmalloc_array() or kcalloc() are known at compile time then their product is known at compile time but search for kmalloc cache happens at runtime not at compile time.

#1192 lore raw

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

Quoted 15 lines · Joe Perches

It doesn't matter match either way to me.

The case for the unnecessary multiply with <= gcc 4.8 was removed with:

commit 91c6a05f72a996bee5133e76374ab3ad7d3b9b72
Author: Alexey Dobriyan <[email protected]>
Date:   Tue Jul 26 15:22:08 2016 -0700

    mm: faster kmalloc_array(), kcalloc()

    When both arguments to kmalloc_array() or kcalloc() are known at compile time then their product is known at compile time but search for kmalloc cache happens at runtime not at compile time.

Quoted 8 lines

You've lost me.

Why does this stop you fixing an apparently wrong checkpatch rule, crude as parts of it are (ie, uppercase identifier must be a constant)?

Paul Bolle

maintainer
#1193 lore raw

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

Quoted 4 lines · Paul Bolle
Quoted 1 line · Joe Perches

It doesn't matter match either way to me.

Why does this stop you fixing an apparently wrong checkpatch rule, crude as parts of it are (ie, uppercase identifier must be a constant)?

It doesn't. It just doesn't matter much (match) to me. Here:

---
 scripts/checkpatch.pl | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
scripts/checkpatch.pl +3 -3
index 3373c65fef1c..fc931d89152e 100755
@@ -5835,8 +5835,8 @@ sub process {
 		if ($^V && $^V ge 5.10.0 &&
 		    $line =~ /\b($Lval)\s*\=\s*(?:$balanced_parens)?\s*(k[mz]alloc)\s*\(\s*($FuncArg)\s*\*\s*($FuncArg)\s*,/) {
 			my $oldfunc = $3;
-			my $a1 = $4;
-			my $a2 = $10;
+			my $a1 = trim($4);
+			my $a2 = trim($10);
 			my $newfunc = "kmalloc_array";
 			$newfunc = "kcalloc" if ($oldfunc eq "kzalloc");
 			my $r1 = $a1;
@@ -5850,7 +5850,7 @@ sub process {
 				if (WARN("ALLOC_WITH_MULTIPLY",
 					 "Prefer $newfunc over $oldfunc with multiply\n" . $herecurr) &&
 				    $fix) {
-					$fixed[$fixlinenr] =~ s/\b($Lval)\s*\=\s*(?:$balanced_parens)?\s*(k[mz]alloc)\s*\(\s*($FuncArg)\s*\*\s*($FuncArg)/$1 . ' = ' . "$newfunc(" . trim($r1) . ', ' . trim($r2)/e;
+					$fixed[$fixlinenr] =~ s/\b($Lval)\s*\=\s*(?:$balanced_parens)?\s*(k[mz]alloc)\s*\(\s*($FuncArg)\s*\*\s*($FuncArg)/$1 . ' = ' . "$newfunc(" . $r1 . ', ' . $r2/e;
 
 				}
 			}
#1194 lore raw

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

Quoted 6 lines · Joe Perches
Quoted 4 lines
Quoted 1 line

It doesn't matter match either way to me.

Why does this stop you fixing an apparently wrong checkpatch rule, crude as parts of it are (ie, uppercase identifier must be a constant)?

It doesn't.  It just doesn't matter much (match) to me.

Joe, please.

I've recently ping-ponged with the kernel's "resident wrong bot of the day" over this very rule (kmalloc_array() is safer than kmalloc(), so change your driver now!). Could we just give wrong bots a bit less ammunition whenever that's feasible?

Even if you don't care about my ping-pong experiences: this checkpatch test is broken, please just fix it!

Paul Bolle

#1195 lore raw

Re: dm snapshot: Use kmalloc_array() in init_origin_hash() ?

Quoted 3 lines

I've recently ping-ponged with the kernel's "resident wrong bot of the day" over this very rule (kmalloc_array() is safer than kmalloc(), so change your driver now!).

Your bot of the day is going to point more update candidates out in various source files that can "accidentally" belong also to Linux. ;-)

Quoted 1 line

Could we just give wrong bots a bit less ammunition whenever that's feasible?

How do you think about to clarify constraints any further so that the probability for false positives can be reduced as desired for the involved source code analysis tools?

Quoted 2 lines

Even if you don't care about my ping-pong experiences: this checkpatch test is broken, please just fix it!

I am curious how collateral software evolution will be continued.

Regards,
Markus

#1196 lore raw

Re: dm snapshot: Use kmalloc_array() in init_origin_hash()

In reply to Paul Bolle
Quoted 1 line

We have no hope of fixing Markus' homegrown coccinelle script.

I have got an other impression. I see further possibilities to clarify involved communication and software development challenges for a few source code search patterns.

How do you think about to discuss the corresponding collateral evolution a bit more?

Are there any more constraints to consider?

Regards,
Markus

#1197 lore raw

Re: dm snapshot: Use kmalloc_array() in init_origin_hash()

Quoted 8 lines · SF Markus Elfring
Quoted 1 line

We have no hope of fixing Markus' homegrown coccinelle script.

I have got an other impression. I see further possibilities to clarify involved communication and software development challenges for a few source code search patterns.

How do you think about to discuss the corresponding collateral evolution a bit more?

Here's my suggestion:

https://www.youtube.com/watch?v=xAnVNXaa5oA

Regards,

- Ted

#1198 lore raw

PATCH 2/10 dm snapshot: Delete two error messages for a failed memory allocation

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Wed, 28 Sep 2016 22:33:09 +0200

Omit extra messages for a memory allocation failure in this function.

---
 drivers/md/dm-snap.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)
drivers/md/dm-snap.c +1 -4
index f262f7e..7d81390 100644
@@ -329,10 +329,8 @@ static int init_origin_hash(void)
 	_origins = kmalloc_array(ORIGIN_HASH_SIZE,
 				 sizeof(*_origins),
 				 GFP_KERNEL);
-	if (!_origins) {
-		DMERR("unable to allocate memory for _origins");
+	if (!_origins)
 		return -ENOMEM;
-	}
 	for (i = 0; i < ORIGIN_HASH_SIZE; i++)
 		INIT_LIST_HEAD(_origins + i);
 
@@ -340,7 +338,6 @@ static int init_origin_hash(void)
 				    sizeof(*_dm_origins),
 				    GFP_KERNEL);
 	if (!_dm_origins) {
-		DMERR("unable to allocate memory for _dm_origins");
 		kfree(_origins);
 		return -ENOMEM;
 	}
Signature · 1 line
2.10.0
#1199 lore raw

PATCH 3/10 dm snapshot: Delete an unnecessary variable initialisation in snapshot_map()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 29 Sep 2016 08:00:29 +0200

The local variable "pe" will be set to an appropriate pointer a bit later. Thus omit the explicit initialisation at the beginning.

---
 drivers/md/dm-snap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/dm-snap.c +1 -1
index 7d81390..82b7604 100644
@@ -1675,7 +1675,7 @@ static int snapshot_map(struct dm_target *ti, struct bio *bio)
 	struct dm_snapshot *s = ti->private;
 	int r = DM_MAPIO_REMAPPED;
 	chunk_t chunk;
-	struct dm_snap_pending_exception *pe = NULL;
+	struct dm_snap_pending_exception *pe;
 
 	init_tracked_chunk(bio);
 
Signature · 1 line
2.10.0
#1200 lore raw

PATCH 4/10 dm snapshot: Rename a jump label in pending_complete()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 29 Sep 2016 08:18:51 +0200

Adjust jump labels according to the current Linux coding style convention.

---
 drivers/md/dm-snap.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)
drivers/md/dm-snap.c +4 -5
index 82b7604..a6b797f 100644
@@ -1460,7 +1460,7 @@ static void pending_complete(void *context, int success)
 		down_write(&s->lock);
 		__invalidate_snapshot(s, -EIO);
 		error = 1;
-		goto out;
+		goto remove_exception;
 	}
 
 	e = alloc_completed_exception(GFP_NOIO);
@@ -1468,7 +1468,7 @@ static void pending_complete(void *context, int success)
 		down_write(&s->lock);
 		__invalidate_snapshot(s, -ENOMEM);
 		error = 1;
-		goto out;
+		goto remove_exception;
 	}
 	*e = pe->e;
 
@@ -1476,7 +1476,7 @@ static void pending_complete(void *context, int success)
 	if (!s->valid) {
 		free_completed_exception(e);
 		error = 1;
-		goto out;
+		goto remove_exception;
 	}
 
 	/* Check for conflicting reads */
@@ -1487,8 +1487,7 @@ static void pending_complete(void *context, int success)
 	 * in-flight exception from the list.
 	 */
 	dm_insert_exception(&s->complete, e);
-
-out:
+remove_exception:
 	dm_remove_exception(&pe->e);
 	snapshot_bios = bio_list_get(&pe->snapshot_bios);
 	origin_bios = bio_list_get(&pe->origin_bios);
Signature · 1 line
2.10.0
#1201 lore raw

PATCH 5/10 dm snapshot: Delete unnecessary variable initialisations in pending_complete()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 29 Sep 2016 08:25:47 +0200

Three local variables will be set to an appropriate pointer a bit later. Thus omit the explicit initialisation at the beginning.

---
 drivers/md/dm-snap.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/md/dm-snap.c +3 -3
index a6b797f..7bbd3c4 100644
@@ -1450,9 +1450,9 @@ static void pending_complete(void *context, int success)
 	struct dm_snap_pending_exception *pe = context;
 	struct dm_exception *e;
 	struct dm_snapshot *s = pe->snap;
-	struct bio *origin_bios = NULL;
-	struct bio *snapshot_bios = NULL;
-	struct bio *full_bio = NULL;
+	struct bio *origin_bios;
+	struct bio *snapshot_bios;
+	struct bio *full_bio;
 	int error = 0;
 
 	if (!success) {
Signature · 1 line
2.10.0
#1202 lore raw

PATCH 6/10 dm snapshot: Delete an unnecessary variable initialisation in snapshot_ctr()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 29 Sep 2016 08:38:29 +0200

The local variable "r" will be set to an appropriate value a bit later. Thus omit the explicit initialisation at the beginning.

---
 drivers/md/dm-snap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/dm-snap.c +1 -1
index 7bbd3c4..06b1b69 100644
@@ -1102,7 +1102,7 @@ static int snapshot_ctr(struct dm_target *ti, unsigned int argc, char **argv)
 {
 	struct dm_snapshot *s;
 	int i;
-	int r = -EINVAL;
+	int r;
 	char *origin_path, *cow_path;
 	dev_t origin_dev, cow_dev;
 	unsigned args_used, num_flush_bios = 1;
Signature · 1 line
2.10.0
#1203 lore raw

PATCH 7/10 dm snapshot: Delete an unnecessary variable initialisation in merge_callback()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 29 Sep 2016 09:00:06 +0200

The local variable "b" will be set to an appropriate pointer a bit later. Thus omit the explicit initialisation at the beginning.

---
 drivers/md/dm-snap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/dm-snap.c +1 -1
index 06b1b69..1d90131 100644
@@ -1046,7 +1046,7 @@ static void error_bios(struct bio *bio);
 static void merge_callback(int read_err, unsigned long write_err, void *context)
 {
 	struct dm_snapshot *s = context;
-	struct bio *b = NULL;
+	struct bio *b;
 
 	if (read_err || write_err) {
 		if (read_err)
Signature · 1 line
2.10.0
#1204 lore raw

PATCH 8/10 dm snapshot: Delete an unnecessary variable initialisation in remove_single_exception_chunk()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 29 Sep 2016 09:06:37 +0200

The local variable "b" will be set to an appropriate pointer a bit later. Thus omit the explicit initialisation at the beginning.

---
 drivers/md/dm-snap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/dm-snap.c +1 -1
index 1d90131..4966584 100644
@@ -904,7 +904,7 @@ static void flush_bios(struct bio *bio);
 
 static int remove_single_exception_chunk(struct dm_snapshot *s)
 {
-	struct bio *b = NULL;
+	struct bio *b;
 	int r;
 	chunk_t old_chunk = s->first_merging_chunk + s->num_merging_chunks - 1;
 
Signature · 1 line
2.10.0
#1205 lore raw

PATCH 9/10 dm snapshot: Combine substrings for seven error messages

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 29 Sep 2016 09:46:32 +0200

The script "checkpatch.pl" can point information out like the following.

WARNING: quoted string split across lines

Thus fix the affected source code places.

---
 drivers/md/dm-snap.c | 21 +++++++--------------
 1 file changed, 7 insertions(+), 14 deletions(-)
drivers/md/dm-snap.c +7 -14
index 4966584..7593986 100644
@@ -468,8 +468,7 @@ static int __validate_exception_handover(struct dm_snapshot *snap)
 	if ((__find_snapshots_sharing_cow(snap, &snap_src, &snap_dest,
 					  &snap_merge) == 2) ||
 	    snap_dest) {
-		snap->ti->error = "Snapshot cow pairing for exception "
-				  "table handover failed";
+		snap->ti->error = "Snapshot cow pairing for exception table handover failed";
 		return -EINVAL;
 	}
 
@@ -496,8 +495,7 @@ static int __validate_exception_handover(struct dm_snapshot *snap)
 
 	if (!snap_src->store->type->prepare_merge ||
 	    !snap_src->store->type->commit_merge) {
-		snap->ti->error = "Snapshot exception store does not "
-				  "support snapshot-merge.";
+		snap->ti->error = "Snapshot exception store does not support snapshot-merge.";
 		return -EINVAL;
 	}
 
@@ -858,8 +856,7 @@ static int __remove_single_exception_chunk(struct dm_snapshot *s,
 
 	e = dm_lookup_exception(&s->complete, old_chunk);
 	if (!e) {
-		DMERR("Corruption detected: exception for block %llu is "
-		      "on disk but not in memory",
+		DMERR("Corruption detected: exception for block %llu is on disk but not in memory",
 		      (unsigned long long)old_chunk);
 		return -EINVAL;
 	}
@@ -886,8 +883,7 @@ static int __remove_single_exception_chunk(struct dm_snapshot *s,
 		e->new_chunk++;
 	} else if (old_chunk != e->old_chunk +
 		   dm_consecutive_chunk_count(e)) {
-		DMERR("Attempt to merge block %llu from the "
-		      "middle of a chunk range [%llu - %llu]",
+		DMERR("Attempt to merge block %llu from the middle of a chunk range [%llu - %llu]",
 		      (unsigned long long)old_chunk,
 		      (unsigned long long)e->old_chunk,
 		      (unsigned long long)
@@ -980,8 +976,7 @@ static void snapshot_merge_next_chunks(struct dm_snapshot *s)
 						      &new_chunk);
 	if (linear_chunks <= 0) {
 		if (linear_chunks < 0) {
-			DMERR("Read error in exception store: "
-			      "shutting down merge");
+			DMERR("Read error in exception store: shutting down merge");
 			down_write(&s->lock);
 			s->merge_failed = 1;
 			up_write(&s->lock);
@@ -1877,12 +1872,10 @@ static int snapshot_preresume(struct dm_target *ti)
 	if (snap_src && snap_dest) {
 		down_read(&snap_src->lock);
 		if (s == snap_src) {
-			DMERR("Unable to resume snapshot source until "
-			      "handover completes.");
+			DMERR("Unable to resume snapshot source until handover completes.");
 			r = -EINVAL;
 		} else if (!dm_suspended(snap_src->ti)) {
-			DMERR("Unable to perform snapshot handover until "
-			      "source is suspended.");
+			DMERR("Unable to perform snapshot handover until source is suspended.");
 			r = -EINVAL;
 		}
 		up_read(&snap_src->lock);
Signature · 1 line
2.10.0
#1206 lore raw

PATCH 10/10 dm snapshot: Delete five unwanted spaces behind "list_for_each_entry"

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Thu, 29 Sep 2016 10:14:32 +0200

The script "checkpatch.pl" can point information out like the following.

WARNING: space prohibited between function name and open parenthesis '('

Thus fix the affected source code places.

---
 drivers/md/dm-snap.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/md/dm-snap.c +5 -5
index 7593986..1310652 100644
@@ -366,7 +366,7 @@ static struct origin *__lookup_origin(struct block_device *origin)
 	struct origin *o;
 
 	ol = &_origins[origin_hash(origin)];
-	list_for_each_entry (o, ol, hash_list)
+	list_for_each_entry(o, ol, hash_list)
 		if (bdev_equal(o->bdev, origin))
 			return o;
 
@@ -385,7 +385,7 @@ static struct dm_origin *__lookup_dm_origin(struct block_device *origin)
 	struct dm_origin *o;
 
 	ol = &_dm_origins[origin_hash(origin)];
-	list_for_each_entry (o, ol, hash_list)
+	list_for_each_entry(o, ol, hash_list)
 		if (bdev_equal(o->dev->bdev, origin))
 			return o;
 
@@ -625,7 +625,7 @@ static void dm_exception_table_exit(struct dm_exception_table *et,
 	for (i = 0; i < size; i++) {
 		slot = et->table + i;
 
-		list_for_each_entry_safe (ex, next, slot, hash_list)
+		list_for_each_entry_safe(ex, next, slot, hash_list)
 			kmem_cache_free(mem, ex);
 	}
 
@@ -653,7 +653,7 @@ static struct dm_exception *dm_lookup_exception(struct dm_exception_table *et,
 	struct dm_exception *e;
 
 	slot = &et->table[exception_hash(et, chunk)];
-	list_for_each_entry (e, slot, hash_list)
+	list_for_each_entry(e, slot, hash_list)
 		if (chunk >= e->old_chunk &&
 		    chunk <= e->old_chunk + dm_consecutive_chunk_count(e))
 			return e;
@@ -2068,7 +2068,7 @@ static int __origin_write(struct list_head *snapshots, sector_t sector,
 	chunk_t chunk;
 
 	/* Do all the snapshots on this origin */
-	list_for_each_entry (snap, snapshots, list) {
+	list_for_each_entry(snap, snapshots, list) {
 		/*
 		 * Don't make new exceptions in a merging snapshot
 		 * because it has effectively been deleted
Signature · 1 line
2.10.0
#1207 lore raw

cover md-cluster: Fine-tuning for ten function implementations

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 1 Oct 2016 16:38:17 +0200

Several update suggestions were taken into account from static source code analysis.

Markus Elfring (15):
Use kcalloc() in lock_all_bitmaps()
Improve another size determination in resync_info_update() Improve another size determination in join()
Improve another size determination in __sendmsg() Improve another size determination in recv_daemon() Rename a jump label in recv_daemon()
Improve another size determination in process_suspend_info() Improve determination of sizes in read_resync_info() Improve another size determination in lockres_init() Delete an unnecessary variable initialisation in lockres_init() Delete four error messages for a failed memory allocation Rename a jump label in area_resyncing()
Less function calls in join() after error detection Less function calls in lockres_init() after error detection Delete unnecessary braces in unlock_all_bitmaps()

 drivers/md/md-cluster.c | 114 ++++++++++++++++++++++++------------------------
 1 file changed, 56 insertions(+), 58 deletions(-)
Signature · 1 line
2.10.0
#1208 lore raw

PATCH 1/15 md-cluster: Use kcalloc() in lock_all_bitmaps()

From: Markus Elfring <[email protected]>
Date: Sat, 1 Oct 2016 11:18:40 +0200

* A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus reuse the corresponding function "kcalloc".

This issue was detected by using the Coccinelle software.

* Replace the specification of a data type by a pointer dereference to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/md/md-cluster.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/md/md-cluster.c +4 -3
index 2b13117..0000e3a 100644
@@ -1188,9 +1188,10 @@ static int lock_all_bitmaps(struct mddev *mddev)
 	char str[64];
 	struct md_cluster_info *cinfo = mddev->cluster_info;
 
-	cinfo->other_bitmap_lockres = kzalloc((mddev->bitmap_info.nodes - 1) *
-					     sizeof(struct dlm_lock_resource *),
-					     GFP_KERNEL);
+	cinfo->other_bitmap_lockres = kcalloc(mddev->bitmap_info.nodes - 1,
+					      sizeof(*cinfo
+						     ->other_bitmap_lockres),
+					      GFP_KERNEL);
 	if (!cinfo->other_bitmap_lockres) {
 		pr_err("md: can't alloc mem for other bitmap locks\n");
 		return 0;
Signature · 1 line
2.10.0
#1209 lore raw

PATCH 2/15 md-cluster: Improve another size determination in resync_info_update()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 1 Oct 2016 11:37:24 +0200

Replace the specification of a data structure by a variable name as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer.

---
 drivers/md/md-cluster.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/md-cluster.c +1 -1
index 0000e3a..c28f596 100644
@@ -1057,7 +1057,7 @@ static int resync_info_update(struct mddev *mddev, sector_t lo, sector_t hi)
 
 	/* do not send zero again, if we have sent before */
 	if (hi = 0) {
-		memcpy(&ri, cinfo->bitmap_lockres->lksb.sb_lvbptr, sizeof(struct resync_info));
+		memcpy(&ri, cinfo->bitmap_lockres->lksb.sb_lvbptr, sizeof(ri));
 		if (le64_to_cpu(ri.hi) = 0)
 			return 0;
 	}
Signature · 1 line
2.10.0
#1210 lore raw

PATCH 3/15 md-cluster: Improve another size determination in join()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 1 Oct 2016 11:42:47 +0200

Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/md/md-cluster.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/md-cluster.c +1 -1
index c28f596..7af27dd 100644
@@ -823,7 +823,7 @@ static int join(struct mddev *mddev, int nodes)
 	int ret, ops_rv;
 	char str[64];
 
-	cinfo = kzalloc(sizeof(struct md_cluster_info), GFP_KERNEL);
+	cinfo = kzalloc(sizeof(*cinfo), GFP_KERNEL);
 	if (!cinfo)
 		return -ENOMEM;
 
Signature · 1 line
2.10.0
#1211 lore raw

PATCH 4/15 md-cluster: Improve another size determination in __sendmsg()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 1 Oct 2016 12:21:48 +0200

Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/md/md-cluster.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/md-cluster.c +1 -1
index 7af27dd..c81eed4 100644
@@ -706,7 +706,7 @@ static int __sendmsg(struct md_cluster_info *cinfo, struct cluster_msg *cmsg)
 	}
 
 	memcpy(cinfo->message_lockres->lksb.sb_lvbptr, (void *)cmsg,
-			sizeof(struct cluster_msg));
+	       sizeof(*cmsg));
 	/*down-convert EX to CW on Message*/
 	error = dlm_lock_sync(cinfo->message_lockres, DLM_LOCK_CW);
 	if (error) {
Signature · 1 line
2.10.0
#1212 lore raw

PATCH 5/15 md-cluster: Improve another size determination in recv_daemon()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 1 Oct 2016 12:28:19 +0200

Replace the specification of a data structure by a variable name as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer.

---
 drivers/md/md-cluster.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/md-cluster.c +1 -1
index c81eed4..adf9555 100644
@@ -617,7 +617,7 @@ static void recv_daemon(struct md_thread *thread)
 	}
 
 	/* read lvb and wake up thread to process this message_lockres */
-	memcpy(&msg, message_lockres->lksb.sb_lvbptr, sizeof(struct cluster_msg));
+	memcpy(&msg, message_lockres->lksb.sb_lvbptr, sizeof(msg));
 	ret = process_recvd_msg(thread->mddev, &msg);
 	if (ret)
 		goto out;
Signature · 1 line
2.10.0
#1213 lore raw

PATCH 6/15 md-cluster: Rename a jump label in recv_daemon()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 1 Oct 2016 12:36:30 +0200

Adjust a jump label according to the Linux coding style convention.

---
 drivers/md/md-cluster.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/md/md-cluster.c +2 -2
index adf9555..94835b5 100644
@@ -620,7 +620,7 @@ static void recv_daemon(struct md_thread *thread)
 	memcpy(&msg, message_lockres->lksb.sb_lvbptr, sizeof(msg));
 	ret = process_recvd_msg(thread->mddev, &msg);
 	if (ret)
-		goto out;
+		goto unlock;
 
 	/*release CR on ack_lockres*/
 	ret = dlm_unlock_sync(ack_lockres);
@@ -634,7 +634,7 @@ static void recv_daemon(struct md_thread *thread)
 	ret = dlm_lock_sync(ack_lockres, DLM_LOCK_CR);
 	if (unlikely(ret != 0))
 		pr_info("lock CR on ack failed return %d\n", ret);
-out:
+unlock:
 	/*release CR on message_lockres*/
 	ret = dlm_unlock_sync(message_lockres);
 	if (unlikely(ret != 0))
Signature · 1 line
2.10.0
#1214 lore raw

PATCH 7/15 md-cluster: Improve another size determination in process_suspend_info()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 1 Oct 2016 12:42:50 +0200

Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/md/md-cluster.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/md/md-cluster.c +1 -2
index 94835b5..e965e78 100644
@@ -482,8 +482,7 @@ static void process_suspend_info(struct mddev *mddev,
 					lo, hi);
 	cinfo->sync_low = lo;
 	cinfo->sync_hi = hi;
-
-	s = kzalloc(sizeof(struct suspend_info), GFP_KERNEL);
+	s = kzalloc(sizeof(*s), GFP_KERNEL);
 	if (!s)
 		return;
 	s->slot = slot;
Signature · 1 line
2.10.0
#1215 lore raw

PATCH 8/15 md-cluster: Improve determination of sizes in read_resync_info()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 1 Oct 2016 12:52:58 +0200

Replace the specification of data structures by either a pointer dereference or a variable name as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/md/md-cluster.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/md/md-cluster.c +2 -2
index e965e78..0918108 100644
@@ -275,10 +275,10 @@ static struct suspend_info *read_resync_info(struct mddev *mddev, struct dlm_loc
 	sector_t hi = 0;
 
 	dlm_lock_sync(lockres, DLM_LOCK_CR);
-	memcpy(&ri, lockres->lksb.sb_lvbptr, sizeof(struct resync_info));
+	memcpy(&ri, lockres->lksb.sb_lvbptr, sizeof(ri));
 	hi = le64_to_cpu(ri.hi);
 	if (hi > 0) {
-		s = kzalloc(sizeof(struct suspend_info), GFP_KERNEL);
+		s = kzalloc(sizeof(*s), GFP_KERNEL);
 		if (!s)
 			goto out;
 		s->hi = hi;
Signature · 1 line
2.10.0
#1216 lore raw

PATCH 9/15 md-cluster: Improve another size determination in lockres_init()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 1 Oct 2016 13:02:18 +0200

Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention.

---
 drivers/md/md-cluster.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/md-cluster.c +1 -1
index 0918108..bec8035 100644
@@ -190,7 +190,7 @@ static struct dlm_lock_resource *lockres_init(struct mddev *mddev,
 	int ret, namelen;
 	struct md_cluster_info *cinfo = mddev->cluster_info;
 
-	res = kzalloc(sizeof(struct dlm_lock_resource), GFP_KERNEL);
+	res = kzalloc(sizeof(*res), GFP_KERNEL);
 	if (!res)
 		return NULL;
 	init_waitqueue_head(&res->sync_locking);
Signature · 1 line
2.10.0
#1217 lore raw

PATCH 10/15 md-cluster: Delete an unnecessary variable initialisation in lockres_init()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 1 Oct 2016 13:07:52 +0200

The local variable "res" will be set to an appropriate pointer a bit later. Thus omit the explicit initialisation at the beginning.

---
 drivers/md/md-cluster.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/md-cluster.c +1 -1
index bec8035..b91b552 100644
@@ -186,7 +186,7 @@ static int dlm_lock_sync_interruptible(struct dlm_lock_resource *res, int mode,
 static struct dlm_lock_resource *lockres_init(struct mddev *mddev,
 		char *name, void (*bastfn)(void *arg, int mode), int with_lvb)
 {
-	struct dlm_lock_resource *res = NULL;
+	struct dlm_lock_resource *res;
 	int ret, namelen;
 	struct md_cluster_info *cinfo = mddev->cluster_info;
 
Signature · 1 line
2.10.0
#1218 lore raw

PATCH 11/15 md-cluster: Delete four error messages for a failed memory allocation

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 1 Oct 2016 13:46:20 +0200

Omit extra messages for a memory allocation failure in three functions.

---
 drivers/md/md-cluster.c | 16 ++++------------
 1 file changed, 4 insertions(+), 12 deletions(-)
drivers/md/md-cluster.c +4 -12
index b91b552..7f82c6b 100644
@@ -200,17 +200,13 @@ static struct dlm_lock_resource *lockres_init(struct mddev *mddev,
 	res->mode = DLM_LOCK_IV;
 	namelen = strlen(name);
 	res->name = kzalloc(namelen + 1, GFP_KERNEL);
-	if (!res->name) {
-		pr_err("md-cluster: Unable to allocate resource name for resource %s\n", name);
+	if (!res->name)
 		goto out_err;
-	}
 	strlcpy(res->name, name, namelen + 1);
 	if (with_lvb) {
 		res->lksb.sb_lvbptr = kzalloc(LVB_SIZE, GFP_KERNEL);
-		if (!res->lksb.sb_lvbptr) {
-			pr_err("md-cluster: Unable to allocate LVB for resource %s\n", name);
+		if (!res->lksb.sb_lvbptr)
 			goto out_err;
-		}
 		res->flags = DLM_LKF_VALBLK;
 	}
 
@@ -852,10 +848,8 @@ static int join(struct mddev *mddev, int nodes)
 	/* Initiate the communication resources */
 	ret = -ENOMEM;
 	cinfo->recv_thread = md_register_thread(recv_daemon, mddev, "cluster_recv");
-	if (!cinfo->recv_thread) {
-		pr_err("md-cluster: cannot allocate memory for recv_thread!\n");
+	if (!cinfo->recv_thread)
 		goto err;
-	}
 	cinfo->message_lockres = lockres_init(mddev, "message", NULL, 1);
 	if (!cinfo->message_lockres)
 		goto err;
@@ -1191,10 +1185,8 @@ static int lock_all_bitmaps(struct mddev *mddev)
 					      sizeof(*cinfo
 						     ->other_bitmap_lockres),
 					      GFP_KERNEL);
-	if (!cinfo->other_bitmap_lockres) {
-		pr_err("md: can't alloc mem for other bitmap locks\n");
+	if (!cinfo->other_bitmap_lockres)
 		return 0;
-	}
 
 	my_slot = slot_number(mddev);
 	for (slot = 0; slot < mddev->bitmap_info.nodes; slot++) {
Signature · 1 line
2.10.0
#1219 lore raw

PATCH 12/15 md-cluster: Rename a jump label in area_resyncing()

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 1 Oct 2016 14:38:12 +0200

Adjust a jump label according to the Linux coding style convention

---
 drivers/md/md-cluster.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/md/md-cluster.c +2 -2
index 7f82c6b..e1ebcc4 100644
@@ -1085,13 +1085,13 @@ static int area_resyncing(struct mddev *mddev, int direction,
 
 	spin_lock_irq(&cinfo->suspend_lock);
 	if (list_empty(&cinfo->suspend_list))
-		goto out;
+		goto unlock;
 	list_for_each_entry(s, &cinfo->suspend_list, list)
 		if (hi > s->lo && lo < s->hi) {
 			ret = 1;
 			break;
 		}
-out:
+unlock:
 	spin_unlock_irq(&cinfo->suspend_lock);
 	return ret;
 }
Signature · 1 line
2.10.0
#1220 lore raw

PATCH 13/15 md-cluster: Less function calls in join() after error detection

In reply to SF Markus Elfring

From: Markus Elfring <[email protected]>
Date: Sat, 1 Oct 2016 15:40:32 +0200

A few resource release functions were called in some cases by the join() function during error handling
even if the passed data structure member contained a null pointer.

* Adjust jump targets according to the Linux coding style convention.

* Delete a repeated check which became unnecessary with this refactoring.

---
 drivers/md/md-cluster.c | 47 ++++++++++++++++++++++++++---------------------
 1 file changed, 26 insertions(+), 21 deletions(-)
drivers/md/md-cluster.c +26 -21
index e1ebcc4..36bb962 100644
@@ -837,39 +837,39 @@ static int join(struct mddev *mddev, int nodes)
 				DLM_LSFL_FS, LVB_SIZE,
 				&md_ls_ops, mddev, &ops_rv, &cinfo->lockspace);
 	if (ret)
-		goto err;
+		goto free_cluster_info;
 	wait_for_completion(&cinfo->completion);
 	if (nodes < cinfo->slot_number) {
 		pr_err("md-cluster: Slot allotted(%d) is greater than available slots(%d).",
 			cinfo->slot_number, nodes);
 		ret = -ERANGE;
-		goto err;
+		goto release_lockspace;
 	}
 	/* Initiate the communication resources */
 	ret = -ENOMEM;
 	cinfo->recv_thread = md_register_thread(recv_daemon, mddev, "cluster_recv");
 	if (!cinfo->recv_thread)
-		goto err;
+		goto release_lockspace;
 	cinfo->message_lockres = lockres_init(mddev, "message", NULL, 1);
 	if (!cinfo->message_lockres)
-		goto err;
+		goto unregister_recv;
 	cinfo->token_lockres = lockres_init(mddev, "token", NULL, 0);
 	if (!cinfo->token_lockres)
-		goto err;
+		goto free_message;
 	cinfo->no_new_dev_lockres = lockres_init(mddev, "no-new-dev", NULL, 0);
 	if (!cinfo->no_new_dev_lockres)
-		goto err;
+		goto free_token;
 
 	ret = dlm_lock_sync(cinfo->token_lockres, DLM_LOCK_EX);
 	if (ret) {
 		ret = -EAGAIN;
 		pr_err("md-cluster: can't join cluster to avoid lock issue\n");
-		goto err;
+		goto free_no_new_dev;
 	}
 	cinfo->ack_lockres = lockres_init(mddev, "ack", ack_bast, 0);
 	if (!cinfo->ack_lockres) {
 		ret = -ENOMEM;
-		goto err;
+		goto free_no_new_dev;
 	}
 	/* get sync CR lock on ACK. */
 	if (dlm_lock_sync(cinfo->ack_lockres, DLM_LOCK_CR))
@@ -886,34 +886,39 @@ static int join(struct mddev *mddev, int nodes)
 	cinfo->bitmap_lockres = lockres_init(mddev, str, NULL, 1);
 	if (!cinfo->bitmap_lockres) {
 		ret = -ENOMEM;
-		goto err;
+		goto free_ack;
 	}
 	if (dlm_lock_sync(cinfo->bitmap_lockres, DLM_LOCK_PW)) {
 		pr_err("Failed to get bitmap lock\n");
 		ret = -EINVAL;
-		goto err;
+		goto free_bitmap;
 	}
 
 	cinfo->resync_lockres = lockres_init(mddev, "resync", NULL, 0);
 	if (!cinfo->resync_lockres) {
 		ret = -ENOMEM;
-		goto err;
+		goto free_bitmap;
 	}
 
 	return 0;
-err:
-	md_unregister_thread(&cinfo->recovery_thread);
-	md_unregister_thread(&cinfo->recv_thread);
-	lockres_free(cinfo->message_lockres);
-	lockres_free(cinfo->token_lockres);
+free_bitmap:
+	lockres_free(cinfo->bitmap_lockres);
+free_ack:
 	lockres_free(cinfo->ack_lockres);
+free_no_new_dev:
 	lockres_free(cinfo->no_new_dev_lockres);
-	lockres_free(cinfo->resync_lockres);
-	lockres_free(cinfo->bitmap_lockres);
-	if (cinfo->lockspace)
-		dlm_release_lockspace(cinfo->lockspace, 2);
-	mddev->cluster_info = NULL;
+free_token:
+	lockres_free(cinfo->token_lockres);
+free_message:
+	lockres_free(cinfo->message_lockres);
+unregister_recv:
+	md_unregister_thread(&cinfo->recv_thread);
+release_lockspace:
+	dlm_release_lockspace(cinfo->lockspace, 2);
+free_cluster_info:
 	kfree(cinfo);
+	md_unregister_thread(&cinfo->recovery_thread);
+	mddev->cluster_info = NULL;
 	return ret;
 }
 
Signature · 1 line
2.10.0
#1221 lore raw

PATCH v2 13/15 md-cluster: Less function calls in join() after error detection

From: Markus Elfring <[email protected]>
Date: Thu, 6 Oct 2016 16:48:51 +0200

A few resource release functions were called in some cases by the join() function during error handling
even if the passed data structure member contained a null pointer.

* Adjust jump targets according to the Linux coding style convention.

* Delete a repeated check which became unnecessary with this refactoring.

---

v2: Julia Lawall wrote on 2016-10-01 at 19:07:

Quoted 43 lines

Please check lines 919 and 920.

julia

---------- Forwarded message ----------
Date: Sun, 2 Oct 2016 01:03:19 +0800
From: kbuild test robot <[email protected]>
To: [email protected]
Cc: Julia Lawall <[email protected]>
Subject:
[linux-review:SF-Markus-Elfring/md-cluster-Fine-tuning-for-ten-function-impl ementations/20161001-230311 13/15] drivers/md/md-cluster.c:920:23-28: ERROR:
reference preceded by free on line 919

CC: [email protected]
TO: Markus Elfring <[email protected]>
CC: 0day robot <[email protected]>

tree:   https://github.com/0day-ci/linux SF-Markus-Elfring/md-cluster-Fine-tuning-for-ten-function-implementations/20161001-230311
head:   7b2084c76eb1c60f2ae5c2778470124b5b68e9fb
commit: 6955234a0083a739f595e753e89ba7b5b3962f50 [13/15] md-cluster: Less function calls in join() after error detection

:::::: branch date: 2 hours ago
:::::: commit date: 2 hours ago

Quoted 1 line
Quoted 1 line

drivers/md/md-cluster.c:920:23-28: ERROR: reference preceded by free on line 919

git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 6955234a0083a739f595e753e89ba7b5b3962f50 vim +920 drivers/md/md-cluster.c

6955234a Markus Elfring    2016-10-01  913  	lockres_free(cinfo->message_lockres);
6955234a Markus Elfring    2016-10-01  914  unregister_recv:
6955234a Markus Elfring    2016-10-01  915  	md_unregister_thread(&cinfo->recv_thread);
6955234a Markus Elfring    2016-10-01  916  release_lockspace:
c4ce867f Goldwyn Rodrigues 2014-03-29  917  	dlm_release_lockspace(cinfo->lockspace, 2);
6955234a Markus Elfring    2016-10-01  918  free_cluster_info:
c4ce867f Goldwyn Rodrigues 2014-03-29 @919  	kfree(cinfo);
6955234a Markus Elfring    2016-10-01 @920  	md_unregister_thread(&cinfo->recovery_thread);
6955234a Markus Elfring    2016-10-01  921  	mddev->cluster_info = NULL;
c4ce867f Goldwyn Rodrigues 2014-03-29  922  	return ret;
edb39c9d Goldwyn Rodrigues 2014-03-29  923  }
Quoted 3 lines

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation

This automatic notification pointed out that I should have switched the order of calls for the functions "kfree" and "md_unregister_thread".
I hope that my second approach could be integrated into another source code repository.

 drivers/md/md-cluster.c | 47 ++++++++++++++++++++++++++---------------------
 1 file changed, 26 insertions(+), 21 deletions(-)
drivers/md/md-cluster.c +26 -21
index e1ebcc4..e60511a 100644
@@ -837,39 +837,39 @@ static int join(struct mddev *mddev, int nodes)
 				DLM_LSFL_FS, LVB_SIZE,
 				&md_ls_ops, mddev, &ops_rv, &cinfo->lockspace);
 	if (ret)
-		goto err;
+		goto unregister_recovery_thread;
 	wait_for_completion(&cinfo->completion);
 	if (nodes < cinfo->slot_number) {
 		pr_err("md-cluster: Slot allotted(%d) is greater than available slots(%d).",
 			cinfo->slot_number, nodes);
 		ret = -ERANGE;
-		goto err;
+		goto release_lockspace;
 	}
 	/* Initiate the communication resources */
 	ret = -ENOMEM;
 	cinfo->recv_thread = md_register_thread(recv_daemon, mddev, "cluster_recv");
 	if (!cinfo->recv_thread)
-		goto err;
+		goto release_lockspace;
 	cinfo->message_lockres = lockres_init(mddev, "message", NULL, 1);
 	if (!cinfo->message_lockres)
-		goto err;
+		goto unregister_recv;
 	cinfo->token_lockres = lockres_init(mddev, "token", NULL, 0);
 	if (!cinfo->token_lockres)
-		goto err;
+		goto free_message;
 	cinfo->no_new_dev_lockres = lockres_init(mddev, "no-new-dev", NULL, 0);
 	if (!cinfo->no_new_dev_lockres)
-		goto err;
+		goto free_token;
 
 	ret = dlm_lock_sync(cinfo->token_lockres, DLM_LOCK_EX);
 	if (ret) {
 		ret = -EAGAIN;
 		pr_err("md-cluster: can't join cluster to avoid lock issue\n");
-		goto err;
+		goto free_no_new_dev;
 	}
 	cinfo->ack_lockres = lockres_init(mddev, "ack", ack_bast, 0);
 	if (!cinfo->ack_lockres) {
 		ret = -ENOMEM;
-		goto err;
+		goto free_no_new_dev;
 	}
 	/* get sync CR lock on ACK. */
 	if (dlm_lock_sync(cinfo->ack_lockres, DLM_LOCK_CR))
@@ -886,34 +886,39 @@ static int join(struct mddev *mddev, int nodes)
 	cinfo->bitmap_lockres = lockres_init(mddev, str, NULL, 1);
 	if (!cinfo->bitmap_lockres) {
 		ret = -ENOMEM;
-		goto err;
+		goto free_ack;
 	}
 	if (dlm_lock_sync(cinfo->bitmap_lockres, DLM_LOCK_PW)) {
 		pr_err("Failed to get bitmap lock\n");
 		ret = -EINVAL;
-		goto err;
+		goto free_bitmap;
 	}
 
 	cinfo->resync_lockres = lockres_init(mddev, "resync", NULL, 0);
 	if (!cinfo->resync_lockres) {
 		ret = -ENOMEM;
-		goto err;
+		goto free_bitmap;
 	}
 
 	return 0;
-err:
-	md_unregister_thread(&cinfo->recovery_thread);
-	md_unregister_thread(&cinfo->recv_thread);
-	lockres_free(cinfo->message_lockres);
-	lockres_free(cinfo->token_lockres);
+free_bitmap:
+	lockres_free(cinfo->bitmap_lockres);
+free_ack:
 	lockres_free(cinfo->ack_lockres);
+free_no_new_dev:
 	lockres_free(cinfo->no_new_dev_lockres);
-	lockres_free(cinfo->resync_lockres);
-	lockres_free(cinfo->bitmap_lockres);
-	if (cinfo->lockspace)
-		dlm_release_lockspace(cinfo->lockspace, 2);
-	mddev->cluster_info = NULL;
+free_token:
+	lockres_free(cinfo->token_lockres);
+free_message:
+	lockres_free(cinfo->message_lockres);
+unregister_recv:
+	md_unregister_thread(&cinfo->recv_thread);
+release_lockspace:
+	dlm_release_lockspace(cinfo->lockspace, 2);
+unregister_recovery_thread:
+	md_unregister_thread(&cinfo->recovery_thread);
 	kfree(cinfo);
+	mddev->cluster_info = NULL;
 	return ret;
 }
 
Signature · 1 line
2.10.1