Hi, Sorry for the spamfest. Forget what I said about the alignment being a solution. It is not. Any object allocated from heap that contains a sem_t structure cannot guarantee that the alignment of sem_t is correct.
So I was just being dumb.. Br, Ville Juven On Tue, Apr 18, 2023 at 11:39 AM Jukka Laitinen <jukka.laiti...@iki.fi> wrote: > 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 > >>> >
