Hi,
I like the alignment idea, thanks for bringing it up!
I think forcing the alignment for the semaphore, and accessing it
directly via page pool from the kernel is the simplest and most trivial
thing. It implements what also Greg suggested + fixes the issue of
semaphore being on the page boundary.
Since the semaphores in CONFIG_BUILD_KERNEL just don't work at all
currently, the best option for now, IMHO, is to implement this solution
and always align the semaphores as suggested in (and only in)
CONFIG_BUILD_KERNEL case. This just makes the semaphores work with
minimal code changes.
I still wouldn't bury the idea of splitting the semaphore into user and
kernel parts entirely. To me it would make perfect sense to cleanly
separate things which belong to kernel from the things that belong to
user space. That solution just needs to maintain the real time
properties, as discussed before, and not break existing functionality or
increase memory consumption.
Current semaphore solution, even with the page-pool access, still has
the problem that user side code has got access to structures belonging
to the kernel (lists which kernel loops through while scheduling &
managing priority inheritance). So a user side process corrupting it's
own semaphore structure can at least crash or jam the kernel.
But, first things first, the solution which Ville suggested below would
fix the most burning issue for us for now.
Thanks,
Jukka
On 18.4.2023 10.26, Sebastien Lorquet wrote:
Hi all,
As Tomek said, whatever you choose to do, please make sure everything
of this is absolutely kept optional, at least during the merge and
community validation phase.
I dont think connecting these proposals to CONFIG_BUILD_KERNEL is
granular enough.
Thanks,
Sebastien
Le 18/04/2023 à 09:18, Ville Juven a écrit :
Hi all,
Sorry, this is going a bit off topic.
One wild solution specifically to solve my/our problem
(CONFIG_BUILD_KERNEL) might be to force a "next power-of-two
alignment" for
the semaphore. This would ensure that the semaphore ALWAYS fits within a
single page and remove the need for cross page checks / mappings in this
specific case.
Although I will still implement a more generic map function (it's almost
done anyway), in the case of semaphores this would simply mean that no
semaphore will ever need to be explicitly mapped into kernel memory,
fetching the page pool mapping will be enough.
For our case the size of sem_t is 32 or 40 bytes (depending on
configuration), this would be aligned to 32 ot 64-bytes which ensures
that
the entire structure fits in a single page. The alignment requirement
can
also be flagged behind CONFIG_BUILD_KERNEL, as such a requirement is not
necessary for the flat addressing modes.
What do you think? Too wild, or something worth considering /
acceptable ?
Br,
Ville Juven / pussuw on github
On Mon, Apr 17, 2023 at 8:58 PM Tomek CEDRO <to...@cedro.info> wrote:
if it possible to add new functionality as optional feature?
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
