[vbox-dev] [PATCH] fix file copy in shared folder on Solaris

[Life is hard, and then you die]

On Mon, Nov 07, 2011 at 04:25:46PM +0100, Ramshankar wrote:
> Seems we cannot drop the lock across the uiomove() call that easily
> since we have just one giant lock. The ideal solution would be to
> write more fine-grained locking but I doubt that buys us much in
> terms of performance since the bottleneck is more likely the HGCM
> calls anyway.

Yes, I didn't see any other solution either that was simpler than
redoing all the locking.

> For the time being this seems good, I've integrated this patch.
> Thanks a lot for the contribution!

Great. However, I think there's a problem: you appear to have left out
one part of the patch (the second half of the second hunk): on line
1642 of vboxfs_vnode.c (svn rev 39245) there's still an unconditional
call to mutex_exit(). Was this on purpose? I can't see how this could
be right.

The diff remaining in my tree now is:

------------------------------------------------------------------------
--- a/src/VBox/Additions/solaris/SharedFolders/vboxfs_vnode.c
+++ b/src/VBox/Additions/solaris/SharedFolders/vboxfs_vnode.c
@@ -1639,7 +1639,8 @@ sffs_getpage(
        /* Don't map pages past end of the file. */
        if (off + len > node->sf_stat.sf_size + PAGEOFFSET)
        {
-               mutex_exit(&sffs_lock);
+               if (!is_recursive)
+                       mutex_exit(&sffs_lock);
                return (EFAULT);
        }
 
------------------------------------------------------------------------


  Cheers,

  Ronald


> On 11/ 7/11 01:30 AM, Life is hard, and then you die wrote:
> >
> >Attached is a somewhat hackish patch to fix the kernel panic in
> >https://www.virtualbox.org/ticket/9862 . There's probably a better
> >solution, but I'm not sure what it is. Together with the previous
> >rmdir patch it does make the shared folders usable again, though.
> >
> >The patch is in the public domain.
> >
> >
> >   Cheers,
> >
> >   Ronald
> >