[Xenomai] RTnet fixes - testers needed

[Xenomai] RTnet fixes - testers needed

[Philippe Gerum]

I pushed a pile of RTnet fixes in a WIP branch of the official repo
(wip/rtnet-fixes). Most of them address invalid direct references to
user memory from kernel space (instead of properly copying back and
forth via the copy_from/to_user interface), which are badly wrong at any
rate, even breaking the kernel on SMAP-enabled x86 platforms.

Most I/O calls were affected, ioctl, sendmsg and recvmsg. I'm still in
the early process of testing the changes gradually, which involves
running tests for all socket levels (RAW, DGRAM) and protocols (INET,
PACKET) enabled.

If you depend on RTnet and want to help with testing, you may want to
give this branch a try. Any help with reviewing the changes would be
beneficial to the project too.

Thanks,

-- 
Philippe.

Re: [Xenomai] RTnet fixes - testers needed

[Leopold Palomo-Avellaneda]

Hi,


On 06/12/17 18:37, Philippe Gerum wrote:
> 
[...]

> If you depend on RTnet and want to help with testing, you may want to
> give this branch a try. Any help with reviewing the changes would be
> beneficial to the project too.

I have tested this branch in two x86 boards: one modern i7 witn PCIe 3x, etc,
and another Dual-core. Both systems where tested with the same kernel:

- 4.9.51 patched
- based in Debian stretch


Mainly I tested the RTNet drivers, for the cards that I have: intel based e1000,
e1000e, eepro100, igb, and r8168, and PCIe and PCI cards.

I haver also some 3Com but I have not tested because they are quite old.

The results are frustrating ...

1) in the modern board, the integrated NIC Intel I219-LM was not detected by the
rt driver.

2) in both boards, none of the PCI cards worked: neither Intel or Realtek.

3) the PCIe cards from intel worked (e1000e and igb) in both mobos

4) in the modern PC, the r8168 was loaded and created the rtethX interface, but
it was not operational (hangs the program). In the old PC do nothing.

5) in the old PC (only tested there) the r8168 doesn't detect the
RTL8111/8168/8411 PCIe cards although they are PCIe

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.

Also, seeing the elephant, it's not obvious (at least for me) how to create or
upgrade a network driver to work with Xenomai. So, some tutorial would help.

Best regards,


Leopold


-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://xenomai.org/pipermail/xenomai/attachments/20171215/25287445/attachment.sig>

Re: [Xenomai] RTnet fixes - testers needed

[Philippe Gerum]

On 12/15/2017 11:46 AM, Leopold Palomo-Avellaneda wrote:
> Hi,
> 
> 
> On 06/12/17 18:37, Philippe Gerum wrote:
>>
> [...]
> 
>> If you depend on RTnet and want to help with testing, you may want to
>> give this branch a try. Any help with reviewing the changes would be
>> beneficial to the project too.
> 
> I have tested this branch in two x86 boards: one modern i7 witn PCIe 3x, etc,
> and another Dual-core. Both systems where tested with the same kernel:
> 
> - 4.9.51 patched
> - based in Debian stretch
> 
> 
> Mainly I tested the RTNet drivers, for the cards that I have: intel based e1000,
> e1000e, eepro100, igb, and r8168, and PCIe and PCI cards.
> 
> I haver also some 3Com but I have not tested because they are quite old.
> 
> The results are frustrating ...
> 
> 1) in the modern board, the integrated NIC Intel I219-LM was not detected by the
> rt driver.
> 
> 2) in both boards, none of the PCI cards worked: neither Intel or Realtek.
> 
> 3) the PCIe cards from intel worked (e1000e and igb) in both mobos
> 
> 4) in the modern PC, the r8168 was loaded and created the rtethX interface, but
> it was not operational (hangs the program). In the old PC do nothing.
> 
> 5) in the old PC (only tested there) the r8168 doesn't detect the
> RTL8111/8168/8411 PCIe cards although they are PCIe
>

Thanks for testing. The fixes I was referring too are not related to NIC
support, they can only be tested with a working NIC actually, since the
bugs they address were affecting the I/O path between the driver and
userland. We could test them with the loopback interface the same way.

This said, your results confirm that the RTnet support has severely bit
rotten (I only tested with the igb which is (only) the NIC I need, at
the moment).

> 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.

> 
> Also, seeing the elephant, it's not obvious (at least for me) how to create or
> upgrade a network driver to work with Xenomai. So, some tutorial would help.
> 

I see this file in the distro which looks like a promising starting
point: kernels/drivers/net/doc/README.drvporting

-- 
Philippe.

Re: [Xenomai] RTnet fixes - testers needed

[Leopold Palomo-Avellaneda]

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:

Dec 15 12:39:03 bmm3 kernel: [ 1495.836505] [Xenomai] switching slaveinfo_rt to
secondary mode after exception #14 in kernel-space at 0xffffffffc046a981 (pid
Dec 15 12:39:03 bmm3 kernel: [ 1495.839892] PGD 45afb2067
Dec 15 12:39:03 bmm3 kernel: [ 1495.839901] PUD 45c07b067
Dec 15 12:39:03 bmm3 kernel: [ 1495.841014] PMD 459b3a067
Dec 15 12:39:03 bmm3 kernel: [ 1495.841019] PTE 8000000451600067
Dec 15 12:39:03 bmm3 kernel: [ 1495.842141]
Dec 15 12:39:03 bmm3 kernel: [ 1495.843237] Oops: 0001 [#2] SMP
Dec 15 12:39:03 bmm3 kernel: [ 1495.844342] Modules linked in: rt_e1000e
rt_loopback rtcfg rtudp rtipv4 rtmac rtpacket ctr ccm cdc_acm snd_hda_codec_hdmi snd
Dec 15 12:39:03 bmm3 kernel: [ 1495.850432]  efivars battery hci_uart btbcm
btqca btintel parport_pc parport bluetooth wmi rfkill intel_lpss_acpi video intel
Dec 15 12:39:03 bmm3 kernel: [ 1495.854316] CPU: 5 PID: 1306 Comm: slaveinfo_rt
Tainted: G      D    O    4.9.51-xenomai-3.0.6-ipipe #1
Dec 15 12:39:03 bmm3 kernel: [ 1495.855577] Hardware name: Gigabyte Technology
Co., Ltd. To be filled by O.E.M./Q170M-D3H, BIOS F2 01/11/2016
Dec 15 12:39:03 bmm3 kernel: [ 1495.856827] I-pipe domain: Linux
Dec 15 12:39:03 bmm3 kernel: [ 1495.858046] task: ffff9c4599fe90c0 task.stack:
ffffa485c090c000
Dec 15 12:39:03 bmm3 kernel: [ 1495.859254] RIP: 0010:[<ffffffffc046a981>]
[<ffffffffc046a981>] rt_packet_ioctl+0x1a1/0x380 [rtpacket]
Dec 15 12:39:03 bmm3 kernel: [ 1495.860460] RSP: 0018:ffffa485c090fdf8  EFLAGS:
00010202
Dec 15 12:39:03 bmm3 kernel: [ 1495.861640] RAX: ffffa485c090fdf8 RBX:
ffff9c45991bbe00 RCX: 0000000000000000
Dec 15 12:39:03 bmm3 kernel: [ 1495.862804] RDX: 0000000000000000 RSI:
00007ffe9ae5eec0 RDI: ffffa485c090fe08
Dec 15 12:39:03 bmm3 kernel: [ 1495.863965] RBP: ffffa485c090fec0 R08:
e4b5e00700000014 R09: 000000000000005c
Dec 15 12:39:03 bmm3 kernel: [ 1495.865114] R10: 00000000000000e4 R11:
0000000100048fc7 R12: 0000000000000003
Dec 15 12:39:03 bmm3 kernel: [ 1495.866255] R13: ffff9c45991bbf40 R14:
ffffa485c02de040 R15: 00007ffe9ae5ef20
Dec 15 12:39:03 bmm3 kernel: [ 1495.867384] FS:  00007f23b82edb80(0000)
GS:ffff9c45a0300000(0000) knlGS:0000000000000000
Dec 15 12:39:03 bmm3 kernel: [ 1495.868528] CS:  0010 DS: 0000 ES: 0000 CR0:
000000008005003b
Dec 15 12:39:03 bmm3 kernel: [ 1495.869662] CR2: 00007ffe9ae5ef20 CR3:
000000045b799000 CR4: 00000000003406e0
Dec 15 12:39:03 bmm3 kernel: [ 1495.870788] DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Dec 15 12:39:03 bmm3 kernel: [ 1495.871913] DR3: 0000000000000000 DR6:
00000000fffe0ff0 DR7: 0000000000000400
Dec 15 12:39:03 bmm3 kernel: [ 1495.873040] Stack:
Dec 15 12:39:03 bmm3 kernel: [ 1495.874139]  00007ffe9ae5ef20 e4b5e00700000014
ffff9c45991bbe00 ffffa485c090fec0
Dec 15 12:39:03 bmm3 kernel: [ 1495.875282]  0000000000000003 ffff9c4599fe90c0
ffffa485c02de040 0000000000011ba0
Dec 15 12:39:03 bmm3 kernel: [ 1495.876416]  ffffffffb7f6b9a8 00007ffe9ae5eeb0
4010002299fe96b8 0000000000000010
Dec 15 12:39:03 bmm3 kernel: [ 1495.877537] Call Trace:
Dec 15 12:39:03 bmm3 kernel: [ 1495.878636]  [<ffffffffb7f6b9a8>] ?
rtdm_fd_ioctl+0xa8/0x1e0
Dec 15 12:39:03 bmm3 kernel: [ 1495.879744]  [<ffffffffb7f70b20>] ?
CoBaLt_fcntl+0x10/0x10
Dec 15 12:39:03 bmm3 kernel: [ 1495.880865]  [<ffffffffb7e8298d>] ?
__ipipe_migrate_head+0x4d/0xb0
Dec 15 12:39:03 bmm3 kernel: [ 1495.881976]  [<ffffffffb7f70b20>] ?
CoBaLt_fcntl+0x10/0x10
Dec 15 12:39:03 bmm3 kernel: [ 1495.883084]  [<ffffffffb7f70b2a>] ?
CoBaLt_ioctl+0xa/0x10
Dec 15 12:39:03 bmm3 kernel: [ 1495.884169]  [<ffffffffb7f807ac>] ?
ipipe_syscall_hook+0xfc/0x2b0
Dec 15 12:39:03 bmm3 kernel: [ 1495.885265]  [<ffffffffb7efad9a>] ?
__ipipe_notify_syscall+0xba/0x170
Dec 15 12:39:03 bmm3 kernel: [ 1495.886356]  [<ffffffffb83868af>] ?
pipeline_syscall+0x8/0x1b
Dec 15 12:39:03 bmm3 kernel: [ 1495.887434] Code: 5f c3 b9 10 00 00 00 48 89 e6
e8 7b 16 46 00 48 3d 00 f0 ff ff 77 d8 83 78 08 13 4c 8b 38 4c 8d ab 40 01 00
Dec 15 12:39:03 bmm3 kernel: [ 1495.890982]  RSP <ffffa485c090fdf8>
Dec 15 12:39:03 bmm3 kernel: [ 1495.892126] CR2: 00007ffe9ae5ef20
Dec 15 12:39:03 bmm3 kernel: [ 1495.893272] ---[ end trace 6ba1d9fc8d294720 ]---


>>
>> Also, seeing the elephant, it's not obvious (at least for me) how to create or
>> upgrade a network driver to work with Xenomai. So, some tutorial would help.
>>
> 
> I see this file in the distro which looks like a promising starting
> point: kernels/drivers/net/doc/README.drvporting
> 

I'll look it.

Thanks,

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [Xenomai] RTnet fixes - testers needed

[Jan Kiszka]

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.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] RTnet fixes - testers needed

[Philippe Gerum]

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.

-- 
Philippe.

Re: [Xenomai] RTnet fixes - testers needed

[Jan Kiszka]

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).

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] RTnet fixes - testers needed

[Leopold Palomo-Avellaneda]

On 15/12/17 14:40, 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).
> 
Yes, I need rtmac and rtcfg.

Leopold


-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [Xenomai] RTnet fixes - testers needed

[Philippe Gerum]

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.

-- 
Philippe.

Re: [Xenomai] RTnet fixes - testers needed

[Philippe Gerum]

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?

-- 
Philippe.

Re: [Xenomai] RTnet fixes - testers needed

[Jan Kiszka]

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

Re: [Xenomai] RTnet fixes - testers needed

[Leopold Palomo-Avellaneda]

On 18/12/17 07:33, Jan Kiszka wrote:
> 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.
> 

Hi,

I have pulled wip/rtnet-fixes branch with the last commit of Philippe from Sun
Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type

I have created the packages and new kernel with the same configuration that I had.

I run my application, that it's a POSIX application Wrapped and I still have the
same error when I activate SMAP:

#######################################################3

Dec 18 14:58:13 bmm3 kernel: [  118.545908] [Xenomai] switching slaveinfo_rt to
secondary mode after exception #14 in kernel-space at 0xffffffffc0743981 (pid 1742)
Dec 18 14:58:13 bmm3 kernel: [  118.545924] BUG: unable to handle kernel paging
request at 00007ffcc7389470
Dec 18 14:58:13 bmm3 kernel: [  118.546586] IP: [<ffffffffc0743981>]
rt_packet_ioctl+0x1a1/0x380 [rtpacket]
Dec 18 14:58:13 bmm3 kernel: [  118.547264] PGD 458a90067
Dec 18 14:58:13 bmm3 kernel: [  118.547273] PUD 45a127067
Dec 18 14:58:13 bmm3 kernel: [  118.547941] PMD 4584fe067
Dec 18 14:58:13 bmm3 kernel: [  118.547946] PTE 8000000452fcb067
Dec 18 14:58:13 bmm3 kernel: [  118.548626]
Dec 18 14:58:13 bmm3 kernel: [  118.549302] Oops: 0001 [#1] SMP
Dec 18 14:58:13 bmm3 kernel: [  118.549979] Modules linked in: rt_e1000e
rt_loopback rtcfg rtudp rtipv4 rtmac rtpacket cdc_acm snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_codec_generic binfmt_misc intel_rapl
x86_pkg_temp_thermal intel_powerclamp nls_ascii coretemp nls_cp437
crct10dif_pclmul crc32_pclmul vfat ghash_clmulni_intel arc4 fat ppdev
aesni_intel ath9k i915 aes_x86_64 ath9k_common lrw ath9k_hw gf128mul glue_helper
pcan(O) ablk_helper ath cryptd mac80211 pcmcia pcmcia_core intel_cstate
drm_kms_helper efi_pstore intel_uncore drm rtnet cfg80211 i2c_algo_bit
fb_sys_fops intel_rapl_perf snd_hda_intel xeno_can_peak_pci syscopyarea
sysfillrect iTCO_wdt xeno_can_sja1000 snd_hda_codec sysimgblt xeno_can
iTCO_vendor_support sg snd_hda_core snd_hwdep mei_me snd_pcm snd_timer mei
shpchp snd soundcore evdev pcspkr serio_raw efivars
Dec 18 14:58:13 bmm3 kernel: [  118.554017]  battery hci_uart btbcm parport_pc
btqca parport btintel bluetooth wmi video rfkill intel_lpss_acpi intel_lpss
tpm_crb acpi_als kfifo_buf button industrialio sunrpc efivarfs ip_tables
x_tables autofs4 ext4 crc16 jbd2 fscrypto mbcache sd_mod crc32c_intel i2c_i801
i2c_smbus ahci libahci xhci_pci libata xhci_hcd scsi_mod usbcore fan i2c_hid hid
fjes [last unloaded: rt_e1000e]
Dec 18 14:58:13 bmm3 kernel: [  118.556765] CPU: 5 PID: 1742 Comm: slaveinfo_rt
Tainted: G           O    4.9.51-xenomai-3.0.6-ipipe #1
Dec 18 14:58:13 bmm3 kernel: [  118.557688] Hardware name: Gigabyte Technology
Co., Ltd. To be filled by O.E.M./Q170M-D3H, BIOS F2 01/11/2016
Dec 18 14:58:13 bmm3 kernel: [  118.558628] I-pipe domain: Linux
Dec 18 14:58:13 bmm3 kernel: [  118.559567] task: ffff8d711868b140 task.stack:
ffffa6a8409d4000
Dec 18 14:58:13 bmm3 kernel: [  118.560518] RIP: 0010:[<ffffffffc0743981>]
[<ffffffffc0743981>] rt_packet_ioctl+0x1a1/0x380 [rtpacket]
Dec 18 14:58:13 bmm3 kernel: [  118.561505] RSP: 0018:ffffa6a8409d7df8  EFLAGS:
00010202
Dec 18 14:58:13 bmm3 kernel: [  118.562483] RAX: ffffa6a8409d7df8 RBX:
ffff8d7118f10800 RCX: 0000000000000000
Dec 18 14:58:13 bmm3 kernel: [  118.563471] RDX: 0000000000000000 RSI:
00007ffcc7389410 RDI: ffffa6a8409d7e08
Dec 18 14:58:13 bmm3 kernel: [  118.564472] RBP: ffffa6a8409d7ec0 R08:
26009bc300000014 R09: 000000000000005d
Dec 18 14:58:13 bmm3 kernel: [  118.565473] R10: 00000000000000e4 R11:
00000000ffff4ebc R12: 0000000000000003
Dec 18 14:58:13 bmm3 kernel: [  118.566477] R13: ffff8d7118f10940 R14:
ffffa6a8402de040 R15: 00007ffcc7389470
Dec 18 14:58:13 bmm3 kernel: [  118.567485] FS:  00007f4db6a00b80(0000)
GS:ffff8d7120300000(0000) knlGS:0000000000000000
Dec 18 14:58:13 bmm3 kernel: [  118.568516] CS:  0010 DS: 0000 ES: 0000 CR0:
000000008005003b
Dec 18 14:58:13 bmm3 kernel: [  118.569560] CR2: 00007ffcc7389470 CR3:
000000045c362000 CR4: 00000000003406e0
Dec 18 14:58:13 bmm3 kernel: [  118.570617] DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Dec 18 14:58:13 bmm3 kernel: [  118.571671] DR3: 0000000000000000 DR6:
00000000fffe0ff0 DR7: 0000000000000400
Dec 18 14:58:13 bmm3 kernel: [  118.572733] Stack:
Dec 18 14:58:13 bmm3 kernel: [  118.573799]  00007ffcc7389470 26009bc300000014
ffff8d7118f10800 ffffa6a8409d7ec0
Dec 18 14:58:13 bmm3 kernel: [  118.574892]  0000000000000003 ffff8d711868b140
ffffa6a8402de040 0000000000011ba0
Dec 18 14:58:13 bmm3 kernel: [  118.575987]  ffffffff9476b9a8 00007ffcc7389400
401000221868b738 0000000000000010
Dec 18 14:58:13 bmm3 kernel: [  118.577088] Call Trace:
Dec 18 14:58:13 bmm3 kernel: [  118.578180]  [<ffffffff9476b9a8>] ?
rtdm_fd_ioctl+0xa8/0x1e0
Dec 18 14:58:13 bmm3 kernel: [  118.579278]  [<ffffffff94770b20>] ?
CoBaLt_fcntl+0x10/0x10
Dec 18 14:58:13 bmm3 kernel: [  118.580377]  [<ffffffff9468298d>] ?
__ipipe_migrate_head+0x4d/0xb0
Dec 18 14:58:13 bmm3 kernel: [  118.581452]  [<ffffffff94770b20>] ?
CoBaLt_fcntl+0x10/0x10
Dec 18 14:58:13 bmm3 kernel: [  118.582541]  [<ffffffff94770b2a>] ?
CoBaLt_ioctl+0xa/0x10
Dec 18 14:58:13 bmm3 kernel: [  118.583625]  [<ffffffff947807ac>] ?
ipipe_syscall_hook+0xfc/0x2b0
Dec 18 14:58:13 bmm3 kernel: [  118.584698]  [<ffffffff946fad9a>] ?
__ipipe_notify_syscall+0xba/0x170
Dec 18 14:58:13 bmm3 kernel: [  118.585774]  [<ffffffff94b868af>] ?
pipeline_syscall+0x8/0x1b
Dec 18 14:58:13 bmm3 kernel: [  118.586836] Code: 5f c3 b9 10 00 00 00 48 89 e6
e8 7b 36 14 00 48 3d 00 f0 ff ff 77 d8 83 78 08 13 4c 8b 38 4c 8d ab 40 01 00 00
0f 86 73 01 00 00 <66> 41 83 3f 11 0f 85 68 01 00 00 41 0f b7 6f 02 66 85 ed 0f 84
Dec 18 14:58:13 bmm3 kernel: [  118.589196] RIP  [<ffffffffc0743981>]
rt_packet_ioctl+0x1a1/0x380 [rtpacket]
Dec 18 14:58:13 bmm3 kernel: [  118.590308]  RSP <ffffa6a8409d7df8>
Dec 18 14:58:13 bmm3 kernel: [  118.591414] CR2: 00007ffcc7389470
Dec 18 14:58:13 bmm3 kernel: [  118.592528] ---[ end trace 7e353ae197f2ee95 ]---

#######################################################3

So, I'm sorry, but it still fails.

And about the addr2line for this case, some help for dummies will be helpful.

Leopold


-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [Xenomai] RTnet fixes - testers needed

[Philippe Gerum]

On 12/15/2017 01:25 PM, 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:
> 

Please confirm that you are running wip/rtnet-fixes, and not
stable-3.0.x or next which are still plagued with direct usermem access
bugs. The backtrace shows SMAP biting in rt_packet_ioctl(), which is
actually the first routine I fixed in the AF_PACKET layer, removing such
invalid accesses, since I need that one.

If you still have this issue over the wip/rtnet-fixes branch, then
please use addr2line to find out which source line triggers the bug in
af_packet.c.

Thanks,

-- 
Philippe.

Re: [Xenomai] RTnet fixes - testers needed

[Leopold Palomo-Avellaneda]

El 15/12/17 a les 21:47, Philippe Gerum ha escrit:
> On 12/15/2017 01:25 PM, 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:
>>
> 
> Please confirm that you are running wip/rtnet-fixes, and not
> stable-3.0.x or next which are still plagued with direct usermem access
> bugs. The backtrace shows SMAP biting in rt_packet_ioctl(), which is
> actually the first routine I fixed in the AF_PACKET layer, removing such
> invalid accesses, since I need that one.

well, I'm remotely connected to my robotic platform and it seems that it's the
version that I built on monday 3.0.6+ds2rtnet-1~drp9+20171211. I built it from:

xenomai-3.git (wip/rtnet-fixes)$

and these are the last two entries of the git:

commit c640a6040e72c7597d06b119d3ce30fbf3408e82
Author: Philippe Gerum <rpm@xenomai.org>
Date:   Wed Dec 6 13:41:06 2017 +0100

    net/iovec: drop useless kernel<-> iovec[] copy helpers

    No more in-tree users for those, in the wake of dropping the broken
    direct references from the kernel to user-space memory.

commit 64d2b7657ce4bddb2e2cc1a209dfedfa01000502
Author: Philippe Gerum <rpm@xenomai.org>
Date:   Wed Dec 6 13:40:19 2017 +0100

    net: convert to rtdm_get_iov_flatlen()


> If you still have this issue over the wip/rtnet-fixes branch, then
> please use addr2line to find out which source line triggers the bug in
> af_packet.c.

ok, on monday I will check again and I try to follow your indications.

Best regards,

Leopold

Re: [Xenomai] RTnet fixes - testers needed

[Andreas Glatz]

>
> I pushed a pile of RTnet fixes in a WIP branch of the official repo
> (wip/rtnet-fixes). Most of them address invalid direct references to
> user memory from kernel space (instead of properly copying back and
> forth via the copy_from/to_user interface), which are badly wrong at any
> rate, even breaking the kernel on SMAP-enabled x86 platforms.
>
> Most I/O calls were affected, ioctl, sendmsg and recvmsg. I'm still in
> the early process of testing the changes gradually, which involves
> running tests for all socket levels (RAW, DGRAM) and protocols (INET,
> PACKET) enabled.
>
> If you depend on RTnet and want to help with testing, you may want to
> give this branch a try. Any help with reviewing the changes would be
> beneficial to the project too.
>

I merged the most recent ipipe version for the 4.9.y kernel into
4.9.69 and patched it with xenomai 3 from the WIP branch (see snip1
below). The kernel boots on the Wandboard with an imx.6 quad. I then
can load the rtnet modules including the rt_fec.ko driver for the FEC
MAC on the imx.6 SoC (see snip2 below) and rtping works. I compiled
and started a udp server [1] that I know works on a similar setup with
the 4.1.y kernel. However, I still see a page domain fault (see snip3
below). That seems to happen somewhere early on in the rt_udp_bind()
function.... I'm currently compiling the 4.9 kernel with debug symbols
to see where it exactly happens. I'll continue looking into it
tomorrow...

A.





[1] http://www.binarytides.com/programming-udp-sockets-c-linux/

<snip1>
debian@arm:~$ cat /proc/version
Linux version 4.9.69-armv7-x6 (agl@TheMint) (gcc version 6.4.1
20171012 (Linaro GCC 6.4-2017.11) ) #5 SMP Sat Dec 16 20:05:17 GMT
2017
debian@arm:~$ cat /proc/xenomai/version
3.0.6
debian@arm:~$ cat /proc/rtnet/version
RTnet for Xenomai v3.0.6
RTcap:      yes
rtnetproxy: yes
bug checks: no
</snip1>

<snip2>
debian@arm:~$ lsmod
Module                  Size  Used by
rt_fec                 16499  1
rtpacket                9149  0
rtudp                  14691  2
rtipv4                 41477  1 rtudp
rt_loopback             1825  1
rtnet                  57796  5 rtipv4,rt_loopback,rtpacket,rt_fec,rtudp
...
</snip2>

<snip3>
root@arm:/home/debian# env LD_LIBRARY_PATH=/usr/xenomai/lib ./server
[ 3425.960029] Unhandled fault: page domain fault (0x01b) at 0xbef98c0a
[ 3425.966405] pgd = ebbbc000
[ 3425.969125] [bef98c0a] *pgd=8f8f1831
[ 3425.972739] Internal error: : 1b [#2] SMP ARM
[ 3425.977107] Modules linked in: rt_fec rtpacket rtudp rtipv4
rt_loopback rtnet caam_jr iptable_nat nf_conntrack_ipv4 ]
[ 3426.024101] CPU: 0 PID: 1822 Comm: server Tainted: G      D
4.9.69-armv7-x6 #5
[ 3426.032028] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 3426.038564] I-pipe domain: Linux
[ 3426.041803] task: ecf2e1c0 task.stack: eb330000
[ 3426.046366] PC is at rt_udp_bind+0x2c/0x38c [rtudp]
[ 3426.051268] LR is at rt_udp_ioctl+0xa4/0xb4 [rtudp]
[ 3426.056158] pc : [<bf4af3c0>]    lr : [<bf4afa24>]    psr: 200e0013
[ 3426.056158] sp : eb331e68  ip : bf4af3ac  fp : eb331ea4
[ 3426.067647] r10: bef98c08  r9 : ed4df824  r8 : 00000003
[ 3426.072882] r7 : 0000fef8  r6 : ed4df800  r5 : 40080022  r4 : c160418c
[ 3426.079419] r3 : eb331ea8  r2 : 00040945  r1 : bef98c08  r0 : ed4df824
[ 3426.085956] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[ 3426.093100] Control: 10c5387d  Table: 3bbbc04a  DAC: 00000051
[ 3426.098856] Process server (pid: 1822, stack limit = 0xeb330220)
[ 3426.104874] Stack: (0xeb331e68 to 0xeb332000)
[ 3426.109247] 1e60:                   00000000 00000051 ed4df800
c160418c 00000003 c160418c
[ 3426.117441] 1e80: 40080022 ed4df800 c160418c 00000003 40080022
c15159b4 eb331ecc eb331ea8
[ 3426.125632] 1ea0: bf4afa24 bf4af3a0 bef98c08 00040945 eb331fb0
ed4df800 c1517cf4 800e0013
[ 3426.133824] 1ec0: eb331f10 eb331ed0 c0299dd0 bf4af98c c027dedc
c01183a4 00000000 bef989c8
[ 3426.142015] 1ee0: eb331f18 00040945 eb331fb0 00000052 c160504c
f0936008 00000001 c029eb3c
[ 3426.150207] 1f00: c15159b4 eb331f2c eb331f20 c029eb54 c0299d2c
40080022 bef989c8 bef989c8
[ 3426.158398] 1f20: eb331f64 eb331f30 c02ac9a0 c029eb48 40080022
00000000 eb331fa4 eed959b4
[ 3426.166589] 1f40: 00000001 eed969b4 c160504c c1820600 c1820600
c15159b4 eb331fac eb331f68
[ 3426.174780] 1f60: c02236bc c02ac874 c15159b4 c1517cf4 c1820600
eb331fb0 c1820600 200e0013
[ 3426.182973] 1f80: b6f476e0 bef989c8 40080022 00000003 000f0042
c0109668 eb330000 00000002
[ 3426.191164] 1fa0: 00000000 eb331fb0 c01095b4 c02235b0 10000050
00000003 40080022 bef989c8
[ 3426.199355] 1fc0: bef989c8 40080022 00000003 000f0042 00000000
00000000 b6f70000 00000000
[ 3426.207545] 1fe0: b6f470dc bef989a8 00000000 b6f2ee72 000e0030
10000050 ffffffff ffffffff
[ 3426.215770] [<bf4af3c0>] (rt_udp_bind [rtudp]) from [<bf4afa24>]
(rt_udp_ioctl+0xa4/0xb4 [rtudp])
[ 3426.224681] [<bf4afa24>] (rt_udp_ioctl [rtudp]) from [<c0299dd0>]
(rtdm_fd_ioctl+0xb4/0x214)
[ 3426.233145] [<c0299dd0>] (rtdm_fd_ioctl) from [<c029eb54>]
(CoBaLt_ioctl+0x18/0x1c)
[ 3426.240823] [<c029eb54>] (CoBaLt_ioctl) from [<c02ac9a0>]
(ipipe_syscall_hook+0x138/0x370)
[ 3426.249109] [<c02ac9a0>] (ipipe_syscall_hook) from [<c02236bc>]
(__ipipe_notify_syscall+0x118/0x1dc)
[ 3426.258266] [<c02236bc>] (__ipipe_notify_syscall) from [<c01095b4>]
(pipeline_syscall+0x8/0x24)
[ 3426.266982] Code: e1a09000 e1a0a001 9a0000cc e30f7ef8 (e1d130b2)
[ 3426.273092] ---[ end trace 08b1f9b9e22886fc ]---
</snip3>

Re: [Xenomai] RTnet fixes - testers needed

[Philippe Gerum]

On 12/17/2017 12:01 AM, Andreas Glatz wrote:
>>
>> I pushed a pile of RTnet fixes in a WIP branch of the official repo
>> (wip/rtnet-fixes). Most of them address invalid direct references to
>> user memory from kernel space (instead of properly copying back and
>> forth via the copy_from/to_user interface), which are badly wrong at any
>> rate, even breaking the kernel on SMAP-enabled x86 platforms.
>>
>> Most I/O calls were affected, ioctl, sendmsg and recvmsg. I'm still in
>> the early process of testing the changes gradually, which involves
>> running tests for all socket levels (RAW, DGRAM) and protocols (INET,
>> PACKET) enabled.
>>
>> If you depend on RTnet and want to help with testing, you may want to
>> give this branch a try. Any help with reviewing the changes would be
>> beneficial to the project too.
>>
> 
> I merged the most recent ipipe version for the 4.9.y kernel into
> 4.9.69 and patched it with xenomai 3 from the WIP branch (see snip1
> below). The kernel boots on the Wandboard with an imx.6 quad. I then
> can load the rtnet modules including the rt_fec.ko driver for the FEC
> MAC on the imx.6 SoC (see snip2 below) and rtping works. I compiled
> and started a udp server [1] that I know works on a similar setup with
> the 4.1.y kernel. However, I still see a page domain fault (see snip3
> below). That seems to happen somewhere early on in the rt_udp_bind()
> function.... I'm currently compiling the 4.9 kernel with debug symbols
> to see where it exactly happens. I'll continue looking into it
> tomorrow...
> 

Thanks. You may need that patch:

diff --git a/kernel/drivers/net/stack/ipv4/udp/udp.c b/kernel/drivers/net/stack/ipv4/udp/udp.c
index a3fd496f3..436830341 100644
--- a/kernel/drivers/net/stack/ipv4/udp/udp.c
+++ b/kernel/drivers/net/stack/ipv4/udp/udp.c
@@ -350,7 +350,7 @@ int rt_udp_ioctl(struct rtdm_fd *fd, unsigned int request, void __user *arg)
 {
 	struct rtsocket *sock = rtdm_fd_to_private(fd);
 	const struct _rtdm_setsockaddr_args *setaddr;
-	struct _rtdm_setsockaddr_args *_setaddr;
+	struct _rtdm_setsockaddr_args _setaddr;
 
 	/* fast path for common socket IOCTLs */
 	if (_IOC_TYPE(request) == RTIOC_TYPE_NETWORK)-- 

--
Philippe.

Re: [Xenomai] RTnet fixes - testers needed

[Andreas Glatz]

On Sun, Dec 17, 2017 at 2:25 PM, Philippe Gerum <rpm@xenomai.org> wrote:
> On 12/17/2017 12:01 AM, Andreas Glatz wrote:
>>>
>>> I pushed a pile of RTnet fixes in a WIP branch of the official repo
>>> (wip/rtnet-fixes). Most of them address invalid direct references to
>>> user memory from kernel space (instead of properly copying back and
>>> forth via the copy_from/to_user interface), which are badly wrong at any
>>> rate, even breaking the kernel on SMAP-enabled x86 platforms.
>>>
...
>> below). That seems to happen somewhere early on in the rt_udp_bind()
>> function.... I'm currently compiling the 4.9 kernel with debug symbols
>> to see where it exactly happens. I'll continue looking into it
>> tomorrow...
>>
>
> Thanks. You may need that patch:
>
> diff --git a/kernel/drivers/net/stack/ipv4/udp/udp.c b/kernel/drivers/net/stack/ipv4/udp/udp.c
> index a3fd496f3..436830341 100644
> --- a/kernel/drivers/net/stack/ipv4/udp/udp.c
> +++ b/kernel/drivers/net/stack/ipv4/udp/udp.c
> @@ -350,7 +350,7 @@ int rt_udp_ioctl(struct rtdm_fd *fd, unsigned int request, void __user *arg)
>  {
>         struct rtsocket *sock = rtdm_fd_to_private(fd);
>         const struct _rtdm_setsockaddr_args *setaddr;
> -       struct _rtdm_setsockaddr_args *_setaddr;
> +       struct _rtdm_setsockaddr_args _setaddr;
>
>         /* fast path for common socket IOCTLs */
>         if (_IOC_TYPE(request) == RTIOC_TYPE_NETWORK)--
>

Unfortunately, that wasn't everything for rt_udp_bind() and
rt_udp_connect() as the initial pointer to struct sockaddr_in was
still a user space pointer and accessing it caused a page domain
fault. Currently, I came up with the patch below with which I get
positive results for rt_udp_bind() and rt_udp_connect(). However,
there's still something wrong in rt_udp_recvmsg() and rt_udp_sendmsg()
(see backtrace further below). Notice also the patch in
rt_udp_recvmsg(): msg->msg_header is another userspace pointer inside
msg. Hence, it has to be used to copy back the struct sockaddr_in
stuff to the user. More tomorrow...

<snip1>
diff --git a/kernel/drivers/net/stack/ipv4/udp/udp.c
b/kernel/drivers/net/stack/ipv4/udp/udp.c
index a3fd496..1beb56f 100644
--- a/kernel/drivers/net/stack/ipv4/udp/udp.c
+++ b/kernel/drivers/net/stack/ipv4/udp/udp.c
@@ -154,17 +154,14 @@ static inline struct rtsocket
*rt_udp_v4_lookup(u32 daddr, u16 dport)
  *  @s:     socket
  *  @addr:  local address
  */
-int rt_udp_bind(struct rtsocket *sock, const struct sockaddr *addr,
-                socklen_t addrlen)
+int rt_udp_bind(struct rtsocket *sock, const struct sockaddr_in *usin)
 {
-    struct sockaddr_in  *usin = (struct sockaddr_in *)addr;
     rtdm_lockctx_t      context;
     int                 index;
     int                 err = 0;


-    if ((addrlen < (int)sizeof(struct sockaddr_in)) ||
-        ((usin->sin_port & auto_port_mask) == auto_port_start))
+    if ((usin->sin_port & auto_port_mask) == auto_port_start)
         return -EINVAL;

     rtdm_lock_get_irqsave(&udp_socket_base_lock, context);
@@ -207,10 +204,8 @@ int rt_udp_bind(struct rtsocket *sock, const
struct sockaddr *addr,
 /***
  *  rt_udp_connect
  */
-int rt_udp_connect(struct rtsocket *sock, const struct sockaddr *serv_addr,
-                   socklen_t addrlen)
+int rt_udp_connect(struct rtsocket *sock, const struct sockaddr_in *usin)
 {
-    struct sockaddr_in  *usin = (struct sockaddr_in *) serv_addr;
     rtdm_lockctx_t      context;
     int                 index;

@@ -233,8 +228,7 @@ int rt_udp_connect(struct rtsocket *sock, const
struct sockaddr *serv_addr,

         rtdm_lock_put_irqrestore(&udp_socket_base_lock, context);
     } else {
-        if ((addrlen < (int)sizeof(struct sockaddr_in)) ||
-            (usin->sin_family != AF_INET))
+        if (usin->sin_family != AF_INET)
             return -EINVAL;

         rtdm_lock_get_irqsave(&udp_socket_base_lock, context);
@@ -350,7 +344,9 @@ int rt_udp_ioctl(struct rtdm_fd *fd, unsigned int
request, void __user *arg)
 {
        struct rtsocket *sock = rtdm_fd_to_private(fd);
        const struct _rtdm_setsockaddr_args *setaddr;
-       struct _rtdm_setsockaddr_args *_setaddr;
+       struct _rtdm_setsockaddr_args _setaddr;
+       const struct sockaddr_in *usin;
+       struct sockaddr_in _usin;

        /* fast path for common socket IOCTLs */
        if (_IOC_TYPE(request) == RTIOC_TYPE_NETWORK)
@@ -362,10 +358,18 @@ int rt_udp_ioctl(struct rtdm_fd *fd, unsigned
int request, void __user *arg)
                setaddr = rtnet_get_arg(fd, &_setaddr, arg, sizeof(_setaddr));
                if (IS_ERR(setaddr))
                        return PTR_ERR(setaddr);
-               if (request == _RTIOC_BIND)
-                       return rt_udp_bind(sock, setaddr->addr,
setaddr->addrlen);
+
+               if (setaddr->addrlen < (int)sizeof(struct sockaddr_in))
+                       return -EINVAL;
+
+               usin = rtnet_get_arg(fd, &_usin, setaddr->addr,
setaddr->addrlen);
+               if (IS_ERR(usin))
+                       return PTR_ERR(usin);

-               return rt_udp_connect(sock, setaddr->addr, setaddr->addrlen);
+               if (request == _RTIOC_BIND)
+                       return rt_udp_bind(sock, usin);
+               else
+                       return rt_udp_connect(sock, usin);

         default:
                return rt_ip_ioctl(fd, request, arg);
@@ -380,7 +384,7 @@ int rt_udp_ioctl(struct rtdm_fd *fd, unsigned int
request, void __user *arg)
 /***
  *  rt_udp_recvmsg
  */
-ssize_t rt_udp_recvmsg(struct rtdm_fd *fd, struct user_msghdr *msg,
int msg_flags)
+ssize_t rt_udp_recvmsg(struct rtdm_fd *fd, struct user_msghdr
*msg_hdr, int msg_flags)
 {
     struct rtsocket     *sock = rtdm_fd_to_private(fd);
     size_t              len;
@@ -393,11 +397,11 @@ ssize_t rt_udp_recvmsg(struct rtdm_fd *fd,
struct user_msghdr *msg, int msg_flag
     struct sockaddr_in  sin;
     nanosecs_rel_t      timeout = sock->timeout;
     int                 ret, flags;
-    struct user_msghdr _msg;
+    struct user_msghdr  *msg, _msg;
     socklen_t namelen;
     struct iovec iov_fast[RTDM_IOV_FASTMAX], *iov;

-    msg = rtnet_get_arg(fd, &_msg, msg, sizeof(*msg));
+    msg = rtnet_get_arg(fd, &_msg, msg_hdr, sizeof(_msg));
    if (IS_ERR(msg))
            return PTR_ERR(msg);

@@ -438,7 +442,7 @@ ssize_t rt_udp_recvmsg(struct rtdm_fd *fd, struct
user_msghdr *msg, int msg_flag
            sin.sin_family      = AF_INET;
            sin.sin_port        = uh->source;
            sin.sin_addr.s_addr = skb->nh.iph->saddr;
-           ret = rtnet_put_arg(fd, &msg->msg_name, &sin, sizeof(sin));
+           ret = rtnet_put_arg(fd, msg->msg_name, &sin, sizeof(sin));
            if (ret)
                    goto fail;

@@ -489,6 +493,7 @@ ssize_t rt_udp_recvmsg(struct rtdm_fd *fd, struct
user_msghdr *msg, int msg_flag
            if (ret)
                    goto fail;
     }
+
 out:
     if ((msg_flags & MSG_PEEK) == 0)
         kfree_rtskb(first_skb);
</snip1>


<snip2>
[ 1462.954012] Unhandled fault: page domain fault (0x01b) at 0xbe90e9a4
[ 1462.963089] pgd = ebb3c000
[ 1462.967451] [be90e9a4] *pgd=8d0f8831
[ 1462.971317] Internal error: : 1b [#3] SMP ARM
[ 1462.975685] Modules linked in: rtudp rt_fec rtpacket rtipv4
rt_loopback rtnet 8021q garp mrp stp llc iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_na]
[ 1463.024766] CPU: 3 PID: 1464 Comm: server Tainted: G      D
4.9.69-armv7-x6 #7
[ 1463.032692] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 1463.039227] I-pipe domain: Linux
[ 1463.042465] task: ee107140 task.stack: eced8000
[ 1463.047031] PC is at rt_udp_getfrag+0x44/0x124 [rtudp]
[ 1463.052235] LR is at rt_ip_build_xmit+0x238/0x304 [rtipv4]
[ 1463.057734] pc : [<bf043c14>]    lr : [<bf01b3b4>]    psr: 200b0013
               sp : eced9ce8  ip : bf043be8  fp : eced9d0c
[ 1463.069220] r10: eb8bce24  r9 : 00000000  r8 : 0000000d
[ 1463.074454] r7 : eb3a4864  r6 : 0000000d  r5 : eced9dac  r4 : 00000000
[ 1463.080990] r3 : be90e9a4  r2 : 00000000  r1 : eb3a4864  r0 : 00000000
[ 1463.087530] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[ 1463.094675] Control: 10c5387d  Table: 3bb3c04a  DAC: 00000051
[ 1463.100431] Process server (pid: 1464, stack limit = 0xeced8220)
[ 1463.106448] Stack: (0xeced9ce8 to 0xeceda000)
[ 1463.110823] 9ce0:                   eced9d0c eced9cf8 eb317400
00002100 eb3a47c0 eb3a4864
[ 1463.119016] 9d00: eced9d64 eced9d10 bf01b3b4 bf043bdc eced9db4
eced9d20 c0189c30 6c03a8c0
[ 1463.127207] 9d20: eced9ddc bf01e718 eced9dac bf043bd0 0000000f
0000000d eced9d64 c160418c
[ 1463.135397] 9d40: 00000005 eced9ddc 00000000 eb8bce00 eced9e04
00000000 eced9eb4 eced9d68
[ 1463.143590] 9d60: bf0440dc bf01b188 eced9ddc 00000000 5003a8c0
00007491 6c03a8c0 c1516b54
[ 1463.151780] 9d80: c160504c 00000000 c0223168 eced9e04 be90ebf8
00000010 be90e9a4 00000001
[ 1463.159971] 9da0: 00000000 00000000 00000000 7491b822 00000d00
6c03a8c0 5003a8c0 eb8bce00
[ 1463.168163] 9dc0: be90e9a4 00000001 00000000 74910002 6c03a8c0
00000000 00000000 6c03a8c0
[ 1463.176352] 9de0: b5cb1600 00003ab6 00000000 00000000 00000000
00000000 00000000 00000000
[ 1463.184545] 9e00: eb317400 be90e9f4 00000005 c0170f24 eced9e44
eced9e20 c0170f24 c01130c0
[ 1463.192734] 9e20: c177b088 00000001 00000002 ee118000 00000000
00000000 eced9e64 eced9e48
[ 1463.200926] 9e40: c0222efc c01183a4 c1516b54 c160504c 00000000
00000000 eced9e94 eced9e68
[ 1463.209117] 9e60: c029907c c0222ee8 be90ebf8 c160418c 00000003
00000000 00000003 00000000
[ 1463.217309] 9e80: eced9ef0 00040945 eced9eb4 eb8bce00 c1517cf4
800b0013 00000003 00000000
[ 1463.225501] 9ea0: eced9ef0 c15159b4 eced9eec eced9eb8 c0299b38
bf043d00 ed3bac08 c1517d44
[ 1463.233692] 9ec0: c1648aa4 c160418c 00000003 00000000 00000051
00000001 c029ecb0 c15159b4
[ 1463.241884] 9ee0: eced9f2c eced9ef0 c029ed60 c0299ab0 be90ebf8
00000010 be90e9a4 00000001
[ 1463.250076] 9f00: 00000000 00000000 00000000 00040945 eced9fb0
00000052 c160504c f0936008
[ 1463.258267] 9f20: eced9f64 eced9f30 c02ac9a0 c029ecbc be90e9ac
c0365388 ed3bac00 eedcb9b4
[ 1463.266457] 9f40: 00000001 eedcc9b4 c160504c c1820600 c1820600
c15159b4 eced9fac eced9f68
[ 1463.274648] 9f60: c02236bc c02ac874 c15159b4 c1517cf4 c1820600
eced9fb0 c1820600 200b0013
[ 1463.282838] 9f80: 009fc6d0 00000000 be90e9ac 00000003 000f0042
c0109668 eced8000 00000002
[ 1463.291029] 9fa0: 00000000 eced9fb0 c01095b4 c02235b0 10000054
00000003 be90e9ac 00000000
[ 1463.299220] 9fc0: 00000000 be90e9ac 00000003 000f0042 be90e9f4
00000005 00000000 00000000
[ 1463.307410] 9fe0: b6f860dc be90e978 00000000 b6f6dee2 000b0030
10000054 65725f65 656d7573
[ 1463.315687] [<bf043c14>] (rt_udp_getfrag [rtudp]) from [<bf01b3b4>]
(rt_ip_build_xmit+0x238/0x304 [rtipv4])
[ 1463.325502] [<bf01b3b4>] (rt_ip_build_xmit [rtipv4]) from
[<bf0440dc>] (rt_udp_sendmsg+0x3e8/0x460 [rtudp])
[ 1463.335279] [<bf0440dc>] (rt_udp_sendmsg [rtudp]) from [<c0299b38>]
(rtdm_fd_sendmsg+0x94/0x1cc)
[ 1463.344088] [<c0299b38>] (rtdm_fd_sendmsg) from [<c029ed60>]
(CoBaLt_sendmsg+0xb0/0xb8)
[ 1463.352113] [<c029ed60>] (CoBaLt_sendmsg) from [<c02ac9a0>]
(ipipe_syscall_hook+0x138/0x370)
[ 1463.360571] [<c02ac9a0>] (ipipe_syscall_hook) from [<c02236bc>]
(__ipipe_notify_syscall+0x118/0x1dc)
[ 1463.369727] [<c02236bc>] (__ipipe_notify_syscall) from [<c01095b4>]
(pipeline_syscall+0x8/0x24)
[ 1463.378444] Code: c590001c da00000a e5953014 e1a02000 (e7930184)
[ 1463.384554] ---[ end trace f8a046fb32eafdc5 ]---
</snip2>

Re: [Xenomai] RTnet fixes - testers needed

[Andreas Glatz]

>
> I have pulled wip/rtnet-fixes branch with the last commit of Philippe from Sun
> Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type
>
> I have created the packages and new kernel with the same configuration that I had.
>
> I run my application, that it's a POSIX application Wrapped and I still have the
> same error when I activate SMAP:

I see that the page fault occurs in rt_packet_ioctl()... by the looks
of this bug it might be similar to the one I found in udp.c (see my
post from Sunday)... basically the ioctl still tries to access user
memory, which causes that stack trace. I'm currently a bit busy - I
hope I can continue debugging this by the end of this week. In the
meantime could you recompile your kernel with debug info which should
improve the kernel bug output?

Cheers,

A.

>
> #######################################################3
>
> Dec 18 14:58:13 bmm3 kernel: [  118.545908] [Xenomai] switching slaveinfo_rt to
> secondary mode after exception #14 in kernel-space at 0xffffffffc0743981 (pid 1742)
> Dec 18 14:58:13 bmm3 kernel: [  118.545924] BUG: unable to handle kernel paging
> request at 00007ffcc7389470
> Dec 18 14:58:13 bmm3 kernel: [  118.546586] IP: [<ffffffffc0743981>]
> rt_packet_ioctl+0x1a1/0x380 [rtpacket]
> Dec 18 14:58:13 bmm3 kernel: [  118.547264] PGD 458a90067
> Dec 18 14:58:13 bmm3 kernel: [  118.547273] PUD 45a127067
> Dec 18 14:58:13 bmm3 kernel: [  118.547941] PMD 4584fe067
> Dec 18 14:58:13 bmm3 kernel: [  118.547946] PTE 8000000452fcb067
> Dec 18 14:58:13 bmm3 kernel: [  118.548626]
> Dec 18 14:58:13 bmm3 kernel: [  118.549302] Oops: 0001 [#1] SMP
> Dec 18 14:58:13 bmm3 kernel: [  118.549979] Modules linked in: rt_e1000e
> rt_loopback rtcfg rtudp rtipv4 rtmac rtpacket cdc_acm snd_hda_codec_hdmi
> snd_hda_codec_realtek snd_hda_codec_generic binfmt_misc intel_rapl
> x86_pkg_temp_thermal intel_powerclamp nls_ascii coretemp nls_cp437
> crct10dif_pclmul crc32_pclmul vfat ghash_clmulni_intel arc4 fat ppdev
> aesni_intel ath9k i915 aes_x86_64 ath9k_common lrw ath9k_hw gf128mul glue_helper
> pcan(O) ablk_helper ath cryptd mac80211 pcmcia pcmcia_core intel_cstate
> drm_kms_helper efi_pstore intel_uncore drm rtnet cfg80211 i2c_algo_bit
> fb_sys_fops intel_rapl_perf snd_hda_intel xeno_can_peak_pci syscopyarea
> sysfillrect iTCO_wdt xeno_can_sja1000 snd_hda_codec sysimgblt xeno_can
> iTCO_vendor_support sg snd_hda_core snd_hwdep mei_me snd_pcm snd_timer mei
> shpchp snd soundcore evdev pcspkr serio_raw efivars
> Dec 18 14:58:13 bmm3 kernel: [  118.554017]  battery hci_uart btbcm parport_pc
> btqca parport btintel bluetooth wmi video rfkill intel_lpss_acpi intel_lpss
> tpm_crb acpi_als kfifo_buf button industrialio sunrpc efivarfs ip_tables
> x_tables autofs4 ext4 crc16 jbd2 fscrypto mbcache sd_mod crc32c_intel i2c_i801
> i2c_smbus ahci libahci xhci_pci libata xhci_hcd scsi_mod usbcore fan i2c_hid hid
> fjes [last unloaded: rt_e1000e]
> Dec 18 14:58:13 bmm3 kernel: [  118.556765] CPU: 5 PID: 1742 Comm: slaveinfo_rt
> Tainted: G           O    4.9.51-xenomai-3.0.6-ipipe #1
> Dec 18 14:58:13 bmm3 kernel: [  118.557688] Hardware name: Gigabyte Technology
> Co., Ltd. To be filled by O.E.M./Q170M-D3H, BIOS F2 01/11/2016
> Dec 18 14:58:13 bmm3 kernel: [  118.558628] I-pipe domain: Linux
> Dec 18 14:58:13 bmm3 kernel: [  118.559567] task: ffff8d711868b140 task.stack:
> ffffa6a8409d4000
> Dec 18 14:58:13 bmm3 kernel: [  118.560518] RIP: 0010:[<ffffffffc0743981>]
> [<ffffffffc0743981>] rt_packet_ioctl+0x1a1/0x380 [rtpacket]
> Dec 18 14:58:13 bmm3 kernel: [  118.561505] RSP: 0018:ffffa6a8409d7df8  EFLAGS:
> 00010202
> Dec 18 14:58:13 bmm3 kernel: [  118.562483] RAX: ffffa6a8409d7df8 RBX:
> ffff8d7118f10800 RCX: 0000000000000000
> Dec 18 14:58:13 bmm3 kernel: [  118.563471] RDX: 0000000000000000 RSI:
> 00007ffcc7389410 RDI: ffffa6a8409d7e08
> Dec 18 14:58:13 bmm3 kernel: [  118.564472] RBP: ffffa6a8409d7ec0 R08:
> 26009bc300000014 R09: 000000000000005d
> Dec 18 14:58:13 bmm3 kernel: [  118.565473] R10: 00000000000000e4 R11:
> 00000000ffff4ebc R12: 0000000000000003
> Dec 18 14:58:13 bmm3 kernel: [  118.566477] R13: ffff8d7118f10940 R14:
> ffffa6a8402de040 R15: 00007ffcc7389470
> Dec 18 14:58:13 bmm3 kernel: [  118.567485] FS:  00007f4db6a00b80(0000)
> GS:ffff8d7120300000(0000) knlGS:0000000000000000
> Dec 18 14:58:13 bmm3 kernel: [  118.568516] CS:  0010 DS: 0000 ES: 0000 CR0:
> 000000008005003b
> Dec 18 14:58:13 bmm3 kernel: [  118.569560] CR2: 00007ffcc7389470 CR3:
> 000000045c362000 CR4: 00000000003406e0
> Dec 18 14:58:13 bmm3 kernel: [  118.570617] DR0: 0000000000000000 DR1:
> 0000000000000000 DR2: 0000000000000000
> Dec 18 14:58:13 bmm3 kernel: [  118.571671] DR3: 0000000000000000 DR6:
> 00000000fffe0ff0 DR7: 0000000000000400
> Dec 18 14:58:13 bmm3 kernel: [  118.572733] Stack:
> Dec 18 14:58:13 bmm3 kernel: [  118.573799]  00007ffcc7389470 26009bc300000014
> ffff8d7118f10800 ffffa6a8409d7ec0
> Dec 18 14:58:13 bmm3 kernel: [  118.574892]  0000000000000003 ffff8d711868b140
> ffffa6a8402de040 0000000000011ba0
> Dec 18 14:58:13 bmm3 kernel: [  118.575987]  ffffffff9476b9a8 00007ffcc7389400
> 401000221868b738 0000000000000010
> Dec 18 14:58:13 bmm3 kernel: [  118.577088] Call Trace:
> Dec 18 14:58:13 bmm3 kernel: [  118.578180]  [<ffffffff9476b9a8>] ?
> rtdm_fd_ioctl+0xa8/0x1e0
> Dec 18 14:58:13 bmm3 kernel: [  118.579278]  [<ffffffff94770b20>] ?
> CoBaLt_fcntl+0x10/0x10
> Dec 18 14:58:13 bmm3 kernel: [  118.580377]  [<ffffffff9468298d>] ?
> __ipipe_migrate_head+0x4d/0xb0
> Dec 18 14:58:13 bmm3 kernel: [  118.581452]  [<ffffffff94770b20>] ?
> CoBaLt_fcntl+0x10/0x10
> Dec 18 14:58:13 bmm3 kernel: [  118.582541]  [<ffffffff94770b2a>] ?
> CoBaLt_ioctl+0xa/0x10
> Dec 18 14:58:13 bmm3 kernel: [  118.583625]  [<ffffffff947807ac>] ?
> ipipe_syscall_hook+0xfc/0x2b0
> Dec 18 14:58:13 bmm3 kernel: [  118.584698]  [<ffffffff946fad9a>] ?
> __ipipe_notify_syscall+0xba/0x170
> Dec 18 14:58:13 bmm3 kernel: [  118.585774]  [<ffffffff94b868af>] ?
> pipeline_syscall+0x8/0x1b
> Dec 18 14:58:13 bmm3 kernel: [  118.586836] Code: 5f c3 b9 10 00 00 00 48 89 e6
> e8 7b 36 14 00 48 3d 00 f0 ff ff 77 d8 83 78 08 13 4c 8b 38 4c 8d ab 40 01 00 00
> 0f 86 73 01 00 00 <66> 41 83 3f 11 0f 85 68 01 00 00 41 0f b7 6f 02 66 85 ed 0f 84
> Dec 18 14:58:13 bmm3 kernel: [  118.589196] RIP  [<ffffffffc0743981>]
> rt_packet_ioctl+0x1a1/0x380 [rtpacket]
> Dec 18 14:58:13 bmm3 kernel: [  118.590308]  RSP <ffffa6a8409d7df8>
> Dec 18 14:58:13 bmm3 kernel: [  118.591414] CR2: 00007ffcc7389470
> Dec 18 14:58:13 bmm3 kernel: [  118.592528] ---[ end trace 7e353ae197f2ee95 ]---
>
> #######################################################3
>
> So, I'm sorry, but it still fails.
>
> And about the addr2line for this case, some help for dummies will be helpful.
>
> Leopold
>

Re: [Xenomai] RTnet fixes - testers needed

[Philippe Gerum]

Hi Andreas,

On 12/19/2017 11:17 AM, Andreas Glatz wrote:
>>
>> I have pulled wip/rtnet-fixes branch with the last commit of Philippe from Sun
>> Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type
>>
>> I have created the packages and new kernel with the same configuration that I had.
>>
>> I run my application, that it's a POSIX application Wrapped and I still have the
>> same error when I activate SMAP:
> 
> I see that the page fault occurs in rt_packet_ioctl()... by the looks
> of this bug it might be similar to the one I found in udp.c (see my
> post from Sunday)... basically the ioctl still tries to access user
> memory, which causes that stack trace. I'm currently a bit busy - I
> hope I can continue debugging this by the end of this week. 

I should be able to squeeze this debug task in the coming 48 hours, I
have your latest patched queued already. Let me know if you want to keep
on addressing this issue, otherwise I'll tackle this stuff.

Thanks,

-- 
Philippe.

Re: [Xenomai] RTnet fixes - testers needed

[Andreas Glatz]

>>>
>>> I have pulled wip/rtnet-fixes branch with the last commit of Philippe from Sun
>>> Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type
>>>
>>> I have created the packages and new kernel with the same configuration that I had.
>>>
>>> I run my application, that it's a POSIX application Wrapped and I still have the
>>> same error when I activate SMAP:
>>
>> I see that the page fault occurs in rt_packet_ioctl()... by the looks
>> of this bug it might be similar to the one I found in udp.c (see my
>> post from Sunday)... basically the ioctl still tries to access user
>> memory, which causes that stack trace. I'm currently a bit busy - I
>> hope I can continue debugging this by the end of this week.
>
> I should be able to squeeze this debug task in the coming 48 hours, I
> have your latest patched queued already. Let me know if you want to keep
> on addressing this issue, otherwise I'll tackle this stuff.
>

I think you'll be at it before me then :) I already made some more
progress in the UDP case. I can send you my latest patch tonight. I'm
also happy to keep testing + fixing when I find time for it! I can use
the RTnet UDP app from the company that I ported from kernel 3.0 to
4.9 to test the RTnet UDP stack.

Best,

A.

Re: [Xenomai] RTnet fixes - testers needed

[Philippe Gerum]

On 12/19/2017 11:46 AM, Andreas Glatz wrote:
>>>>
>>>> I have pulled wip/rtnet-fixes branch with the last commit of Philippe from Sun
>>>> Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type
>>>>
>>>> I have created the packages and new kernel with the same configuration that I had.
>>>>
>>>> I run my application, that it's a POSIX application Wrapped and I still have the
>>>> same error when I activate SMAP:
>>>
>>> I see that the page fault occurs in rt_packet_ioctl()... by the looks
>>> of this bug it might be similar to the one I found in udp.c (see my
>>> post from Sunday)... basically the ioctl still tries to access user
>>> memory, which causes that stack trace. I'm currently a bit busy - I
>>> hope I can continue debugging this by the end of this week.
>>
>> I should be able to squeeze this debug task in the coming 48 hours, I
>> have your latest patched queued already. Let me know if you want to keep
>> on addressing this issue, otherwise I'll tackle this stuff.
>>
> 
> I think you'll be at it before me then :)

Not that sure, I'm discovering the rtnet implementation as I go actually.

 I already made some more
> progress in the UDP case. I can send you my latest patch tonight. I'm
> also happy to keep testing + fixing when I find time for it! I can use
> the RTnet UDP app from the company that I ported from kernel 3.0 to
> 4.9 to test the RTnet UDP stack.
> 

Thanks, let's progress on this front in parallel then: I'll let you keep
on fighting with the UDP stuff, and I'll dive into the AF_PACKET stuff.

Thanks,

-- 
Philippe.

Re: [Xenomai] RTnet fixes - testers needed

[Leopold Palomo-Avellaneda]

On 19/12/17 11:17, Andreas Glatz wrote:
>>
>> I have pulled wip/rtnet-fixes branch with the last commit of Philippe from Sun
>> Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type
>>
>> I have created the packages and new kernel with the same configuration that I had.
>>
>> I run my application, that it's a POSIX application Wrapped and I still have the
>> same error when I activate SMAP:
> 
> I see that the page fault occurs in rt_packet_ioctl()... by the looks
> of this bug it might be similar to the one I found in udp.c (see my
> post from Sunday)... basically the ioctl still tries to access user
> memory, which causes that stack trace. I'm currently a bit busy - I
> hope I can continue debugging this by the end of this week. In the
> meantime could you recompile your kernel with debug info which should
> improve the kernel bug output?
> 

I have compiled the kernel with  CONFIG_DEBUG_KERNEL=Y. But, I have seen that
there's another option.

Which one could be the best for this case?

Leopold


-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [Xenomai] RTnet fixes - testers needed

[Andreas Glatz]

>>> I have pulled wip/rtnet-fixes branch with the last commit of Philippe from Sun
>>> Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type
>>>
>>> I have created the packages and new kernel with the same configuration that I had.
>>>
>>> I run my application, that it's a POSIX application Wrapped and I still have the
>>> same error when I activate SMAP:
>>
>> I see that the page fault occurs in rt_packet_ioctl()... by the looks
>> of this bug it might be similar to the one I found in udp.c (see my
>> post from Sunday)... basically the ioctl still tries to access user
>> memory, which causes that stack trace. I'm currently a bit busy - I
>> hope I can continue debugging this by the end of this week. In the
>> meantime could you recompile your kernel with debug info which should
>> improve the kernel bug output?
>>
>
> I have compiled the kernel with  CONFIG_DEBUG_KERNEL=Y. But, I have seen that
> there's another option.
>
> Which one could be the best for this case?
>

I think you want CONFIG_DEBUG_INFO, which depends on CONFIG_DEBUG_KERNEL=Y.

On ARM I also enabled CONFIG_DEBUG_INFO_DWARF4... but the help says
it's just for gdb + optimised code so I think you can leave it out.

Cheers,

A.

Re: [Xenomai] RTnet fixes - testers needed

[Philippe Gerum]

On 12/19/2017 11:17 AM, Andreas Glatz wrote:
>>
>> I have pulled wip/rtnet-fixes branch with the last commit of Philippe from Sun
>> Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type
>>
>> I have created the packages and new kernel with the same configuration that I had.
>>
>> I run my application, that it's a POSIX application Wrapped and I still have the
>> same error when I activate SMAP:
> 
> I see that the page fault occurs in rt_packet_ioctl()... by the looks
> of this bug it might be similar to the one I found in udp.c (see my

Confirmed, same pattern. The network address is wrongly accessed in
rt_packet_getsockname().

-- 
Philippe.

Re: [Xenomai] RTnet fixes - testers needed

[Philippe Gerum]

On 12/20/2017 11:17 AM, Philippe Gerum wrote:
> On 12/19/2017 11:17 AM, Andreas Glatz wrote:
>>>
>>> I have pulled wip/rtnet-fixes branch with the last commit of Philippe from Sun
>>> Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type
>>>
>>> I have created the packages and new kernel with the same configuration that I had.
>>>
>>> I run my application, that it's a POSIX application Wrapped and I still have the
>>> same error when I activate SMAP:
>>
>> I see that the page fault occurs in rt_packet_ioctl()... by the looks
>> of this bug it might be similar to the one I found in udp.c (see my
> 
> Confirmed, same pattern. The network address is wrongly accessed in
> rt_packet_getsockname().
> 

Likewise for the bind side.

-- 
Philippe.

Re: [Xenomai] RTnet fixes - testers needed

[Philippe Gerum]

On 12/20/2017 11:19 AM, Philippe Gerum wrote:
> On 12/20/2017 11:17 AM, Philippe Gerum wrote:
>> On 12/19/2017 11:17 AM, Andreas Glatz wrote:
>>>>
>>>> I have pulled wip/rtnet-fixes branch with the last commit of Philippe from Sun
>>>> Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type
>>>>
>>>> I have created the packages and new kernel with the same configuration that I had.
>>>>
>>>> I run my application, that it's a POSIX application Wrapped and I still have the
>>>> same error when I activate SMAP:
>>>
>>> I see that the page fault occurs in rt_packet_ioctl()... by the looks
>>> of this bug it might be similar to the one I found in udp.c (see my
>>
>> Confirmed, same pattern. The network address is wrongly accessed in
>> rt_packet_getsockname().
>>
> 
> Likewise for the bind side.
> 

That one should help fixing the the AF_PACKET layer:

http://git.xenomai.org/xenomai-3.git/commit/?h=wip/rtnet-fixes&id=3e388bcfde6c59bd9ec28bbcdb3757d32f19160b

-- 
Philippe.

Re: [Xenomai] RTnet fixes - testers needed

[Leopold Palomo-Avellaneda]

On 20/12/17 11:47, Philippe Gerum wrote:
> On 12/20/2017 11:19 AM, Philippe Gerum wrote:
>> On 12/20/2017 11:17 AM, Philippe Gerum wrote:
>>> On 12/19/2017 11:17 AM, Andreas Glatz wrote:
>>>>>
>>>>> I have pulled wip/rtnet-fixes branch with the last commit of Philippe from Sun
>>>>> Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type
>>>>>
>>>>> I have created the packages and new kernel with the same configuration that I had.
>>>>>
>>>>> I run my application, that it's a POSIX application Wrapped and I still have the
>>>>> same error when I activate SMAP:
>>>>
>>>> I see that the page fault occurs in rt_packet_ioctl()... by the looks
>>>> of this bug it might be similar to the one I found in udp.c (see my
>>>
>>> Confirmed, same pattern. The network address is wrongly accessed in
>>> rt_packet_getsockname().
>>>
>>
>> Likewise for the bind side.
>>
> 
> That one should help fixing the the AF_PACKET layer:
> 
> http://git.xenomai.org/xenomai-3.git/commit/?h=wip/rtnet-fixes&id=3e388bcfde6c59bd9ec28bbcdb3757d32f19160b
> 
Yes!!!!!

fixed. I can run my program and it doesn't crash. And SMAP is enabled!!!

Good job,

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?