On Sun, Jul 12, 2015 at 06:54:21PM -0700, Chuck Silvers wrote:
> > Now I think it would be nice to also cut coners in VFS_SYNC() when
> > the force flag is used, but that touches filesystem-indpendent code,
> > in dounmount():
> > if ((mp->mnt_flag & MNT_RDONLY) == 0) {
> >
On Thu, Jul 16, 2015 at 06:57:30PM +0200, Emmanuel Dreyfus wrote:
> Hello
>
> I discovered another scenario where force unmount could not work: an
> unresponsive PUFFS filesystem. The filesystem got out of order during an
> operation where the filesystem root vnode is locked. As a result, try
On Fri, Jul 17, 2015 at 06:37:30PM +0200, Emmanuel Dreyfus wrote:
> > `Last locked' tells you the return address of the call to rw_enter
> > that last acquired the lock. (The other addresses may be useful for
> > other lockdebug panics but aren't likely to be of much use here.)
>
> Here is t
On Fri, Jul 17, 2015 at 04:43:36PM +, Taylor R Campbell wrote:
> (Perhaps we ought to put extra lockdebug crud in vn_lock and a new
> vn_unlock in order to track these things down more usefully.)
Yes please :-)
(vn_unlock should exist for symmetry; I've been meaning to institute
it for so l
On Sat, Jul 18, 2015 at 04:59:36AM +0200, Emmanuel Dreyfus wrote:
> David Holland wrote:
>
> > That you've leaked a vnode lock.
>
> I did not leak anything: this is netbsd-7 PUFFS without any add-on from
> me :-/
Must have been pooka then :-) but that
On Thu, Jul 16, 2015 at 07:34:20PM +0200, Emmanuel Dreyfus wrote:
> David Holland wrote:
>
> > Either make vnode locks interruptible, or debug puffs.
> >
> > I favor the former, but lost the argument a few years back. Others
> > (including e.g. yam
On Mon, Aug 03, 2015 at 02:51:37PM -0700, Jeff Rizzo wrote:
> I need to look deeper, but a quick test writing lines of
> ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
>
> Shows that corruption starts when the file is exactly 65536 bytes long
> (with an 8192 byte page size), with anythi
On Sun, Aug 09, 2015 at 02:46:44PM -0400, Thor Lancelot Simon wrote:
> > Just for the archive, this effectively means Pentium+. There are
> > actually 486-class SMP systems.
>
> Heh. There are 386-class SMP systems (including some massively parallel
> ones, some of which even ran open-source
On Mon, Aug 17, 2015 at 08:13:33PM +0200, Martin Husemann wrote:
> On Mon, Aug 17, 2015 at 06:08:32PM +, Stephan wrote:
> > I have just rebooted with WAPBL enabled. Some quick notes:
> > -Creating 1000 files takes 0,25 sec. while almost no xfers happen. (It just
> > goes to the log I guess)
On Tue, Aug 18, 2015 at 01:06:02PM +0200, J. Hannken-Illjes wrote:
> > /root/test/files> time seq 1 1|xargs touch
> > 3.10s real 0.01s user 3.07s system
> > /root/test/files> rm *
> > /root/test/files> time seq 1 2|xargs touch
> > 9.88s real 0.01s user 8.51s sys
On Fri, Aug 28, 2015 at 11:17:24AM +0200, Maxime Villard wrote:
> _11/ UNINITIALIZED VAR: sys/dev/ic/sgec.c
> _12/ USE-AFTER-FREE: sys/arch/mips/alchemy/dev/aupcmcia.c
> _13/ MEMORY LEAK: sys/dev/ic/smc91cxx.c
> _15/ MEMORY LEAK: sys/arch/acorn26/ioc/arcpp.c
> _17/ MEMORY LEAK: sys/dev/ic/gem.
On Mon, Aug 31, 2015 at 04:43:17PM +, Eric Haszlakiewicz wrote:
> On August 30, 2015 11:31:54 PM EDT, Masao Uebayashi
> wrote:
> >I believe that the exact problem exists in userland's dynamically
> >linked libraries/programs, right? If so, how do they deal with this
> >dead code problem
On Mon, Sep 07, 2015 at 11:13:35AM +0200, Joerg Sonnenberger wrote:
> > Two nits:
> >
> > 1) vnode_to_path(9) is undocumented
> > 2) it only works if you are lucky (IIUC) - which you mostly are
> >
> > The former is easy to fix, the latter IMHO is a killer before we expose
> > this inter
On Mon, Sep 07, 2015 at 09:13:11PM +0100, David Laight wrote:
> > There's another problem this thread hasn't mentioned, which is that
> > the result of vnode_to_path for non-directories isn't necessarily
> > unique or deterministic even if the object hasn't been moved about.
>
> Perhaps the k
On Sun, Sep 06, 2015 at 02:36:07PM +0200, Maxime Villard wrote:
> Le 30/08/2015 06:43, David Holland a ?crit :
> > On Fri, Aug 28, 2015 at 11:17:24AM +0200, Maxime Villard wrote:
> > > _11/ UNINITIALIZED VAR: sys/dev/ic/sgec.c
> > > _12/ USE-AFTER-FREE: sys/arch/
As noted in passing elsewhere, it seems that process_write() in
spiflash.c allocates a scratch buffer on every call... and leaks it on
every call too. This clearly isn't a good thing.
Meanwhile the size of buffer it tries to allocate doesn't have any
obvious bound; I suspect it's limited to MAXPHY
On Fri, Sep 11, 2015 at 09:11:02PM +0200, Maxime Villard wrote:
> _26/ INCONSISTENCY: sys/fs/udf/udf_strat_rmw.c [+] rev1.24
: _26/ INCONSISTENCY: sys/fs/udf/udf_strat_rmw.c [+] rev1.24
: Inconsistency at l.622 and l.717.
622:lb_size = lb_size;
717:lb_size = lb_size;
Er wut? That
On Sat, Sep 19, 2015 at 04:18:38PM +0200, Maxime Villard wrote:
> Hi,
> in sys/dev/iscsi/iscsi_ioctl.c:
>
> 1542 free(sess, M_DEVBUF);
> 1543
> 1544 DEB(1, ("Cleanup: session ended %d\n", sess->id));
>
> I guess inverting the two instructions fixes the bug.
>
> Found by
On Sun, Oct 04, 2015 at 11:52:18AM +1100, matthew green wrote:
> how about this:
I would suggest using void * for the unaligned pointer, but other than
that looks at least correctly consistent with the discussion here.
--
David A. Holland
dholl...@netbsd.org
I have a candidate patch for kern/28448, which at this point only
affects -6 (and -5, but it's presumably not getting fixed there) --
the issue is that lookups of ".." can deadlock.
The patch has passed an anita run, so it isn't overtly toxic, but
that's not itself all that persuasive. I don't hav
On Wed, Oct 14, 2015 at 11:01:32PM +, Taylor R Campbell wrote:
>The syscall is sctp_peeloff().
>
> Hmm... Introducing a protocol-specific syscall doesn't strike me as a
> great design. I can imagine wanting to do something similar with,
> e.g., minimalt, if we ever had that in-kerne
On Thu, Nov 05, 2015 at 10:46:17PM +0100, Rhialto wrote:
> > This file (fs/nfs/client/nfs_clvnops.c) is part of a second (dead) nfs
> > implementation from FreeBSD. It is not part of any kernel.
> >
> > Our nfs lives in sys/nfs.
>
> Ok, why is it included in syssrc.tgz then?
> I'd say it
On Fri, Nov 13, 2015 at 08:05:25PM +0800, Paul Goyette wrote:
> One final attempt to summarize the objections that have been made:
> [snip]
One other thing: posix semaphores used to be a module. That code was
made the victim^W showpiece for demonstrating how the New World Order
was going to be.
On Fri, Nov 13, 2015 at 04:41:18PM +, David Holland wrote:
> On Fri, Nov 13, 2015 at 08:05:25PM +0800, Paul Goyette wrote:
> > One final attempt to summarize the objections that have been made:
> > [snip]
>
> One other thing: posix semaphores used to be a module.
On Sat, Nov 14, 2015 at 01:41:00PM +0800, Paul Goyette wrote:
> Is there a good reason to continue to include wapbl.h in the lfs source
> files? As far as I can see, nothing in lfs uses any of the macros or
> structs that are defined in wapbl.h; other than the #include lines, the
> only refere
On Thu, Nov 26, 2015 at 11:38:14PM +0700, Robert Elz wrote:
> (for 4K sector drives, cgd and lvm both give you 1/8 the space that
> you should have had on the device.)
Ewww
> ccd (especially if combining a 4k byte sector device with a 512 byte sector
> device) is simply a mess - perhaps a
On Thu, Nov 26, 2015 at 11:25:21PM +, Michael van Elst wrote:
> dholland-t...@netbsd.org (David Holland) writes:
>
> >The problem I see with carrying around unit values at runtime (besides
> >potential overhead) is that at least in FS-level code it'll make a
On Fri, Nov 27, 2015 at 05:40:39PM +, David Holland wrote:
> On Thu, Nov 26, 2015 at 11:25:21PM +, Michael van Elst wrote:
> > dholland-t...@netbsd.org (David Holland) writes:
> >
> > >The problem I see with carrying around unit values at runtime (besides
As a few people have heard, I thought up a way to implement
per-process namespaces reasonably cheaply without requiring massive
rewrites of everything. It is kind of a hack, but not super awful.
Preliminary patch is here:
http://www.netbsd.org/~dholland/tmp/namespaces-20151127.diff
It at least
On Sun, Nov 29, 2015 at 10:52:18AM +, Michael van Elst wrote:
> mlel...@serpens.de (Michael van Elst) writes:
> >The bizarre disklabel seems to be another problem.
>
> vnd.c says:
>/*
> * For historical reasons, if there's no disklabel
>
On Thu, Dec 10, 2015 at 08:41:50PM -0800, Chuck Silvers wrote:
> > | > So I propose to always check the return value of allocators with
> > | > an 'if' and not a KASSERT.
> > |
> > | There are some codes like "foo = kmem_alloc(size, KM_SLEEP);
> > | KASSERT(foo != NULL)".
> > | Should the co
On Fri, Dec 11, 2015 at 11:00:06AM -0500, Christos Zoulas wrote:
> Fixing kmem_alloc() and friends not to fail under certain conditions might
> be possible, but it could lead to livelock scenarios where everything is
> stuck in the kernel waiting for resources to be freed.
That's a deadlock, no
On Tue, Dec 22, 2015 at 04:15:47PM +, Christos Zoulas wrote:
> 1. Do we have a PR for the MFS umount hang?
Don't think so.
> 2. Do we have a PR for the TEMPFS race?
No. Unless it turns out to be the same as some old existing problem;
but it seems to have appeared only within the last few m
On Wed, Jan 06, 2016 at 08:10:36AM +0800, Paul Goyette wrote:
> Does anyone have any good suggestions for how to arrange for another
> thread/lwp to run so it can remove the extra reference to the logging
> descriptor?
A better suggestion: remove the broken behavior of close().
--
David A. Ho
On Fri, Jan 08, 2016 at 02:33:58PM +0900, Kengo NAKAHARA wrote:
> --- a/sys/kern/subr_prof.c
> +++ b/sys/kern/subr_prof.c
> @@ -48,6 +48,10 @@ __KERNEL_RCSID(0, "$NetBSD: subr_prof.c,v 1.47 2014/07/10
> 21:13:52 christos Exp
> #include
> #include
>
> +#ifdef MULTIPROCESSOR
> +__cpu_
On Fri, Jan 08, 2016 at 06:50:02AM +, David Holland wrote:
> > --- a/sys/kern/subr_prof.c
> > +++ b/sys/kern/subr_prof.c
> > @@ -48,6 +48,10 @@ __KERNEL_RCSID(0, "$NetBSD: subr_prof.c,v 1.47
> 2014/07/10 21:13:52 christos Exp
> > #include
>
On Thu, Jan 07, 2016 at 07:34:33AM +0800, Paul Goyette wrote:
> Based on internal implementation of filemon(4), there is an ordering
> requirement imposed on the sequence of events that occur when a process
> using /dev/filemon exits. In particular, the file descriptor on which the
> device is
On Fri, Jan 08, 2016 at 11:22:28AM +0800, Paul Goyette wrote:
> Yeah, I was trying to avoid the change in semantics. :) The fewer things
> I touch, the fewer things will go wrong, and I definitely don't want to
> break make, which would result in difficulties making[sic] a new version.
> :)
On Fri, Jan 08, 2016 at 07:08:19AM +, David Holland wrote:
> For an example of the right way to do this kind of thing, look in
> kern_acct.c.
Better example: sys_fktrace, since that uses a file handle. And it
does virtually the same thing that filemon's trying to do, excep
On Sat, Jan 09, 2016 at 08:25:05AM +0100, Mateusz Guzik wrote:
> >if (!mutex_tryenter(parent->p_lock)) {
> >mutex_exit(t->p_lock);
> >mutex_enter(parent->p_lock);
>
> As a side note this looks like a bug. t->p_lock is
On Mon, Jan 25, 2016 at 02:31:15PM -0500, Christos Zoulas wrote:
> The directory functions pass around ap_cookies, and ap_ncookies,
> but if one uses kmem_alloc() instead of malloc(), there is no way
> to kmem_free() the buffer, since we don't pass the size. I suggest
> that we add a new field
On Mon, Feb 15, 2016 at 01:42:51PM +0100, Edgar Fu? wrote:
> Is there a special reason for rccide not being listed (not even
> commented out) in the amd64 GENERIC kernel configuration?
> Are there any known issues with that driver?
Nothing I remember hearing about/seeing...
--
David A. Hollan
One of the less useful things we have hanging around is support for
WebNFS, which was something Sun tried to get people to use in place of
http a long time ago.
Is there any reason to keep it? It is not doing any significant harm
(other than it has a tentacle interacting with namei) but it's also
The vnode interface has long had a misfeature where inside VOP_LOOKUP
the filesystem can choose to consume more of the pathname than the
next component.
We have two users of this functionality: hfs, which uses it to allow
addressing resource forks, and rump, which uses it as a shortcut hack
to all
On Sun, Apr 17, 2016 at 03:20:33AM +, David Holland wrote:
> So:
>- Can anyone think of a magic alternative way to handle these cases
> without making an extra vop call? (And without complexifying
> VOP_LOOKUP as much of the point of the whole exercise is to simplify
&
On Fri, Apr 22, 2016 at 09:10:23AM +, Emmanuel Dreyfus wrote:
> I talked to the glusterFS developer that hit the problem about the
> requirement. This is to iplement mandatory locks, a feature not available
> in UFS.
UFS isn't relevant.
> Quooted below is the scenario chere the problem
On Sat, Apr 23, 2016 at 09:20:28PM +0200, Emmanuel Dreyfus wrote:
> > If something in fuse is causing these cases to share the same open and
> > thus the same struct file, fuse is broken. Fix fuse first.
>
> The NetBSD VFS interface does not let underlying filesystem distinguish
> different s
On Sun, Apr 24, 2016 at 04:40:43AM +0200, Emmanuel Dreyfus wrote:
> > If something in fuse is causing these cases to share the same open and
> > thus the same struct file, fuse is broken. Fix fuse first.
> >
> > If that isn't what's happening, the next possible problem is that
> > puffs/refus
On Wed, Apr 27, 2016 at 03:58:43PM +, Emmanuel Dreyfus wrote:
> On Sun, Apr 24, 2016 at 07:11:37PM +0000, David Holland wrote:
> > Since you said fuse has a way to do that but it doesn't work for our
> > fuse, I guess the right way forward is to make it work in o
On Mon, May 02, 2016 at 04:59:32AM +0300, Valery Ushakov wrote:
> I've accidentally wrote a Forth for sh3 (long story). I thought it
> might be interesting to put it into the kernel so that it can be
> hooked into DDB.
> [...]
> Is this something that might be of general interest?
Sure... a
On Sun, May 15, 2016 at 03:54:07PM -0700, Lyndon Nerenberg wrote:
> > On most architectures, you can't use the FPU in the kernel at this time.
>
> Something that's lacking is a portable API that lets problem state
> programs tell the kernel they are using the FP etc. registers and
> need them
On Mon, Jun 06, 2016 at 04:57:02AM +1000, matthew green wrote:
> > I noticed that gets_s (a bounded version of gets) was added in the kernel.
> > While this iis nice, it conflicts with the c-11 "Annex K" which has a
> > different prototype (takes rsize_t instead of size_t). Perhaps we should
>
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 kernel.
> >While this iis nice, it conflicts with the c-11 "Annex K" which has a
> >different prototype (takes rsize_t instead of size_t). Perhaps we should
> >r
On Tue, Jun 07, 2016 at 12:04:26PM -0400, Christos Zoulas wrote:
> | How about not giving people the false impression it's part of Annex K?
> |
> | > gets is not gets either, and so far nobody has complained about it.
>
> Yes, that was my point. I also wanted to remove gets() in SA complete
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 arbi
On Wed, Jun 08, 2016 at 12:52:33PM +0200, Maxime Villard wrote:
> 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
On Fri, Jun 10, 2016 at 03:13:43PM +, David Holland wrote:
> > libsa is just made of many libc-like functions. getl and
> > bounded_gets are not close to anything in userland. gets_s is, even
> > though it is in annex K.
>
> It's more important not to l
A while back the filehandle type for ffs was fixed to have a 64-bit
inode number instead of silently truncating to 32 bits. Yesterday I
naively merged that change into lfs and it exploded the world.
It seems that lfs has an extra 32-bit field in its filehandle (that
ffs doesn't) -- it is a copy of
On Tue, Jul 05, 2016 at 02:00:35AM +, co...@sdf.org wrote:
> After failing to fix enough broken things with the interrupt code by
> reading it, I wanted to try adding some code to let me know when the
> interrupt level was changed.
>
> I've attempted to add a couple of PRINTFs from , but
On Sat, Jul 09, 2016 at 04:57:20PM -0700, John Nemeth wrote:
> A number of people have expressed reservation (bring up memories
> of device_t and how long that took to settle out) indicating that
> this should be done on a branch or something. Personally, I don't
> see the need to do so.
On Sat, Jul 09, 2016 at 08:45:15PM -0700, John Nemeth wrote:
> } The substance of that reservation is that there's not much point doing
> } it without also taking the time to correct the behavior, i.e., back
> } out properly if something fails. And that requires attention, not just
> } mechanic
Is there any reason lfs is using a global (rather than per-volume)
lock? ad@ seems to have introduced it but as usual there's little in
the way of reasoning or explanation.
--
David A. Holland
dholl...@netbsd.org
On Thu, Jul 14, 2016 at 08:50:26AM -0400, Christos Zoulas wrote:
> | On Wed, Jul 13, 2016 at 02:39:37PM -0400, Christos Zoulas wrote:
> | > great, are we doing something about tunefs?
> |
> | You mean fsck_ext2fs ?
>
> Tunefs so we can adjust superblock flags.
Should we have a fs-independe
On Sat, Jul 16, 2016 at 02:27:32PM +0800, Paul Goyette wrote:
> Is there a reason for emitting these unused externs?
"bugs"
It's obviously wrong, so I think you should just commit the fix... :-)
--
David A. Holland
dholl...@netbsd.org
On Thu, Jul 21, 2016 at 01:21:57PM +, co...@sdf.org wrote:
> I've been reading the vfs code for no reason.
>
> in vfs_bio.c:802 we have:
> vp = bp->b_vp;
>
> then we have a test if it's NULL, but strangely, we do not leave the
> function, we continue with it.
>
> there is even a c
On Fri, Jul 29, 2016 at 10:08:48AM +0200, Maxime Villard wrote:
> >IIRC some software relies on this feature, like emulators/wine. If
> >really so then something like a sysctl to allow it again would be helpful.
>
> I thought about that. The only emulator-related problem I found is [1],
> bec
On Thu, Aug 18, 2016 at 07:58:53PM +0200, Jose Luis Rodriguez Garcia wrote:
> > LFS writes the metadata at the same time, in the same place as the data.
> > No synchronous writes necessary.
>
> As I understand LFS needs to do synchronous writes when there is
> metadata operations (directories
some quibbles:
On Thu, Aug 18, 2016 at 05:24:53PM +, Eduardo Horvath wrote:
> And you should be able to roll back the
> filesystem to snapshots of any earlier synchronization points.
In LFS there are only two snapshots and in practice often one of
them's not valid (because it was halfway t
On Thu, Aug 18, 2016 at 07:00:02PM +, Eduardo Horvath wrote:
> > > And you should be able to roll back the
> > > filesystem to snapshots of any earlier synchronization points.
> >
> > In LFS there are only two snapshots and in practice often one of
> > them's not valid (because it was ha
On Fri, Sep 09, 2016 at 11:09:49PM +0200, Jose Luis Rodriguez Garcia wrote:
> This is a continuation of the thread Is factible to implement full
> writes of stripes to raid using NVRAM memory in LFS.
> http://mail-index.netbsd.org/tech-kern/2016/08/18/msg020982.html
>
> I want to discuss in w
On Thu, Sep 22, 2016 at 07:57:00AM +0800, Paul Goyette wrote:
> While not particularly part of wapbl itself, I would like to see its
> callers (ie, lfs) be more modular!
lfs is not related to wapbl, or even (now) ufs.
> Currently, ffs (whether built-in or modular) has to be built with OPTIONS
On Fri, Sep 23, 2016 at 11:49:50AM +0200, Edgar Fu? wrote:
> > The whole point of tagged queueing is to let you *not* set [the write
> > cache] bit in the mode pages and still get good performance.
>
> I don't get that. My understanding was that TCQ allowed the drive
> to re-order commands wi
On Fri, Sep 23, 2016 at 07:51:32PM +0200, Manuel Bouyer wrote:
> > > *if you have the write cache disabled*
> >
> > *Running with the write cache enabled is a bad idea*
>
> On ATA devices, you can't permanently disable the write cache. You have
> to do it on every power cycles.
There are a
On Sat, Oct 01, 2016 at 05:00:10PM +, Taylor R Campbell wrote:
> It's also suboptimal that we sleep while holding rwlocks for vnode
> locks, since rw_enter is uninterruptable, so if a wait inside the
> kernel hangs with a vnode lock held, anyone else trying to examine
> that vnode will hang
On Tue, Oct 18, 2016 at 09:49:34PM +0200, Aymeric Vincent wrote:
> in order to avoid breaking working setups using a dsrtc at iic, I
> introduced a flag DSRTC_FLAG_YEAR_START_2K to impose a base year of 2000
> on a per-chip basis. The existing code starts at POSIX_BASE_YEAR (1970),
> with the c
On Sun, Oct 23, 2016 at 06:27:09PM +0200, Jarom?r Dole?ek wrote:
> I have the filesystem mounted async and the machine has huge amount of
> RAM, without logging at the moment. So it's mostly buffer cache
> exercise, with i/o spikes on sync.
>
> I see interesting thing - periodically, all of t
We still have elements of union wait hanging around in sys/wait.h.
This has been deprecated for > 20 years; does anyone mind if I G/C
them?
(I think just about all the legacy code in pkgsrc that uses union wait
has been fixed by now as it doesn't exist on a number of other
systems; but if not, it'
On Sun, Nov 13, 2016 at 09:33:53AM +0800, Paul Goyette wrote:
> While starting to investigate the possibility of modularizing the if_wm(4)
> driver, I discovered some issues where signed expressions are being
> compared to unsigned expressions. When if_wm.c is being compiled as a
> built-in dr
On Sat, Dec 10, 2016 at 10:00:30AM +0800, Paul Goyette wrote:
> Yeah. Too bad we don't have the ability to enumerate the set
> of "all platforms". We have the same
> issue with building pci driver modules for only those platforms
> that have pci ...
Maybe if modules interacted with config(1
On a low-memory machine Nick ran into the following deadlock:
(a) rename -> vrele on child -> inactive -> truncate -> getblk ->
no memory in buffer pool -> wait for syncer
(b) syncer waiting for locked parent vnode from the rename
This makes it in general unsafe to vrele while holding a
On Sun, Dec 11, 2016 at 08:39:06PM +, Michael van Elst wrote:
> >On a low-memory machine Nick ran into the following deadlock:
>
> > (a) rename -> vrele on child -> inactive -> truncate -> getblk ->
> > no memory in buffer pool -> wait for syncer
> > (b) syncer waiting for locked p
On Mon, Dec 12, 2016 at 10:55:27AM +0100, J. Hannken-Illjes wrote:
> Some time ago I unconditionally removed LK_NOWAIT from vn_lock().
> Suppose we need this patch:
You realize that isn't sufficient, right? :-) Although it should stop
the deadlock. (see my other mail)
--
David A. Holland
dholl
On Mon, Dec 26, 2016 at 04:40:16PM -0500, Mouse wrote:
> > The only reason I know for mapping address zero [...]
>
> > Anyway mmap() without MAP_FIXED should never return NULL.
>
> Perhaps it's time to implement null pointers as something other than
> all-bits-zero?
Wouldn't help much; the
On Tue, Dec 27, 2016 at 11:15:59AM -0500, Mouse wrote:
> >> Perhaps it's time to implement null pointers as something other than
> >> all-bits-zero?
> > Wouldn't help much; the next obvious (probably only viable) candidate
> > is all-bits-1 and then you just need a slightly larger offset from i
On Tue, Dec 27, 2016 at 06:02:01AM +, Michael van Elst wrote:
> >> I'm not sure wether disks without labels could be used at all in
> >> 4.3bsd.
>
> >Those memories are pretty fuzzy, but I _think_ it worked this way:
>
> >4.3 did not have on-disk disklabels.
>
> 4.3tahoe added the on
(from a while back)
On Wed, Sep 28, 2016 at 02:27:39PM +, paul.kon...@dell.com wrote:
> > On Sep 28, 2016, at 7:22 AM, Jarom?r Dole?ek
> > wrote:
> > I think it's far assesment to say that on SATA with NCQ/31 tags (max
> > is actually 31, not 32 tags), it's pretty much impossible to have
On Fri, Sep 23, 2016 at 08:51:30AM -0600, Warner Losh wrote:
> [*] There is an NCQ version of TRIM, but it requires the AUX register
> to be sent and very few sata hosts controllers support that (though
> AHCI does, many of the LSI controllers don't in any performant way).
I (somewhat idly) won
On Mon, Jan 02, 2017 at 01:01:34PM -0500, Thor Lancelot Simon wrote:
> On Mon, Jan 02, 2017 at 05:31:23PM +0000, David Holland wrote:
> > (from a while back)
> >
> > However, I'm missing something. The I/O queue depths that you need to
> > get peak write perfo
On Thu, Dec 22, 2016 at 12:57:10PM +0100, J. Hannken-Illjes wrote:
> > On 11 Dec 2016, at 21:01, David Holland wrote:
> >
> > On a low-memory machine Nick ran into the following deadlock:
> >
> > (a) rename -> vrele on child -> inactive -> trunc
On Thu, Jan 12, 2017 at 01:31:17AM +, Taylor R Campbell wrote:
>Currently, there's a long comment in src/sys/sys/mutex.h which reads in
>part:
>
>...
> *
> * MUTEX_OWNER(owner)
> * Returns the owner of the adaptive mutex (LWP address).
>
On Sat, Jan 14, 2017 at 04:53:50PM +0100, Thomas Klausner wrote:
> Perhaps there are other, even better solutions. My point is, we should
> switch away from our current method.
>
> Am I overlooking something?
No.
It's the way it is because, mostly, of strident dogmatic insistence on
the part
On Wed, Jan 25, 2017 at 11:05:04PM +0100, Pierre Pronchery wrote:
> Subsidiary question: is there a consensus on the behaviour of the kernel if
> a device driver matches, but then really fails to attach?
The current design is that it's not supposed to happen - drivers that
aren't going to attach
On Sun, Feb 12, 2017 at 11:06:35AM +0800, Paul Goyette wrote:
> 5. Does the current FFS_EI allow for creation of opposite-endian
>file systems? I don't see any endian option for newfs(8).
Not that I know of. Also, based on things I saw when hacking lfs last
year (all of which got fixed), I
On Tue, Feb 14, 2017 at 04:10:11PM -0500, Mouse wrote:
> > [B]ased on things I saw when hacking lfs last year (all of which got
> > fixed), I wouldn't rely on FFS_EI until someone gives it a good
> > thorough audit, preferably with some kind of automated checking tool.
>
> What sort of things
On Tue, Feb 28, 2017 at 10:50:04PM +0800, Jia-Ju Bai wrote:
> Unluckily, after my driver is loaded, I do not see any my "printf" messages
> on the screen before the crash occurs :(
Most likely the problem is either it's dying before any of your
prints, or it dies and resets itself and clears the
On Wed, Mar 01, 2017 at 10:37:00PM +0100, Jarom?r Dole?ek wrote:
> I'm working on an interface for WAPBL to use Force Unit Access (FUA)
> feature on compatible hardware (currently SCSI and NVMe), as a
> replacement to full disk cache flushes. I'd also like to add support
> for DPO (Disable Page
On Thu, Mar 02, 2017 at 09:11:17PM +0100, Jarom?r Dole?ek wrote:
> > Some quick thoughts, though:
> >
> > (1) ultimately it's necessary to patch each driver to crosscheck the
> > flag, because otherwise eventually there'll be silent problems.
>
> Maybe. I think I like having this as responsi
On Thu, Apr 06, 2017 at 06:11:20PM +0800, Paul Goyette wrote:
> Man page for kcopy(9) makes no mention of what happens if the src and dst
> memory regions overlap. :) While we probably don't expect it to happen,
> it would be nice if the behavior were documented. :)
The amd64 version support
On Fri, Apr 07, 2017 at 07:17:05PM +0200, Kamil Rytarowski wrote:
> What's the purpose of ELFOSABI_NETBSD on NetBSD?
Short answer: the OSABI field in the elf header was added way too late
for it to be widely adopted or honored. :-/
--
David A. Holland
dholl...@netbsd.org
On Wed, Jun 14, 2017 at 10:25:11AM -0700, Chuck Silvers wrote:
> while working on updating ZFS to the current freebsd code I've discovered
> that the vnode lifecycle changes in the last couple of years prevent ZFS
> from working, specifically that calling vcache_get() from within VOP_FSYNC()
>
401 - 500 of 951 matches
Mail list logo
