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]

Date:	Wed, 17 Feb 2010 13:16:48 +0300
From:	"Nikita V. Youshchenko" <yoush@...msu.su>
To:	Andi Kleen <andi@...stfloor.org>
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.

Why not create a generic solution for this, if one does not exist yet?

For example, have a "last error" string associated with task_struct, that:
- will clean on each syscall entry,
- while syscall is running, may be filled with printf-style routines,
- may be accessible from userspace with additional syscall [that obviously 
should not reset error]?

This will give driver writers a common interface for extended error 
reporting...

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