linux-kernel - [PATCH] pmem: don't allocate unused major device number

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <87k2lclif1.fsf@notabene.neil.brown.name>
Date:	Wed, 09 Mar 2016 09:21:54 +1100
From:	NeilBrown <neilb@...e.com>
To:	Dan Williams <dan.j.williams@...el.com>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	linux-nvdimm@...ts.01.org, linux-kernel@...r.kernel.org
Subject: [PATCH] pmem: don't allocate unused major device number

When alloc_disk(0) or alloc_disk-node(0, XX) is used, the ->major
number is completely ignored:  all devices are allocated with a
major of BLOCK_EXT_MAJOR.

So there is no point allocating pmem_major.

Signed-off-by: NeilBrown <neilb@...e.com>
---
 drivers/nvdimm/pmem.c | 19 +------------------
 1 file changed, 1 insertion(+), 18 deletions(-)

Hi Dan et al,
 I was recently educating myself about the behavior of alloc_disk(0).
 As I understand it, the ->major is ignored and all device numbers for all
 partitions (including '0') are allocated on demand with major number of
 BLOCK_EXT_MAJOR.

 So I was a little surprised to find that pmem.c allocated a major
 number which is never used - historical anomaly I suspect.
 I was a bit more surprised at the comment in:

  Commit: 9f53f9fa4ad1 ("libnvdimm, pmem: add libnvdimm support to the pmem driver")

 "The minor numbers are also more predictable by passing 0 to alloc_disk()."

 How can they possibly be more predictable given that they are allocated
 on-demand?  Maybe discovery order is very predictable???

 In any case, I propose this patch but cannot test it (beyond compiling)
 as I don't have relevant hardware.  And maybe some user-space code greps
 /proc/devices for "pmem" to determine if "pmem" is compiled in (though
 I sincerely hope not).
 So I cannot be certain that this patch won't break anything, but am
 hoping that if you like it you might test it.

 If it does prove acceptable, then similar changes would be appropriate
 for btt.c and blk.c.   And drivers/memstick/core/ms_block.c and
 drivers/nvme/host/core.c. (gotta stamp out this cargo cult)

 drivers/lightnvm/core.c is the only driver which uses alloc_disk(0) and
 doesn't provide a 'major' number. :-(

Thanks,
NeilBrown

diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 8d0b54670184..ec7e9e6a768e 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -47,8 +47,6 @@ struct pmem_device {
 	struct badblocks	bb;
 };

-static int pmem_major;
-
 static bool is_bad_pmem(struct badblocks *bb, sector_t sector, unsigned int len)
 {
 	if (bb->count) {
@@ -228,8 +226,6 @@ static int pmem_attach_disk(struct device *dev,
 		return -ENOMEM;
 	}

-	disk->major		= pmem_major;
-	disk->first_minor	= 0;
 	disk->fops		= &pmem_fops;
 	disk->private_data	= pmem;
 	disk->queue		= pmem->pmem_queue;
@@ -502,26 +498,13 @@ static struct nd_device_driver nd_pmem_driver = {

 static int __init pmem_init(void)
 {
-	int error;
-
-	pmem_major = register_blkdev(0, "pmem");
-	if (pmem_major < 0)
-		return pmem_major;
-
-	error = nd_driver_register(&nd_pmem_driver);
-	if (error) {
-		unregister_blkdev(pmem_major, "pmem");
-		return error;
-	}
-
-	return 0;
+	return nd_driver_register(&nd_pmem_driver);
 }
 module_init(pmem_init);

 static void pmem_exit(void)
 {
 	driver_unregister(&nd_pmem_driver.drv);
-	unregister_blkdev(pmem_major, "pmem");
 }
 module_exit(pmem_exit);

-- 
2.7.2

Download attachment "signature.asc" of type "application/pgp-signature" (819 bytes)