Messages in this thread | | | Date | Thu, 4 Jul 2019 16:31:55 +0200 | From | Andrew Lunn <> | Subject | Re: [PATCH net-next v6 06/15] ethtool: netlink bitset handling |
| |
> OK, here I guess I see what you mean. You're saying if ethtool were to > send a value/mask of "0..0100/0..0111" you wouldn't know what to do with > BIT(4) as long as the kernel knows about that bit? > > I guess the difference now is depending on the operation. NLA_BITFIELD32 > is sort of built on the assumption of having a "toggle" operation. If > you want to have a "set to" operation, then you don't really need the > selector/mask at all, just the value.
I don't think it is as simple as this. User space has a few different things it wants to pass to the kernel:
I want to set this bit to 0 I want to set this bit to 1 I don't want to change this bit In my world view, this bit is unused
The kernel has had a long history of trouble with flag bits in system calls. It has not validated that unused bits are clear. Meaning when you actually want to make use of the unused bits you cannot because userspace has been passing random values in them since day 1.
We need a design which is clear to everybody which bits are unused and should be validated as being unused and an error returned if an unused bit is actually used. A value and a mask is not sufficient for this. We need the length in bits.
Andrew
| |