Received: by 10.223.185.116 with SMTP id b49csp8758197wrg; Fri, 2 Mar 2018 07:28:10 -0800 (PST) X-Google-Smtp-Source: AG47ELtBYwC7kl0RYQzpIGbClY7Gg9+1wAcUjI50C9LhZWPIdxg54R5Qqbr76tv403GDMjsbWGqL X-Received: by 10.99.120.201 with SMTP id t192mr4820445pgc.39.1520004490743; Fri, 02 Mar 2018 07:28:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520004490; cv=none; d=google.com; s=arc-20160816; b=OsHWZdm+vQ6T/peEtpjFKRp+6tUVgs78YyqVb/yOwE8TW9RkKUYY0jlx3LSqDnmZBE /iowt7n4JpC27eh1aHbmavRfZgpBBiA4QgNmEqNxoofMJLH62eWd73uW0Us3gmzisnj5 CaMzPpe/4hbFM9e6mCSrxu2PSOGfcws5Yr/2RfenGjMme+7ngi2cSGRnXM11PBxem/KY fJ3+V9hNZacOjbCNdl26WTnQD/BdS8IK30B/8+nKdAs7OneVRKXXWpOrVTUEOgNlLpEo /GYpqU3+eET9OVstqGAuxuB5v6GiwGvHRABmkpBPO//kHPRf+UQa9KzRnI7HiXl65A96 JXJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=QC/CgT7/RWhJtTTxTnjmIWRpwyZTVoMUEWDq0XxULsc=; b=aTkIvs51lpYH9rqCLStdPWy+BrzAe1ehe0NeNB40bDgJ2nW/yfszhyKzYzjNnjQlRr AmePy0bsgayGAy/jvuaRW6Z2sDAYKa1zxnEPMDDNYUB5hUwuu2zH6U3+aO8ndNsYHHtR ma44qreTsfK+Ucqaxv4zKics1nMHLk4+9AGxRJd+idh5hrtzCFIQ3LZEpF0hx2dAZdYM YCDjbNWYN3vTNAztiMR4dMG8A9n7DK4fOzmDTTLfVDdOgOO0X2d1wcA++IO709UjpJMb 4AcnXnTcojVvJlbxGSfz0JrftRo8tyhzv2gfzJUHVgQ72ZdB46WPxdRdDi/povulVUxh P91Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=ApXPnK9F; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q22si5078419pfj.50.2018.03.02.07.27.56; Fri, 02 Mar 2018 07:28:10 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=ApXPnK9F; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1427888AbeCBMxS (ORCPT + 99 others); Fri, 2 Mar 2018 07:53:18 -0500 Received: from mail-it0-f66.google.com ([209.85.214.66]:52141 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423162AbeCBMxP (ORCPT ); Fri, 2 Mar 2018 07:53:15 -0500 Received: by mail-it0-f66.google.com with SMTP id u66so1595270ith.1 for ; Fri, 02 Mar 2018 04:53:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QC/CgT7/RWhJtTTxTnjmIWRpwyZTVoMUEWDq0XxULsc=; b=ApXPnK9Fr3b2YhBtQv5F6R+CnXu8hlsg4Pmq+l2ye4aQIPwHy9fwr3jPwEogpUYhmJ x5Ng2mE5zXgcDIe01mu3XUvffzY8PE/LokzfybuIfs+i8EgiFTZSWc1eGv0PSASQGGeP RtvoqHRaRiSl3xvN3Sx55IskF5oXTFyOxwbUo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QC/CgT7/RWhJtTTxTnjmIWRpwyZTVoMUEWDq0XxULsc=; b=NMDHBOWlS2yrroIQuZpu8hib1qdsfY9alPUZxwVbf59MPUJWK6vjvJvyz4RFRgur9j kl8SuLfJAD2g0lpzUH8Ig9q+Wdyqfa7PDjPwGtW1OJGuPAw2lv4LWeNnFzWBPB5+icvA V5KWGTFAdxE7m3bekSC7vtxq/nZrZIAuPNE6NOxdRDXHjpuZbRmsW+y8KgOqNtz0NImF ZFBLdOFF34cOBfOFzMLwteKAIlAlRvIz5Dd3DzlhKAgwGiapFboXaKjNTu2Sz3Son2Gu opVmp/bRlogH0o1DUDITBPyM/TOJqHGDXu7ISkvJXPZicw4ozWO/LNA8MwzJD3TAXwz1 Kadg== X-Gm-Message-State: AElRT7HxCPT42sE9ywfrC27YVvtLkmyL/Y2MXDU2KmA4ntYtnAQcEw1f Znc22sDPTajol4tWAjzd8rzlLdwxH1RpZCfn6D73Ig== X-Received: by 10.36.104.1 with SMTP id v1mr2251084itb.70.1519995195309; Fri, 02 Mar 2018 04:53:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.230.25 with HTTP; Fri, 2 Mar 2018 04:53:14 -0800 (PST) In-Reply-To: <1519731229-19141-1-git-send-email-harish_kandiga@mentor.com> References: <1519731229-19141-1-git-send-email-harish_kandiga@mentor.com> From: Linus Walleij Date: Fri, 2 Mar 2018 13:53:14 +0100 Message-ID: Subject: Re: [PATCH] mmc: card: Don't show eMMC RPMB and BOOT areas in /proc/partitions To: Harish Jenny K N Cc: Ulf Hansson , Adrian Hunter , Shawn Lin , linux-mmc , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 27, 2018 at 12:33 PM, Harish Jenny K N wrote: > From: Andrew Gabbasov > > 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 > Signed-off-by: Harish Jenny K N Makes sense to me, at least it makes the problem smaller not bigger. Reviewed-by: Linus Walleij > 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