Re: DEVFS
In message <[EMAIL PROTECTED]>, Coleman Kane writes: >Who is currently working on the DEVFS? I emailed the last person >to commit to the HOWTO and got no response. I'd like to look into >finisheing this, and may start hacking if no one tells me otherwise... bp@ has a non-working prototype, (as has julian@). None of them fixes the root-mount kludges. None of them implement cloning devices. If you (or a group of people) seriously want to work on DEVFS, send me an email and I will coordinate and try to make sure we get this done *right* so that we cover all the issues we need to cover with devfs (root-mount, jail, cloning etc etc) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DEVFS
Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, Coleman Kane writes: > > >Who is currently working on the DEVFS? I emailed the last person > >to commit to the HOWTO and got no response. I'd like to look into > >finisheing this, and may start hacking if no one tells me otherwise... Well, it was almost fully working before soem core members decided to delete part of the support code for no apparent reason. However there are some new design criteria that need to be considered that the old devfs didn't consider. (that is why one makes a prototype, so that one learns what is important). For example, it turns out that one of the important items a devfs needs to take into account is the ability for an operator to populate chroot/jail regions with a subset of devices. Puting a mountpoint for a devfs on each jail (there could be thousands) is not a winning solution. This suggests that the base filesystem needs to be involved in some way. Also the probing of new devices and disk partitions as they are loaded and created can be problematic. (that is what the deleted code did). I am now of the opinion that there needs to be a kernel devd which is responsible for probing out new partition hierarchies (with it's own context), and other actions within the devfs. it is even possible, given Poul-henning's device nodes within the kernel that much of the functionality that is looked for with devfs can be achieved via other means. Certainly the whole concept is up for discussion. > > bp@ has a non-working prototype, (as has julian@). > > None of them fixes the root-mount kludges. actually the code you and SOS delted DID solve that > > None of them implement cloning devices. no, though have you tried looking at ptys under devfs.. as you use them, more are created.. (a bit of a hack but kinda cute). > > If you (or a group of people) seriously want to work on DEVFS, send > me an email and I will coordinate and try to make sure we get this > done *right* so that we cover all the issues we need to cover with > devfs (root-mount, jail, cloning etc etc) Of better still email me too. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ;_.---._/ presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DEVFS
>> None of them fixes the root-mount kludges. > >actually the code you and SOS delted DID solve that No it didn't. rootvn was still magically wired from rootdev, with DEVFS mounted first it could be looked up with namei in a proper fashion. >> None of them implement cloning devices. >no, though have you tried looking at ptys under devfs.. >as you use them, more are created.. (a bit of a hack but kinda cute). Cute, but not cute enough. We have several devices which do this by now, but we need full cloning ability. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DEVFS
On Sat, 15 Jul 2000, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Coleman Kane writes: > > >Who is currently working on the DEVFS? I emailed the last person > >to commit to the HOWTO and got no response. I'd like to look into > >finisheing this, and may start hacking if no one tells me otherwise... > > bp@ has a non-working prototype, (as has julian@). Poul, I've made a mistake sending you an out of sync and not finished code. > None of them fixes the root-mount kludges. True, it requires some changes to VFS synch code. > None of them implement cloning devices. Again, wrong. If you disagree on what I've proposed it doesn't mean that it didn't work. It is _necessary_ to fix make_dev() usage/implementation to make cloning code clean. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DEVFS
On Sat, Jul 15, 2000, Boris Popov wrote: > On Sat, 15 Jul 2000, Poul-Henning Kamp wrote: > > > In message <[EMAIL PROTECTED]>, Coleman Kane writes: > > > > >Who is currently working on the DEVFS? I emailed the last person > > >to commit to the HOWTO and got no response. I'd like to look into > > >finisheing this, and may start hacking if no one tells me otherwise... > > > > bp@ has a non-working prototype, (as has julian@). > > Poul, I've made a mistake sending you an out of sync and not > finished code. > > > None of them fixes the root-mount kludges. > > True, it requires some changes to VFS synch code. > > > None of them implement cloning devices. > > Again, wrong. If you disagree on what I've proposed it doesn't > mean that it didn't work. It is _necessary_ to fix make_dev() > usage/implementation to make cloning code clean. Ok, how about you, phk and julian throw up a list of what devfs should do? I am forming some ideas on how to solve the namespace and device cloning issues, we might make some forward work on this finally? :-) Adrian -- Adrian ChaddBuild a man a fire, and he's warm for the <[EMAIL PROTECTED]>rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DEVFS
This is a great idea. We need a good, well drawn out description of what DEVFS is supposed to accomplish and how we'd like it to work. I will be glad to help out, and perhaps we can get some movement on this. Personally, I'd like to see DEVFS completely replace the current system of nodes in /dev. One nice feature would also be to be able to define aliases of certain devices, such as cdrom, modem, etc... I suppose these could get handled in rc/rc.conf. Also, I really like the idea of being able to create a 'limited' devfs mount for a chroot'd environment. Adrian Chadd had the audacity to say: > > Ok, how about you, phk and julian throw up a list of what devfs should do? > I am forming some ideas on how to solve the namespace and device cloning > issues, we might make some forward work on this finally? :-) > > > Adrian > > -- > Adrian Chadd Build a man a fire, and he's warm for the > <[EMAIL PROTECTED]> rest of the evening. Set a man on fire and > he's warm for the rest of his life. > -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DEVFS
On Saturday, July 15, 2000, Adrian Chadd wrote: > Ok, how about you, phk and julian throw up a list of what devfs should do? > I am forming some ideas on how to solve the namespace and device cloning > issues, we might make some forward work on this finally? :-) I'm not Boris, phk or Julian, but I'd like to add that it should probably integrate the fdesc code. Especially since I'm working on (and am soon going to hopefully commit) code to do more relatively major repairs to fdesc[1]. -- |Chris Costello <[EMAIL PROTECTED]> |[1] Removing all references to DTYPE_* macros. `-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DEVFS
| |One nice feature would also be to be able to define aliases of certain |devices, such as cdrom, modem, etc... I suppose these could get handled |in rc/rc.conf. Also, I really like the idea of being able to create a |'limited' devfs mount for a chroot'd environment. Or via a symlink. - Andrew Reiter<[EMAIL PROTECTED]> Computer Security Engineer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DEVFS
On Sunday, July 16, 2000, Coleman Kane wrote:
> This is a great idea. We need a good, well drawn out description of
> what DEVFS is supposed to accomplish and how we'd like it to work. I
> will be glad to help out, and perhaps we can get some movement on this.
> Personally, I'd like to see DEVFS completely replace the current system
> of nodes in /dev.
That's the point of it, or so I've heard.
> One nice feature would also be to be able to define aliases of certain
> devices, such as cdrom, modem, etc... I suppose these could get handled
> in rc/rc.conf.
Probably using symlinks:
if [ "X$default_modem_device" != "X" ]
then
ln -sf /dev/defaultmodem ${default_modem_device}
fi
if [ "X$default_cdrom_device" != "X" ]
then
ln -sf /dev/cdrom ${default_cdrom_device}
fi
...
I would like to point out that if anyone does this, my advance
suggestion is that you differentiate between data and audio
CDROM.
--
|Chris Costello <[EMAIL PROTECTED]>
|Swap read error. You lose your mind.
`-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: DEVFS
Just to make sure we all know what's going on: Is someone currently tracking this thread and merging ideas into a write-up of what features DEVFS should have, as well as its implementation? I nice text would be fine to stick in the devfs tree to outline this, it would help facilitate work on this project. Chris Costello had the audacity to say: > > On Saturday, July 15, 2000, Adrian Chadd wrote: > > Ok, how about you, phk and julian throw up a list of what devfs should do? > > I am forming some ideas on how to solve the namespace and device cloning > > issues, we might make some forward work on this finally? :-) > >I'm not Boris, phk or Julian, but I'd like to add that it > should probably integrate the fdesc code. Especially since I'm > working on (and am soon going to hopefully commit) code to do > more relatively major repairs to fdesc[1]. > > -- > |Chris Costello <[EMAIL PROTECTED]> > |[1] Removing all references to DTYPE_* macros. > `-- > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DEVFS
In message <[EMAIL PROTECTED]>, Coleman Kane writes: >Just to make sure we all know what's going on: > >Is someone currently tracking this thread and merging ideas into >a write-up of what features DEVFS should have, as well as its >implementation? I consider myself the coordinator for DEVFS, and I track the discussion and ideas that are floated. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DEVFS
Excellent. I saw a large amount of traffic floating around, wanted to see if there was a major coordinator keeping track. Saw a few of your posts earlier, anyway I noted to jkh that I had an interest in helping work on this. It seemed to be on hold for a little while, but listed as unfinished. I'd like to help set a goal of getting it to a finished product before 4.2 and hopefully, getting inclusion in 4.3-R... Poul-Henning Kamp had the audacity to say: > > I consider myself the coordinator for DEVFS, and I track the > discussion and ideas that are floated. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: devfs
On Tue, 3 Jan 2006, TSaplin Mikhail wrote: Hi all i have a problem with devfs device hiding. My system is FreeBSD 6.0 (i386 and amd64, compiled from last sunday source (RELENG_6)) After mounting defs: #mount -t devfs devfs /tmp/proba first devfs command: # devfs -m /tmp/proba rule add type disk hide devfs rule: ioctl DEVFSIO_RADD: Input/output error the second command hangs: # devfs -m /tmp/proba rule add type disk hide command doesnt responds on HUP and TERM signals A week or two ago I fixed a bug in devfs where an error condition results in a lock leak, followed by hanging processes and a deadlock. I merged the change to RELENG_6 this morning having returned from India yesterday night. If a fair number of people are running into this, we may want to merge it to RELENG_6_0 and do an errata announcement for it. The change you want is this one: revision 1.21 date: 2006/01/03 09:49:10; author: rwatson; state: Exp; lines: +4 -2 When returning EIO from DEVFSIO_RADD ioctl, drop the exclusive rule lock. Otherwise the system comes to a rather sudden and grinding halt. MFC after: 1 week I ran into it while on travel, as I was trying to get devfs to make /dev/bpf* readable by the operator group, and typed the command wrong. The RELENG_6 revision is devfs_rule.c:1.14.2.3. Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: devfs?
In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes: : Kevin D.Wooten <[EMAIL PROTECTED]> writes: : > Well the linux devfs has a compatibility mode that maintains a /dev : > that looks exactly like pre-devfs ( the actual list of files is : > static ), and only links up ( mknod ) the newly added devices to the : > pre-existing files. There is also the non-compatible mode which only : > has files for the devices you actually have, and creates the files : > on demand. : : What's the point with having device nodes for devices you don't have? So open return -1 with errno set to ENXIO rater than ENOENT. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: devfs?
> What's the point with having device nodes for devices you don't have? A warm fuzzy feeling of having all the device nodes you're used to, even if the devices don't exist? :-) Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: devfs?
On Tue, Nov 06, 2001 at 05:16:31PM +0100, Dag-Erling Smorgrav wrote: > Kevin D.Wooten <[EMAIL PROTECTED]> writes: > > Well the linux devfs has a compatibility mode that maintains a /dev > > that looks exactly like pre-devfs ( the actual list of files is > > static ), and only links up ( mknod ) the newly added devices to the > > pre-existing files. There is also the non-compatible mode which only > > has files for the devices you actually have, and creates the files > > on demand. > > What's the point with having device nodes for devices you don't have? Historical sensitivity? Anyone in for a RK05 dev node? ;) -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: devfs deadlock
On Friday 18 August 2006 15:26, Alex Unleashed wrote:
> Hello,
>
> Before anything else I'd like to say I'm working on a SoC project for
> Gentoo for which I have to port a sandbox-like application wrapper (in
> userspace) to FreeBSD, which deals with the building and installing of
> software so that nothing gets screwed in the filesystem. It's
> finished, but unfortunately it gets frozen at random points,
> preventing the system from launching new programs or saving to disk,
> which suggested a kernel bug, as was later confirmed looking at the
> waitchannels and debugging. I know there is someone working out issues
> in devfs code in 6.x, so this might also be interesting to him.
>
> I've been able to reproduce both in 6.1-RELEASE-p3 and 6-STABLE
> (snapshot from August 16th ~01:00 GMT) a deadlock in devfs code which
> leaves the system unable to access the disk. I've come up with some
> interesting debugging info, and it looks to me like there are vnode
> problems while a sx lock is being held.
>
> My take at it is that the deadlock occurs when a process gets a lock
> on a vnode (tagged "devfs") and another process xlocks an sx lock
> ("devfsmount"). For some reason the one holding the sx lock wants to
> get the lock on the vnode through devfs_allocv(), and the other
> process wants to get the sx lock through devfs_lookup(). From this
> point on, pretty much anything wanting to touch the filesystem waits
> forever on devfs_root() for another vnode flagged as VV_ROOT and
> locked by the process holding the sx lock.
>
> Patching the devfs code with fixes from -CURRENT didn't work out.
This deadlock is fixed in current as of this:
kib 2006-09-18 13:23:08 UTC
FreeBSD src repository
Modified files:
sys/fs/devfs devfs.h devfs_devs.c devfs_vfsops.c
devfs_vnops.c
Log:
Resolve the devfs deadlock caused by LOR between devfs_mount->dm_lock and
vnode lock in devfs_allocv. Do this by temporary dropping dm_lock around
vnode locking.
For safe operation, add hold counters for both devfs_mount and devfs_dirent,
and DE_DOOMED flag for devfs_dirent. The facilities allow to continue after
dropping of the dm_lock, by making sure that referenced memory does not
disappear.
Reviewed by:tegge
Tested by: kris
Approved by:kan (mentor)
PR: kern/102335
Revision ChangesPath
1.30 +11 -0 src/sys/fs/devfs/devfs.h
1.47 +12 -1 src/sys/fs/devfs/devfs_devs.c
1.51 +20 -4 src/sys/fs/devfs/devfs_vfsops.c
1.134 +70 -11src/sys/fs/devfs/devfs_vnops.c
and
kib 2006-09-19 14:03:02 UTC
FreeBSD src repository
Modified files:
sys/fs/devfs devfs_vnops.c
Log:
Fix the bug in rev. 1.134. In devfs_allocv_drop_refs(), when not_found == 2
and drop_dm_lock is true, no unlocking shall be attempted. The lock is
already dropped and memory is freed.
Found with: Coverity Prevent(tm)
CID:1536
Approved by:pjd (mentor)
Revision ChangesPath
1.135 +1 -1 src/sys/fs/devfs/devfs_vnops.c
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: devfs panic w/INVARIANTS
On Thu, Feb 04, 2010 at 03:40:28PM -0500, Andrew Gallatin wrote: > I've got a commercial driver that uses device cloning. > At unload time, the driver calls clone_cleanup(). When I unload > the driver when the kernel is built with INVARIANTS, I'll see a > panic in devfs_populate_loop(). This happens in 6-stable, > as well as 8-stable. > > From what I can see the clone has been freed, but it > remains on the devfs cdevp_list. Then the next time > devfs_populate_loop() is called, it trips over the bad > entry (cdp->cdp_dirents points to 0xdeadc0dedeadc0de) > See appended kgdb session. > > If I trace the code path, it looks like clone_cleanup() > calls destroy_devl(). And destroy_devl() will eventually > call devfs_free() if the si_refcnt is zero. But I don't > see anything which will get the cdev removed from > the cdevp_list prior to it being freed. > > The only code I see which will get the cdev removed from > the cdevp_list() seems to be the "GC any lingering devices" > block in devfs_populate_loop > > What am I missing? You did not mentioned it, but my guess is that you create clones from the dev_clone event handler. Please note that devfs_lookup() that fires dev_clone event, consumes a device reference. Thus clone handlers shall do dev_ref(). Due to races with cleanup, you should use MAKEDEV_REF flag for make_dev_credv(9) KPI instead of doing make_dev()/dev_ref() pair. That said, do you really need clones at all ? pgpJxMOAun7Uh.pgp Description: PGP signature
Re: devfs panic w/INVARIANTS
Kostik Belousov wrote: On Thu, Feb 04, 2010 at 03:40:28PM -0500, Andrew Gallatin wrote: I've got a commercial driver that uses device cloning. At unload time, the driver calls clone_cleanup(). When I unload the driver when the kernel is built with INVARIANTS, I'll see a panic in devfs_populate_loop(). This happens in 6-stable, as well as 8-stable. From what I can see the clone has been freed, but it remains on the devfs cdevp_list. Then the next time devfs_populate_loop() is called, it trips over the bad entry (cdp->cdp_dirents points to 0xdeadc0dedeadc0de) See appended kgdb session. If I trace the code path, it looks like clone_cleanup() calls destroy_devl(). And destroy_devl() will eventually call devfs_free() if the si_refcnt is zero. But I don't see anything which will get the cdev removed from the cdevp_list prior to it being freed. The only code I see which will get the cdev removed from the cdevp_list() seems to be the "GC any lingering devices" block in devfs_populate_loop What am I missing? You did not mentioned it, but my guess is that you create clones from the dev_clone event handler. Please note that devfs_lookup() that fires Yes, I do. dev_clone event, consumes a device reference. Thus clone handlers shall do dev_ref(). Due to races with cleanup, you should use MAKEDEV_REF flag for make_dev_credv(9) KPI instead of doing make_dev()/dev_ref() pair. I need to support FreeBSD going all the way back to 6, so that's not an option in some versions. But, I'm talking about device removal time. If I call clone_cleanup() where the clones have dev->si_refcount==1, then I get the use-after-free panic. If I hack things to elevate the reference count (such that dev->si_refcount==2 when clone_cleanup() is called), then I don't get the panic. Are you saying I should have been taking the extra reference via my dev_clone eventhandler? Won't having the extra reference lead to a memory leak? Or am I just mis-reading the code, and this will lead to things being freed normally? That said, do you really need clones at all ? I need to support FreeBSD back to 6.x, and I need to support the linux-like model of opening the "same" /dev/node multiple times and getting unique handles. So I think I need clones. Thanks for the help! Drew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: devfs panic w/INVARIANTS
On Fri, Feb 05, 2010 at 08:51:25AM -0500, Andrew Gallatin wrote: > Kostik Belousov wrote: > >On Thu, Feb 04, 2010 at 03:40:28PM -0500, Andrew Gallatin wrote: > >>I've got a commercial driver that uses device cloning. > >>At unload time, the driver calls clone_cleanup(). When I unload > >>the driver when the kernel is built with INVARIANTS, I'll see a > >>panic in devfs_populate_loop(). This happens in 6-stable, > >>as well as 8-stable. > >> > >>From what I can see the clone has been freed, but it > >>remains on the devfs cdevp_list. Then the next time > >>devfs_populate_loop() is called, it trips over the bad > >>entry (cdp->cdp_dirents points to 0xdeadc0dedeadc0de) > >>See appended kgdb session. > >> > >>If I trace the code path, it looks like clone_cleanup() > >>calls destroy_devl(). And destroy_devl() will eventually > >>call devfs_free() if the si_refcnt is zero. But I don't > >>see anything which will get the cdev removed from > >>the cdevp_list prior to it being freed. > >> > >>The only code I see which will get the cdev removed from > >>the cdevp_list() seems to be the "GC any lingering devices" > >>block in devfs_populate_loop > >> > >>What am I missing? > > > >You did not mentioned it, but my guess is that you create clones from > >the dev_clone event handler. Please note that devfs_lookup() that fires > > Yes, I do. > > >dev_clone event, consumes a device reference. Thus clone handlers shall > >do dev_ref(). > > > >Due to races with cleanup, you should use MAKEDEV_REF flag for > >make_dev_credv(9) KPI instead of doing make_dev()/dev_ref() pair. > > I need to support FreeBSD going all the way back to 6, so that's not an > option in some versions. > > But, I'm talking about device removal time. If I call clone_cleanup() > where the clones have dev->si_refcount==1, then I get the use-after-free > panic. If I hack things to elevate the reference count (such that > dev->si_refcount==2 when clone_cleanup() is called), then I don't > get the panic. > > Are you saying I should have been taking the extra reference > via my dev_clone eventhandler? Won't having the extra reference > lead to a memory leak? Or am I just mis-reading the code, and > this will lead to things being freed normally? Yes, clone handler shall do dev_ref(). Either by doing race-free make_dev_credf(MAKEDEV_REF) call, or by using dev_ref() after make_dev(). > > >That said, do you really need clones at all ? > > I need to support FreeBSD back to 6.x, and I need to support the > linux-like model of opening the "same" /dev/node multiple times > and getting unique handles. So I think I need clones. Wouldn't it be cleaner to use cdevpriv for the 7/8/HEAD where it is present ? And have special #ifdef-ed code for 6, that could be eventually dropped. pgp4s5tFWCcUK.pgp Description: PGP signature
Re: devfs panic w/INVARIANTS
Kostik Belousov wrote: On Fri, Feb 05, 2010 at 08:51:25AM -0500, Andrew Gallatin wrote: Kostik Belousov wrote: On Thu, Feb 04, 2010 at 03:40:28PM -0500, Andrew Gallatin wrote: I've got a commercial driver that uses device cloning. At unload time, the driver calls clone_cleanup(). When I unload the driver when the kernel is built with INVARIANTS, I'll see a panic in devfs_populate_loop(). This happens in 6-stable, as well as 8-stable. >From what I can see the clone has been freed, but it remains on the devfs cdevp_list. Then the next time devfs_populate_loop() is called, it trips over the bad entry (cdp->cdp_dirents points to 0xdeadc0dedeadc0de) See appended kgdb session. If I trace the code path, it looks like clone_cleanup() calls destroy_devl(). And destroy_devl() will eventually call devfs_free() if the si_refcnt is zero. But I don't see anything which will get the cdev removed from the cdevp_list prior to it being freed. The only code I see which will get the cdev removed from the cdevp_list() seems to be the "GC any lingering devices" block in devfs_populate_loop What am I missing? You did not mentioned it, but my guess is that you create clones from the dev_clone event handler. Please note that devfs_lookup() that fires Yes, I do. dev_clone event, consumes a device reference. Thus clone handlers shall do dev_ref(). Due to races with cleanup, you should use MAKEDEV_REF flag for make_dev_credv(9) KPI instead of doing make_dev()/dev_ref() pair. I need to support FreeBSD going all the way back to 6, so that's not an option in some versions. But, I'm talking about device removal time. If I call clone_cleanup() where the clones have dev->si_refcount==1, then I get the use-after-free panic. If I hack things to elevate the reference count (such that dev->si_refcount==2 when clone_cleanup() is called), then I don't get the panic. Are you saying I should have been taking the extra reference via my dev_clone eventhandler? Won't having the extra reference lead to a memory leak? Or am I just mis-reading the code, and this will lead to things being freed normally? Yes, clone handler shall do dev_ref(). Either by doing race-free make_dev_credf(MAKEDEV_REF) call, or by using dev_ref() after make_dev(). OK, cool. The man pages are handy. When I started this back in the FreeBSD 5 days, the man pages didn't exist :) That said, do you really need clones at all ? I need to support FreeBSD back to 6.x, and I need to support the linux-like model of opening the "same" /dev/node multiple times and getting unique handles. So I think I need clones. Wouldn't it be cleaner to use cdevpriv for the 7/8/HEAD where it is present ? And have special #ifdef-ed code for 6, that could be eventually dropped. Yes, the cdevpriv() is a much cleaner interface. I'll probably add support for that soon. Thanks for the help, Drew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: devfs file name NLS encoding?
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] org writes: >Hi, as you know, we can create arbitaly file name on devfs. >But for now, all file names on a devfs are encoded in ASCII. > >If we want to put Japanese file names in devfs, how should it >be encoded? UTF-8 or something convinient for the source encoding? All filenames in DEVFS are either created from the device driver 'C' source (as a string literal via sprintf mostly) or from userland as symlink. So whatever works. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: devfs symlink over device doesn't work
Stef Walter wrote: > After deleting a device in devfs, any symlink placed over it results in > ENOENT. > > I'd like to fix this behavior. Or is there a reason for it that I'm not > seeing? Filed a bug report with a patch that solves the issue: http://www.freebsd.org/cgi/query-pr.cgi?pr=114057 Cheers, Stef Walter ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
