linux-kernel - Re: [PATCH] ieee802154: add rx LQI from userspace

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:   Mon, 2 Jul 2018 13:53:29 -0400
From:   Alexander Aring <aring@...atatu.com>
To:     Clément Péron <peron.clem@...il.com>
Cc:     Romuald Cari <romuald.cari@...ialet.com>,
        linux-wpan@...r.kernel.org, Alexander Aring <alex.aring@...il.com>,
        Stefan Schmidt <stefan@....samsung.com>,
        "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Clément Peron <clement.peron@...ialet.com>
Subject: Re: [PATCH] ieee802154: add rx LQI from userspace

Hi,

On Mon, Jul 02, 2018 at 03:28:04PM +0200, Clément Péron wrote:
> Could you review it please ?
>

sorry... I was thinking a lot what I can contribute to this patch, I
want to make it short.

I see your use case and your use case has of course a valid point.

What I can say about the code? This socket layer was contributed a lot
in a time where the subsystem was unmaintained. Stefan has some
experience with this socket layer by doing some examples [0].

In my opinion I am confused that a lot of netlink handling is needed to
do "something" with this socket layer. I already thought that we need
some af802154ng for next generation.

Known bug is also RAW sockets on af802154 are totally messed up... but
we don't need them, this can be done by AF_PACKET (just need to think
about similar handling there).

---

Now to your patch, you use skb->cb there. The tc ingress part can
_maybe_? use this control block information. I think this issue is out
of scope because we have also other parts in the code how we pass data
between driver and packet layer with skb->cb -> we simply do it wrong.

I have no problems to have this patch inside but for future we should
tackle a af802154ng with a better UAPI handling.

If we fix skb->cb we just need to think about how to pass such data up
to socket layer.

- Alex

[0] https://github.com/linux-wpan/wpan-tools/tree/master/examples