Re: [Breaking change] Move nxmutex to sched

Hi, just to add that in the normal case obviously the correct process *is* running when the semaphore is accessed (sem_wait(), sem_post()), but there is one exception: sem_waitirq() which is called either by the watchdog ISR or by the signal dispatch logic. In this case most likely the correct

Re: [Breaking change] Move nxmutex to sched

I believe that all of the lists and structures that you are concerned with are already allocated from kernel space memory, but I have not The lists do exist in user memory, although I agree that they should not. Then that is a bug.  It is a serious security error if OS internal data struct

Re: [Breaking change] Move nxmutex to sched

Hi, just to add that in the normal case obviously the correct process *is* running when the semaphore is accessed (sem_wait(), sem_post()), but there is one exception: sem_waitirq() which is called either by the watchdog ISR or by the signal dispatch logic. In this case most likely the correct proc

Re: [Breaking change] Move nxmutex to sched

Hi, thanks again for the responses and bearing with me > I believe that all of the lists and structures that you are concerned > with are already allocated from kernel space memory, but I have not The lists do exist in user memory, although I agree that they should not. > verified that it all c

Re: [Breaking change] Move nxmutex to sched

However, as I said, there are some things in the sem_t structure whose usage is ubiquitous and I don't know if the scalar access macros will be enough, i.e. I don't fully understand how they work / are supposed to work. ... I believe that all of the lists and structures that you are concern

Re: [Breaking change] Move nxmutex to sched

On 4/19/2023 3:33 AM, Ville Juven wrote: However, as I said, there are some things in the sem_t structure whose usage is ubiquitous and I don't know if the scalar access macros will be enough, i.e. I don't fully understand how they work / are supposed to work. ... I believe that all of the list

Re: sched_lock() should be completely removed

> I think sched_lock() should be completely removed > most case we can replace sched_lock() with enter_critical_section(), > at the sametime we add sched_lock()'s ability to the enter_critical_section() > we can replace sched_lock() with mutex ,sem or spinlock。 > directly removal I would not re

Re: [Breaking change] Move nxmutex to sched

Hi, Thanks for the responses. The scalar read / write functions will work when accessing singular fields from the semaphore, and such an access will (or at least should be) always be correctly aligned so there is no risk in the scalar value being split by a page boundary -> no extra work is requir

Re: [ANNOUNCE] Apache NuttX 12.1.0 released

CONGRATZ!! :-) https://nuttx.apache.org/download https://nuttx.apache.org/releases/12.1.0 -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

sched_lock() should be completely removed

Hi, all: The function sched_lock() is used to disable preemption, I also see a lot about sched_lock() discussion in the community, and based on my own experience,I believe that sched_lock() is very easy to misuse and difficult to understand , especially in SMP where sched_lock() has caused many b