https://bugzilla.novell.com/show_bug.cgi?id=231171

------- Comment #2 from sndirsch@novell.com 2006-12-30 10:21 MST ------- I remember that we tried to add /dev/dri to /etc/logindevperm in the past, but this was a bad idea since that means that all processes, which access this device are killed when the user's session is terminated. Unfortunately this is also the Xserver, which resulted in undefined behaviour after the first user logged out, mostly machine freezes. :-(

BTW, /etc/logindevperm no longer exists. Don't know how in which way it has been replaced.

The same problematic applies to /dev/nvidia*.

https://bugzilla.novell.com/show_bug.cgi?id=231171

------- Comment #4 from sndirsch@novell.com 2007-01-05 08:10 MST ------- Maybe, but I don't know anything about it. So any help/suggestion would be appreciated. :-)

https://bugzilla.novell.com/show_bug.cgi?id=231171

meissner@novell.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |security-team@suse.de AssignedTo|security-team@suse.de |lnussel@novell.com

------- Comment #6 from meissner@novell.com 2007-01-09 05:45 MST ------- ludwig can help here. he will be back thursday.

https://bugzilla.novell.com/show_bug.cgi?id=231171

sndirsch@novell.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |lnussel@novell.com

------- Comment #8 from sndirsch@novell.com 2007-01-11 02:51 MST ------- I Hope it's ok for you remaining in Cc, Ludwig.

https://bugzilla.novell.com/show_bug.cgi?id=231171

------- Comment #10 from sndirsch@novell.com 2007-01-11 04:07 MST -------

@sndirsch: Is there a respondig device in sysfs for /dev/dri and /dev/nvidia* ?

Probably, but I'm not sure. For nvidia you can verify this on machine "shannon". Matthias, can you help with DRI?

https://bugzilla.novell.com/show_bug.cgi?id=231171

sndirsch@novell.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|birger.kollstrand@googlemail| |.com |

https://bugzilla.novell.com/show_bug.cgi?id=231171

sndirsch@novell.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |eich@novell.com

------- Comment #13 from sndirsch@novell.com 2007-05-12 04:28 MST ------- Egbert, JFYI. Since Matthias or me is in Cc of this bugreport or the reported itself, it might be interesting for you as well.

https://bugzilla.novell.com/show_bug.cgi?id=231171#c15

--- Comment #15 from Stefan Dirsch sndirsch@novell.com 2007-07-04 14:32:46 MST --- Ludwig, we just discussed about this issue. :-)

https://bugzilla.novell.com/show_bug.cgi?id=231171#c17

--- Comment #17 from Stefan Dirsch sndirsch@novell.com 2007-08-11 03:28:58 MST --- Sure, 10.3 is affected, too.

https://bugzilla.novell.com/show_bug.cgi?id=231171

Thomas Biege thomas@novell.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Component|Security |Security Product|openSUSE 10.2 |openSUSE 10.3 Version|Final |RC 1

https://bugzilla.novell.com/show_bug.cgi?id=231171#c20

--- Comment #20 from Birger Kollstrand birger.kollstrand@googlemail.com 2007-09-24 06:40:34 MST --- This will be much more visible when users start using OpenGL accelerated desktops.

https://bugzilla.novell.com/show_bug.cgi?id=231171#c23

--- Comment #23 from Stefan Dirsch sndirsch@novell.com 2007-11-16 07:59:53 MST ---

Only to clarify: we speak about the drm subsystem (e.g. on intel: /dev/dri/card0)?

Yes.

https://bugzilla.novell.com/show_bug.cgi?id=231171#c25

--- Comment #25 from Stefan Dirsch sndirsch@novell.com 2007-11-16 08:03:12 MST --- Created an attachment (id=183705) --> (https://bugzilla.novell.com/attachment.cgi?id=183705) messages

https://bugzilla.novell.com/show_bug.cgi?id=231171#c28

--- Comment #28 from Stefan Dirsch sndirsch@novell.com 2007-11-17 13:15:29 MST --- Whatever I try to attach to this bugreport. Bugzilla tells me

"The attachment you are attempting to access has been removed."

when trying to look at it afterwards. :-(

https://bugzilla.novell.com/show_bug.cgi?id=231171#c33

--- Comment #33 from Stefan Dirsch sndirsch@novell.com 2007-11-19 06:45:43 MST --- NVIDIA does not use DRI at all, fglrx does. I'm not sure, which information you need. Permissions of /dev/nvidia* needs to be set appropriately.

nvidia files I could find in /dev, /proc and /sys.

/dev/nvidia0 /dev/nvidiactl

/proc/irq/16/nvidia /proc/driver/nvidia /proc/driver/nvidia/registry /proc/driver/nvidia/version /proc/driver/nvidia/warnings /proc/driver/nvidia/warnings/README /proc/driver/nvidia/cards /proc/driver/nvidia/cards/0

/sys/module/nvidia /sys/module/nvidia/drivers /sys/module/nvidia/drivers/pci:nvidia /sys/module/nvidia/sections /sys/module/nvidia/sections/.strtab /sys/module/nvidia/sections/.symtab /sys/module/nvidia/sections/.bss /sys/module/nvidia/sections/.gnu.linkonce.this_module /sys/module/nvidia/sections/.data /sys/module/nvidia/sections/__versions /sys/module/nvidia/sections/__ksymtab_strings /sys/module/nvidia/sections/__kcrctab /sys/module/nvidia/sections/__ksymtab /sys/module/nvidia/sections/__param /sys/module/nvidia/sections/.altinstructions /sys/module/nvidia/sections/.smp_locks /sys/module/nvidia/sections/.rodata.str1.1 /sys/module/nvidia/sections/.parainstructions /sys/module/nvidia/sections/.rodata /sys/module/nvidia/sections/.altinstr_replacement /sys/module/nvidia/sections/.init.text /sys/module/nvidia/sections/.exit.text /sys/module/nvidia/sections/.text /sys/module/nvidia/refcnt /sys/module/nvidia/initstate /sys/module/nvidia/holders /sys/module/i2c_core/holders/nvidia /sys/module/agpgart/holders/nvidia /sys/bus/pci/drivers/nvidia /sys/bus/pci/drivers/nvidia/new_id /sys/bus/pci/drivers/nvidia/bind /sys/bus/pci/drivers/nvidia/unbind /sys/bus/pci/drivers/nvidia/uevent /sys/bus/pci/drivers/nvidia/module /sys/bus/pci/drivers/nvidia/0000:01:00.0

https://bugzilla.novell.com/show_bug.cgi?id=231171#c36

Stefan Dirsch sndirsch@novell.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |rohui@nvidia.com, aritger@nvidia.com

--- Comment #36 from Stefan Dirsch sndirsch@novell.com 2007-11-21 02:34:46 MST --- Andy (Ritger) @ NVIDIA, would it be possible to send such an uevent during device creation?

https://bugzilla.novell.com/show_bug.cgi?id=231171#c38

--- Comment #38 from Stefan Dirsch sndirsch@novell.com 2007-11-21 23:26:21 MST --- Thanks, Andy!

We're currently using

NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=33 (33=video on our systems) NVreg_DeviceFileMode=0660

for security reasons. The plan is to set the appropriate permissions for the user, who is currently logged in. I'm clueless about HAL, but I think Danny can help you here.

https://bugzilla.novell.com/show_bug.cgi?id=231171#c41

--- Comment #41 from andy ritger aritger@nvidia.com 2007-11-23 14:39:59 MST --- Hi Danny,

Yes, you understand the current state of the NVIDIA driver correctly.

There is a lot of history, here. Stefan may have additional records on some of this, as he and Greg K-H and I exchanged some correspondence on this back in 2005 (I've pasted some of that below).

I've not tracked sysfs/udev development recently, but back in 2005 device file management in the NVIDIA driver was quite difficult:

- large maintenance burden for NVIDIA, trying to interface properly with the varying device file creation schemes across all the various distributions

- devfs/udev interfaces in the Linux kernel changed frequently and often required driver updates

- there plans to make the interfaces for hotplug/udev sysfs support to be exported GPL-only

- with various kernel versions, device file creation through udev had substantial latency

It is entirely possible that the device file creation interfaces exposed in recent kernels have matured and stabilized and are standardized across Linux distributions since we last looked at this seriously.

However, NVIDIA's current solution of creating the device files from user space has been quite robust over the past few years and required minimal maintenance work for us. We can definitely investigate making use of newer interfaces if there are strong benefits, but I would need help to understand what the interfaces are, and to understand when the new interfaces should be used.

I've included some past exchanges Stefan, Greg, and me. The end result strongly encouraged NVIDIA to create the device files from user space.

Thanks, - Andy

----

Stefan Dirsch: Andy, I wonder whether the nvidia video driver is udev-aware. Could you please comment on this?

Greg thinks so: "In looking at the latest nvidia source tarball I could find, they already have code that calls class_simple_* which creates the entries needed in sysfs for udev to create the device nodes. So I don't think you have to do anything special, if you already have their latest release."

Additional Comment #1 From Andy Ritger 2005-03-04 16:11 MST [reply]

Yes, the NVIDIA driver is udev-aware.

I should point out, though, some problems we encountered with udev:

- it appears that device files do not get created until sometime after the kernel module is loaded

- the kernel module is supposed to be autoloaded when the device files are opened

From our experience in other distros, this led to bootstrapping problems due to

this circular dependency. The 716x driver you have breaks this circular dependency by explicitly loading the kernel module from the X driver during X initialization. Our makedevices.sh script that runs during installation also creates device files in /etc/udev/devices/, which I believe get propogated to /dev/ by the OS, but I am not sure how configuration or distribution specific that is.

All in all, NVIDIA's experience with udev has not been impressive. Hopefully that is just to due to bugs in the initial udev deployments we've seen.

Thanks.

Additional Comment #2 From Greg Kroah-Hartman 2005-03-04 16:43 MST [reply]

Feedback from nvidia, to the udev developers about the issues they have with it, would be greatly appreciated. They can be contacted on the linux-hotplug-devel mailing list, or by direct email to the address in the README file in the udev releases.

Otherwise, such issues will remain unknown, and hence, unfixed by the udev developers :)

Additional Comment #3 From Andy Ritger 2005-04-06 08:18 MST [reply]

Setting resolution to WorksForMe; not sure if that is the most appropriate setting.

Additional Comment #4 From Stefan Dirsch 2005-04-06 08:21 MST [reply]

Perfectly ok for me. Up to now I didn't hear from any udev related problems with the nvidia driver. We can reopen it again, in case there are any. I would like to thank you for commenting on this.

Additional Comment #5 From Andy Ritger 2005-04-06 12:33 MST [reply]

Based on recent developments, though, I wonder why this question was asked. If the class_simple interface is going to not be available to the NVIDIA driver in future kernels, what good does it do for the NVIDIA kernel module to be udev aware?

Additional Comment #6 From Stefan Dirsch 2005-04-06 13:07 MST [reply]

I asked this question since we somewhat switched to udev with SUSE 9.3. I can't comment on the technical details (class_simple interface) since I'm not a kernel developer. Hopefully Greg can ...

Additional Comment #7 From Greg Kroah-Hartman 2005-04-06 13:27 MST [reply]

The in-kernel apis have changed again, yes. But that code hasn't made it into mainline, and will not until some unspecified time after 2.6.12 is released. If nvidia's license isn't compatible with them, there's nothing I can do about it, sorry.

Additional Comment #8 From Andy Ritger 2005-04-06 14:28 MST [reply]

Thanks, Greg.

All my previous experience with SuSE/Novell has been so positive, I'm disappointed to see that attitude taken.

Stefan, to (re)answer your original question: NVIDIA is aware of udev, in that we are aware of its existence and attempt to use it when possible. However, apparently we will not be permitted to use udev in the future.

Additional Comment #9 From Greg Kroah-Hartman 2005-04-06 14:47 MST [reply]

I'm sorry, but this is not a SuSE/Novell attitude at all. It is the "linux kernel developer" hat that I must wear. I have held people off on marking the class_simple() code as GPL only for much longer than I ever expected it to be able to be done, it was only a matter of time.

Sorry for any trouble this might have caused, and good luck with maintaining a kernel driver outside of the kernel tree, I know it is quite difficult and time-consuming.

Legally, I have no idea how you are getting away with doing what you have done so far, but hey, that's why I'm not a lawyer :)

Additional Comment #10 From Andy Ritger 2005-04-06 17:14 MST [reply]

Understood, thanks.

Stefan: I guess just be aware that the NVIDIA driver may not be able to utilize udev in the future. We're investigating other solutions.

Additional Comment #11 From Greg Kroah-Hartman 2005-04-07 03:21 MST [reply]

You might want to look at how vmware handles a udev system, without using sysfs or udev at all. They create their nodes statically in their startup script which is a valid way to handle this.

Additional Comment #12 From Stefan Dirsch 2005-04-07 03:31 MST [reply]

Thanke for the hint, Greg. I think this is something I should take care of.

Additional Comment #13 From Stefan Dirsch 2005-04-07 09:01 MST [reply]

Andy, this is now discussed internally here at SuSE. We'll let you know about the results ASAP.

------

Greg K-H:

class_simple is now gone in the latest -mm releases. I've reworked the core class code to work much like class_simple used to work, and fixed up a number of issues along the way. The other class apis will be removed so that the new class functions are all that is left. This will take a while, but is a good thing as the new functions are much easier to use, understand, and more importantly, almost impossible to use incorrectly. This code will not go into mainline until after 2.6.12 is released.

The new functions are marked EXPORT_SYMBOL_GPL(), so code like nvidia and vmware can't use them. The entire driver core and sysfs was marked this way a while ago (September 2004 to be exact), but the class_simple code was not marked as such because people complained that there was no warning (and they didn't like their closed source modules breaking.) They have had such warning now for a while, and vmware now no longer uses these functions at all.

As the class_simple functions were tiny wrappers around the core class code, people argued a lot with me that they were circumventing the GPL markings of the driver code, and I agreed.

nvidia can modify their startup scripts to just statically create the device nodes, just like vmware does, to have them work properly on a udev aware distro (in fact, that's what they used to do a while ago...) That will solve the issue for them of not being able to export any device major:minor number information in sysfs for udev to pick up on.

I hope this helps clear up any confusion, and provides a solution for what nvidia can do to work with future releases from us.

https://bugzilla.novell.com/show_bug.cgi?id=231171#c43

Stefan Dirsch sndirsch@novell.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|aritger@nvidia.com |

--- Comment #43 from Stefan Dirsch sndirsch@novell.com 2007-11-24 08:15:58 MST --- Thanks, Danny. What exactly should I test?

https://bugzilla.novell.com/show_bug.cgi?id=231171#c45

--- Comment #45 from Stefan Dirsch sndirsch@novell.com 2007-11-24 13:11:32 MST --- Looks good on Intel after installing your packages from

http://download.opensuse.org/repositories/home:/dkukawka:/hal-beta/openSUSE_...

and running "rchal restart".

# lshal [...] udi = '/org/freedesktop/Hal/devices/pci_8086_2982_drm_i915_card0' drm.dri_library = 'i915' (string) drm.version = 'drm 1.1.0 20060810' (string) info.capabilities = {'drm'} (string list) info.category = 'drm' (string) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2982' (string) info.product = 'Direct Rendering Manager Device' (string) info.udi = '/org/freedesktop/Hal/devices/pci_8086_2982_drm_i915_card0' (string) info.vendor = 'Intel Corporation' (string) linux.device_file = '/dev/dri/card0' (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = 'drm' (string) linux.sysfs_path = '/sys/class/drm/card0' (string)

I didn't try this with "fglrx" driver yet.

https://bugzilla.novell.com/show_bug.cgi?id=231171#c47

--- Comment #47 from Danny Kukawka dkukawka@novell.com 2007-11-26 14:37:05 MST --- It's the same problem like with Nvidia. It works for me with the radeon driver.

https://bugzilla.novell.com/show_bug.cgi?id=231171#c49

--- Comment #49 from Stefan Dirsch sndirsch@novell.com 2007-11-27 07:49:38 MST --- Danny means nvidia/fglrx drivers here, not intel. intel should work fine.

https://bugzilla.novell.com/show_bug.cgi?id=231171#c51

Stefan Dirsch sndirsch@novell.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |lnussel@novell.com

--- Comment #51 from Stefan Dirsch sndirsch@novell.com 2007-11-27 08:01:22 MST --- Thanks. Could you explain the fake entries in hal in more detail, please?

https://bugzilla.novell.com/show_bug.cgi?id=231171#c53

--- Comment #53 from Stefan Dirsch sndirsch@novell.com 2007-11-27 09:22:08 MST --- But if I understand it correctly for this we would need a patched hald as well.

https://bugzilla.novell.com/show_bug.cgi?id=231171#c55

Danny Kukawka dkukawka@novell.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |dkukawka@novell.com Status|NEEDINFO |NEW Info Provider|dkukawka@novell.com |

--- Comment #55 from Danny Kukawka dkukawka@novell.com 2007-11-27 10:00:25 MST --- No. 1) we don't want to add every device in sysfs to HAL (also because the most of them provide absolutely no useful info). This would fill HAL with complete useless information. 2) IMO it would not fix the problem of _this_ bug, there is simply no info for NVIDIA/ATI in sysfs (which e.g. tell us the releated /dev entry).

https://bugzilla.novell.com/show_bug.cgi?id=231171#c57

--- Comment #57 from Ludwig Nussel lnussel@novell.com 2007-11-28 01:36:28 MST --- With fake entries I was referring to the workaround using 'hal-device' to create objects in hal that don't exist in sysfs. Of course the patch to add all devices doesn't fix the problem with ATI/NVIDIA.