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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
