lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 7 Sep 2022 14:10:33 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Joerg Roedel <joro@...tes.org>
Cc:     Nicolin Chen <nicolinc@...dia.com>, will@...nel.org,
        robin.murphy@....com, alex.williamson@...hat.com,
        suravee.suthikulpanit@....com, marcan@...can.st,
        sven@...npeter.dev, alyssa@...enzweig.io, robdclark@...il.com,
        dwmw2@...radead.org, baolu.lu@...ux.intel.com,
        mjrosato@...ux.ibm.com, gerald.schaefer@...ux.ibm.com,
        orsonzhai@...il.com, baolin.wang@...ux.alibaba.com,
        zhang.lyra@...il.com, thierry.reding@...il.com, vdumpa@...dia.com,
        jonathanh@...dia.com, jean-philippe@...aro.org, cohuck@...hat.com,
        tglx@...utronix.de, shameerali.kolothum.thodi@...wei.com,
        thunder.leizhen@...wei.com, christophe.jaillet@...adoo.fr,
        yangyingliang@...wei.com, jon@...id-run.com, iommu@...ts.linux.dev,
        linux-kernel@...r.kernel.org, asahi@...ts.linux.dev,
        linux-arm-kernel@...ts.infradead.org,
        linux-arm-msm@...r.kernel.org, linux-s390@...r.kernel.org,
        linux-tegra@...r.kernel.org,
        virtualization@...ts.linux-foundation.org, kvm@...r.kernel.org,
        kevin.tian@...el.com
Subject: Re: [PATCH v6 1/5] iommu: Return -EMEDIUMTYPE for incompatible
 domain and device/group

On Wed, Sep 07, 2022 at 04:06:29PM +0200, Joerg Roedel wrote:
> On Wed, Sep 07, 2022 at 10:47:39AM -0300, Jason Gunthorpe wrote:
> > Would you be happier if we wrote it like
> > 
> >  #define IOMMU_EINCOMPATIBLE_DEVICE xx
> > 
> > Which tells "which of the function parameters is actually invalid" ?
> 
> Having done some Rust hacking in the last months, I have to say I like
> to concept of error handling with Result<> there. Ideally we have a way
> to emulate that in our C code without having to change all callers.

Sure, rust has all sorts of nice things. But the kernel doesn't follow
rust idioms, and I don't think this is a great place to start
experimenting with them.

The unix/linux idiom is return an errno, and define what the errnos
mean for your function. We have a long history of creatively applying
the existing errnos, and sometimes we create new ones.

We rarely return an errno and an additional error code because it
doesn't fit the overall model, I can't return something like that
through a system call, for instance.

> What I am proposing is a way this could be emulated here, but I am open
> to other suggestions. Still better than re-using random error codes for
> special purposes.

I think, in context of Linux as a project, it very much is worse to
make up some rust-inspired error handing and discard the typical
design patterns.

Linux works because, for the most part, people follow similar design
sensibilities throughout the tree.

It has been 3 months since EMEDIUMTYPE was first proposed and 6
iterations of the series, don't you think it is a bit late in the game
to try to experiment with rust error handling idioms?

So, again, would you be happy with a simple 

 #define IOMMU_EINCOMPATIBLE_DEVICE xx

to make it less "re-using random error codes"?

Thanks,
Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ