| Message ID | CAEO8o4=-oYuHuh42yfRa6kAUZ2hBmxHabU-W3V82kURg-GZv_g@mail.gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Johannes Berg |
| Headers | show |
> diff --git a/net/wireless/wext-core.c b/net/wireless/wext-core.c > index 6250b1c..50583fb 100644 > --- a/net/wireless/wext-core.c > +++ b/net/wireless/wext-core.c > @@ -958,8 +958,28 @@ static int wireless_process_ioctl(struct net > *net, struct ifreq *ifr, > return private(dev, iwr, cmd, info, handler); > } > /* Old driver API : call driver ioctl handler */ > - if (dev->netdev_ops->ndo_do_ioctl) > - return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd); > + if (dev->netdev_ops->ndo_do_ioctl) { > + if (info->flags & IW_REQUEST_FLAG_COMPAT) { > + int ret = 0; > + struct iwreq iwrp; > + struct compat_iw_point *iwp_compat = > + (struct compat_iw_point *) &iwr->u.data; No need for the long cast - use (void *). > + strncpy(iwrp.ifr_ifrn.ifrn_name, iwr->ifr_ifrn.ifrn_name, > IFNAMSIZ); > + iwrp.u.data.pointer = compat_ptr(iwp_compat->pointer); > + iwrp.u.data.length = iwp_compat->length; > + iwrp.u.data.flags = iwp_compat->flags; Maybe you should clear iwrp first? > + ret = dev->netdev_ops->ndo_do_ioctl(dev, (struct ifreq *) > &iwrp, cmd); Same here with the cast. I'd blissfully forgotten how totally crufty this API is ... oh well. > + iwp_compat->pointer = ptr_to_compat(iwrp.u.data.pointer); > + iwp_compat->length = iwrp.u.data.length; > + iwp_compat->flags = iwrp.u.data.flags; > + return ret; > + } else { > + return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd); Please resend as a proper patch, with signed-off-by etc., and a commit log explaining the problem and solution. Thanks, johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Johannes Berg <johannes@sipsolutions.net> writes:
> I'd blissfully forgotten how totally crufty this API is ... oh well.
Yesterday there was a user on IRC having problems with wext (I didn't
even bother to investigate what exactly) which was immediately solved by
switching to nl80211. But he had no idea that wext was depricated until
I told him.
I know we can't remove wext because of legacy applications but is there
anything more we can do to make the users aware that wext is depreciated
and really should be avoided? For example a onetime kernel warning? Or
is that too spammy? Anything else?
> I know we can't remove wext because of legacy applications but is > there anything more we can do to make the users aware that wext is > depreciated and really should be avoided? For example a onetime > kernel warning? Or is that too spammy? Anything else? The problem is that wext is in this weird hybrid state where it's really deprecated if you can use nl80211, but you are required to use wext if you can't use nl80211. Now, we disabled wext-for-cfg80211 by default, but it's still there and could be used for some cases. We probably should try to fix things, but I realize that code that never gets tested [1]. Maybe we could print a message in the special cfg80211-wext case, which has a special case in wext-core to avoid creating all those iw_handler tables? johannes [1] and yeah - people move to nl80211 once told, so there's evidently very little incentive to keep using wext, so in reality people don't really seem to have applications that only use wext even with pure cfg80211 drivers ... -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/net/wireless/wext-core.c +++ b/net/wireless/wext-core.c @@ -958,8 +958,28 @@ static int wireless_process_ioctl(struct net *net, struct ifreq *ifr, return private(dev, iwr, cmd, info, handler); } /* Old driver API : call driver ioctl handler */ - if (dev->netdev_ops->ndo_do_ioctl) - return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd); + if (dev->netdev_ops->ndo_do_ioctl) { + if (info->flags & IW_REQUEST_FLAG_COMPAT) { + int ret = 0; + struct iwreq iwrp; + struct compat_iw_point *iwp_compat = + (struct compat_iw_point *) &iwr->u.data; + + strncpy(iwrp.ifr_ifrn.ifrn_name, iwr->ifr_ifrn.ifrn_name, IFNAMSIZ); + iwrp.u.data.pointer = compat_ptr(iwp_compat->pointer); + iwrp.u.data.length = iwp_compat->length; + iwrp.u.data.flags = iwp_compat->flags; + + ret = dev->netdev_ops->ndo_do_ioctl(dev, (struct ifreq *) &iwrp, cmd); + + iwp_compat->pointer = ptr_to_compat(iwrp.u.data.pointer); + iwp_compat->length = iwrp.u.data.length; + iwp_compat->flags = iwrp.u.data.flags; + return ret; + } else { + return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd); + } + } return -EOPNOTSUPP;
Hi, If a wireless driver uses "iw_handler_def.private_args" to populate iwpriv command for private ioctls but handlers for private ioctls(iw_handler) of iw_handler_def.private is set to NULL like "atmel" and "airo" wireless drivers. For those case, the IOCTLs from SIOCIWFIRSTPRIV to SIOCIWLASTPRIV will follow the path ndo_do_ioctl(). Accordingly when the filled up "iw_point" structure comes from 32 bit iwpriv to 64 bit Kernel, Kernel will not convert the pointer and sends it to driver. So, the driver may get the invalid data. We have used another iwr (i.e; iwrp) to pass things to driver. Changes are as follows. Please have look into this. diff --git a/net/wireless/wext-core.c b/net/wireless/wext-core.c index 6250b1c..50583fb 100644 } Is it Ok? Thanks, Prasun On Tue, May 31, 2016 at 3:55 PM, Johannes Berg <johannes@sipsolutions.net> wrote: > Hi, > > I must say, this is a bit of a surprise - where is iwpriv actually > still relevant? What driver could this possibly matter for? > > Anyway ... > >> + if (dev->netdev_ops->ndo_do_ioctl) { >> + if ((info->flags & IW_REQUEST_FLAG_COMPAT) && >> + (cmd >= SIOCIWFIRSTPRIV && cmd <= >> SIOCIWLASTPRIV)) { > > This has coding style issues, obviously. > > Also, handling the non-compat case would allow you to return and reduce > indentation by one in the large code block that handles the compat. > >> + int ret = 0; >> + struct compat_iw_point *iwp_compat = (struct compat_iw_point *) &iwr->u.data; >> + struct iw_point *iwp = &iwr->u.data; >> + __u16 length = iwp_compat->length, flags = iwp_compat->flags; >> + >> + iwp->pointer = compat_ptr(iwp_compat->pointer); >> + iwp->length = length; >> + iwp->flags = flags; >> + >> + ret = dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd); >> + >> + length = iwp->length; >> + flags = iwp->flags; >> + iwp_compat->pointer = ptr_to_compat(iwp->pointer); >> + iwp_compat->length = length; >> + iwp_compat->flags = flags; > > Why don't you just put another ifr/iwr on the stack, and use that to > pass things to the driver? This modify-in-place of 'iwp', which > requires loading all the variables first, seems very awkward to me. > > > johannes