User Details
- User Since
- Mar 31 2020, 12:57 PM (240 w, 1 d)
Jul 1 2022
Jun 29 2022
I found one minor issue. Even though it's under HWACCEL3 ifdef, I think it should be fixed.
Nov 25 2021
Nov 18 2021
Nov 2 2021
Oct 21 2021
Oct 14 2021
Removed the clamping.
Added newline after variable declaration.
Oct 13 2021
Some style changes.
Added struct proc *p helper variable.
Sep 23 2021
Ping. Any remarks?
Ping. Any comments? (Also for D31898)
Ping. Any remarks?
Sep 13 2021
Add kern.usrstack fallback if kern.stacktop was not found.
Sep 10 2021
- Made sv_stackgap return the size of the stack gap.
- Moved vm_stkgap assignment into exec_stackgap().
- Changed vm_stkgap type to vm_size_t
- Modified a comment to mention that stack gap size is in bytes.
Sep 2 2021
Do you have any remarks about this version of the diff (and also D31692)?
Aug 26 2021
This requires D31516.
Updated setrlimit to automatically adjust stack rlim_cur value by the stack gap size. This also works, however now the rlim_max is properly respected. Ntpd also doesn't crash.
Aug 17 2021
Aug 12 2021
May 11 2021
Ping. Does the patch look good? It's needed for D29553.
Ping. Does the patch look good? It's needed for D29553.
Ping. Does the patch look good? It's needed for D29553.
Apr 28 2021
So, I've looked at this more and setting the stack size to 4096 pages should technically also resolve this problem. I tested this restarting the daemon multiple times and in my case it worked. However, the problem will occur randomly due to random nature of stack gap randomization. By default, the maximum size of stack gap is 15.36MiB on amd64, I'm not sure about other platforms. The default value of kern.elf64.aslr.stack_gap is 3, so in case of amd64, where the default stack limit is equal to 512MiB, that gives us the 15.36MiB number. I used 4096 as this means that we are setting the stack limit to 16MiB, which should leave enough stack for ntpd to work - I think that 15.56MiB is needed (15.36 of stack gap and 200K taken from the fact that we were limiting this to 200K previously), but I rounded this up to 16MiB.
Apr 27 2021
Apr 26 2021
I re-opened D29553. I'm leaving this up as I don't know which will be the accepted method for solving the problem.
Apr 19 2021
Apr 6 2021
Yes, this could be resolved by changing the default stack resource limit from 200KiB to around 16MiB (maximum stack gap that can be created with default settings is 15.36MiB - 3% of default 512MiB stack resource limit). In that case the stack gap would actually exist, so any benefits resulting from it would still be there. Of course, the disadvantage of this approach is the increased resource utilization but that is expected with ASLR anyway. Also, if anyone changes the default stack limit to a lower value, this could result in segfault for them, so I think that information about that should be included somewhere in documentation.
Apr 2 2021
Feb 23 2021
Feb 22 2021
Feb 19 2021
My initial tests did not show any problems, but I only checked some basic functions of the server, for example CGI was not tested. This server is quite minimal, so testing reasonable part of this should not take long. Hopefully, the maintainer will tell us more about that. If not, I'll setup something and test this myself. Disabling PIE entirely, just because it does not build, may be an overkill here.
It seems that the maintainer doesn't have an account here. I'll send an email directly.
Feb 11 2021
Feb 10 2021
I have looked at *.mk files and if I am not mistaken it seems that there is currently no clean way of having a separate default option for PIE for base, as the __DEFAULT_YES_OPTIONS from bsd.opts.mk takes precedence and moving this option from bsd.opts.mk will leave us with no MK_PIE defined.
Jan 28 2021
Added a comment indicating that PIE is incompatible with -mno-abicalls. Thanks, @emaste.
Jan 27 2021
Nov 12 2020
Oct 30 2020
Jul 9 2020
May 22 2020
Replace SOC_NXP_LS1046 with SOC_NXP_LS.
Replace SOC_NXP_LS1046A with SOC_NXP_LS.
Add ls1046_gpio device in kernel config. Replace SOC_NXP_LS1046 with SOC_NXP_LS.
Replace SOC_NXP_LS1046 with SOC_NXP_LS.
Added comment about 1:1 sysclk and coreclk divider nodes.
I'll change it in all the patches to SOC_NXP_LS.
May 21 2020
Modified to work with new version of D24351
Modified driver to use clock id for lookup instead of names.
Modified the way sysclk and coreclk are created - currently
should follow bindings. The clock sources for PLLs are now
selected by driver automatically depending on the presence
of coreclk.
May 15 2020
Moved to dev/iicbus/rtc/ directory.
Moved to dev/iicbus/gpio directory.
May 12 2020
Hi, if you have any more comments or remarks, please let me know. Thanks.
Hi, if you have any more comments or remarks, please let me know. Thanks.
Hi, if you have any more comments or remarks, please let me know. Thanks.
Hi, if you have any more comments or remarks, please let me know. Thanks.
Hi, if you have any more comments or remarks, please let me know. Thanks.
Hi, if you have any more comments or remarks, please let me know. Thanks.
Hi, if you have any more comments or remarks, please let me know. Thanks.
May 11 2020
Added pin_access_32 and pin_config_32 functions.
Changed get_name function to generate "pin <pin_number>" as name.
Additional minor fixes.
Added vf_i2c as driver name in files.arm64
Removed "All rights reserved" from copyright notice.
Added clock enabling in attach function.
May 7 2020
Each PLL has multiple dividers. For each PLL single PLL node is created
and fixed factor clock nodes are created for each divider that the PLL has.
So only a single PLL node exists, but there are multiple divider nodes.
Thanks, I'll prepare patch in the coming days.
The controller is actually connected to platform PLL, which
is always enabled, but since the controller might be used in
different SoC in the future, I'll add clock enabling.
Apr 30 2020
Add dependency on SOC_NXP_LS1046A option.
Renamed file to rx8803.
Removed code that needed interrupts to start before executing.
The problem was with dts file not conforming to device tree documentation. Abandoning.
Added bus_release_resources call and dependency on SOC_NXP_LS1046A.