y to reproduce them was to try to
build "pkgsrc/lang/perl5".
After rebuilding and installing "libc" and "libpthread" from today's
NetBSD-current sources Perl works fine again.
Kind regards
--
Matthias Scheler https://zhadum.org.uk/
Module Name:src
Committed By: tron
Date: Sun Jul 30 09:09:38 UTC 2023
Modified Files:
src/etc: services
Log Message:
Resolve the port 2049 conflict by commenting out the entries for "shilp".
Now "netstat" will produce sensible output for NFS connections again.
To generat
Module Name:src
Committed By: tron
Date: Sun Jul 30 09:09:38 UTC 2023
Modified Files:
src/etc: services
Log Message:
Resolve the port 2049 conflict by commenting out the entries for "shilp".
Now "netstat" will produce sensible output for NFS connections again.
To generat
spected that this function is also used on UDP sockets where
listen(2) will of course fail.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
On Wed, May 28, 2014 at 02:12:40PM +0100, Matthias Scheler wrote:
> On Wed, May 28, 2014 at 09:09:40AM +, Matthew Green wrote:
> > Module Name:src
> > Committed By: mrg
> > Date: Wed May 28 09:09:39 UTC 2014
> >
> > Modified Files:
r.amd64 -o grodvi dvi.o
-Wl,-rpath-link,/export/scratch/tron/obj/destdir.amd64/lib -L=/lib
/export/scratch/tron/obj/gnu/usr.bin/groff/src/libs/libdriver/libdriver.a
/export/scratch/tron/obj/gnu/usr.bin/groff/src/libs/libgroff/libgroff.a -lm
*** Error code 1
Stop.
Kind regards
--
Matthi
onable
code which breaks because of the limit enforcing of fortification.
But I couldn't find it yesterday and I really wanted to have "emacs"
on my NetBSD-current machine.
Kind regards
--
Matthias Scheler https://zhadum.org.uk/
On Mon, Mar 24, 2014 at 11:20:04PM +, Christos Zoulas wrote:
> In article <20140324230302.1ad1...@cvs.netbsd.org>,
> Matthias Scheler wrote:
> >Module Name: src
> >Committed By:tron
> >Date:Mon Mar 24 23:03:02 UTC 2014
> >
> &
during a build
> with MKDTRACE=yes.
That fixes the build for me.
Thanks a lot
--
Matthias Scheler http://zhadum.org.uk/
On Sun, Mar 04, 2012 at 04:12:25PM +, Matthias Scheler wrote:
> Module Name: src
> Committed By: tron
> Date: Sun Mar 4 16:12:25 UTC 2012
>
> Modified Files:
> src/distrib/sets/lists/man: mi
> src/external/ibm-public/postfix: Makefile.inc
>
On Sat, Feb 11, 2012 at 10:40:03PM +0200, Alan Barrett wrote:
> On Sat, 11 Feb 2012, Matthias Scheler wrote:
> >Log Message:
> >Initial import of "expat" 2.0.1 into base:
> >This is James Clark's expat XML parser library in C. It is a stream
> >oriente
On Sat, Feb 11, 2012 at 10:13:19PM +0200, Alan Barrett wrote:
> On Sat, 11 Feb 2012, Matthias Scheler wrote:
> >Log Message:
> >Initial import of "expat" 2.0.1 into base:
>
> Was this approved by releng?
Yes, it was. Sorry, I forgot to mention that.
Kin
ot;src/sys"? It is not a UFS derivative, is it?
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
On Mon, Nov 07, 2011 at 06:51:58AM +0200, Jukka Ruohonen wrote:
> On Sun, Nov 06, 2011 at 10:34:48PM +0000, Matthias Scheler wrote:
> > Module Name:src
> > Committed By: tron
> > Date: Sun Nov 6 22:34:48 UTC 2011
> >
> > Modified
way of a major
other feature it should be left alone.
The best solution would of course to replace it with a driver for
the new framework. But that might be a lot of work for hardware
which might become obsolete in the near future.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
On Tue, Aug 30, 2011 at 03:42:18PM +0200, Martin Husemann wrote:
> On Tue, Aug 30, 2011 at 01:31:50PM +0100, Matthias Scheler wrote:
> > It is supported by "pkgsrc/multimedia/fxtv" which the last time I had
> > an analog TV feed worked well enough to watch TV.
>
>
4) infrastructure.
>
> XXX: This driver should be converted (or even bluntly removed, given the
> lack of general third-party software support).
It is supported by "pkgsrc/multimedia/fxtv" which the last time I had
an analog TV feed worked well enough to watch T
martin discovered that this one works:
>
>const char fmt[] = "...";
Which is the better choice anyway as it saves 4 or 8 bytes of static data.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
rations.
Thanks a lot.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
her than only on i386.
Yes, that was the intention. Sorry about the mistake.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
wmany(), we can use it
> here too, can't we?
Indeed, we can and we should.
Thanks a lot
--
Matthias Scheler http://zhadum.org.uk/
th and without real locking, with and without "libpthread" present.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
that one binary is linked with "libpthread" and the other one isn't.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
are single-core.
It fails for me on a virtual machine with four (virtual) cores as well.
And yes, that VM can really use four cores.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
bsd/bugs/build/build/2011.05.29.12.57.14/test.html#syscall_t_pselect_pselect_signal_mask_with_signal
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
On Sun, May 29, 2011 at 02:57:14PM +0100, Julio M. Merino Vidal wrote:
> On 5/29/11 1:57 PM, Matthias Scheler wrote:
> >Modified Files:
> > src/tests/syscall: t_pollts.c
> >
> >Log Message:
> >[...]
> >Also use ATF_REQUIRE_EQ_MSG() instead of ATF_REQUIRE_
On Sat, May 28, 2011 at 11:42:37PM +0100, Julio M. Merino Vidal wrote:
> On 5/28/11 10:46 PM, Christos Zoulas wrote:
> >In article<20110528161256.ab89817...@cvs.netbsd.org>,
> >Matthias Scheler wrote:
> >>+ assert(pipe(fds) == 0);
> >[...]
>
ests don't pass on my setup:
t_pselect (17/21): 2 test cases
pselect_signal_mask_with_signal: Failed: pselect() did not receive signal
pselect_signal_mask_with_timeout: Failed: pselect() did not receive signal
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
On Sun, Apr 17, 2011 at 07:04:05PM +0100, Matthias Scheler wrote:
> You have now broken the "tools" build again:
>
> ===> build.sh command:./build.sh -O /export/scratch/tron/obj -u -U -x
> tools
[...]
Some testing revealed that this only happens if you "MKDTRA
eal}" &&
/src/tools/bin/nbmake _THISDIR_="${this}" "$@" ${target}; }; _makedirtarget
libelf dependall
*** Error code 1
Stop.
nbmake: stopped in /src/NetBSD-current/src/tools
ERROR: Failed to make dependall in "tools"
*** BUILD ABORTED ***
Can you please fix that?
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
is problem. what failed for you?
"./build -O /path/to/obj -u -U -j 8 -x distribution sets" under
NetBSD/i386 5.99.49
> are you sure it was a completely clean build?
Yes, tool and object directory were empty.
> we should fix nbhost-mkdep if it is broken, and revert
.
2.) Run them with "MALLOC_OPTIONS" set to "AJ".
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
n anyone else's env)
Is he perhaps using "USE_SSP=yes"?
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
\"dovecot\"
+.endif
+
.if defined(HAVE_PCC)
# code uses gcc-specific aggregate dynamic array
CPPFLAGS+= -DCANT_USE_SEND_RECV_MSG
> And yes there is less reason to use cyrus right now, which is what
> the libsaslc project is all about.
I agree.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
to USE_LIB_SASL that can be set to saslc or cyrus
Do we really want to support "USE_LIB_SASL=cyrus"? Linking stuff in
base again libraries from "pkgsrc" sounds like a big hack to me and
will e.g. break cross compiling.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
rely
> on modules that could be absent or non accessible at boot time.
I don't think it needs typical file-systems. IMHO the kernel should
contain the file-systems required for booting. This will solve most
of the update issues.
Kind regards
--
Matthias Scheler
"/bin" and "/usr/bin".
Please consider using "SYMLINKS" for the compatibility links.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
axf.c n_fmin.c n_fminf.c
>
> Log Message:
> Imlementations of fmax, fmaxf, fmin and fminf libm functions for VAX.
Thank you.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
On Sun, Jan 09, 2011 at 02:47:27AM +, David Holland wrote:
> On Sat, Jan 08, 2011 at 11:49:54PM +0000, Matthias Scheler wrote:
> > > This is no longer true, for lvm and other things, so let's take a deep
> > > breath and move chown.
> >
> > Yes, bu
ns.
> I don't like the idea of having rc.d scripts depend on /rescue.
Me neither.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
e with existing MAX() macro.
Why not? It doesn't sound hard to do that based on the manual page.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
ultiple
gigabytes of storage space.
"/usr" over NFS is useful for a system with a shortage of local disk space.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
cause
it now depends on "/usr/lib/librumpclient.so.0".
Utilities in "/bin" and "/sbin" are supposed to work without
"/usr" mounted.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
On Tue, Oct 26, 2010 at 05:05:28AM +1100, matthew green wrote:
>
> > On Mon, Oct 25, 2010 at 08:52:43AM +0100, Matthias Scheler wrote:
> > > On Sun, Oct 24, 2010 at 10:56:40PM +, David Holland wrote:
> > > > Anyway, ISTM that writing from the mmap buffer in say 6
On Mon, Oct 25, 2010 at 08:52:43AM +0100, Matthias Scheler wrote:
> On Sun, Oct 24, 2010 at 10:56:40PM +, David Holland wrote:
> > Anyway, ISTM that writing from the mmap buffer in say 64K chunks would
> > retain nearly all the advantages and get rid of the latency problem.
&
impact
performance on some ports.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
On Mon, Oct 25, 2010 at 12:24:14AM +0700, Robert Elz wrote:
> Date:Sun, 24 Oct 2010 16:00:46 +0100
> From: Matthias Scheler
> Message-ID: <20101024150046.ga...@colwyn.zhadum.org.uk>
>
> | It doesn't have to be a macro anyway as it used on
On Sun, Oct 24, 2010 at 09:55:21AM +0700, Robert Elz wrote:
> Date:Sat, 23 Oct 2010 16:33:37 +0100
> From: Matthias Scheler
> Message-ID: <20101023153336.ga...@colwyn.zhadum.org.uk>
>
> | I'm sorry but this whole code is horrible.
&
It works fine under NetBSD/i386 and builts fine for NetBSD/amd64.
And I would hope that the compiler is clever anough to optimize
the code away on 64bit platforms.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
nv/getenv functions will write to it.
Which is the case for our "libc" after my change.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
er an upgrade to NetBSD 6.0.
> ... because while it fixes the common case, it might break programs
> that use both putenv and setenv (hopefully none).
It shouldn't. I've tried to take care of that with the second half
of the change. setenv(3) will not try to write to an
tore that behaviour. I'm not sure whether
it is good idea to document that we tolerate it.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
, has already done the same ...
So it assumes that it gets back from getenv(3) exactly what it passed
into putenv(3). Well, it seesm our putenv(3) needs a rewrite.
I think that setenv(3) and unsetenv(3) are correct as they are.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
ithout a corresponding unsetenv in between (just like
> malloc()/free() behaviour).
Is there any standard which backs this statement?
> Otherwise, if i understand things
> correctly, it's more putenv that shoud work that way.
Our putenv(3) is implemented via setenv(3).
On 11 Sep 2010, at 23:44, Christos Zoulas wrote:
> In article <5217ce1f-57c2-40bc-9281-50f90bba0...@zhadum.org.uk>,
> Matthias Scheler wrote:
>>
>> On 6 Sep 2010, at 23:35, Christos Zoulas wrote:
>>> Should we make perror() produce a warning so people will s
On 6 Sep 2010, at 23:35, Christos Zoulas wrote:
> Should we make perror() produce a warning so people will stop using it?
No, as it is not a NetBSD specific API.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
means that you have to be prepared to deal with the occassional failure
> of this nature when doing update builds anyways.
I'm aware of this case. But in this case there is a good reason. And I'm
less concerned about the destdir anyway. I'm concerned about obsolete
manual pages remaining on a system.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
ed
way how to handle renaming files. If people use it The Right Thing(TM)
happens.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
be linked with -lperfuse.
Can you please explain what is the difference between "libperfuse" and
"librefuse" is?
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
able and for every
> entry it calls particular sync routine which propagates DIOCCACHESYNC
> to real disk.
What happens if a logical volume consists of two slice of one physical
device? Will the physical device get flushed twice?
Kind regards
--
Matthias Scheler
fail and return -1.
> Note that in such cases the NetBSD implementation does not set errno to
> EBADF, hence diverging from the standard in this small detail.
Is there any reason not to make in compliant? It seems like a
reasonable change.
Kind regards
--
Matthias Schel
You only need to disable the warnings which would tell
you that the *particular* function which uses alloca(3) cannot be
protected. Please look at the end of "src/sys/conf/Makefile.inc"
how to handle this and update your change accordingly.
Kind re
gt; > 2.) Include "x86/include/cpu_counter.h" for amd64 and i386 to get the
> > prototype of "cpu_frequency".
>
> Probably this should be rewritten to use MI timecounter(9)?
Well, it seems to be an architecture specific file anyway. But I don't
know the de
Could you move this to bsd.own.mk, where all the dirty work is done now?
I specifically decided not to do that because this flag is not necessary
outside of set lists. make(1) can combine two conditions with or just fine.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
Module Name:src
Committed By: tron
Date: Wed Mar 3 16:13:42 UTC 2010
Modified Files:
src/distrib/sets: mkvars.mk sets.subr
src/distrib/sets/lists/modules: mi
Log Message:
"dtrace,zfs" means "MKDTRACE=yes" *and* "MKZFS=yes" which is not what
we want. Invent a flag
Module Name:src
Committed By: tron
Date: Wed Mar 3 16:13:42 UTC 2010
Modified Files:
src/distrib/sets: mkvars.mk sets.subr
src/distrib/sets/lists/modules: mi
Log Message:
"dtrace,zfs" means "MKDTRACE=yes" *and* "MKZFS=yes" which is not what
we want. Invent a flag
Module Name:src
Committed By: tron
Date: Wed Mar 3 14:43:41 UTC 2010
Modified Files:
src/distrib/sets/lists/modules: mi
Log Message:
The directory "modules/solaris" depends on ZFS as well.
To generate a diff of this commit:
cvs rdiff -u -r1.9 -r1.10 src/distrib/sets/lis
Module Name:src
Committed By: tron
Date: Wed Mar 3 14:43:41 UTC 2010
Modified Files:
src/distrib/sets/lists/modules: mi
Log Message:
The directory "modules/solaris" depends on ZFS as well.
To generate a diff of this commit:
cvs rdiff -u -r1.9 -r1.10 src/distrib/sets/lis
Module Name:src
Committed By: tron
Date: Wed Mar 3 14:32:29 UTC 2010
Modified Files:
src/distrib/sets/lists/modules: mi
Log Message:
The "solaris" kernel module also gets build if ZFS is enabled.
To generate a diff of this commit:
cvs rdiff -u -r1.8 -r1.9 src/distrib/se
Module Name:src
Committed By: tron
Date: Wed Mar 3 14:32:29 UTC 2010
Modified Files:
src/distrib/sets/lists/modules: mi
Log Message:
The "solaris" kernel module also gets build if ZFS is enabled.
To generate a diff of this commit:
cvs rdiff -u -r1.8 -r1.9 src/distrib/se
Module Name:src
Committed By: tron
Date: Wed Feb 24 15:40:54 UTC 2010
Modified Files:
src/external/cddl/osnet/lib/libdtrace: Makefile
Log Message:
Disable stack protection warnings for more sources which use dynamically
sized stack buffers.
To generate a diff of this com
Module Name:src
Committed By: tron
Date: Wed Feb 24 12:51:06 UTC 2010
Modified Files:
src/external/cddl/osnet/lib/libdtrace: Makefile
Log Message:
Disable stack protection warnings for sources which use dynamically
sized stack buffers.
To generate a diff of this commit:
Module Name:src
Committed By: tron
Date: Wed Feb 24 12:18:37 UTC 2010
Modified Files:
src/external/cddl/osnet/lib: Makefile
Log Message:
Include "bsd.own.mk" before checking "MKDTRACE" to allow setting it
in "/etc/mk.conf".
To generate a diff of this commit:
cvs rdiff -u
Module Name:src
Committed By: tron
Date: Wed Feb 24 11:56:35 UTC 2010
Modified Files:
src/external/cddl/osnet/usr.sbin/zdb: Makefile
Log Message:
Disable stack protection warnings for "zdb_il.c" which uses a dynamically
sized array on the stack.
To generate a diff of thi
Module Name:src
Committed By: tron
Date: Wed Feb 24 10:18:19 UTC 2010
Modified Files:
src/sys/sys: dtrace_bsd.h
Log Message:
Fix build of the "dtrace" kernel module.
To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/sys/sys/dtrace_bsd.h
Please note that di
Module Name:src
Committed By: tron
Date: Mon Feb 22 12:21:27 UTC 2010
Modified Files:
src/external/cddl/osnet/usr.sbin/dtrace: Makefile
Log Message:
Disable stack protection warnings for "dtrace.c" which uses alloca(3).
To generate a diff of this commit:
cvs rdiff -u -r1
Module Name:src
Committed By: tron
Date: Mon Feb 22 12:21:27 UTC 2010
Modified Files:
src/external/cddl/osnet/usr.sbin/dtrace: Makefile
Log Message:
Disable stack protection warnings for "dtrace.c" which uses alloca(3).
To generate a diff of this commit:
cvs rdiff -u -r1
Module Name:src
Committed By: tron
Date: Fri Feb 19 11:15:23 UTC 2010
Modified Files:
src/usr.bin/wc: wc.c
Log Message:
Report the number of characters, not the number of bytes in the
longest line.
Problem pointed out by YAMAMOTO Takashi on "tech-userlevel" mailing list.
Module Name:src
Committed By: tron
Date: Thu Feb 18 10:43:50 UTC 2010
Modified Files:
src/usr.bin/wc: wc.1 wc.c
Log Message:
Add support for "-L" option (longest line) as present in the GNU and
FreeBSD version of "wc".
No objections on "tech-userlevel" mailing list.
To
Module Name:src
Committed By: tron
Date: Thu Feb 4 13:22:34 UTC 2010
Modified Files:
src/external/mit/xorg/bin/xterm: Makefile
Log Message:
Define "HAVE_TERMCAP_H" to fix build with the new terminfo library.
To generate a diff of this commit:
cvs rdiff -u -r1.5 -r1.6 sr
Module Name:src
Committed By: tron
Date: Tue Feb 2 09:04:14 UTC 2010
Modified Files:
src/sys/ddb: db_user.h db_write_cmd.c
Log Message:
Include "ctype.h" in the central place which deals with building the
kernel debugger as a userland program.
To generate a diff of this
Module Name:src
Committed By: tron
Date: Mon Feb 1 09:56:58 UTC 2010
Modified Files:
src/sys/ddb: db_write_cmd.c
Log Message:
Include "ctype.h" if we are not building a kernel to fix the build
of crash(8).
To generate a diff of this commit:
cvs rdiff -u -r1.24 -r1.25 sr
Module Name:xsrc
Committed By: tron
Date: Wed Jan 27 13:46:39 UTC 2010
Modified Files:
xsrc/xfree/xc/config/pswrap: lexer.l
Log Message:
Remove EMX compatibility hack which breaks NetBSD/alpha cross-builds,
at least under Mac OS X.
To generate a diff of this commit:
cvs
Module Name:xsrc
Committed By: tron
Date: Wed Jan 27 13:47:28 UTC 2010
Modified Files:
xsrc/xfree/xc/extras/expat/lib: xmlparse.c
Log Message:
Add patch from upstream CVS to fix CVE-2009-3560 (possible DOS due to
crash on bad input).
To generate a diff of this commit:
cv
Module Name:xsrc
Committed By: tron
Date: Wed Jan 27 13:17:47 UTC 2010
Modified Files:
xsrc/external/mit/expat/dist/lib: xmlparse.c
Log Message:
Add patch from upstream CVS to fix CVE-2009-3560 (possible DOS due to
crash on bad input).
To generate a diff of this commit:
Module Name:src
Committed By: tron
Date: Mon Jan 11 12:10:19 UTC 2010
Modified Files:
src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_replay.c
zfs_znode.c
Log Message:
Replace VATTR_NULL() with vattr_null(). The ZFS module can be loaded
again now.
To gene
;GENERIC", etc.?
It should probably be added to all kernel configuration which
use "pseudo-device raid".
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
On Tue, Dec 08, 2009 at 09:12:26AM +0900, Masao Uebayashi wrote:
> I wonder why we don't have ${TOOL_SH}.
Because making our shell portable will probably be much harder
than occasionally fixing some shell scripts.
Kind regards
--
Matthias Scheler
each% nbmake-shark -V MKZFS MKZFS=yes
> yes
Yes, indeed. But this will only work if "sets.subr" actually
checks for this variable, won't it?
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
On Fri, Dec 04, 2009 at 12:57:55AM +0900, Masao Uebayashi wrote:
> > I'm sorry but I don't think this is a good solution.
>
> What is your better solution?
I can see why "_MKVARS" would be nice. But why do we need "_MKVARS.yes"
and "_MKVARS.n
On Fri, Nov 27, 2009 at 03:39:51PM +0100, Manuel Bouyer wrote:
> On Fri, Nov 27, 2009 at 10:30:32AM +0000, Matthias Scheler wrote:
> > If I understood the Isilon presentation during EuroBSDCon 2009 correctly
> > FreeBSD 8.0 has an in-kernel lockd. Porting their code might be
&
s an in-kernel lockd. Porting their code might be
an option to achieve that.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
On Thu, Nov 12, 2009 at 07:19:55AM +, Mindaugas Rasiukevicius wrote:
> * 5% performance hit on build.sh is not really a small number to me.
I've disabled SSP again, the performance hit is gone.
We can therefore stop this fruitless discussion.
Kind regards
--
Matthias
anyway..
Yes, but the question is whether the attack can panic the kernel (bad)
or gain root access to your system (very, very bad).
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
TIC option?
Because it is also a security feature. I can e.g. turn a remote root
exploit into a DoS which will at least keep your data safe.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
by enforcing and allocating always the
> maximum.
The change isn't completely correct. The code will later use
"sizeof(sink)" and "sizeof(blkno_buf)" which is no the maximum and
not the actual buffer size.
You probably need to replace all those occurrences of "
The maximum value at the moment is 128 bytes which will result
in a total of 384 bytes of buffers allocated on the stack.
There is therefore no risk of stack overflows.
2.) I have backed out my changes to fix the LOCKDEBUG kernel panics.
Thanks a lot for pointing out the problem.
On Tue, Nov 10, 2009 at 03:29:29PM +0100, Adam Hamsik wrote:
> On Tue, Nov 10, 2009 at 2:35 PM, Matthias Scheler wrote:
> > On Tue, Nov 10, 2009 at 08:48:42AM +, Matthias Scheler wrote:
> >> > A LOCKDEBUG kernel will panic. How can we avoid the stack
> >> >
On Tue, Nov 10, 2009 at 08:48:42AM +, Matthias Scheler wrote:
> > A LOCKDEBUG kernel will panic. How can we avoid the stack
> > overflows and such in a different way?
>
> I'll try to rewrite the code to use M_NOWAIT.
The attached diff changes the code to use M_NOWA
in a different way?
I'll try to rewrite the code to use M_NOWAIT.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
1 - 100 of 118 matches
Mail list logo
