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 initializ
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 ±2
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 stick
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 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&#
On Tue, May 29, 2001 at 12:12:56AM +0100, Russell King wrote:
> On Mon, May 28, 2001 at 11:43:38PM +0200, Vadim Lebedev wrote:
> > 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.
>
> I don't think there's problem, u
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 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 use
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 do
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 oth
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 i
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 m
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
> reporters
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
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 : Auth
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 messag
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 se
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 pro
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 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 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 /lib/modules/2.4.1-ac8
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 l
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). A
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
t
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 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
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 ah
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 INIT_LIS
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
> >u
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 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 soundblas
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
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 i
36 matches
Mail list logo
