sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update TODO list and some Kconfig comments.

Browse Source
This commit is contained in:
Gregory Nutt 2017-03-03 09:20:02 -06:00
parent c2b620b4f8
commit 04c9ccdd2d
2 changed files with 35 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
TODO
View File

@ -19,7 +19,7 @@ nuttx/:
(8) Kernel/Protected Build (8) Kernel/Protected Build
(3) C++ Support (3) C++ Support
(6) Binary loaders (binfmt/) (6) Binary loaders (binfmt/)
(12) Network (net/, drivers/net) (13) Network (net/, drivers/net)
(4) USB (drivers/usbdev, drivers/usbhost) (4) USB (drivers/usbdev, drivers/usbhost)
(0) Other drivers (drivers/) (0) Other drivers (drivers/)
(12) Libraries (libc/, libm/) (12) Libraries (libc/, libm/)
@ -1032,6 +1032,29 @@ o Network (net/, drivers/net)
Status: Open Status: Open
Priority: Low Priority: Low
Title: ETHERNET WITH MULTIPLE LPWORK THREADS
Description: Recently, Ethernet drivers were modified to support multiple
work queue structures. The question was raised: "My only
reservation would be, how would this interact in the case of having CONFIG_STM32_ETHMAC_LPWORK and CONFIG_SCHED_LPNTHREADS
> 1? Can it be guaranteed that one work item won't be
interrupted and execution switched to another? I think so but
am not 100% confident."
I suspect that you right. There are probably vulnerabilities
in the CONFIG_STM32_ETHMAC_LPWORK with CONFIG_SCHED_LPNTHREADS
> 1 case. But that really doesn't depend entirely upon the
change to add more work queue structures. Certainly with only
work queue structure you would have concurrent Ethernet
operations in that multiple LP threads; just because the work
structure is available, does not mean that there is not dequeued
work in progress. The multiple structures probably widens the
window for that concurrency, but does not create it.
The current Ethernet designs depend upon a single work queue to
serialize data. In the case of muliple LP threads, some
additional mechanism would have to be added to enforce that
serialization.
o USB (drivers/usbdev, drivers/usbhost) o USB (drivers/usbdev, drivers/usbhost)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

12
sched/Kconfig
View File

@ -1220,7 +1220,17 @@ config SCHED_LPNTHREADS
This options is required to support, for example, I/O operations This options is required to support, for example, I/O operations
that stall waiting for input. If there is only a single thread, that stall waiting for input. If there is only a single thread,
then the entire low-priority queue processing stalls in such cases. then the entire low-priority queue processing stalls in such cases.
Such behavior is necessary to support asynchronous I/O, AIO (for example). Such behavior is necessary to support asynchronous I/O, AIO (for
example).
CAUTION: Some drivers, such as most Ethernet drivers, use the work
queue to serialize network operations. The will also use the low-
priority work queue if it is available. If there are multiple low-
priority worker thread, then this can result in the loss of that
serialization. There may be concurrent Ethernet operations running
on different LP threads and this could lead to a failure. You may
need to visit the use of the LP work queue on your configuration
is you select CONFIG_SCHED_LPNTHREADS > 1
config SCHED_LPWORKPRIORITY config SCHED_LPWORKPRIORITY
int "Low priority worker thread priority" int "Low priority worker thread priority"