| Message ID | 1519731229-19141-1-git-send-email-harish_kandiga@mentor.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
在 2018/2/27 19:33, Harish Jenny K N 写道: > From: Andrew Gabbasov <andrew_gabbasov@mentor.com> > > Since RPMB area is accessible via special ioctl only and boot areas > are unlikely to contain any partitions, exclude them all from listing > in /proc/partitions. This will hide them from various user-level > software (e.g. fdisk), thus avoiding unnecessary access attempts. > > Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> > Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com> > --- > drivers/mmc/core/block.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c > index 20135a5..376e47e 100644 > --- a/drivers/mmc/core/block.c > +++ b/drivers/mmc/core/block.c > @@ -2341,7 +2341,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card, > set_disk_ro(md->disk, md->read_only || default_ro); > md->disk->flags = GENHD_FL_EXT_DEVT; > if (area_type & (MMC_BLK_DATA_AREA_RPMB | MMC_BLK_DATA_AREA_BOOT)) > - md->disk->flags |= GENHD_FL_NO_PART_SCAN; > + md->disk->flags |= GENHD_FL_NO_PART_SCAN > + | GENHD_FL_SUPPRESS_PARTITION_INFO; I would prefer using GENHD_FL_HIDDEN instead of adding all these two flags. > > /* > * As discussed on lkml, GENHD_FL_REMOVABLE should: >
V2hpbGUgUlBNQiBwYXJ0aXRpb24gcmVxdWlyZXMgc3BlY2lhbCBJT0NUTA0KDQpUaGFua3MsDQpB bGV4IA0K77u/T24gMi8yNy8xOCwgMTozNCBQTSwgImxpbnV4LW1tYy1vd25lckB2Z2VyLmtlcm5l bC5vcmcgb24gYmVoYWxmIG9mIEhhcmlzaCBKZW5ueSBLIE4iIDxsaW51eC1tbWMtb3duZXJAdmdl ci5rZXJuZWwub3JnIG9uIGJlaGFsZiBvZiBoYXJpc2hfa2FuZGlnYUBtZW50b3IuY29tPiB3cm90 ZToNCg0KICAgIEZyb206IEFuZHJldyBHYWJiYXNvdiA8YW5kcmV3X2dhYmJhc292QG1lbnRvci5j b20+DQogICAgDQogICAgU2luY2UgUlBNQiBhcmVhIGlzIGFjY2Vzc2libGUgdmlhIHNwZWNpYWwg aW9jdGwgb25seSBhbmQgYm9vdCBhcmVhcw0KICAgIGFyZSB1bmxpa2VseSB0byBjb250YWluIGFu eSBwYXJ0aXRpb25zLCBleGNsdWRlIHRoZW0gYWxsIGZyb20gbGlzdGluZw0KICAgIGluIC9wcm9j L3BhcnRpdGlvbnMuIFRoaXMgd2lsbCBoaWRlIHRoZW0gZnJvbSB2YXJpb3VzIHVzZXItbGV2ZWwN CiAgICBzb2Z0d2FyZSAoZS5nLiBmZGlzayksIHRodXMgYXZvaWRpbmcgdW5uZWNlc3NhcnkgYWNj ZXNzIGF0dGVtcHRzLg0KICAgIA0KICAgIFNpZ25lZC1vZmYtYnk6IEFuZHJldyBHYWJiYXNvdiA8 YW5kcmV3X2dhYmJhc292QG1lbnRvci5jb20+DQogICAgU2lnbmVkLW9mZi1ieTogSGFyaXNoIEpl bm55IEsgTiA8aGFyaXNoX2thbmRpZ2FAbWVudG9yLmNvbT4NCiAgICAtLS0NCiAgICAgZHJpdmVy cy9tbWMvY29yZS9ibG9jay5jIHwgMyArKy0NCiAgICAgMSBmaWxlIGNoYW5nZWQsIDIgaW5zZXJ0 aW9ucygrKSwgMSBkZWxldGlvbigtKQ0KICAgIA0KICAgIGRpZmYgLS1naXQgYS9kcml2ZXJzL21t Yy9jb3JlL2Jsb2NrLmMgYi9kcml2ZXJzL21tYy9jb3JlL2Jsb2NrLmMNCiAgICBpbmRleCAyMDEz NWE1Li4zNzZlNDdlIDEwMDY0NA0KICAgIC0tLSBhL2RyaXZlcnMvbW1jL2NvcmUvYmxvY2suYw0K ICAgICsrKyBiL2RyaXZlcnMvbW1jL2NvcmUvYmxvY2suYw0KICAgIEBAIC0yMzQxLDcgKzIzNDEs OCBAQCBzdGF0aWMgc3RydWN0IG1tY19ibGtfZGF0YSAqbW1jX2Jsa19hbGxvY19yZXEoc3RydWN0 IG1tY19jYXJkICpjYXJkLA0KICAgICAJc2V0X2Rpc2tfcm8obWQtPmRpc2ssIG1kLT5yZWFkX29u bHkgfHwgZGVmYXVsdF9ybyk7DQogICAgIAltZC0+ZGlzay0+ZmxhZ3MgPSBHRU5IRF9GTF9FWFRf REVWVDsNCiAgICAgCWlmIChhcmVhX3R5cGUgJiAoTU1DX0JMS19EQVRBX0FSRUFfUlBNQiB8IE1N Q19CTEtfREFUQV9BUkVBX0JPT1QpKQ0KICAgIC0JCW1kLT5kaXNrLT5mbGFncyB8PSBHRU5IRF9G TF9OT19QQVJUX1NDQU47DQogICAgKwkJbWQtPmRpc2stPmZsYWdzIHw9IEdFTkhEX0ZMX05PX1BB UlRfU0NBTg0KICAgICsJCQkJICAgfCBHRU5IRF9GTF9TVVBQUkVTU19QQVJUSVRJT05fSU5GTzsN CiAgICAgDQogICAgIAkvKg0KICAgICAJICogQXMgZGlzY3Vzc2VkIG9uIGxrbWwsIEdFTkhEX0ZM X1JFTU9WQUJMRSBzaG91bGQ6DQogICAgLS0gDQogICAgMS45LjENCiAgICANCiAgICAtLQ0KICAg IFRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmli ZSBsaW51eC1tbWMiIGluDQogICAgdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2 Z2VyLmtlcm5lbC5vcmcNCiAgICBNb3JlIG1ham9yZG9tbyBpbmZvIGF0ICBodHRwOi8vdmdlci5r ZXJuZWwub3JnL21ham9yZG9tby1pbmZvLmh0bWwNCiAgICANCg0K -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Andrew, While RPMB partition requires special IOCTL, the boot partition is only requires "switch partition", which is not unusual operation in eMMC. Why to prevent users access boot partition? Thanks, Alex On 2/27/18, 1:34 PM, "linux-mmc-owner@vger.kernel.org on behalf of Harish Jenny K N" <linux-mmc-owner@vger.kernel.org on behalf of harish_kandiga@mentor.com> wrote: From: Andrew Gabbasov <andrew_gabbasov@mentor.com> Since RPMB area is accessible via special ioctl only and boot areas are unlikely to contain any partitions, exclude them all from listing in /proc/partitions. This will hide them from various user-level software (e.g. fdisk), thus avoiding unnecessary access attempts. Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com> --- drivers/mmc/core/block.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index 20135a5..376e47e 100644 --- a/drivers/mmc/core/block.c +++ b/drivers/mmc/core/block.c @@ -2341,7 +2341,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card, set_disk_ro(md->disk, md->read_only || default_ro); md->disk->flags = GENHD_FL_EXT_DEVT; if (area_type & (MMC_BLK_DATA_AREA_RPMB | MMC_BLK_DATA_AREA_BOOT)) - md->disk->flags |= GENHD_FL_NO_PART_SCAN; + md->disk->flags |= GENHD_FL_NO_PART_SCAN + | GENHD_FL_SUPPRESS_PARTITION_INFO; /* * As discussed on lkml, GENHD_FL_REMOVABLE should: -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 27 February 2018 08:28 PM, Alex Lemberg wrote: > Hi Andrew, > > While RPMB partition requires special IOCTL, the boot partition is only requires "switch partition", which is not unusual operation in eMMC. > Why to prevent users access boot partition? > > Thanks, > Alex The main intention of the patch was to not have RPMB device in /proc/partitions. Boot partitions are also unlikely to have any partitioning, so it made sense to treat them the same way as RPMB and not list in /proc/partitions. Now I see that RPMB is converted to a character device and this change may not be required for RPMB. Correct me if I am wrong. Also any comments are welcome. Thanks, Harish Jenny K N -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 27, 2018 at 12:33 PM, Harish Jenny K N <harish_kandiga@mentor.com> wrote: > From: Andrew Gabbasov <andrew_gabbasov@mentor.com> > > Since RPMB area is accessible via special ioctl only and boot areas > are unlikely to contain any partitions, exclude them all from listing > in /proc/partitions. This will hide them from various user-level > software (e.g. fdisk), thus avoiding unnecessary access attempts. > > Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> > Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com> Makes sense to me, at least it makes the problem smaller not bigger. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > The main intention of the patch was to not have RPMB device in /proc/partitions. > Boot partitions are also unlikely to have any partitioning, so it made sense to > treat them the same way as RPMB and not list in /proc/partitions. > Now I see that RPMB is converted to a character device and this change > may not be required for RPMB. It certainly does not hurt, even if this code path is not called for the RPMB partition anymore (luckily). On a general note, I do not feel the work with boot partitions or the general purpose partitions is finished. In a lecture I pointed out that: dd if=/dev/sda of=sda.img Gives an image of the whole device, and you can restore the device by doing the inverse of that command. For MMC devices, dd if=/dev/mmcblk0 of=mmcblk0.img does NOT have the same nice property. Instead, since the special partitions are their own devices and not part of the main device, they have to be backed up separately. IMO this breaks the user contract of how a device vs a partition works. What we need to do is make the "special partitions" part of the main block device and stop spawning these special block devices for each boot partions or general partitions. In addition, each of these boot partitions or general partitions will get their own block queue and state container which is not cheap in runtime memory footprint terms. So what I want to do (unless someone beats me to it) it to come up with some way making boot and general partitions part of the main block device. Possibly the core kernel partitioning code needs to be augmented. The tentative idea is to just put the sectors representing these partitions after the main block device and access them from there, with an offset. That job isn't entirely trivial though. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 02 March 2018 06:23 PM, Linus Walleij wrote: > On Tue, Feb 27, 2018 at 12:33 PM, Harish Jenny K N > <harish_kandiga@mentor.com> wrote: > >> From: Andrew Gabbasov <andrew_gabbasov@mentor.com> >> >> Since RPMB area is accessible via special ioctl only and boot areas >> are unlikely to contain any partitions, exclude them all from listing >> in /proc/partitions. This will hide them from various user-level >> software (e.g. fdisk), thus avoiding unnecessary access attempts. >> >> Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> >> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com> > Makes sense to me, at least it makes the problem smaller not bigger. > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Any other comments/inputs on this ? Thanks, Harish Jenny K N -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SGkgTGludXMsDQoNCk9uIDMvMi8xOCA0OjUzIEFNLCBMaW51cyBXYWxsZWlqIHdyb3RlOg0KPiBP biBUdWUsIEZlYiAyNywgMjAxOCBhdCAxMjozMyBQTSwgSGFyaXNoIEplbm55IEsgTg0KPiA8aGFy aXNoX2thbmRpZ2FAbWVudG9yLmNvbT4gd3JvdGU6DQo+DQo+PiBGcm9tOiBBbmRyZXcgR2FiYmFz b3YgPGFuZHJld19nYWJiYXNvdkBtZW50b3IuY29tPg0KPj4NCj4+IFNpbmNlIFJQTUIgYXJlYSBp cyBhY2Nlc3NpYmxlIHZpYSBzcGVjaWFsIGlvY3RsIG9ubHkgYW5kIGJvb3QgYXJlYXMNCj4+IGFy ZSB1bmxpa2VseSB0byBjb250YWluIGFueSBwYXJ0aXRpb25zLCBleGNsdWRlIHRoZW0gYWxsIGZy b20gbGlzdGluZw0KPj4gaW4gL3Byb2MvcGFydGl0aW9ucy4gVGhpcyB3aWxsIGhpZGUgdGhlbSBm cm9tIHZhcmlvdXMgdXNlci1sZXZlbA0KPj4gc29mdHdhcmUgKGUuZy4gZmRpc2spLCB0aHVzIGF2 b2lkaW5nIHVubmVjZXNzYXJ5IGFjY2VzcyBhdHRlbXB0cy4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5 OiBBbmRyZXcgR2FiYmFzb3YgPGFuZHJld19nYWJiYXNvdkBtZW50b3IuY29tPg0KPj4gU2lnbmVk LW9mZi1ieTogSGFyaXNoIEplbm55IEsgTiA8aGFyaXNoX2thbmRpZ2FAbWVudG9yLmNvbT4NCj4g TWFrZXMgc2Vuc2UgdG8gbWUsIGF0IGxlYXN0IGl0IG1ha2VzIHRoZSBwcm9ibGVtIHNtYWxsZXIg bm90IGJpZ2dlci4NCj4gUmV2aWV3ZWQtYnk6IExpbnVzIFdhbGxlaWogPGxpbnVzLndhbGxlaWpA bGluYXJvLm9yZz4NCj4NCj4+IFRoZSBtYWluIGludGVudGlvbiBvZiB0aGUgcGF0Y2ggd2FzIHRv IG5vdCBoYXZlIFJQTUIgZGV2aWNlIGluIC9wcm9jL3BhcnRpdGlvbnMuDQo+PiBCb290IHBhcnRp dGlvbnMgYXJlIGFsc28gdW5saWtlbHkgdG8gaGF2ZSBhbnkgcGFydGl0aW9uaW5nLCBzbyBpdCBt YWRlIHNlbnNlIHRvDQo+PiB0cmVhdCB0aGVtIHRoZSBzYW1lIHdheSBhcyBSUE1CIGFuZCBub3Qg bGlzdCBpbiAvcHJvYy9wYXJ0aXRpb25zLg0KPj4gTm93IEkgc2VlIHRoYXQgUlBNQiBpcyBjb252 ZXJ0ZWQgdG8gYSBjaGFyYWN0ZXIgZGV2aWNlIGFuZCB0aGlzIGNoYW5nZQ0KPj4gbWF5IG5vdCBi ZSByZXF1aXJlZCBmb3IgUlBNQi4NCj4gSXQgY2VydGFpbmx5IGRvZXMgbm90IGh1cnQsIGV2ZW4g aWYgdGhpcyBjb2RlIHBhdGggaXMgbm90IGNhbGxlZA0KPiBmb3IgdGhlIFJQTUIgcGFydGl0aW9u IGFueW1vcmUgKGx1Y2tpbHkpLg0KPg0KPiBPbiBhIGdlbmVyYWwgbm90ZSwgSSBkbyBub3QgZmVl bCB0aGUgd29yayB3aXRoIGJvb3QgcGFydGl0aW9ucyBvcg0KPiB0aGUgZ2VuZXJhbCBwdXJwb3Nl IHBhcnRpdGlvbnMgaXMgZmluaXNoZWQuDQo+DQo+IEluIGEgbGVjdHVyZSBJIHBvaW50ZWQgb3V0 IHRoYXQ6DQo+DQo+IGRkIGlmPS9kZXYvc2RhIG9mPXNkYS5pbWcNCj4NCj4gR2l2ZXMgYW4gaW1h Z2Ugb2YgdGhlIHdob2xlIGRldmljZSwgYW5kIHlvdSBjYW4gcmVzdG9yZSB0aGUNCj4gZGV2aWNl IGJ5IGRvaW5nIHRoZSBpbnZlcnNlIG9mIHRoYXQgY29tbWFuZC4NCj4NCj4gRm9yIE1NQyBkZXZp Y2VzLA0KPg0KPiBkZCBpZj0vZGV2L21tY2JsazAgb2Y9bW1jYmxrMC5pbWcNCj4NCj4gZG9lcyBO T1QgaGF2ZSB0aGUgc2FtZSBuaWNlIHByb3BlcnR5LiBJbnN0ZWFkLCBzaW5jZSB0aGUNCj4gc3Bl Y2lhbCBwYXJ0aXRpb25zIGFyZSB0aGVpciBvd24gZGV2aWNlcyBhbmQgbm90IHBhcnQgb2YgdGhl IG1haW4NCj4gZGV2aWNlLCB0aGV5IGhhdmUgdG8gYmUgYmFja2VkIHVwIHNlcGFyYXRlbHkuDQo+ DQo+IElNTyB0aGlzIGJyZWFrcyB0aGUgdXNlciBjb250cmFjdCBvZiBob3cgYSBkZXZpY2UgdnMg YSBwYXJ0aXRpb24NCj4gd29ya3MuDQo+DQo+IFdoYXQgd2UgbmVlZCB0byBkbyBpcyBtYWtlIHRo ZSAic3BlY2lhbCBwYXJ0aXRpb25zIiBwYXJ0IG9mIHRoZQ0KPiBtYWluIGJsb2NrIGRldmljZSBh bmQgc3RvcCBzcGF3bmluZyB0aGVzZSBzcGVjaWFsIGJsb2NrDQo+IGRldmljZXMgZm9yIGVhY2gg Ym9vdCBwYXJ0aW9ucyBvciBnZW5lcmFsIHBhcnRpdGlvbnMuIEluIGFkZGl0aW9uLA0KPiBlYWNo IG9mIHRoZXNlIGJvb3QgcGFydGl0aW9ucyBvciBnZW5lcmFsIHBhcnRpdGlvbnMgd2lsbCBnZXQg dGhlaXINCj4gb3duIGJsb2NrIHF1ZXVlIGFuZCBzdGF0ZSBjb250YWluZXIgd2hpY2ggaXMgbm90 IGNoZWFwIGluDQo+IHJ1bnRpbWUgbWVtb3J5IGZvb3RwcmludCB0ZXJtcy4NCj4NCj4gU28gd2hh dCBJIHdhbnQgdG8gZG8gKHVubGVzcyBzb21lb25lIGJlYXRzIG1lIHRvIGl0KSBpdCB0byBjb21l DQo+IHVwIHdpdGggc29tZSB3YXkgbWFraW5nIGJvb3QgYW5kIGdlbmVyYWwgcGFydGl0aW9ucyBw YXJ0DQo+IG9mIHRoZSBtYWluIGJsb2NrIGRldmljZS4gUG9zc2libHkgdGhlIGNvcmUga2VybmVs IHBhcnRpdGlvbmluZw0KPiBjb2RlIG5lZWRzIHRvIGJlIGF1Z21lbnRlZC4gVGhlIHRlbnRhdGl2 ZSBpZGVhIGlzIHRvIGp1c3QNCj4gcHV0IHRoZSBzZWN0b3JzIHJlcHJlc2VudGluZyB0aGVzZSBw YXJ0aXRpb25zIGFmdGVyIHRoZSBtYWluDQo+IGJsb2NrIGRldmljZSBhbmQgYWNjZXNzIHRoZW0g ZnJvbSB0aGVyZSwgd2l0aCBhbiBvZmZzZXQuDQpJIGRvbid0IHRoaW5rIHRoYXQgaGlkaW5nIHRo ZSBCb290IGFuZCBSUE1CIHdpbGwgcmVzb2x2ZSB0aGUgcHJvYmxlbQ0KZGVzY3JpYmVkIGFib3Zl Lg0KQm9vdCBwYXJ0aXRpb24gKHNhbWUgYXMgUlBNQikgaW4gZU1NQyBkZXZpY2UgaXMgYSBzZXBh cmF0ZQ0KInBoeXNpY2FsIiBwYXJ0aXRpb24uDQpJdCBoYXMgaXRzIG93biBsb2dpY2FsIGFkZHJl c3MgcmFuZ2UgYW5kIGRpZmZlcmVudCBmcm9tIGdlbmVyYWwNCnBhcnRpdGlvbiBjaGFyYWN0ZXJp c3RpY3MuDQpGcm9tIHRoZSBwcm90b2NvbCAtIHRoZSBhY2Nlc3MgdG8gdGhpcyBwYXJ0aXRpb24g aXQgcmVxdWlyZXMgc3dpdGNoDQpwYXJ0aXRpb24gY29tbWFuZC4gSXQgY2FuIGJlIGFjY2Vzc2Vz IGR1cmluZyB0aGUgYm9vdCBzZXF1ZW5jZQ0KYmVmb3JlIHRoZSBnZW5lcmFsL3VzZXJkYXRhIHBh cnRpdGlvbiBpcyBtb3VudGVkLg0KRnJvbSB0aGUgZGV2aWNlIHNpZGUgLSBpdCBjYW4gYmUgbWFu YWdlZCBpbiB0b3RhbGx5IGRpZmZlcmVudCBtYW5uZXINCihTTEMgdnMuIE1MQyBibG9ja3MsIGV0 Yy4pDQpJIHRoaW5rIGl0IGNvbXBsZXRlbHkgbWFrZXMgc2Vuc2UgdG8gYWxsb3cgYWNjZXNzIHRv IEJvb3QgcGFydGl0aW9uIGZyb20gdGhlDQp1c2VyIHNwYWNlLiBGb3IgZXhhbXBsZSAtIHRvIGFs bG93IFIvVyB0aGUgYm9vdCBpbWFnZS4NCg0KQUZBSUssIGluIGNhc2Ugb2YgU0NTSS9VRlMgZGV2 aWNlcyAtIEJvb3QgTFVOJ3MgYXJlIHJlcHJlc2VudGVkIGFzDQpzZXBhcmF0ZSBibG9jaw0KZGV2 aWNlIHBhcnRpdGlvbnMgKC9kZXYvc2RiLCBkZXYvc2RjLi4uKS4NClNob3VsZG4ndCB3ZSBoYXZl IHRoZSBzYW1lIGZvciBlTU1DPw0KDQo+IFRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBz ZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsaW51eC1tbWMiIGluDQo+IHRoZSBib2R5IG9mIGEg bWVzc2FnZSB0byBtYWpvcmRvbW9Admdlci5rZXJuZWwub3JnDQo+IE1vcmUgbWFqb3Jkb21vIGlu Zm8gYXQgIGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbA0K -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 8, 2018 at 9:36 PM, Alex Lemberg <Alex.Lemberg@wdc.com> wrote: > On 3/2/18 4:53 AM, Linus Walleij wrote: >> What we need to do is make the "special partitions" part of the >> main block device and stop spawning these special block >> devices for each boot partions or general partitions. In addition, >> each of these boot partitions or general partitions will get their >> own block queue and state container which is not cheap in >> runtime memory footprint terms. >> >> So what I want to do (unless someone beats me to it) it to come >> up with some way making boot and general partitions part >> of the main block device. Possibly the core kernel partitioning >> code needs to be augmented. The tentative idea is to just >> put the sectors representing these partitions after the main >> block device and access them from there, with an offset. > > I don't think that hiding the Boot and RPMB will resolve the problem > described above. Me neither. I'm just trying to discuss the problem lurking behind these partitions. > Boot partition (same as RPMB) in eMMC device is a separate > "physical" partition. > It has its own logical address range and different from general > partition characteristics. Yep. > From the protocol - the access to this partition it requires switch > partition command. Yeah I saw that as well... it's a bit funny. > From the device side - it can be managed in totally different manner > (SLC vs. MLC blocks, etc.) > I think it completely makes sense to allow access to Boot partition from the > user space. For example - to allow R/W the boot image. But this patch doesn't hide the partition from userspace does it? They will still appear in /dev/mmcblk0boot1 etc. Just not reported as "real" partitions in /proc/partitions. Or do I misunderstand it? > AFAIK, in case of SCSI/UFS devices - Boot LUN's are represented as > separate block > device partitions (/dev/sdb, dev/sdc...). > Shouldn't we have the same for eMMC? I think we should, but we have the problem with the boot partitions and general partitions that they do not work anything like SCSCI LUNs. On a SCSI device dd from the whole device will copy all data on the device, the partition table and contents of all partitions. For say /dev/mmcblk0 this is not true of the device contains boot or general partitions, those other partitions will not be copied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 10 March 2018 05:29 PM, Linus Walleij wrote: > > But this patch doesn't hide the partition from userspace does it? > > They will still appear in /dev/mmcblk0boot1 etc. > > Just not reported as "real" partitions in /proc/partitions. > > Or do I misunderstand it? > > You are correct. This patch does not hide partition from userspace. They will still appear in /dev/. But not reported as "real" partitions in /proc/partiotions. Thanks, Harish Jenny K N -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday 12 March 2018 10:14 AM, Harish Jenny K N wrote: > > On Saturday 10 March 2018 05:29 PM, Linus Walleij wrote: >> But this patch doesn't hide the partition from userspace does it? >> >> They will still appear in /dev/mmcblk0boot1 etc. >> >> Just not reported as "real" partitions in /proc/partitions. >> >> Or do I misunderstand it? >> >> > You are correct. This patch does not hide partition from userspace. > They will still appear in /dev/. But not reported as "real" partitions in /proc/partiotions. > > Thanks, > Harish Jenny K N Any other comments/inputs on this ? Thanks, Harish Jenny K N -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 27 February 2018 at 12:33, Harish Jenny K N <harish_kandiga@mentor.com> wrote: > From: Andrew Gabbasov <andrew_gabbasov@mentor.com> > > Since RPMB area is accessible via special ioctl only and boot areas > are unlikely to contain any partitions, exclude them all from listing > in /proc/partitions. This will hide them from various user-level > software (e.g. fdisk), thus avoiding unnecessary access attempts. > > Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> > Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com> Queued up for 3.18, thanks! Kind regards Uffe > --- > drivers/mmc/core/block.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c > index 20135a5..376e47e 100644 > --- a/drivers/mmc/core/block.c > +++ b/drivers/mmc/core/block.c > @@ -2341,7 +2341,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card, > set_disk_ro(md->disk, md->read_only || default_ro); > md->disk->flags = GENHD_FL_EXT_DEVT; > if (area_type & (MMC_BLK_DATA_AREA_RPMB | MMC_BLK_DATA_AREA_BOOT)) > - md->disk->flags |= GENHD_FL_NO_PART_SCAN; > + md->disk->flags |= GENHD_FL_NO_PART_SCAN > + | GENHD_FL_SUPPRESS_PARTITION_INFO; > > /* > * As discussed on lkml, GENHD_FL_REMOVABLE should: > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index 20135a5..376e47e 100644 --- a/drivers/mmc/core/block.c +++ b/drivers/mmc/core/block.c @@ -2341,7 +2341,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card, set_disk_ro(md->disk, md->read_only || default_ro); md->disk->flags = GENHD_FL_EXT_DEVT; if (area_type & (MMC_BLK_DATA_AREA_RPMB | MMC_BLK_DATA_AREA_BOOT)) - md->disk->flags |= GENHD_FL_NO_PART_SCAN; + md->disk->flags |= GENHD_FL_NO_PART_SCAN + | GENHD_FL_SUPPRESS_PARTITION_INFO; /* * As discussed on lkml, GENHD_FL_REMOVABLE should: