1. 11 Jun, 2021 1 commit
    • Jan Kiszka's avatar
      rtdm/nrtsig: Move inband work description off the stack · 17fa132d
      Jan Kiszka authored
      
      
      Unlike the I-pipe, Dovetail does not copy the work descriptor but
      merely hands over the request to the common irq_work() mechanism. We
      must guarantee that such descriptor lives in a portion of memory which
      won't go stale until the handler has run, which by design can only
      happen once the calling out-of-band context unwinds.
      
      Therefore, we have to move the non-rt signal descriptors off the
      stack. When it comes to the basic non-RT signal, the rtdm_nrtsig_t
      descriptor itself is a proper place to host the inband work descriptor
      which carries out the work under the hood.
      
      When a task work needs to be scheduled, we enqueue it into global,
      lock-protected list, trigger a common lostage handler, and let that
      transfer the item to schedule_work.
      
      Based on original patch by Philippe Gerum, avoiding xnmalloc in RT code
      paths.
      
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      17fa132d
  2. 10 Jun, 2021 1 commit
  3. 09 Jun, 2021 2 commits
  4. 08 Jun, 2021 1 commit
  5. 04 Jun, 2021 31 commits
  6. 25 May, 2021 1 commit
    • Philippe Gerum's avatar
      cobalt/vfile: seq_file seek index must progress · 018003d3
      Philippe Gerum authored and Jan Kiszka's avatar Jan Kiszka committed
      
      
      The offset field we receive from the kernel in a vfile next() handler
      must progress in order for the loop to stop properly, independently
      from our own tracking of the end-of-list condition.
      
      Bug is reproducible by running two loops in parallel:
      
      - one continuously spawning an application which creates a few tenths
      of threads (10-20 would suffice) before exiting shortly after.
      
      - another one continuously reading from /proc/xenomai/sched/{threads,
        stat, acct}.
      
      At some point, the vfile handler should cause a kernel crash.
      
      Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      018003d3
  7. 20 May, 2021 3 commits