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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ