On 2017-12-15 21:42, Philippe Gerum wrote: > On 12/15/2017 02:48 PM, Philippe Gerum wrote: >> On 12/15/2017 02:40 PM, Jan Kiszka wrote: >>> On 2017-12-15 14:29, Philippe Gerum wrote: >>>> On 12/15/2017 02:20 PM, Jan Kiszka wrote: >>>>> On 2017-12-15 13:25, Leopold Palomo-Avellaneda wrote: >>>>>> Hi, >>>>>> >>>>>> I forgot something more: >>>>>> >>>>>> On 15/12/17 12:04, Philippe Gerum wrote: >>>>>> >>>>>> [...] >>>>>>>> >>>>>>>> I guess that there's something in the kernel config or somewhere in >>>>>>>> 3.x that >>>>>>>> affects the PCI cards. In 2.6.x worked. >>>>>>> >>>>>>> On x86, I'd dare to say that it worked mostly by accident, as revealed >>>>>>> by SMAP later on. RTnet was out of the Xenomai tree in 2.6.x, some >>>>>>> changes introduced during the merge into 3.x might have caused >>>>>>> regressions, or maybe some latent issues started to bite when transposed >>>>>>> in a different environment, just like the SMAP problem on x86, revealing >>>>>>> an ancient Rnet bug. I genuinely don't know when things started to hit >>>>>>> the fan. >>>>>> >>>>>> I don't know if it's relevant or not, or I didn't understand it, but I >>>>>> think >>>>>> that I still have problems with SMAP. If I activate it, I got: >>>>> >>>>> You must leave SMAP off until someone develops patches to convert the >>>>> complete RTnet userspace API over to rtdm_copy_to/from_user. >>>>> >>>> >>>> The patches in wip/rtnet-fixes address this issue, this is the patch >>>> series I was referring to in this discussion. >>>> >>> >>> Hmm, for the protocol core. I suspect you are missing further cases in >>> RTmac and RTcfg (provided anyone needs them). >>> >> >> The author of ioctl* support in both cases used copy_from_user directly, >> maybe that is a problem with the calling mode. Ok, I'll check whether >> rtnet_ioctls dispatcher actually routes from ioctl_nrt. Thanks. >> > > RTcfg and RTmac are fine in the wip/rtnet-fixes branch. The rtnet_ioctls > dispatcher runs over a regular ioctl_unlocked context from a chrdev, so > there is no mode issue. All user memory is accessed via copy_to/from > routines. I see no sendmsg/recvmsg which could raise the SMAP issue there. > > Do you have any hint about those missing cases? >
Nope, those two indeed seem to be fine. I didn't remember that we wrote them with proper copy_to/from, also for the RT part (tdma_dev.c). The core has a different, longer history, lacking any usercopy from day #1. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux _______________________________________________ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
