Re: Locking strategy for device deletion (also see PR kern/48536)

On Wed, 8 Jun 2016, Robert Elz wrote: Date:Wed, 8 Jun 2016 22:16:28 +0800 (PHT) From:Paul Goyette Message-ID: | Hmmm. Would it be valid, then, for my close() routine to reset the | ref-count

dhcpcd and routing of ipv6 prefixes

Can it be that if I use dhcpcd to obtain an IPv6 prefix from my router (a FritzBox in my case), and it assigns the prefix::1 address to the desired interface, that still no routing in that direction occurs? Here is my case: dhcpcd.conf: interface re0 noipv4 interface re1

Re: Locking strategy for device deletion (also see PR kern/48536)

p...@whooppee.com (Paul Goyette) writes: >On Wed, 8 Jun 2016, Michael van Elst wrote: >> p...@whooppee.com (Paul Goyette) writes: >> See misfs/specfs/spec_vnops.c::spec_close(). >> >>> yes, that would certainly explain the situation. It does, however, make >>> it rather difficult to

Re: Locking strategy for device deletion (also see PR kern/48536)

Date: Wed, 8 Jun 2016 19:47:38 +0800 (PHT) From: Paul Goyette For some reason, the device's open() routine is being called twice, but the close() routine is only called once. So every iteration leaves the refcount with a net increment of one. Correct! But,

Re: Locking strategy for device deletion (also see PR kern/48536)

On Tue, Jun 07, 2016 at 06:28:11PM +0800, Paul Goyette wrote: > Can anyone suggest a reliable way to ensure that a device-driver module can > be _really_ safely detached? There's a pserialize scheme for this; see e.g. an old thread called "kicking everybody out of the softc". The catch for

Re: Locking strategy for device deletion (also see PR kern/48536)

On Wed, 8 Jun 2016, Michael van Elst wrote: p...@whooppee.com (Paul Goyette) writes: See misfs/specfs/spec_vnops.c::spec_close(). yes, that would certainly explain the situation. It does, however, make it rather difficult to maintain a valid ref-count! specfs does the open refcounting.

device open/close (was: Locking strategy for device deletion (also see PR kern/48536))

> I'll try to lookup chapter and verse for you in the next week or so 6.2, 197--198.

Re: Locking strategy for device deletion (also see PR kern/48536)

p...@whooppee.com (Paul Goyette) writes: >> See misfs/specfs/spec_vnops.c::spec_close(). >yes, that would certainly explain the situation. It does, however, make >it rather difficult to maintain a valid ref-count! specfs does the open refcounting. The device only has a single bit, open sets

Re: Locking strategy for device deletion (also see PR kern/48536)

hello. For most devices, an open() is called each time a process opens one of the nodes associated with that device. However, the kernel only calls the close routine for the device driver when the last close is called from the last process on the last node that was open for that device

Re: gets in the kernel

Le 07/06/2016 à 18:04, Christos Zoulas a écrit : On Jun 7, 3:20pm, dholland-t...@netbsd.org (David Holland) wrote: -- Subject: Re: gets in the kernel | On Tue, Jun 07, 2016 at 12:36:54PM +0200, Maxime Villard wrote: | > >I noticed that gets_s (a bounded version of gets) was added in the

Re: modules: per-segment policy

Le 08/06/2016 à 08:57, Martin Husemann a écrit : On Wed, Jun 08, 2016 at 05:57:47AM +0800, Paul Goyette wrote: All of this sounds like a good idea. however, there are at least one or two PRs out there related to limits on the amount of address space that modules can occupy, on i386. Where?

Re: Locking strategy for device deletion (also see PR kern/48536)

On Wed, 8 Jun 2016, J. Hannken-Illjes wrote: Well, it almost works! Just one little problem... :) For some reason, the device's open() routine is being called twice, but the close() routine is only called once. So every iteration leaves the refcount with a net increment of one. I cannot

Re: Locking strategy for device deletion (also see PR kern/48536)

> On 08 Jun 2016, at 13:47, Paul Goyette wrote: > > On Wed, 8 Jun 2016, Paul Goyette wrote: > >> On Tue, 7 Jun 2016, Taylor R Campbell wrote: >> >>> Date: Tue, 7 Jun 2016 18:28:11 +0800 (PHT) >>> From: Paul Goyette >>> >>> Can anyone suggest a

Re: Locking strategy for device deletion (also see PR kern/48536)

On Wed, 8 Jun 2016, Paul Goyette wrote: On Tue, 7 Jun 2016, Taylor R Campbell wrote: Date: Tue, 7 Jun 2016 18:28:11 +0800 (PHT) From: Paul Goyette Can anyone suggest a reliable way to ensure that a device-driver module can be _really_ safely detached? General

Re: modules: per-segment policy

On Wed, 8 Jun 2016, Maxime Villard wrote: Le 08/06/2016 à 08:57, Martin Husemann a écrit : On Wed, Jun 08, 2016 at 05:57:47AM +0800, Paul Goyette wrote: All of this sounds like a good idea. however, there are at least one or two PRs out there related to limits on the amount of address space

Re: modules: per-segment policy

On Wed, Jun 08, 2016 at 05:57:47AM +0800, Paul Goyette wrote: > All of this sounds like a good idea. however, there are at least one or > two PRs out there related to limits on the amount of address space that > modules can occupy, on i386. It would seem to me that taking each > module and