From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Boaz Harrosh <boaz@plexistor.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, Matthew Wilcox <willy@linux.intel.com>,
Sagi Manole <sagi@plexistor.com>,
Yigal Korman <yigal@plexistor.com>
Subject: Re: [PATCH 5/9 v2] SQUASHME: prd: Last fixes for partitions
Date: Mon, 25 Aug 2014 14:10:03 -0600 [thread overview]
Message-ID: <1408997403.17731.7.camel@rzwisler-mobl1.amr.corp.intel.com> (raw)
In-Reply-To: <53ECB480.4060104@plexistor.com>
On Thu, 2014-08-14 at 16:07 +0300, Boaz Harrosh wrote:
> From: Boaz Harrosh <boaz@plexistor.com>
>
> This streamlines prd with the latest brd code.
>
> In prd we do not allocate new devices dynamically on devnod
> access, because we need parameterization of each device. So
> the dynamic allocation in prd_init_one is removed.
>
> Therefor prd_init_one only called from prd_prob is moved
> there, now that it is small.
>
> And other small fixes regarding partitions
>
> Signed-off-by: Boaz Harrosh <boaz@plexistor.com>
> ---
> drivers/block/prd.c | 47 ++++++++++++++++++++++++-----------------------
> 1 file changed, 24 insertions(+), 23 deletions(-)
<snip>
> @@ -333,16 +321,27 @@ static void prd_del_one(struct prd_device *prd)
> prd_free(prd);
> }
>
> +/*FIXME: Actually in our driver prd_probe is never used. Can be removed */
> static struct kobject *prd_probe(dev_t dev, int *part, void *data)
> {
> struct prd_device *prd;
> struct kobject *kobj;
> + int number = MINOR(dev);
Unfortunately I think this is broken, and it was broken in the previous
version of prd_probe() as well.
When we were allocating minors from our own device we could rely on the fact
that there was a relationship between the minor number of the device and the
prd_number. Now that we're using the dynamic minors scheme, our minor is
dependent on other drivers that are also using that same scheme. For example,
when both PRD and BRD are using dynamic minors:
# ls -la /dev/ram* /dev/pmem*
brw-rw---- 1 root disk 259, 4 Aug 25 12:38 /dev/pmem0
brw-rw---- 1 root disk 259, 5 Aug 25 12:38 /dev/pmem1
brw-rw---- 1 root disk 259, 6 Aug 25 12:38 /dev/pmem2
brw-rw---- 1 root disk 259, 7 Aug 25 12:38 /dev/pmem3
brw-rw---- 1 root disk 259, 0 Aug 25 12:22 /dev/ram0
brw-rw---- 1 root disk 259, 1 Aug 25 12:22 /dev/ram1
brw-rw---- 1 root disk 259, 2 Aug 25 12:22 /dev/ram2
brw-rw---- 1 root disk 259, 3 Aug 25 12:22 /dev/ram3
pmem0 has prd_number 0, but has minor 4.
I think we can still have a working probe by instead comparing the passed in
dev_t against the dev_t we get back from disk_to_dev(prd->prd_disk), but I'd
really like a use case so I can test this. Until then I think I'm just going
to stub out prd/pmem_probe() with a BUG() so we can see if anyone hits it.
It seems like this is preferable to just registering NULL for probe, as that
would cause an oops in kobj_lookup(() when probe() is blindly called without
checking for NULL.
- Ross
>
> mutex_lock(&prd_devices_mutex);
> - prd = prd_init_one(MINOR(dev));
> - kobj = prd ? get_disk(prd->prd_disk) : NULL;
> - mutex_unlock(&prd_devices_mutex);
>
> + list_for_each_entry(prd, &prd_devices, prd_list) {
> + if (prd->prd_number == number) {
> + kobj = get_disk(prd->prd_disk);
> + goto out;
> + }
> + }
> +
> + pr_err("prd: prd_probe: Unexpected parameter=%d\n", number);
> + kobj = NULL;
> +
> +out:
> + mutex_unlock(&prd_devices_mutex);
> return kobj;
> }
>
> @@ -424,5 +423,7 @@ static void __exit prd_exit(void)
>
> MODULE_AUTHOR("Ross Zwisler <ross.zwisler@linux.intel.com>");
> MODULE_LICENSE("GPL");
> +MODULE_ALIAS("pmem");
> +
> module_init(prd_init);
> module_exit(prd_exit);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-08-25 20:10 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-13 12:08 [RFC 0/9] pmem: Support for "struct page" with Persistent Memory storage Boaz Harrosh
2014-08-13 12:10 ` [RFC 1/9] prd: Initial version of Persistent RAM Driver Boaz Harrosh
2014-08-13 12:11 ` [RFC 2/9] prd: add support for rw_page() Boaz Harrosh
2014-08-13 12:12 ` [RFC 3/9] prd: Add getgeo to block ops Boaz Harrosh
2014-08-13 12:14 ` [RFC 4/9] SQUASHME: prd: Fixs to getgeo Boaz Harrosh
2014-08-20 22:10 ` Ross Zwisler
2014-08-21 9:47 ` Boaz Harrosh
2014-08-13 12:16 ` [RFC 5/9] SQUASHME: prd: Last fixes for partitions Boaz Harrosh
2014-08-14 13:04 ` Boaz Harrosh
2014-08-14 13:16 ` Matthew Wilcox
2014-08-14 13:55 ` Boaz Harrosh
2014-08-14 13:07 ` [PATCH 5/9 v2] " Boaz Harrosh
2014-08-25 20:10 ` Ross Zwisler [this message]
2014-08-26 8:18 ` Boaz Harrosh
2014-08-26 17:36 ` Boaz Harrosh
2014-08-26 20:34 ` Ross Zwisler
2014-08-27 4:38 ` Matthew Wilcox
2014-08-20 23:03 ` [RFC 5/9] " Ross Zwisler
2014-08-21 10:05 ` Boaz Harrosh
2014-08-13 12:18 ` [RFC 6/9] SQUASHME: prd: Let each prd-device manage private memory region Boaz Harrosh
2014-08-21 16:57 ` Ross Zwisler
2014-08-13 12:20 ` [RFC 7/9] SQUASHME: prd: Support of multiple memory regions Boaz Harrosh
2014-08-25 23:02 ` Ross Zwisler
2014-08-13 12:21 ` [RFC 8/9] mm: export sparse_add/remove_one_section Boaz Harrosh
2014-08-13 12:26 ` [RFC 9/9] prd: Add support for page struct mapping Boaz Harrosh
2014-08-15 20:28 ` Toshi Kani
2014-08-17 9:17 ` Boaz Harrosh
2014-08-18 19:48 ` Toshi Kani
2014-08-19 8:40 ` Boaz Harrosh
2014-08-19 16:49 ` Toshi Kani
2014-08-22 14:36 ` Dave Hansen
2014-09-09 16:16 ` Boaz Harrosh
2014-09-09 16:29 ` Dave Hansen
2014-08-20 20:13 ` [RFC 0/9] pmem: Support for "struct page" with Persistent Memory storage Ross Zwisler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1408997403.17731.7.camel@rzwisler-mobl1.amr.corp.intel.com \
--to=ross.zwisler@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=boaz@plexistor.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sagi@plexistor.com \
--cc=willy@linux.intel.com \
--cc=yigal@plexistor.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox