Re: 242-ac3 loop bug

Re: 242-ac3 loop bug

[Jonathan Oppenheim]

i have also been having trouble with many cyphers including
blowfish (although twofish and idea worked).  the error seems to be the
same in all 2.4.x kernels (i have all the relevant options compiled
as modules eg. loopback and ciphers))

i follow the encryptionhowto, but when i do a 
losetup -e blah blah blah
i get a segmentation fault (no core, no other error
messages as far as i can see)

then, i can't rmmod the loop module and other modules because
they are busy.

so i can't unmount the disk.

i haven't yet tried things with 2.4.2-ac3, but the problem
seems to be with particular cyphers not with loopback.

let me know what system specs you need (directly -as i'm not
on the kernel list)

(i have an amd athlon running on k7a asus motherboard if that helps).

cheers,
j

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2

mQCNAzc5/rwAAAEEALGi/cKupURWMeRs3xKx7+3PHi1hqfswOuM5suJhTEJZiR+p
xYsVYB/B/uNwrr+m+Rzd8sEJlB2D/JkkCHMUplDR2OC0hfUYmQGIXEg9kShudRsO
E+1oVFFevj6MTgIY6c5nSWvz3n+zLHrcHk/k8pLDpI6qcIGqrAEcX2GVzVwNAAUR
tARqb25vtBU8am9ub0BwaHlzaWNzLnViYy5jYT4=
=fDxR
-----END PGP PUBLIC KEY BLOCK-----

Re: 242-ac3 loop bug

[Jens Axboe]

On Sun, Feb 25 2001, Jonathan Oppenheim wrote:
> i have also been having trouble with many cyphers including
> blowfish (although twofish and idea worked).  the error seems to be the
> same in all 2.4.x kernels (i have all the relevant options compiled
> as modules eg. loopback and ciphers))
> 
> i follow the encryptionhowto, but when i do a 
> losetup -e blah blah blah
> i get a segmentation fault (no core, no other error
> messages as far as i can see)
> 
> then, i can't rmmod the loop module and other modules because
> they are busy.
> 
> so i can't unmount the disk.
> 
> i haven't yet tried things with 2.4.2-ac3, but the problem
> seems to be with particular cyphers not with loopback.

So report the problem to the crypto folks people? I've seen several
of these now, but not one includes ksymoops info etc.

-- 
Jens Axboe

Re: 242-ac3 loop bug

[Mario Hermann]

Hi!

Jonathan Oppenheim wrote:

> i have also been having trouble with many cyphers including
> blowfish (although twofish and idea worked).  the error seems to be the
> same in all 2.4.x kernels (i have all the relevant options compiled
> as modules eg. loopback and ciphers))

I had the same problem today with blowfish. Following mini-diff works for
blowfish(apply after patch-int-2.4.0.3):

--- crypto/cipher-blowfish.c~   Sun Feb 25 13:33:42 2001
+++ crypto/cipher-blowfish.c    Sun Feb 25 13:48:23 2001
@@ -404,6 +404,8 @@
     u32 *P = key2->P;
     u32 *S = key2->S;

+    if (keybytes<=0 || keybytes>32) return(-1);
+
     /* Copy the initialization s-boxes */

     for (i = 0, count = 0; i < 256; i++)

242-ac3 loop bug

[Mark Swanson]

First, good job on the loop device. It's rock stable for me - except
when I try to load the blowfish module which oops the kernel and
crashes the loop device:-) No problem, I just use another cipher.

The bug I'm reporting is that when a loop device is in use the load of
the machine stays at 1.00 even though nothing is happening. If I umount
the loop filesystem the load goes down to 0.00.

> ps -aux | grep loop
1674 tty1     DW<   0:00 [loop0]

The system is doing nothing to the loop filesystem.
Strange that the process isn't logging any cpu usage time. It's
definately responsible for the 1.00 load.



__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Re: 242-ac3 loop bug

[Doug McNaught]

Mark Swanson <swansma@yahoo.com> writes:

> > ps -aux | grep loop
> 1674 tty1     DW<   0:00 [loop0]
> 
> The system is doing nothing to the loop filesystem.
> Strange that the process isn't logging any cpu usage time. It's
> definately responsible for the 1.00 load.

It's just an artifact of the fact that processes in state D
(uninterruptible sleep) are included in the load average calculation.
Since the loop thread apparently sits in state D waiting for events
on its device, you get a load average of 1 for each mounted loop
device. 

I know nothing about the implementation of the loop thread so won't
presume to say whether/how it can be "fixed". 

-Doug

Re: 242-ac3 loop bug

[Mark Swanson]

--- Doug McNaught <doug@wireboard.com> wrote:
> Mark Swanson <swansma@yahoo.com> writes:
> 
> > > ps -aux | grep loop
> > 1674 tty1     DW<   0:00 [loop0]
> > 
> > The system is doing nothing to the loop filesystem.
> > Strange that the process isn't logging any cpu usage time. It's
> > definately responsible for the 1.00 load.
> 
> It's just an artifact of the fact that processes in state D
> (uninterruptible sleep) are included in the load average calculation.
> Since the loop thread apparently sits in state D waiting for events
> on its device, you get a load average of 1 for each mounted loop
> device. 

My thought was that the calculation seems to be misleading. The loop
process isn't taking up any CPU time. My applications are running
faster than ever. I'm guessing that ps (and /proc/loadavg) need to make
the distinction between:
1. uninterruptable sleep - where the process is blocking but taking
0CPU
2. uninterruptable sleep - I/O is happening using CPU

But I may not understand what uninterruptable sleep is supposed to
mean.

Take sendmail for example. Its default configuration for Linux won't
send attachments if the machine's load is too high. If I have 8 loop
devices in use and the load is at least 8, this may affect how sendmail
operates.



__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Re: 242-ac3 loop bug

[Doug McNaught]

Mark Swanson <swansma@yahoo.com> writes:

> --- Doug McNaught <doug@wireboard.com> wrote:
> > It's just an artifact of the fact that processes in state D
> > (uninterruptible sleep) are included in the load average calculation.
> > Since the loop thread apparently sits in state D waiting for events
> > on its device, you get a load average of 1 for each mounted loop
> > device. 
> 
> My thought was that the calculation seems to be misleading. The loop
> process isn't taking up any CPU time. My applications are running
> faster than ever. I'm guessing that ps (and /proc/loadavg) need to make
> the distinction between:
> 1. uninterruptable sleep - where the process is blocking but taking
> 0CPU
> 2. uninterruptable sleep - I/O is happening using CPU
> 
> But I may not understand what uninterruptable sleep is supposed to
> mean.

Well, "sleep" means we're not using CPU at all; we're waiting for
something.  Remember, "load average" isn't purely a CPU measure.

Historically, state D has meant "fast" i/o--reading from disk or tape,
where the result is supposed to be available very soon and it's not
worth doing the extra housekeeping to sleep interruptibly.  Processes
aren't supposed to sit in state D for more than a fraction of a
second.  This being the case, Unix has always factored state D
processes into the load average.  For your distinction to work, there
would have to be an extra flag somewhere saying "I'm in state D, but
don't factor me into the load average", with corresponding code in the
load average calculation routine to honor the flag.  Doable, but not
useful up to now, and only (possibly) worth doing if we get more
threads like the loop driver that sit in D state for a long time. 

This is the first example I've seen in Linux of something sitting in
state D for a long time on purpose.  I agree that IMHO it's not ideal
(for the reason you outline below, mainly).

> Take sendmail for example. Its default configuration for Linux won't
> send attachments if the machine's load is too high. If I have 8 loop
> devices in use and the load is at least 8, this may affect how sendmail
> operates.

Yup. 

The whole Sendmail/load average thing needs careful thought anyway
when setting up a production system--a load average of 8 on an 8-way
system, for example, is a much lighter load than a load of 8 on a
single-CPU machine.

-Doug

Re: 242-ac3 loop bug

[Arjan van de Ven]

In article <20010224173234.14673.qmail@web1301.mail.yahoo.com> you wrote:
> First, good job on the loop device. It's rock stable for me - except
> when I try to load the blowfish module which oops the kernel and
> crashes the loop device:-) No problem, I just use another cipher.

> The bug I'm reporting is that when a loop device is in use the load of
> the machine stays at 1.00 even though nothing is happening. If I umount
> the loop filesystem the load goes down to 0.00.

>> ps -aux | grep loop
> 1674 tty1     DW<   0:00 [loop0]

This is probably easy to fix in the driver, right now it waits for
events in UNINTERRUPTIBLE state, while it should wait in INTERRUPTIBLE
state. The fix isn't as trivial as removing 2 letters though, I'll send Alan
a real patch on monday.

Greetings,
   Arjan van de Ven

Re: 242-ac3 loop bug

[Jens Axboe]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

On Sat, Feb 24 2001, Mark Swanson wrote:
> First, good job on the loop device. It's rock stable for me - except

thanks, glad to hear it.

> when I try to load the blowfish module which oops the kernel and
> crashes the loop device:-) No problem, I just use another cipher.

cipher bug or? never the less, could you ksymoops that and send
it along?

> The bug I'm reporting is that when a loop device is in use the load of
> the machine stays at 1.00 even though nothing is happening. If I umount
> the loop filesystem the load goes down to 0.00.
> 
> > ps -aux | grep loop
> 1674 tty1     DW<   0:00 [loop0]
> 
> The system is doing nothing to the loop filesystem.
> Strange that the process isn't logging any cpu usage time. It's
> definately responsible for the 1.00 load.

Oops, this slipped by me. Patch should fix it.

-- 
Jens Axboe


[-- Attachment #2: loop_sig-1 --]
[-- Type: text/plain, Size: 546 bytes --]

--- drivers/block/loop.c~	Sat Feb 24 23:08:38 2001
+++ drivers/block/loop.c	Sat Feb 24 23:11:13 2001
@@ -507,7 +507,7 @@
 	sprintf(current->comm, "loop%d", lo->lo_number);
 
 	spin_lock_irq(&current->sigmask_lock);
-	siginitsetinv(&current->blocked, sigmask(SIGKILL));
+	sigfillset(&current->blocked);
 	flush_signals(current);
 	spin_unlock_irq(&current->sigmask_lock);
 
@@ -525,7 +525,7 @@
 	up(&lo->lo_sem);
 
 	for (;;) {
-		down(&lo->lo_bh_mutex);
+		down_interruptible(&lo->lo_bh_mutex);
 		if (!atomic_read(&lo->lo_pending))
 			break;
 

Re: 242-ac3 loop bug

[Mircea Ciocan]

	Halleluiah ;)!!!

	Finally, it works as is suposed to do :)))), the load on my dual
PIIIx950 is 0.01 three times and I can mount and umonunt ISOs as much I
wish.
	Thank you very much Jens and all that provided usefull feedback, this
patch alone deserves including in an .acX release.
	And Jens if you ever come to Romania give me a call I owe you a lot of
beers and pizzas :).

		Mircea "happy, happy, joy, joy...;)" C.



Jens Axboe wrote:
> 
> On Sat, Feb 24 2001, Mark Swanson wrote:
> > First, good job on the loop device. It's rock stable for me - except
> 
> thanks, glad to hear it.
> 
> > when I try to load the blowfish module which oops the kernel and
> > crashes the loop device:-) No problem, I just use another cipher.
> 
> cipher bug or? never the less, could you ksymoops that and send
> it along?
> 
> > The bug I'm reporting is that when a loop device is in use the load of
> > the machine stays at 1.00 even though nothing is happening. If I umount
> > the loop filesystem the load goes down to 0.00.
> >
> > > ps -aux | grep loop
> > 1674 tty1     DW<   0:00 [loop0]
> >
> > The system is doing nothing to the loop filesystem.
> > Strange that the process isn't logging any cpu usage time. It's
> > definately responsible for the 1.00 load.
> 
> Oops, this slipped by me. Patch should fix it.
> 
> --
> Jens Axboe
> 
>   ------------------------------------------------------------------------
> --- drivers/block/loop.c~       Sat Feb 24 23:08:38 2001
> +++ drivers/block/loop.c        Sat Feb 24 23:11:13 2001
> @@ -507,7 +507,7 @@
>         sprintf(current->comm, "loop%d", lo->lo_number);
> 
>         spin_lock_irq(&current->sigmask_lock);
> -       siginitsetinv(&current->blocked, sigmask(SIGKILL));
> +       sigfillset(&current->blocked);
>         flush_signals(current);
>         spin_unlock_irq(&current->sigmask_lock);
> 
> @@ -525,7 +525,7 @@
>         up(&lo->lo_sem);
> 
>         for (;;) {
> -               down(&lo->lo_bh_mutex);
> +               down_interruptible(&lo->lo_bh_mutex);
>                 if (!atomic_read(&lo->lo_pending))
>                         break;
>