Hi Luiz, > >> This use MSG_DONTROUTE to send a single message with highest possible > >> priority without having to rely on socket options. > >> > >> This is useful for RFCOMM which relies on socket interface to send frames > >> to L2CAP, but since some of this frames are actual commands that can > >> timeout they should be sent as soon as possible. > >> > >> For userspace this also offer the convenience of not having to use > >> setsockopt several times when only a single/some messages needs to be > >> prioritize. > > > > are you sure that we are not mis-using the MSG_DONTROUTE flag? > > This is the reason Ive sent as RFC, man page says it is only define > for protocols that route, but note that MSG_TRYHARD does map to the > same value (4) so the meaning depend on the protocol. Perhaps creating > a new flag e.g. MSG_HIGHPRIO would be acceptable? try to get this upstream via netdev mailing list first. And lets see where this goes. I personally like the idea, but shoehorning it into MSG_DONTROUTE seems not really a good idea. > >> + priority = sk->sk_priority; > >> + > >> + /* MSG_DONTROUTE send message at maximum possible priority */ > >> + if ((msg->msg_flags & MSG_DONTROUTE) && priority < HCI_PRIO_MAX - 1) > >> + priority = HCI_PRIO_MAX - 1; > >> + > > > > you need to enforce the same privilege check that SO_PRIORITY does. > > Otherwise every single application can just go and overwrite it. > > Currently HCI_PRIO_MAX - 1 maps to the highest priority without > requiring privileges, but I can change that to HCI_PRIO_MAX so only > privileged processes such bluetoothd can make use of it. If we wanna do then, we should give privileged daemons to use highest priority as well. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
