[dm-devel] [git pull] Additional device mapper changes for 6.0

[Milan Broz]

Hi,

Just a few notes on why we use target versions in libcryptsetup,
as I am perhaps one user of this field there.

TL;DR: it is *only* for hinting to users what is possibly wrong
after activation fails because there is *no* proper error reporting
from the device-mapper.

On 06/08/2022 20:36, Linus Torvalds wrote:
> On Sat, Aug 6, 2022 at 11:30 AM Mike Snitzer <snitzer at kernel.org> wrote:
...
>> Yes, I know you mentioned this before and I said I'd look to switch to
>> feature bitmasks. Yet here we are. Sorry about that, but I will take
>> a serious look at fixing this over the next development cycle(s).

Please don't just replace it with bitmaps.

It will not bring any better interface while adding more magic with
handling compatibility, as we need to use both... see below.

> Well, right now we're in the situation where there are certain kernels
> that say that they implement "version 1.9" of the thing, but they
> don't actually implement the "version 1.8.1" extensions.

I cannot speak for the others, but for veritysetup (libcryptsetup),
the worst that can happen is that the user will get a wrong error message
(or just a generic message "something failed, bye").
(All the crypto options are tricky, I would like to keep at least basic
usability and better errors like "seems tasklets are not supported,
retrying without tasklets flags.")

In principle, we use activation flags/options as Linus describes - try
to set it, then deal with the failure.

And *this* is the real problem that needs to be solved - there is no proper
userspace interface that says what went wrong.

The userspace sees only -EINVAL from ioctl() and a generic message.

Perhaps in the syslog is more info, but usually only at debug level
(that is often not visible), and parsing syslog is not the option for us either.

What is even more problematic is that the error string in DM target is
often set (e.g. ti->error = "Integrity profile tag size mismatch.";) but later
discarded, and it never reaches neither log nor userspace calling the failing
ioctl().

If the device-mapper can fix this, we can easily thrash the magic that
consults the target version and determines what went wrong.

Then you can forget the version and feature bitmaps and send
us a proper (ideally structured) error message in ioctl() reply.

Milan