linux-kernel - Re: [PATCH] x86 ptrace: fix PTRACE

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] [day] [month] [year] [list]

Date:	Wed,  2 Jul 2008 20:00:01 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	TAKADA Yoshihito <takada@....nifty.com>
Cc:	mingo@...e.hu, tglx@...utronix.de, linux-kernel@...r.kernel.org,
	stable@...nel.org
Subject: Re: [PATCH] x86 ptrace: fix PTRACE_GETFPXREGS error

> Hi. Thanks for your right patch.
> BTW, are FXSAVE and FXRSTOR instructions device?
> Is it right to return ENODEV?
> I think I had bettor return EXIO or ENOTSUP. 
> If it discussed, tell me URL of tree at lkml.org.

I don't think it was discussed.  It's clearly documented in the
linux/regset.h kerneldoc comments that define the interface.  
I don't recall any feedback about error codes when that went in.

Device, eh, whatever.  We're not going to add a new code that means
precisely "this user_regset refers to hardware not present", that would be
silly.  It's going to be chosen by some analogy with the original use of
some existing code.  ENXIO is fine too.  I probably chose ENODEV over ENXIO
just because it's easier to read the name and remember what it might mean
(and it's easier to type).  

All that really matters is that for the particular case of user_regset
functions, there be clearly specified one errno code that means "all's well,
but this supported hardware is not here".  Then callers know to check for
that, and any other error code value is potentially an unexpected sort of
error.  I see nothing wrong with ENODEV.  The only thing wrong with ENXIO is
trying to type it correctly twice in a row.  ENOTSUP does not seem like a
good fit as an analogy to its other specified uses.

Thanks,
Roland
--
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/