Re: [PATCH v4 3/7] s390: zcrypt: driver callback to indicate resource in use

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/9/19 6:49 AM, Cornelia Huck wrote:
On Mon, 8 Jul 2019 10:27:11 -0400
Tony Krowiak <akrowiak@xxxxxxxxxxxxx> wrote:

On 7/1/19 3:26 PM, Cornelia Huck wrote:
On Wed, 19 Jun 2019 09:04:18 -0400
Tony Krowiak <akrowiak@xxxxxxxxxxxxx> wrote:

Allow me to first address your fear that a bad actor can hog
resources that can't be removed by root. With this enhancement,
there is nothing preventing a root user from taking resources
from a matrix mdev, it simply forces him/her to follow the
proper procedure. The resources to be removed must first be
unassigned from the matrix mdev to which they are assigned.
The AP bus's /sys/bus/ap/apmask and /sys/bus/ap/aqmask
sysfs attributes can then be edited to transfer ownership
of the resources to zcrypt.

What is the suggested procedure when root wants to unbind a queue
device? Find the mdev using the queue (is that easy enough?), unassign
it, then unbind? Failing to unbind is a bit unexpected; can we point
the admin to the correct mdev from which the queue has to be removed
first?

The proper procedure is to first unassign the adapter, domain, or both
from the mdev to which the APQN is assigned. The difficulty in finding
the queue depends upon how many mdevs have been created. I would expect
that an admin would keep records of who owns what, but in the case he or
she doesn't, it would be a matter of printing out the matrix attribute
of each mdev until you find the mdev to which the APQN is assigned.

Ok, so the information is basically available, if needed.

The only means I know of for informing the admin to which mdev a given
APQN is assigned is to log the error when it occurs.

That might be helpful, if it's easy to do.

I think Matt is
also looking to provide query functions in the management tool on which
he is currently working.

That also sounds helpful.

(...)

* It forces the use of the proper procedure to change ownership of AP
     queues.

This needs to be properly documented, and the admin needs to have a
chance to find out why unbinding didn't work and what needs to be done
(see my comments above).

I will create a section in the vfio-ap.txt document that comes with this
patch set describing the proper procedure for unbinding queues. Of
course, we'll make sure the official IBM doc also more thoroughly
describes this.

+1 for good documentation.

With that, I don't really object to this change.

Then I will make the suggested changes and post v5 to the list.






[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux