Fatal exceptions on context-switching for more than two isolated threads

Hello, When I isolate more than two threads in RTEMS (the implementation can be found here ), I get fatal exceptions while context-switching. On stepping into the code, the problem seems to be with the _User_extensions_T

[PATCH v4] Test for clock_nanosleep() with CLOCK_MONOTONIC option

From: Utkarsh Closes #3890 Signed-off-by: Utkarsh Rai --- spec/build/testsuites/psxtests/grp.yml| 2 + .../psxtests/psxclocknanosleep01.yml | 20 +++ .../psxtests/psxclocknanosleep01/init.c | 94 ++ .../psxclocknanosleep01.doc | 13

Re: Fatal exceptions on context-switching for more than two isolated threads

On Mon, Sep 21, 2020 at 10:29 PM Gedare Bloom wrote: > On Sat, Sep 19, 2020 at 5:41 AM Utkarsh Rai > wrote: > > > > Hello, > > When I isolate more than two threads in RTEMS (the implementation can be > found here), I get fatal exceptions while context-switching. On st

Re: [PATCH v4] Test for clock_nanosleep() with CLOCK_MONOTONIC option

Hello, Can someone please review this. I would like to work on the suggested changes over the weekend. On Mon, Sep 21, 2020 at 8:45 PM Utkarsh Rai wrote: > From: Utkarsh > > Closes #3890 > > Signed-off-by: Utkarsh Rai > --- > spec/build/testsuites/psxtests

Re: [PATCH v4] Test for clock_nanosleep() with CLOCK_MONOTONIC option

what I have implemented. I will change this. > > > On Mon, Sep 21, 2020 at 9:15 AM Utkarsh Rai > wrote: > > > > From: Utkarsh > Please use full (legal) name for commit metadata > > > > > Closes #3890 > > > > Signed-off-by: Utkarsh Rai > &

Error while using the trace linker

Hello, I am following the tracing example as mentioned in the docs for sparc/erc32 BSP. When I run the "rtems-tld" command, I get the following error - "error: /home/utkarsh/sandbox/bsps/sparc: Invalid RTEMS path" My directory st

[PATCH v4 0/1] Test for clock_nanosleep() with CLOCK_MONOTONIC option

(yielding and blocking). Utkarsh Rai (1): Test for clock_nanosleep() with CLOCK_MONOTONIC option .../psxtests/psxclocknanosleep01.yml | 19 +++ spec/build/testsuites/psxtmtests/grp.yml | 4 + .../psxtmtests/psxtmclocknanosleep04.yml | 19 +++ .../psxtmtests

[PATCH v4 1/1] Test for clock_nanosleep() with CLOCK_MONOTONIC option

-SA-4.0 OR BSD-2-Clause +build-type: test-program +cflags: [] +copyrights: +- Copyright (C) 2020 Utkarsh Rai(utkarsh.ra...@gmail.com) +cppflags: [] +cxxflags: [] +enabled-by: true +features: c cprogram +includes: [] +ldflags: [] +links: [] +source: +- testsuites/psxtests/psxclocknanosleep01/init.c

Re: Fatal exceptions on context-switching for more than two isolated threads

been set to NO-ACCESS during the context switch. Is there any work-around to this? On Tue, Sep 22, 2020 at 8:28 PM Utkarsh Rai wrote: > > > > On Mon, Sep 21, 2020 at 10:29 PM Gedare Bloom wrote: > >> On Sat, Sep 19, 2020 at 5:41 AM Utkarsh Rai >> wrote: >>

Re: Fatal exceptions on context-switching for more than two isolated threads

On Thu, Oct 22, 2020 at 11:23 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 22/10/2020 02:40, Utkarsh Rai wrote: > > > Hello, this thread has gone a bit cold over the last few weeks, due to > > my engagement in the university tests. I have provid

Re: Fatal exceptions on context-switching for more than two isolated threads

On Fri, Oct 23, 2020 at 9:57 PM Gedare Bloom wrote: > On Fri, Oct 23, 2020 at 9:37 AM Utkarsh Rai > wrote: > > > > > > > > On Thu, Oct 22, 2020 at 11:23 PM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> > >> On 22/

Re: [PATCH v4 0/1] Test for clock_nanosleep() with CLOCK_MONOTONIC option

Ping. On Wed, Oct 21, 2020 at 8:58 AM Utkarsh Rai wrote: > This patch has the tests for clock_nanosleep with the CLOCK_MONOTONIC > option. > The psxtests/psxclocknanosleep01/.. tests for valid timeout values as well > as > for the effect on timeout delay when REALTIME clock

Re: Fatal exceptions on context-switching for more than two isolated threads

On Fri, Oct 23, 2020 at 10:28 PM Utkarsh Rai wrote: > > > On Fri, Oct 23, 2020 at 9:57 PM Gedare Bloom wrote: > >> On Fri, Oct 23, 2020 at 9:37 AM Utkarsh Rai >> wrote: >> > >> > >> > >> > On Thu, Oct 22, 2020 at 11:23 PM Se

Re: [PATCH v4 0/1] Test for clock_nanosleep() with CLOCK_MONOTONIC option

On Thu, Nov 5, 2020 at 12:13 AM Gedare Bloom wrote: > i need to find time to look at this, and try it out. > > Does this compile? e.g., I don't see a definition of OPERATION_COUNT > Yes, the OPERATION_COUNT is defined in "timesys.h". > > On Wed, Oct 28, 202

Re: Fatal exceptions on context-switching for more than two isolated threads

On Thu, Nov 5, 2020 at 11:45 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 04/11/2020 19:38, Gedare Bloom wrote: > > >> Based on the above suggestions I tried to move the > User_extensions_Iterator storage to the TCB by adding a new field to the > structure, but that did n

Re: Fatal exceptions on context-switching for more than two isolated threads

On Thu, Nov 19, 2020 at 11:39 PM Gedare Bloom wrote: > Hi Utkarsh, > > On Thu, Nov 19, 2020 at 4:59 AM Sebastian Huber > wrote: > > > > On 19/11/2020 11:47, Utkarsh Rai wrote: > > > > > There are a couple of other areas in RTEMS in which the stack of

Re: [PATCH v4 0/1] Test for clock_nanosleep() with CLOCK_MONOTONIC option

Hello, Is there any update on this patch? On Wed, Oct 28, 2020 at 7:04 PM Utkarsh Rai wrote: > Ping. > > On Wed, Oct 21, 2020 at 8:58 AM Utkarsh Rai > wrote: > >> This patch has the tests for clock_nanosleep with the CLOCK_MONOTONIC >> option. >> The psxtests

Report on failing tests with thread stack protection and their resolution.

Hello, As discussed in this thread, I have compiled a list of the tests that deal with inter stack communication and fail with the thread stack protection option. Most of these tests pass when, as Sebastian suggested and had provid

Re: Report on failing tests with thread stack protection and their resolution.

On Thu, Dec 3, 2020 at 10:22 PM Gedare Bloom wrote: > > > On Wed, Dec 2, 2020 at 5:53 PM Utkarsh Rai > wrote: > >> Hello, >> As discussed in this >> <https://lists.rtems.org/pipermail/devel/2020-November/063341.html> thread, >> I have compiled a

Re: Report on failing tests with thread stack protection and their resolution.

On Thu, Dec 17, 2020 at 8:23 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello, > > On 03/12/2020 01:53, Utkarsh Rai wrote: > > +rtems_status_code _Memory_protection_Disable( void ) > > +{ > > + uint32_t access_flags; > >

Re: Report on failing tests with thread stack protection and their resolution.

On Mon, Dec 7, 2020 at 8:00 AM Utkarsh Rai wrote: > > > On Thu, Dec 3, 2020 at 10:22 PM Gedare Bloom wrote: > >> >> >> On Wed, Dec 2, 2020 at 5:53 PM Utkarsh Rai >> wrote: >> >>> Hello, >>> As discussed in this >>> <h

Re: Report on failing tests with thread stack protection and their resolution.

On Sat, Jan 23, 2021 at 9:29 PM Joel Sherrill wrote: > > > On Sat, Jan 23, 2021, 12:28 AM Utkarsh Rai > wrote: > >> >> >> On Mon, Dec 7, 2020 at 8:00 AM Utkarsh Rai >> wrote: >> >>> >>> >>> On Thu, Dec 3, 2020 at 10:22 P

Re: Report on failing tests with thread stack protection and their resolution.

On Tue, Jan 26, 2021 at 9:33 PM Gedare Bloom wrote: > > > On Tue, Jan 26, 2021 at 8:24 AM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> On 23/01/2021 07:27, Utkarsh Rai wrote: >> >> > The issue that remains is of User extensi

Re: Memory Protection related project for GSOC

On Sun, Feb 21, 2021 at 12:00 AM Gedare Bloom wrote: > Hi Sanskar, > > We had a student (Utkarsh) work on this project last year. I have CC'd > him here, and he may be able to suggest some ideas/updates. > > On Sat, Feb 20, 2021 at 7:17 AM Sanskar Khandelwal > wrote: > > > > Hello, > Hello Sans

Re: GSoC project: Memory protection (Ticket no: 2904)

On Mon, Mar 22, 2021 at 9:54 PM Gedare Bloom wrote: > Hi Rajiv, > > On Sat, Mar 20, 2021 at 12:40 AM Rajiv Vaidyanathan > wrote: > > > > Hello RTEMS community, > Hello Rajiv, > > > > I am interested in the ticket: Memory protection. I saw that this topic > has been pursued a few times in GSoC

Re: GSoC project: Memory protection (Ticket no: 2904)

elated to user extension iterators and then making it compatible with existing testsuites should be a long enough task. You can also take up the task of thread stack sharing if this is resolved early. > Thanks and regards, > Rajiv > > On Tue, 23 Mar 2021 at 16:15, Utkarsh Rai wrote: >

Re: GSoC Project - Beagle BSP Projects

On Tue, Mar 23, 2021 at 9:36 PM Nils Hölscher wrote: > Hi, > > Regarding the PRU. > I was able to load code to the PRU. > However I wasn't able to map IRQ interrupts to the PRU, thus unable to > communicate with it in a meaningful way > Just a small addition, AFAIK the issue with this was the f

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

On Wed, Apr 15, 2020 at 10:26 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Utkarsh Rai, > > do we really need a new test program for this test case? I would prefer > add it to an existing test program or add a generic POSIX test program > using the

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

On Wed, Apr 15, 2020 at 5:35 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 15/04/2020 14:02, Utkarsh Rai wrote: > > > + status = clock_gettime( CLOCK_MONOTONIC, &end_time ); >> > + rtems_test_assert( status == 0 ); >> > + >

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

:29, Utkarsh Rai wrote: > > On Wed, Apr 15, 2020 at 5:35 PM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> On 15/04/2020 14:02, Utkarsh Rai wrote: >> >> > + status = clock_gettime( CLOCK_MONOTONIC, &end_time ); >>> > + r

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

Yes sir. On Wed 15 Apr, 2020, 7:21 PM Sebastian Huber, < sebastian.hu...@embedded-brains.de> wrote: > On 15/04/2020 15:00, Utkarsh Rai wrote: > > > Okay, so from what I could gather the time between the two gettime > > calls can exceed 1 sec if it is preempted by anothe

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

gt; and you delay for 1 ns? > > On Wed, Apr 15, 2020 at 8:00 AM Sebastian Huber > wrote: > > > > On 15/04/2020 15:55, Utkarsh Rai wrote: > > > > Yes sir. > > > > Ok, good, then you should do this. Maybe someone else solved this > problem already.

fdt_rw.c: Unchecked return value (CID #1047324) (#3947)

As is suggested in the ticket I checked for return value checking in the upstream and it is not present. Should I send a patch that checks for the error value (FDT_END)? ___ devel mailing list devel@rtems.org http://l

[PATCH] Test for clock_nanosleep() with CLOCK_MONOTONIC option.

b/testsuites/psxtests/psxclocknanosleep/init.c @@ -0,0 +1,182 @@ +/* + * Copyright (c) 2020 Utkarsh Rai. + * + * The license and distribution terms for this file may be + * found in the file LICENSE in this distribution or at + * http://www.rtems.org/license/LICENSE. + */ + +#ifdef HAVE_CONFIG

[PATCH v2] Test for clock_nanosleep() with CLOCK_MONOTONIC option.

x 00..c1f10b9eb9 --- /dev/null +++ b/testsuites/psxtests/psxclocknanosleep01/init.c @@ -0,0 +1,155 @@ +/* + * Copyright (c) 2020 Utkarsh Rai. + * + * The license and distribution terms for this file may be + * found in the file LICENSE in this distribution or at + * http://www.rtems.org/lic

Test for clock_nanosleep

I have written the following patch based on the new test framework. Although the test runs successfully, I am not sure I have utilized the RTEMS_LINKER_ROSET/ ROSET_DECLARE properly to link test objects. ___ devel mailing list devel@rtems.org http://lists

[PATCH v3] Test for clock_nanosleep() with CLOCK_MONOTONIC option

- /dev/null +++ b/testsuites/psxtests/psxclocknanosleep01/init.c @@ -0,0 +1,102 @@ +/* SPDX-License-Identifier: BSD-2-Clause + * + * Copyright (C) 2020 Utkarsh Rai + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the fol

Memory Protection project interface details (GSoC 2020)

executing thread. Since context-switch is low-level architecture-specific, this also has to be provided with more support. Kindly provide your feedback if I have missed something or I have a wrong idea about it. Regards, Utkarsh Rai. ___ devel mailing list devel

Re: Memory Protection project interface details (GSoC 2020)

bugging on QEMU with GDB is way > > easier, and you can consider either qemu-xilinx-zynq-a9 or rpi2 BSPs. > > Later, you can move your code to BBB if you want, since both are based > > on ARMv7. > +1 > > Past work has also used psim successfully I thought? Or am I

Re: Memory Protection project interface details (GSoC 2020)

ully I thought? Or am I mistaken >> there. >> > >> Before my 2012 project (and part of it, yes), we used psim. The use of >> software TLBs wasn't very ideal/easy though, so we moved to ARM in >> 2013. The development/testing was mainly on a RPi board. I don&#

Help on how to configure for user-defined memory protection support (GSoC 2020)

Hello, My GSoC project, providing thread stack protection support, has to be a user-configurable feature. My question is, what would be the best way to implement this, my idea was to model it based on the existing system configuration

Re: Memory Protection project interface details (GSoC 2020)

On Wed, May 13, 2020 at 8:11 PM Gedare Bloom wrote: > On Wed, May 13, 2020 at 6:12 AM Utkarsh Rai > wrote: > > > > > > > > On Wed, May 13, 2020 at 3:56 AM Joel Sherrill wrote: > >> > >> I hate to top post but I'm not sure where to insert

Re: Memory Protection project interface details (GSoC 2020)

On Wed, May 13, 2020 at 10:27 PM Joel Sherrill wrote: > > > On Wed, May 13, 2020 at 9:41 AM Gedare Bloom wrote: > >> On Wed, May 13, 2020 at 6:12 AM Utkarsh Rai >> wrote: >> > >> > >> > >> > On Wed, May 13, 2020 at 3:56 AM Joel Sher

Re: Help on how to configure for user-defined memory protection support (GSoC 2020)

On Thu, May 14, 2020 at 10:23 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Utkarsh Rai, > > On 13/05/2020 14:30, Utkarsh Rai wrote: > > Hello, > > My GSoC project, providing thread stack protection support, has to be > > a user-configu

Re: Help on how to configure for user-defined memory protection support (GSoC 2020)

that you use plain text when inlining a reply, or at least that you >> broke the reply format. >> >> Gedare >> >> On Fri, May 15, 2020, 6:04 PM Utkarsh Rai >> wrote: >> >>> >>> >>> On Thu, May 14, 2020 at 10:23 AM Sebastian Hube

Re: Help on how to configure for user-defined memory protection support (GSoC 2020)

On Mon, May 18, 2020 at 8:38 PM Gedare Bloom wrote: > On Mon, May 18, 2020 at 4:31 AM Utkarsh Rai > wrote: > > > > > > > > > > On Sat, May 16, 2020 at 9:16 PM Joel Sherrill wrote: > >> > >> > >> > >> On Sat, May 16, 2020 a

Re: Help on how to configure for user-defined memory protection support (GSoC 2020)

On Wed, May 20, 2020 at 7:40 AM Hesham Almatary wrote: > On Tue, 19 May 2020 at 14:00, Utkarsh Rai wrote: > > > > > > > > On Mon, May 18, 2020 at 8:38 PM Gedare Bloom wrote: > >> > >> On Mon, May 18, 2020 at 4:31 AM Utkarsh Rai > wrote: > &g

Re: Help on how to configure for user-defined memory protection support (GSoC 2020)

ad here is the flushing of the protected region > (that might be a shared protected stack for example). Only that > region's TLB entry will differ between tasks on context switches, and > if ASID is used, the hardware will make sure it gets the correct entry > (by doing a HW page-table

Re: Help on how to configure for user-defined memory protection support (GSoC 2020)

On Fri, May 22, 2020, at 10:59 AM Gedare Bloom wrote: > > This means that our low-level design for providing thread stack > protection may look something like this:- > > > > 1. For MPU based processors, the number of protected stacks will depend > on the number of protection domains i.e. for MPU

Re: Help on how to configure for user-defined memory protection support (GSoC 2020)

On Mon, May 25, 2020 at 9:32 PM Gedare Bloom wrote: > On Mon, May 25, 2020 at 5:39 AM Utkarsh Rai > wrote: > > > > > > On Fri, May 22, 2020, at 10:59 AM Gedare Bloom wrote: > >> > >> > This means that our low-level design for providing thread st

Re: Help on how to configure for user-defined memory protection support (GSoC 2020)

On Wed, May 27, 2020 at 8:29 PM Gedare Bloom wrote: > On Tue, May 26, 2020 at 6:12 PM Utkarsh Rai > wrote: > > > > > > > > On Mon, May 25, 2020 at 9:32 PM Gedare Bloom wrote: > >> > >> On Mon, May 25, 2020 at 5:39 AM Utkarsh Rai > wrote: >

Error in building application with rpi BSP with waf build system

gure command. Is there a typo in my configure command or the waf build does not support raspberrypi BSP? Kindly point out my error. Regards, Utkarsh Rai. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: Error in building application with rpi BSP with waf build system

On Mon, Jun 1, 2020 at 9:32 AM Utkarsh Rai wrote: > Hello, > > I was unable to build a sample app for raspberrypi, I followed the docs > <https://docs.rtems.org/branches/master/user/start/app.html> and was able > to build the app for Xilinx-qemu and beagleboard. > > Th

Setting up the TTBR0 and TTBR1 register for thread stack protection in ARMv7-A MMU

Hello, Section B3.3.3 of the ARMv7-A Reference manual says that we can have TTBR0 and 1 split up the address space into two parts, where each register has the address of the translation table base of the divid

Re: Setting up the TTBR0 and TTBR1 register for thread stack protection in ARMv7-A MMU

ables for more > fine-grained page sizes. No this will not be an issue, we can set the bits[1:0] of the table-entry to account for the levels of page tables. I was thinking about ways to simplify the implementation of stack allocation, but doing this is definitely not feasible. > O

Help in figuring out score objects in RTEMS and ticket #3131

Hello, For my GSoC project, user-configurable thread stack protection, I need to track, allocate, and manipulate attributes of shared as well as protected stacks. Dr.Gedare suggested that tracking them with score objects would be a good idea. He also indicated a good place to start and understand s

Re: Help in figuring out score objects in RTEMS and ticket #3131

e have to define the mmap_h in the IMFS file system layer(as I could not find an implementation for this handler) and then register it in the file_handlers table and then use this in mmap? Or do we already have a generic mmap_h implementation that I can use? On Thu, Jun 11, 2020 at 6:04 AM Utkarsh R

Re: Help in figuring out score objects in RTEMS and ticket #3131

On Mon, Jun 15, 2020 at 6:46 PM Joel Sherrill wrote: > > > On Wed, Jun 10, 2020 at 7:34 PM Utkarsh Rai > wrote: > >> Hello, >> For my GSoC project, user-configurable thread stack protection, I need to >> track, allocate, and manipulate attributes of shar

Context switching for protected stacks

Hello, For my GSoC project, I need to set/unset the memory attributes of the thread stacks on each context switch. Right now I am making changes to the CPU-specific context switch assembly code. The arm/../cpu.h file has the Context_Control structure, which is used to store the relevant registers a

Re: Context switching for protected stacks

On Thu, Jun 18, 2020 at 6:34 PM Gedare Bloom wrote: > On Wed, Jun 17, 2020 at 11:17 PM Utkarsh Rai > wrote: > > > > Hello, > > For my GSoC project, I need to set/unset the memory attributes of the > thread stacks on each context switch. > > Right now I am m

Re: Context switching for protected stacks

On Fri, Jun 19, 2020 at 3:04 AM Gedare Bloom wrote: > On Thu, Jun 18, 2020 at 8:03 AM Utkarsh Rai > wrote: > > > > > > > > On Thu, Jun 18, 2020 at 6:34 PM Gedare Bloom wrote: > >> > >> On Wed, Jun 17, 2020 at 11:17 PM Utkarsh Rai > wrote:

Offset locations of registers in ARM context-switch code

Hello, The 'Context_Control' structure in score/.../arm/cpu.h has registers and attributes that need to be saved during context-switching. Some of these registers/attributes are conditionally compiled depending upon the mode in which the processor is running. The registers are saved by 'ldr' instru

Verfication of context-switching mechanism for protected stacks

The following patch provides a context-switching mechanism for protected stacks. This is not a mergeable patch. I want to have feedback on the mechanism. > I have added 'stack_attribute' to the 'Context_Control' structure. > On a call to 'Context_Initialize()'. the 'stack_attribute' field is initia

Re: [PATCH] Assembly suppport for context switch and bug fixes

rates your > idea for review. Should I squash all of my commits and send it as a single patch (along with the changes suggested in this one) or break it into multiple patches? > More below: > > On Mon, Jun 29, 2020 at 8:48 AM utkarsh.ra...@gmail.com > wrote: > > > > F

Re: Applying an operation to a set of threads in RTEMS

On Fri, Jul 3, 2020 at 1:32 AM Peter Dufault wrote: > I finally have gotten to reviewing Utkarsh's work in GSOC. One item that > I don't like is that there is a linked list management of the threads that > have access to the stack. > I think this access is similar to the file descriptors that ar

Re: Applying an operation to a set of threads in RTEMS

> > > > My thought is that it matches what is needed and is expected to be > optimized. > > > >> On Jul 3, 2020, at 24:37 , Utkarsh Rai wrote: > >> > >> > >> > >> On Fri, Jul 3, 2020 at 1:32 AM Peter Dufault wrote: > >> I f

Converting stack address to shared-memory object name

Hello, For my GSoC project, I have to provide high-level APIs for sharing isolated stacks. The POSIX compliant high-level way of sharing stacks can be to create a shared memory object of the stack to be shared through shm_open and then mmap that to the address space of the current stack. My doubt i

Re: Converting stack address to shared-memory object name

On Wed, Jul 8, 2020 at 6:56 PM Gedare Bloom wrote: > On Wed, Jul 8, 2020 at 6:53 AM Sebastian Huber > wrote: > > > > On 08/07/2020 14:43, Utkarsh Rai wrote: > > > > > Hello, > > > For my GSoC project, I have to provide high-level APIs for sharing > &

Re: Converting stack address to shared-memory object name

On Thu, Jul 9, 2020 at 8:57 PM Gedare Bloom wrote: > On Thu, Jul 9, 2020 at 9:24 AM Gedare Bloom wrote: > > > > On Wed, Jul 8, 2020 at 10:08 PM Utkarsh Rai > wrote: > > > > > > > > > > > > > > > On Wed, Jul 8, 2020 at 6:56 PM Ge

[PATCH] Strict thread-stack isolation

- This is the complete set of changes for strict isolation of thread stacks. - There needs to be a confiuration operation,(#if defined(USE_THREAD_STACK_PROTECTION) for simple configuration can be used) - The stack attributes are allocated through malloc, this needs to be done through score unlimi

Re: [PATCH] Strict thread-stack isolation

the code format? Have you looked at > > https://docs.rtems.org/branches/master/eng/coding.html > > ? > Yes, sorry, I realize I need to do a better job with the coding standard and maintaining namespace consistency. I will rectify this. > On 13/07/2020 18:33, Utkarsh Rai wrote: &g

Re: [PATCH] Strict thread-stack isolation

On Tue, Jul 14, 2020 at 7:36 PM Gedare Bloom wrote: > I won't comment on the namespace and coding conventions, other than to > say you should focus on doing them correctly as you code, rather than > going back and fixing them later. More below. > > On Mon, Jul 13, 2020 at

[PATCH v2] Strict thread-stack isolation

c680 --- /dev/null +++ b/cpukit/include/rtems/score/memorymanagement.h @@ -0,0 +1,89 @@ +/* SPDX-License-Identifier: BSD-2-Clause */ + +/** + * @file + * + * @ingroup RTEMSScoreMemorymanagement + * + * @brief This file provodes APIs for high-level memory management + * + */ + +/* + * Copyright (C)

Re: [PATCH v2] Strict thread-stack isolation

Kindly ignore this patch. It breaks the build. On Thu, Jul 16, 2020 at 4:54 PM Utkarsh Rai wrote: > - This is the complete set of changes for strict isolation of thread > stacks. > - There needs to be a confiuration operation,(#if > defined(USE_THREAD_STACK_PROTECTION) for simple c

[PATCH v2] Thread-stack isolation

The following is the rectified patch and does not break the build. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] Strict thread-stack isolation

c680 --- /dev/null +++ b/cpukit/include/rtems/score/memorymanagement.h @@ -0,0 +1,89 @@ +/* SPDX-License-Identifier: BSD-2-Clause */ + +/** + * @file + * + * @ingroup RTEMSScoreMemorymanagement + * + * @brief This file provodes APIs for high-level memory management + * + */ + +/* + * Copyright (C)

Re: [PATCH v2] Strict thread-stack isolation

On Fri, Jul 17, 2020 at 11:08 AM Gedare Bloom wrote: > Is this code working? how do you test it? > > There are several points buried below that you might need to bring out > to separate threads for discussion, while you work on the code. > > On Thu, Jul 16, 2020 at 5:34 AM Ut

GSoC: Disabling interrupts while modifying translation table entries for armv7-A MMU.

Hello, The translation table setting code has _ARM_Data_synchronization_barrier() before and after invalidating the instruction and data TLB entry, this ensures synchronization of instructions for the TLB invalidation in case of multiple cores. My question is, do we have to explicitly disable inter

GSoC: Correct placement and naming of memory protection APIs

Hello, In RTEMS each set of BSP has its own MMU implementation, for utilizing this for high-level operations such as thread-stack protection we need a common interface that is implemented for each BSP but is available for high-level operations ( Something along the lines of the cache manager ), my

Re: GSoC: Correct placement and naming of memory protection APIs

cing this in the score? (If you look into my commit history, I have fiddled with the placement quite a bit without any resolution). > > > On Fri, 17 Jul 2020 at 21:33, Utkarsh Rai wrote: > > > > Hello, > > In RTEMS each set of BSP has its own MMU implementation, for uti

Fatal exception while changing the memory entries in ARMv7 MMU

Hello, While changing the memory entries for a section in the ARMv7 MMU using 'arm_cp15_set_translation_table_entries()' I get fatal exception error. On stepping through the debugger, the exception occurs when invalidating the data TLB entries, using 'arm_cp15_tlb_data_invalidate_entry()'. You can

Re: Fatal exception while changing the memory entries in ARMv7 MMU

> On Sat, Jul 25, 2020 at 9:44 AM Utkarsh Rai > wrote: > > > > Hello, > > While changing the memory entries for a section in the ARMv7 MMU using > 'arm_cp15_set_translation_table_entries()' I get fatal exception error. On > stepping through the debugger, the

Segmentation fault whie setting up translation table for small pages in ARMv7 MMU

Hello, I was facing issues while changing the memory entries for a section. The thread can be viewed here . The error is most probably due to the fact that while I change the memory entry of my desired region it ends up changing the mem

Re: Segmentation fault whie setting up translation table for small pages in ARMv7 MMU

On Sun, Jul 26, 2020 at 9:12 PM Hesham Almatary < hesham.almat...@cl.cam.ac.uk> wrote: > > > On Sun, Jul 26, 2020 at 2:04 PM Utkarsh Rai > wrote: > >> Hello, >> I was facing issues while changing the memory entries for a section. The >> thread can be

Translation table for small pages in ARMv7 MMU conflicting with other data regions

The translation table for ARMv7 MMU starts at 0x10 and extends up to 0x104000 for section-based pages. Although for small pages it extends up to 0x504000 this possibly conflicts with other data regions and setting up of translation table for smaller pages fails. I realize that various data regi

Re: Translation table for small pages in ARMv7 MMU conflicting with other data regions

Thanks, I'll check it out. On Wed, Jul 29, 2020 at 9:36 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 29/07/2020 18:02, Utkarsh Rai wrote: > > > The translation table for ARMv7 MMU starts at 0x10 and extends up > > to 0x104000 for sect

[PATCH] Strict thread-stack isolation and thread-stack sharing.

ryprotection.h @@ -0,0 +1,82 @@ +/* SPDX-License-Identifier: BSD-2-Clause */ + +/** + * @file + * + * @ingroup RTEMSScoreMemoryprotection + * + * @brief This file provodes APIs for high-level memory protection + * + */ + +/* + * Copyright (C) 2020 Utkarsh Rai + * + * Redistribution and use in sour

Design issues with thread-stack isolation/sharing.

This thread is an attempt to consolidate and resolve all the issues that have been raised related to my patches- 1. https://lists.rtems.org/pipermail/devel/2020-July/060675.html and 2. https://lists.rtems.org/pipermail/devel/2020-July/061056.html. I intend to first resolve all the issues through th

Re: Design issues with thread-stack isolation/sharing.

On Sat, Aug 1, 2020 at 10:51 PM Gedare Bloom wrote: > On Sat, Aug 1, 2020 at 10:38 AM Utkarsh Rai > wrote: > > > > This thread is an attempt to consolidate and resolve all the issues that > have been raised related to my patches- 1. > https://lists.rtems.org/pipermai

Error while building realview_pbx_a9 BSP with the new build system

Hello, I have been trying out the new build system. Unfortunately, while building for the realview_pbx_a9 BSP I get the following error on ' ./waf install ' - " Waf: Entering directory `/home/utkarsh/new_build/rtems/build' Waf: Leaving directory `/home/utkarsh/new_build/rtems/build' 'install' fin

Re: Error while building realview_pbx_a9 BSP with the new build system

mkdir self.parent.mkdir() File "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Node.py", line 188, in mkdir raise Errors.WafError('Could not create the directory %r'%self) WafError: Could not create the directory /opt/rtems On Mon, Aug 3, 2020 at 9:42 PM Se

Re: Design issues with thread-stack isolation/sharing.

On Mon, Aug 3, 2020 at 9:35 PM Gedare Bloom wrote: > On Sun, Aug 2, 2020 at 5:46 AM Utkarsh Rai > wrote: > > > > > > > > On Sat, Aug 1, 2020 at 10:51 PM Gedare Bloom wrote: > >> > >> On Sat, Aug 1, 2020 at 10:38 AM Utkarsh Rai > wrote: >

Re: Error while building realview_pbx_a9 BSP with the new build system

On Mon, Aug 3, 2020 at 9:56 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 03/08/2020 18:17, Utkarsh Rai wrote: > > > When I use the above branch I get the following error on './waf > > install ' - > > > > Build failed >

Re: Error while building realview_pbx_a9 BSP with the new build system

n Mon, Aug 3, 2020 at 10:47 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 03/08/2020 18:32, Gedare Bloom wrote: > > > On Mon, Aug 3, 2020 at 10:27 AM Sebastian Huber > > wrote: > >> On 03/08/2020 18:25, Gedare Bloom wrote: > >> &g

Configuration option for thread-stack protection.

Hello, The thread-stack protection needs to be configured by the user. Two of the options that need configuring during build time are - > Enabling thread stack protection ( THREAD_STACK_PROTECTION )- This is a high-level option similar to RTEMS_SMP, RTEMS_POSIX_API etc. > Size of the MMU pages - T

Re: Configuration option for thread-stack protection.

On Thu, Aug 6, 2020 at 8:34 PM Gedare Bloom wrote: > On Thu, Aug 6, 2020 at 6:21 AM Sebastian Huber > wrote: > > > > On 06/08/2020 14:12, Utkarsh Rai wrote: > > > > > Hello, > > > The thread-stack protection needs to be configured by the user. Two

Context switching through an ISR in RTEMS

Hello, I have been testing my code for thread stack isolation against various tests( Some written by me, and remaining already present). One of the limitations that I have found is that I encounter fatal errors whenever a context switch takes place through an ISR. Can you please explain how the con

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

t;>> On Tue, Apr 14, 2020 at 10:56 PM Sebastian Huber >>> wrote: >>> > >>> > Hello Utkarsh Rai, >>> > >>> > do we really need a new test program for this test case? I would prefer >>> > add it to an existing test program o

Re: Context switching through an ISR in RTEMS

Thanks, I'll check them out. On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom wrote: > On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai > wrote: > > > > Hello, > > I have been testing my code for thread stack isolation against various > tests( Some written by me, and

Strict thread stack isolation and sharing

Following is the complete set of changes for thread stack isolation and sharing. Configuration for thread stack isolation. > The configuration for thread stack isolation is based upon the new build system. > The RTEMS_THREAD_STACK_PROTECTION option needs to be specified and set to 'True' for en

  1   2   >