tree abfa0474dc3442e0584a8173cc6a5b1969556cb1
parent 4f005551a8fac21b6fec8d10d57cd12d373d79e1
author Christoph Hellwig <hch@lst.de> 1131826254 -0800
committer David S. Miller <davem@davemloft.net> 1131826254 -0800

[SPARC]: Fix RTC compat ioctl kernel log spam.

On Fri, Nov 11, 2005 at 12:58:40PM -0800, David S. Miller wrote:
> 
> This change:
> 
> diff-tree 8ca2bdc7a98b9584ac5f640761501405154171c7 (from feee207e44d3643d19e648aAuthor: Christoph Hellwig <hch@lst.de>
> Date:   Wed Nov 9 12:07:18 2005 -0800
> 
>     [SPARC] sbus rtc: implement ->compat_ioctl
>     
>     Signed-off-by: Christoph Hellwig <hch@lst.de>
>     Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> results in the console now getting spewed on sparc64 systems
> with messages like:
> 
> [   11.968298] ioctl32(hwclock:464): Unknown cmd fd(3) cmd(401c7014){00} arg(efc
> What's happening is hwclock tries first the SBUS rtc device ioctls
> then the normal rtc driver ones.
> 
> So things actually worked better when we had the SBUS rtc compat ioctl
> directly handled via the generic compat ioctl code.
> 
> There are _so_ many rtc drivers in the kernel implementing the
> generic rtc ioctls that I don't think putting a ->compat_ioctl
> into all of them to fix this problem is feasible.  Unless we
> write a single rtc_compat_ioctl(), export it to modules, and hook
> it into all of those somehow.
> 
> But even that doesn't appear to have any pretty implementation.
> 
> Any better ideas?

We had similar problems with other ioctls where userspace did things
like that.  What we did there was to put the compat handler to generic
code.  The patch below does that, adding a big comment about what's
going on and removing the COMPAT_IOCTL entires for these on powerpc
that not only weren't ever useful but are duplicated now aswell.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: David S. Miller <davem@davemloft.net>