linux-kernel - Re: Extended error reporting to user space?

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: <87r5ok5gl2.fsf@basil.nowhere.org>
Date:	Wed, 17 Feb 2010 10:58:33 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	"Nikita V. Youshchenko" <yoush@...msu.su>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Extended error reporting to user space?

"Nikita V. Youshchenko" <yoush@...msu.su> writes:

> I'm developing a device driver that, in it's ioctl()s, accepts a complex 
> data structure. Before doing it's operation, it performs large number of 
> checks if data is valid. If one of those checks fail, driver 
> returns -EINVAL.
>
> Unfortunately this -EINVAL is not really useful. E.g. if a developer, 
> sitting in his IDE and debugging his code, will see ioctl() 
> returning -EINVAL, and will have hard times finding what exactly is wrong.
>
> Before inventing driver-specific extended error reporting, I'd like to ask 
> if there is anything more or less generic for this.
> I believe situation when -Exxx is too weak interface for error reporting is 
> common.

This is a very common problem in Linux unfortunately.  I always
describe that as a the "ed approach to error handling". Instead
of giving a error message you just give ?. Just ? happens
to be EINVAL in Linux. 

My favourite example of this is the configuration of the networking
queueing disciplines, which configure complicated data structures and
algorithms and in many cases have tens of different error conditions
based on the input parameters -- and they all just report EINVAL.

The standard way (standard kludge or standard workaround would be a
better description) is to use printk; often guarded by a special
kernel tunable or ifdef to avoid flooding the log in the normal case.

IMHO it would be best to simply add a way to return strings directly
in this case (a la plan9). This would be probably not too hard to
implement. It's not there unfortunately.

This could be done with one of the message oriented protocols,
e.g. netlink or read/write on a special minor.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only.
--
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/