netdev - Re: [RFC 2/3] genetlink: pass extended error report down

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: <fd15a0bb-535a-ba4f-efbb-fa566e30fcd4@candelatech.com>
Date:   Fri, 7 Apr 2017 12:27:33 -0700
From:   Ben Greear <greearb@...delatech.com>
To:     Johannes Berg <johannes@...solutions.net>,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Cc:     pablo@...filter.org
Subject: Re: [RFC 2/3] genetlink: pass extended error report down

On 04/07/2017 12:12 PM, Johannes Berg wrote:
> On Fri, 2017-04-07 at 11:37 -0700, Ben Greear wrote:
>>
>> I guess the error string must be constant and always available in
>> memory in this implementation?
>
> Yes.
>
>> I think it would be nice to dynamically create strings (malloc,
>> snprintf, etc) and have the err_str logic free it when done?
>
> We can think about that later, but I don't actually think it makes a
> lot of sense - if we point to the attribute and/or offset you really
> ought to have enough info to figure out what's up.

We can think about it later, but lots of things in the wifi stack
could use a descriptive message specific to the failure.  Often these
messages are much more useful if you explain why the failure conflicts
with regulatory, channel, virtual-dev combination, etc info, so that needs
to be dynamic.  The code that is failing knows, so I'd like to pass it
back to user-space.

Thanks,
Ben

-- 
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com