On Wed, Apr 26, 2023 at 9:32 AM Fotis Panagiotopoulos
wrote:
>
> Hello,
>
> I fixed all critical usages of asprintf and strdup.
>
> These fixes are in the following PRs:
> https://github.com/apache/nuttx/pull/9009
> https://github.com/apache/nuttx/pull/9010
> https://github.com/apache/nuttx-apps/p
I didn't do a careful analysis, but glancing at the ARMv7-A code, it
looks to me that none of the things needed to create stack frames are
available for the kernel stack. It looks like the system call entry
logic just sets the SP to the top of the kernel stack and does very
little more. The a
Hi,
>But, why need involve kheap here? If the security is your concern, you
>should enable per-thread kernel stack in the first place. It's safe to
>allocate waitlist/holder from this stack directly, since userspace code
>can't touch this area too.
Not from a security perspective, and of course I
On Thu, Apr 27, 2023 at 2:18 AM Ville Juven wrote:
> Hi,
>
> Yes exactly, this is the basic idea. Like I said, the waitlist/holder
> structure is needed only when sem_wait needs to block / wait for the
> semaphore to become available.
>
> How to protect the integrity of the stack allocated struct
On 4/26/2023 12:18 PM, Ville Juven wrote:
How to protect the integrity of the stack allocated structure is still a
bit open but one option is to use kheap as well. Semantics to be figured
out, the solution should be feasible.
My idea was to put the handle to this data into the user semaphore, how
Hi,
Yes exactly, this is the basic idea. Like I said, the waitlist/holder
structure is needed only when sem_wait needs to block / wait for the
semaphore to become available.
How to protect the integrity of the stack allocated structure is still a
bit open but one option is to use kheap as well. S
But why not allocate list entry and holder temporally inside the kernel
thread stack? Both data is just used when the calling thread can't hold,
but wait the semphare, this trick is widely used inside Linux kernel.
On Thu, Apr 27, 2023 at 1:32 AM Ville Juven wrote:
> Hi,
>
> Thanks for the expla
Hi,
I think that rtc should be one! If you have two rtcs which one is correct? And
from which one OS will sync time?
>From my point of view if you select both internal rtc and external rtc there
>should be an error
(in this case as a side effect) or the config options for them must be mutually
Hi,
Thanks for the explanation, it makes sense. I had an idea to move struct
sem_s entirely to kernel and make the user use it via a handle (in KERNEL
build) but due to the ubiquitous init macros, that is not a feasible
solution.
I will explore allocating the kernel structures on-demand next.
Wh
Hi,
Thanks for the explanation. I did notice the reason why the macro exists.
If the macro was removed an option I thought of was to implement a lazy
init for the semaphore into e.g. sem_wait(), sem_post() etc. That path will
not work, because like you said, the semaphores exist in many structures
On 4/26/2023 4:10 AM, Ville JUven wrote:
I know it might be too late to fix the usage of SEM_INITIALIZER macro
from user space, as many out-of-tree targets might depend on this as
well, but I'd still like to open a discussion about the possibility of
removing it from user space.
Why remove it
Hello Krasimir,
One of the contributors brought
https://lists.apache.org/thread/y7zrsbf2k86n1qbjlt67hlcj10smjdfw into the
discussion.
Could you please take a look and reply if you agree?
Best regards,
Petro
On Wed, Apr 26, 2023, 10:26 AM Petro Karashchenko <
petro.karashche...@gmail.com> wrote:
I have a question about using mutex_t / struct mutex_s inside
libs/libc. The mutex_t definition is kernel internal but some modules
inside the libs folder use it directly. My question is, is this
intentional ? I don't think such modules should be using mutex_t.
...
My question ? Should the
Hello,
I fixed all critical usages of asprintf and strdup.
These fixes are in the following PRs:
https://github.com/apache/nuttx/pull/9009
https://github.com/apache/nuttx/pull/9010
https://github.com/apache/nuttx-apps/pull/1713
The OS itself is now fixed, there should be no other issues pending
On Wed, Apr 26, 2023 at 8:34 AM Ville Juven wrote:
> Hi,
>
> Thanks for pointing that out, basically the same issue I face.
>
> First I thought it would be simple to fix OR wrap around the usage of
> SEM_INITIALIZER/NXSEM_INITIALIZER/NXMUTEX_INITIALIZER. My assumption was
> that they are not used
Hi,
Thanks for pointing that out, basically the same issue I face.
First I thought it would be simple to fix OR wrap around the usage of
SEM_INITIALIZER/NXSEM_INITIALIZER/NXMUTEX_INITIALIZER. My assumption was
that they are not used in very many places in user space. For wrapping
one option w
Hi,
I know it might be too late to fix the usage of SEM_INITIALIZER macro
from user space, as many out-of-tree targets might depend on this as
well, but I'd still like to open a discussion about the possibility of
removing it from user space.
Why remove it? SEM_INITIALIZER is a non-standard
Hi,
Some time ago I tried to fix this with
https://github.com/apache/nuttx/pull/6376 but it ended-up nowhere as I
didn't find time for a proper solution.
Best regards,
Petro
ср, 26 квіт. 2023 р. о 12:50 Ville JUven пише:
> Hi,
>
> I'm in the process of trying to fix this issue:
> https://githu
Hi,
I'm in the process of trying to fix this issue:
https://github.com/apache/nuttx/issues/8917
TL;DR semaphores are unusable when MMU is in use, because the kernel
private data of struct sem_s exists in user space and is not always
visible to the kernel when it needs it. So I'm trying to se
Please take a look if this https://github.com/apache/nuttx/pull/9104 fixes
the reported issue.
Best regards,
Petro
ср, 26 квіт. 2023 р. о 10:10 Krasimir Cheshmedzhiev
пише:
> Hi,
>
> 12.1, but this exists in earlier versions - 7.27 for example
>
> >>> So you propose not to call up_rtc_initializ
Hi,
12.1, but this exists in earlier versions - 7.27 for example
>>> So you propose not to call up_rtc_initialize(); as well?
No, only when using external rtc.
Should be:
#if defined(CONFIG_RTC) && !defined(CONFIG_RTC_EXTERNAL)
/* Initialize the internal RTC hardware. Initialization of exte
Hi,
Which version are you using? In the latest master I see:
#if defined(CONFIG_RTC)
/* Initialize the internal RTC hardware. Initialization of external RTC
* must be deferred until the system has booted.
*/
up_rtc_initialize();
#if !defined(CONFIG_RTC_EXTERNAL)
/* Initialize the ti
22 matches
Mail list logo
