vfs: getname() / putname() used by VMware drivers

vfs: getname() / putname() used by VMware drivers

[Thomas Jarosch]

Hi Jeff,

I just compiled the VMware kernel modules 9.4.6-1770165
on kernel 3.14.18 (upgrading from 3.4.101).

The functions getname() and putname() are both used
by the "vmblock" and "vmsync" module.

Any chance to revert 8e377d15078a501c4da98471f56396343c407d92
---------------------------------------
vfs: unexport getname and putname symbols

I see no callers in module code.
---------------------------------------

since there are callers to those functions?

Otherwise the VMware code needs to be changed downstream.
For now I've reverted the commit in question locally.

Cheers,
Thomas

Re: vfs: getname() / putname() used by VMware drivers

[Christoph Hellwig]

On Fri, Sep 12, 2014 at 03:57:39PM +0200, Thomas Jarosch wrote:
> Hi Jeff,
> 
> I just compiled the VMware kernel modules 9.4.6-1770165
> on kernel 3.14.18 (upgrading from 3.4.101).
> 
> The functions getname() and putname() are both used
> by the "vmblock" and "vmsync" module.
> 
> Any chance to revert 8e377d15078a501c4da98471f56396343c407d92
> ---------------------------------------
> vfs: unexport getname and putname symbols

No.  that was intentional an no module should use them.

Re: vfs: getname() / putname() used by VMware drivers

[Jeff Layton]

On Fri, 12 Sep 2014 15:57:39 +0200
Thomas Jarosch <thomas.jarosch@intra2net.com> wrote:

> Hi Jeff,
> 
> I just compiled the VMware kernel modules 9.4.6-1770165
> on kernel 3.14.18 (upgrading from 3.4.101).
> 
> The functions getname() and putname() are both used
> by the "vmblock" and "vmsync" module.
> 
> Any chance to revert 8e377d15078a501c4da98471f56396343c407d92
> ---------------------------------------
> vfs: unexport getname and putname symbols
> 
> I see no callers in module code.
> ---------------------------------------
> 
> since there are callers to those functions?
> 
> Otherwise the VMware code needs to be changed downstream.
> For now I've reverted the commit in question locally.
> 
> Cheers,
> Thomas
> 

(I've left Red Hat so the redhat.com address no longer works)

As Christoph says...no, there's no way that we'll revert that.

Those functions have hooks into the audit layer and 3rd party modules
almost universally got their usage wrong.

-- 
Jeff Layton <jlayton@poochiereds.net>

Re: vfs: getname() / putname() used by VMware drivers

[Thomas Jarosch]

Hi Jeff,

On Friday, 12. September 2014 22:12:08 Jeff Layton wrote:
> > I just compiled the VMware kernel modules 9.4.6-1770165
> > on kernel 3.14.18 (upgrading from 3.4.101).
> > 
> > The functions getname() and putname() are both used
> > by the "vmblock" and "vmsync" module.
> > 
> > Any chance to revert 8e377d15078a501c4da98471f56396343c407d92
> > ---------------------------------------
> > vfs: unexport getname and putname symbols
> > 
> > I see no callers in module code.
> > ---------------------------------------
> > 
> > since there are callers to those functions?
> > 
> > Otherwise the VMware code needs to be changed downstream.
> > For now I've reverted the commit in question locally.
> > 
> > Cheers,
> > Thomas
> 
> (I've left Red Hat so the redhat.com address no longer works)
> 
> As Christoph says...no, there's no way that we'll revert that.
> 
> Those functions have hooks into the audit layer and 3rd party modules
> almost universally got their usage wrong.

thanks for the explanation, especially about the audit layer part.

Let's see if Dmitry still works for VMware as the @vmware.com address 
bounces. Adding CC: to Dyno and Dmitry (another address).

Cheers,
Thomas

Re: vfs: getname() / putname() used by VMware drivers

[Dmitry Torokhov]

On September 15, 2014 12:41:40 AM PDT, Thomas Jarosch <thomas.jarosch@intra2net.com> wrote:
>Hi Jeff,
>
>On Friday, 12. September 2014 22:12:08 Jeff Layton wrote:
>> > I just compiled the VMware kernel modules 9.4.6-1770165
>> > on kernel 3.14.18 (upgrading from 3.4.101).
>> > 
>> > The functions getname() and putname() are both used
>> > by the "vmblock" and "vmsync" module.
>> > 
>> > Any chance to revert 8e377d15078a501c4da98471f56396343c407d92
>> > ---------------------------------------
>> > vfs: unexport getname and putname symbols
>> > 
>> > I see no callers in module code.
>> > ---------------------------------------
>> > 
>> > since there are callers to those functions?
>> > 
>> > Otherwise the VMware code needs to be changed downstream.
>> > For now I've reverted the commit in question locally.
>> > 
>> > Cheers,
>> > Thomas
>> 
>> (I've left Red Hat so the redhat.com address no longer works)
>> 
>> As Christoph says...no, there's no way that we'll revert that.
>> 
>> Those functions have hooks into the audit layer and 3rd party modules
>> almost universally got their usage wrong.
>
>thanks for the explanation, especially about the audit layer part.
>

You do not need neither vmsync nor vmblock on kernels past 3.0 so just hack around vmware-coonfig-tools.pl (or whatever the install script is called) and do not compile them.

Hi Thomas,
Thanks.

-- 
Dmitry

Re: Re: vfs: getname() / putname() used by VMware drivers

[Thomas Jarosch]

Hi Dmitry,

On Monday, 15. September 2014 08:28:33 Dmitry Torokhov wrote:
> >> As Christoph says...no, there's no way that we'll revert that.
> >> 
> >> Those functions have hooks into the audit layer and 3rd party modules
> >> almost universally got their usage wrong.
> >
> >thanks for the explanation, especially about the audit layer part.
> 
> You do not need neither vmsync nor vmblock on kernels past 3.0 so just
> hack around vmware-coonfig-tools.pl (or whatever the install script is
> called) and do not compile them.

thanks for the hint, that makes things a lot easier.

Probably a lot of people on the web could stop to publish
compiling-but-more-or-less-working patches to port
those modules to recent kernels ;)

Thanks again,
Thomas

Re: Re: vfs: getname() / putname() used by VMware drivers

[Dmitry Torokhov]

On Thu, Sep 18, 2014 at 03:48:03PM +0200, Thomas Jarosch wrote:
> Hi Dmitry,
> 
> On Monday, 15. September 2014 08:28:33 Dmitry Torokhov wrote:
> > >> As Christoph says...no, there's no way that we'll revert that.
> > >> 
> > >> Those functions have hooks into the audit layer and 3rd party modules
> > >> almost universally got their usage wrong.
> > >
> > >thanks for the explanation, especially about the audit layer part.
> > 
> > You do not need neither vmsync nor vmblock on kernels past 3.0 so just
> > hack around vmware-coonfig-tools.pl (or whatever the install script is
> > called) and do not compile them.
> 
> thanks for the hint, that makes things a lot easier.
> 
> Probably a lot of people on the web could stop to publish
> compiling-but-more-or-less-working patches to port
> those modules to recent kernels ;)

Yeah. Well, it is hard for VMware to go back and adjust already released
tools packages ;). I believe this issue is fixed in newer versions and in
open-vm-tools.

BTW, more and more distributions package open-vm-tools and I believe most of
the needed kernel drivers are now in mainline so things should be getting
better. 

Thanks.

-- 
Dmitry