Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753136AbcCBXST (ORCPT ); Wed, 2 Mar 2016 18:18:19 -0500 Received: from mleia.com ([178.79.152.223]:60565 "EHLO mail.mleia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751004AbcCBXSS (ORCPT ); Wed, 2 Mar 2016 18:18:18 -0500 Subject: Re: [PATCHv7 6/7] eeprom: 93xx46: extend driver to plug into the NVMEM framework To: Andrew Lunn References: <1456516764-1456-1-git-send-email-andrew@lunn.ch> <1456516764-1456-7-git-send-email-andrew@lunn.ch> <56D7644F.8060601@mleia.com> <20160302222639.GC15541@lunn.ch> Cc: GregKH , srinivas.kandagatla@linaro.org, maxime.ripard@free-electrons.com, wsa@the-dreams.de, broonie@kernel.org, linux-kernel@vger.kernel.org, pantelis.antoniou@konsulko.com, bgolaszewski@baylibre.com From: Vladimir Zapolskiy Message-ID: <56D774B6.6070108@mleia.com> Date: Thu, 3 Mar 2016 01:18:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160302222639.GC15541@lunn.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-49551924 X-CRM114-CacheID: sfid-20160302_232130_032324_13350EEC X-CRM114-Status: GOOD ( 16.52 ) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1998 Lines: 59 On 03.03.2016 00:26, Andrew Lunn wrote: >>> static ssize_t >>> -eeprom_93xx46_bin_read(struct file *filp, struct kobject *kobj, >>> - struct bin_attribute *bin_attr, >>> - char *buf, loff_t off, size_t count) >>> +eeprom_93xx46_read(struct eeprom_93xx46_dev *edev, char *buf, >>> + unsigned off, size_t count) >>> { >>> - struct eeprom_93xx46_dev *edev; >>> - struct device *dev; >>> ssize_t ret = 0; >>> >>> - dev = kobj_to_dev(kobj); >>> - edev = dev_get_drvdata(dev); >>> + if (unlikely(off >= edev->size)) >>> + return 0; >>> + if ((off + count) > edev->size) >>> + count = edev->size - off; >>> + if (unlikely(!count)) >>> + return count; >>> >> >> I'm scratching my head, do you want to kind of revert >> the change https://lkml.org/lkml/2015/7/26/89 ? Why? > > Hi Vladimir > > I had not noticed you had removed this. > >> If you know regmap_config.max_register, then all necessary >> boundary checks can be done inside NVMEM core. > > You don't have to use NVMEM, you could use the regmap directly. No problem, regmap API from drivers/base/regmap/regmap.c contains all necessary boundary checks as far as I understand. > It is a public API. Also, during implementation, i did manage to get out of > bounds read passed into the drivers and they caused a crash. That > might of been AT24, i don't remember, but verifying is better than > possible crashing. > IMHO to avoid boilerplate code and/or missed/redundant checks it might be better to handle this particular kind of problem only in one common place, for example sysfs binary attribute files do not need this anymore, probably I should scrutinize the situation with this transition to NVMEM as well. If you remember a reproduction scenario for that crash, please let me know. At least this changeset must be applied I guess, am I right? In other words is the code without this changeset safe in connection to boundary checks, and this is a new discovered issue? -- With best wishes, Vladimir