Custom Query (16363 matches)
Results (16 - 18 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #18926 | fixed | Problem loading vboxsf.ko after upgrade to 6.0.12 | ||
| Description |
$ uname -r
$ cat /etc/oracle-release After upgrading from 6.0.10 to 6.0.12 (+Guest Additions), shared folders are not available (mounted) anymore.
Trying to manually loading the module I'm getting (in /var/log/message): Just for fun, I tried rebuilding VBoxGuestAdditions after applying the following patch and rebuilding VBoxGuestAdditions, and now I'm able to load the module and mount my shared folders. --- vboxguest-6.0.12/vboxsf/vfsmod.c.orig 2019-09-03 11:48:44.000000000 +0200
+++ vboxguest-6.0.12/vboxsf/vfsmod.c 2019-09-12 13:23:51.083557673 +0200
@@ -434,9 +434,11 @@
{
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 24) && LINUX_VERSION_CODE <= KERNEL_VERSION(4, 12, 0)
bdi_destroy(&pSuperInfo->bdi); /* includes bdi_unregister() */
+/*
# if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 34) && LINUX_VERSION_CODE < KERNEL_VERSION(4, 10, 0)
sb->s_bdi = &noop_backing_dev_info;
# endif
+*/
#endif
}
I know that shouldn't be the way to fix the problem...maybe the commented IF should be verified against 4.1.12-124.31.1.el6uek src(?). Please let me know if you need any test in order to fix the problem. |
|||
| #18945 | fixed | Linux 5.4: no more arbitrary executable pages and more changes | ||
| Description |
It was kindly pointed out that the Linux 5.4 kernel will no longer make interfaces available so that arbitrary kernel modules may modify page attributes to turn the executable bit on/off. Virtualbox currently is one of such kernel modules doing that. From: "Larry Finger" <Larry.Finger@xxxxxxxx> To: vbox-dev@virtualbox.org Subject: [vbox-dev] Problem with kernel 5.4 Date: Wed, 18 Sep 2019 21:16:12 +0200 In kernel 5.4, the wrapper routines set_pages_x() and set_pages_nx() that enable/disable execution of memory are removed. The underlying routines set_memory_x() and set_memory_nx() are not, and will not be exported. See [http://lkml.iu.edu/hypermail/linux/kernel/1909.2/02763.html] for a discussion of the issue. I have currently disabled the only calls to these routines, which occur in alloc-r0drv-linux.c. My test VMs appear to work OK. Is there some case where allocated pages really need to be executable? If so, then the developers at Oracle will need to consult with Linus to develop a method that will be acceptable. In the meantime, I have developed a patch that allows a build with kernel 5.4 that eliminates the offending calls. Larry
https://www.virtualbox.org/pipermail/vbox-dev/2019-September/015343.html Lets see where and how we get that: trunk/src/VBox/Runtime/r0drv/linux/the-linux-kernel.h 339 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 25)
340 # define MY_SET_PAGES_EXEC(pPages, cPages) set_pages_x(pPages, cPages)
341 # define MY_SET_PAGES_NOEXEC(pPages, cPages) set_pages_nx(pPages, cPages)
342 #else
343 # define MY_SET_PAGES_EXEC(pPages, cPages) \
344 do { \
345 if (pgprot_val(MY_PAGE_KERNEL_EXEC) != pgprot_val(PAGE_KERNEL)) \
346 MY_CHANGE_PAGE_ATTR(pPages, cPages, MY_PAGE_KERNEL_EXEC); \
347 } while (0)
348 # define MY_SET_PAGES_NOEXEC(pPages, cPages) \
349 do { \
350 if (pgprot_val(MY_PAGE_KERNEL_EXEC) != pgprot_val(PAGE_KERNEL)) \
351 MY_CHANGE_PAGE_ATTR(pPages, cPages, PAGE_KERNEL); \
352 } while (0)
353 #endif
C symbol: MY_SET_PAGES_EXEC File Function Line
0 the-linux-kernel.h <global> 340 #define MY_SET_PAGES_EXEC(pPages, cPages) set_pages_x(pPages,
cPages)
1 the-linux-kernel.h <global> 343 #define MY_SET_PAGES_EXEC(pPages, cPages) \
2 alloc-r0drv-linux.c RTMemContAlloc 447 MY_SET_PAGES_EXEC(&paPages[iPage], 1);
3 memobj-r0drv-linux.c rtR0MemObjLinuxAllocPages 374 MY_SET_PAGES_EXEC(pMemLnx->apPages[iPage], 1);
trunk/src/VBox/Runtime/r0drv/linux/alloc-r0drv-linux.c 385 * Allocates physical contiguous memory (below 4GB). 386 * The allocation is page aligned and the content is undefined. 387 * 388 * @returns Pointer to the memory block. This is page aligned. 389 * @param pPhys Where to store the physical address. 390 * @param cb The allocation size in bytes. This is always 391 * rounded up to PAGE_SIZE. 392 */ 393 RTR0DECL(void *) RTMemContAlloc(PRTCCPHYS pPhys, size_t cb) [...] 428 * Reserve the pages and mark them executable. 429 */ 430 unsigned iPage; 431 for (iPage = 0; iPage < cPages; iPage++) [...] 445 SetPageReserved(&paPages[iPage]); 446 #if LINUX_VERSION_CODE > KERNEL_VERSION(2, 4, 20) /** @todo find the exact kernel where change_page_attr was introdu ced. */ 447 MY_SET_PAGES_EXEC(&paPages[iPage], 1); 448 #endif 449 } trunk/src/VBox/Runtime/r0drv/linux/memobj-r0drv-linux.c 282 * Internal worker that allocates physical pages and creates the memory object for them.
283 *
284 * @returns IPRT status code.
285 * @param ppMemLnx Where to store the memory object pointer.
286 * @param enmType The object type.
287 * @param cb The number of bytes to allocate.
288 * @param uAlignment The alignment of the physical memory.
289 * Only valid if fContiguous == true, ignored otherwise.
290 * @param fFlagsLnx The page allocation flags (GPFs).
291 * @param fContiguous Whether the allocation must be contiguous.
292 * @param rcNoMem What to return when we're out of pages.
293 */
294 static int rtR0MemObjLinuxAllocPages(PRTR0MEMOBJLNX *ppMemLnx, RTR0MEMOBJTYPE enmType, size_t cb,
295 size_t uAlignment, gfp_t fFlagsLnx, bool fContiguous, int rcNoMem)
296 {
[...]
323 * Allocate the pages.
324 * For small allocations we'll try contiguous first and then fall back on page by page.
325 */
326 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 4, 22)
327 if ( fContiguous
328 || cb <= PAGE_SIZE * 2)
329 {
[...]
363 #else /* < 2.4.22 */
364 /** @todo figure out why we didn't allocate page-by-page on 2.4.21 and older... */
365 paPages = alloc_pages(fFlagsLnx, rtR0MemObjLinuxOrder(cPages));
366 if (!paPages)
367 {
368 rtR0MemObjDelete(&pMemLnx->Core);
369 return rcNoMem;
370 }
371 for (iPage = 0; iPage < cPages; iPage++)
372 {
373 pMemLnx->apPages[iPage] = &paPages[iPage];
374 MY_SET_PAGES_EXEC(pMemLnx->apPages[iPage], 1);
375 if (PageHighMem(pMemLnx->apPages[iPage]))
376 BUG();
377 }
378
379 fContiguous = true;
380 #endif /* < 2.4.22 */
I'll investigate why we'd possibly think we need this anyways and seek to remove that code. |
|||
| #18961 | worksforme | 5.2.X new guest additions don't work with Linux 5.3 kernels | ||
| Description |
The current 5.2.X testbuild guest additions to not quite work with a guest running a Linux 5.3 kernel. testbuilds that contain the fixes for: #18911 (closed defect: fixed) Fixes for Linux kernel 5.3 wanted - part 1 https://www.virtualbox.org/ticket/18911 HOST: Linux lserver 4.18.0-80.11.1.el8_0.x86_64 #1 SMP Thu Sep 12 03:35:29 GMT 2019 x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/os-release NAME="Oracle Linux Server" VERSION="8.0" ID="ol" ID_LIKE="fedora" VARIANT="Server" VARIANT_ID="server" VERSION_ID="8.0" PLATFORM_ID="platform:el8" PRETTY_NAME="Oracle Linux Server 8.0" GUEST: Fedora-Workstation-Live-x86_64-31_Beta-1.1.iso root@localhost ~]# uname -a Linux localhost.localdomain 5.3.0-1.fc31.x86_64 #1 SMP Mon Sep 16 12:34:42 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux [root@localhost ~]# cat /etc/os-release NAME=Fedora VERSION="31 (Workstation Edition)" ID=fedora VERSION_ID=31 VERSION_CODENAME="" PLATFORM_ID="platform:f31" PRETTY_NAME="Fedora 31 (Workstation Edition)" ANSI_COLOR="0;34" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:31" Virtualboxversion:
Linux EL8 64-bit 5.2.x revision 133577
Extension Pack 5.2.x revision 133571
https://www.virtualbox.org/download/testcase/VirtualBox-5.2-5.2.33_133577_el8-1.x86_64.rpm whe installing and compiling the guest additions inside the guest we see: touch: cannot touch '/var/lib/VBoxGuestAdditions/skip-5.3.0-1.fc31.x86_64': No such file or directory Copying additional installer modules ... Installing additional modules ... VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel modules. This may take a while. VirtualBox Guest Additions: To build modules for other installed kernels, run VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup <version> VirtualBox Guest Additions: Building the modules for kernel 5.3.0-1.fc31.x86_64. VirtualBox Guest Additions: Running kernel modules will not be replaced until the system is restarted VirtualBox Guest Additions: Starting. VirtualBox Guest Additions: modprobe vboxsf failed => then reboot the guest. We get the guest to a certain stage at graphcial boot but apparently it does not reach the state where it presents the login screen finally. => removed shared folder from settings and reboot = same problem => removing shared clipboard settings and reboot = same problem NB: This does not happen with the 6.0.X test builds from: https://www.virtualbox.org/wiki/Testbuilds VirtualBox-6.0-6.0.13_133347_el8-1.x86_64.rpm Oracle_VM_VirtualBox_Extension_Pack-6.0.13-133347.vbox-extpack these are also test builds that contain the fixes for: #18911 (closed defect: fixed) Fixes for Linux kernel 5.3 wanted - part 1 https://www.virtualbox.org/ticket/18911 running those on the host and inside the a Fedora 31 kernel 5.3 guest,the shared folders, shared cliboard and everything else just works. So this must be something specific to the 5.2.X virtualbox guest additions. Needs more investigation. |
|||

