On Sat, Oct 16, 2010 at 11:23:29AM +0900, Izumi Tsutsui wrote:
> > It would seem to be intentional. After all, kernel modules can
> > do all sorts of nasty things if they want to.
>
> In that case, module autoload/autounload is not functional at all and
> we have to specify all possible nece
On Sun, Oct 17, 2010 at 03:03:58AM +0900, Izumi Tsutsui wrote:
> > > If we should I'll enable options INSECURE by default on ports
> > > that require options MODULAR (to save kernel file size).
> >
> > Do not do that. You will introduce a significant security regression
> > just for your own
On Sun, Oct 17, 2010 at 03:38:42AM +0900, Izumi Tsutsui wrote:
> > > Heh, then why have we had it on i386 for years?
> >
> > Because of the X server.
>
> You are just saying:
> "We introduced a significant security regression just for our own
> convenience."
Perhaps...
> I see no prope
On Sat, Oct 16, 2010 at 05:07:30AM -0700, Paul Goyette wrote:
> autoload/autounload does NOT perform any authorization checks -
> please look at the code! No checking of securelevel occurs, as far
> as I can see. For autoload, the module name must not contain a
> '/', so if the module is bein
On Sat, Oct 16, 2010 at 12:03:52PM -0700, Paul Goyette wrote:
> >> autoload/autounload does NOT perform any authorization checks -
> >> please look at the code! No checking of securelevel occurs, as far
> >> as I can see. For autoload, the module name must not contain a
> >> '/', so if the mo
On Sun, Oct 17, 2010 at 06:13:11AM +1100, matthew green wrote:
> > ...and I'm not convinced of this, primarily because (from a practical
> > point of view) X is unavoidable and unfixable, whereas modules are
> > neither.
>
> actually, with DRM (and KMS) i believe we will be able to run the
>
On Sat, Oct 16, 2010 at 08:28:42PM +, Andrew Doran wrote:
> I may be missing your point but there are other ways of sabotaging
> the securelvel mechanism without kernel modules available. It doesn't
> seem like a new problem to me. A more obvious way to be mischievous
> for sure but not n
(adding tech-kern because this seems likely to become lengthy; if
following up please drop source-changes-d)
On Sun, Oct 24, 2010 at 11:30:43AM +0100, David Laight wrote:
> > > [mmap mode disabled in cp due to long vnode lock waits]
> >
> > Because individual write() calls are supposed to be at
On Mon, Oct 25, 2010 at 05:49:11PM +0100, David Laight wrote:
> > No, since in general the file is also being extended (certainly in
> > this case it is) it also has to lock the file size, and that's going
> > to deny stat() until it's done.
>
> A stat request during a write can safely return
On Mon, Nov 01, 2010 at 08:00:09PM -0500, David Young wrote:
> I'm working on a library called ppath(3) for making property lists more
> convenient to use in the kernel. With ppath(3), you refer to a property
> to read/write/delete in a property list by the path from the list's
> outermost con
On Wed, Nov 03, 2010 at 09:28:11AM +0100, Martin Husemann wrote:
> This is one of the ocassions where I would love to use C++ and templates
> in the kernel ;-}
I think what you mean is that you'd like to have a language that has
some kind of sane parameterized types... :-/
--
David A. Holland
On Mon, Nov 08, 2010 at 12:37:01PM +0100, Thomas Klausner wrote:
> On Mon, Nov 08, 2010 at 09:47:29AM +0000, David Holland wrote:
> > Not from me! Although rather than /usr/src it might say "the top level
> > of the source tree".
>
> How about:
> [...]
&g
On Thu, Nov 11, 2010 at 06:35:55PM +0100, Johnny Billquist wrote:
>> [spl mutex stuff]
>
> Hum? So that was introduced with the new locking code then? Because
> back when we used splraise/splx, the above would not have worked.
This would have worked:
s = splvm();
slow_stuff_1();
s2
On Fri, Nov 12, 2010 at 02:21:34PM +0100, Johnny Billquist wrote:
> > > then I realized that this solution would break if people actually
> > > wrote code like
> > > lock(a)
> > > lock(b)
> > > release(a)
> > > release(b)
> >
> >...which is very common.
>
> It is? I would hav
On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo Horvath wrote:
> No it doesen't because all those macros assume the value is being
> transferred from one register to another rather than regiser to memory.
> The assignment:
>
> foo.size = htole64(size);
>
> Cannot be replaced with:
>
On Sat, Nov 13, 2010 at 01:45:40AM +0900, Izumi Tsutsui wrote:
> > Wow. I guess you can add me to the list of people leaving.
>
> There is no perfect world and we don't have enough resources.
>
> Any help to keep support for ancient machines are appreciate, but
> complaints like "we should
(moving this to tech-kern because it's the right place and per request)
On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote:
> > Every header file should include the things it requires to compile.
> > Therefore, there should in principle be no cases where a header file
> > (or sourc
On Mon, Nov 15, 2010 at 10:41:55PM +, David Laight wrote:
> > Indeed. Properly speaking though, headers that are exported to
> > userland should define only the precise symbols that userland needs;
> > kernel-only material should be kept elsewhere.
>
> One start would be to add a sys/proc
On Mon, Nov 15, 2010 at 03:47:32PM -0500, der Mouse wrote:
> > [...] just forward declarations of the structs.
>
> > (this is, btw, one of the reasons to avoid silly typedefs)
>
> I'm not sure what typedefs have to do with it. typedeffing a name to
> an incomplete ("forward") struct type w
On Mon, Nov 15, 2010 at 05:40:05PM +0100, Johnny Billquist wrote:
> [...] but rwlocks can not be fixed without more work. :-(
I wouldn't be particularly surprised if replacing the current overbred
rwlock code with a simple implementation using a single mutex and
condvar made it go faster... or at
On Sat, Nov 20, 2010 at 05:08:25PM +0900, Masao Uebayashi wrote:
> Never mind. It protects some on-memory data which I don't know.
>
> (Why do I lock lots of things to read read-only ROM data? I wish
> VFS/BIO were written in Haskell...)
http://programatica.cs.pdx.edu/House/
--
David A. H
On Fri, Nov 19, 2010 at 12:33:00AM -0800, John Nemeth wrote:
> .prop is short for proplib or property list. It also made
> coding easier as s/.kmod/.prop/ doesn't change the length of the path.
> Anyways, I have received several private requests to change the name to
> .plist. After thin
On Sat, Nov 20, 2010 at 07:50:03PM -0800, John Nemeth wrote:
> } embed the property info in the module file itself?
>
> That may or may not make more sense, but it would require a lot
> more work (i.e. inventing a tool to extract them, edit them, and insert
> them; and modifying the modu
I have run into a problem fixing namei.
First, background: VOP_LOOKUP is the per-fs vnode operation that takes
a directory and a name and returns the vnode associated with that
name. This currently has a horrific interface and the chief goal of
the namei cleanup is to rectify this so all it needs
On Tue, Nov 23, 2010 at 11:13:02PM +, David Holland wrote:
> However, I discovered today that rumpfs's VOP_LOOKUP implementation
> relies on being able to access not just the name to be looked up, but
> also the rest of the pathname namei is working on, specifically
> in
On Wed, Nov 24, 2010 at 08:26:42AM -0500, der Mouse wrote:
> > (2) does anyone think that a correct namei design should provide a
> > correct canonicalized full pathname for its inspection during lookup?
>
> Not me.
>
> > (Note that this is free -- it would require splicing a getcwd into
>
On Wed, Nov 24, 2010 at 07:32:42PM +0200, Antti Kantee wrote:
> > Furthermore, it is just plain gross for the behavior of VOP_LOOKUP in
> > some directory to depend on how one got to that directory. As a matter
> > of design, the working path should not be available to VOP_LOOKUP and
> > VOP_LO
On Wed, Nov 24, 2010 at 06:19:50PM +, David Laight wrote:
> > First, background: VOP_LOOKUP is the per-fs vnode operation that takes
> > a directory and a name and returns the vnode associated with that
> > name. This currently has a horrific interface and the chief goal of
> > the namei cl
On Wed, Nov 24, 2010 at 01:26:04PM -0500, der Mouse wrote:
> > Right. But if you want a guaranteed absolute path you should be able
> > to do it by calling getcwd first.
>
> Only if you accept breakage if the current directory no longer has any
> name.
Well, if you can't call getcwd, then it
On Wed, Nov 24, 2010 at 08:30:18PM +0200, Antti Kantee wrote:
> > I think it makes more sense for doregister to check for at least one
> > leading '/' and remove the leading slashes before storing the key.
> > Then the key will match the name passed by lookup; otherwise the
> > leading slash wo
On Sun, Nov 28, 2010 at 05:53:59PM +0100, Manuel Bouyer wrote:
> our FFS quota system is pretty outdated and is less and less
> suitable for modern storage (quotacheck is long and can't be
> avoided). I'm thinking about coding a new quota system [...]
Unfortunately, before you can change the FF
On Sun, Nov 28, 2010 at 09:47:02PM +, David Holland wrote:
> (Also, why a radix tree? Radix trees are generally not very efficient.
> If you're going to, though, you might want to reuse the direct,
> indirect, double indirect, etc. method FFS uses for block mapping.)
...and t
On Mon, Nov 29, 2010 at 01:29:47AM +0700, Robert Elz wrote:
> If you're going to force the quota info to be in the filesystem itself,
> then you should probably consider splitting the two types of info that
> are stored there - there's the current usage info (etc) that can certainly
> be associ
On Sun, Nov 28, 2010 at 11:43:48PM +0100, Joerg Sonnenberger wrote:
> A radix tree is kind of a bad choice for this purpose. The easiest
> approach is most likely to have [a btree]
I would go with an expanding hash table of some kind, e.g. size is 2^n
pages, hash & (2^n - 1) tells you the page t
On Mon, Nov 29, 2010 at 11:12:21AM -0500, der Mouse wrote:
> Without any real data on what UID distribution looks like in practice,
> we're all speculating in a vacuum here.
Just for shits and giggles I ran this on a real password file with
about 350 users that's had lots of churn since it was f
On Tue, Dec 14, 2010 at 08:49:14PM -0800, Matt Thomas wrote:
> I have a fairly large but mostly simple patch which changes the
> stats collected in uvmexp for faults, intrs, softs, syscalls, and
> traps from 32 bit to 64 bits and puts them in cpu_data (in
> cpu_info). This makes more accurate
On Wed, Dec 22, 2010 at 12:41:23PM +, Michael van Elst wrote:
> [...]
> There are other places in the WAPBL code (and one in UFS1 dealing with
> extended attributes) that get vnodes during a mount operation. While
> I haven't seen crashes from this it is likely that such vnodes are
> never
Because we have at least one FS that may not want paths being looked
up to be split on '/', namely rump etfs, and arguably the most
important simplification to VOP_LOOKUP is to make it handle one path
component at a time, we need a way for a FS to decide how much of a
path it wants to digest at onc
Has anyone ever sat down and clearly worked out the desired semantics
for TRYEMULROOT? I've noted inconsistencies in the past, and because
in a number of ways it's a special case of onionfs I'm somewhat
concerned that there may be cases where the proper or desired behavior
is unclear or ambiguous.
On Sun, Jan 02, 2011 at 09:19:30AM -0500, matthew sporleder wrote:
> > [TRYEMULROOT]
>
> Since it's on http://www.netbsd.org/~dholland/buglists/file.html , I'm
> sure you're aware of it, but would 41678 be solved?
>
> http://gnats.NetBSD.org/cgi-bin/query-pr-single.pl?number=41678
Doubtful
On Sun, Jan 02, 2011 at 06:14:57PM +, David Laight wrote:
> On Sun, Jan 02, 2011 at 09:52:31AM +0000, David Holland wrote:
> > Has anyone ever sat down and clearly worked out the desired semantics
> > for TRYEMULROOT? I've noted inconsistencies in the past, and because
On Sun, Jan 02, 2011 at 10:48:03AM +, David Laight wrote:
> On Sun, Jan 02, 2011 at 09:17:11AM +0000, David Holland wrote:
> > Because we have at least one FS that may not want paths being looked
> > up to be split on '/', namely rump etfs, and arguabl
On Sun, Jan 02, 2011 at 09:19:51PM +, Eduardo Horvath wrote:
> TRYEMULROOT should only open existing objects on the emul path, it should
> never create anything new, so you would never want to use it for mkdir.
> I don't know if that means you need to pass an extra flag to
> namei_paren
On Tue, Jan 04, 2011 at 01:09:34PM +0100, Joerg Sonnenberger wrote:
> Hi all,
> while investigating ways to access the auxillary vector, I found that we
> currently don't deal correctly with struct ps_strings in 32bit compat.
> This structure is placed by the kernel into the initial stack and
On Mon, Jan 17, 2011 at 04:33:25PM +0100, Manuel Bouyer wrote:
> so I'm evaluating how to use proplib for the new quotactl(2) I'm working on.
er, why? When I was looking at quota stuff in the context of lfs and
other fs types, the existing quotactl interface seemed fine -- it just
needs to have a
On Tue, Jan 18, 2011 at 04:24:37PM +0100, Joerg Sonnenberger wrote:
> Well, we derive the version to include from the version file. This is
> controlled by a central script. What about adding support to expand
> $DATE$ or some other magic version string, if it is the last in the
> version file?
On Tue, Jan 18, 2011 at 09:39:58PM +0100, Joerg Sonnenberger wrote:
> > That's unnecessarily complicated. There's prior art for this:
> > [...]
>
> Please look at the mail that started this threat. newvers provides
> multiple independent variable, so conditionally providing one of them
> ne
PR 44496 notes that COMPAT_386BSD_MBRPART is still enabled in
disklabel(8), even though it was turned off by default in the kernel
early in 4.99.x. The PR also notes that it's not harmless to leave it
on.
I'm inclined to turn it off in disklabel(8) right now. There's no
particular reason to have i
On Mon, Jan 31, 2011 at 05:40:20PM +0100, Matthias Drochner wrote:
> > PR 44496 notes that COMPAT_386BSD_MBRPART is still enabled in
> > disklabel(8), even though it was turned off by default in the kernel
> > early in 4.99.x. The PR also notes that it's not harmless to leave it
> > on.
>
>
On Sat, Feb 05, 2011 at 10:07:13PM -0500, der Mouse wrote:
> Of course, still better would be to fix vnd, though I'm not sure what
> the right fix would be.
What's the problem? My vague understanding was that you could get into
deadlocks allocating blocks, but maybe I'm confusing it with someth
On Thu, Feb 03, 2011 at 08:04:26AM +, David Laight wrote:
> > > The PR rather leads to the conclusion that the support for
> > > old Partition IDs in disklabel(8) is suboptimal.
> > > Originally, the code did only consider a partition with the
> > > old ID if no new one was found. This appa
On Mon, Feb 07, 2011 at 01:48:57AM -0500, Thor Lancelot Simon wrote:
> For the record, I am pretty sure it was sysinst, not disklabel, which
> hosed my disk. Sysinst compiles equivalent code in directly, no?
There are only two uses of MBR_PTYPE_386BSD in src/distrib. One is a
perfectly innocuou
On Sun, Feb 13, 2011 at 01:06:36PM -0500, Thor Lancelot Simon wrote:
> Not in the failure case I observed (I can now reproduce this, but since
> it looks like the code in disklabel is going to Go,
It has Gone :-)
(The remaining question is whether to request pullup to -5; I think I
will unless
On Wed, Mar 02, 2011 at 12:40:44AM +, Andrew Doran wrote:
> With modules now basically working we should either retire or move
> some of these items to pkgsrc so that the interested parties maintain them.
> An awful lot of the compat stuff is now very compartmentalised, with not
> much more
On Sat, Feb 19, 2011 at 11:21:35PM +0100, Manuel Bouyer wrote:
> I think the code in the bouyer-quota2 branch is stable now, and
> ready to be merged to HEAD. Unless objections, I'll merge it in
> about 2 weeks.
> [...]
So, I thought one of the points of this was to make the quota
interface fs
On Mon, Mar 07, 2011 at 01:07:05PM +0100, Manuel Bouyer wrote:
> > So, I thought one of the points of this was to make the quota
> > interface fs-independent, but as it seems to have come out all the
> > pieces and definitions are still in sys/ufs/ufs, and so far at least I
> > really do not se
On Wed, Mar 09, 2011 at 08:20:00PM +0100, Manuel Bouyer wrote:
> On Wed, Mar 09, 2011 at 06:28:11PM +0000, David Holland wrote:
> > > struct quota2_entry (and so struct quota2_val) is used for both
> > > on-disk storage, and in-memory representation in tools and kernel.
On Sat, Mar 19, 2011 at 05:45:38PM +0100, Manuel Bouyer wrote:
> > Everywhere? If "quota2" is going to be the standard quota and the old one
> > is going to be deprecated, then it is better to call it "quota" and rename
> > the old one.
>
> At this point, in the source 'quota1' is used for th
On Sat, Mar 19, 2011 at 06:19:30PM +0100, Manuel Bouyer wrote:
> > > At this point, in the source 'quota1' is used for the old
> > > quota format, 'quota2' for the new one and 'quota' for the few things
> > > that are common.
> >
> > Everything outside the kernel should be in the last categor
On Mon, Mar 21, 2011 at 02:21:26PM +0100, Manuel Bouyer wrote:
> > (also, edquota and repquota seem fs-independent to me...)
>
> no, they're not: they can directly the quota1 file specified in the
> fstab if quotactl fails or the filesystem is not mounted.
That's a bug, or more accurately leg
On Tue, Mar 22, 2011 at 05:41:52PM +0100, Manuel Bouyer wrote:
> > | > > (also, edquota and repquota seem fs-independent to me...)
> > | >
> > | > no, they're not: they can directly the quota1 file specified in the
> > | > fstab if quotactl fails or the filesystem is not mounted.
> > |
> >
On Tue, Mar 22, 2011 at 03:21:22PM +0100, Manuel Bouyer wrote:
> > That's a bug, or more accurately legacy behavior that doesn't need to
> > be supported.
>
> of course it's not nice. But we're talking about existing code calling the
> legacy quotactl. If we're going to change it to not check
(more context restored)
On Wed, Mar 23, 2011 at 09:51:48AM +0100, Manuel Bouyer wrote:
>> (also, edquota and repquota seem fs-independent to me...)
>
> no, they're not: they can directly the quota1 file specified in the
> fstab if quotactl fails or the filesystem is not mounted
On Wed, Mar 23, 2011 at 09:50:16AM +0100, Manuel Bouyer wrote:
> On Wed, Mar 23, 2011 at 03:44:53AM +0000, David Holland wrote:
> > On Tue, Mar 22, 2011 at 05:41:52PM +0100, Manuel Bouyer wrote:
> > > > | > > (also, edquota and repquot
On Wed, Mar 23, 2011 at 02:18:55PM +, Mindaugas Rasiukevicius wrote:
> > > I would like to split-off parts of vfs_subr.c into vfs_node.c * and
> > > vfs_mount.c modules. Decomposing should hopefully bring some better
> > > abstraction, as well as make it easier to work with VFS subsystem.
On Wed, Mar 23, 2011 at 05:10:08PM +0100, Manuel Bouyer wrote:
> > > > No, it doesn't. Even before you touched anything, they were only
> > > > scribbling directly as a fallback if the kernel operations failed.
> > > > The kernel operations should not fail in any case where scribbling
> > > > d
On Wed, Mar 23, 2011 at 05:11:21PM +0100, Manuel Bouyer wrote:
(also, edquota and repquota seem fs-independent to me...)
>>>
>>> no, they're not: they can directly the quota1 file specified in the
>>> fstab if quotactl fails or the filesystem is not mounted.
>>
On Sat, Mar 19, 2011 at 02:07:50PM -0400, Christos Zoulas wrote:
> | At this point, in the source 'quota1' is used for the old
> | quota format, 'quota2' for the new one and 'quota' for the few things
> | that are common.
>
> Are we planning to keep quota1 around for more than 6.0? If not, it
On Fri, Mar 18, 2011 at 08:30:41PM +0100, Manuel Bouyer wrote:
> looking at pkgsrc/net/netatalk to make it use the new quota interface
> convinced be that we need a libquota, which can return the quota status
> for a id in a simple way, as independant as possible from the underlying
> filesyste
On Wed, Mar 23, 2011 at 10:07:42PM +, Mindaugas Rasiukevicius wrote:
> > > >
> > > > - I think it should be vfs_vnode.c?
> > >
> > > OK, unless somebody will come up with a better name.
> >
> > Since AIUI from chat this is going to contain the vnode lifecycle and
> > code and not e.g.
On Tue, Apr 19, 2011 at 01:36:36PM -0500, Frank Zerangue wrote:
> I am confused about what vnode operation vop_lookup_desc should
> return for two directory entries that refer to the same underling
> filesystem inode (i.e. hard links).
>
> // VNODE(9): There is a unique vnode allocated for ea
On Thu, Apr 28, 2011 at 12:02:51PM +0200, Edgar Fu? wrote:
> > Is there a saner way of reading non-standard (e.g., 10 sectors per track)
> > floppies than either
> > a) building a custom kernel with modified fd_types in sys/dev/isa/fd.c
> > b) writing a user-space program that sets the appropri
On Mon, May 02, 2011 at 03:23:48PM +0200, Manuel Bouyer wrote:
> > unfortunably I don't have a core dump (I couldn't get one).
>
> And unfortunably it's not reproductible with a simple testbed (I've been
> trying for 3 days).
> I wonder if it could be related to the INRENAME change that has
On Sat, May 07, 2011 at 09:28:23PM +0200, Emmanuel Dreyfus wrote:
> On NetBSD-5.1, when an FFS filesystem has extended attributes, any call
> to statfs(2) will never return from the kernel. ps -axl shows the
> process is sleeping at tstile.
>
> Is it a known problem, is there already a PR for
On Sun, May 08, 2011 at 01:36:53PM -0400, der Mouse wrote:
> That could be part of my confusion, then. Speaking strictly from a
> personal-experience historical perspective, FFS was the Berkeley "Fast
> File System", added no later than 4.2 (can't recall whether it was in
> 4.1c) and UFS was S
On Sun, May 08, 2011 at 10:45:15PM +0200, Martin Husemann wrote:
> For example this is from an i386 5.1 machine:
> [snip]
>
> This is a FFSv1 file system (called UFS1 in the dumpfs output), but the
> superblock is in FFSv2 format.
>
> Compare to this:
> [snip]
>
> Here we have a FFSv2
On Sun, May 15, 2011 at 06:13:48PM +0200, Joerg Sonnenberger wrote:
> > > How about adding fcntl(F_GETPEER) returning pid_t, then you can do
> > > kill(fcntl(fd, F_GETPEER))?
> >
> > There's still a race -- if your process sleeps between the fcntl
> > and the kill system calls, you can kill t
On Sat, Jun 04, 2011 at 01:09:19PM -0500, David Young wrote:
> Is there a good reason that we are not using and
> in the kernel, instead of and ? It seems
> to me that we could cut simplify by using the same headers for the same
> definitions everywhere.
We should, but the source tree orga
On Sat, Jun 04, 2011 at 02:27:59PM -0700, John Nemeth wrote:
> } > Is there a good reason that we are not using and
> } > in the kernel, instead of and ? It seems
> } > to me that we could cut simplify by using the same headers for the same
> } > definitions everywhere.
> }
> } We sh
On Sat, Jun 04, 2011 at 07:03:34PM -0700, John Nemeth wrote:
> } > The files in src/sys/sys get installed into /usr/include/sys .
> }
> } Yes, I'm aware of that. Your point being?
>
> Then what purpose would src/sys/include serve?
To hold header files? I think the point you're mi
On Mon, Jun 20, 2011 at 12:32:25PM -0700, Brian Buhrow wrote:
> I don't think this is a bug as it behaves this way on NetBS-3.x, 4.x and
> 5.x. Can anyone provide clue?
Check the group memberships of the processes?
--
David A. Holland
dholl...@netbsd.org
On Thu, Jun 16, 2011 at 07:49:43PM +0200, Manuel Bouyer wrote:
> > I'm not in favor of LOCKDEBUG by default, for reasons already stated here.
>
> Also, could LOCKDEBUG have ABI issues with modules ?
> I've only ever used LOCKDEBUG with non-MODULAR kernels ...
The whole reason LOCKDEBUG is aby
We got a new NFS server at work over the weekend, and it's been a bit
flaky and causing my machines to hang left and right. In the course of
poking about with ddb and crash I've found no less than three
problems:
(1) The syncer holds syncer_mutex while calling VOP_FSYNC. If
VOP_FSYNC goes off to p
On Wed, Jun 22, 2011 at 10:26:47PM +0200, Manuel Bouyer wrote:
> > Any idea on how to properly fix this ?
> > a workaround could be to use yield() in uvm_loan.c because it would not
> > require a clock tick to wake up.
> > I'm not sure if it's possible to drop the socket lock before unloaning t
On Thu, Jun 23, 2011 at 06:36:31AM -0700, Matt Thomas wrote:
> > That doesn't seem like it can really be right. There are plenty of
> > systems where devices cannot DMA from user addresses.
>
> Really? That seems unlikely.
It's not that devices can't DMA from user addresses; it's that the
On Fri, Jun 24, 2011 at 01:43:34AM +0200, Johnny Billquist wrote:
> >In other words, Erik is right, at least if we're talking historically.
> >Of course, at least there it's documented. (I took a quick glance
> >at the code, too -- it did appear to check for erroneous parameters,
> >though I t
On Fri, Jun 24, 2011 at 11:33:51AM -0400, der Mouse wrote:
> >> Oh, I was talking about current NetBSD where block devices are a
> >> second class citizen, soon to be abolished if someone finds enough
> >> round tuits.
> > Yes, so it keeps being said. It would truly be a pity to see that
> >
On Fri, Jun 24, 2011 at 12:11:22PM +0200, Manuel Bouyer wrote:
> > I've been thinking that the nfs client problems I've been seeing,
> > which seem to be callout-related, are maybe connected, as could be the
> > odd problem mrg has been having with raidframe.
> >
> > Do we have a debug hook o
On Fri, Jun 24, 2011 at 06:37:09PM +0100, David Laight wrote:
> > > > Do we have a debug hook or other method that will raise a panic if
> > > > callouts stop getting processed?
> > >
> > > unfortunably, no (AFAIK).
> >
> > without looking at the code (today) I'm wondering if it would be
>
On Sat, Jun 25, 2011 at 09:29:57PM +0700, Robert Elz wrote:
> | At least for NetBSD, that's never been true. The most glaring
> | problem is that there's no protection against causing the same
> | underlying disk blocks to be multiply cached by accessing the
> | buffer cache with a different s
On Sat, Jun 25, 2011 at 08:57:30PM +0200, Johnny Billquist wrote:
> I might be confused here. I thought that if you accessed the block
> device, you were restricted to blocks. So you can in fact not seek
> to an arbitrary byte, nor read an arbitrary length, like for a
> normal file, but instead
On Mon, Jun 27, 2011 at 02:00:54PM -0400, Paul Koning wrote:
> >> It took the invention of that paragon of OS's - DOS - to teach
> >> the populace that simply pulling the device/media was an acceptable
> >> operating procedure.
> >
> > That's hardly fair. Until the Mac appeared in 1984 every
On Sun, Jun 26, 2011 at 04:48:22AM +0200, Emmanuel Dreyfus wrote:
> I implemented extattr_list_file for UFS1. The thing works fine, but I
> notice the data expected by lsextattr(8) is not in the same shape as
> described in NetBSD documentation and in FUSE and Linux.
I'll throw a spanner in the
On Wed, Jun 29, 2011 at 09:31:33AM +, Emmanuel Dreyfus wrote:
> The conversion is easy to do, but the right place to do it is
> tricky. VOP_LISTEXTATTR() writes its output to the userland
> buffer, therefore if I convert in src/sys/ufs/ufs/ufs_extattr.c, I
> have to copyin/convert/copyout,
On Fri, Jul 01, 2011 at 01:10:06AM +, YAMAMOTO Takashi wrote:
> hi,
>
> > That said, even if you don't like the suggestion of using struct
> > dirent, ISTM that the preferred user API for listing extended
> > attributes should be something more like opendir/readdir.
>
> do you know any
New patch for wapbl_ufs_rename:
http://www.eecs.harvard.edu/~dholland/tmp/netbsd/rename-candidate.diff
this is smaller and less directly intrusive than the old patch set,
but it has the same problem:
ufs_direnter: reached 4.2-only block, not supposed to happen
panic: kernel diagnostic asserti
On Thu, Jul 14, 2011 at 09:01:00AM +, David Holland wrote:
> New patch for wapbl_ufs_rename:
>
>http://www.eecs.harvard.edu/~dholland/tmp/netbsd/rename-candidate.diff
>
> this is smaller and less directly intrusive than the old patch set,
> but it ha
On Fri, Jul 15, 2011 at 10:43:31PM +, David Holland wrote:
> I will commit it later after an anita run if I don't find any more
> problems.
I did find one more problem... hopefully no more than that.
> Note that when pounding on rename I am occasionally seeing:
On Sat, Jul 16, 2011 at 08:04:15AM +, David Holland wrote:
> This seems to be connected to rmdir, not rename. The panic has (so
> far) always occurred in a process doing only rmdirs and no renames.
>
> I've spotted two problems in ufs_rmdir but neither of them could be
&
On Mon, Jul 18, 2011 at 09:37:33AM -0400, Thor Lancelot Simon wrote:
> On Mon, Jul 18, 2011 at 08:00:18AM +0000, David Holland wrote:
> >
> > Other fses with their own rename implementations whose locking is
> > clearly wrong include tmpfs, ms
101 - 200 of 951 matches
Mail list logo
