Re: per file descriptor device driver data ?
On 29/05/2015 15:37, Konstantin Belousov wrote: On Fri, May 29, 2015 at 02:24:14PM +0200, Luigi Rizzo wrote: Hi, in the kernel module for netmap we need to store some private data associated to each open netmap file descriptor. Our current design uses devfs_set_cdevpriv() during the open() handler, but for some reason a subsequent devfs_get_cdevpriv(p) returns *p = NULL in additional threads created by the process that did the open(). The manpage devfs_set_cdevpriv() does not mention threads, and so i am a bit puzzled why the cdevpriv is only good for the original thread. Probably, due to a bug, and the bug is more likely in the consumer code, than in cdevpriv. The cdevpriv requires the current file context, i.e. you should be in the context of the syscall which is operating on the file, to get the file related private data. If you believe that the bug is in cdevpriv interface, please provide the minimal example to demonstrate the issue. I know of one case where ZFS driver has to play tricks with devfs_get_cdevpriv(), please see zfs_onexit_fd_hold(). In the linux version 'struct file' has a private_data field that we use for that purpose, and remains valid on all threads. i wonder if there is something similar we can use in FreeBSD. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
per file descriptor device driver data ?
Hi, in the kernel module for netmap we need to store some private data associated to each open netmap file descriptor. Our current design uses devfs_set_cdevpriv() during the open() handler, but for some reason a subsequent devfs_get_cdevpriv(p) returns *p = NULL in additional threads created by the process that did the open(). The manpage devfs_set_cdevpriv() does not mention threads, and so i am a bit puzzled why the cdevpriv is only good for the original thread. In the linux version 'struct file' has a private_data field that we use for that purpose, and remains valid on all threads. i wonder if there is something similar we can use in FreeBSD. cheers luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: per file descriptor device driver data ?
On 05/29/15 14:24, Luigi Rizzo wrote: Our current design uses devfs_set_cdevpriv() during the open() handler, but for some reason a subsequent devfs_get_cdevpriv(p) returns *p = NULL in additional threads created by the process that did the open(). Hi, Are you sure it is the same file handle passed around, that the FD's were not cloned? The devfs_set_cdevpriv() is per struct file in the kernel from my knowledge. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: per file descriptor device driver data ?
On Fri, May 29, 2015 at 02:24:14PM +0200, Luigi Rizzo wrote: Hi, in the kernel module for netmap we need to store some private data associated to each open netmap file descriptor. Our current design uses devfs_set_cdevpriv() during the open() handler, but for some reason a subsequent devfs_get_cdevpriv(p) returns *p = NULL in additional threads created by the process that did the open(). The manpage devfs_set_cdevpriv() does not mention threads, and so i am a bit puzzled why the cdevpriv is only good for the original thread. Probably, due to a bug, and the bug is more likely in the consumer code, than in cdevpriv. The cdevpriv requires the current file context, i.e. you should be in the context of the syscall which is operating on the file, to get the file related private data. If you believe that the bug is in cdevpriv interface, please provide the minimal example to demonstrate the issue. In the linux version 'struct file' has a private_data field that we use for that purpose, and remains valid on all threads. i wonder if there is something similar we can use in FreeBSD. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
