All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Kiszka" <jan.kiszka@siemens.com>
To: cip-dev@lists.cip-project.org, Rainer Kloud <rainer.kloud@abwesend.de>
Subject: Re: [cip-dev] BUG: using smp_processor_id() in preemptible [00000000] code: TCPTSK/1809
Date: Thu, 10 Jun 2021 07:33:16 +0200	[thread overview]
Message-ID: <785d1d13-5d5b-fb7d-707d-52ccc04f2e28@siemens.com> (raw)
In-Reply-To: <trinity-b2d83de7-b7f2-4f74-802b-0b2c801ae463-1623061125004@3c-app-gmx-bap15>

[-- Attachment #1: Type: text/plain, Size: 2412 bytes --]

On 07.06.21 12:18, Rainer Kloud wrote:
> Hi,
>  
>>>> I notice you are using -rt kernel. Do you actually need realtime
>>>> features?
>>>
>>> Yes, I actually need the realtime feature. I have one task which
>>> needs to run periodically in realtime (triggered every 10ms by an
>>> external IRQ).
>>>
>>
>> Please don't forget to share your kernel config with us so that we can
>> make sure your use case is covered subsystem-wise in CIP. From Siemens
>> side, we still have room for improvements in this regard, even more on -rt.
>  
> Attached you can find my kernel config. 
>  

Would you propose it as patch to
https://gitlab.com/cip-project/cip-kernel/cip-kernel-config?

>>> Jun 1 09:11:46 sicam kernel: [46802.944299] [<c062f854>] (dump_stack) from [<c03a57ec>] (check_preemption_disabled+0x110/0x114)
>>> Jun 1 09:11:46 sicam kernel: [46802.944316] [<c03a57ec>] (check_preemption_disabled) from [<c014163c>] (migrate_enable+0x40/0x488)
>>> Jun 1 09:11:46 sicam kernel: [46802.944338] [<c014163c>] (migrate_enable) from [<c053ff0c>] (ip_finish_output2+0x21c/0x460)
>>
>> Migration should be on across migration-disabled sections, that's their
>> whole purpose. But maybe the check that preemption needs to be off when
>> using smp_processor_id needs relaxing to at least migration must be off.
> 
> Sorry, but I can not follow your words. What do you mean with 'needs relaxing to
> at least migration must be off'?
> 

Strike it, that case is too generic to be a reason for something that
long in the field by now.

From looking at the code of migrate_enable(), I suspect that we cause
the call to smp_processor_id() via "struct rq *rq = this_rq();". That
comes fairly at the beginning of migrated_enable(), which matches the
small offset in your backtrace (you can confirm that better). That would
complain about "preemptible code" if the caller does not have preemption
or at least migration off. So my suspect would be a
migration_disable/enable imbalance in the code path you triggered,
likely somewhere in the TCP code.

Did you already try more recent RT kernels, both in the 4.19 series as
well as maybe 5.10 or even latest -rt? Possibly, this issue has been
fixed by now. If you can even reproduce with latest -rt, the issue is
better reported to linux-rt-users.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

[-- Attachment #2: Type: text/plain, Size: 428 bytes --]


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#6500): https://lists.cip-project.org/g/cip-dev/message/6500
Mute This Topic: https://lists.cip-project.org/mt/83330337/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/4520388/727948398/xyzzy [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-


  reply	other threads:[~2021-06-10  5:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-05 13:50 [cip-dev] BUG: using smp_processor_id() in preemptible [00000000] code: TCPTSK/1809 Rainer Kloud
2021-06-06 19:14 ` Pavel Machek
2021-06-07  4:31   ` rainer.kloud
2021-06-07  5:23   ` Rainer Kloud
2021-06-07  8:25     ` Jan Kiszka
2021-06-07 10:18       ` Rainer Kloud
2021-06-10  5:33         ` Jan Kiszka [this message]
2021-06-11 22:34     ` Pavel Machek
2021-06-15  4:56       ` Rainer Kloud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=785d1d13-5d5b-fb7d-707d-52ccc04f2e28@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=cip-dev@lists.cip-project.org \
    --cc=rainer.kloud@abwesend.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.