1. 08 Jan, 2021 7 commits
  2. 17 Dec, 2020 3 commits
    • Philippe Gerum's avatar
      cobalt/intr: pipeline: IRQ management code is pipeline-specific · 38baf072
      Philippe Gerum authored
      The way we request and manage interrupts depends on the underlying
      pipeline interface.
      
      As a matter of fact, Dovetail already deals with most of the logic
      implemented by the xnintr layer, such as edge/level shared IRQs, fully
      reusing the regular genirq interface for management. IRQ handlers with
      Dovetail have regular signatures as well.
      
      For the time being, let's move the entire xnintr layer to the I-pipe
      specific section created earlier. We should be able to design the
      abstract interface to IRQ management after this layer for the most
      part, which we would connect to Dovetail eventually.
      
      No functional change is introduced.
      Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      38baf072
    • Philippe Gerum's avatar
      cobalt/init: pipeline: abstract pipeline-specific inits · 6d2989b6
      Philippe Gerum authored
      This is the initial step to enabling Dovetail for the Cobalt core,
      which requires to introduce an abstraction layer between such core and
      the interrupt pipeline interface, either Dovetail or the legacy
      I-pipe.
      
      Eventually, the Cobalt implementation which has to interface to the
      underlying pipeline should branch off at the following points:
      
      - kernel/cobalt/{ipipe, dovetail}/arch, the arch-specific
        implementation which overwhelmingly depends on the pipeline flavour.
      
      - kernel/cobalt/{ipipe, dovetail}, the generic Cobalt code calling
        pipeline services.
      
      - kernel/cobalt/include/{ipipe, dovetail}, the client glue types and
        definitions pulled into some basic kernel types by the pipeline
        implementation (e.g. the thread_info extension structure).
      
      - include/cobalt/kernel/{ipipe, dovetail}, the generic Cobalt headers
        depending on services and definitions the pipeline provides for.
      
      We start the process by abstracting the machine-level init code which
      depends on the pipeline flavour.
      
      No functional change is introduced.
      Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      6d2989b6
    • Philippe Gerum's avatar
      cobalt/kernel: substitute ipipe_processor_id() with raw_smp_processor_id() · 18c7ed6a
      Philippe Gerum authored
      raw_smp_processor_id() has been callable from any pipeline domain for
      many moons now, there is no point in using the legacy
      ipipe_processor_id() call anymore.
      Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      18c7ed6a
  3. 16 Dec, 2020 3 commits
  4. 14 Dec, 2020 4 commits
  5. 11 Dec, 2020 7 commits
  6. 17 Nov, 2020 2 commits
  7. 12 Nov, 2020 1 commit
    • Florian Bezdeka's avatar
      lib/boilerplate/iniparser: Allow building with GCC 10.2 2020101 · 8acdbd71
      Florian Bezdeka authored
      Updating to upstream revision f858275f7f307eecba84c2f5429483f9f28007f8.
      Upstream repository is located at [1].
      
      The reason for updating was the following compiler error when trying
      to compile with GCC 10.2 10.2.1 20201016. As it turned out the problem
      was already addressed upstream:
      
      iniparser/iniparser.c: In function ‘iniparser_load’:
      iniparser/iniparser.c:616:13: error: ‘sprintf’ arguments 3, 4 may
      overlap destination object ‘buf’ [-Werror=restrict]
         616 |             sprintf(tmp, "%s:%s", section, key);
             |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      I reviewed especially the API changes. Most of them are cleanups only
      but two things should be pointed out:
      
        - The type of the size field of struct _dictionary_ changed from int
          to ssize_t. The only user of this struct is
          lib/analogy/calibration.c which uses this structure for internal
          things only. It is never exposed to any public API so updating is
          OK and fully backward compatible.
      
        - dictionary_new changed its signature
            from dictionary_new(int size)
            to   dictionary_new(size_t size).
          This function is not part of any public API. So updating does not
          break backward compatibility.
      
      [1] https://github.com/ndevilla/iniparserSigned-off-by: default avatarFlorian Bezdeka <florian.bezdeka@siemens.com>
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      8acdbd71
  8. 26 Oct, 2020 12 commits
  9. 13 Oct, 2020 1 commit
    • Philippe Gerum's avatar
      cobalt/kernel: vfile_snapshot: fix seq_file leakage on race detection · fa8ad1a1
      Philippe Gerum authored
      vfile_snapshot_open() may re-run the data collection loop in case we
      detected a race by checking the revision tag of the data
      set. Unfortunately, the seq_file is already open at this point,
      causing a leakage as seq_open() will be called again.
      
      The bug triggers after a while running the following commands
      concurrently:
      
      $ while : ; do cat /proc/xenomai/sched/stat > /dev/null; done &
      $ while : ; do switchtest -T 5; done
      
      As the private_data field of the backing file is not NULL once
      seq_open() has run, this bug triggers the following warning splat when
      calling it anew for the same file:
      
      [   32.660548] WARNING: CPU: 0 PID: 446 at fs/seq_file.c:55 seq_open.cold+0xc/0x1a
      [   32.670934] CPU: 0 PID: 446 Comm: cat Not tainted 4.19.89+ #16
      [   32.686078] I-pipe domain: Linux
      [   32.689312] RIP: 0010:seq_open.cold+0xc/0x1a
      [   32.693592] Code: 48 8b 74 24 08 e8 1e 5e f9 ff 48 8b 5d 18 48 8b 55 08 4c 01 f3 48 89 5d 18 e9 25 fe ff ff 48 c7 c7 00 99 2b 82 e8 32 71 de ff <0f> 0b e9 d3 db ff ff 90 90 90 90 90 90 90 41 57 41 56 41 55 41 54
      [   32.712354] RSP: 0018:ffff88815476f9b0 EFLAGS: 00010246
      [   32.717588] RAX: 0000000000000024 RBX: ffff888153ec7400 RCX: 0000000000000000
      [   32.724728] RDX: 1ffff1102b944a01 RSI: 0000000000000008 RDI: ffffed102a8edf2d
      [   32.731873] RBP: ffffffff828c5560 R08: 0000000000000024 R09: ffffffff815d0644
      [   32.739016] R10: ffffed102b946f1c R11: ffff88815ca378e7 R12: ffff888153ec74c8
      [   32.746156] R13: ffffffff828c75a0 R14: ffff8881544ebb80 R15: ffff888155a2d9c8
      [   32.753299] FS:  00007ff225dc3740(0000) GS:ffff88815ca00000(0000) knlGS:0000000000000000
      [   32.761395] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   32.767152] CR2: 00007ff225eb8120 CR3: 0000000153d8c000 CR4: 00000000003406f0
      [   32.774289] Call Trace:
      [   32.776746]  vfile_snapshot_open+0x2a8/0x560
      [   32.781022]  proc_reg_open+0x124/0x270
      [   32.784782]  ? proc_i_callback+0x20/0x20
      [   32.788713]  do_dentry_open+0x2ac/0x750
      [   32.792558]  ? proc_i_callback+0x20/0x20
      [   32.796492]  ? __x64_sys_fchmod+0x70/0x70
      [   32.800507]  ? inode_permission.part.0+0x4f/0x180
      [   32.805219]  ? security_inode_permission+0x13/0x60
      [   32.810015]  path_openat+0x456/0x1b80
      [   32.813681]  ? kmem_cache_alloc+0xd2/0x1c0
      [   32.817783]  ? getname_flags+0x35/0x240
      [   32.821624]  ? do_syscall_64+0x8a/0x240
      [   32.825466]  ? __rcu_read_unlock+0x66/0x80
      [   32.829572]  ? path_lookupat+0x430/0x430
      [   32.833497]  ? find_get_pages_range_tag+0x3a0/0x3a0
      [   32.838381]  ? finish_mkwrite_fault+0x1f0/0x1f0
      [   32.842916]  do_filp_open+0x103/0x210
      [   32.846586]  ? may_open_dev+0x50/0x50
      [   32.850253]  ? __fdget+0xe0/0xe0
      [   32.853491]  ? __virt_addr_valid+0xa6/0x100
      [   32.857677]  ? check_stack_object+0x1f/0x60
      [   32.861864]  ? __check_object_size+0x10c/0x1ce
      [   32.866316]  ? _raw_spin_unlock+0x9/0x30
      [   32.870245]  ? __alloc_fd+0x115/0x220
      [   32.873910]  do_sys_open+0x1c3/0x290
      [   32.877489]  ? __do_page_fault+0x494/0x7b0
      [   32.881588]  ? file_open_name+0x180/0x180
      [   32.885604]  do_syscall_64+0x8a/0x240
      [   32.889270]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fix this by deferring the call to seq_open() until after the data is
      fully collected without race, which prevents any seq_file leakage on
      race by design.
      Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      fa8ad1a1