netdev - Re: [PATCH net-next-2.6] can: Proper ctrlmode handling for CAN devices

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:	Thu, 14 Jan 2010 15:18:28 +0100
From:	christian pellegrin <chripell@...e.org>
To:	Wolfgang Grandegger <wg@...ndegger.com>
Cc:	socketcan-core@...ts.berlios.de, netdev@...r.kernel.org
Subject: Re: [PATCH net-next-2.6] can: Proper ctrlmode handling for CAN 
	devices

On Wed, Jan 13, 2010 at 8:56 PM, Wolfgang Grandegger <wg@...ndegger.com> wrote:
> Hi Christian,

Hi,

> Could you please explain, what the "check_ctrlmode" callback is good
> for. For me it seems useless, at a first glance. Without, also the
> variable ctrlmode is not necessary.

It's needed to avoid unmeaningful combinations like loop-back +
listen-only (it's quite sure you won't hear nothing and this mode
isn't even programmable on the mcp251x for example; other could be
more subtle, like having one-shot mode on or off doesn't make any
difference both with loop-back or listen-only). Of course I can
hard-code this but if we add some other fancy options with
controller-specific behavior I'm not sure all the possible cases could
be catch. On the other hand it's supposed that people who set ctrlmode
more or less know what are they doing, so this test may be superflous.
If you think so I can just eliminate it.

>> +             return -EOPNOTSUPP;
>
> In another mail you mentioned, that "ENOTSUPP" does not result in a
> useful user space error message. I checked "errno.h" of my Linux
> distribution and there ENOTSUPP is not even defined, in contrast to
> "EOPNOTSUPP". Hm, ENOTSUPP is used in may places in the kernel and also
> in some CAN source files and I think we should fix that.
>

I agree, perhaps this should be pointed out on LKML too (even if we
risk to ignite a flame war between kernel and glibc folks ;-) )

>> +     return 0;
>> +}
>
> For me this check never fails if "priv->can.ctrlmode_supported" is set
> properly. Or have I missed something?
>

as I said above it catches the case when the device is put in
loop-back and listen-only at the same time.

-- 
Christian Pellegrin, see http://www.evolware.org/chri/
"Real Programmers don't play tennis, or any other sport which requires
you to change clothes. Mountain climbing is OK, and Real Programmers
wear their climbing boots to work in case a mountain should suddenly
spring up in the middle of the computer room."
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html