[PATCH rtems-libbsd] ipsec-tools: Fix copying fd_set prior to select
The racoon session code copies an fd_set from one variable into another
prior to calling select. That works well for simple structures.
In libbsd we have to allocate fd_sets instead of using fixed structures
to avoid a problem with file numbers bigger than FD_SETSIZE. The simple
assignment didn't work in that case.
This patch makes sure that a memcpy is used instead.
---
ipsec-tools/src/racoon/session.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/ipsec-tools/src/racoon/session.c b/ipsec-tools/src/racoon/session.c
index 7ea857ba..bd2bd316 100644
--- a/ipsec-tools/src/racoon/session.c
+++ b/ipsec-tools/src/racoon/session.c
@@ -215,6 +215,8 @@ session(void)
#ifndef __rtems__
FD_ZERO(&preset_mask);
#else /* __rtems__ */
+ size_t allocated_mask_size = sizeof(fd_set) *
+ howmany(rtems_libio_number_iops, sizeof(fd_set) * 8);
allocated_preset_mask = calloc(sizeof(fd_set),
howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
if (allocated_preset_mask == NULL)
@@ -352,7 +354,12 @@ session(void)
/* schedular can change select() mask, so we reset
* the working copy here */
+#ifndef __rtems__
active_mask = preset_mask;
+#else /* __rtems__ */
+ memcpy(allocated_active_mask, allocated_preset_mask,
+ allocated_mask_size);
+#endif /* __rtems__ */
error = select(nfds + 1, &active_mask, NULL, NULL, timeout);
if (error < 0) {
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd] ipsec-tools: Fix copying fd_set prior to select
Hello,
I would like to apply this patch on 5 and 6 branches. I'll create
tickets before applying it.
Best regards
Christian
On 2023-05-22 09:36, Christian Mauderer wrote:
The racoon session code copies an fd_set from one variable into another
prior to calling select. That works well for simple structures.
In libbsd we have to allocate fd_sets instead of using fixed structures
to avoid a problem with file numbers bigger than FD_SETSIZE. The simple
assignment didn't work in that case.
This patch makes sure that a memcpy is used instead.
---
ipsec-tools/src/racoon/session.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/ipsec-tools/src/racoon/session.c b/ipsec-tools/src/racoon/session.c
index 7ea857ba..bd2bd316 100644
--- a/ipsec-tools/src/racoon/session.c
+++ b/ipsec-tools/src/racoon/session.c
@@ -215,6 +215,8 @@ session(void)
#ifndef __rtems__
FD_ZERO(&preset_mask);
#else /* __rtems__ */
+ size_t allocated_mask_size = sizeof(fd_set) *
+ howmany(rtems_libio_number_iops, sizeof(fd_set) * 8);
allocated_preset_mask = calloc(sizeof(fd_set),
howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
if (allocated_preset_mask == NULL)
@@ -352,7 +354,12 @@ session(void)
/* schedular can change select() mask, so we reset
* the working copy here */
+#ifndef __rtems__
active_mask = preset_mask;
+#else /* __rtems__ */
+ memcpy(allocated_active_mask, allocated_preset_mask,
+ allocated_mask_size);
+#endif /* __rtems__ */
error = select(nfds + 1, &active_mask, NULL, NULL, timeout);
if (error < 0) {
--
embedded brains GmbH & Co. KG
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
mobile: +49-176-152 206 08
Registergericht: Amtsgericht München
Registernummer: HRA 117265
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems v2 00/12] bsp/imxrt: Update SDK and prepare for new variant
Thanks. I pushed the patches. I'll start a discussion regarding the HALs soon. On 2023-05-15 15:53, Gedare Bloom wrote: I'm fine with the v2 now, thanks for reducing it. Do feel free to start a separate discussion / ticket about how we should handle HALs. I think this problem will only get worse not better. On Tue, May 9, 2023 at 6:11 AM Christian Mauderer wrote: Hello, this is the second version of the patch set to update the SDK files in the i.MXRT BSPs. Like said in the earlier version: I plan to add a i.MXRT1166 based BSP soon. The changes are: - I now only imported the SDK files for i.MXRT1050 and i.MXRT1166. With that the imported files (mainly first patch) are now only 18MB instead of 90MB. - The script to import the files is now removed. I added a link to it in the description of the import patch. I'll create a short note for the documentation soon. - I added some minor fixes that I noted during further tests. The full version of the two big patches (1 and 3) can be found on this branch: https://gitlab.com/c-mauderer/rtems/-/commits/cm/20230509_imxrt/ Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH & Co. KG Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRA 117265 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/5] build: Use CSafeLoader if available
On 22.05.23 01:48, Chris Johns wrote: The support for the CSafeLoader is just about 60 lines of additional code. It would be a nice improvement for systems supporting this feature. I don't have time to work on adding PyYAML with libyaml to the RTEMS Tools right now and I think this would open another maintenance issues. If someone would be unable to get a yaml module with a CSafeLoader, then he would be no longer able to build RTEMS. It is not about the size of the implementation, it is about making 2 classes of performance, those with and those without csafe. I am a firm believer all developers and especially core developers need to be using the exact same tools and code our community users are using. We did not always do this and it resulted in the developers being disconnected from the user experience and I decided I would do what I could to avoid this happening again. I really don't see the issue here. It is just the way to load the items from the file system. This is a very isolated task in the build and having two ways to do this is not a big deal from my point of view. In regards to PyYAML there are a few basic issues with it that I am not sure about. The package can be built without support for the C library even if it is installed. I cannot tell if a pip installed version is using the C YAML package or not. I would like more certainty across our supported hosts before agreeing to us using it. I think it is just too complicated to make sure that the user has a PyYAML with the CSafeLoader available when RTEMS is built. A more robust approach is a fall back to the current implementation if needed. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] tester/rt: use shlex.split to split command args
The regular split-by-space function used to split command arguments
creates compatibility issues with many shell command syntaxes. A
specific example is the handling of string arguments, as shown below:
%define renode_args -e start_opts -e "s %{bsp_resc_script}"
Thus, it is changed to use shlex.split instead. It splits
the command arguments using shell-like syntax. More about shlex
module here: https://docs.python.org/3/library/shlex.html
---
tester/rt/config.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tester/rt/config.py b/tester/rt/config.py
index 8a433af..bf6fdbf 100644
--- a/tester/rt/config.py
+++ b/tester/rt/config.py
@@ -38,6 +38,7 @@ import datetime
import os
import re
import threading
+import shlex
from rtemstoolkit import configuration
from rtemstoolkit import config
@@ -326,7 +327,7 @@ class file(config.file):
if len(_data):
ds = [_data[0]]
if len(_data) > 1:
-ds += _data[1].split()
+ds += shlex.split(_data[1], posix=False)
ds = self.expand(ds)
if _directive == '%console':
--
2.34.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems v1] score/src/pheap*: Remove unreferenced methods
* _Protected_heap_Get_block_size * _Protected_heap_Iterate * _Protected_heap_Resize_block Closes #4909. --- cpukit/include/rtems/score/protectedheap.h | 69 -- cpukit/score/src/pheapgetblocksize.c | 56 cpukit/score/src/pheapiterate.c| 52 -- cpukit/score/src/pheapresizeblock.c| 60 -- spec/build/cpukit/librtemscpu.yml | 3 -- 5 files changed, 240 deletions(-) delete mode 100644 cpukit/score/src/pheapgetblocksize.c delete mode 100644 cpukit/score/src/pheapiterate.c delete mode 100644 cpukit/score/src/pheapresizeblock.c diff --git a/cpukit/include/rtems/score/protectedheap.h b/cpukit/include/rtems/score/protectedheap.h index 884d7e1..2871085 100644 --- a/cpukit/include/rtems/score/protectedheap.h +++ b/cpukit/include/rtems/score/protectedheap.h @@ -163,59 +163,6 @@ static inline void *_Protected_heap_Allocate( } /** - * @brief Returns the size of the allocatable memory area. - * - * The size value may be greater than the initially requested size in - * _Heap_Allocate_aligned_with_boundary(). - * - * Inappropriate values for @a addr will not corrupt the heap, but may yield - * invalid size values. - * - * This method first locks the allocator and after the operation, unlocks it again. - * - * @param heap The heap to operate upon. - * @param addr The starting address of the allocatable memory area. - * @param[out] size Stores the size of the allocatable memory area after the method call. - * - * @retval true The operation was successful. - * @retval false The operation was not successful. - */ -bool _Protected_heap_Get_block_size( - Heap_Control *heap, - void *addr, - uintptr_t *size -); - -/** - * @brief Resizes the block of the allocated memory area. - * - * Inappropriate values for @a addr may corrupt the heap. - * - * This method first locks the allocator and after the resize, unlocks it again. - * - * @param[in, out] heap The heap to operate upon. - * @param addr The starting address of the allocated memory area to be resized. - * @param size The least possible size for the new memory area. Resize may be - * impossible and depends on the current heap usage. - * @param[out] old_size Stores the size available for allocation in the current - * block before the resize after the method call. - * @param[out] new_size Stores the size available for allocation in the resized - * block after the method call. In the case of an unsuccessful resize, - * zero is returned in this parameter - * - * @retval HEAP_RESIZE_SUCCESSFUL The resize was successful. - * @retval HEAP_RESIZE_UNSATISFIED The least possible size @a size was too big. - * Resize not possible. - * @retval HEAP_RESIZE_FATAL_ERROR The block starting at @a addr is not part of - * the heap. - */ -bool _Protected_heap_Resize_block( - Heap_Control *heap, - void *addr, - uintptr_t size -); - -/** * @brief Frees the allocated memory area. * * Inappropriate values for @a addr may corrupt the heap. This method first locks @@ -245,22 +192,6 @@ bool _Protected_heap_Free( Heap_Control *heap, void *addr ); bool _Protected_heap_Walk( Heap_Control *heap, int source, bool dump ); /** - * @brief Iterates over all blocks of the heap. - * - * This method first locks the allocator and after the operation, unlocks it again. - * - * @param[in, out] heap The heap to iterate over. - * @param visitor This will be called for each heap block with - * the argument @a visitor_arg. - * @param[in, out] visitor_arg The argument for all calls of @a visitor. - */ -void _Protected_heap_Iterate( - Heap_Control *heap, - Heap_Block_visitor visitor, - void *visitor_arg -); - -/** * @brief Returns information about used and free blocks for the heap. * * This method first locks the allocator and after the operation, unlocks it again. diff --git a/cpukit/score/src/pheapgetblocksize.c b/cpukit/score/src/pheapgetblocksize.c deleted file mode 100644 index c53a66b..000 --- a/cpukit/score/src/pheapgetblocksize.c +++ /dev/null @@ -1,56 +0,0 @@ -/* SPDX-License-Identifier: BSD-2-Clause */ - -/** - * @file - * - * @ingroup RTEMSScoreProtHeap - * - * @brief This source file contains the implementation of - * _Protected_heap_Get_block_size(). - */ - -/* - * COPYRIGHT (c) 1989-2007. - * On-Line Applications Research Corporation (OAR). - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * 1. Redistributions of source code must retain the above copyright - *notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - *notice, this list of conditions and the following disclaimer in the - *documentation and/or other materials provided with the distribution. - * - * THIS SOFTWARE IS PROVIDED BY
Github Mirrors not syncing with upstream repos
Hello, I have noticed every rtems's github repositories are not syncing with the upstream. From what I know, they sync twice or thrice a day. On Github, the last commit in RTEMS is from 23 March 2023, on RTEMS-source-builder it's from 22 March 2023, on RTEMS-tools it's from 14 March 2023, on RTEMS-libbsd it's from 20, 2023. So I think something broke after 23 March 2023. Thanks, -- Mohd Noor Aman Tinkering with Hardware ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/5] build: Use CSafeLoader if available
On 22/5/2023 6:29 pm, Sebastian Huber wrote: > On 22.05.23 01:48, Chris Johns wrote: >>> The support for the CSafeLoader is just about 60 lines of additional code. >>> It would be a nice improvement for systems supporting this feature. I don't >>> have >>> time to work on adding PyYAML with libyaml to the RTEMS Tools right now and >>> I >>> think this would open another maintenance issues. If someone would be >>> unable to >>> get a yaml module with a CSafeLoader, then he would be no longer able to >>> build >>> RTEMS. >> It is not about the size of the implementation, it is about making 2 classes >> of >> performance, those with and those without csafe. I am a firm believer all >> developers and especially core developers need to be using the exact same >> tools >> and code our community users are using. We did not always do this and it >> resulted in the developers being disconnected from the user experience and I >> decided I would do what I could to avoid this happening again. > > I really don't see the issue here. It is just the way to load the items from > the > file system. This is a very isolated task in the build and having two ways to > do > this is not a big deal from my point of view. Great, lets not go down this path and we all use the same process. >> In regards to PyYAML there are a few basic issues with it that I am not sure >> about. The package can be built without support for the C library even if it >> is >> installed. I cannot tell if a pip installed version is using the C YAML >> package >> or not. I would like more certainty across our supported hosts before >> agreeing >> to us using it. > > I think it is just too complicated to make sure that the user has a PyYAML > with > the CSafeLoader available when RTEMS is built. A more robust approach is a > fall > back to the current implementation if needed. Maybe we move away from YAML for the build system data? Amar and I originally had python and INI files. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd] ipsec-tools: Fix copying fd_set prior to select
Hi,
I have been resolving this by adding:
#define preset_mask *preset_mask_prealloc
#define active_mask *active_mask_prealloc
as the assignment logic works as is. It does not catch FD_ZERO which is a shame
but is helps avoid us adding a special case.
Chris
On 22/5/2023 5:36 pm, Christian Mauderer wrote:
> The racoon session code copies an fd_set from one variable into another
> prior to calling select. That works well for simple structures.
>
> In libbsd we have to allocate fd_sets instead of using fixed structures
> to avoid a problem with file numbers bigger than FD_SETSIZE. The simple
> assignment didn't work in that case.
>
> This patch makes sure that a memcpy is used instead.
> ---
> ipsec-tools/src/racoon/session.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/ipsec-tools/src/racoon/session.c
> b/ipsec-tools/src/racoon/session.c
> index 7ea857ba..bd2bd316 100644
> --- a/ipsec-tools/src/racoon/session.c
> +++ b/ipsec-tools/src/racoon/session.c
> @@ -215,6 +215,8 @@ session(void)
> #ifndef __rtems__
> FD_ZERO(&preset_mask);
> #else /* __rtems__ */
> + size_t allocated_mask_size = sizeof(fd_set) *
> + howmany(rtems_libio_number_iops, sizeof(fd_set) * 8);
> allocated_preset_mask = calloc(sizeof(fd_set),
> howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
> if (allocated_preset_mask == NULL)
> @@ -352,7 +354,12 @@ session(void)
>
> /* schedular can change select() mask, so we reset
>* the working copy here */
> +#ifndef __rtems__
> active_mask = preset_mask;
> +#else /* __rtems__ */
> + memcpy(allocated_active_mask, allocated_preset_mask,
> + allocated_mask_size);
> +#endif /* __rtems__ */
>
> error = select(nfds + 1, &active_mask, NULL, NULL, timeout);
> if (error < 0) {
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/5] build: Use CSafeLoader if available
On 23.05.23 02:42, Chris Johns wrote: On 22/5/2023 6:29 pm, Sebastian Huber wrote: On 22.05.23 01:48, Chris Johns wrote: The support for the CSafeLoader is just about 60 lines of additional code. It would be a nice improvement for systems supporting this feature. I don't have time to work on adding PyYAML with libyaml to the RTEMS Tools right now and I think this would open another maintenance issues. If someone would be unable to get a yaml module with a CSafeLoader, then he would be no longer able to build RTEMS. It is not about the size of the implementation, it is about making 2 classes of performance, those with and those without csafe. I am a firm believer all developers and especially core developers need to be using the exact same tools and code our community users are using. We did not always do this and it resulted in the developers being disconnected from the user experience and I decided I would do what I could to avoid this happening again. I really don't see the issue here. It is just the way to load the items from the file system. This is a very isolated task in the build and having two ways to do this is not a big deal from my point of view. Great, lets not go down this path and we all use the same process. The CSafeLoader approach makes my work more efficient, so I will definitely use it. In regards to PyYAML there are a few basic issues with it that I am not sure about. The package can be built without support for the C library even if it is installed. I cannot tell if a pip installed version is using the C YAML package or not. I would like more certainty across our supported hosts before agreeing to us using it. I think it is just too complicated to make sure that the user has a PyYAML with the CSafeLoader available when RTEMS is built. A more robust approach is a fall back to the current implementation if needed. Maybe we move away from YAML for the build system data? Amar and I originally had python and INI files. This discussion started with a proposal to switch to JSON: https://lists.rtems.org/pipermail/devel/2023-April/075082.html The INI format is a simple key-value format with no support for hierarchical data, so not suitable from my point of view. Using Python code could be an option, however, this gives the writer of the files more freedom and room for creativity. On lesson learnt from converting the autoconf/automake build to the new build system is, that this may cause some issues. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd] ipsec-tools: Fix copying fd_set prior to select
Hello Chris,
On 2023-05-23 03:36, Chris Johns wrote:
Hi,
I have been resolving this by adding:
#define preset_mask *preset_mask_prealloc
#define active_mask *active_mask_prealloc
as the assignment logic works as is. It does not catch FD_ZERO which is a shame
but is helps avoid us adding a special case.
Thanks for the suggestion. I used that solution already in the file
during the initial port. But it doesn't work in this case (and maybe we
should check other cases in libbsd too). It only copies the first
element of the array of fd_sets.
The variables / defines are (in the patched version - see [1]):
static fd_set *allocated_preset_mask, *allocated_active_mask;
static struct fd_monitor *allocated_fd_monitors;
#define preset_mask (*allocated_preset_mask)
#define active_mask (*allocated_active_mask)
#define fd_monitors (allocated_fd_monitors)
They are allocated as follows (see [2]):
allocated_preset_mask = calloc(sizeof(fd_set),
howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
allocated_active_mask = calloc(sizeof(fd_set),
howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
allocated_fd_monitors = calloc(
rtems_libio_number_iops, sizeof(struct fd_monitor));
So basically it's a bunch of arrays of fd_sets. If I now use the
following (unpatched) assignment:
active_mask = preset_mask;
After the preprocessor the line will be
(*allocated_active_mask) = (*allocated_preset_mask);
Which copies only the first element. That's why I had to add the memcpy.
Did I miss some better solution?
Best regards
Christian
[1]
https://git.rtems.org/rtems-libbsd/tree/ipsec-tools/src/racoon/session.c?id=16be3a7c7d3141018c48d5131a3069184cd3937a#n136
[2]
https://git.rtems.org/rtems-libbsd/tree/ipsec-tools/src/racoon/session.c?id=16be3a7c7d3141018c48d5131a3069184cd3937a#n218
Chris
On 22/5/2023 5:36 pm, Christian Mauderer wrote:
The racoon session code copies an fd_set from one variable into another
prior to calling select. That works well for simple structures.
In libbsd we have to allocate fd_sets instead of using fixed structures
to avoid a problem with file numbers bigger than FD_SETSIZE. The simple
assignment didn't work in that case.
This patch makes sure that a memcpy is used instead.
---
ipsec-tools/src/racoon/session.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/ipsec-tools/src/racoon/session.c b/ipsec-tools/src/racoon/session.c
index 7ea857ba..bd2bd316 100644
--- a/ipsec-tools/src/racoon/session.c
+++ b/ipsec-tools/src/racoon/session.c
@@ -215,6 +215,8 @@ session(void)
#ifndef __rtems__
FD_ZERO(&preset_mask);
#else /* __rtems__ */
+ size_t allocated_mask_size = sizeof(fd_set) *
+ howmany(rtems_libio_number_iops, sizeof(fd_set) * 8);
allocated_preset_mask = calloc(sizeof(fd_set),
howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
if (allocated_preset_mask == NULL)
@@ -352,7 +354,12 @@ session(void)
/* schedular can change select() mask, so we reset
* the working copy here */
+#ifndef __rtems__
active_mask = preset_mask;
+#else /* __rtems__ */
+ memcpy(allocated_active_mask, allocated_preset_mask,
+ allocated_mask_size);
+#endif /* __rtems__ */
error = select(nfds + 1, &active_mask, NULL, NULL, timeout);
if (error < 0) {
--
embedded brains GmbH & Co. KG
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
mobile: +49-176-152 206 08
Registergericht: Amtsgericht München
Registernummer: HRA 117265
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd] ipsec-tools: Fix copying fd_set prior to select
On 23/5/2023 4:25 pm, Christian MAUDERER wrote:
> Hello Chris,
>
> On 2023-05-23 03:36, Chris Johns wrote:
>> Hi,
>>
>> I have been resolving this by adding:
>>
>> #define preset_mask *preset_mask_prealloc
>> #define active_mask *active_mask_prealloc
>>
>> as the assignment logic works as is. It does not catch FD_ZERO which is a
>> shame
>> but is helps avoid us adding a special case.
>
> Thanks for the suggestion. I used that solution already in the file during the
> initial port. But it doesn't work in this case (and maybe we should check
> other
> cases in libbsd too). It only copies the first element of the array of
> fd_sets.
>
> The variables / defines are (in the patched version - see [1]):
>
> static fd_set *allocated_preset_mask, *allocated_active_mask;
> static struct fd_monitor *allocated_fd_monitors;
> #define preset_mask (*allocated_preset_mask)
> #define active_mask (*allocated_active_mask)
> #define fd_monitors (allocated_fd_monitors)
>
> They are allocated as follows (see [2]):
>
> allocated_preset_mask = calloc(sizeof(fd_set),
> howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
> allocated_active_mask = calloc(sizeof(fd_set),
> howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
> allocated_fd_monitors = calloc(
> rtems_libio_number_iops, sizeof(struct fd_monitor));
>
> So basically it's a bunch of arrays of fd_sets. If I now use the following
> (unpatched) assignment:
>
> active_mask = preset_mask;
>
> After the preprocessor the line will be
>
> (*allocated_active_mask) = (*allocated_preset_mask);
>
> Which copies only the first element. That's why I had to add the memcpy. Did I
> miss some better solution?
I am using this in ntpd which I checked yesterday:
#ifdef __rtems__
#include
static size_t rtems_ntpd_fds_size;
static int rtems_fd_set_alloc(fd_set **setp) {
if (*setp == NULL) {
rtems_ntpd_fds_size = sizeof(fd_set) *
(howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
*setp = malloc(rtems_ntpd_fds_size);
if (*setp == NULL) {
errno = ENOMEM;
return -1;
}
memset(*setp, 0, rtems_ntpd_fds_size);
}
return 0;
}
#define activefds (*activefds_prealloc)
static fd_set *activefds_prealloc;
#define rtems_activefds_alloc() rtems_fd_set_alloc(&activefds_prealloc)
#else /* __rtems__ */
static fd_set activefds;
#endif /* __rtems__ */
and:
#if __rtems__
#define rdfdes (*rdfdes_prealloc)
static fd_set *rdfdes_prealloc;
#else /* __rtems__ */
fd_set rdfdes;
#endif /* __rtems__ */
int nfound;
#if __rtems__
if (rtems_fd_set_alloc(&rdfdes_prealloc) < 0) {
return;
}
memset(rdfdes_prealloc, 0, rtems_ntpd_fds_size);
#else /* __rtems__ */
FD_ZERO(&set);
#endif /* __rtems__ */
with:
++handler_calls;
rdfdes = activefds;
Stepping:
Thread 9 hit Breakpoint 1, _ntp_io_handler () at
../../bsd/freebsd/contrib/ntp/ntpd/ntp_io.c:3727
3727rdfdes = activefds;
(gdb) x /8bx activefds_prealloc
0x1083e650: 0x200x440x050x200x000x400x000x00
(gdb) x /8bx rdfdes_prealloc
0x108353a0: 0x000x000x000x000x000x000x000x00
(gdb) n
3736t1.tv_usec = 0;
(gdb) x /8bx rdfdes_prealloc
0x108353a0: 0x200x440x050x200x000x400x000x00
Looks ok to me.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
