[PATCH] lp486e.c: check region removal

[pazke]

Hi all,

patch for lp486e.c network driver attached. 
Changes: check_region() call removed, added missing __init and __exit.

Best regards.

-- 
Andrey Panin| Embedded systems software engineer
[EMAIL PROTECTED]| PGP key: http://www.orbita1.ru/~pazke/AndreyPanin.asc


diff -ur -X /usr/dontdiff linux.vanilla/drivers/net/lp486e.c 
/linux/drivers/net/lp486e.c
--- linux.vanilla/drivers/net/lp486e.c  Mon May 21 23:49:44 2001
+++ /linux/drivers/net/lp486e.c Fri May 25 22:23:22 2001
@@ -971,16 +971,17 @@
volatile struct i596_private *lp;
unsigned char eth_addr[6] = { 0, 0xaa, 0, 0, 0, 0 };
unsigned char *bios;
-   int i,j;
-   static int probed = 0;
+   int i, j;
+   int ret = -ENOMEM;
+   static int probed;
 
if (probed)
return -ENODEV;
probed++;
 
-   if (check_region(IOADDR, LP486E_TOTAL_SIZE)) {
-   printk("lp486e: IO address 0x%x in use\n", IOADDR);
-   return -ENODEV;
+   if (!request_region(IOADDR, LP486E_TOTAL_SIZE, dev->name)) {
+   printk(KERN_ERR "lp486e: IO address 0x%x in use\n", IOADDR);
+   return -EBUSY;
}
 
/*
@@ -989,7 +990,7 @@
dev->mem_start = (unsigned long)
kmalloc(sizeof(struct i596_private) + 0x0f, GFP_KERNEL);
if (!dev->mem_start)
-   return -ENOMEM;
+   goto err_out;
dev->priv = (void *)((dev->mem_start + 0xf) & 0xfff0);
lp = (struct i596_private *) dev->priv;
memset((void *)lp, 0, sizeof(struct i596_private));
@@ -998,12 +999,10 @@
 * Do we really have this thing?
 */
if (i596_scp_setup(dev)) {
-   kfree ((void *) dev->mem_start);
-   return -ENODEV;
+   ret = -ENODEV;
+   goto err_out_kfree;
}
 
-   request_region(IOADDR, LP486E_TOTAL_SIZE, "lp486e");
-
dev->base_addr = IOADDR;
dev->irq = IRQ;
 
@@ -1053,6 +1052,12 @@
i596_port_do(dev, PORT_DUMP, "dump");
 #endif
return 0;
+
+err_out_kfree:
+   kfree ((void *) dev->mem_start);
+err_out:
+   release_region(IOADDR, LP486E_TOTAL_SIZE);
+   return ret;
 }
 
 static void inline
@@ -1330,7 +1335,7 @@
 static int io = IOADDR;
 static int irq = IRQ;
 
-static int lp486e_init_module(void) {
+static int __init lp486e_init_module(void) {
struct net_device *dev = &dev_lp486e;
dev->irq = irq;
dev->base_addr = io;
@@ -1342,7 +1347,7 @@
return 0;
 }
 
-static void lp486e_cleanup_module(void) {
+static void __exit lp486e_cleanup_module(void) {
unregister_netdev(&dev_lp486e);
kfree((void *)dev_lp486e.mem_start);
dev_lp486e.priv = NULL;

 PGP signature

Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

[David Welch]

On Fri, May 25, 2001 at 03:20:20PM +1000, Keith Owens wrote:
> 
> >> On a side note, does anyone know if the kernel does checking if the
> >> stack overflowed at any time?
> >
> >You normally get a silent hang or worse a stack fault exception 
> >(which linux/x86 without kdb cannot recover from) which gives you instant 
> >reboot.
> 
> You cannot recover from a kernel stack overflow even with kdb.  The
> exception handler and kdb use the stack that just overflowed.
> 
Why not use a task gate for the double fault handler points to a 
per-processor TSS with a seperate stack. This would allow limited recovery
from a kernel stack overlay.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Alexander Viro]

On 25 May 2001, Andreas Jaeger wrote:

> We have comments in the code that state how j0 is build, and R0/S0
> come from some expansion:
>  * Bessel function of the first and second kinds of order zero.
>  * Method -- j0(x):
>  *1. For tiny x, we use j0(x) = 1 - x^2/4 + x^4/64 - ...
>  *2. Reduce x to |x| since j0(x)=j0(-x),  and
>  *   for x in (0,2)
>  *j0(x) = 1-z/4+ z^2*R0/S0,  where z = x*x;
>  *   (precision:  |j0-1+z/4-z^2R0/S0 |<2**-63.67 )
> 
> Andreas

Sure. However, the question about choosing the polynomials stands.
(And no, I'm not proposing to go and bugger glibc folks over that ;-)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Andreas Jaeger]

Aaron Lehmann <[EMAIL PROTECTED]> writes:

> On Fri, May 25, 2001 at 02:34:05AM -0400, Alexander Viro wrote:
> > Should we file bug reports against glibc?
> 
> invsqrtpi=  5.64189583547756279280e-01
> Inverted square root of pi. Want to file a bug on Pi?
> 
> tpi  =  6.36619772367581382433e-01,
> R0/S0 on [0, 2.00]
> 
> I'm not sure what R and S are, but the glibc developers probably are.

We have comments in the code that state how j0 is build, and R0/S0
come from some expansion:
 * Bessel function of the first and second kinds of order zero.
 * Method -- j0(x):
 *  1. For tiny x, we use j0(x) = 1 - x^2/4 + x^4/64 - ...
 *  2. Reduce x to |x| since j0(x)=j0(-x),  and
 * for x in (0,2)
 *  j0(x) = 1-z/4+ z^2*R0/S0,  where z = x*x;
 * (precision:  |j0-1+z/4-z^2R0/S0 |<2**-63.67 )

Andreas
-- 
 Andreas Jaeger
  SuSE Labs [EMAIL PROTECTED]
   private [EMAIL PROTECTED]
http://www.suse.de/~aj
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Alexander Viro]

On Thu, 24 May 2001, Aaron Lehmann wrote:

> On Fri, May 25, 2001 at 02:34:05AM -0400, Alexander Viro wrote:
> > Should we file bug reports against glibc?
> 
> invsqrtpi=  5.64189583547756279280e-01
> Inverted square root of pi. Want to file a bug on Pi?

Nope. Well-known constant.

> tpi  =  6.36619772367581382433e-01,
> R0/S0 on [0, 2.00]
> 
> I'm not sure what R and S are, but the glibc developers probably are.
> IMHO poorly documented code is different from binary-only code.
> However, it appears to be a sketchy line.

It _is_ a sketchy line. In that case you can be damn sure that constants
had been derived from other form. And you need that other form to do any
modifications that wouldn't turn the thing into random junk.

Normally you don't need it, unless you feel that one you have in glibc is
not good enough for your needs or want to experiment with modifying it.
Or analise the thing.

It's pretty similar to the case in question. The only difference is that
information needed to implement Bessel functions from scratch is easier
to find. However, it will be reimplementing from scratch. It won't help
you to answer any questions about the accuracy of implementation in glibc,
etc.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reg ramfs mkfs

[SATHISH.J]

Hi all,

Please excuse me if my doubt is silly but do help me in answering this.

I compiled the ramfilesystem under fs/ramfs and got the object file
inode.o.

1.Should I do insmod to insert this module. 
2.After inserting this module how can I use "mkfs" to make this file
system befor mounting it.

Please help with the answers as I am highly confused.

Thanks in advance,

Regards,
sathish.j

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ac15 and 2.4.5-pre6, pwc format conversion

[Norbert Preining]

Hi!

According to ac ChangeLog:
o   Rip format conversion out of the pwc driver (me)
| It belongs in user space..

This change is included in 2.4.5-pre6, but
drivers/usb/pwc-uncompress.c
still relies on this files:
gcc -D__KERNEL__ -I/usr/src/linux-2.4.5.6-packet/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=k6 
-DMODULE   -DEXPORT_SYMTAB -c pwc-uncompress.c
pwc-uncompress.c:25: vcvt.h: No such file or directory
pwc-uncompress.c: In function `pwc_decompress':
pwc-uncompress.c:158: warning: implicit declaration of function `vcvt_420i_rgb24'
pwc-uncompress.c:161: warning: implicit declaration of function `vcvt_420i_bgr24'
pwc-uncompress.c:164: warning: implicit declaration of function `vcvt_420i_rgb32'
pwc-uncompress.c:167: warning: implicit declaration of function `vcvt_420i_bgr32'
pwc-uncompress.c:171: warning: implicit declaration of function `vcvt_420i_yuyv'
pwc-uncompress.c:185: warning: implicit declaration of function `vcvt_420i_420p'

Best wishes

Norbert

PS: Please reply by email since I am not subscribed and I skim the
mailing list via the web archive.
THANKS.

-- 
ciao
norb

+---+
| Norbert Preining  http://www.logic.at/people/preining |
| University of Technology Vienna, Austria[EMAIL PROTECTED] |
| DSA: 0x09C5B094 (RSA: 0xCF1FA165) mail subject: get [DSA|RSA]-key |
+---+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Aaron Lehmann]

On Fri, May 25, 2001 at 02:34:05AM -0400, Alexander Viro wrote:
> Should we file bug reports against glibc?

invsqrtpi=  5.64189583547756279280e-01
Inverted square root of pi. Want to file a bug on Pi?

tpi  =  6.36619772367581382433e-01,
R0/S0 on [0, 2.00]

I'm not sure what R and S are, but the glibc developers probably are.
IMHO poorly documented code is different from binary-only code.
However, it appears to be a sketchy line.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

[Andreas Dilger]

Keith Owens writes:
> Andi Kleen <[EMAIL PROTECTED]> wrote:
> >At one time someone had a script to grep objdump -S vmlinux for the
> >stack allocations generated by gcc and check them.
> 
> ftp://ftp.ocs.com.au/pub/kernel.stack.gz.  ix86 specific, probably gcc
> specific and it only picks up code that you compile.  The Stanford
> checker is much better.

I would probably agree.  Dawson said in a separate email that it would
be possible to enhance the checker to follow the call chains to measure
total stack usage.  Combining this with potential interrupt stack usage,
we may be able to eliminate some rare problems otherwise hard to find.

> >> On a side note, does anyone know if the kernel does checking if the
> >> stack overflowed at any time?
> >
> >You normally get a silent hang or worse a stack fault exception 
> >(which linux/x86 without kdb cannot recover from) which gives you instant 
> >reboot.
> 
> You cannot recover from a kernel stack overflow even with kdb.  The
> exception handler and kdb use the stack that just overflowed.

If it at least tells you that the stack has overflowed, and a backtrace
of the stack up to that point, that would at least be useful for fixing
the functions which caused the problem.

Also, allowing a config option to zero the stack at allocation would at
least allow the SysRQ-T code to tell you how much of the stack has
previously been in use so we can get an idea if we are close or not.

Given that the Stanford checker has discovered several individual 3kB+
stack allocations, it would surprise me if we didn't have stack overflows.
It may well be that people get mysterious hangs in these cases and have
no way to even diagnose the problem.  Maybe they are blaming the rare
hangs on hardware instead of software.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Alexander Viro]

On Thu, 24 May 2001, Aaron Lehmann wrote:

> explicit about defining source code:
>   The source code for a work means the preferred form of the work for
>   making modifications to it.

Erm... May I point you to the sysdep/libm-ieee754/e_j0.c? There's a bunch
of constants of unknown origin. If you want to modify the implementation
you most certainly want more than numeric values.

Same goes for any tables that contain anything besides well-known constants.

Should we file bug reports against glibc?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Configure.help entries wanted

[Eric S. Raymond]

Keith Owens <[EMAIL PROTECTED]>:
> I claim my erudition prize (do I get steak knives with that?).

Results doubtful.  Consult Magic 8-Ball again :-).

I'm going to critique these individually pour encourager les autres.

> +Disable IA-64 Virtual Hash Page Table
> +CONFIG_DISABLE_VHPT
> +  The Virtual Hash Page Table (VHPT) enhances virtual address
> +  translation performance.  Normally you want the VHPT active but you
> +  can select this option to disable the VHPT for debugging.  If you're
> +  unsure, answer N.

Excellent!  Second sentence a good example of motivation.

> +McKinley A-step specific code
> +CONFIG_MCKINLEY_ASTEP_SPECIFIC
> +  Select this option to build a kernel for an IA64 McKinley system
> +  with any A-stepping CPU.
> +
> +McKinley A0/A1-step specific code
> +CONFIG_MCKINLEY_A0_SPECIFIC
> +  Select this option to build a kernel for an IA64 McKinley system
> +  with an A0 or A1 stepping CPU.

Ah, now I could have written these.  What I was hoping for was extra
information analogous to what's in these:

Enable Itanium B-step specific code
CONFIG_ITANIUM_BSTEP_SPECIFIC
  Select this option to build a kernel for an Itanium prototype system
  with a B-step CPU.  You have a B-step CPU if the "revision" field in
  /proc/cpuinfo has a value in the range from 1 to 4.

Enable Itanium B0-step specific code
CONFIG_ITANIUM_B0_SPECIFIC
  Select this option to build a kernel for an Itanium prototype system
  with a B0-step CPU.  You have a B0-step CPU if the "revision" field in
  /proc/cpuinfo is 1.

Is there a value range in /proc/cpuinfo that tells you you have an A/A0 step?

> +IA64 compare-and-exchange bug checking
> +CONFIG_IA64_DEBUG_CMPXCHG
> +  Selecting this option turns on bug checking for the IA64
> +  compare-and-exchange instructions.  This is slow!  If you're unsure,
> +  select N.
> +
> +IA64 IRQ bug checking
> +CONFIG_IA64_DEBUG_IRQ
> +  Selecting this option turns on bug checking for the IA64 irq_save and
> +  restore instructions.  This is slow!  If you're unsure, select N.

These would be much improved by some indication of what IA64 variants or mask
steppings have these problems.

> +IA64 Early printk support
> +CONFIG_IA64_EARLY_PRINTK
> +  Selecting this option uses the VGA screen for printk() output before
> +  the consoles are initialised.  It is useful for debugging problems
> +  early in the boot process, but only if you have a VGA screen
> +  attached.  If you're unsure, select N.

Good!

> +IA64 Print Hazards
> +CONFIG_IA64_PRINT_HAZARDS
> +  Selecting this option prints more information for Illegal Dependency
> +  Faults, that is, for Read after Write, Write after Write or Write
> +  after Read violations.  This option is ignored if you are compiling
> +  for an Itanium A step processor (CONFIG_ITANIUM_ASTEP_SPECIFIC).  If
> +  you're unsure, select Y.

Excellent!

This is a fine start.
-- 
http://www.tuxedo.org/~esr/";>Eric S. Raymond

"If I must write the truth, I am disposed to avoid every assembly 
of bishops; for of no synod have I seen a profitable end, but
rather an addition to than a diminution of evils; for the love 
of strife and the thirst for superiority are beyond the power 
of words to express."
-- Father Gregory Nazianzen, 381 AD
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Aaron Lehmann]

On Thu, May 24, 2001 at 11:26:20PM -0700, Matthew Jacob wrote:
> Sure- that's not BSD. You were speaking about all kinds of firmware, at least
> I thought you were. Must be too short on sleep.

Yes, I am. New-style BSD licenses are compatible with the GPL. As long
as a piece of firmware contains source (which I discussed in a
previous post; see the GPL for the relevent defenition of source code)
and is under a GPL-compatible license it should be fine (excepting
further issues like patents.

In the case of the keyspan drivers, the source code is not distributed
and the license is not free, nor GPL-compatible. I hear steps are
going towards resolving this, which is excellent. My other concern is
what the general policy towards these non-free firmware images
is/should be. I know that a lot of firmware exists in advansys.c, and
there are probably many more occurances of binary-only firmware
throughout the kernel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Big-ish SCSI disks

[Greg Johnson]

Thanks. Interesting that you mention the Severworks LE chipset. We
have 2 identical machines with the intel STL MOBO wich uses
the Severworks LE. They are both dual PIII 1GHz 1GB mem and ultra
160 drives. I have had nothing but trouble getting RedHat 7.1 beta-1,
7.1 beta-2 and 7.1 release. The OS tended to install ok 
but on beta1, only the up kernel would boot. On beta-2 and release
both up and smp kernels would boot. On neither of the systems
have I managed to build a kernel up or smp, new or same version
as was installed. When I tried to boot the kernel I had built,
the scsi driver would fail to load. This also happen on the Redhat
installed smp kernel in beta-1 and on any of the redhat installed
kernels in either of beta-2 or release when I tried to use disk
striping.

Have you experienced any issues like this?
Have you successfuly built a kernel that booted on these machines?

Regards

Greg.

Quoth Scott Murray:
> 
> On Fri, 25 May 2001, Greg Johnson wrote:
> 
> > Hi kernel poeple,
> >
> > Can anyone out there say for certain that 76GB SCSI disks should
> > just work with kernel versions 2.2 and/or 2.4? We need to get some
> > big disk space and have heard reports of problems with disks
> > bigger than 30GB under linux.
> 
> I set up a machine at work a few months ago with two Seagate 73GB
> Ultra160 drives (model ST173404LW) using the Adaptec AIC-7899 adapter
> on board a ServerWorks LE chipset based motherboard.  Everything has
> been working fine using the stock RedHat 7.0 2.2.16-22smp kernel.  I
> also played with some 2.4.1-ac kernels to try out ReiserFS, and also
> had no problems using the disks.
> 
> Scott
> 
> 
> -- 
> =
> Scott Murrayemail: [EMAIL PROTECTED]
> http://www.spiteful.org (coming soon) ICQ: 10602428
> -
>  "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness"
> 


-- 
+--+
| Do you want to know more? www.geocities.com/worfsom/ |
|  ..ooOO Greg Johnson OOoo..  |
| HW/SW Engineer[EMAIL PROTECTED] |
| Canon Information Systems Research Australia (CISRA) |
| 1 Thomas Holt Dr., North Ryde, NSW, 2113,  Australia |
|  "I FLEXed my BISON and it went YACC!" - me. |
+--+

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Matthew Jacob]

Sure- that's not BSD. You were speaking about all kinds of firmware, at least
I thought you were. Must be too short on sleep.


On Thu, 24 May 2001, Aaron Lehmann wrote:

> On Thu, May 24, 2001 at 10:00:15PM -0700, Matthew Jacob wrote:
> > 
> > It is my opinion, such as it is, that a BSD copyright inside of a GPL package
> > does not, per se, weaken the GPL. The BSD copyright is, in fact, the more
> > permissive license. My reading of both licenses would have me believe that a
> > BSD licensed piece of software cannot then permit the linux kernel to be
> > binary only. The BSD licencse does not, per se, prohibit any form of binary
> > redistribution- nor does it require it. The GPL covers the whole kernel, and
> > if a BSD piece of code is directly linked in (not modloaded), it would have to
> > also be under GPL.
> > 
> > So pieces of linux-kernel which have BSD copyright are probably just fine.
> 
> /* keyspan_usa18x_fw.h
>   
>Generated from Keyspan firmware image Wed Jul  5 09:18:29 2000 EST
>This firmware is for the Keyspan USA-18X Serial Adaptor
> 
>"The firmware contained herein as keyspan_usa18x_fw.h is
>Copyright (C) 1999-2000 Keyspan, A division of InnoSys Incorporated
>("Keyspan"), as an unpublished work.  This notice does not imply
>unrestricted or public access to this firmware which is a trade secret of
>Keyspan, and which may not be reproduced, used, sold or transferred to any
>third party without Keyspan's prior written consent.  All Rights Reserved.
> 
>This firmware may not be modified and may only be used with the Keyspan 
>  ^^^
>USA-18X Serial Adapter.  Distribution and/or Modification of the
>keyspan.c driver which includes this firmware, in whole or in part,
>requires the inclusion of this statement."
> 
> That doesn't look like the BSD license to me.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] free bugs in 2.4.4 and 2.4.4-ac8

[Greg KH]

Here's the patch to fix the io_edgeport driver.  Johannes, please send
this to Linus, it's against 2.4.5-pre5.

thanks,

greg k-h


diff -Nru a/drivers/usb/serial/io_edgeport.c b/drivers/usb/serial/io_edgeport.c
--- a/drivers/usb/serial/io_edgeport.c  Thu May 24 23:18:56 2001
+++ b/drivers/usb/serial/io_edgeport.c  Thu May 24 23:18:56 2001
@@ -944,7 +944,7 @@
}
 
if (status) {
-   dbg(__FUNCTION__" - nonzero write bulk status received: %d", 
urb->status);
+   dbg(__FUNCTION__" - nonzero write bulk status received: %d", status);
return;
}
 

Re: [PATCH] bulkmem.c - null ptr fixes for 2.4.4

[Praveen Srinivasan]

Do we need to free the linked list in setup_regions? Would it be easier to 
try and preallocate the structures beforehand, and then fill them with the 
loop? Btw, we didn't find anything wrong with the first part of the patch.

Praveen Srinivasan and Frederick Akalin

Alan Cox wrote:

>> kernel code. This patch fixes numerous unchecked pointers in the PCMCIA
>> bulkmem driver.
> 
> Since when has two been numerous - also I dont thin the fix is right - you
> need to undo what has already been done
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Greg KH]

On Thu, May 24, 2001 at 09:34:04PM -0700, Aaron Lehmann wrote:
> This message sparked a long thread on the debian-legal mailing list,
> which is long since dead. I am personally very curious about whether
> this has been resolved upstream. I consider it a very important issue,
> which is why I asked for RMS' opinion. He said that what is being done
> is clearly not "mere aggregation", and that such firmware should be
> moved out of the kernel (and even the tarball) to stop violating the
> GPL and make Linux be free software.

Last I heard, Hugh was talking with the Keyspan people to get this
resolved.  But that was a few weeks ago.

Any news Hugh?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Aaron Lehmann]

On Fri, May 25, 2001 at 01:59:08AM -0400, Albert D. Cahalan wrote:
> If a driver writes 0x63f30e44 (4 bytes) to the card, no problem?
> Fine, how about 0x52e590a84fc8231e (8 bytes) then? You can see
> where this is leading I hope: 200 kB is perfectly fine.

Yes, I thought this way at first. However, the GPL is actually quite
explicit about defining source code:
The source code for a work means the preferred form of the work for
making modifications to it.

That means that if you modify your string of bytes in a hex editor,
it's not a problem. But if (as in the case of firmware) you create the
strings from secret, undistributed source files, then according to the
GPL the strings are not source code. Since the source code is
unavailable, that makes them non-free. You can see where this leads...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Pete Zaitcev]

> From: "Adam J. Richter" <[EMAIL PROTECTED]>
> Date: Sun, 22 Apr 2001 12:53:48 -0700
> To: [EMAIL PROTECTED]
> Subject: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

>[...]
>   I believe this infringinges the copyrights of the authors
> of the code used in these drivers who released their code under GPL.
> Alan Cox, has gone on a campaign claiming that this is "mere aggregation"
> and insists that I bring in the lawyers to prove him otherwise.  I
> really do not want to take this step, but he is forcing my hand.  Note
> that Yggdrasil is a copyright owner in this case.

Translation: Adam was soundly beaten on linux-usb-devel and is sore.

>   To simplify removal of the offending code, I have provided
> a separate user level facility that can use the USB "hot plugging"
> system to automatically load that "firmware" or any other. [...]

A good thing for many reasons, if it works. Personally, I do not
care why Adam writes right code as long as he does. :)

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Aaron Lehmann]

On Thu, May 24, 2001 at 10:00:15PM -0700, Matthew Jacob wrote:
> 
> It is my opinion, such as it is, that a BSD copyright inside of a GPL package
> does not, per se, weaken the GPL. The BSD copyright is, in fact, the more
> permissive license. My reading of both licenses would have me believe that a
> BSD licensed piece of software cannot then permit the linux kernel to be
> binary only. The BSD licencse does not, per se, prohibit any form of binary
> redistribution- nor does it require it. The GPL covers the whole kernel, and
> if a BSD piece of code is directly linked in (not modloaded), it would have to
> also be under GPL.
> 
> So pieces of linux-kernel which have BSD copyright are probably just fine.

/* keyspan_usa18x_fw.h
  
   Generated from Keyspan firmware image Wed Jul  5 09:18:29 2000 EST
   This firmware is for the Keyspan USA-18X Serial Adaptor

   "The firmware contained herein as keyspan_usa18x_fw.h is
   Copyright (C) 1999-2000 Keyspan, A division of InnoSys Incorporated
   ("Keyspan"), as an unpublished work.  This notice does not imply
   unrestricted or public access to this firmware which is a trade secret of
   Keyspan, and which may not be reproduced, used, sold or transferred to any
   third party without Keyspan's prior written consent.  All Rights Reserved.

   This firmware may not be modified and may only be used with the Keyspan 
 ^^^
   USA-18X Serial Adapter.  Distribution and/or Modification of the
   keyspan.c driver which includes this firmware, in whole or in part,
   requires the inclusion of this statement."

That doesn't look like the BSD license to me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Patch for PM in ymfpci (against 2.4.5-pre3)

[Pete Zaitcev]

> From: Jeff Garzik <[EMAIL PROTECTED]>

> Looks ok, only a small nit:  an include and 'pmdev' are left over from
> the older PM implementation, and can be removed.

Oops, here's a better one.

-- Pete

-

PM support for suspend/resume (without pm_register, proper PCI API);
Killed some P3's;
Removed unused unit.error;
Removed access_ok;

diff -ur -X dontdiff linux-2.4.5-pre3/drivers/sound/ymfpci.c 
linux-2.4.5-pre3-p3/drivers/sound/ymfpci.c
--- linux-2.4.5-pre3/drivers/sound/ymfpci.c Fri May 18 14:09:46 2001
+++ linux-2.4.5-pre3-p3/drivers/sound/ymfpci.c  Thu May 24 22:12:27 2001
@@ -23,10 +23,8 @@
  *   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  *
  * TODO:
- *  - Use P44Slot for 44.1 playback.
+ *  - Use P44Slot for 44.1 playback (beware of idle buzzing in P44Slot).
  *  - 96KHz playback for DVD - use pitch of 2.0.
- *  - uLaw for Sun apps.
- * : Alan says firmly "no software format conversion in kernel".
  *  - Retain DMA buffer on close, do not wait the end of frame.
  *  - Cleanup
  *  ? underused structure members
@@ -66,14 +64,19 @@
 #endif
 #include "ymfpci.h"
 
-static int ymf_playback_trigger(ymfpci_t *codec, struct ymf_pcm *ypcm, int cmd);
+static int ymf_playback_trigger(ymfpci_t *unit, struct ymf_pcm *ypcm, int cmd);
 static void ymf_capture_trigger(ymfpci_t *unit, struct ymf_pcm *ypcm, int cmd);
-static void ymfpci_voice_free(ymfpci_t *codec, ymfpci_voice_t *pvoice);
+static void ymfpci_voice_free(ymfpci_t *unit, ymfpci_voice_t *pvoice);
 static int ymf_capture_alloc(struct ymf_unit *unit, int *pbank);
 static int ymf_playback_prepare(struct ymf_state *state);
 static int ymf_capture_prepare(struct ymf_state *state);
 static struct ymf_state *ymf_state_alloc(ymfpci_t *unit);
 
+static void ymfpci_aclink_reset(struct pci_dev * pci);
+static void ymfpci_disable_dsp(ymfpci_t *unit);
+static void ymfpci_download_image(ymfpci_t *codec);
+static void ymf_memload(ymfpci_t *unit);
+
 static LIST_HEAD(ymf_devs);
 
 /*
@@ -330,7 +333,7 @@
spin_lock_irqsave(&state->unit->reg_lock, flags);
dmabuf->hwptr = dmabuf->swptr = 0;
dmabuf->total_bytes = 0;
-   dmabuf->count = dmabuf->error = 0;
+   dmabuf->count = 0;
spin_unlock_irqrestore(&state->unit->reg_lock, flags);
 
/* allocate DMA buffer if not allocated yet */
@@ -810,8 +813,6 @@
end >>= 1;
if (w_16)
end >>= 1;
-/* P3 */ // printk("ymf_pcm_init_voice: %d: Rate %d Format 0x%08x Delta 0x%x End 
0x%x\n",
-//  voice->number, rate, format, delta, end);
for (nbank = 0; nbank < 2; nbank++) {
bank = &voice->bank[nbank];
bank->format = format;
@@ -907,7 +908,7 @@
 
if ((err = ymfpci_pcm_voice_alloc(ypcm, state->format.voices)) < 0) {
/* Somebody started 32 mpg123's in parallel? */
-   /* P3 */ printk("ymfpci%d: cannot allocate voice\n",
+   printk(KERN_INFO "ymfpci%d: cannot allocate voice\n",
state->unit->dev_audio);
return err;
}
@@ -1178,6 +1179,7 @@
 {
struct ymf_state *state = (struct ymf_state *)file->private_data;
struct ymf_dmabuf *dmabuf = &state->rpcm.dmabuf;
+   struct ymf_unit *unit = state->unit;
DECLARE_WAITQUEUE(waita, current);
ssize_t ret;
unsigned long flags;
@@ -1190,18 +1192,26 @@
return -ENXIO;
if (!dmabuf->ready && (ret = prog_dmabuf(state, 1)))
return ret;
-   if (!access_ok(VERIFY_WRITE, buffer, count))
-   return -EFAULT;
ret = 0;
 
add_wait_queue(&dmabuf->wait, &waita);
while (count > 0) {
-   spin_lock_irqsave(&state->unit->reg_lock, flags);
+   spin_lock_irqsave(&unit->reg_lock, flags);
+   if (unit->suspended) {
+   spin_unlock_irqrestore(&unit->reg_lock, flags);
+   set_current_state(TASK_INTERRUPTIBLE);
+   schedule();
+   if (signal_pending(current)) {
+   if (!ret) ret = -EAGAIN;
+   break;
+   }
+   continue;
+   }
swptr = dmabuf->swptr;
cnt = dmabuf->dmasize - swptr;
if (dmabuf->count < cnt)
cnt = dmabuf->count;
-   spin_unlock_irqrestore(&state->unit->reg_lock, flags);
+   spin_unlock_irqrestore(&unit->reg_lock, flags);
 
if (cnt > count)
cnt = count;
@@ -1240,7 +1250,7 @@
}
spin_unlock_irqrestore(&state->unit->reg_lock, flags);
if (signal_pending(current)) {
-   ret = ret ? ret : -ERESTARTSYS;
+   if (!ret) ret = 

Re: Linux 2.4.4-ac17

[Jaswinder Singh]

Dear Mike ,

>
> This one I tested with memleak.  It wasn't a leak, it was dcache
> growth.  Under vm stress, it shrank down fine.
>

It will depends upon lot of thing :-
1.What is your size of ramfs ,
2. Are you using any harddisk ,
3. How many many files are you creating ,
4. How frequently you are making files .
5. What are the size of your files ?

In my case , my ramfs is of 14 MB , using no hard-disk , i am continously
making and deleting files of 4 K size , my Machine hangs within 5 minutes ,
by saying no memory left.

Please tell me about your system and what you are doing on it ?

Thanks ,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.



> -Mike
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[CHECKER] Web interface to database

[Andy Chou]

We've made the database of errors found as part of the MC project
online.  Some of the cool features are:

- Over 3500 errors (not necessarily unique across versions)
- Results for 12 checkers, across 18 Linux versions from 1.0 to 2.4.4
- Keyword search on the file, function, or cause of an error
- Default sorting of results by severity of bug/ease of diagnosis
- Sorting results by file, function, and other fields
- Filter out error reports that also exist in older versions
- Links to annotated source code for each error

The URL:

http://hands.stanford.edu/linux


Some disclaimers:

1) We're improving the site and updating the database constantly, so it
might not always be accessible, or it might show incomplete data at times.

2) We're looking for feedback on how to improve things.  Please send
suggestions to [EMAIL PROTECTED]  Also, please email us if you fix any
of the errors, or can show that they are not errors.

3) Not all checker results are available for all versions.  We load the
database asynchronously with the bug reports sent to LKML.

4) All queries are logged.  We are doing this so we can analyze what
errors people are interested in, and also as a precaution in case there
are any attacks.

5) Queries that return a large number of results will take a while to run.  
Please be patient, or restrict the scope of queries.

6) See the FAQ link for answers to some other questions.  The
documentation, including the description of the checkers, is under
construction.


Enjoy,
-Andy Chou

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fsm.c - null ptr fixes for 2.4.4

[Praveen Srinivasan]

We tried to minimize the amount of changes we made; your patch is far more 
extensive. As this is not our code, we felt it would be a bad idea to make 
changes to the underlying structure.

Praveen Srinivasan and Frederick Akalin

Kai Germaschewski wrote:

> On Thu, 24 May 2001, Praveen Srinivasan wrote:
> 
>> Using the Stanford checker, we searched for null-pointer bugs in the
>> linux kernel code. This patch fixes numerous unchecked pointers in the
>> ISDN hisax card driver (fsm.c).
> 
> Is one numerous? Anyway, thanks for you effort. Your fix is not
> correct though, because it replaces the bug with another one.
> 
> In case the allocation fails, the current code will oops directly, so it's
> quite easy to track down what went wrong. After applying your patch, the
> code will still oops, but at a later time, when one of the not correctly
> initialized state machines is actually used, so the problem is harder to
> track.
> 
> The correct way to fix the problem is something along the lines of the
> appended patch. You need to notify the caller of the allocation failure
> and handle it correctly.
> 
> Thanks for your work, I'll take care of submitting the right fix to Linus.
> 
> --Kai
> 
> Index: callc.c
> ===
> RCS file: /scratch/kai/cvsroot/linux_2_4/drivers/isdn/hisax/callc.c,v
> retrieving revision 1.1.1.2
> diff -u -r1.1.1.2 callc.c
> --- callc.c   2001/04/23 22:51:03 1.1.1.2
> +++ callc.c   2001/05/24 16:04:16
> @@ -850,14 +850,14 @@
> 
>  #define FNCOUNT (sizeof(fnlist)/sizeof(struct FsmNode))
> 
> -void __init
> +int __init
>  CallcNew(void)
>  {
>  callcfsm.state_count = STATE_COUNT;
>  callcfsm.event_count = EVENT_COUNT;
>  callcfsm.strEvent = strEvent;
>  callcfsm.strState = strState;
> - FsmNew(&callcfsm, fnlist, FNCOUNT);
> + return FsmNew(&callcfsm, fnlist, FNCOUNT);
>  }
> 
>  void
> Index: config.c
> ===
> RCS file: /scratch/kai/cvsroot/linux_2_4/drivers/isdn/hisax/config.c,v
> retrieving revision 1.1.1.4.32.1
> diff -u -r1.1.1.4.32.1 config.c
> --- config.c  2001/05/24 07:52:56 1.1.1.4.32.1
> +++ config.c  2001/05/24 16:17:00
> @@ -1332,18 +1332,28 @@
> 
>  static int __init HiSax_init(void)
>  {
> - int i;
> + int i, retval;
>  #ifdef MODULE
>  int j;
>  int nzproto = 0;
>  #endif
> 
>  HiSaxVersion();
> - CallcNew();
> - Isdnl3New();
> - Isdnl2New();
> - TeiNew();
> - Isdnl1New();
> + retval = CallcNew();
> + if (retval)
> + goto out;
> + retval = Isdnl3New();
> + if (retval)
> + goto out_callc;
> + retval = Isdnl2New();
> + if (retval)
> + goto out_isdnl3;
> + retval = TeiNew();
> + if (retval)
> + goto out_isdnl2;
> + retval = Isdnl1New();
> + if (retval)
> + goto out_tei;
> 
>  #ifdef MODULE
>  if (!type[0]) {
> @@ -1490,17 +1500,26 @@
>  printk(KERN_DEBUG "HiSax: Total %d card%s defined\n",
>  nrcards, (nrcards > 1) ? "s" : "");
> 
> - if (HiSax_inithardware(NULL)) {
> - /* Install only, if at least one card found */
> - return (0);
> - } else {
> - Isdnl1Free();
> - TeiFree();
> - Isdnl2Free();
> - Isdnl3Free();
> - CallcFree();
> - return -EIO;
> + /* Install only, if at least one card found */
> + if (!HiSax_inithardware(NULL)) {
> + retval = -EIO;
> + goto out_isdnl1;
>  }
> +
> + return 0;
> +
> + out_isdnl1:
> + Isdnl1Free();
> + out_tei:
> + TeiFree();
> + out_isdnl2:
> + Isdnl2Free();
> + out_isdnl3:
> + Isdnl3Free();
> + out_callc:
> + CallcFree();
> + out:
> + return retval;
>  }
> 
>  static void __exit HiSax_exit(void)
> Index: fsm.c
> ===
> RCS file: /scratch/kai/cvsroot/linux_2_4/drivers/isdn/hisax/fsm.c,v
> retrieving revision 1.1.1.2
> diff -u -r1.1.1.2 fsm.c
> --- fsm.c 2001/04/23 22:51:00 1.1.1.2
> +++ fsm.c 2001/05/24 16:03:22
> @@ -15,13 +15,16 @@
> 
>  #define FSM_TIMER_DEBUG 0
> 
> -void __init
> +int __init
>  FsmNew(struct Fsm *fsm, struct FsmNode *fnlist, int fncount)
>  {
>  int i;
> 
>  fsm->jumpmatrix = (FSMFNPTR *)
>  kmalloc(sizeof (FSMFNPTR) * fsm->state_count * fsm->event_count,
>  GFP_KERNEL);
> + if (!fsm->jumpmatrix)
> + return -ENOMEM;
> +
>  memset(fsm->jumpmatrix, 0, sizeof (FSMFNPTR) * fsm->state_count *
>  fsm->event_count);
> 
>  for (i = 0; i < fncount; i++)
> @@ -32,6 +35,7 @@
>  } else
>  fsm->jumpmatrix[fsm->state_count * fnlist[i].event +
>  fnlist[i].state] = (FSMFNPTR) fnlist[i].routine;
> + return 0;
>  }
> 
>  void
> Index: hisax.h
> ===
> RCS file: /scratch/kai/cvsroot/linux_2_4/drivers/isdn/hisax/hisax.h,v
> retrieving revision 1.1.1.4
> diff -u 

Re: Busy on BLKFLSBUF w/initrd

[Scott Murray]

On Thu, 24 May 2001, Maciek Nowacki wrote:

> Problem seems to be solved. Here is what I did, for anyone who is interested
> in using a loopback file on a local disk as root:
[snip recipe]
> This method depends on the change_root() mechanism which I had assumed is
> becoming obsolete. It works, and there is no need to mess with
> /proc/sys/kernel/real_root_dev if the root is specified on the command line.
> Trying to use only pivot_root did not work as /dev/rd/0 could never be
> flushed (see previous messages in this thread).

I was having similiar problems a few months back.  I was also trying
to pivot_root out of an initial ramdisk and then unmount it.  I got it
working, but kept forgetting to post one of the fixes that I found
necessary to make it work when using auto-mounted devfs.

Here it is (exported from BitKeeper, hence the a and b):

diff -Nru a/init/main.c b/init/main.c
--- a/init/main.c   Fri May 25 00:31:25 2001
+++ b/init/main.c   Fri May 25 00:31:25 2001
@@ -273,6 +273,9 @@
 #ifdef CONFIG_NFTL
{ "nftla", 0x5d00 },
 #endif
+#ifdef CONFIG_DEVFS_MOUNT
+   { "rd/", 0x0100 },
+#endif
{ NULL, 0 }
 };

What this does is make /dev/rd/* parseable by name_to_kdev_t, with
the result that ROOT_DEV gets set correctly in root_dev_setup and
the initrd logic at the bottom of do_basic_setup doesn't automatically
trigger the change_root.  The same effect can be achieved by setting
real_root_dev in proc in your ramdisk, but since that's not required
for non-devfs ramdisks, it takes some digging for the uninitiated to
figure out why things don't work.

With this fix and the fix for the missing bldev_put in drivers/block/rd.c
(which has been in Alan's tree for ages), the pivot_root instructions
given in the file Documentation/initrd.txt have been working fine for me.

Scott


-- 
=
Scott Murrayemail: [EMAIL PROTECTED]
http://www.spiteful.org (coming soon) ICQ: 10602428
-
 "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness"


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Patch for PM in ymfpci (against 2.4.5-pre3)

[Jeff Garzik]

Looks ok, only a small nit:  an include and 'pmdev' are left over from
the older PM implementation, and can be removed.
-- 
Jeff Garzik  | "Are you the police?"
Building 1024| "No, ma'am.  We're musicians."
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4 freezes on VIA KT133

[Albert D. Cahalan]

Mark Hahn writes:

> contrary to the implication here, I don't believe there is any *general*
> problem with Linux/VIA/AMD stability.  there are well-known issues
> with specific items (VIA 686b, for instance), but VIA/AMD hardware
> is quite suitable for servers.

VIA hardware is not suitable for anything until we _know_ the
truth about what is wrong. VIA is hiding something big.

Simple fix:

0. get lawyer
1. start class-action lawsuit
2. do discovery
3. unseal court records
4. done -- you may drop the case if not settled already

Well, something like that... not a lawyer, etc.
If you have the time and money, go for it. Have fun.

Creative Labs ought to toast VIA over blaming the sound card. :-)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH: "Kernel Insider" (security optimization)

[David Wagner]

>Its a linux kernel modification, that allows to decide wich uid, pid or
>file can open a tcp socket in listening state.

- Putting access control on listen() [rather than socket()/bind()]
  seems like a really bad idea.  In particular, in some cases one can
  bind to a port and receive messages on it without ever calling listen(),
  if I am not mistaken.

- The use of sock_i_uid(sock) seems poorly chosen; if sock->socket==NULL,
  then your module will mistakenly think that the action was requested by
  uid 0.  In general, the return value from sock_i_uid() cannot be trusted
  for permission checks for several reasons.  Why don't you simply use
  current->euid for your permission checks?

- Checking pid's doesn't seem like a good idea.  If a process listed in
  allowed_pids dies, then some other malicious process can wrap the pid
  space and take over that trusted pid, thereby subverting your access
  control policy.

- Are you aware of previous work on this subject?  In particular, you
  might enjoy checking out the Janus project, which is a much more general
  implementation of this idea: http://www.cs.berkeley.edu/~daw/janus/

- You should really join the mailing list hosted by Crispin Cowan working
  to develop kernel hooks for this sort of kernel security modification.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Copyright for drivers- two SCSI HBA drivers

[Matthew Jacob]

> As a user of hardware which requires firmware like this, I have mixed
> feelings, but feel strongly that requirements of the GPL clearly
> override any measure of convenience. Are there any plans to remove the
> binary-only firmware from the kernel, and/or eventually from the Linux
> source distribution? I am not refering to this USB driver
> specifically, but rather the general occurance of firmware embedded in
> Linux device trivers.
> 

In the specific instances that I know about, the f/w for the older Qlogic SCSI
cards (the drivers *not* supplied by vendors) for qlogicisp (qlogicisp_asm.c)
and qlogicpti (qlogicisp_pti.c) is in the Linux source *and has been for
years) with no copyright attribution whatsoever. qlogicfc has the BSD style
copyright that I partly, but mostly Theo Deraadt of OpenBSD, managed to beat
QLogic into doing.

Versions of f/w for qlogicisp && qlogicpti can easily also be had with the BSD
licence- check any *BSD distribution, or pick 'em up via bitkeeper from my
site.


-matt


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Re: How to add ntfs support]

[Blesson Paul]

Hi Anton
  So you are constructing a improved NTFS file driver. So when you
have to check your written codes of file driver, will u recompile the whole
kernel ? . That is what I am asking. I am in a way to build a new file system.
I took NTFS as a sample one. I thought , I will first try to compile and make
it run. 
Thanks in advance
by
   Blesson Paul


Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
At 09:20 24/05/2001, Blesson Paul wrote:
>  I have redhat6.2. I have to add ntfs support to it(defaultly
>it do not have). I know to do it by changing the configuration and
>recompiling the whole kernel. I want to know , is there any method to
>register ntfs file system without recompiling the whole kernel

No, it is not possible to not recompile the kernel if NTFS was configured. 
You might see some very strange effects if you try... What is your problem? 
Just recompile the kernel. Remember NTFS should be used read-only as write 
support is broken.

I have a much improved NTFS driver but my Sourceforge linux-NTFS CVS is 
down (for a week now!) so I can't release it at the moment. )-:

Anton


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sf.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/




Get free email and a permanent address at http://www.netaddress.com/?N=1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Aaron Lehmann]

This message sparked a long thread on the debian-legal mailing list,
which is long since dead. I am personally very curious about whether
this has been resolved upstream. I consider it a very important issue,
which is why I asked for RMS' opinion. He said that what is being done
is clearly not "mere aggregation", and that such firmware should be
moved out of the kernel (and even the tarball) to stop violating the
GPL and make Linux be free software.

As a user of hardware which requires firmware like this, I have mixed
feelings, but feel strongly that requirements of the GPL clearly
override any measure of convenience. Are there any plans to remove the
binary-only firmware from the kernel, and/or eventually from the Linux
source distribution? I am not refering to this USB driver
specifically, but rather the general occurance of firmware embedded in
Linux device trivers.

- Forwarded message from "Adam J. Richter" <[EMAIL PROTECTED]> -

From: "Adam J. Richter" <[EMAIL PROTECTED]>
Date: Sun, 22 Apr 2001 12:53:48 -0700
To: [EMAIL PROTECTED]
Subject: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h


Linus's Linux kernel releases from 2.3.50 through the latest
test release (2.4.4-pre6) contain GPL-incompatible "firmware" images
for "EZUSB" devices in linux/drivers/usb/serial/keyspan*fw.h, which
are #included into drivers which contain GPL'ed code, even when compiled
as modules.

I believe this infringinges the copyrights of the authors
of the code used in these drivers who released their code under GPL.
Alan Cox, has gone on a campaign claiming that this is "mere aggregation"
and insists that I bring in the lawyers to prove him otherwise.  I
really do not want to take this step, but he is forcing my hand.  Note
that Yggdrasil is a copyright owner in this case.

To simplify removal of the offending code, I have provided
a separate user level facility that can use the USB "hot plugging"
system to automatically load that "firmware" or any other.  The USB serial
maintainer already plans to switch to it in 2.5, and has tested it and
verified that it works.  The software and a kernel patch to remove
the offending code is FTPable from
ftp://ftp.yggdrasil.com/pub/dist/device_control/ezusb/.  The kernel patch
also moves the "whiteheat" code loading into the same user space utility,
just for technical reasons, even though that code can apparently be legally
included in the kernel.  Note that even without this software, the EZUSB
firmware can apparently be loaded by other facilities or from other
operating systems.

Here is what people involved in Debian should do:

1. Make sure that no Debian release or snapshot that
   includes a kernel from 2.3.50 through the current
   one (don't know if there are any yet) includes
   linux/drivers/usb/serial/keyspan*fw.h.  By the way,
   even if there were no legal liability, these files
   could not be in the "free" part of Debian, if I
   read the Debian Free Software "Guidelines" correctly.

2. Possibly include the user level software FTPable from
   Yggdrasil, although be warned that that code will probably
   be replaced in the near future to use an input file
   format more compatible with other development tools used
   for EZUSB 8051 microcontroller software development.

Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /  San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l   United States of America
fax +1 408 261-6631  "Free Software For The Rest Of Us."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



- End forwarded message -

-- 
#define m(i)(x[i]^s[i+84])<< /* I do not condone improper use of this code */
unsigned char x[5],y,s[2048];main(n){for(read(0,x,5);read(0,s,n=2048);write(1,s
,n))if(s[y=s[13]%8+20]/16%4==1){int i=m(1)17^256+m(0)8,k=m(2)0,j=m(4)17^m(3)9^k
*2-k%8^8,a=0,c=26;for(s[y]-=16;--c;j*=2)a=a*2^i&1,i=i/2^j&1<<24;for(j=127;++jy)c+=y=i^i/8^i>>4^i>>12,i=i>>8^y<<17,a^=a>>14,y=a^a*8^a<<6,a=a>>8^y<<9,k=s
[j],k="7Wo~'G_\216"[k&7]+2^"cr3sfw6v;*k+>/n."[k>>4]*2^k*257/8,s[j]=k^(k&k*2&34)
*6^c+~y;}}//Please join us in civil disobedience and distribute DeCSS(or efdtt!)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Patch for PM in ymfpci (against 2.4.5-pre3)

[Pete Zaitcev]

I am sorry to be a poor maintainer, people were sending me patches
to enable PM support for a long time. I took most of this from
Paul Stewart, fixed a buglet, and factored common parts into
a function.

-- Pete

* PM support for suspend/resume (without pm_register, proper PCI API);
* Killed some P3's;
* Removed unused unit.error;
* Removed access_ok (we do copy_[to|from]_user);

diff -ur -X dontdiff linux-2.4.5-pre3/drivers/sound/ymfpci.c 
linux-2.4.5-pre3-p3/drivers/sound/ymfpci.c
--- linux-2.4.5-pre3/drivers/sound/ymfpci.c Fri May 18 14:09:46 2001
+++ linux-2.4.5-pre3-p3/drivers/sound/ymfpci.c  Thu May 24 20:58:27 2001
@@ -23,10 +23,8 @@
  *   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  *
  * TODO:
- *  - Use P44Slot for 44.1 playback.
+ *  - Use P44Slot for 44.1 playback (beware of idle buzzing in P44Slot).
  *  - 96KHz playback for DVD - use pitch of 2.0.
- *  - uLaw for Sun apps.
- * : Alan says firmly "no software format conversion in kernel".
  *  - Retain DMA buffer on close, do not wait the end of frame.
  *  - Cleanup
  *  ? underused structure members
@@ -55,6 +53,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -66,14 +65,19 @@
 #endif
 #include "ymfpci.h"
 
-static int ymf_playback_trigger(ymfpci_t *codec, struct ymf_pcm *ypcm, int cmd);
+static int ymf_playback_trigger(ymfpci_t *unit, struct ymf_pcm *ypcm, int cmd);
 static void ymf_capture_trigger(ymfpci_t *unit, struct ymf_pcm *ypcm, int cmd);
-static void ymfpci_voice_free(ymfpci_t *codec, ymfpci_voice_t *pvoice);
+static void ymfpci_voice_free(ymfpci_t *unit, ymfpci_voice_t *pvoice);
 static int ymf_capture_alloc(struct ymf_unit *unit, int *pbank);
 static int ymf_playback_prepare(struct ymf_state *state);
 static int ymf_capture_prepare(struct ymf_state *state);
 static struct ymf_state *ymf_state_alloc(ymfpci_t *unit);
 
+static void ymfpci_aclink_reset(struct pci_dev * pci);
+static void ymfpci_disable_dsp(ymfpci_t *unit);
+static void ymfpci_download_image(ymfpci_t *codec);
+static void ymf_memload(ymfpci_t *unit);
+
 static LIST_HEAD(ymf_devs);
 
 /*
@@ -330,7 +334,7 @@
spin_lock_irqsave(&state->unit->reg_lock, flags);
dmabuf->hwptr = dmabuf->swptr = 0;
dmabuf->total_bytes = 0;
-   dmabuf->count = dmabuf->error = 0;
+   dmabuf->count = 0;
spin_unlock_irqrestore(&state->unit->reg_lock, flags);
 
/* allocate DMA buffer if not allocated yet */
@@ -810,8 +814,6 @@
end >>= 1;
if (w_16)
end >>= 1;
-/* P3 */ // printk("ymf_pcm_init_voice: %d: Rate %d Format 0x%08x Delta 0x%x End 
0x%x\n",
-//  voice->number, rate, format, delta, end);
for (nbank = 0; nbank < 2; nbank++) {
bank = &voice->bank[nbank];
bank->format = format;
@@ -907,7 +909,7 @@
 
if ((err = ymfpci_pcm_voice_alloc(ypcm, state->format.voices)) < 0) {
/* Somebody started 32 mpg123's in parallel? */
-   /* P3 */ printk("ymfpci%d: cannot allocate voice\n",
+   printk(KERN_INFO "ymfpci%d: cannot allocate voice\n",
state->unit->dev_audio);
return err;
}
@@ -1178,6 +1180,7 @@
 {
struct ymf_state *state = (struct ymf_state *)file->private_data;
struct ymf_dmabuf *dmabuf = &state->rpcm.dmabuf;
+   struct ymf_unit *unit = state->unit;
DECLARE_WAITQUEUE(waita, current);
ssize_t ret;
unsigned long flags;
@@ -1190,18 +1193,26 @@
return -ENXIO;
if (!dmabuf->ready && (ret = prog_dmabuf(state, 1)))
return ret;
-   if (!access_ok(VERIFY_WRITE, buffer, count))
-   return -EFAULT;
ret = 0;
 
add_wait_queue(&dmabuf->wait, &waita);
while (count > 0) {
-   spin_lock_irqsave(&state->unit->reg_lock, flags);
+   spin_lock_irqsave(&unit->reg_lock, flags);
+   if (unit->suspended) {
+   spin_unlock_irqrestore(&unit->reg_lock, flags);
+   set_current_state(TASK_INTERRUPTIBLE);
+   schedule();
+   if (signal_pending(current)) {
+   if (!ret) ret = -EAGAIN;
+   break;
+   }
+   continue;
+   }
swptr = dmabuf->swptr;
cnt = dmabuf->dmasize - swptr;
if (dmabuf->count < cnt)
cnt = dmabuf->count;
-   spin_unlock_irqrestore(&state->unit->reg_lock, flags);
+   spin_unlock_irqrestore(&unit->reg_lock, flags);
 
if (cnt > count)
cnt = count;
@@ -1240,7 +1254,7 @@
}
spin_unlock_irqrestore(&state->unit->reg_lock, flags);
if (signal_pending(current)) {
-   ret = ret ? ret : -

Re: Big-ish SCSI disks

[Scott Murray]

On Fri, 25 May 2001, Greg Johnson wrote:

> Hi kernel poeple,
>
> Can anyone out there say for certain that 76GB SCSI disks should
> just work with kernel versions 2.2 and/or 2.4? We need to get some
> big disk space and have heard reports of problems with disks
> bigger than 30GB under linux.

I set up a machine at work a few months ago with two Seagate 73GB
Ultra160 drives (model ST173404LW) using the Adaptec AIC-7899 adapter
on board a ServerWorks LE chipset based motherboard.  Everything has
been working fine using the stock RedHat 7.0 2.2.16-22smp kernel.  I
also played with some 2.4.1-ac kernels to try out ReiserFS, and also
had no problems using the disks.

Scott


-- 
=
Scott Murrayemail: [EMAIL PROTECTED]
http://www.spiteful.org (coming soon) ICQ: 10602428
-
 "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness"

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

[Dunlap, Randy]

> From: Andrew Morton [mailto:[EMAIL PROTECTED]]
> 
> Andreas Dilger wrote:
> > 
> > On a side note, does anyone know if the kernel does checking if the
> > stack overflowed at any time?
> 
> There's a little bit of code in show_task() which calculates
> how close this task ever got to overrunning its kernel stack:
> 
> {
> unsigned long * n = (unsigned long *) (p+1);
> while (!*n)
> n++;
> free = (unsigned long) n - (unsigned long)(p+1);
> }
> printk("%5lu %5d %6d ", free, p->pid, p->p_pptr->pid);
> 
> SYSRQ-T will trigger this.
> 
> However it doesn't work, because do_fork() doesn't zero
> out the stack pages when they're created.

If do_fork() performance is an issue, at least clearing the stack
pages as a build option would be nice for some of us.

~Randy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

[Andrew Morton]

Andreas Dilger wrote:
> 
> Dawson Engler writes:
> > Here are 37 errors where variables >= 1024 bytes are allocated on a
> > function's stack.
> 
> First of all, thanks very much for the work you are doing.  It really
> is useful, and a good way to catch those very rare error cases that
> would not otherwise be fixed.
> 
> I'm curious about this stack checker.  Does it check for a single
> stack allocation >= 1024 bytes, or does it also check for several
> individual, smaller allocations which total >= 1024 bytes inside
> a single function?  That would be equally useful.
> 
> On a side note, does anyone know if the kernel does checking if the
> stack overflowed at any time?

There's a little bit of code in show_task() which calculates
how close this task ever got to overrunning its kernel stack:

{
unsigned long * n = (unsigned long *) (p+1);
while (!*n)
n++;
free = (unsigned long) n - (unsigned long)(p+1);
}
printk("%5lu %5d %6d ", free, p->pid, p->p_pptr->pid);

SYSRQ-T will trigger this.

However it doesn't work, because do_fork() doesn't zero
out the stack pages when they're created.

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PATCH: "Kernel Insider" (security optimization)

[bruj0]

Hello, i wrote a modification for kernels 2.4.x, actually it can be
lodaded as a module and its not intrusive. I would love to get you opinions,
critics, flames about it. Plase CC: me becouse im not in the list. thanx
The whole package with a intructions is at
http://securityportal.com.ar/files/insider-1.6.tar.gz

This is the description:
INSIDER
---
Its a linux kernel modification, that allows to decide wich uid, pid or
file can open a tcp socket in listening state.
The changes to the kernel are really insignificant, only to export 2
variables.
When  a program tries to open a port it first makes a md5 checksum
of the file and compares it with the config list then it compares the user
id and finally the pid.
The policy is to "DENY" everything that is not in the allowed list.

Bruj0

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

[Dawson Engler]

> > Ah, nice --- I keep meaning to tell the checker to demote its warning
> > about NULL bugs or large stack vars in __init routines and/or routines
> > that have the substring "init" in them ;-)
> 
> Please, don't. These functions are often used from/as init_module(),
> so they must handle the case when allocation fails. They can be
> called long after the boot.

I meant "demote"  to mean "reducing the ranking of these errors during
sorting" rather than "eliminate from the error logs".  


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

[Alexander Viro]

On Thu, 24 May 2001, Dawson Engler wrote:

> > check_nmi_watchdog() is __init and we know exactly when it's called.
> > The interesting cases (SMP kernel, since for UP NR_CPUS==1) are:
> 
> Ah, nice --- I keep meaning to tell the checker to demote its warning
> about NULL bugs or large stack vars in __init routines and/or routines
> that have the substring "init" in them ;-)

Please, don't. These functions are often used from/as init_module(),
so they must handle the case when allocation fails. They can be
called long after the boot.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] error path memory leaks in 2.4.4 and 2.4.4-ac8

[Dawson Engler]

> Disagree
> 
> > ahc = ahc_alloc(NULL, name);
> 
> ahc_alloc frees name on error

Wow.  That would have been a really nasty "fix."  Sorry about that -- the
name "ahc_alloc" is a little counter-intuitive ;-)

Thanks for the quick feedback.

Dawson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

[Dawson Engler]

> check_nmi_watchdog() is __init and we know exactly when it's called.
> The interesting cases (SMP kernel, since for UP NR_CPUS==1) are:

Ah, nice --- I keep meaning to tell the checker to demote its warning
about NULL bugs or large stack vars in __init routines and/or routines
that have the substring "init" in them ;-)


> IMHO the checker tool should take call paths into consideration
> when trying to detect stack overflow problems. Does it do that?
> (I.e. is it polyvariant or monovariant?)

The var checker is more "really stupid".  It just does a flow
insensitive pass looking for big variables.  I could make it follow
call chains without too much work (other checkers do do this.)

> I could write a patch to make 'tmp' __initdata instead, which would
> silence the checker tool, but I don't really want to do that unless
> someone can convince me that there is a real problem here.

No need.  Once it's marked as an FP the checker won't warn about it
anymore.

Thanks for post-mortem.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] memory leak in scsi_proc.c

[Mike Brown]

Hi,

If someone writes to a scsi adapter's /proc entry and that scsi adapter
has not defined a proc_info() entry point, proc_scsi_write() will leak a
page.  Furthermore, no sense asking for a page if said proc_info() entry
point does not exist.  This patch fixes the above problem and patches
cleanly against 2.4.4

--- drivers/scsi/scsi_proc.c.orig   Fri Feb  9 14:30:23 2001
+++ drivers/scsi/scsi_proc.cThu May 24 22:26:59 2001
@@ -99,6 +99,9 @@
char * page;
char *start;
 
+   if (hpnt->hostt->proc_info == NULL)
+   return -ENOSYS;
+
if (count > PROC_BLOCK_SIZE)
return -EOVERFLOW;
 
@@ -106,12 +109,10 @@
return -ENOMEM;
copy_from_user(page, buf, count);
 
-   if (hpnt->hostt->proc_info == NULL)
-   ret = -ENOSYS;
-   else
-   ret = hpnt->hostt->proc_info(page, &start, 0, count,
-   hpnt->host_no, 1);
+ret = hpnt->hostt->proc_info(page, &start, 0, count,
+ hpnt->host_no, 1);
free_page((ulong) page);
+
return(ret);
 }
 

-Michael F. Brown, UMass Lowell Computer Science

email:  [EMAIL PROTECTED]

"In theory, there is no difference between theory and practice,
 but in practice, there is."   - Jan L.A. van de Snepscheut

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] warning fixes for 2.4.5pre5

[Rich Baum]

Here is a patch that fixes warnings when using gcc 3.0 snapshots to compile 
the kernel.  Most of these warnings are for labels at the end of compound 
statements and extra tokens at the end of #endifs.  The patch for 
linux/drivers/usb/pwc-uncompress.c adds includes to fix warnings where 
kmalloc(), kfree(), and  EXPORT_SYMBOL_NONVERS() implicity declared.

This patch has been tested and the code does compile. 

Rich

diff -urN -X /linux/dontdiff linux/arch/i386/math-emu/fpu_trig.c 
rb/arch/i386/math-emu/fpu_trig.c
--- linux/arch/i386/math-emu/fpu_trig.c Fri Apr  6 12:42:47 2001
+++ rb/arch/i386/math-emu/fpu_trig.cTue May 22 16:44:57 2001
@@ -1543,6 +1543,7 @@
  EXCEPTION(EX_INTERNAL | 0x116);
  return;
 #endif /* PARANOID */
+ return;   
}
 }
   else if ( (st0_tag == TAG_Valid) || (st0_tag == TW_Denormal) )
diff -urN -X /linux/dontdiff linux/drivers/atm/fore200e.c 
rb/drivers/atm/fore200e.c
--- linux/drivers/atm/fore200e.cFri Feb  9 14:30:22 2001
+++ rb/drivers/atm/fore200e.c   Tue May 22 16:44:57 2001
@@ -439,6 +439,7 @@
 
 case FORE200E_STATE_BLANK:
/* nothing to do for that state */
+   break;
 }
 }
 
diff -urN -X /linux/dontdiff linux/drivers/cdrom/sbpcd.c 
rb/drivers/cdrom/sbpcd.c
--- linux/drivers/cdrom/sbpcd.c Fri Apr  6 12:42:55 2001
+++ rb/drivers/cdrom/sbpcd.cThu May 24 19:45:59 2001
@@ -1118,7 +1118,7 @@
return (0);
 }
 /*==*
/
-#endif 0
+#endif /* 0 */
 /*==*
/
 static int ResponseInfo(void)
 {
diff -urN -X /linux/dontdiff linux/drivers/media/video/tuner.c 
rb/drivers/media/video/tuner.c
--- linux/drivers/media/video/tuner.c   Mon Feb 19 17:43:36 2001
+++ rb/drivers/media/video/tuner.c  Tue May 22 16:45:02 2001
@@ -558,6 +558,7 @@
 #endif
default:
/* nothing */
+   break;
}

return 0;
diff -urN -X /linux/dontdiff linux/drivers/net/tokenring/ibmtr.c 
rb/drivers/net/tokenring/ibmtr.c
--- linux/drivers/net/tokenring/ibmtr.c Tue Mar 20 15:05:00 2001
+++ rb/drivers/net/tokenring/ibmtr.cTue May 22 16:45:03 2001
@@ -1185,7 +1185,7 @@
isa_writeb(~CMD_IN_SRB, ti->mmio + ACA_OFFSET + 
ACA_RESET + ISRA_ODD);
isa_writeb(~SRB_RESP_INT, ti->mmio + ACA_OFFSET + 
ACA_RESET + ISRP_ODD);
 
- skip_reset:
+ skip_reset:;
} /* SRB response */
 
if (status & ASB_FREE_INT) { /* ASB response */
diff -urN -X /linux/dontdiff linux/drivers/net/wan/hdlc.c 
rb/drivers/net/wan/hdlc.c
--- linux/drivers/net/wan/hdlc.cWed Apr 18 16:40:07 2001
+++ rb/drivers/net/wan/hdlc.c   Tue May 22 16:45:03 2001
@@ -1082,7 +1082,9 @@
}
break;
 
-   default:/* to be defined */
+   default:
+   /* to be defined */
+   break;
}
 
dev_kfree_skb(skb);
diff -urN -X /linux/dontdiff linux/drivers/net/wan/sdla_fr.c 
rb/drivers/net/wan/sdla_fr.c
--- linux/drivers/net/wan/sdla_fr.c Fri Apr 20 13:54:22 2001
+++ rb/drivers/net/wan/sdla_fr.cTue May 22 16:45:03 2001
@@ -4435,7 +4435,8 @@
trigger_fr_poll(dev);

break;
-   default:  // ARP's and RARP's -- Shouldn't happen.
+   default:
+   break; // ARP's and RARP's -- Shouldn't happen.
}
 
return 0;   
diff -urN -X /linux/dontdiff linux/drivers/net/wan/sdla_x25.c 
rb/drivers/net/wan/sdla_x25.c
--- linux/drivers/net/wan/sdla_x25.cFri Apr 20 13:54:22 2001
+++ rb/drivers/net/wan/sdla_x25.c   Tue May 22 16:45:03 2001
@@ -3108,7 +3108,7 @@
case 0x08:  /* modem failure */
 #ifndef MODEM_NOT_LOG
printk(KERN_INFO "%s: modem failure!\n", card->devname);
-#endif MODEM_NOT_LOG
+#endif /* MODEM_NOT_LOG */
api_oob_event(card,mb);
break;
 
diff -urN -X /linux/dontdiff linux/drivers/scsi/NCR53c406a.c 
rb/drivers/scsi/NCR53c406a.c
--- linux/drivers/scsi/NCR53c406a.c Thu May 24 19:35:06 2001
+++ rb/drivers/scsi/NCR53c406a.cTue May 22 16:45:03 2001
@@ -221,7 +221,7 @@
 (void *)0xc8000
 };
 #define ADDRESS_COUNT (sizeof( addresses ) / sizeof( unsigned ))
-#endif USE_BIOS
+#endif /* USE_BIOS */
   
 /* possible i/o port addresses */
 static unsigned short ports[] =
@@ -244,7 +244,7 @@
 { "Copyright (C) Acculogic, Inc.\r\n2.8M Diskette Extension Bios ver 
4.04.03 03/01/1993", 61, 82 },
 };
 #define SIGNATURE_COUNT (sizeof( signatures ) / sizeof( struct signature ))
-#endif USE_BIOS
+#endif /* USE_BIOS */
 
 /*  */
 
@@ -347,7 +347,7 @@
 

Re: [CHECKER] error path memory leaks in 2.4.4 and 2.4.4-ac8

[Dawson Engler]

> These are all now either fixed or obsoleted in my tree, and I will send a 
> patch to Linus shortly. Thankyou. 

Good deal.  Thanks for letting us know!

> Do you find it useful to get a response such as this? Are you keeping track
> of the bugs you find? (Or is it simply reassuring to confirm that someone's
> paying attention? :)

It's definitely useful, since it lets us keep tabs on what types of bugs
people actually fix ;-)  The tool keeps track of the bugs/false positives we
find, so that it can say when we find something new.

> I believe we can make that a short. Arjan?

Is the general way to fix these too-large stack vars to heap allocate
them?  Or is it preferable to put a "static" in front of them, if the
routine is non-reentrant?

Dawson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Ramdisk Initialization Problem

[Jaswinder Singh]

"H. Peter Anvin" <[EMAIL PROTECTED]> wrote :
>
> First of all, try the latest kernel if you are going to report a bug.
>

As far as i know , Regarding Ramdisk linux-2.4.4 and 2.4.1 are similar.
, no body fixed this problem after 2.4.1 , If somebody please let me know .

Anyhow i will try with latest kernel and let you know , but it will take
some time .

> For the kernel people, this is classic evidence of relying on
> uninitialized memory; the "few minutes" is roughly how long it takes
> modern SDRAM to *reliably* discharge.
>

In my case , If i restart after 5 minutes it works fine , but if i restart
after 1 or 2 minutes kernel hangs during uncompressing ramdisk.

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.

> -hpa


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.4-ac17

[Jaswinder Singh]

Dear Alan ,

Have you noticed (or fixed ) :-

1. the Memory leakage in ramfs
2. initialization of Ramdisk.

In you your new versions .


I am adding some details about them , for your reference :-

###
1. the Memory leakage in ramfs  (Subject of email was "Memory leak in the
ramfs file system")
---
Stephen L Johnson  <[EMAIL PROTECTED]> wrote:
>>
>>A group of us from the handhelds.org site think that we have found a
memory
>>leak in the ramfs file system. After a long period of create and deleting
>>small files in a mounted ramfs partition we have substantially less
freemem.
>>The problem has been confirmed on 2.4.2 on an i386 and StormARM ports.

"Linus Torvalds" <[EMAIL PROTECTED]> wrote:
> What does /proc/slabinfo say? The most likely leak is a dentry leak or
> an inode leak, and both of those should be fairly easy to see in the
> slab info (dentry_cache and inode_cache respectively).
>

I am attaching details before and during  my application .

Mainly changes are in dentry_cache and inode_cache , but i am attaching
whole /proc/slabinfo for your reference.


> Obviously, it could be a data page leak too, but such a leak should be
> easy to see by creating a few big files and deleting them..
>
> Linus

I am also facing one more problem with ramfs.

du and df shows 0 , so i am also attaching its output.
###
2. initialization of Ramdisk. (Subject of email was "Ramdisk Initialization
Problem")
---

I am using kernel 2.4.1 with compressed Ramdisk on  Hitachi SH board ,
with no battery.   When i run kernel first time , it works fine , it
uncompress Ramdisk and i get my shell prompt .But when i restart it
second time (with out  removing power cable ) kernel dies when
uncompressing Ramdisk.
But , if i remove my power supply for more than 5 minutes , and then
i start again , it works again.
It seems that in 2.4.1 and/or later versions has  Ramdisk Initailization
or uninitialised memory problem.
But i faced no problem  with 2.2.12 kernel.
###

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.

---
- Original Message -
From: "Alan Cox" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 24, 2001 4:37 PM
Subject: Linux 2.4.4-ac17


>
> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
>
> Intermediate diffs are available from
> http://www.bzimage.org
>
> In terms of going through the code audit almost all the sound drivers
still
> need fixing to lock against format changes during a read/write. Poll
creating
> and starting a buffer as write does and also mmap during write, write
during
> an mmap.
>
> This one just fixes the first chunk of stuff the Stanford checker found
and
> a couple of other small bits.
>
> 2.4.4-ac17
> o Fix double free in new cciss (me)
> o Fix i2o_pci double free on error (me)
> o Fix use after free in iphase (two of) (me)
> o Fix use after free in cs4281 (me)
> o Fix use after free in lapbether (me)
> o Fix use after free in bpqether (me)
> o Fix use after free in edgeport (me)
> o Fix memory leak in cciss (me)
> o Fix memory leak in failed vxfs mounts (me)
> o Fix memory leak in failed cmsfs mounts (me)
> o Fix memory leak on error in ixj (me)
> o Fix memory leak in lmc (me)
> o Fix memory leak in isdnppp (me)
> o Fix memory leak in wanrouter (me)
> o Fix memory leak on error in jffs (me)
> o Fix reference to invalid memory in rio (me)
> o Fix leaks in xircom driver (and update) (Arjan van de Ven)
> | All of the above found by the stanford checking team
> | who [or whose tools] effectively did the work for us
> o Fix maestro bug from merge (Marcus Meissner)
>
> 2.4.4-ac16
> o Fix FAT crashes with 2K media (OGAWA Hirofumi)
> o Fix scsi trace messages (Khalid Aziz)
> o Fix hga module laod problem (Juan Quintela)
> o Fix leak in wanproc (Akash Jain)
> o ESS solo clean ups (Marcus Meissner)
> o Update address for Jonathan Woithe (Jonathan Woithe)
> o Fix the mess I made of the stradis driver (Francois Romieu)
> o Port maestro to 2.4 PCI API (Marcus Meissner)
> o Report shmem pages in /proc (Christoph Rohland)
> | Im not sure this is the right approach - opinions ?
> o Port toshoboe driver to 2.4 PCI api (Marcus Meissner)
> o Update 3ware ide raid driver (Adam Radford)
> o Update ncr/symbios drivers (Gerhard Roudier)
> o Fix fealnx build on some non x86 platforms (Jeff Garzik)
>
> 2.4.4-ac15
> o Merge Linus 2.4.5pre5
> | Also fixes a dumb bug in my mmx fixups I
> | managed to forget to test and spot
> o Dump the ACPI changes - new ones are pending (me)
> and the old ones are better than this lot
> o Revert serial incompatibility pending nice fix (me)
> o Move a few other oddments to match Linus
> o Rip format conversion out of the pwc driver (me)
> | It belongs in user space..
>
> 2.4.4-ac14
> o Fix error corner case on max file size check (Andrew Mort

SiS630 linking problems w/ 2.4.4-ac12

[rolf]

Hi,
I`m trying to compile 2.4.4-ac12 with support for SiS accelerated
framebuffer device in the kernel. It compiles fine but then I get the
attached errors.
I`m trying the ac12 cause the sis framebuffer from the stock kernel
doesn`t even boot and there seem to be significant changes beetween those
two versions.

Please CC me cause I can`t keep up with the enormous traffic this list
generates :(
Thanks in advance, Rolf

make CFLAGS="-D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 
-march=i686 " -C  arch/i386/lib
make[1]: Entering directory `/usr/src/linux/arch/i386/lib'
make all_targets
make[2]: Entering directory `/usr/src/linux/arch/i386/lib'
gcc -D__ASSEMBLY__ -D__KERNEL__ -I/usr/src/linux/include -c checksum.S -o checksum.o
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 
-march=i686-c -o old-checksum.o old-checksum.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 
-march=i686-c -o delay.o delay.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 
-march=i686-c -o usercopy.o usercopy.c
gcc -D__ASSEMBLY__ -D__KERNEL__ -I/usr/src/linux/include -c getuser.S -o getuser.o
gcc -D__ASSEMBLY__ -D__KERNEL__ -I/usr/src/linux/include -c putuser.S -o putuser.o
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 
-march=i686-c -o memcpy.o memcpy.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 
-march=i686-c -o strstr.o strstr.c
rm -f lib.a
ar  rcs lib.a checksum.o old-checksum.o delay.o usercopy.o getuser.o putuser.o 
memcpy.o strstr.o
make[2]: Leaving directory `/usr/src/linux/arch/i386/lib'
make[1]: Leaving directory `/usr/src/linux/arch/i386/lib'
ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext 
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o 
ipc/ipc.o \
 drivers/char/char.o drivers/block/block.o drivers/misc/misc.o 
drivers/net/net.o drivers/media/media.o drivers/ide/idedriver.o drivers/cdrom/driver.o 
drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/video/video.o \
net/network.o \
/usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a 
/usr/src/linux/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
fs/fs.o: In function `bm_register_write':
fs/fs.o(.text+0x16093): undefined reference to `lookup_one'
drivers/video/video.o: In function `SiSInit300':
drivers/video/video.o(.text+0x6276): undefined reference to `sisfb_set_reg1'
drivers/video/video.o(.text+0x6285): undefined reference to `sisfb_get_reg1'
drivers/video/video.o(.text+0x6298): undefined reference to `sisfb_get_reg1'
drivers/video/video.o(.text+0x62ab): undefined reference to `sisfb_get_reg1'
drivers/video/video.o(.text+0x62cf): undefined reference to `sisfb_set_reg1'
drivers/video/video.o(.text+0x630f): undefined reference to `sisfb_set_reg1'
drivers/video/video.o(.text+0x632f): undefined reference to `sisfb_set_reg1'
drivers/video/video.o(.text+0x634f): undefined reference to `sisfb_set_reg1'
drivers/video/video.o(.text+0x6379): undefined reference to `sisfb_get_reg1'
drivers/video/video.o(.text+0x63a3): undefined reference to `sisfb_get_reg1'
drivers/video/video.o(.text+0x63c4): undefined reference to `sisfb_get_reg1'
drivers/video/video.o(.text+0x63d9): undefined reference to `sisfb_set_reg1'
drivers/video/video.o(.text+0x63ef): undefined reference to `sisfb_get_reg1'
drivers/video/video.o(.text+0x6410): undefined reference to `sisfb_get_reg1'
drivers/video/video.o(.text+0x6425): undefined reference to `sisfb_set_reg1'
drivers/video/video.o(.text+0x643e): undefined reference to `sisfb_get_reg1'
drivers/video/video.o(.text+0x6466): undefined reference to `sisfb_set_reg1'
drivers/video/video.o(.text+0x6490): undefined reference to `sisfb_set_reg1'
drivers/video/video.o(.text+0x64b1): undefined reference to `sisfb_set_reg1'
drivers/video/video.o(.text+0x64c0): undefined reference to `sisfb_get_reg1'
drivers/video/video.o(.text+0x64e9): undefined reference to `sisfb_set_reg1'
drivers/video/video.o(.text+0x650c): undefined reference to `sisfb_set_reg1'
drivers/video/video.o(.text+0x6523): undefined reference to `sisfb_set_reg1'
drivers/video/video.o(.text+0x653a): undefined reference to `sisfb_set_reg1'
drivers/video/video.o(.text+0x6554): undefined reference to `sisfb_set_reg1'
drivers/video/video.o(.text+0x656b): more undefined refere

Re: Ramdisk Initialization Problem

[H. Peter Anvin]

Followup to:  
By author:"Jaswinder Singh" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> I am using kernel 2.4.1 with compressed Ramdisk on  Hitachi SH board ,
> with no battery.   When i run kernel first time , it works fine , it
> uncompress Ramdisk and i get my shell prompt .But when i restart it
> second time (with out  removing power cable ) kernel dies when
> uncompressing Ramdisk.   But , if i remove my power supply for more than 5
> minutes , and then i start again , it works again.   It seems that in 2.4.1
> and/or later versions has  Ramdisk Initailization or uninitialised memory
> problem. But i faced no problem  with 2.2.12 kernel.   Thank you,  
> 
> Best Regards,   Jaswinder (and his wonder machine).
> 

First of all, try the latest kernel if you are going to report a bug.

For the kernel people, this is classic evidence of relying on
uninitialized memory; the "few minutes" is roughly how long it takes
modern SDRAM to *reliably* discharge.

-hpa
-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SyncPPP Generic PPP merge

[Paul Mackerras]

Jeff Mcadams writes:

> Indeed.  And let me just throw out another thought.  A clean abstraction
> of the various portions of the PPP functionality is beneficial in other
> ways.  My personal pet project being to add L2TP support to the kernel
> eventually.  A good abstraction of the framing capabilities and basic
> PPP processing would be rather useful in that project.

That is exactly what ppp_generic.c is intended to do - it abstracts
out the framing and encapsulation and low-level transport of PPP
frames into ppp "channels" (see for example ppp_async.c,
ppp_synctty.c) while ppp_generic.c does the basic PPP processing
(compression, multilink, handling the network interface device etc.).

You should be able to write an L2TP channel to work with ppp_generic -
all your code would need to know about is how to take a PPP frame and
encapsulate and send it, and how to receive and decapsulate PPP
frames.

[Note to myself: send in a Documentation/ppp_generic.txt which
describes the interface between ppp_generic.c and the channels.]

> I would agree that such a project would be 2.5 material.

Do it today if you like, I can't see that adding a new PPP channel
could break anything else, it would be like adding a new driver.

Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: O_TRUNC problem on a full filesystem

[Andrew Morton]

Andreas Dilger wrote:
> 
> Andrew writes:
> > "Stephen C. Tweedie" wrote:
> > > On Wed, May 23, 2001 at 07:55:48PM +1000, Andrew Morton wrote:
> > > > When you truncated your file, the blocks remained preallocated
> > > > on behalf of the file, and were hence considered "used".  For
> > > > some reason, a subsequent attempt to allocate blocks for the
> > > > same file failed to use that file's preallocated blocks.
> > >
> > > Nope.  ext2_truncate() calls ext2_discard_prealloc() to fix this up.
> > > Both 2.2 and 2.4 do this correctly.
> >
> > But the problem goes away when you disable EXT2_PREALLOCATE.
> > I tested it.
> 
> Are you sure that a truncated file will re-use the same truncated blocks,
> but not the preallocated ones?  I can imagine not re-using all of the data
> blocks within a single transaction, but it would be odd if the preallocated
> blocks are treated differently.

This is vanliia ext2.  The O_TRUNC problem is easy to reproduce,
and goes away when EXT*2*_PREALLOC is undefined.  Haven't looked
into it further, but I suppose one should.  It's not nice having
unexplained mysteries in ext2.

> How have you done the ext3 preallocation code?  One way to do it would be
> to only mark the blocks as used in the in-memory copy of the block bitmap
> and not write that to disk (we keep 2 copies of the block bitmap, IIRC).
> That way you don't need to do anything fancy at recovery time.
> 
> Did you ever benchmark ext2 with and without preallocation to see if it
> made any difference?  No point in doing extra work if there is no benefit.

This is an excellent point - it would be unwise to go to the
effort and complexity of putting prealloc back into ext3
without first analysing how useful it actually is.  Perhaps
some tuning of the other anti-fragmentation algorithms
will suffice.

For example, when we miss the goal block we search forward
up to 63 blocks for a *single* free block, and use that.
Perhaps we shouldn't?

And perhaps the search for eight contiguous free blocks
is no longer appropriate to current disks.  32 may be better?

So I'd prefer to set up a simulator and at least validate the
current algorithms beforehand, perhaps tune them as well.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Two-machine cluster efficient approach(?) Comment? Thanks.

[Ragnar Kjørstad]

On Thu, May 24, 2001 at 06:32:10PM -0400, Chuck Wu wrote:
> Two machines want to be accessed by the same IP address and
> share workload. Can not change the router. Can only change 
> local linux system. Will the following approach work? Thanks.

You should check out Linux Virtual Server; it does something simular
(only it doesn't reply to arp-requests with broadcast-address, but with
one of the servers' ethernet-address).

> Solution:
> -
> 1. Reserve an unused IP as the to be publicized "Server IP", actually no
>machine takes it. So, it is kind of "virtual IP".
> 2. Alias the NIC of those two work stations to this "virtual IP" so they
>can accept packets to this "virtual IP".
> 3. For ARP request packet to this "virtual IP", those two work stations
>will return the MAC broadcast address. Then, all the packets to the
>"virtual IP" will be broadcast to this subnet and those two machines
>will get such packtes.
> 4. Before such packets gets into the TCP/IP stack, use a hash function
>to filter the packets. Say, workstation A will accept packets whose
>source IP is an odd number and discard the packets with even-number
>source IP.

If this work, a useful addon would be to use something a little more
advanced, to allow it to scale to more than 2 servers.

> 5. For the outgoing packets from those two workstations, change the source
>IP address to be the "virtual IP".
> 6. Have another thread keep ping each other, once another workstation
>crashes, change my hash function to accept all the packets to the
>"virtual IP". Whenever another workstation resumes, switch back to
>the original hash function.
> 
>Do you think if this approach will work? There is also a question I
> am not quite sure, can two machines's NICs be aliased to the same "virtual
> IP"? Will it cause some conflicts? And, it seems I need to change the
> linux kernel source code. I am not pretty sure where is the location of
> the source code related to the above operations. Like, can you tell me the
> location of the linux kernel source code to answer an ARP request packet,
> to build a hash function to filter the incoming IP packets before it
> enters the TCP/IP stack?


--
Ragnar Kjørstad
Big Storage
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Big-ish SCSI disks

[Greg Johnson]

Hi kernel poeple,

Can anyone out there say for certain that 76GB SCSI disks should
just work with kernel versions 2.2 and/or 2.4? We need to get some
big disk space and have heard reports of problems with disks
bigger than 30GB under linux.

Thanks.

Greg.

-- 
+--+
| Do you want to know more? www.geocities.com/worfsom/ |
|  ..ooOO Greg Johnson OOoo..  |
| HW/SW Engineer[EMAIL PROTECTED] |
| Canon Information Systems Research Australia (CISRA) |
| 1 Thomas Holt Dr., North Ryde, NSW, 2113,  Australia |
|  "I FLEXed my BISON and it went YACC!" - me. |
+--+

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] null bugs in 2.4.4 and 2.4.4-ac8

[Willem Riede]

Junfeng Yang wrote:
> 
> On Thu, 24 May 2001, Willem Riede wrote:
> 
> > Dawson Engler wrote:
> > >
> > > Hi All,
> > >
> > > Enclosed are 103 potential errors where code gets a pointer from a
> > > possibly-failing routine (kmalloc, etc) and dereferences it without
> > >
> > > [BUG] osst_do_scsi will never return NULL if argument SRpnt isn't NULL. But they 
>copy SRpnt back by *aSRpnt, implies it could be NULL
> >
> > No. It implies SRpnt could have changed. The functions flagged
> > (osst_read_back_buffer_and_rewrite and osst_reposition_and_retry)
> > cannot be reached with SRpnt == NULL. So these are false alarms.
> 
> these are false positives if osst_read_back_buffer_and rewrite can't be
> reached with SRpnt == NULL. It seems that osst_do_scsi will not change
> SRpnt unless it is NULL though.

That is currently true, and the re-assignment of SRpnt is superfluous but
harmless. It is not a design constraint though that SRpnt cannot change
(except it can't change to NULL), so I prefer to leave the code as is.

> In other words, SRpnt is changed by
> osst_do_scsi <=> the initial argument SRpnt == NULL. Probabaly the pointer
> aSRpnt is useless.
> 
The pointer aSRpnt is not useless, it's used to communicate the current
value of SRpnt throughout the driver.

Regards, Willem Riede.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: nfs mount by label not working.

[Dave Mielke]

[quoted lines by Philipp Matthias Hahn on May 24, 2001, at 09:31]

>Do you realy mean what you wrote in the Subject line:
>
>Subject : Re: *nfs* mount by label not working.

No, I mean ext2. It would appear that my mount command was a little old. A
newer version of mount works.

-- 
Dave Mielke   | 2213 Fox Crescent | I believe that the Bible is the
Phone: 1-613-726-0014 | Ottawa, Ontario   | Word of God. Please contact me
EMail: [EMAIL PROTECTED] | Canada  K2A 1H7   | if you're concerned about Hell.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Accelerated TCP/IP support from kernel

[Gerhard Mack]

I'm curious.. do your cards support IPv6 and ECN ?

Gerhard


On Thu, 24 May 2001, Bharath Madhavan wrote:

> Thanks a lot. That was useful info especially your last point
> where you are saying that most of the area we can save is in
> data processing and not in protocol processing.
> So, if we use the ZERO_COPY feature, we should gain quite a bit.
> I guess 3c905c NIC supports HW checksumming. Is this true?
> In this case, do we have any benchmarking for this card 
> with and without ZERO_COPY (and HW checksumming). I am eager to
> know by how many times did the system throughput increase?
> Thanks a lot
> Bharath
> 
> 
> 
> 
> -Original Message-
> From: David S. Miller [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 24, 2001 6:29 PM
> To: Bharath Madhavan
> Cc: [EMAIL PROTECTED]
> Subject: Re: Accelerated TCP/IP support from kernel
> 
> 
> 
> Bharath Madhavan writes:
>  >I am looking into a scenario where we have a NIC which performs 
>  > all the TCP/IP processing and basically the core CPU offloads all data
> from
>  > the socket level interface onwards to this NIC. 
> 
> Why would you ever want to do this?
> 
> Point 1: Support for new TCP techniques and bug fixes are hard enough
> to propagate to user's systems as it is with the implementation being
> done in software.
> 
> Point 2: If I find a bug in the cards TCP implementation, will I be
> able to get at the source for the firmware and fix it?  Likely the
> answer to this is no.
> 
> Every couple years a few vendors make cards like this, yet ignore
> these core issues.  It is currently impractical to use these kinds of
> cards today except in a few very special case situations.
> 
> Furthermore, the actual protocol processing overhead is quite small
> and almost neglible especially on today's gigahertz beasts.  The data
> copy is where the time is spent, and checksum offload takes care of
> that.
> 
> Later,
> David S. Miller
> [EMAIL PROTECTED]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

--
Gerhard Mack

[EMAIL PROTECTED]

<>< As a computer I find your faith in technology amusing.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.4.4-ac17

[Alan Cox]

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/

 Intermediate diffs are available from
http://www.bzimage.org

In terms of going through the code audit almost all the sound drivers still 
need fixing to lock against format changes during a read/write. Poll creating 
and starting a buffer as write does and also mmap during write, write during
an mmap.

This one just fixes the first chunk of stuff the Stanford checker found and
a couple of other small bits.

2.4.4-ac17
o   Fix double free in new cciss(me)
o   Fix i2o_pci double free on error(me)
o   Fix use after free in iphase (two of)   (me)
o   Fix use after free in cs4281(me)
o   Fix use after free in lapbether (me)
o   Fix use after free in bpqether  (me)
o   Fix use after free in edgeport  (me)
o   Fix memory leak in cciss(me)
o   Fix memory leak in failed vxfs mounts   (me)
o   Fix memory leak in failed cmsfs mounts  (me)
o   Fix memory leak on error in ixj (me)
o   Fix memory leak in lmc  (me)
o   Fix memory leak in isdnppp  (me)
o   Fix memory leak in wanrouter(me)
o   Fix memory leak on error in jffs(me)
o   Fix reference to invalid memory in rio  (me)
o   Fix leaks in xircom driver (and update) (Arjan van de Ven)
| All of the above found by the stanford checking team
| who [or whose tools] effectively did the work for us
o   Fix maestro bug from merge  (Marcus Meissner)

2.4.4-ac16
o   Fix FAT crashes with 2K media   (OGAWA Hirofumi)
o   Fix scsi trace messages (Khalid Aziz)
o   Fix hga module laod problem (Juan Quintela)
o   Fix leak in wanproc (Akash Jain)
o   ESS solo clean ups  (Marcus Meissner)
o   Update address for Jonathan Woithe  (Jonathan Woithe)
o   Fix the mess I made of the stradis driver   (Francois Romieu)
o   Port maestro to 2.4 PCI API (Marcus Meissner)
o   Report shmem pages in /proc (Christoph Rohland)
| Im not sure this is the right approach - opinions ?
o   Port toshoboe driver to 2.4 PCI api (Marcus Meissner)
o   Update 3ware ide raid driver(Adam Radford)
o   Update ncr/symbios drivers  (Gerhard Roudier)
o   Fix fealnx build on some non x86 platforms  (Jeff Garzik)

2.4.4-ac15
o   Merge Linus 2.4.5pre5
| Also fixes a dumb bug in my mmx fixups I 
| managed to forget to test and spot
o   Dump the ACPI changes - new ones are pending(me)
and the old ones are better than this lot
o   Revert serial incompatibility pending nice fix  (me)
o   Move a few other oddments to match Linus
o   Rip format conversion out of the pwc driver (me)
| It belongs in user space..

2.4.4-ac14
o   Fix error corner case on max file size check(Andrew Morton)
o   Do first bits of applicom.c cleanup (me)
| This needs a lot of cleaning yet
o   Fix open/close locking on dsp56k(me)
o   Clean up the obvious namespace mess in h8.c (me)
| Wants verifying by Alpha folks
o   Fix locking errors in machzwd watchdog  (me)
o   Fix printk levels on nwflush , someone with a   (me)
netwindup needs to see the FIXME cases still
o   Fix out of memory oops in pcwd.c(me)
o   Add more Dell raid devices to sparselun table   (Matt Domsch)
o   Add hotplug table entry for aic7xxx (Marcus Meissner)
o   Drop deceased APA1480 driver to match Linus tree(me)
o   Fix ali15x3 nodma behaviour (Jeff Garzik)
o   Further quota fixups(Jan Kara)
o   Update a2232 to current version (Geert Uytterhoeven)
| Older one got merged in error..
o   Clean up sonicvibes pci handling(Marcus Meissner)
o   Remove dead radio miscdevice bits   (Al Viro)
o   Merge ATI Rage XL console support   (Geert Uytterhoeven)
o   Fix problems with pyxis iommu on Alpha  (Ivan Kokshaysky)
o   Fix compile errors when built without /proc   (Andrzej Krzysztofowicz)
o   Encapsulate shmem inode info using macros   (Christoph Rohland)
| So Al can attack the inode struct..
o   Move small symlinks into shmem_inode_info   (Christoph Rohland)
o   Count shmemfs pages and put them in /proc   (Christoph Rohland)
o   Put back accidentally reverted PnPBIOS pa

Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

[Andi Kleen]

On Thu, May 24, 2001 at 05:08:40PM -0600, Andreas Dilger wrote:
> I'm curious about this stack checker.  Does it check for a single
> stack allocation >= 1024 bytes, or does it also check for several
> individual, smaller allocations which total >= 1024 bytes inside
> a single function?  That would be equally useful.

At one time someone had a script to grep objdump -S vmlinux for the
stack allocations generated by gcc and check them. It found a few 
cases. It is easy to rewrite, as they are very regular instruction 
patterns at the beginning of functions (at least when you ignore variable 
length stack arrays, which do not seem to be common in the kernel anyways) 

> 
> On a side note, does anyone know if the kernel does checking if the
> stack overflowed at any time?  It is hard to use Dawson's tools to
> verify call paths because of interrupts and such, but I wonder what
> happens when the kernel stack overflows - OOPS, or silent corruption?

You normally get a silent hang or worse a stack fault exception 
(which linux/x86 without kdb cannot recover from) which gives you instant 
reboot.
The ikd patches contain a stack overflow checker for runtime.


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Kernel 2.4.x TODO

[Dunlap, Randy]

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> 
> Was the TODO list at http://linux24.sourceforge.net just 
> meant to be useful before 2.4.0 was released?

I believe that is the case.

> It seems to me that it would still be useful for (amongst 
> other things)
> potential kernel hackers looking for something to have a stab 
> at but it
> doesn't seem to up to date. Is it still supposed to be being 
> maintained by anyone?

Check out the kernel janitor project at
http://bazar.conectiva.com.br/~acme/TODO (original)
and
http://sourceforge.net/projects/kernel-janitor (later)

~Randy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4 freezes on VIA KT133

[Mark Hahn]

> This report is probably not very helpful, but it may be useful for those who
> planned to purchase AMD / VIA solution for a server.

contrary to the implication here, I don't believe there is any *general*
problem with Linux/VIA/AMD stability.  there are well-known issues
with specific items (VIA 686b, for instance), but VIA/AMD hardware
is quite suitable for servers.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.4 kernel freeze

[Jens Gecius]

Jens Gecius <[EMAIL PROTECTED]> writes:

> > > what do you mean by freeze?  in theory, the fact that the irq
> > I cannot ping the machine anymore, no Ooops, no kernel messages, the
> > attached screen is freezed (which implies that no more interrupts
> > are handled, right?)
> 
> Excuse me hopping in.
> 
> I have that situation here, too. Screen frozen, no pings from the
> local network, sysrq doesn't work (keyboard dead).
> 
> maniac kernel: NETDEV WATCHDOG: eth1: transmit timed out
> maniac kernel: eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3,
> t=21.
> 
> All this happened on 2.4.3 and 2.4.4 (don't excactly remember on
> earlier 2.4).
> 
> I followed your suggestion regarding PCI-slots. Both my nics used to
> use PCI 4 and 5 (on a gigabyte vxd7, dual 1GHz). Only the one in slot
> 4 had the problems. I switched the card to slot 1 and will monitor the
> situation. I'll mail the list in case it doesn't change my situation.

OK - now it even got worse. After just a couple hours slot5 was dead
(that was the one working just fine with the other card in
slot4). Three minutes later slot1 was dead, too. Both cards share
irq12.

Fortunately, the box wasn't frozen this time. X was up and running
fine and I was able to reboot in a sound manner.

I'll try another change in slots, but unfortunately, my nics are the
ones with the lowest traffic: one other is SCSI, the other one
firewire... (even though the latter one is hardly used).
 
> Any other hints are welcome (other than the noapic, which didn't help).

I have to reiterate this one. Any hints are very welcome.

-- 
Tschoe,Get my gpg-public-key here
 Jens http://gecius.de/gpg-key.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] free bugs in 2.4.4 and 2.4.4-ac8

[Alan Cox]

> > > Error --->
> > >  p, p->RIOHosts, p->RIOPortp, rio_termios, rio_termios);
> > 
> > Not a bug - you need to teach your code that printf has formats that print the
> > value of a pointer not dereference it
> > 
> 
> Take another look.  p is potentially bogus here, meaning those p->RIOHosts and
> p->RIOPortp references are bad.

True - fixed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] free bugs in 2.4.4 and 2.4.4-ac8

[David S. Miller]

Alan Cox writes:
 > > [BUG]  seems possible --- or is some precondition guarenteed?
 > > /u2/engler/mc/oses/linux/2.4.4-ac8/net/ipv6/udp.c:438:udpv6_recvmsg: 
 >ERROR:FREE:453:438: WARN: Use-after-free of "skb"! set by 'kfree_skb':453
 > 
 > Looks right. Left for DaveM

It's wrong, in the MSG_PEEK case skb->users is incremented by
skb_recv_datagram, so to truly get rid of it we do indeed need to
unlink it from the receive_queue then free it twice :-)

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

[Andreas Dilger]

Dawson Engler writes:
> Here are 37 errors where variables >= 1024 bytes are allocated on a
> function's stack.

First of all, thanks very much for the work you are doing.  It really
is useful, and a good way to catch those very rare error cases that
would not otherwise be fixed.

I'm curious about this stack checker.  Does it check for a single
stack allocation >= 1024 bytes, or does it also check for several
individual, smaller allocations which total >= 1024 bytes inside
a single function?  That would be equally useful.

On a side note, does anyone know if the kernel does checking if the
stack overflowed at any time?  It is hard to use Dawson's tools to
verify call paths because of interrupts and such, but I wonder what
happens when the kernel stack overflows - OOPS, or silent corruption?

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: nfs mount by label not working.

[Philipp Matthias Hahn]

On Wed, 23 May 2001, Dave Mielke wrote:

> Using kernel 2.2.17-14 as supplied by RedHat, and using mount from
> mount-2.9u-4, mounting by label using the -L option does not work.
>
> mount -L backup1 /a
Do you realy mean what you wrote in the Subject line:

Subject : Re: *nfs* mount by label not working.
  ^

That would be something like:
   ask every server in the known universe if it has a nfs-export by
   name backup1, choose one of them and mount it locally on /a.

If you use nfs you have to specify the server and the volume old
fashioned. Mounting by lable or uuid is supported by very few filesystems,
mainly by ext2 only.

What the kernel does is to read /proc/partitions and check if any
partition found there has the label or uuid you search for.

BYtE
Philipp
-- 
  / /  (_)__  __   __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
//_/_//_/\_,_/ /_/\_\ [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4 freezes on VIA KT133

[Tomas Styblo]

Hi !

I've yet seen similar freeze reports here in the past, so I decided to post
my one too.
The said system is a server, Athlon 850, no overclocking, no overheating,
100 Mhz FSB, 512 MB brand RAM, Abit KT7A board with VIA KT133.

The system is heavy loaded in daytime, but almost idle at night. It crashes
only about three times per month. These freezes
started to happen after 2.2 -> 2.4 upgrade, that I performed early after the
2.4.1 revision was released. These crashes are completely untracable for me,
because there is nothing suspicious in the syslog afterwards. Also the
system runs ABSOLUTELY perfectly between the crashes  - no problems with
kernel compilations or similar tasks that push the system over stability.

The crashes occur absolutely unpredictably, sometimes even at night, when
the system is idle.

The system runs various network services and dynamic web applications that
use the MySQL database a lot. The only used filesystem is EXT2. I do not use
buggy redhat compiler.

This report is probably not very helpful, but it may be useful for those who
planned to purchase AMD / VIA solution for a server.
I am not subscribed to this list, but I will monitor it through a web
archive and will try to respond, if needed.

Thanks for your work !
Tomas Styblo


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] free bugs in 2.4.4 and 2.4.4-ac8

[Alan Cox]

> [BUG] [fixed in 2.4.4]
> /u2/engler/mc/oses/linux/2.4.4-ac8/drivers/block/cciss.c:686:cciss_ioctl: 
>ERROR:FREE:682:686: WARN: Use-after-free of "c"! set by 'cmd_free':682 [type=SECURITY]
> {
> /* Copy the data out of the buffer we created */
> if (copy_to_user(iocommand.buf, buff, iocommand.buf_size))
>   {
>   kfree(buff);
> Start --->
>   cmd_free(h, c, 0);

Missing return -EFAULT - fixed. (The one thing your analyser cant do is guess
history of bugs ;) - this is one that came with the updated driver. Im glad
you caught it as the update went on to Linus for 2.4.5pre


> /u2/engler/mc/oses/linux/2.4.4-ac8/drivers/usb/dc2xx.c:473:camera_disconnect: 
>ERROR:FREE:466:473: WARN: Use-after-free of "camera"! set by 'kfree':466

Already fixed in ac15 but a real bug

> [BUG]  seems possible --- or is some precondition guarenteed?
> /u2/engler/mc/oses/linux/2.4.4-ac8/net/ipv6/udp.c:438:udpv6_recvmsg: 
>ERROR:FREE:453:438: WARN: Use-after-free of "skb"! set by 'kfree_skb':453

Looks right. Left for DaveM

> -
> [BUG]  [BAD] Seems like a really really bad double free.
> /u2/engler/mc/oses/linux/2.4.4/drivers/i2o/i2o_pci.c:231:i2o_pci_install: 
>ERROR:FREE:229:231: WARN: Use-after-free of "c"! set by 'i2o_delete_controller':229

Real bug - in -ac the bug is the same but the file moved

> /u2/engler/mc/oses/linux/2.4.4-ac8/drivers/isdn/isdn_ppp.c:822:isdn_ppp_init: 
>ERROR:FREE:822:822: WARN: Use-after-free of "ippp_table"! set by 'kfree':822
>
Fixed in -ac and current 2.4.5pre already - real bug

> [BUG]
> /u2/engler/mc/oses/linux/2.4.4-ac8/drivers/atm/iphase.c:1323:rx_dle_intr: 
>ERROR:FREE:1321:1323: WARN: Use-after-free of "skb"! set by 'dev_kfree_skb_any':1321

Real bug - fixed

> /u2/engler/mc/oses/linux/2.4.4-ac8/drivers/atm/iphase.c:1339:rx_dle_intr: 
>ERROR:FREE:1337:1339: WARN: Use-after-free of "skb"! set by 'dev_kfree_skb_any':1337
>   length =  swap(trailer->length);

Real bug - fixed

> -
> [BUG]
> 
>/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/sound/cs4281/cs4281m.c:4468:cs4281_remove: 
>ERROR:FREE:4466:4468: WARN: Use-after-free of "s"! set by 'kfree':4466

Real bug - fixed

> [BUG] Again assumes kfree sets memory to NULL.

Disagree with diagnosis
> 
>/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/net/wan/lapbether.c:116:lapbeth_check_devices:
> ERROR:FREE:113:116: WARN: Use-after-free of "lapbeth"! set by 'kfree':113
>   if (&lapbeth->axdev == dev)

But the bug is real - fixed a missing else

> [BUG] bpq is freed, assigned to another variable (bpq_prev), then
> 
>/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/net/hamradio/bpqether.c:196:bpq_check_devices:
> ERROR:FREE:193:196: WARN: Use-after-free of "bpq"! set by 'kfree':193

Fixed - real bug (copy of lapbether bug)

> [BUG]
>
 /u2/engler/mc/oses/linux/2.4.4-ac8/net/wanrouter/wanmain.c:617:device_setup: 
ERROR:FREE:614:617: WARN: Use-after-free of "conf"! set by 'kfree':614

Real bug - fixed

> /u2/engler/mc/oses/linux/2.4.4-ac8/net/netrom/nr_dev.c:122:nr_rebuild_header: 
>ERROR:FREE:117:122: WARN: Use-after-free of "skbn"! set by 'kfree_skb':117
>   skb_set_owner_w(skbn, skb->sk);
> 

Real bug - fixed

> /u2/engler/mc/oses/linux/2.4.4-ac8/net/ax25/ax25_ip.c:163:ax25_rebuild_header: 
>ERROR:FREE:157:163: WARN: Use-after-free of "skb"! set by 'kfree_skb':157
>   }

Uggh - nasty - fixed.

> Error --->
>   dbg(__FUNCTION__" - nonzero write bulk status received: %d", 
>urb->status);

Fixed

>   return;
> 
>/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/char/drm/gamma_dma.c:573:gamma_dma_send_buffers:
> ERROR:FREE:561:573: WARN: Use-after-free of "last_buf"! set by 'drm_free_buffer':561
>   DRM_DEBUG("%d running\n", current->pid);

Left for the XFree folk

> [BUG]
> /u2/engler/mc/oses/linux/2.4.4-ac8/drivers/usb/dc2xx.c:332:camera_release: 
>ERROR:FREE:330:332: WARN: Use-after-free of "camera"! set by 'kfree':330
>

Already fixed in ac15 - real bug
> 
>/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/char/rio/rio_linux.c:1036:rio_init_datastructures:
> ERROR:FREE:1031:1036: WARN: Use-after-free of "RIOHosts"! set by 'kfree':1031
> kfree (p->RIOPortp[i]);
>   rio_dprintk (RIO_DEBUG_INIT, "Not enough memory! %p %p %p %p %p\n", 
> Error --->
>  p, p->RIOHosts, p->RIOPortp, rio_termios, rio_termios);

Not a bug - you need to teach your code that printf has formats that print the
value of a pointer not dereference it

Thats pretty good - one false positive. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

[Anton Altaparmakov]

At 22:10 24/05/2001, Dawson Engler wrote:
[snip]
>-
>[BUG]
>/u2/engler/mc/oses/linux/2.4.4-ac8/fs/ntfs/super.c:352:ntfs_get_free_cluster_count: 
>ERROR:VAR:352:352: suspicious var 'bits' = 2048 bytes:352 [nbytes=2048]
>
>static int nc[16]={4,3,3,2,3,2,2,1,3,2,2,1,2,1,1,0};
>
>int ntfs_get_free_cluster_count(ntfs_inode *bitmap)
>{
>
>Error --->
> unsigned char bits[2048];
>-

Thanks. I was just about to submit a large patch anyway, so I will fix this 
and submit shortly.

Anton



-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sf.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] null bugs in 2.4.4 and 2.4.4-ac8

[Junfeng Yang]

On Thu, 24 May 2001, Willem Riede wrote:

> Dawson Engler wrote:
> >
> > Hi All,
> >
> > Enclosed are 103 potential errors where code gets a pointer from a
> > possibly-failing routine (kmalloc, etc) and dereferences it without
> >
> > [BUG] osst_do_scsi will never return NULL if argument SRpnt isn't NULL. But they 
>copy SRpnt back by *aSRpnt, implies it could be NULL
>
> No. It implies SRpnt could have changed. The functions flagged
> (osst_read_back_buffer_and_rewrite and osst_reposition_and_retry)
> cannot be reached with SRpnt == NULL. So these are false alarms.

these are false positives if osst_read_back_buffer_and rewrite can't be
reached with SRpnt == NULL. It seems that osst_do_scsi will not change
SRpnt unless it is NULL though. In other words, SRpnt is changed by
osst_do_scsi <=> the initial argument SRpnt == NULL. Probabaly the pointer
aSRpnt is useless.

>
> > 
>/u2/engler/mc/oses/linux/2.4.4/drivers/scsi/osst.c:1163:osst_read_back_buffer_and_rewrite:
> ERROR:NULL::1163: Using unknown ptr "SRpnt" illegally! set by 
>'osst_do_scsi':1163 [nbytes = 216]
> > #if DEBUG
> > if (debugging)
> > printk(OSST_DEB_MSG "osst%d: About to attempt to write to 
>frame %d\n", dev, new_block+i);
> > #endif
> > SRpnt = osst_do_scsi(SRpnt, STp, cmd, OS_FRAME_SIZE, 
>SCSI_DATA_WRITE,
> > Start --->
> > STp->timeout, MAX_WRITE_RETRIES, TRUE);
> >
> > ... DELETED 46 lines ...
> >
> > }
> > }
> > if (flag) {
> > if ((SRpnt->sr_sense_buffer[ 2] & 0x0f) == 13 &&
> >  SRpnt->sr_sense_buffer[12] ==  0 &&
> > Error --->
> >  SRpnt->sr_sense_buffer[13] ==  2) {
> > printk(KERN_ERR "osst%d: Volume overflow in write 
>error recovery\n", dev);
> > vfree((void *)buffer);
> > return (-EIO);  /* hit end of tape 
>= fail */
> >
>
> Regards. Willem Riede.
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Two-machine cluster efficient approach(?) Comment? Thanks.

[Chuck Wu]

Two machines want to be accessed by the same IP address and
share workload. Can not change the router. Can only change 
local linux system. Will the following approach work? Thanks.

Solution:
-
1. Reserve an unused IP as the to be publicized "Server IP", actually no
   machine takes it. So, it is kind of "virtual IP".
2. Alias the NIC of those two work stations to this "virtual IP" so they
   can accept packets to this "virtual IP".
3. For ARP request packet to this "virtual IP", those two work stations
   will return the MAC broadcast address. Then, all the packets to the
   "virtual IP" will be broadcast to this subnet and those two machines
   will get such packtes.
4. Before such packets gets into the TCP/IP stack, use a hash function
   to filter the packets. Say, workstation A will accept packets whose
   source IP is an odd number and discard the packets with even-number
   source IP.
5. For the outgoing packets from those two workstations, change the source
   IP address to be the "virtual IP".
6. Have another thread keep ping each other, once another workstation
   crashes, change my hash function to accept all the packets to the
   "virtual IP". Whenever another workstation resumes, switch back to
   the original hash function.

   Do you think if this approach will work? There is also a question I
am not quite sure, can two machines's NICs be aliased to the same "virtual
IP"? Will it cause some conflicts? And, it seems I need to change the
linux kernel source code. I am not pretty sure where is the location of
the source code related to the above operations. Like, can you tell me the
location of the linux kernel source code to answer an ARP request packet,
to build a hash function to filter the incoming IP packets before it
enters the TCP/IP stack?

   Thanks a lot.

best,
chuck

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Accelerated TCP/IP support from kernel

[David S. Miller]

Bharath Madhavan writes:
 >  I am looking into a scenario where we have a NIC which performs 
 > all the TCP/IP processing and basically the core CPU offloads all data from
 > the socket level interface onwards to this NIC. 

Why would you ever want to do this?

Point 1: Support for new TCP techniques and bug fixes are hard enough
to propagate to user's systems as it is with the implementation being
done in software.

Point 2: If I find a bug in the cards TCP implementation, will I be
able to get at the source for the firmware and fix it?  Likely the
answer to this is no.

Every couple years a few vendors make cards like this, yet ignore
these core issues.  It is currently impractical to use these kinds of
cards today except in a few very special case situations.

Furthermore, the actual protocol processing overhead is quite small
and almost neglible especially on today's gigahertz beasts.  The data
copy is where the time is spent, and checksum offload takes care of
that.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] null bugs in 2.4.4 and 2.4.4-ac8

[Anton Altaparmakov]

At 22:09 24/05/2001, Dawson Engler wrote:
[snip]
>-
>[BUG]
>/u2/engler/mc/oses/linux/2.4.4-ac8/fs/ntfs/support.c:244:ntfs_dupuni2map: 
>ERROR:NULL:243:244: Passing unknown ptr "buf"! as arg 0 to call "memcpy"! 
>set by 'kmalloc':244 [nbytes = 1]
> wchar_t uni = in[i];
> if ((chl = nls->uni2char(uni, charbuf,
> NLS_MAX_CHARSET_SIZE)) > 0) {
> /* adjust result buffer */
> if (chl > 1) {
>Start --->
> buf = ntfs_malloc(*out_len + chl 
> - 1);
>Error --->
> memcpy(buf, result, o);
> ntfs_free(result);
> result = buf;
> *out_len += (chl - 1);
>-

Thanks. I was just about to submit a large patch anyway, so I will fix this 
and submit shortly.

Anton


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sf.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dying disk and filesystem choice.

[Alan Cox]

> IMHO we are not that deep into code freeze anymore. Freevxfs got added
> in linux-2.4.5-pre*, so I think that a patch that adds a useful feature
> like badblock support would be OK.

FreeVxFS changes precisely nothing in the behaviour of any other fs - its like
adding a new driver.

Updating Reiserfs requires a lot more care because it has the potential to
harm existing stable setups

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Accelerated TCP/IP support from kernel

[Bharath Madhavan]

Hello all,
I am looking into a scenario where we have a NIC which performs 
all the TCP/IP processing and basically the core CPU offloads all data from
the socket level interface onwards to this NIC. 
Can Linux do this as of now. I saw some limited support like TCP/IP
checksumming
being done in HW (ex: 3c905c) and linux supports it. I also saw the
ZERO_COPY
feature in linux code. 
My question is can there be support for entire (almost) TCP/IP to be
offloaded 
to a NIC card. I noticed some NIC cards by Alacritec and Applicom who have 
such NICs but it looks like the support from Linux would be quite a bit of
work.
Basically Linux needs to support all socket calls as it will usually but
the socket interface must be intelligent enough to call different drivers(!)
for those NIC cards and thus bypassing the whole of TCP/IP stack of Linux.
Is this possible at all and if so, is anyone doing this???
I talked to a vendor who does this NIC and he said that they provide a
library
for linux which means that they have proprietery functions for using their
NIC
and thus this cannot be used in the standard socket interface way. That is a
big
limitation and not of much use. Basically, I am looking into a case where 
the kernel code needs to be changed to handle this
Looking eagerly for some help/advice from you folks
Thanks a lot
Bharath
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] free bugs in 2.4.4 and 2.4.4-ac8

[Justin Carlson]

On Thu, 24 May 2001, Dawson Engler wrote:
> Hi All,
> 
> Enclosed are 24 bugs where code uses memory that has been freed.  The
> good thing about these bugs is that they are easy to fix.  (Note: About
> 5 of these have had patches submitted, so this list is a bit out of
> date.)

Enclosed is a patch for these.  It's untested, as I don't have any of this
hardware, but all the fixes I made seemed relatively obvious.  Of course, by
saying this, I've doomed myself to at least 1 stupid mistake.

There are 3 spots I didn't fix, just because I'm not sure what the appropriate
fix is.  On in the ipv6 udp code, I'm unsure as to what the intent is.  The 2
rio code spots require some more serious restructuring to fix the debug message.

Patch is against 2.4.4-ac16

-Justin

--- linux-2.4.4-ac16/drivers/atm/iphase.c   Thu May 24 14:24:46 2001
+++ linux/drivers/atm/iphase.c  Thu May 24 14:43:25 2001
@@ -1318,12 +1318,12 @@
   if (ia_vcc == NULL)
   {
  atomic_inc(&vcc->stats->rx_err);
- dev_kfree_skb_any(skb);
 #if LINUX_VERSION_CODE >= 0x20312
  atm_return(vcc, atm_guess_pdu2truesize(skb->len));
 #else
  atm_return(vcc, atm_pdu2truesize(skb->len));
 #endif
+ dev_kfree_skb_any(skb);
  goto INCR_DLE;
}
   // get real pkt length  pwang_test
@@ -1334,7 +1334,6 @@
   (skb->len - sizeof(struct cpcs_trailer
   {
  atomic_inc(&vcc->stats->rx_err);
- dev_kfree_skb_any(skb);
  IF_ERR(printk("rx_dle_intr: Bad  AAL5 trailer %d (skb len %d)", 
 length, skb->len);)
 #if LINUX_VERSION_CODE >= 0x20312
@@ -1342,6 +1341,7 @@
 #else
  atm_return(vcc, atm_pdu2truesize(skb->len));
 #endif 
+ dev_kfree_skb_any(skb);
  goto INCR_DLE;
   }
   skb_trim(skb, length);
diff -ru linux-2.4.4-ac16/drivers/block/cciss.c linux/drivers/block/cciss.c
--- linux-2.4.4-ac16/drivers/block/cciss.c  Thu May 24 14:24:47 2001
+++ linux/drivers/block/cciss.c Thu May 24 14:28:26 2001
@@ -680,6 +680,7 @@
{
kfree(buff);
cmd_free(h, c, 0);
+   return ( -EFAULT);
}
 }
 kfree(buff);
diff -ru linux-2.4.4-ac16/drivers/char/drm/gamma_dma.c 
linux/drivers/char/drm/gamma_dma.c
--- linux-2.4.4-ac16/drivers/char/drm/gamma_dma.c   Mon Dec 11 12:39:44 2000
+++ linux/drivers/char/drm/gamma_dma.c  Thu May 24 14:55:44 2001
@@ -555,12 +555,6 @@
current->state = TASK_RUNNING;
DRM_DEBUG("%d running\n", current->pid);
remove_wait_queue(&last_buf->dma_wait, &entry);
-   if (!retcode
-   || (last_buf->list==DRM_LIST_PEND && !last_buf->pending)) {
-   if (!waitqueue_active(&last_buf->dma_wait)) {
-   drm_free_buffer(dev, last_buf);
-   }
-   }
if (retcode) {
DRM_ERROR("ctx%d w%d p%d c%d i%d l%d %d/%d\n",
  d->context,
@@ -571,6 +565,12 @@
  last_buf->list,
  last_buf->pid,
  current->pid);
+   }
+   if (!retcode
+   || (last_buf->list==DRM_LIST_PEND && !last_buf->pending)) {
+   if (!waitqueue_active(&last_buf->dma_wait)) {
+   drm_free_buffer(dev, last_buf);
+   }
}
}
return retcode;
diff -ru linux-2.4.4-ac16/drivers/message/i2o/i2o_pci.c 
linux/drivers/message/i2o/i2o_pci.c
--- linux-2.4.4-ac16/drivers/message/i2o/i2o_pci.c  Thu May 24 14:24:52 2001
+++ linux/drivers/message/i2o/i2o_pci.c Thu May 24 14:40:17 2001
@@ -254,7 +254,6 @@
 #else
i2o_delete_controller(c);
 #endif /* MODULE */
-   kfree(c);
iounmap(mem);
return -EBUSY;
}
diff -ru linux-2.4.4-ac16/drivers/net/hamradio/bpqether.c 
linux/drivers/net/hamradio/bpqether.c
--- linux-2.4.4-ac16/drivers/net/hamradio/bpqether.cWed Apr 18 14:40:06 2001
+++ linux/drivers/net/hamradio/bpqether.c   Thu May 24 14:48:02 2001
@@ -191,9 +191,9 @@
 
unregister_netdevice(&bpq->axdev);
kfree(bpq);
+   } else {
+   bpq_prev = bpq;
}
-
-   bpq_prev = bpq;
}
 
restore_flags(flags);
diff -ru linux-2.4.4-ac16/drivers/net/wan/lapbether.c linux/drivers/net/wan/lapbether.c
--- linux-2.4.4-ac16/drivers/net/wan/lapbether.cWed Apr 18 14:40:07 2001
+++ linux/drivers/net/wan/lapbet

Re: [CHECKER] null bugs in 2.4.4 and 2.4.4-ac8

[Willem Riede]

Dawson Engler wrote:
> 
> Hi All,
> 
> Enclosed are 103 potential errors where code gets a pointer from a
> possibly-failing routine (kmalloc, etc) and dereferences it without
>
> [BUG] osst_do_scsi will never return NULL if argument SRpnt isn't NULL. But they 
>copy SRpnt back by *aSRpnt, implies it could be NULL

No. It implies SRpnt could have changed. The functions flagged
(osst_read_back_buffer_and_rewrite and osst_reposition_and_retry)
cannot be reached with SRpnt == NULL. So these are false alarms.

> 
>/u2/engler/mc/oses/linux/2.4.4/drivers/scsi/osst.c:1163:osst_read_back_buffer_and_rewrite:
> ERROR:NULL::1163: Using unknown ptr "SRpnt" illegally! set by 
>'osst_do_scsi':1163 [nbytes = 216]
> #if DEBUG
> if (debugging)
> printk(OSST_DEB_MSG "osst%d: About to attempt to write to 
>frame %d\n", dev, new_block+i);
> #endif
> SRpnt = osst_do_scsi(SRpnt, STp, cmd, OS_FRAME_SIZE, SCSI_DATA_WRITE,
> Start --->
> STp->timeout, MAX_WRITE_RETRIES, TRUE);
> 
> ... DELETED 46 lines ...
> 
> }
> }
> if (flag) {
> if ((SRpnt->sr_sense_buffer[ 2] & 0x0f) == 13 &&
>  SRpnt->sr_sense_buffer[12] ==  0 &&
> Error --->
>  SRpnt->sr_sense_buffer[13] ==  2) {
> printk(KERN_ERR "osst%d: Volume overflow in write 
>error recovery\n", dev);
> vfree((void *)buffer);
> return (-EIO);  /* hit end of tape = 
>fail */
> 

Regards. Willem Riede.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.4.4ac15/16] problems with stat or link

[Andreas Hartmann]

Hallo all,


I get the mentioned error as often as longer the system is running. E.g.:
> ls kviewshell/.libs/libkmultipage.so

The following is what strace say's:
(The problem-zone can be found between two lines)

3795  execve("/usr/local/bin/ls", ["ls", "-l", 
"kviewshell/.libs/libkmultipage.so"], [/* 54 vars */]) = 0
3795  brk(0)= 0x804fbf0
3795  open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or 
directory)
3795  open("/etc/ld.so.cache", O_RDONLY) = 4
3795  fstat(4, {st_mode=S_IFREG|0644, st_size=48328, ...}) = 0
3795  mmap(NULL, 48328, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40015000
3795  close(4)  = 0
3795  open("/lib/libc.so.6", O_RDONLY)  = 4
3795  fstat(4, {st_mode=S_IFREG|0755, st_size=4145658, ...}) = 0
3795  read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \217\1"..., 
4096) = 4096
3795  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x40021000
3795  mmap(NULL, 982684, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40022000
3795  mprotect(0x4010a000, 32412, PROT_NONE) = 0
3795  mmap(0x4010a000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 
0xe7000) = 0x4010a000
3795  mmap(0x4010f000, 11932, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4010f000
3795  close(4)  = 0
3795  mprotect(0x40022000, 950272, PROT_READ|PROT_WRITE) = 0
3795  mprotect(0x40022000, 950272, PROT_READ|PROT_EXEC) = 0
3795  munmap(0x40015000, 48328) = 0
3795  personality(PER_LINUX)= 0
3795  getpid()  = 3795
3795  brk(0)= 0x804fbf0
3795  brk(0x804fc20)= 0x804fc20
3795  brk(0x805)= 0x805
3795  open("/share/locale/locale.alias", O_RDONLY) = 4
3795  SYS_197(0x4, 0xbfffb538, 0x4010e3a0, 0x804fc18, 0x4) = 0
3795  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x40015000
3795  read(4, "# Locale name alias data base.\n#"..., 4096) = 2265
3795  brk(0x8051000)= 0x8051000
3795  read(4, "", 4096) = 0
3795  close(4)  = 0
3795  munmap(0x40015000, 4096)  = 0
[...]
3795  open("/share/locale/de_DE/LC_MESSAGES", O_RDONLY) = 4
3795  fstat(4, {st_mode=S_IFDIR|0555, st_size=66, ...}) = 0
3795  close(4)  = 0
3795  open("/share/locale/de_DE/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY) = 4
3795  fstat(4, {st_mode=S_IFREG|0444, st_size=44, ...}) = 0
3795  mmap(NULL, 44, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40015000
3795  close(4)  = 0
[]
3795  open("/share/locale/de_DE/LC_MONETARY", O_RDONLY) = 4
3795  fstat(4, {st_mode=S_IFREG|0444, st_size=94, ...}) = 0
3795  mmap(NULL, 94, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40016000
3795  close(4)  = 0
3795  brk(0x8052000)= 0x8052000
[...]
3795  open("/share/locale/de_DE/LC_COLLATE", O_RDONLY) = 4
3795  fstat(4, {st_mode=S_IFREG|0444, st_size=29970, ...}) = 0
3795  mmap(NULL, 29970, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40017000
3795  close(4)  = 0
[...]
3795  open("/share/locale/de_DE/LC_TIME", O_RDONLY) = 4
3795  fstat(4, {st_mode=S_IFREG|0444, st_size=492, ...}) = 0
3795  mmap(NULL, 492, PROT_READ, MAP_PRIVATE, 4, 0) = 0x4001f000
3795  close(4)  = 0
[...]
3795  open("/share/locale/de_DE/LC_NUMERIC", O_RDONLY) = 4
3795  fstat(4, {st_mode=S_IFREG|0444, st_size=27, ...}) = 0
3795  mmap(NULL, 27, PROT_READ, MAP_PRIVATE, 4, 0) = 0x4002
3795  close(4)  = 0
[...]
3795  open("/share/locale/de_DE/LC_CTYPE", O_RDONLY) = 4
3795  fstat(4, {st_mode=S_IFREG|0444, st_size=87756, ...}) = 0
3795  mmap(NULL, 87756, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40112000
3795  close(4)  = 0
3795  time(NULL)= 990738510
3795  ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
3795  ioctl(1, TIOCGWINSZ, {ws_row=50, ws_col=80, ws_xpixel=0, ws_ypixel=0}) 
= 0
3795  brk(0x8055000)= 0x8055000

-

3795  lstat("kviewshell/.libs/libkmultipage.so", 0xb718) = -1 EIO 
(Input/output error)

---

3795  write(2, "ls: ", 4)   = 4
3795  write(2, "kviewshell/.libs/libkmultipage.s"..., 33) = 33
[...]
3795  open("/share/locale/de/LC_MESSAGES/libc.mo", O_RDONLY) = 4
3795  fstat(4, {st_mode=S_IFREG|0644, st_size=94208, ...}) = 0
3795  mmap(NULL, 94208, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40128000
3795  close(4)  = 0
3795  write(2, ": Eingabe-/Ausgabefehler", 24) = 24
3795  write(2, "\n", 1) = 1
3795  close(1)  = 0
3795  _exit(1)  = ?


Another example is:
> umount /boot


That's what strace is 

Re: [CHECKER] error path memory leaks in 2.4.4 and 2.4.4-ac8

[David Woodhouse]

[EMAIL PROTECTED] said:
> 1 |   drivers/mtd/mtdchar.c 
> 1 |   fs/jffs/jffs_fm.c 
> 2 |   fs/jffs/intrep.c
> 1 |   drivers/mtd/slram.c
> 1 |   drivers/mtd/ftl.c
> 1 |   drivers/mtd/mtdram.c

These are all now either fixed or obsoleted in my tree, and I will send a 
patch to Linus shortly. Thankyou. 

Do you find it useful to get a response such as this? Are you keeping track
of the bugs you find? (Or is it simply reassuring to confirm that someone's
paying attention? :)

[EMAIL PROTECTED] said:
> Here are 37 errors where variables >= 1024 bytes are allocated on a
> function's stack.
> 2 |   fs/jffs2/compr_rtime.c

int positions[256];

I believe we can make that a short. Arjan?

--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

[Hans Reiser]

Daniel Phillips wrote:
> 
> On Tuesday 22 May 2001 22:10, Andreas Dilger wrote:
> > Peter Braam writes:
> > > File system journal recovery can corrupt a snapshot, because it
> > > copies data that needs to be preserved in a snapshot. During
> > > journal replay such data may be copied again, but the source can
> > > have new data already.
> >
> > The way it is implemented in reiserfs is to wait for existing
> > transactions to complete, entirely flush the journal and block all
> > new transactions from starting.  Stephen implemented a journal flush
> > API to do this for ext3, but the hooks to call it from LVM are not in
> > place yet.  This way the journal is totally empty at the time the
> > snapshot is done, so the read-only copy does not need to do journal
> > recovery, so no problems can arise.
> 
> I suppose I'm just reiterating the obvious, but we should eventually
> have a generic filesystem transaction API at the VFS level, once we
> have enough data points to know what the One True API should be.
> 
> --
> Daniel
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


Daniel, implementing transactions is not a trivial thing as you probably know. 
It requires that you resolve such issues as, what happens if the user forgets to
close the transaction, issues of lock/transaction duration, of transaction
batching, of levels of isolation, of concurrent transactions modifying global fs
metadata and some but not all of those concurrent transactions receiving a
rollback, and of permissions relating to keeping transactions open.  I would
encourage you to participate in the reiser4 design discussion we will be having
over the next 6 months, and give us your opinions.  Josh will be leading that
design effort for the ReiserFS team.

Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dying disk and filesystem choice.

[monkeyiq]

Hans Reiser <[EMAIL PROTECTED]> writes:

> 
> 
> No, reiserfs does have badblock support
> 
> You just have to get it as a separate patch from us because it was written after
> code freeze.
> 
> Hans
> 

It might be nice to have a link to that patch from the "download" page.
I didn't see that patch the first time from
ftp://ftp.namesys.com/pub/misc-patches/

because I assumed that the interesting patches were linked from the 
downloads page. Atleast a hint that there is a badblocks patch available
on the ftp site on the downloads page, so that the reader can go grab 
this patch. 

Hopefully this will extend my mileage until drive replacement :)
Though I think I'll back a few more things up before attempting 
a kernel compile.


-- 
---
It's the question, http://witme.sourceforge.net
If you think education is expensive, try ignorance.
-- Derek Bok, president of Harvard

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.2.19+ide: corrupts ide tape output

[Camm Maguire]

Greetings, and thank you for this information!  I've just confirmed
this.  Both of my ATAPI tapes don't work reliably with the Promise
Ultra100, but do work with the on board ALI 15x3 chipsets.  Both disks
in this box appear to work with both sets of controllers.  After
considerable difficulty, I'm now booting off of the off-board Promise,
and all looks stable.

Question -- is the lack of support for ATAPI on the Promise Ultra100 a
hardware, or a driver/software, issue?

Take care,

Mikael Pettersson <[EMAIL PROTECTED]> writes:

> On 21 May 2001 14:49:55 -0400, Camm Maguire <[EMAIL PROTECTED]> wrote:
> 
> >Greetings!  2.2.19+ide, applied the patch because this box has a new
> >Promise PDC20267 ide controller.  14GB HP Colorado tape drive.  Before
> >we installed the new ide controller and patched the kernel, i.e. with
> >unpatched 2.2.19 running on a different ide controller, this setup
> >works just fine.  Now I get the following occasionally, which results
> >in corrupted dumps to tape:
> >
> >May 21 10:27:47 intech9 kernel: hdh: status error: status=0x40 { DriveReady }
> >May 21 10:27:47 intech9 kernel: ide-scsi: Strange, packet command initiated yet DRQ 
>isn't asserted
> 
> You added a Promise Ultra100 PCI card, right?
> >From what I hear, it doesn't support ATAPI devices well, only disks.
> So if you moved the HP tape drive to the PDC, move it back to
> the mainboard's IDE controller.
> Also, don't disable the mainboard's controller thinking you can save
> some interrupts that way. Andre Hedrick (Linux IDE guy) once wrote
> that this could cause the PDC to grab IRQ 14, which had some nasty
> side-effects.
> 
> (My main box runs with disks on a Promise Ultra100 card and
> ATAPI CD-RW and tape on the mainboard's IDE (440BX) controller.
> Both 2.2+ide and 2.4 work fine.)
> 
> /Mikael
> 
> 

-- 
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dying disk and filesystem choice.

[Hans Reiser]

Erik Mouw wrote:
> 
> On Thu, May 24, 2001 at 09:53:45AM -0700, Hans Reiser wrote:
> > No, reiserfs does have badblock support
> >
> > You just have to get it as a separate patch from us because it was
> > written after code freeze.
> 
> IMHO we are not that deep into code freeze anymore. Freevxfs got added
> in linux-2.4.5-pre*, so I think that a patch that adds a useful feature
> like badblock support would be OK.
> 
> Erik
> 
> --
> J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
> of Electrical Engineering, Faculty of Information Technology and Systems,
> Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
> Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
> WWW: http://www-ict.its.tudelft.nl/~erik/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

vxfs is probably a completely separate fs that won't destabilize other
filesystems, or at least I hope so.  ReiserFS is stable code now, we aren't
going to change that by adding features unless they go into the ac series for
six weeks or so first.  ReiserFS is the SuSE recommended FS, and we can't go
destabilizing it.  I am told by sistina.com (maintainers of LVM) that in their
surveys of the users of LVM, 90% use ReiserFS, and the users of LVM tend very
much to be persons with mission critical servers.  We sent Linus a patch to mark
us as stable not experimental.  When we say stable, it means something.  Right
now it means zero (yes, zero) new bug reports that are not user error or old
versions or fsck, since 2.4.4 came out.  

fsck is improving dramatically in stability every week.  I used it myself last
week, and got my data back minus the root directory after trashing the front of
my partition accidentally.  (Which gave me a chance to review its end user
usability, which is also improving.)  We aren't yet ready to pass the zero a
random block and see it recover always excepting what was zero'd test, but we
will be before long.  One of the things we realized recently is that if the user
knows what got trashed, and he can tell this to the FS, it can be very useful
for bitmap blocks.  Sorry, I wander here.

Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

[Alexander Viro]

On Thu, 24 May 2001, Edgar Toernig wrote:

> > What *won't* happen is, you won't get side effects from opening
> > your serial ports (you'd have to open them without O_DIRECTORY
> > to get that) so that seems like a little step forward.
> 
> As already said: depending on O_DIRECTORY breaks POSIX compliance
> and that alone should kill this idea...

What really kills that idea is the fact that you can trick applications
into opening your serial ports _without_ O_DIRECTORY.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] free bugs in 2.4.4 and 2.4.4-ac8

[Alexander Viro]

On Thu, 24 May 2001, Dawson Engler wrote:

> [BUG] [BAD] Returns a freed pointer -- very very bad.

... and easy to fix.
> /u2/engler/mc/oses/linux/2.4.4/fs/proc/generic.c:438:proc_symlink: 
>ERROR:FREE:430:438: WARN: Use-after-free of "ent"! set by 'kfree':430
>   ent->namelen = len;
>   ent->nlink = 1;
>   ent->mode = S_IFLNK|S_IRUGO|S_IWUGO|S_IXUGO;
>   ent->data = kmalloc((ent->size=strlen(dest))+1, GFP_KERNEL);
>   if (!ent->data) {
> Start --->
>   kfree(ent);
>   goto out;
>   }
>   strcpy((char*)ent->data,dest);
> 
>   proc_register(parent, ent);
>   
> out:
> Error --->
>   return ent;


--- linux/fs/proc/generic.c.old Fri Feb 16 21:01:43 2001
+++ linux/fs/proc/generic.c Thu May 24 17:13:22 2001
@@ -428,6 +428,7 @@
ent->data = kmalloc((ent->size=strlen(dest))+1, GFP_KERNEL);
if (!ent->data) {
kfree(ent);
+   ent = NULL;
goto out;
}
strcpy((char*)ent->data,dest);

Linus, apply it, please.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[CHECKER] user-pointer bugs in 2.4.4 and 2.4.4-ac8

[Dawson Engler]

Hi All,

Enclosed are 10 probable security holes where code treats a pointer as
a bad user pointer in one place (by passing it as an argument to a
*_user or verify_area routine) but then dereferences it, or passes it
to a routine that does dereference it somewhere else.

We've reported many of these bugs before. 

Summary for 
2.4.4ac8-specific errors   = 4
2.4.4-specific errors = 0
Common errors = 6
Total = 10

Dawson

# BUGs  |   File Name
5   |   drivers/isdn/eicon/linchr.c
3   |   drivers/net/appletalk/ipddp.c
1   |   net/decnet/af_decnet.c
1   |   drivers/telephony/ixj.c


# 2.4.4ac8 specific errors
#
-
[BUG] supposed to at least be bad form.
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/isdn/eicon/linchr.c:64:do_ioctl: 
ERROR:PARAM:62:64: tainted var 'pDivaConfig' (from line 62) used as arg 0 to 
'DivasCardConfig'
switch (command)
{
case DIA_IOCTL_CONFIG:
pDivaConfig = (dia_config_t *) arg;

Start --->
if (!verify_area(VERIFY_READ, pDivaConfig, 
sizeof(dia_config_t)))
{
Error --->
DivasCardConfig(pDivaConfig);
}
else
{
-
[BUG]supposed to at least be bad form.
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/isdn/eicon/linchr.c:186:do_ioctl: 
ERROR:PARAM:184:186: tainted var 'mem_block' (from line 184) used as arg 0 to 
'DivasGetMem'
return 0;

case DIA_IOCTL_GET_MEM:
mem_block = (mem_block_t *) arg;

Start --->
if (!verify_area(VERIFY_WRITE, mem_block, sizeof(mem_block_t)))
{
Error --->
DivasGetMem(mem_block);
}
else
{
-
[BUG]supposed to at least be bad form.
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/isdn/eicon/linchr.c:131:do_ioctl: 
ERROR:PARAM:129:131: tainted var 'pDivaLog' (from line 129) used as arg 0 to 'DivasLog'
return 0;

case DIA_IOCTL_LOG:
pDivaLog = (dia_log_t *) arg;

Start --->
if (!verify_area(VERIFY_READ, pDivaLog, sizeof(dia_log_t)))
{
Error --->
DivasLog(pDivaLog);
}
else
{
-
[BUG]supposed to at least be bad form.
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/isdn/eicon/linchr.c:172:do_ioctl: 
ERROR:PARAM:142:172: tainted var 'arg' (from line 142) used as arg 0 to 'DivasGetList'
}
return 0;

case DIA_IOCTL_XLOG_REQ:

Start --->
if (!verify_area(VERIFY_READ, (void *)arg, sizeof(word)))

... DELETED 24 lines ...

case DIA_IOCTL_GET_LIST:
DPRINTF(("divas: DIA_IOCTL_GET_LIST"));

if (!verify_area(VERIFY_WRITE, (void *)arg, 
sizeof(dia_card_list_t)))
{
Error --->
DivasGetList((dia_card_list_t *)arg);
}
else
{



# errors common to both

#
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/net/appletalk/ipddp.c:268:ipddp_ioctl: 
ERROR:PARAM:268:268: tainted var 'rt' (from line 268) used as arg 0 to 
'ipddp_find_route'
{
case SIOCADDIPDDPRT:
return (ipddp_create(rt));

case SIOCFINDIPDDPRT:

Error --->
if(copy_to_user(rt, ipddp_find_route(rt), sizeof(struct 
ipddp_route)))
-
[BUG] but minor i think
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/isdn/eicon/linchr.c:97:do_ioctl: 
ERROR:PARAM:95:97: Deref tainted var 'pDivaStart' (tainted from line 95)
return 0;

case DIA_IOCTL_START:
pDivaStart = (dia_start_t *) arg;

Start --->
if (!verify_area(VERIFY_READ, pDivaStart, sizeof(dia_start_t)))
{
Error --->
return DivasCardS

Re: Dual Athlon on 2.2.19 ?

[Johannes Erdfelt]

On Thu, May 24, 2001, Prasanna P Subash <[EMAIL PROTECTED]> wrote:
> Without the patch below the boot up would hang right after it detected the
> ide devices.
> 
> After applying the patch it booted all the way but the keyboard would hang.
> 
> BTW I'm trying to port this patch back to the 2.2.18 TL-Kernel. Are there
> anymore changes I have to look at ?

There were 2 patches. The one that went into 2.2.20-pre1 (not the patch
you just sent) and the patch you just sent. You need both.

JE

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops on booting 2.4.4

[Harm Verhagen]

Pete Zaitcev wrote:

> > May 23 02:46:24 localhost kernel: Process kudzu (pid: 219,
> > stackpage=c7845000)
> > May 23 02:46:24 localhost kernel: Stack: c12607e0 0400 0400
> > c73aa000 c122a060 c122a05c c122a058 c88fbb20
> > May 23 02:46:24 localhost kernel:03f1 03f1 c014ab80
> > c73aa3f1 c7845f9c  0400 ffea
> > May 23 02:46:24 localhost kernel:c7f43f60 0400 b4b8
> > c7f2e220 c12607e0   c73aa000
> > May 23 02:46:24 localhost kernel: Call Trace: []
> > [proc_file_read+184/464] [sys_read+142/196] [system_call+51/56]
> > May 23 02:46:24 localhost kernel: Call Trace: [] []
> > [] []
>
> A module deregistered incorrectly, or has a race between
> post-load activities and unload. One way or another it left
> a dangling proc entry.
>
> The oops does not provide off-stack information, so it's impossible
> to tell what particular modules is the culprit.
>
> > May 23 02:46:24 localhost kernel: hub.c: USB new device connect on
> > bus1/2, assigned device number 2
> > May 23 02:46:24 localhost kernel: usb.c: USB device 2 (vend/prod
> > 0x4a9/0x2204) is not claimed by any active driver.
>
> What is this thing you have on USB? Try to run without it.
>
> -- Pete

It's a canon usb scanner.
running with or without it does not make any difference.

kind regards,
Harm

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Ramdisk Initialization Problem

[Jaswinder Singh]

I am using kernel 2.4.1 with compressed Ramdisk on  Hitachi SH board ,
with no battery.   When i run kernel first time , it works fine , it
uncompress Ramdisk and i get my shell prompt .But when i restart it
second time (with out  removing power cable ) kernel dies when
uncompressing Ramdisk.   But , if i remove my power supply for more than 5
minutes , and then i start again , it works again.   It seems that in 2.4.1
and/or later versions has  Ramdisk Initailization or uninitialised memory
problem. But i faced no problem  with 2.2.12 kernel.   Thank you,  

Best Regards,   Jaswinder (and his wonder machine).
--
These are my opinions not  3Di.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual Athlon on 2.2.19 ?

[Prasanna P Subash]

Without the patch below the boot up would hang right after it detected the ide devices.

After applying the patch it booted all the way but the keyboard would hang.

BTW I'm trying to port this patch back to the 2.2.18 TL-Kernel. Are there anymore 
changes I have to
look at ?

--- arch/i386/kernel/io_apic.c.old  Wed May 16 12:48:03 2001
+++ arch/i386/kernel/io_apic.c  Wed May 16 12:55:30 2001
@@ -204,6 +204,8 @@
 /*
  * We disable IO-APIC IRQs by setting their 'destination CPU mask' to
  * zero. Trick by Ramesh Nalluri.
+ * Not anymore. This causes problems on some IO-APIC's, notably AMD 760MP's
+ * So we do it a more 2.4 kind of way now which should be safer -jerdfelt
  */
 DO_ACTION( mask,0, |= 0x0001, io_apic_sync(entry->apic))/* mask = 1 */
 DO_ACTION( unmask,  0, &= 0xfffe, )/* mask = 0 */
@@ -646,8 +648,8 @@

entry.delivery_mode = dest_LowestPrio;
entry.dest_mode = 1;/* logical delivery */
-   entry.mask = 0; /* enable IRQ */
-   entry.dest.logical.logical_dest = 0xff; /* but no route */
+   entry.mask = 1; /* disable IRQ */
+   entry.dest.logical.logical_dest = 0xff;

idx = find_irq_entry(apic,pin,mp_INT);
if (idx == -1) {


On Thu, May 24, 2001 at 03:36:54PM -0400, Johannes Erdfelt wrote:
> On Thu, May 24, 2001, Prasanna P Subash <[EMAIL PROTECTED]> wrote:
> > I have a dual athlon on the 760MP chipset.
> > 2.2.20pre1 and 2 dont work. I got it to work partly after applying Johannes
> > Erdfel's 760MP patch in io_apic.c. Even after applying the patch, there
> > are messages like
> 
> 2.2.20pre1 and pre2 both have the patch I created already applied. If
> you had to apply them yourself then something is wrong.
> 
> > hdc: IRQ probe failed(0)
> > hdd: IRQ probe failed(0)
> > hde: IRQ probe failed(0)
> > 
> > hdc: lost interrupt
> > hdc: lost interrupt
> > 
> > and then the machine hangs randomly. I an guessing the io_apic does not
> > route the interrupts correctly.
> 
> That would be the problem.
> 
> Which patch of mine did you apply? Which motherboard are you doing your
> testing with?
> 
> JE

-- 
Prasanna Subash   ---   [EMAIL PROTECTED]   --- TurboLinux, INC

Linux, the choice  | The only real advantage to punk music is
of a GNU generation   -o)  | that nobody can whistle it. 
Kernel 2.4.1  /\\  | 
on a i686_\\_v | 
   | 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[CHECKER] error path memory leaks in 2.4.4 and 2.4.4-ac8

[Dawson Engler]

Hi All,

This checker warns when you do not free allocated memory on failure paths.
The error messages with "type=SECURITY" were emitted when the error path
was triggered by a failed copy_*_user or eqvuivalent --- bad people can
easily use these to make the kernel lose memory.

Summary for 
2.4.4ac8-specific errors= 5
2.4.4-specific errors   = 1
Common errors   = 17
Total   = 23

Note: this is a very small subset of these errors --- I was a bit lazy
about inspecting these logs.

Dawson

# BUGs  |   File Name
4   |   drivers/scsi/scsi_ioctl.c
3   |   fs/freevxfs/vxfs_super.c
2   |   drivers/telephony/ixj.c
1   |   drivers/net/wan/lmc/lmc_main.c
1   |   drivers/acpi/driver.c
1   |   drivers/scsi/aic7xxx/aic7xxx_linux_pci.c
1   |   net/irda/irlan/irlan_common.c
1   |   drivers/isdn/isdn_ppp.c
1   |   fs/jffs/jffs_fm.c
1   |   drivers/mtd/mtdchar.c
1   |   drivers/block/cciss.c
1   |   net/wanrouter/wanproc.c
1   |   drivers/isdn/avmb1/capi.c
1   |   net/wanrouter/wanmain.c
1   |   fs/cmsfs/cmsfsvfs.c
1   |   drivers/net/pcmcia/aironet4500_cs.c
1   |   drivers/media/video/zr36120.c

Boilerplate disclaimer:
- this is part of a one-time large batch of errors.  In the future,
  we'll send out incremental bug reports along with a pointer to
  the bug database on our website.

- as always, bugs may not be errors --- we have inspected the
  error logs to counter this.

- bugs may be missing in one distribution versus the other because
  we did not compile that file (or failed to fully compile it).
  It can be worthwhile to cross check important bugs to make sure
  they've been killed.

- bugs are sorted roughly by severity and ease-of-diagnosis.
  The highest ranked bugs are "SECURITY" which (in most of the
  examples) are primarily denial-of-service vulnerabilities
  where the user could trigger the bug when they canted to.
  Ease-of-diagnosis is currently crude: we rank LOCAL errors
  over GLOBAL (GLOBAL require looking at call chains) and then
  distance between error source and manifestation as the next
  (closer is better)

- these errors are a subset of the ones we found --- we typically
  did not inspect many of the global errors, since there were so
  many local ones.  If you'd like to see uninspected files, let
  me know.



# 2.4.4ac8 specific errors
#
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/block/cciss.c:613:cciss_ioctl: 
ERROR:INVERSE:605:613: UNREVERSED 'buff' on error path! set by 'kmalloc':605 
[nbytes=1] [rank=easy] [type=SECURITY]
/* Check kmalloc limits */
if(iocommand.buf_size > 128000)
return -EINVAL;
if(iocommand.buf_size > 0)
{
Start --->
buff =  kmalloc(iocommand.buf_size, GFP_KERNEL);
if( buff == NULL) 
return -EFAULT;
}
if (iocommand.Request.Type.Direction == XFER_WRITE)
{
/* Copy the data into the buffer we created */ 
if (copy_from_user(buff, iocommand.buf, iocommand.buf_size))
Error --->
return -EFAULT;
}
if ((c = cmd_alloc(h , 0)) == NULL)
{
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4-ac8/fs/freevxfs/vxfs_super.c:171:vxfs_read_super: 
ERROR:INVERSE:159:171: UNREVERSED 'infp' on error path! set by 'kmalloc':159 
[nbytes=36] [rank=easy]
struct vxfs_sb  *rsbp;
struct buffer_head  *bp;
u_long  bsize;
kdev_t  dev = sbp->s_dev;

Start --->
infp = kmalloc(sizeof(struct vxfs_sb_info), GFP_KERNEL);
if (!infp) {
printk(KERN_WARNING "vxfs: unable to allocate incore superblock\n");
return NULL;
}
memset(infp, 0, sizeof(struct vxfs_sb_info));

bsize = vxfs_validate_bsize(dev);

bp = bread(dev, 1, bsize);
if (!bp) {
printk(KERN_WARNING "vxfs: unable to read disk superblock\n");
Error --->
return NULL;
}

rsbp = (struct vxfs_sb *)bp->b_data;
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4-ac8/fs/freevxfs/vxfs_super.c:177:vxfs_read_super: 
ERROR:INVERSE:159:177: UNREVERSED 'infp' on error path! set by 'kmallo

[CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

[Dawson Engler]

Hi All,

Here are 37 errors where variables >= 1024 bytes are allocated on a function's
stack.

Summary for 
2.4.4ac8-specific errors  = 9
2.4.4-specific errors = 0
Common errors = 28
Total = 37

Dawson

# BUGs  |   File Name
5   |   drivers/message/i2o/i2o_proc.c
4   |   drivers/cdrom/cdrom.c
3   |   drivers/block/../../lib/inflate.c
3   |   drivers/acpi/ospm/busmgr/bmpm.c
2   |   drivers/acpi/ospm/busmgr/bmdriver.c
2   |   net/irda/af_irda.c
2   |   fs/jffs2/compr_rtime.c
1   |   drivers/sound/emu10k1/audio.c
1   |   fs/jffs2/zlib.c
1   |   drivers/scsi/qlogicfc.c
1   |   arch/i386/kernel/nmi.c
1   |   drivers/net/wan/cycx_x25.c
1   |   drivers/media/video/w9966.c
1   |   drivers/block/cpqarray.c
1   |   fs/ntfs/super.c
1   |   fs/nfs/nfsroot.c
1   |   arch/i386/kernel/setup.c
1   |   drivers/net/zlib.c
1   |   fs/devfs/base.c
1   |   drivers/net/ewrk3.c
1   |   net/wanrouter/wanmain.c
1   |   net/bridge/br_ioctl.c
1   |   drivers/atm/iphase.c


# 2.4.4ac8 specific errors
#
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/media/video/w9966.c:921:w9966_v4l_read: 
ERROR:VAR:921:921: suspicious var 'tbuf' = 2048 bytes:921 [nbytes=2048]
}

while(dleft > 0)
{
unsigned long tsize = (dleft > W9966_RBUFFER) ? W9966_RBUFFER : dleft;

Error --->
unsigned char tbuf[W9966_RBUFFER];
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/acpi/ospm/busmgr/bmpm.c:57:bm_get_inferred_power_state:
 ERROR:VAR:57:57: suspicious var 'pr_list' = 1028 bytes:57 [nbytes=1028]
ACPI_STATUS
bm_get_inferred_power_state (
BM_DEVICE   *device)
{
ACPI_STATUS status = AE_OK;

Error --->
BM_HANDLE_LIST  pr_list;
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/acpi/ospm/busmgr/bmpm.c:205:bm_set_power_state:
 ERROR:VAR:205:205: suspicious var 'target_list' = 1028 bytes:205 [nbytes=1028]
{
ACPI_STATUS status = AE_OK;
BM_DEVICE   *device = NULL;
BM_DEVICE   *parent_device = NULL;
BM_HANDLE_LIST  current_list;

Error --->
BM_HANDLE_LIST  target_list;
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/acpi/ospm/busmgr/bmpm.c:204:bm_set_power_state:
 ERROR:VAR:204:204: suspicious var 'current_list' = 1028 bytes:204 [nbytes=1028]
BM_POWER_STATE  state)
{
ACPI_STATUS status = AE_OK;
BM_DEVICE   *device = NULL;
BM_DEVICE   *parent_device = NULL;

Error --->
BM_HANDLE_LIST  current_list;
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/acpi/ospm/busmgr/bmdriver.c:323:bm_register_driver:
 ERROR:VAR:323:323: suspicious var 'device_list' = 1028 bytes:323 [nbytes=1028]
bm_register_driver (
BM_DEVICE_ID*criteria,
BM_DRIVER   *driver)
{
ACPI_STATUS status = AE_NOT_FOUND;

Error --->
BM_HANDLE_LIST  device_list;
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/acpi/ospm/busmgr/bmdriver.c:407:bm_unregister_driver:
 ERROR:VAR:407:407: suspicious var 'device_list' = 1028 bytes:407 [nbytes=1028]
bm_unregister_driver (
BM_DEVICE_ID*criteria,
BM_DRIVER   *driver)
{
ACPI_STATUS status = AE_NOT_FOUND;

Error --->
BM_HANDLE_LIST  device_list;
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4-ac8/arch/i386/kernel/nmi.c:47:check_nmi_watchdog: 
ERROR:VAR:47:47: suspicious var 'tmp' = 1024 bytes:47 [nbytes=1024]
#define P6_EVENT_CPU_CLOCKS_NOT_HALTED  0x79
#define P6_NMI_EVENTP6_EVENT_CPU_CLOCKS_NOT_HALTED

int __init check_nmi_watchdog (void)
{

Error --->
irq_cpustat_t tmp[NR_CPUS];
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4-ac8/fs/jffs2/compr_rtime.c:97:rtime_decompress: 
ERROR:VAR:97:97: suspicious var 'positions' = 1024 bytes:97 [nbytes=1024]


void rtime_decompress(unsigned char *data_in, unsigned char *cpage_out,
  __u32 srclen, __u32 destlen)
{

Error --->
int positions[256];
-
[BUG]
/u2/engler/mc/ose

[CHECKER] null bugs in 2.4.4 and 2.4.4-ac8

[Dawson Engler]

Hi All,

Enclosed are 103 potential errors where code gets a pointer from a
possibly-failing routine (kmalloc, etc) and dereferences it without
checking.  Many follow the simple pattern of alloc-memset:

private = kmalloc(sizeof(*private),GFP_KERNEL);
memset(private, 0, sizeof(struct xircom_private));

   Summary for 
2.4.4ac8-specific errors= 7
2.4.4-specific errors   = 24
Common errors   = 72
Total   = 103

 BUGs   |   File Name
9   |   drivers/block/DAC960.c
5   |   drivers/scsi/sd.c
4   |   drivers/net/aironet4500_card.c
4   |   net/atm/lec.c
3   |   drivers/md/raid5.c
3   |   drivers/scsi/osst.c
3   |   fs/nfsd/nfsfh.c
3   |   drivers/char/ip2main.c
3   |   drivers/ide/ide-probe.c
2   |   arch/i386/kernel/irq.c
2   |   drivers/scsi/hosts.c
2   |   drivers/scsi/megaraid.c
2   |   fs/hpfs/anode.c
2   |   drivers/media/video/bttv-driver.c
2   |   fs/jffs/intrep.c
2   |   drivers/net/skfp/ess.c
2   |   drivers/net/wan/sdla_fr.c
2   |   drivers/pcmcia/bulkmem.c
1   |   drivers/video/sis/sis_main.c
1   |   drivers/net/pcmcia/xircom_cb.c
1   |   drivers/net/wan/comx-proto-fr.c
1   |   drivers/char/drm/context.c
1   |   net/sched/sch_gred.c
1   |   drivers/char/drm/dma.c
1   |   drivers/char/drm/radeon_bufs.c
1   |   fs/bfs/inode.c
1   |   drivers/mtd/slram.c
1   |   fs/locks.c
1   |   drivers/char/epca.c
1   |   drivers/scsi/gdth.c
1   |   drivers/i2o/i2o_core.c
1   |   drivers/char/rio/riocmd.c
1   |   drivers/scsi/ultrastor.c
1   |   drivers/scsi/g_NCR5380.c
1   |   drivers/scsi/scsi_proc.c
1   |   drivers/usb/kaweth.c
1   |   drivers/net/wan/sdla_chdlc.c
1   |   drivers/scsi/eata_dma.c
1   |   drivers/isdn/hisax/fsm.c
1   |   fs/qnx4/inode.c
1   |   drivers/pcmcia/rsrc_mgr.c
1   |   drivers/scsi/sr.c
1   |   drivers/char/rio/riotable.c
1   |   drivers/media/video/zoran_procfs.c
1   |   drivers/scsi/gdth_proc.c
1   |   net/irda/irproc.c
1   |   drivers/mtd/mtdram.c
1   |   drivers/net/eql.c
1   |   fs/binfmt_misc.c
1   |   drivers/char/drm/fops.c
1   |   drivers/media/video/i2c-parport.c
1   |   drivers/usb/hp5300.c
1   |   drivers/scsi/scsi_scan.c
1   |   drivers/ieee1394/video1394.c
1   |   drivers/block/ll_rw_blk.c
1   |   drivers/ide/ide-tape.c
1   |   drivers/mtd/ftl.c
1   |   drivers/media/video/videodev.c
1   |   drivers/video/matrox/matroxfb_crtc2.c
1   |   fs/ntfs/support.c
1   |   drivers/char/drm/r128_bufs.c
1   |   fs/hpfs/dir.c
1   |   drivers/usb/se401.c
1   |   fs/reiserfs/journal.c
1   |   drivers/scsi/sr_ioctl.c
1   |   drivers/char/drm/proc.c
--

Boilerplate disclaimer:
- this is part of a one-time large batch of errors.  In the future,
  we'll send out incremental bug reports along with a pointer to
  the bug database on our website.

- as always, bugs may not be errors --- we have inspected the
  error logs to counter this.

- bugs may be missing in one distribution versus the other because
  we did not compile that file (or failed to fully compile it).
  It can be worthwhile to cross check important bugs to make sure
  they've been killed.

- bugs are sorted roughly by severity and ease-of-diagnosis.
  The highest ranked bugs are "SECURITY" which (in most of the
  examples) are primarily denial-of-service vulnerabilities
  where the user could trigger the bug when they canted to.
  Ease-of-diagnosis is currently crude: we rank LOCAL errors
  over GLOBAL (GLOBAL require looking at call chains) and then
  distance between error source and manifestation as the next
  (closer is better)

- these errors are a subset of the ones we found --- we typically
  did not inspect many of the global errors, since there were so
  many local ones.  If you'd like to see uninspected files, let
  me know.



# 2.4.4ac8 specific errors
#
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/net/pcmcia/xircom_cb.c:222:xircom_probe: 
ERROR:NULL:221:222: Passing unknown ptr "private"! as arg 0 to call "memset"! set by 
'kmalloc':222 [nbytes = 148] 
/* 
   Before changing the hardware, allocate the memory.
   This way, we c

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

[Daniel Phillips]

On Tuesday 22 May 2001 22:10, Andreas Dilger wrote:
> Peter Braam writes:
> > File system journal recovery can corrupt a snapshot, because it
> > copies data that needs to be preserved in a snapshot. During
> > journal replay such data may be copied again, but the source can
> > have new data already.
>
> The way it is implemented in reiserfs is to wait for existing
> transactions to complete, entirely flush the journal and block all
> new transactions from starting.  Stephen implemented a journal flush
> API to do this for ext3, but the hooks to call it from LVM are not in
> place yet.  This way the journal is totally empty at the time the
> snapshot is done, so the read-only copy does not need to do journal
> recovery, so no problems can arise.

I suppose I'm just reiterating the obvious, but we should eventually
have a generic filesystem transaction API at the VFS level, once we
have enough data points to know what the One True API should be.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[CHECKER] use of floating point in 2.4.4 and 2.4.4-ac8

[Dawson Engler]

Hi All,

These check the rule "DO NOT USE FLOATING POINT IN THE KERNEL" on the 
2.4.4 and 2.4.4-ac8 releases.  There were 10 errors in all:
2.4.4-specific errors = 8
Common errors = 2

--
BUG Count   |   File Name
--
8   |   drivers/video/sis/sis_main.c
2   |   drivers/video/sgivwfb.c


Dawson


Boilerplate disclaimer:
- this is part of a one-time large batch of errors.  In the future,
  we'll send out incremental bug reports along with a pointer to
  the bug database on our website.

- as always, bugs may not be errors --- we have inspected the
  error logs to counter this.

- bugs may be missing in one distribution versus the other because
  we did not compile that file (or failed to fully compile it).
  It can be worthwhile to cross check important bugs to make sure
  they've been killed.

- sorted roughly by severity and ease-of-diagnosis.  The highest
  ranked bugs are "SECURITY" which (in most of the examples) 
  are primarily denial-of-service vulnerabilities where the user
  could trigger the bug when they canted to.  Ease-of-diagnosis
  is currently crude: we rank LOCAL errors over GLOBAL (GLOBAL
  require looking at call chains) and then distance between
  error source and manifestation as the next (closer is better)


- if a version if one of the version has no errors specific to it,
  this can just be because we did not inspect all the error reports.
  These are typically from checkers that required some inter-function
  inspection.  If you are interested in these errors, send us mail,,
  and we can send you the unispected file.


# 2.4.4 specific errors

-
[BUG]  What is the right way to count these?  Probably each unique var
   and each uniq expr that counted vars don't appear in?
/u2/engler/mc/oses/linux/2.4.4/drivers/video/sis/sis_main.c:589:crtc_to_var: 
ERROR:FLOAT: cannot use fp in kernel

VT <<= 1;
HT = (HT + 5) * 8;

hrate = (double) ivideo.refresh_rate * (double) VT / 2;
drate = hrate * HT;

Error --->
var->pixclock = (u32) (1E12 / drate);
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4/drivers/video/sis/sis_main.c:777:do_set_var: 
ERROR:FLOAT: cannot use fp in kernel

if (!htotal || !vtotal) {
DPRINTK("Invalid 'var' Information!\n");
return 1;
}


Error --->
drate = 1E12 / var->pixclock;
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4/drivers/video/sis/sis_main.c:778:do_set_var: 
ERROR:FLOAT: cannot use fp in kernel

DPRINTK("Invalid 'var' Information!\n");
return 1;
}

drate = 1E12 / var->pixclock;

Error --->
hrate = drate / htotal;
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4/drivers/video/sis/sis_main.c:779:do_set_var: 
ERROR:FLOAT: cannot use fp in kernel

return 1;
}

drate = 1E12 / var->pixclock;
hrate = drate / htotal;

Error --->
ivideo.refresh_rate = (unsigned int) (hrate / vtotal * 2 + 0.5);
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4/drivers/video/sis/sis_main.c:760:do_set_var: 
ERROR:FLOAT: cannot use fp in kernel

var->left_margin + var->xres + var->right_margin +
var->hsync_len;
unsigned int vtotal =
var->upper_margin + var->yres + var->lower_margin +
var->vsync_len;

Error --->
double drate = 0, hrate = 0;
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4/drivers/video/sis/sis_main.c:587:crtc_to_var: 
ERROR:FLOAT: cannot use fp in kernel


VT += 2;
VT <<= 1;
HT = (HT + 5) * 8;


Error --->
hrate = (double) ivideo.refresh_rate * (double) VT / 2;
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4/drivers/video/sis/sis_main.c:403:crtc_to_var: 
ERROR:FLOAT: cannot use fp in kernel

{
u16 VRE, VBE, VRS, VBS, VDE, VT;
u16 HRE, HBE, HRS, HBS, HDE, HT;
u8 uSRdata, uCRdata, uCRdata2, uCRdata3, uMRdata;
int A, B, C, D, E, F, temp;

Error --->
double hrate, drate;
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4/drivers/video/sis/sis_main.c:588:crtc_to_var: 
ERROR:FLOAT: cannot use fp in kernel

VT += 2;
VT <<= 1;

[CHECKER] free bugs in 2.4.4 and 2.4.4-ac8

[Dawson Engler]

Hi All,

Enclosed are 24 bugs where code uses memory that has been freed.  The
good thing about these bugs is that they are easy to fix.  (Note: About
5 of these have had patches submitted, so this list is a bit out of
date.)

Summary 
  2.4.4ac8-specific errors  = 4
  2.4.4-specific errors = 5
  Common errors = 15
  Total = 24

Dawson

# BUGs  |   File Name
3   |   drivers/char/rio/rio_linux.c
3   |   drivers/atm/iphase.c
2   |   drivers/usb/dc2xx.c
2   |   drivers/block/cciss.c
1   |   drivers/char/drm/gamma_dma.c
1   |   fs/proc/generic.c
1   |   drivers/isdn/isdn_ppp.c
1   |   net/ax25/ax25_ip.c
1   |   drivers/net/wan/lapbether.c
1   |   drivers/usb/serial/io_edgeport.c
1   |   net/netrom/nr_dev.c
1   |   drivers/i2o/i2o_pci.c
1   |   drivers/sound/cs4281/cs4281m.c
1   |   drivers/net/hamradio/bpqether.c
1   |   net/ipv6/udp.c
1   |   net/wanrouter/wanmain.c
1   |   drivers/net/irda/nsc-ircc.c
1   |   drivers/sound/cs46xx.c

--

Boilerplate disclaimer:
- this is part of a one-time large batch of errors.  In the future,
  we'll send out incremental bug reports along with a pointer to
  the bug database on our website.

- as always, bugs may not be errors --- we have inspected the
  error logs to counter this.

- bugs may be missing in one distribution versus the other because
  we did not compile that file (or failed to fully compile it).
  It can be worthwhile to cross check important bugs to make sure
  they've been killed.

- sorted roughly by severity and ease-of-diagnosis.  The highest
  ranked bugs are "SECURITY" which (in most of the examples) 
  are primarily denial-of-service vulnerabilities where the user
  could trigger the bug when they canted to.  Ease-of-diagnosis
  is currently crude: we rank LOCAL errors over GLOBAL (GLOBAL
  require looking at call chains) and then distance between
  error source and manifestation as the next (closer is better)

- if a version if one of the version has no errors specific to it,
  this can just be because we did not inspect all the error reports.
  These are typically from checkers that required some inter-function
  inspection.  If you are interested in these errors, send us mail,,
  and we can send you the unispected file.


# 2.4.4ac8 specific errors
#
-
[BUG] [fixed in 2.4.4]
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/block/cciss.c:686:cciss_ioctl: 
ERROR:FREE:682:686: WARN: Use-after-free of "c"! set by 'cmd_free':682 [type=SECURITY]
{
/* Copy the data out of the buffer we created */
if (copy_to_user(iocommand.buf, buff, iocommand.buf_size))
{
kfree(buff);
Start --->
cmd_free(h, c, 0);
}
}
kfree(buff);
Error --->
cmd_free(h, c, 0);
return(0);
} 

-
[BUG] [fixed in 2.4.4]
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/block/cciss.c:685:cciss_ioctl: 
ERROR:FREE:681:685: WARN: Use-after-free of "buff"! set by 'kfree':681 [type=SECURITY]
if (iocommand.Request.Type.Direction == XFER_READ)
{
/* Copy the data out of the buffer we created */
if (copy_to_user(iocommand.buf, buff, iocommand.buf_size))
{
Start --->
kfree(buff);
cmd_free(h, c, 0);
}
}
Error --->
kfree(buff);
cmd_free(h, c, 0);
return(0);
} 
-
[BUG] Looks pretty bad
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/usb/dc2xx.c:473:camera_disconnect: 
ERROR:FREE:466:473: WARN: Use-after-free of "camera"! set by 'kfree':466
/* If camera's not opened, we can clean up right away.
 * Else apps see a disconnect on next I/O; the release cleans.
 */
if (!camera->buf) {
minor_data [subminor] = NULL;
Start --->
kfree (camera);
} else
camera->dev = NULL;

info ("USB Camera #%d disconnected", subminor);
usb_dec_dev_use (dev);

Error --->
up (&camera->sem);
up (&state_table_mutex);
}

--

Re: Dying disk and filesystem choice.

[Hans Reiser]

J Sloan wrote:
> 
> Excellent!
> 
> Will this be in resierfs 4.0 then?
> 
> cu
> 
> jjs
> 
> Hans Reiser schrieb:
> 
> > No, reiserfs does have badblock support
> >
> > You just have to get it as a separate patch from us because it was written after
> > code freeze.


No, version 4 won't ship until september 2002, these features are all v3.7,
which will be sent to Linus as soon as 2.5.1 opens up.

Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: O_TRUNC problem on a full filesystem

[Andreas Dilger]

Stephen writes:
> On Thu, May 24, 2001 at 11:24:10AM -0600, Andreas Dilger wrote:
> > How have you done the ext3 preallocation code? 
> 
> Preallocation is currently disabled in ext3.  Eventually I'll probably
> get it going by adding a journal prepare-commit callback to allow the
> filesystem to flush preallocation before committing.

Yes, it is disabled in 2.2 ext3, but if Andrew is complaining about the
blocks not being freed in 2.4 ext3, I assume he re-enabled it somehow...

> > One way to do it would be
> > to only mark the blocks as used in the in-memory copy of the block bitmap
> > and not write that to disk (we keep 2 copies of the block bitmap, IIRC).
> 
> Indeed; I'd need to keep 3 copies to make that work.  The state
> machine just gets even uglier.  :-)  I thought about it and I might
> still end up going that route.
> 
> > Did you ever benchmark ext2 with and without preallocation to see if it
> > made any difference?  No point in doing extra work if there is no benefit.
> 
> The point is not just performance, but also cpu cost (which
> preallocation definitely wins on)

Yes, currently this is one thing that ext2/ext3 still have over XFS and
reiserfs - lower CPU usage.  If you ever see benchmarks on slower CPU
systems, ext2 does very well, and XFS does quite poorly.  The only bad
spot is the large directory handling, and I think Daniel's indexed dir
code handles that very well, because it doesn't need continual balancing
and re-packing of the directory entries.

I even realized that if you have a (formerly) huge directory, with lots
of empty blocks this even speeds up searches for non-existent entries,
sort of like a negative dentry.

> and on fragmentation if you have multiple writers in the same directory.

Yes, of course this is also hard to notice in benchmarks, but a good
feature in real life to keep file reads more within device read-ahead.

When I was thinking about the current preallocation code in conjunction
with the block goal searching code, I realized that we are normally
looking through the bitmap for at least 8 contiguous blocks, and then
back-searching for up to 7 additional contiguous blocks.  We _should_ do
block preallocation immediately at this point for up to 14 more blocks,
because we already know they are contiguous.  Something like the following
(untested) patch:

Cheers, Andreas
=
diff -u -u -r1.4 balloc.c
--- fs/ext3/balloc.c2001/05/21 17:00:17 1.4
+++ fs/ext3/balloc.c2001/05/24 20:17:02
@@ -509,7 +509,11 @@
int bitmap_nr;
struct super_block * sb;
struct ext3_group_desc * gdp;
-   struct ext3_super_block * es;
+   struct ext3_super_block *es = EXT3_SB(sb)->s_es;
+#ifdef EXT3_PREALLOCATE
+   int prealloc_goal = es->s_prealloc_blocks ?
+   es->s_prealloc_blocks : EXT2_DEFAULT_PREALLOC_BLOCKS;
+#endif
 #ifdef EXT3FS_DEBUG
static int goal_hits = 0, goal_attempts = 0;
 #endif
@@ -521,7 +526,6 @@
}
 
lock_super (sb);
-   es = sb->u.ext3_sb.s_es;
if (le32_to_cpu(es->s_free_blocks_count) <=
le32_to_cpu(es->s_r_blocks_count) &&
((sb->u.ext3_sb.s_resuid != current->fsuid) &&
@@ -614,7 +618,9 @@
k < 7 && j > 0 && ext3_test_allocatable(j - 1, bh);
k++, j--)
;
-   
+#ifdef EXT3_PREALLOCATE
+   prealloc_goal += k;
+#endif
 got_block:
 
ext3_debug ("using block group %d(%d)\n", i, gdp->bg_free_blocks_count);
@@ -673,11 +679,7 @@
 */
/* Writer: ->i_prealloc* */
if (prealloc_count && !*prealloc_count) {
-   int prealloc_goal;
unsigned long next_block = tmp + 1;
-
-   prealloc_goal = es->s_prealloc_blocks ?
-   es->s_prealloc_blocks : EXT3_DEFAULT_PREALLOC_BLOCKS;
 
*prealloc_block = next_block;
/* Writer: end */
 
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dying disk and filesystem choice.

[Erik Mouw]

On Thu, May 24, 2001 at 09:53:45AM -0700, Hans Reiser wrote:
> No, reiserfs does have badblock support
> 
> You just have to get it as a separate patch from us because it was
> written after code freeze.

IMHO we are not that deep into code freeze anymore. Freevxfs got added
in linux-2.4.5-pre*, so I think that a patch that adds a useful feature
like badblock support would be OK.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual Athlon on 2.2.19 ?

[Dan Hollis]

On Thu, 24 May 2001, Johannes Erdfelt wrote:
> Which patch of mine did you apply? Which motherboard are you doing your
> testing with?

The dual tyan presumably. Or are there others you are aware of.

-Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Selectively refusing TCP connections

[Andi Kleen]

On Thu, May 24, 2001 at 12:15:44PM -0700, David Ford wrote:
> Is there an example somewhere of this?

I don't have one handy, but basically you have to hack libpcap a bit
to push the generated filters using SO_ATTACH_FILTER onto a socket.

The format (LPF) understood by the kernel is a superset of the BPF 
stack machine code generated by libpcap. See linux/filter.h and the BPF
documentation.

It's main drawback is that it doesn't support variable length headers
properly.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual Athlon on 2.2.19 ?

[Johannes Erdfelt]

On Thu, May 24, 2001, Prasanna P Subash <[EMAIL PROTECTED]> wrote:
> I have a dual athlon on the 760MP chipset.
> 2.2.20pre1 and 2 dont work. I got it to work partly after applying Johannes
> Erdfel's 760MP patch in io_apic.c. Even after applying the patch, there
> are messages like

2.2.20pre1 and pre2 both have the patch I created already applied. If
you had to apply them yourself then something is wrong.

> hdc: IRQ probe failed(0)
> hdd: IRQ probe failed(0)
> hde: IRQ probe failed(0)
> 
> hdc: lost interrupt
> hdc: lost interrupt
> 
> and then the machine hangs randomly. I an guessing the io_apic does not
> route the interrupts correctly.

That would be the problem.

Which patch of mine did you apply? Which motherboard are you doing your
testing with?

JE

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual Athlon on 2.2.19 ?

[Prasanna P Subash]

Alan,

I have a dual athlon on the 760MP chipset.
2.2.20pre1 and 2 dont work. I got it to work partly after applying Johannes Erdfel's
760MP patch in io_apic.c. Even after applying the patch, there are messages like

hdc: IRQ probe failed(0)
hdd: IRQ probe failed(0)
hde: IRQ probe failed(0)

hdc: lost interrupt
hdc: lost interrupt

and then the machine hangs randomly. I an guessing the io_apic does not route the 
interrupts
correctly.




On Thu, May 24, 2001 at 01:02:11PM +0100, Alan Cox wrote:
> > Is there a patch to make dual athlons work on 2.2.19 ? I know it work on
> > 2.4.3-pre1 with AA's patch.
> 
> 2.2.20pre1 and 2.4.current should both work

-- 
Prasanna Subash   ---   [EMAIL PROTECTED]   --- TurboLinux, INC

Linux, the choice  | Reporter, n.:  A writer who guesses his way
of a GNU generation   -o)  | to the truth and dispels it with a  tempest
Kernel 2.4.1  /\\  | of words.   -- Ambrose Bierce, "The Devil's
on a i686_\\_v | Dictionary" 
   | 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/