Bug 234134
| Summary: | Increase VM_MAX_NAMELEN value | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Mateusz Kwiatkowski <kwiat3k> |
| Component: | kern | Assignee: | Rodney W. Grimes <rgrimes> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | kaktus, kwiat3k, misho, rgrimes, scottl, swills, virtualization |
| Priority: | --- | ||
| Version: | 12.0-STABLE | ||
| Hardware: | amd64 | ||
| OS: | Any | ||
|
Description
Mateusz Kwiatkowski
2018-12-18 13:52:11 UTC
A little bit of code work to change this into a dynamically allocated string and then raise the limit to pathmax is probably in order. This constant was just a fast path to deployed code. Rodney, thank you for your answer. Are you going to work on this soon? If not can we have it just bumped to 64 for now? I have bhyve work planned over the week between christmas and new years, I have also added virtualization to the CC: list, and am sending an email to have this issue added as a topic for the next bhyve conference call (early January). That sounds great. Thanks! Hi Rodney, Did you have a chance to take a look on this issue? Thanks! (In reply to Mateusz Kwiatkowski from comment #5) Some how I let this slide off the radar, this bug is now on the PR list for the bi-monthly bhyve developers call and shall be discussed at the next meeting on February 21, 2019. As long as there are no issues with doing this I'll create a phabricator review and get this enhancement moved forward. (In reply to Mateusz Kwiatkowski from comment #5) This was discussed during the bhyve developer call on 2019/02/21 and I shall be creating a patch that makes the vm name a dynamic string of size up to MAX_NAMELEN. Look for a diffential review to be added to this PR in the next 2 weeks. (In reply to Rodney W. Grimes from comment #7) Hi Rodney, Any update on this? Hi Rodney, I understand that proper change may take some time but can we have this limit simply bumped to 64 so that it can make into upcoming releases? VM_MAX_NAMELEN can be increased to 63 right now. Any larger and it exceeds the length allowed by the devfs (i.e. /dev) filesystem via the SPECNAMELEN limit. Truncating names in those nodes will be problematic, and increasing the limit will require a significant amount of code review and testing. Would 63 be good enough for now? Hi Scott, Thank you for chiming in. Yes, 63 is fine for our use case. Internally we’re we use limit of 64 and works fine. All VM has UUIDs as their names so well below that though. (In reply to Scott Long from comment #10) Hi Scott, Would you have some free cycles to commit the change? Thank you in advance. See the following review: https://reviews.freebsd.org/D20924 A commit references this bug: Author: scottl Date: Fri Jul 12 18:37:57 UTC 2019 New revision: 349948 URL: https://svnweb.freebsd.org/changeset/base/349948 Log: Tie the name limit of a VM to SPECNAMELEN from devfs instead of a hard-coded value. Don't allocate space for it from the kernel stack. Account for prefix, suffix, and separator space in the name. This takes the effective length up to 229 bytes on 13-current, and 37 bytes on 12-stable. 37 bytes is enough to hold a full GUID string. PR: 234134 MFC after: 1 week Differential Revision: http://reviews.freebsd.org/D20924 Changes: head/sys/amd64/include/vmm.h head/sys/amd64/include/vmm_dev.h head/sys/amd64/vmm/vmm_dev.c *** Bug 243713 has been marked as a duplicate of this bug. *** (In reply to commit-hook from comment #14) > MFC after: 1 week That was about 44 weeks ago. MFC? :-) |
