On Wed, Oct 4, 2017 at 1:58 PM, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > On 04/10/17 12:09, Linus Walleij wrote: >>> But how do you know md still exists? >> >> I was thinking that the reference counting is exactly for making sure >> it exists across open()/close()? > > Previously the device being opened was the block device which had to exist. > > But I think it is OK to assume md exists in mmc_rpmb_chrdev_open() because > rpmb->chrdev is removed before the main disk. That's my thought too. But thinking it over there could be a race if e.g. you write a script with a loop hammering the device in/out with bind/unbind at the same time opening and closing the RPMB chardev and holding a handle to it. It is not a very realistic usecase but I will try to provoke it anyways. > OK. What about the "capable(CAP_SYS_RAWIO)" question? The flag has a very strange definition in include/uapi/linux/capability.h: /* Allow sending USB messages to any device via /dev/bus/usb */ #define CAP_SYS_RAWIO 17 So I read in the codebase how this flag is actuallt used. It seems to universally apply for cases where userspace is allowed to read or write directly into device registers. So I dropped that since the character device is only able to do ioctl()s, no raw I/O. RPMB is and always was strictly ioctl-based. We should simply plug the hole and not letting people shoot themselves in the foot with this. I think it is bogus that we have it even for the block device, but it may be argued that the stuff returned from the ioctl reading card info is "kind of" RAWIO. I guess that is why it's there. But we are using well structured ioctls so it is really irrelevant. The flag is not needed or used for anything (the subsystems using it is checking for it explicitly, it is not checked in the core fs code or anything), we could just drop it from the block devices too. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html