linux-kernel - Re: [tip:x86/cpu] Modify the VMware balloon driver for the new x86

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]

Message-Id: <201005101052.22796.dtor@vmware.com>
Date:	Mon, 10 May 2010 10:52:22 -0700
From:	Dmitry Torokhov <dtor@...are.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"mingo@...hat.com" <mingo@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"greg@...ah.com" <greg@...ah.com>,
	"hjanssen@...rosoft.com" <hjanssen@...rosoft.com>,
	"ksrinivasan@...ell.com" <ksrinivasan@...ell.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	Alok Kataria <akataria@...are.com>,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:x86/cpu] Modify the VMware balloon driver for the new x86_hyper API

On Monday 10 May 2010 10:30:43 am H. Peter Anvin wrote:
> On 05/10/2010 09:17 AM, Dmitry Torokhov wrote:
> > On Monday 10 May 2010 08:23:28 am H. Peter Anvin wrote:
> >> On 05/10/2010 01:06 AM, Dmitry Torokhov wrote:
> >>> Source please? I was not aware that there was a standard governing
> >>> returns code for module init methods.
> >> 
> >> ENODEV means "not a device node."
> >> ENXIO means "hardware not present."
> > 
> > There is no device node in question. Again, could you please point me to
> > the list of allowed error codes for init methods? According to SUS,
> > we need to follow ERROR section of the appropriate function, and I do
> > not believe that spec covers cases if driver binding and module loading.
> > 
> > FWIW -ENODEV is explicitly allowed in our device core and means "device
> > not found", especially in context of platform devices. I do not see the
> > need of changing that.
> 
> The problem with this abuse of ENODEV is that people start using it
> elsewhere, where it *DOES* matter than ENXIO is the proper return code.
>  Yes, we handle incorrect uses of ENODEV, but the right thing to do is
> to teach people to use ENXIO properly.

The usage that you mention only valid in the context of working with
device nodes. In other cases it can be used to indicate different errors
altogether:

mmap:

[ENODEV]
    The fildes argument refers to a file whose type is not supported
    by mmap().

fallocate:

[ENODEV]
    The fd argument does not refer to a regular file.

Linux mount:

      ENODEV filesystemtype not configured in the kernel.

      ENXIO  The major number of the block device source is out of range.

Solaris ldi:

ENODEV

    Requested device does not exist.

ENXIO

    Unsupported device operation or access mode.

and so on...

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/