On 10/21/2019 05:52 PM, Dave Chinner wrote:

On Mon, Oct 21, 2019 at 04:41:37PM -0500, Mike Christie wrote:

quoted

There are several storage drivers like dm-multipath, iscsi, tcmu-runner,
amd nbd that have userspace components that can run in the IO path. For
example, iscsi and nbd's userspace deamons may need to recreate a socket
and/or send IO on it, and dm-multipath's daemon multipathd may need to
send IO to figure out the state of paths and re-set them up.

In the kernel these drivers have access to GFP_NOIO/GFP_NOFS and the
memalloc_*_save/restore functions to control the allocation behavior,
but for userspace we would end up hitting a allocation that ended up
writing data back to the same device we are trying to allocate for.

I think this needs to describe the symptoms this results in. i.e.
that this can result in deadlocking the IO path.

quoted

This patch allows the userspace deamon to set the PF_MEMALLOC* flags
with prctl during their initialization so later allocations cannot
calling back into them.

Signed-off-by: Mike Christie <redacted>
---

....

quoted

+	case PR_SET_MEMALLOC:
+		if (!capable(CAP_SYS_ADMIN))
+			return -EPERM;

Wouldn't CAP_SYS_RAWIO (because it's required by kernel IO path
drivers) or CAP_SYS_RESOURCE (controlling memory allocation
behaviour) be more appropriate here?

I think I misread a review comment last posting. I will use
CAP_SYS_RESROUCE on the next resend if people do not have any objections.

Which-ever is selected, the use should be added to the list above
the definition of the capability in include/linux/capability.h...

Will do. Thanks.

Otherwise looks fine to me.

Cheers,

Dave.