Re: [git pull] Additional device mapper changes for 6.0

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

 



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@xxxxxxxxxx> 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



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux