Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 1 Feb 2021 13:08:49 -0500
From:   Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To:     Ben Widawsky <ben.widawsky@intel.com>
Cc:     linux-cxl@vger.kernel.org, linux-acpi@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org,
        linux-pci@vger.kernel.org, Bjorn Helgaas <helgaas@kernel.org>,
        Chris Browy <cbrowy@avery-design.com>,
        Christoph Hellwig <hch@infradead.org>,
        Dan Williams <dan.j.williams@intel.com>,
        Ira Weiny <ira.weiny@intel.com>,
        Jon Masters <jcm@jonmasters.org>,
        Jonathan Cameron <Jonathan.Cameron@huawei.com>,
        Rafael Wysocki <rafael.j.wysocki@intel.com>,
        Randy Dunlap <rdunlap@infradead.org>,
        Vishal Verma <vishal.l.verma@intel.com>,
        daniel.lll@alibaba-inc.com,
        "John Groves (jgroves)" <jgroves@micron.com>,
        "Kelley, Sean V" <sean.v.kelley@intel.com>
Subject: Re: [PATCH 03/14] cxl/mem: Find device capabilities
Message-ID: <20210201180849.GH197521@fedora>
References: <20210130002438.1872527-1-ben.widawsky@intel.com>
 <20210130002438.1872527-4-ben.widawsky@intel.com>
 <20210201174136.GF197521@fedora>
 <20210201175041.qs56jk5tdbgn2zia@intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210201175041.qs56jk5tdbgn2zia@intel.com>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from fedora (209.6.208.110) by BLAPR03CA0142.namprd03.prod.outlook.com (2603:10b6:208:32e::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.16 via Frontend Transport; Mon, 1 Feb 2021 18:08:52 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e0f83a44-2a89-47e6-2e31-08d8c6dc6fbd
X-MS-TrafficTypeDiagnostic: BY5PR10MB4065:
X-Microsoft-Antispam-PRVS: <BY5PR10MB4065514211173C674699F33D89B69@BY5PR10MB4065.namprd10.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:226;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: i50V+nq6f0Ni2pwtijrSjRoihSoVacMbjVsSB2eSJzYk2X9tr28wU3WMEwdPdt/mSWkXar+YJJsIlUf3FRV1/aAEB/FUTVSDZAWsgq+STd0ZeJgS7PVrxZpKDBnBUdd0GBM1RH8KXUroW0LRYdZ5sdAoKqbC5k0AXV6uiW8hmUB0W+SbiU2HyWvxljVuddCaWi2dFZY1y4h3dNmTEcxcplwQIGJb1IM2dHi+bZSqQZlpVegakswamRSO+aqPnJbnq1fQCRmxjIr1fO6GtTA7LuhilFF5vi11FG5OnV8RQ1urzbVuXQeOaEwwbP/QFFcWnG5CP0kFe0BaF+LWyrm9ZeWPu1w3Xq2A1xUcZHQvnzhQTBDECCJd5mGxMGk5SJ+ZsBtW5VN/+h2OmVVdzRbYLgAJFORYzAxAcuplKvQJyNMr9s2bq9glx+qZ6dGDP/oLlPy/KNMJXxa0cgbHDqz+jwLcIFjrwkget3a2ssZhHMYHwURHICttBtkFJ7Os7w+iRKrl8DIxbf/ChGvu0QvZdIYzRq6uC8c24jNUzG93Ksy16ifhtfTZ1gMT05u2qZMWX1S9/3r0cqZ30bvu4yTBrxGj5WfaysE23ybIIJnvHCk=
X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR10MB2999.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(39860400002)(346002)(136003)(376002)(396003)(366004)(6496006)(6916009)(9576002)(83380400001)(26005)(52116002)(966005)(5660300002)(53546011)(86362001)(186003)(316002)(16526019)(54906003)(478600001)(2906002)(7416002)(8676002)(33656002)(4326008)(9686003)(1076003)(55016002)(66556008)(33716001)(66946007)(66476007)(956004)(6666004)(8936002);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?Ecg4u1dpIlr8EIo774trpOESjkqaloaHPt4GOSRa4mL1FEFCxGYZ23582+Zv?=
 =?us-ascii?Q?EHSoLph0A6QFrsgd8exnnoriEchwuPhC9MxTRa/PXrygqFtdwERFjkUgUEdy?=
 =?us-ascii?Q?/AkG+CF5kTPxZQnCo6rktw1Us6HYUU+aIBAS4tzYv/TF5CU0kjBoJ0cQ/5bs?=
 =?us-ascii?Q?atwzpWNxXGB0wI5qigzuGdZldSL7p3f+eDO/NmdGTPtfShtxQ/d/LeapEgKg?=
 =?us-ascii?Q?duXS1RSqMNOSojTcO+1lNWjpvtEqbOVxqjuzLgHdKD8cmf5b6r3RNY5Q2Szi?=
 =?us-ascii?Q?VEjlDC6w7omIAd54+3BcCFZuTRiGLExNX0ZpLOaUZlV/bp6RJUAVkPPR1h8o?=
 =?us-ascii?Q?hx+Lw0AxSrnYSzBaS14Y2dEXgB5xeTyoqyBY9yZl77k4fBjc4LB0tcaVPAqA?=
 =?us-ascii?Q?5u0ceIOQDVieQcOGLeyedZi5MtY7xaMeES37Vwf+ojL4h1ewE0mL6oUGGOeq?=
 =?us-ascii?Q?GBeQXvkT6NXbn/KQc8l3VRjGdVOqObCMbR98qwgDHCXnaJK5qIzV4KLdxb3S?=
 =?us-ascii?Q?P181GJpMVcupzDsuTOEsj7daF0427LFGWosC6XwrYYjorlFCVkrcGeMQ4xth?=
 =?us-ascii?Q?9QzLVKFjylGVRJXc2gAmJufjhBsgUhbqksZLF2FQLETp8KXzHeWGLIAcWY11?=
 =?us-ascii?Q?9DuAUR3CTAAr0BQ3KfsSV/WFwhlrTUSwGWS2Yks9M/3Dk8tBow/sduijTgXc?=
 =?us-ascii?Q?RN3MCcgamCo4RMHchV0OB80JZfxOwhaL43ET1Q0QMaJ3Zxy7GeyHtcaW8wBY?=
 =?us-ascii?Q?8I22n0OOGGBALEPyjML3oHITV6Oo6tAAqVAn7f7t6lQbfDKUbOUiEkDQgslg?=
 =?us-ascii?Q?wt2kbmwogGf9TWQWk8bAimvEtQUm/KQdNVacvfbDtb2sw0QYM3JDDr+HghKT?=
 =?us-ascii?Q?bzxxQfIBdnklVgmXVZh1liRVZcJ1NtzdyI9mhPTmYfls0nBjHo/qJgClKv50?=
 =?us-ascii?Q?FDtzi88J0IB1a/z5jW52PyRUpsUobPLN++Y5vR+fC3nK77IEKRWkqn1TQMV8?=
 =?us-ascii?Q?supIketUfXDdz096OfTr7Yea8OAIEbtJ8QFwT+cy8GJMfIOVn4t2cEMlZRtF?=
 =?us-ascii?Q?Y+iyeQDp?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e0f83a44-2a89-47e6-2e31-08d8c6dc6fbd
X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB2999.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Feb 2021 18:08:54.5627
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ZZ+yB5X0c0ZLIgH5BFddGm7U4vWECQSa8SPIh24RDw8N9YAPb+E1XeKNadrxAKyCzJwvs+OF0oe9KK5Y+l0dmw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR10MB4065
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9882 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0
 suspectscore=0 spamscore=0 mlxlogscore=999 phishscore=0 adultscore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2009150000 definitions=main-2102010094
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9882 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0
 priorityscore=1501 impostorscore=0 malwarescore=0 clxscore=1015
 spamscore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 mlxscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2009150000 definitions=main-2102010094
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Feb 01, 2021 at 09:50:41AM -0800, Ben Widawsky wrote:
> On 21-02-01 12:41:36, Konrad Rzeszutek Wilk wrote:
> > > +static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
> > > +{
> > > +	struct device *dev = &cxlm->pdev->dev;
> > > +	int cap, cap_count;
> > > +	u64 cap_array;
> > > +
> > > +	cap_array = readq(cxlm->regs + CXLDEV_CAP_ARRAY_OFFSET);
> > > +	if (CXL_GET_FIELD(cap_array, CXLDEV_CAP_ARRAY_ID) != CXLDEV_CAP_ARRAY_CAP_ID)
> > > +		return -ENODEV;
> > > +
> > > +	cap_count = CXL_GET_FIELD(cap_array, CXLDEV_CAP_ARRAY_COUNT);
> > > +
> > > +	for (cap = 1; cap <= cap_count; cap++) {
> > > +		void __iomem *register_block;
> > > +		u32 offset;
> > > +		u16 cap_id;
> > > +
> > > +		cap_id = readl(cxlm->regs + cap * 0x10) & 0xffff;
> > > +		offset = readl(cxlm->regs + cap * 0x10 + 0x4);
> > > +		register_block = cxlm->regs + offset;
> > > +
> > > +		switch (cap_id) {
> > > +		case CXLDEV_CAP_CAP_ID_DEVICE_STATUS:
> > > +			dev_dbg(dev, "found Status capability (0x%x)\n",
> > > +				offset);
> > 
> > That 80 character limit is no longer a requirement. Can you just make
> > this one line? And perhaps change 'found' to 'Found' ?
> > 
> 
> Funny that.
> https://lore.kernel.org/linux-cxl/20201111073449.GA16235@infradead.org/

 "If there is a good reason to go against the
style (a line which becomes far less readable if split to fit within the
80-column limit, for example), just do it.
"

I would say that having an offset on its own line is kind of silly.

> 
> > > +			cxlm->status.regs = register_block;
> > > +			break;
> > > +		case CXLDEV_CAP_CAP_ID_PRIMARY_MAILBOX:
> > > +			dev_dbg(dev, "found Mailbox capability (0x%x)\n",
> > > +				offset);
> > > +			cxlm->mbox.regs = register_block;
> > > +			break;
> > > +		case CXLDEV_CAP_CAP_ID_SECONDARY_MAILBOX:
> > > +			dev_dbg(dev,
> > > +				"found Secondary Mailbox capability (0x%x)\n",
> > > +				offset);
> > > +			break;
> > > +		case CXLDEV_CAP_CAP_ID_MEMDEV:
> > > +			dev_dbg(dev, "found Memory Device capability (0x%x)\n",
> > > +				offset);
> > > +			cxlm->mem.regs = register_block;
> > > +			break;
> > > +		default:
> > > +			dev_warn(dev, "Unknown cap ID: %d (0x%x)\n", cap_id,
> > > +				 offset);
> > > +			break;
> > > +		}
> > > +	}
> > > +
> > > +	if (!cxlm->status.regs || !cxlm->mbox.regs || !cxlm->mem.regs) {
> > > +		dev_err(dev, "registers not found: %s%s%s\n",
> > > +			!cxlm->status.regs ? "status " : "",
> > > +			!cxlm->mbox.regs ? "mbox " : "",
> > > +			!cxlm->mem.regs ? "mem" : "");
> > > +		return -ENXIO;
> > > +	}
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static int cxl_mem_setup_mailbox(struct cxl_mem *cxlm)
> > > +{
> > > +	const int cap = cxl_read_mbox_reg32(cxlm, CXLDEV_MB_CAPS_OFFSET);
> > > +
> > > +	cxlm->mbox.payload_size =
> > > +		1 << CXL_GET_FIELD(cap, CXLDEV_MB_CAP_PAYLOAD_SIZE);
> > > +
> > 
> > I think the static analyzers are not going to be happy that you are not
> > checking the value of `cap` before using it.
> > 
> > Perhaps you should check that first before doing the manipulations?
> > 
> 
> I'm not following the request. CXL_GET_FIELD is just doing the shift and mask on
> cap.
> 
> Can you explain what you're hoping to see?

My thoughts were that if cxl_read_mbox_reg32 gave you -1 (would be wacky
but we live in the world of having a healthy vision of devices not
always giving right values).

Then your payload_size bit shifting will get bent out of shape as you
are effectively casting cap to unsigned, which means it will end up
being 0xfffffffffffffffff.. and your bit shifting end up with a bunch
of zeros at the end.
> 
> > > +	/* 8.2.8.4.3 */
> > > +	if (cxlm->mbox.payload_size < 256) {

If this ends up being casted back to signed, this conditional will
catch it (-4096 < 256, true).

But if it does not (so 0xffffffff<256, false), then this wacky
number will pass this check and you may reference a payload_size that is
larger than the reality and copy the wrong set of values (buffer
overflow).

So what I was thinking is that you want to check `cap` to make sure it
is not negative nor to large?

> > 
> > #define for 256?