[PATCH] Changed 'hello world' as a proof of concept(GSoC 2020).

From: ur10 --- testsuites/samples/hello/init.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c index 34ded37c55..e2a4f30cd1 100644 --- a/testsuites/samples/hello/init.c +++ b/testsuites/samples/hello/init.c

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

On Mon, Sep 28, 2020 at 9:58 PM Gedare Bloom wrote: > Hi Utkarsh, > > I was starting to review this, but then I got a little bit confused by > what you have done. > > I think you may have gone down the wrong path to do this work. It > looks like you copied from libtests/ttes

Error while using the trace linker

Hello, I am following the tracing example as mentioned in the docs <https://docs.rtems.org/branches/master/user/tracing/examples.html> for sparc/erc32 BSP. When I run the "rtems-tld" command, I get the following error - "error: /home/utkarsh/sandbox/bsps/sparc: Invalid RTEM

[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 > wrot

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

topic > has been pursued a few times in GSoC. It would be great if someone can let > me know the current status of this project and guide me about what are the > contributions that can be done this year. > > > Yes, this is a frequently attempted project that slowly makes progress >

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

On Tue, Mar 23, 2021 at 5:49 PM Rajiv Vaidyanathan < rajiv.vaidyanath...@gmail.com> wrote: > Dear Utkarsh, > > Thank you for providing these links. I would like to know if these pending > tasks are long enough to take it up as a GSoC project. > > Resolving the issues r

Re: GSoC Project - Beagle BSP Projects

task. > > Best, > Nils > > On Tue, 23 Mar 2021 at 17:00, Christian MAUDERER < > christian.maude...@embedded-brains.de> wrote: > >> Hello Gedare, >> >> Am 23.03.21 um 16:48 schrieb Gedare Bloom: >> > CC: Nils, Utkarsh >> > >> >

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.

Okay, so from what I could gather the time between the two gettime calls can exceed 1 sec if it is preempted by another process in between. Is my line of thought correct? On Wed, Apr 15, 2020 at 6:01 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > > On 15/04/2020 14

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)

On Tue, May 12, 2020 at 9:27 AM Gedare Bloom wrote: > On Thu, May 7, 2020 at 9:59 PM Hesham Almatary > wrote: > > > > Hello Utkarsh, > > > > I'd suggest you don't spend too much efforts on setting up BBB > > hardware if you haven't already. De

Re: Memory Protection project interface details (GSoC 2020)

l > ultimately be information in the CPU Supplement. > Noted. > > --joel > > On Tue, May 12, 2020 at 5:02 PM Hesham Almatary < > hesham.almat...@cl.cam.ac.uk> wrote: > >> On Tue, 12 May 2020 at 04:57, Gedare Bloom wrote: >> > >> > On Thu, May 7

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)

On Sat, May 16, 2020 at 9:16 PM Joel Sherrill wrote: > > > On Sat, May 16, 2020 at 10:14 AM Gedare Bloom wrote: > >> Utkarsh, >> >> What do you mean by "This would although mean that we would have page >> tables of 1MB." >> >> Check

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

sp=arm/raspberrypi The log file shows the following message- " # project configured on Mon Jun 1 09:19:15 2020 by # waf 2.0.19 (abi 20, python 20711f0 on linux2) # using ./waf configure --rtems=/home/utkarsh/sandbox/rtems/5 --rtems-bsp=arm/raspberrypi # -

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

s the above-suggested implementation feasible? Regards, Utkarsh ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

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

On Fri, Jun 5, 2020 at 6:19 PM Hesham Almatary wrote: > Hello Utkarsh, > > TTBR1 is there primarily for UNIX-like kernels to be re-mapped at very > high addresses and user space can use TTBR0. In the case of RTEMS, we > don't have that user vs kernel separation. Furthermore,

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

r is currently missing. Maybe the mmap_h handler should use a flag to deal with construction and destruction.' I am unclear as to how the mmap_h handler should precisely look like and where should it be defined? I would be grateful if you can provide some help in figuring this out

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

lize. For unsetting stack memories, I plan on making changes to _CPU_Context_Switch(). The problem is when I try to include the header in cpu.h it breaks the build with the following error - '... .... /home/utkarsh/sandbox/rtems/5/arm-rtems5/include/machine/_default_types.h: Ass

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

On Tue, Jul 14, 2020 at 1:13 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Utkarsh, > > if you look a the stuff you added to the score and compare it with > something existing in the score, do you notice differences in the naming > conventions and

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/r

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

When I use the above branch I get the following error on './waf install ' - Build failed Traceback (most recent call last): File "/home/utkarsh/new_build/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Task.py", line 180, in process ret=self.run() File &quo

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

  1   2   3   >