On Wed, Oct 02, 2019 at 11:36:55PM -0400, Theodore Y. Ts'o wrote:
> On Wed, Oct 02, 2019 at 06:55:33PM +0200, Kurt Roeckx wrote:
> >
> > But it seems people are now thinking about breaking getrandom() too,
> > to let it return data when it's not initialized by defa
Hi,
As OpenSSL, we want cryptograhic secure random numbers. Before
getrandom(), Linux never provided a good API for that, both
/dev/random and /dev/urandom have problems. getrandom() fixed
that, so we switched to it were available.
It was possible to combine /dev/random and /dev/urandom, and get
On Thu, Jun 21, 2001 at 12:18:12PM +0100, Jonathan Morton wrote:
> I've been taught by every Maths, Engineering and Physics
> teacher/lecturer I've encountered to write down significant figures
> consistent with the precision of the value. So blindly writing down
> a value of 59.42886726469
On Thu, Jun 21, 2001 at 12:18:12PM +0100, Jonathan Morton wrote:
I've been taught by every Maths, Engineering and Physics
teacher/lecturer I've encountered to write down significant figures
consistent with the precision of the value. So blindly writing down
a value of 59.42886726469 ±2°C
On Wed, Jun 06, 2001 at 10:57:57AM +0100, Dr S.M. Huen wrote:
> On Wed, 6 Jun 2001, Sean Hunter wrote:
>
> >
> > For large memory boxes, this is ridiculous. Should I have 8GB of swap?
> >
>
> Do I understand you correctly?
> ECC grade SDRAM for your 8GB server costs £335 per GB as 512MB
On Wed, Jun 06, 2001 at 10:57:57AM +0100, Dr S.M. Huen wrote:
On Wed, 6 Jun 2001, Sean Hunter wrote:
For large memory boxes, this is ridiculous. Should I have 8GB of swap?
Do I understand you correctly?
ECC grade SDRAM for your 8GB server costs £335 per GB as 512MB sticks even
at
On Thu, May 31, 2001 at 04:01:34PM -0700, Dawson Engler wrote:
> Is there an easy way to tell which routines must be re-entrant?
> (it doesn't have to be exhaustive, even an incomplete set is useful)
>
> I was going to write a checker to make sure supposedly re-entrant
> routines actually were,
On Thu, May 31, 2001 at 04:01:34PM -0700, Dawson Engler wrote:
Is there an easy way to tell which routines must be re-entrant?
(it doesn't have to be exhaustive, even an incomplete set is useful)
I was going to write a checker to make sure supposedly re-entrant
routines actually were, but
On Tue, May 29, 2001 at 01:30:30AM +0200, Kurt Roeckx wrote:
> You should never "return" from userspace to kernelspace. The
> only way to go from user space to kernel space should be by using
> a system call.
If you were able to return to kernel space, it already means
you'r
On Tue, May 29, 2001 at 12:30:03AM +0200, Vadim Lebedev wrote:
> Kurt,
>
> Maybe i'm missing something but it seems that during execution of the signal
> handler, user mode stack contains kernel mode context...
> Hence the security hole
It's rather complicated how things work.
Both the user
On Mon, May 28, 2001 at 11:43:38PM +0200, Vadim Lebedev wrote:
> Hi folks,
>
> Please correct me if i'm wrong but it seems to me that i've stumbled on
> really BIG security hole in the signal handling code.
> The problem IMO is that the signal handling code stores a processor context
> on the
On Mon, May 28, 2001 at 11:43:38PM +0200, Vadim Lebedev wrote:
Hi folks,
Please correct me if i'm wrong but it seems to me that i've stumbled on
really BIG security hole in the signal handling code.
The problem IMO is that the signal handling code stores a processor context
on the
On Tue, May 29, 2001 at 12:30:03AM +0200, Vadim Lebedev wrote:
Kurt,
Maybe i'm missing something but it seems that during execution of the signal
handler, user mode stack contains kernel mode context...
Hence the security hole
It's rather complicated how things work.
Both the user and
On Tue, May 29, 2001 at 01:30:30AM +0200, Kurt Roeckx wrote:
You should never return from userspace to kernelspace. The
only way to go from user space to kernel space should be by using
a system call.
If you were able to return to kernel space, it already means
you're running as kernel
On Fri, May 18, 2001 at 09:02:51PM +0100, Alan Cox wrote:
> > What I'm seeing however in an other program is that select says I
> > can read from the socket, and that read returns 0, with errno set
> > to EGAIN. I call select() again, with returns and says I can read
>
> No no no. If the read
On Thu, May 17, 2001 at 11:57:45PM +0100, Chris Evans wrote:
>
> Hi,
>
> I wonder if the following is a bug? It certainly differs from FreeBSD 4.2
> behaviour, which gives the behaviour I would expect.
>
> The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
> Since the
On Thu, May 17, 2001 at 11:57:45PM +0100, Chris Evans wrote:
Hi,
I wonder if the following is a bug? It certainly differs from FreeBSD 4.2
behaviour, which gives the behaviour I would expect.
The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
Since the other end
On Fri, May 18, 2001 at 09:02:51PM +0100, Alan Cox wrote:
What I'm seeing however in an other program is that select says I
can read from the socket, and that read returns 0, with errno set
to EGAIN. I call select() again, with returns and says I can read
No no no. If the read does not
On Sat, May 05, 2001 at 06:26:30PM +0200, Rogier Wolff wrote:
>
> As all this is trying to avoid bus turnarounds (i.e. switching from
> reading to writing), wouldn't it be fastest to just trust that the CPU
> has at least 4k worth of cache? (and hope for the best that we don't
> get interrupted
On Sat, May 05, 2001 at 06:26:30PM +0200, Rogier Wolff wrote:
As all this is trying to avoid bus turnarounds (i.e. switching from
reading to writing), wouldn't it be fastest to just trust that the CPU
has at least 4k worth of cache? (and hope for the best that we don't
get interrupted in
On Sat, Apr 14, 2001 at 04:42:54PM +0200, Kurt Roeckx wrote:
> While running 2.4.3, I saw the following message a few times:
>
> KERNEL: assertion (tp->lost_out == 0) failed at
> tcp_input.c(1202):tcp_remove_reno_sacks
I've been running tcpdump for some time, and get the messag
On Sat, Apr 14, 2001 at 04:42:54PM +0200, Kurt Roeckx wrote:
While running 2.4.3, I saw the following message a few times:
KERNEL: assertion (tp-lost_out == 0) failed at
tcp_input.c(1202):tcp_remove_reno_sacks
I've been running tcpdump for some time, and get the message 2
times again today
On Mon, Apr 16, 2001 at 01:30:14PM +0100, Alan Cox wrote:
>
> 2. 'My athlon box is fine until I am swapping' {and using DMA}
>
> Compiler independant, CPU version independant. All victims have a VIA chipset.
> This one may be linked to the reported problems with VIA PCI. Two of the
>
On Sat, Apr 14, 2001 at 04:42:54PM +0200, Kurt Roeckx wrote:
> While running 2.4.3, I saw the following message a few times:
>
> KERNEL: assertion (tp->lost_out == 0) failed at
> tcp_input.c(1202):tcp_remove_reno_sacks
Nobody seems to be intrested in fixing this bug?
Anyway
On Sat, Apr 14, 2001 at 04:42:54PM +0200, Kurt Roeckx wrote:
While running 2.4.3, I saw the following message a few times:
KERNEL: assertion (tp-lost_out == 0) failed at
tcp_input.c(1202):tcp_remove_reno_sacks
Nobody seems to be intrested in fixing this bug?
Anyway, I was looking at some
On Sat, Apr 14, 2001 at 04:12:09PM +0100, Alan Cox wrote:
> Can the folks who are seeing crashes running athlon optimised kernels all mail
> me
Just trying to privide you with usefull info. I'm NOT seeing any
crashes at all.
> - CPU model/stepping
processor : 0
vendor_id :
While running 2.4.3, I saw the following message a few times:
KERNEL: assertion (tp->lost_out == 0) failed at
tcp_input.c(1202):tcp_remove_reno_sacks
Is that bad, or should I just ignore it?
Kurt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Sat, Apr 14, 2001 at 11:38:06AM +0200, Andreas Peter wrote:
> Am Samstag, 14. April 2001 09:04 schrieb David Rees:
>
> > OK, so it's not the RAID setup. There's two things that can cause this.
> > One is that DMA is turned off (what does hdparm /dev/hda and hdparm
> > /dev/hdc show?), the
On Sat, Apr 14, 2001 at 11:38:06AM +0200, Andreas Peter wrote:
Am Samstag, 14. April 2001 09:04 schrieb David Rees:
OK, so it's not the RAID setup. There's two things that can cause this.
One is that DMA is turned off (what does hdparm /dev/hda and hdparm
/dev/hdc show?), the second
While running 2.4.3, I saw the following message a few times:
KERNEL: assertion (tp-lost_out == 0) failed at
tcp_input.c(1202):tcp_remove_reno_sacks
Is that bad, or should I just ignore it?
Kurt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Sat, Apr 14, 2001 at 04:12:09PM +0100, Alan Cox wrote:
Can the folks who are seeing crashes running athlon optimised kernels all mail
me
Just trying to privide you with usefull info. I'm NOT seeing any
crashes at all.
- CPU model/stepping
processor : 0
vendor_id :
On Wed, Apr 11, 2001 at 01:38:30AM +0200, Kurt Roeckx wrote:
> On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
> >
> > the shutdown scripts
> > include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
> > "al
On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
>
> the shutdown scripts
> include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
> "all processes except me". That means init will get hit with
> SIGTERM occasionally during shutdown, and that might cause
> weird things
On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
the shutdown scripts
include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
"all processes except me". That means init will get hit with
SIGTERM occasionally during shutdown, and that might cause
weird things to
On Wed, Apr 11, 2001 at 01:38:30AM +0200, Kurt Roeckx wrote:
On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
the shutdown scripts
include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
"all processes except me". That means in
On Wed, Mar 28, 2001 at 08:37:49PM -0500, Alexander Valys wrote:
> Is there a kernel development irc room anywhere? If not, does anyone think
> it might be useful?
I'd just like to point out that it's called a channel, not a
room. Room is a term introduced by AOL, and I don't think it has
On Wed, Mar 28, 2001 at 08:37:49PM -0500, Alexander Valys wrote:
Is there a kernel development irc room anywhere? If not, does anyone think
it might be useful?
I'd just like to point out that it's called a channel, not a
room. Room is a term introduced by AOL, and I don't think it has
much
On Sat, Mar 03, 2001 at 07:32:13PM +, Alan Cox wrote:
>
> 2.4.2-ac11
> o Add ALi15x3 to the list of isa dma hangs(Angelo Di Filippo)
What does this mean?
Kurt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Sat, Mar 03, 2001 at 07:32:13PM +, Alan Cox wrote:
2.4.2-ac11
o Add ALi15x3 to the list of isa dma hangs(Angelo Di Filippo)
What does this mean?
Kurt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
I suddenly started to get those oopses. It didn't seem to cause
any problems tho.
I hope this result from ksymoops are usefull.
Kurt
ksymoops 2.3.7 on i586 2.4.1-ac8. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o
I suddenly started to get those oopses. It didn't seem to cause
any problems tho.
I hope this result from ksymoops are usefull.
Kurt
ksymoops 2.3.7 on i586 2.4.1-ac8. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o
On Thu, Feb 08, 2001 at 08:12:39PM -0200, Rik van Riel wrote:
> On Thu, 8 Feb 2001, Alan Cox wrote:
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
> >
> > 2.4.1-ac7
> > o Rebalance the 2.4.1 VM (Rik van Riel)
> > | This should make things feel a
On Thu, Feb 08, 2001 at 08:12:39PM -0200, Rik van Riel wrote:
On Thu, 8 Feb 2001, Alan Cox wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
2.4.1-ac7
o Rebalance the 2.4.1 VM (Rik van Riel)
| This should make things feel a lot faster
On Tue, Jan 30, 2001 at 11:31:13PM -0600, Mohit Aron wrote:
> I analyzed the problem to be the following. Linux uses periodic SIGPROF signals
> for profiling (Linux doesn't use the profil system call used in other OS's like
> Solaris where the kernel does the profiling on behalf of the process).
On Tue, Jan 30, 2001 at 11:31:13PM -0600, Mohit Aron wrote:
I analyzed the problem to be the following. Linux uses periodic SIGPROF signals
for profiling (Linux doesn't use the profil system call used in other OS's like
Solaris where the kernel does the profiling on behalf of the process). All
I'm having a problem when I try to profile a program that
fork()'s. The problem is that it does count how many times I'm in
a function, but nothing seems to use any cpu time at all.
If I call setitmer(ITIMER_PROF, ...) again after the
fork, it works as expected. fork() doesn't seem to copy the
I'm having a problem when I try to profile a program that
fork()'s. The problem is that it does count how many times I'm in
a function, but nothing seems to use any cpu time at all.
If I call setitmer(ITIMER_PROF, ...) again after the
fork, it works as expected. fork() doesn't seem to copy the
On Mon, Jan 08, 2001 at 11:50:44PM +0100, [EMAIL PROTECTED] wrote:
> From: Andrea Arcangeli <[EMAIL PROTECTED]>
>
> > But in fact it fails with EINVAL, and
> >
> > [EINVAL]: The path argument contains a last component that is dot.
>
> I can't confirm. The specs I'm checking
On Mon, Jan 08, 2001 at 11:50:44PM +0100, [EMAIL PROTECTED] wrote:
From: Andrea Arcangeli [EMAIL PROTECTED]
But in fact it fails with EINVAL, and
[EINVAL]: The path argument contains a last component that is dot.
I can't confirm. The specs I'm checking are here:
On Sun, Jan 07, 2001 at 08:43:12PM +1100, Brett wrote:
>
> Taking a guess here
>
> strings /lib/libc* | grep "release version"
>
> I'm not sure how reliable this method is either :)
That returns nothing here.
I do find this in it:
"@(#) The Linux C library 5.4.46"
Kurt
-
To
On Sun, Jan 07, 2001 at 08:43:12PM +1100, Brett wrote:
Taking a guess here
strings /lib/libc* | grep "release version"
I'm not sure how reliable this method is either :)
That returns nothing here.
I do find this in it:
"@(#) The Linux C library 5.4.46"
Kurt
-
To unsubscribe from
On Sat, Jan 06, 2001 at 11:35:52AM -0800, [EMAIL PROTECTED] wrote:
> Neither hwclock nor the /dev/rtc driver takes the following comment from
> set_rtc_mmss() in arch/i386/kernel/time.c into account. As a result, using
> hwclock --systohc or --adjust always leaves the Hardware Clock 500 ms
On Sat, Jan 06, 2001 at 11:35:52AM -0800, [EMAIL PROTECTED] wrote:
Neither hwclock nor the /dev/rtc driver takes the following comment from
set_rtc_mmss() in arch/i386/kernel/time.c into account. As a result, using
hwclock --systohc or --adjust always leaves the Hardware Clock 500 ms
On Tue, Jan 02, 2001 at 03:51:34AM +0100, Gerold Jury wrote:
> The ISDN changes for the HISAX drivers
> that came in since test12 have introduced a bug that causes a
> AIEE-something and a complete kernel hang when i hangup the isdn line.
> I have reversed the patch for all occurences of
On Tue, Jan 02, 2001 at 03:51:34AM +0100, Gerold Jury wrote:
The ISDN changes for the HISAX drivers
that came in since test12 have introduced a bug that causes a
AIEE-something and a complete kernel hang when i hangup the isdn line.
I have reversed the patch for all occurences of
On Fri, Dec 15, 2000 at 12:14:04AM +, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> LA Walsh <[EMAIL PROTECTED]> wrote:
> >Which works because in a normal compile environment they have /usr/include
> >in their include path and /usr/include/linux points to the directory
>
On Fri, Dec 15, 2000 at 12:14:04AM +, Miquel van Smoorenburg wrote:
In article [EMAIL PROTECTED],
LA Walsh [EMAIL PROTECTED] wrote:
Which works because in a normal compile environment they have /usr/include
in their include path and /usr/include/linux points to the directory
under
On Thu, Nov 16, 2000 at 11:52:49AM -0800, jesse wrote:
> On Thu, Nov 16, 2000 at 05:16:18PM +0100, Andrea Arcangeli wrote:
> > On Thu, Nov 16, 2000 at 03:07:04PM +0100, Matthias Andree wrote:
> > > It shows a program that saves the cwd -- open(".",...) in an open file,
> > > then chroots [..]
> >
On Thu, Nov 16, 2000 at 11:52:49AM -0800, jesse wrote:
On Thu, Nov 16, 2000 at 05:16:18PM +0100, Andrea Arcangeli wrote:
On Thu, Nov 16, 2000 at 03:07:04PM +0100, Matthias Andree wrote:
It shows a program that saves the cwd -- open(".",...) in an open file,
then chroots [..]
This is
On Wed, Nov 08, 2000 at 12:53:18PM -0800, Jim Bonnet wrote:
> I am using the 2.4.0-test10 kernel. I have a sound blaster 16 which
> works fine under 2.2.17.
>
> I see that a while back someone posted on this problem previously but
> there were no answers I can find..
>
> Is support for
I once complained about the s390 port not compiling because
_stext had conflicting types.
You seem to have changed include/asm/irq.h then, adding [] to it,
like it is in kernel/ksyms.c.
I just did a little grepping, And saw this:
./init/main.c:extern char _stext, _etext;
./kernel/ksyms.c:extern
I once complained about the s390 port not compiling because
_stext had conflicting types.
You seem to have changed include/asm/irq.h then, adding [] to it,
like it is in kernel/ksyms.c.
I just did a little grepping, And saw this:
./init/main.c:extern char _stext, _etext;
./kernel/ksyms.c:extern
On Wed, Nov 08, 2000 at 12:53:18PM -0800, Jim Bonnet wrote:
I am using the 2.4.0-test10 kernel. I have a sound blaster 16 which
works fine under 2.2.17.
I see that a while back someone posted on this problem previously but
there were no answers I can find..
Is support for soundblaster16
When trying to compile something using libc5, with the
2.4.0-test10 kernel, I get this:
/usr/include/time.h:85: conflicting types for `mktime'
/usr/include/linux/time.h:69: previous declaration of `mktime'
A simple diff is attached
--- include/linux/time.h~ Fri Nov 3 20:22:14 2000
+++
When trying to compile something using libc5, with the
2.4.0-test10 kernel, I get this:
/usr/include/time.h:85: conflicting types for `mktime'
/usr/include/linux/time.h:69: previous declaration of `mktime'
A simple diff is attached
--- include/linux/time.h~ Fri Nov 3 20:22:14 2000
+++
On Tue, Sep 05, 2000 at 05:30:46PM +0200, Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
>
> > A kernel debugger will reduce development costs. No one cares what's
> > underneath, [...]
>
> this is the point where IMO your argument gets flawed, and where you are
> apparently
66 matches
Mail list logo
