Re: 2.4.30 Oops when connecting external USB hard drive

[Willy Tarreau]

On Fri, Apr 15, 2005 at 02:50:48PM +0200, Karl Kiniger wrote:
> On Thu, Apr 14, 2005 at 07:02:44AM +0200, Willy Tarreau wrote:
> > You may try to unload the ehci-hcd driver and load only uhci and check if
> > it still happens. I guess from the trace that the problem lies in the ehci
> > driver itself.
> 
> Your guess is right. With only uhci loaded it works (dog slow of course).
> When I then insmod the ehci-hcd driver: instant Oops.
> 
> Today I tried with another USB 2.0 enclosure w/o crash - it seems
> to dislike especially the Seagate enclosure.

Fine, it may not be an important bug.

> perhaps the output of cat /proc/bus/usb/devices gives some hint?
> (BTW: what does the asterisk in the 'C:' lines mean?)

I don't remember at all...

> On the two "GE Med. Kretz" USB<>IDE devices there is 
> a DVD recorder and a Maxtor HD connected, both are working fine
> as long as nobody tries to plug in this particular Seagate.
> 
> What to do next? I have no clue about the innards of ehci-hcd

You should CC the ehci-hcd the usb-storage maintainers, they probably
will have more clues or ideas about what you encounter. A post to the
linux-usb-users list would be a good idea too. Also, if you can test
2.6 and find that it is broken only on 2.4, it will be easier for them
to send you some code to try.

Regards,
Willy

-
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 system call need to copy the date from the userspace before using it

[Vadim Lobanov]

On Sat, 16 Apr 2005, Hacksaw wrote:

> Sorry if this bugs anyone, but I'm learning things here.
>
> What I would expect the kernel to do is this:
>
> system_call_data_prep (userdata, size){
>
>if !4G/4G {
>   for each page from userdata to userdata+size
>   {
>   if the page is swapped out, swap it in
>   if the page is not owned by the user process, return -ENOWAYMAN
>   otherwise, lock the page
>   }
>   return userdata;
> }
> else { //kernel land and userland are mutually exclusive
>  copy the data into kernel land
>  return kernelland_copy_of_userdata;
>   }
> }
>
> (And then the syscall would need to run the opposite function
> sys_call_data_unprep to unlock pages.)
>
> Hmm, maybe that interface sucks.

That's one approach. Unfortunately, it's not what the kernel currently
does. The root of the problem is -- it needs to copy the data, even if
the kernel can access userspace data. There are many reasons for why
this is a simpler way to program the interface; if you want actual
concrete examples, let me know.

In order to accomplish the copy_from_user() procedure, from the i386
perspective, the kernel first figures out where userspace is telling it
to look for the data buffer. It checks if the LAST page belongs to
userland, and fails if not; this works because the kernel sits in higher
memory. Then it simply does the direct copy. If during the copy it hits
an invalid page, the exception handler code will run, realize that the
exception occurred because of the copy, and return an error code right
then and there.

Lots of details left out, but this is the 10,000 foot view, I think.

-Vadim Lobanov

> Is it anything close to that?
>
> --
> The best is the enemy of the good  -- Voltaire
> The Good Enough is the enemy of the Great -- Me
> http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD
>
>
> -
> 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: ACPI/HT or Packet Scheduler BUG?

[Steven Rostedt]

On Sat, 2005-04-16 at 11:49 +1000, Herbert Xu wrote:


> Here is a quick'n'dirty fix to the problem at hand.  What happened
> between 2.6.10-rc1 and 2.6.10-rc2 is that qdisc_destroy started
> changing the next pointer of qdisc entries which totally confuses
> the readers because qdisc_destroy doesn't always take the tree lock.
> 
> This patch tries to ensure that all top-level calls to qdisc_destroy
> come under the tree lock.  As Thomas correctedly pointed out, most
> of the other qdisc_destroy calls occur after the top qdisc has been
> unlinked from the device qdisc_list.  However, someone should go
> through each one of the remaining ones (they're all in the individual
> sch_* implementations) and make sure that this assumption is really
> true.
> 
> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
> 
> If anyone has cycles to spare and a stomach strong enough for
> this stuff, here is your chance :)
> 

FYI,

I ran the test case that Tarhon-Ohn had, but had to change his tc
execution from batch to single lines since the version of tc I have
segfaults on newlines.  Anyway, I did see the lock up with 2.6.11.2
after 7 iterations. I applied your patch, and it ran for 30 iterations
before I manually killed it. I didn't test any more than that, but this
seems to be the quick fix for now.

-- Steve


-
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 system call need to copy the date from the userspace before using it

[Hacksaw]

Sorry if this bugs anyone, but I'm learning things here.

What I would expect the kernel to do is this:

system_call_data_prep (userdata, size){ 

   if !4G/4G {
  for each page from userdata to userdata+size
  {
if the page is swapped out, swap it in
if the page is not owned by the user process, return -ENOWAYMAN
otherwise, lock the page
  }
  return userdata;
}
else { //kernel land and userland are mutually exclusive
   copy the data into kernel land
   return kernelland_copy_of_userdata;
  }
}

(And then the syscall would need to run the opposite function 
sys_call_data_unprep to unlock pages.)

Hmm, maybe that interface sucks.

Is it anything close to that? 
   
-- 
The best is the enemy of the good  -- Voltaire
The Good Enough is the enemy of the Great -- Me
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD


-
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: FUSYN and RT

[Inaky Perez-Gonzalez]

> Steven Rostedt <[EMAIL PROTECTED]> writes:

> On Fri, 2005-04-15 at 18:53 -0700, Inaky Perez-Gonzalez wrote:
>> > Steven Rostedt <[EMAIL PROTECTED]> writes:
>> 
>> I see--would the following fit your view?
>> 

> I think it's time that I take a look at the fusyn code. I don't have
> all the emails on this thread, could you point out to me where I can
> see the latest fusyn patch. Thanks.

http://developer.osdl.org/dev/robustmutexes/fusyn/20040510

There you have the a full patch against 2.6.10, against the previous
stable release (2.3.1) and the patch broken up in parts (the first one
001.msg has the index). 

You want 016.msg and 020.msg, the ones that implement fulocks (the
mutexes) and user space fulocks. 

013.msg has all the priority change engine (along with the queues);
__fuqueue_waiter_chprio() is the function.

In the same page site, up a couple of levels, three is info on how to
grab it from CVS. There is also the OLS 2004 stuff which explains
things in detail.

> It's getting late where I am, and I'm getting tired, so I'm a little
> slow right now.  Is what you are showing me here what is currently
> in fusyn or a proposal with the merging of Ingo's rt_mutex?  Reason
> why I'm asking, is what's the difference between the owner here and
> in fuqueue's spin_lock?

This is all without taking into account Ingo's work (you could say it
is kind of parallel/redundant/etc). In any case, to sum up w/ what
Sven said, the spinlock would be a raw_spinlock_t when that makes it
into the kernel. It just protects access to the fuqueue/fulock/ufulock
structures. 

>> This has an in kernel API so you can use it from modules or kernel
>> code.
>> ...

> This above structure would represent the user space wrapper
> structure that I meant with the fusyn structure containing the
> rt_mutex lock.  Right?

Yep

> Also in the above, is the fuqueue_ops the ops we mentioned earlier
> as the links into PI?

Yes and no.

Yes because the ops are there to be able to be able to do the kind of
things that user space mutexes need done differently (look for the
fu*_op_* functions--or fulock_ops and ufulock_ops).

However, in the case of the PI handling--that is just priority change
handling--the op is the same for both fulocks and user space fulocks.

But the priority change handling is different for queues, so you need
an op to distinguish.

> Sorry about being totally ignorant here, but it's the end of the day
> for me, and I'm starting to feel burnt out.

That's when you do 'shutdown -h now' and go for a beer :)

-- 

Inaky

-
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: Booting from USB with initrd

[Eric Lammerts]

gabriel wrote:
Hi Im trying to boot an encrypted file system using an initrd on a USB. 
I use syslinux for the actual boot process as I couldnt get Grub to boot
of it for some reason. This is the .cfg

 append initrd=/initrd.gz root=/dev/ram0 rootfstype=minix init=/linuxrc
I don't think syslinux digs the "/" in the initrd filename. Did you try 
it with initrd=initrd.gz?

Eric
-
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: FUSYN and RT

[Steven Rostedt]

On Fri, 15 Apr 2005, Sven Dietrich wrote:

> > > >
> > >   /** A fuqueue, a prioritized wait queue usable from
> > kernel space. */
> > >   struct fuqueue {
> > >   spinlock_t lock;
> > >   struct plist wlist;
> > >   struct fuqueue_ops *ops;
> > >   };
> > >
> >
> > Would the above spinlock_t be a raw_spinlock_t? This goes
> > back to my first question. I'm not sure how familiar you are
> > with Ingo's work, but he has turned all spinlocks into
> > mutexes, and when you really need an original spinlock, you
> > declare it with raw_spinlock_t.
> >
>
> This one probably should be a raw_spinlock.
> This lock is only held to protect access to the queues.
> Since the queues are already priority ordered, there is
> little benefit to ordering -the order of insertion-
> in case of contention on a queue, compared with the complexity.
>

Surprisingly, this makes perfect sense to me! I'm not going to comment on
this code until I actually get to see the whole package.  I don't know how
much Inaky has used Ingo's work, but I'd figured it should be a
raw_spinlock.

> Just what you want to say to a guy who says he is tired  ;)
>

This is nothing, I'm currently trying to test stuff from another thread
dealing with qdiscs in the net code. %-}

-- Steve

-
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.6 patch] drivers/video/intelfb/intelfbdrv.h

[Antonino A. Daplas]

On Friday 15 April 2005 08:48, Adrian Bunk wrote:
> Ingo Oeser noticed that all that intelfbdrv.h contains are prototypes
> for static functions - and such prototypes don't belong into header
> files.
>
> This patch therefore removes drivers/video/intelfb/intelfbdrv.h and
> moves the prototypes to intelfbdrv.c .
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

Patch is linewrapped.  Can you resend?

Tony


-
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/

Ooops with kernel 2.6.12-rc2 and rsync in "D" state

[Rogério Brito]

Hi there.

Today, I was copying the contents of some CDs of mine (with rsync) to my HD
and suddenly rsync stalled. I went to see the cause and it was in D state.

Then, I discovered that it had generated an Ooops and I am sending it with
this message.

The box in question is a Duron 600MHz with 256MB of RAM and with an Asus
A7V motherboard. It has an uptime of 6 days and it seems fine otherwise
(well, apart from the stack trace that I get saying that irq 10 is
ignored), but the messages surely seem to be scary.

If my .config is needed, please let me know.


Thanks in advance, Rogério.

-- 
Learn to quote e-mails decently at:
http://pub.tsn.dk/how-to-quote.php
http://learn.to/quote
http://www.xs4all.nl/~sbpoley/toppost.htm
[4294667.296000] Linux version 2.6.12-rc2-1 ([EMAIL PROTECTED]) (gcc version 
3.3.5 (Debian 1:3.3.5-8)) #1 Tue Apr 5 02:13:31 BRT 2005
[4294667.296000] BIOS-provided physical RAM map:
[4294667.296000]  BIOS-e820:  - 0009e800 (usable)
[4294667.296000]  BIOS-e820: 0009e800 - 000a (reserved)
[4294667.296000]  BIOS-e820: 000f - 0010 (reserved)
[4294667.296000]  BIOS-e820: 0010 - 0ffec000 (usable)
[4294667.296000]  BIOS-e820: 0ffec000 - 0ffef000 (ACPI data)
[4294667.296000]  BIOS-e820: 0ffef000 - 0000 (reserved)
[4294667.296000]  BIOS-e820: 0000 - 1000 (ACPI NVS)
[4294667.296000]  BIOS-e820:  - 0001 (reserved)
[4294667.296000] 255MB LOWMEM available.
[4294667.296000] On node 0 totalpages: 65516
[4294667.296000]   DMA zone: 4096 pages, LIFO batch:1
[4294667.296000]   Normal zone: 61420 pages, LIFO batch:14
[4294667.296000]   HighMem zone: 0 pages, LIFO batch:1
[4294667.296000] DMI 2.3 present.
[4294667.296000] ACPI: RSDP (v000 ASUS  ) @ 
0x000f6a90
[4294667.296000] ACPI: RSDT (v001 ASUS   A7V  0x30303031 MSFT 0x31313031) @ 
0x0ffec000
[4294667.296000] ACPI: FADT (v001 ASUS   A7V  0x30303031 MSFT 0x31313031) @ 
0x0ffec080
[4294667.296000] ACPI: BOOT (v001 ASUS   A7V  0x30303031 MSFT 0x31313031) @ 
0x0ffec040
[4294667.296000] ACPI: DSDT (v001   ASUS A7V  0x1000 MSFT 0x010b) @ 
0x
[4294667.296000] ACPI: PM-Timer IO Port: 0xe408
[4294667.296000] Allocating PCI resources starting at 1000 (gap: 
1000:efff)
[4294667.296000] Built 1 zonelists
[4294667.296000] Kernel command line: auto BOOT_IMAGE=Linux root=2103
[4294667.296000] Local APIC disabled by BIOS -- you can enable it with "lapic"
[4294667.296000] mapped APIC to d000 (01201000)
[4294667.296000] Initializing CPU#0
[4294667.296000] PID hash table entries: 1024 (order: 10, 16384 bytes)
[4294667.296000] Detected 605.450 MHz processor.
[4294667.296000] Using pmtmr for high-res timesource
[4294667.296000] Console: colour VGA+ 80x25
[4294670.344000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[4294670.346000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[4294670.363000] Memory: 255996k/262064k available (1803k kernel code, 5508k 
reserved, 791k data, 144k init, 0k highmem)
[4294670.363000] Checking if this processor honours the WP bit even in 
supervisor mode... Ok.
[4294670.364000] Calibrating delay loop... 1196.03 BogoMIPS (lpj=598016)
[4294670.387000] Mount-cache hash table entries: 512
[4294670.387000] CPU: After generic identify, caps: 0183f9ff c1c7f9ff  
   
[4294670.387000] CPU: After vendor identify, caps: 0183f9ff c1c7f9ff  
   
[4294670.387000] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 
bytes/line)
[4294670.387000] CPU: L2 Cache: 64K (64 bytes/line)
[4294670.387000] CPU: After all inits, caps: 0183f9ff c1c7f9ff  
0020   
[4294670.387000] Intel machine check architecture supported.
[4294670.387000] Intel machine check reporting enabled on CPU#0.
[4294670.387000] CPU: AMD Duron(tm) Processor stepping 00
[4294670.387000] Enabling fast FPU save and restore... done.
[4294670.387000] Checking 'hlt' instruction... OK.
[4294670.392000]  tbxface-0118 [02] acpi_load_tables  : ACPI Tables 
successfully acquired
[4294670.433000] Parsing all Control 
Methods:...
[4294670.522000] Table [DSDT](id F004) - 356 Objects with 38 Devices 115 
Methods 24 Regions
[4294670.522000] ACPI Namespace successfully loaded at root c03dd6c0
[4294670.522000] ACPI: setting ELCR to 0200 (from 0e20)
[4294670.522000] evxfevnt-0094 [03] acpi_enable   : Transition to ACPI 
mode successful
[4294670.523000] NET: Registered protocol family 16
[4294670.525000] PCI: PCI BIOS revision 2.10 entry at 0xf1180, last bus=1
[4294670.525000] PCI: Using configuration type 1
[4294670.525000] mtrr: v2.0 (20020519)
[4294670.526000] ACPI: Subsystem revision 

Re: [2.6 patch] drivers/serial/8250_acpi.c: fix a warning

[Herbert Xu]

Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
>> drivers/serial/8250_acpi.c doesn't use CONFIG_ symbols.
> 
> 8250_acpi.c #include's  which requires config.h .
> 
> In the Linux kernel, it's more common to put such header dependencies 
> for header files into the C files, but if the ACPI people agree a patch 

I disagree with this assertion.  Try

grep -l linux/config.h include/linux/*.h | wc -l

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.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: FUSYN and RT

[Sven Dietrich]

> > > 
> > /** A fuqueue, a prioritized wait queue usable from
> kernel space. */
> > struct fuqueue {
> > spinlock_t lock;
> > struct plist wlist;
> > struct fuqueue_ops *ops;
> > };
> > 
> 
> Would the above spinlock_t be a raw_spinlock_t? This goes
> back to my first question. I'm not sure how familiar you are 
> with Ingo's work, but he has turned all spinlocks into 
> mutexes, and when you really need an original spinlock, you 
> declare it with raw_spinlock_t.  
> 

This one probably should be a raw_spinlock. 
This lock is only held to protect access to the queues.
Since the queues are already priority ordered, there is
little benefit to ordering -the order of insertion-
in case of contention on a queue, compared with the complexity.

Just what you want to say to a guy who says he is tired  ;)

Sven



-
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.6 patch] drivers/serial/8250_acpi.c: fix a warning

[Adrian Bunk]

On Fri, Apr 15, 2005 at 08:10:54PM +0400, Alexey Dobriyan wrote:
> On Fri, 15 Apr 2005 17:10:53 +0200, Adrian Bunk wrote:
> 
> > This patch fixes the following warning:
> 
> >   CC  drivers/serial/8250_acpi.o
> > drivers/serial/8250_acpi.c: In function `acpi_serial_ext_irq':
> > drivers/serial/8250_acpi.c:51: warning: implicit declaration of function 
> > `acpi_register_gsi'
> 
> > --- linux-2.6.12-rc2-mm1-full/drivers/serial/8250_acpi.c.old
> > +++ linux-2.6.12-rc2-mm1-full/drivers/serial/8250_acpi.c
> 
> > +#include 
> 
> drivers/serial/8250_acpi.c doesn't use CONFIG_ symbols.

8250_acpi.c #include's  which requires config.h .

In the Linux kernel, it's more common to put such header dependencies 
for header files into the C files, but if the ACPI people agree a patch 
to add the #include  to acpi_bus.h is the other possble 
correct solution for this issue.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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: [SATA] status reports updated

[Andy Lutomirski]

Jeff Garzik wrote:
My Linux SATA software/hardware status reports have just been updated. 
To see where libata (SATA) support stands for a particular piece of 
hardware, or a particular feature, go to

http://linux.yyz.us/sata/
What's the timeline on getting sata-promise's PATA support into 
mainline?  I've been 2.6.11-gentoo-r2, which includes this feature, for 
weeks now, and it's been perfectly stable (including md's RAID5) using 
the PATA port.  It would be nice to be able to run my system with a 
mainline kernel.

The broken-out patch that Gentoo is using is here:
http://dev.gentoo.org/~dsd/gentoo-dev-sources/release-11.01/dist/4320_promise-pdc2037x.patch
Thanks,
Andy
-
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: FUSYN and RT

[Steven Rostedt]

On Fri, 2005-04-15 at 18:53 -0700, Inaky Perez-Gonzalez wrote:
> > Steven Rostedt <[EMAIL PROTECTED]> writes:
> 
> > On Fri, 2005-04-15 at 18:20 -0700, Inaky Perez-Gonzalez wrote:
> 
> >> Back to my example before: in fusyn, a user space lock is a kernel
> >> space lock with a wrapper, that provides all that is necessary for
> >> doing the fast path and handling user-space specific issues.
> 
> > ...
> 
> > So, to answer your question. Looking forward, I kind of see two
> > different structures for locking.  The rt_mutex and something that
> > is used by fusyn, then there being some common structure (or ops)
> > that they both use to implement the PI.  But the implementation of
> > how the locks work may as well be different. But this may not be the
> > case, and there still be two structures but the fusyn just contain a
> > rt_mutex lock to do the actual locking and the rest of the structure
> > be used for showing information or what not back up to user
> > space. This stuff wouldn't be necessary for the rt_mutex. We need to
> > keep rt_mutex small since it is used all over the place.
> 
> I see--would the following fit your view?
> 

I think it's time that I take a look at the fusyn code. I don't have all
the emails on this thread, could you point out to me where I can see the
latest fusyn patch. Thanks.


> This would be a kernel lock [from the fusyn patch, linux/fulock.h]:
> 
>   /** A fulock, mutex usable from the kernel. */
>   struct fulock {
>   struct fuqueue fuqueue;
>   struct task_struct *owner;
>   unsigned flags;
>   struct plist olist_node;
>   };
> 

It's getting late where I am, and I'm getting tired, so I'm a little
slow right now.  Is what you are showing me here what is currently in
fusyn or a proposal with the merging of Ingo's rt_mutex?   Reason why
I'm asking, is what's the difference between the owner here and in
fuqueue's spin_lock?

> This has an in kernel API so you can use it from modules or kernel
> code.
> 
> And this would be kernel representation of a user space lock [from
> linux/fulock_kernel.h]:
> 
>   struct ufulock {
>   struct fulock fulock;
>   struct vlocator vlocator;
>   struct page *page;
>   };
> 
> This is exposed via system calls with fast-path as an option.
> 

This above structure would represent the user space wrapper structure
that I meant with the fusyn structure containing the rt_mutex lock.
Right?

> This is basically the kernel lock that provides the functionality and
> an structure to keep a tab to where the thing is in user space (hash
> queues a la futex). The ops are hidden in fulock.fuqueue.ops [fuqueue
> is the waitqueue--just for reference, from linux/fuqueue.h].
> 
>   /** A fuqueue, a prioritized wait queue usable from kernel space. */
>   struct fuqueue {
>   spinlock_t lock;
>   struct plist wlist;
>   struct fuqueue_ops *ops;
>   };
> 

Would the above spinlock_t be a raw_spinlock_t? This goes back to my
first question. I'm not sure how familiar you are with Ingo's work, but
he has turned all spinlocks into mutexes, and when you really need an
original spinlock, you declare it with raw_spinlock_t.  

Also in the above, is the fuqueue_ops the ops we mentioned earlier as
the links into PI?

Sorry about being totally ignorant here, but it's the end of the day for
me, and I'm starting to feel burnt out.

Thanks,

-- Steve


-
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: Exploit in 2.6 kernels

[Adrian Bunk]

On Wed, Apr 13, 2005 at 03:01:46PM +0100, John M Collins wrote:
>...
> Could I possibly make a suggestion for "make xconfig" in the kernel tree
> (and make other-kinds-of-config I suppose)?
> 
> I currently routinely copy the ".config" out of the previous kernel tree
> before I start to save working through questions about sound cards I
> never heard of and so forth.
> 
> Could it perhaps optionally initialise most of the settings to fit the
> current machine and/or grab the last lot of settings
> from /proc/config.gz?


  zcat /proc/config.gz > .config


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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: FUSYN and RT

[Inaky Perez-Gonzalez]

> Steven Rostedt <[EMAIL PROTECTED]> writes:

> On Fri, 2005-04-15 at 18:20 -0700, Inaky Perez-Gonzalez wrote:

>> Back to my example before: in fusyn, a user space lock is a kernel
>> space lock with a wrapper, that provides all that is necessary for
>> doing the fast path and handling user-space specific issues.

> ...

> So, to answer your question. Looking forward, I kind of see two
> different structures for locking.  The rt_mutex and something that
> is used by fusyn, then there being some common structure (or ops)
> that they both use to implement the PI.  But the implementation of
> how the locks work may as well be different. But this may not be the
> case, and there still be two structures but the fusyn just contain a
> rt_mutex lock to do the actual locking and the rest of the structure
> be used for showing information or what not back up to user
> space. This stuff wouldn't be necessary for the rt_mutex. We need to
> keep rt_mutex small since it is used all over the place.

I see--would the following fit your view?

This would be a kernel lock [from the fusyn patch, linux/fulock.h]:

/** A fulock, mutex usable from the kernel. */
struct fulock {
struct fuqueue fuqueue;
struct task_struct *owner;
unsigned flags;
struct plist olist_node;
};

This has an in kernel API so you can use it from modules or kernel
code.

And this would be kernel representation of a user space lock [from
linux/fulock_kernel.h]:

struct ufulock {
struct fulock fulock;
struct vlocator vlocator;
struct page *page;
};

This is exposed via system calls with fast-path as an option.

This is basically the kernel lock that provides the functionality and
an structure to keep a tab to where the thing is in user space (hash
queues a la futex). The ops are hidden in fulock.fuqueue.ops [fuqueue
is the waitqueue--just for reference, from linux/fuqueue.h].

/** A fuqueue, a prioritized wait queue usable from kernel space. */
struct fuqueue {
spinlock_t lock;
struct plist wlist;
struct fuqueue_ops *ops;
};

-- 

Inaky

-
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: ACPI/HT or Packet Scheduler BUG?

[Herbert Xu]

On Fri, Apr 15, 2005 at 10:54:22PM +, Thomas Graf wrote:
>
> Another case were it's not locked is upon a deletion of a class where
> the class deletes its inner qdisc, although there is only one case
> how this can happen and that's under rtnl semaphore so there is no
> way we can have a dumper at the same time.

Sorry, that's where tc went astray :)

The assumption that the rtnl is held during dumping is false.  It is
only true for the initial dump call.  All subsequent dumps are not
protected by the rtnl.

The solution is certainly not to place the dumpers under rtnl :)
The dump operation is read-only and should not need any exclusive
locks.

In fact the whole qdisc locking is a mess.  It's a cross-breed
between locking with ad-hoc reference counting and RCU.  What's
more, the RCU is completely useless too because for the case
where we actually have a queue we still end up taking the spin
lock on each transmit! I think someone's been benchmarking the
loopback device again :)

It needs to be reengineered.

Here is a quick'n'dirty fix to the problem at hand.  What happened
between 2.6.10-rc1 and 2.6.10-rc2 is that qdisc_destroy started
changing the next pointer of qdisc entries which totally confuses
the readers because qdisc_destroy doesn't always take the tree lock.

This patch tries to ensure that all top-level calls to qdisc_destroy
come under the tree lock.  As Thomas correctedly pointed out, most
of the other qdisc_destroy calls occur after the top qdisc has been
unlinked from the device qdisc_list.  However, someone should go
through each one of the remaining ones (they're all in the individual
sch_* implementations) and make sure that this assumption is really
true.

Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>

If anyone has cycles to spare and a stomach strong enough for
this stuff, here is your chance :)

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
= net/sched/sch_api.c 1.47 vs edited =
--- 1.47/net/sched/sch_api.c2005-04-01 14:35:56 +10:00
+++ edited/net/sched/sch_api.c  2005-04-16 08:47:16 +10:00
@@ -608,9 +608,9 @@
return err;
if (q) {
qdisc_notify(skb, n, clid, q, NULL);
-   spin_lock_bh(>queue_lock);
+   qdisc_lock_tree(dev);
qdisc_destroy(q);
-   spin_unlock_bh(>queue_lock);
+   qdisc_unlock_tree(dev);
}
} else {
qdisc_notify(skb, n, clid, NULL, q);
@@ -743,17 +743,17 @@
err = qdisc_graft(dev, p, clid, q, _q);
if (err) {
if (q) {
-   spin_lock_bh(>queue_lock);
+   qdisc_lock_tree(dev);
qdisc_destroy(q);
-   spin_unlock_bh(>queue_lock);
+   qdisc_unlock_tree(dev);
}
return err;
}
qdisc_notify(skb, n, clid, old_q, q);
if (old_q) {
-   spin_lock_bh(>queue_lock);
+   qdisc_lock_tree(dev);
qdisc_destroy(old_q);
-   spin_unlock_bh(>queue_lock);
+   qdisc_unlock_tree(dev);
}
}
return 0;

Re: [patch] sched: fix sched domain degenerate

[Nick Piggin]

Siddha, Suresh B wrote:
On Fri, Apr 15, 2005 at 11:03:20PM +1000, Nick Piggin wrote:
Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c   2005-04-15 22:52:25.0 +1000
+++ linux-2.6/kernel/sched.c2005-04-15 22:58:54.0 +1000
@@ -4844,7 +4844,14 @@ static int __devinit sd_parent_degenerat
/* WAKE_BALANCE is a subset of WAKE_AFFINE */
if (cflags & SD_WAKE_AFFINE)
pflags &= ~SD_WAKE_BALANCE;
-   if ((~sd->flags) & parent->flags)
+   /* Flags needing groups don't count if only 1 group in parent */
+   if (parent->groups == parent->groups->next) {
+   pflags &= ~(SD_LOAD_BALANCE |
+   SD_BALANCE_NEWIDLE |
+   SD_BALANCE_FORK |
+   SD_BALANCE_EXEC);
+   }

This patch works fine and I like this fix. But should n't we be adding 
SD_WAKE_AFFINE and SD_WAKE_BALANCE to this list?

Hmm, well they don't use groups, but I guess they can be excluded,
because if the parent span is the same as the child span (and that
is true at this point), then SD_WAKE_AFFFINE/BALANCE in the parent
will never be executed. Good point.
wake_idle should be doing a similar thing too, but that needs a bit
of work.
And about SD_BALANCE_FORK, now that we have multi level sbe/sbf, we should 
add this flag to SD_CPU/SIBLING_INIT too..

I guess we should think about it. It depends - does SD_BALANCE_FORK
make sense on a plain SMP machine? If so, then it probably makes
sense to be in the 'SMP' domain on a NUMA system, otherwise not.
I suspect that for BALANCE_FORK, the answer may be no. On an SMP, it
is far less disastrous to misplace tasks and have them picked up by
the periodic rebalancer. What's more, BALANCE_FORK does add a non
trivial overhead when moving tasks to other CPUs.
But it's open for debate. I haven't done comprehensive tests.
--
SUSE Labs, Novell Inc.
-
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: FUSYN and RT

[Steven Rostedt]

On Fri, 2005-04-15 at 18:20 -0700, Inaky Perez-Gonzalez wrote:
> > Steven Rostedt <[EMAIL PROTECTED]> writes:
> >> On Fri, 2005-04-15 at 16:37 -0700, Inaky Perez-Gonzalez wrote:
> 
> > I have to agree with Inaky too.  Fundamentally, PI is the same for
> > the system regardless of if the locks are user or kernel. I still
> > don't see the difference here.  But for other reasons, I feel that
> > the user lock should be a different structure from the kernel
> > lock. That's why I mentioned that it would be a good idea if Ingo
> > modulized the PI portion.  So that part would be the same for
> > both. If he doesn't have the time to do it, I'll do it :-) (Ingo,
> > all you need to do is ask.)
> 
> Can you qualify "different" here? I don't mean that they need to be
> interchangeable, but that they are esentially the same. Obviously the
> user cannot acces the kernel locks, but kernel locks are *used* to
> implement user space locks.
> 
> Back to my example before: in fusyn, a user space lock is a kernel
> space lock with a wrapper, that provides all that is necessary for
> doing the fast path and handling user-space specific issues.

I was actually thinking of just giving more flexibility to the user
locks, in case the application using them needed more information, for
debugging or whatever.  Honestly, I haven't looked at the fusyn code
yet, so I don't really know if there is a difference.  As I said, I
"feel" the user lock should be different. I really don't know if they
should.

So, to answer your question. Looking forward, I kind of see two
different structures for locking.  The rt_mutex and something that is
used by fusyn, then there being some common structure (or ops) that they
both use to implement the PI.  But the implementation of how the locks
work may as well be different. But this may not be the case, and there
still be two structures but the fusyn just contain a rt_mutex lock to do
the actual locking and the rest of the structure be used for showing
information or what not back up to user space. This stuff wouldn't be
necessary for the rt_mutex. We need to keep rt_mutex small since it is
used all over the place.

That's all I meant.


-- Steve


-
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] X86_64 TASK_SIZE cleanup

[Zou, Nanhai]

Hi,
   This patch will clean up the X86_64 compatibility mode TASK_SIZE
define thus fix some bugs found in X86_64 compatibility mode program.

Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]> 
Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]>



x86_64-compat-tasksize-fix.patch
Description: x86_64-compat-tasksize-fix.patch

Re: Fortuna

[David Wagner]

linux wrote:
>/dev/urandom depends on the strength of the crypto primitives.
>/dev/random does not.  All it needs is a good uniform hash.

That's not at all clear.  I'll go farther: I think it is unlikely
to be true.

If you want to think about cryptographic primitives being arbitrarily
broken, I think there will be scenarios where /dev/random is insecure.

As for what you mean by "good uniform hash", I think you'll need to
be a bit more precise.

>Do a bit of reading on the subject of "unicity distance".

Yes, I've read Shannon's original paper on the subject, as well
as many other treatments.

I stand by my comments above.
-
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: Fortuna

[David Wagner]

Theodore Ts'o  wrote:
>With a properly set up set of init scripts, /dev/random is initialized
>with seed material for all but the initial boot [...]

I'm not so sure.  Someone posted on this mailing list several months
ago examples of code in the kernel that looks like it could run before
those init scripts are run, and that looks like it might well be using
/dev/*random before it has been seeded.

I never saw any response.

>It fundamentally assumes that crypto
>primitives are secure (when the recent break of MD4, MD5, and now SHA1
>should have been a warning that this is a Bad Idea (tm)),

It looks to me like the recent attacks on MD4, MD5, and SHA1 do not
endanger /dev/random.  Those attacks affect collision-resistance, but
it looks to me like the security of /dev/random relies on other properties
of the hash function (e.g., pseudorandomness, onewayness) which do not
seem to be threatened by these attacks.  But of course this is a complicated
business, and maybe I overlooked something about the way /dev/random uses
those hash functions.  Did I miss something?

As for which threat models are realistic, I consider it more likely
that my box will be hacked in a way that affects /dev/random than that
SHA1 will be broken in a way that affects /dev/random.

>In addition, Fortuna is profligate with entropy, [...]

Yup.
-
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: BUGs in 2.6.12-rc2-RT-V0.7.45-01

[William Weston]

On Fri, 15 Apr 2005, Ingo Molnar wrote:

> * William Weston <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, 13 Apr 2005, Ingo Molnar wrote:
> > 
> > > what are you using kprobes for? Do you get lockups even if you disable 
> > > kprobes?
> > 
> > Various processes will lockup on the P4/HT system, usually while under 
> > some load.  The processes cannot be killed.  X will lockup once or 
> > twice a day (which means my console, and thus sysrq, are toast), but I 
> > can still ssh in.  Nothing is logged by the kernel.  Are there any 
> > post-lockup forensics that can be performed before I reboot?
> 
> could you try the -44-03 patch:
> 
>  
> http://redhat.com/~mingo/realtime-preempt/older/realtime-preempt-2.6.12-rc2-V0.7.44-03
> 
> this doesnt have the plist changes yet. Is this one more stable?

With 2.6.12-rc2-V0.7.44-03, the P4/HT box has been stable all day.  I'm 
seeing another BUG on boot, not kprobes related this time:

Freeing unused kernel memory: 192k freed
logips2pp: Detected unknown logitech mouse model 86
input: ImExPS/2 Logitech Explorer Mouse on isa0060/serio1
BUG: kstopmachine:1054 RT task yield()-ing!
 [] dump_stack+0x23/0x25 (20)
 [] yield+0x67/0x69 (20)
 [] stop_machine+0xa4/0x15e (40)
 [] do_stop+0x15/0x77 (20)
 [] kthread+0xab/0xd3 (48)
 [] kernel_thread_helper+0x5/0xb (563617812)
---
| preempt count: 0001 ]
| 1-level deep critical section nesting:

.. []  print_traces+0x1b/0x52
.[] ..   ( <= dump_stack+0x23/0x25)

ns83820.c: National Semiconductor DP83820 10/100/1000 driver.
eth0: ns83820.c: 0x22c: 49001186, subsystem: 1186:4900
eth0: ns83820 v0.20: DP83820 v1.2: 00:50:ba:37:d4:bc io=0xff8ff000 irq=18 f=sg


I'm also seeing an unlikely wakeup time:

(   X-3581 |#1): new 2533412143 us maximum-latency wakeup.


Otherwise, this on seems very stable.


Best Regards,
--William Weston


--
/* William Weston <[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: Fortuna

[David Wagner]

Jean-Luc Cooke  wrote:
>Info-theoretic randomness is a strong desire of some/many users, [..]

I don't know.  Most of the time that I've seen users say they want
information-theoretic randomness, I've gotten the impression that those
users didn't really understand what information-theoretic randomness means,
and their applications usually didn't need information-theoretic randomness
in the first place.

As for those who reject computational security because of its
unproven nature, they should perhaps be warned that any conjectured
information-theoretic security of /dev/random is also unproven.

Personally, I feel the issue of information-theoretic security
is a distraction.  Given the widespread confusion about what
information-theoretic security means, I certainly sympathize with why
Jean-Luc Cooke left in the existing entropy estimation technique as a
way of side-stepping the whole argument.

Anyway, the bottom line is I don't consider "information-theoretic
arguments" as a very convincing reason to reject Cooke's proposal.
-
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: FUSYN and RT

[Inaky Perez-Gonzalez]

> Steven Rostedt <[EMAIL PROTECTED]> writes:
>> On Fri, 2005-04-15 at 16:37 -0700, Inaky Perez-Gonzalez wrote:

> I have to agree with Inaky too.  Fundamentally, PI is the same for
> the system regardless of if the locks are user or kernel. I still
> don't see the difference here.  But for other reasons, I feel that
> the user lock should be a different structure from the kernel
> lock. That's why I mentioned that it would be a good idea if Ingo
> modulized the PI portion.  So that part would be the same for
> both. If he doesn't have the time to do it, I'll do it :-) (Ingo,
> all you need to do is ask.)

Can you qualify "different" here? I don't mean that they need to be
interchangeable, but that they are esentially the same. Obviously the
user cannot acces the kernel locks, but kernel locks are *used* to
implement user space locks.

Back to my example before: in fusyn, a user space lock is a kernel
space lock with a wrapper, that provides all that is necessary for
doing the fast path and handling user-space specific issues.

>> As long as the concept of rwlock allows for it to have multiple
>> owners (read locks need to have them), the procedure is mostly the
>> same. However, this not being POSIX, nobody (yet) has asked for it.
>
> I don't think rwlocks work well with PI.  You can implement it, but
> it's like implementing multiple inheritance for Object Oriented
> languages...

I have to agree--that's why I don't go further than saying in theory
is possible. I would only touch it with a ten foot pole or if someone
offered a lot in exchange :]

-- 

Inaky

-
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: FUSYN and RT

[Steven Rostedt]

On Fri, 2005-04-15 at 16:37 -0700, Inaky Perez-Gonzalez wrote:
> > Bill Huey (hui) <[EMAIL PROTECTED]> writes:
> 
> > Ok, I've been thinking about these issues and I believe there are a
> > number of misunderstandings here. The user and kernel space mutexes
> > need to be completely different implementations. I'll have more on
> > this later.
> 
> > First of all, priority transitivity should be discontinuous at the
> > user/kernel space boundary, but be propagated by the scheduler, via
> > an API or hook, upon a general priority boost to the thread in
> > question.
> 
> This is not necessarily true. My temperature-regulating thread should
> be able to promote a task so it works around priority invertion, no
> matter if they are sharing a kernel or user space lock. 
> 
> By following your method, the pi engine becomes unnecesarily complex;
> you have actually two engines following two different propagation
> chains (one kernel, one user). If your mutexes/locks/whatever are the
> same with a different cover, then you can simplify the whole
> implementation by leaps.
> 

I have to agree with Inaky too.  Fundamentally, PI is the same for the
system regardless of if the locks are user or kernel. I still don't see
the difference here.  But for other reasons, I feel that the user lock
should be a different structure from the kernel lock. That's why I
mentioned that it would be a good idea if Ingo modulized the PI portion.
So that part would be the same for both. If he doesn't have the time to
do it, I'll do it :-)  (Ingo, all you need to do is ask.)

[...]

> > There will be problems trying to implement a Posix read/write lock
> 
> As long as the concept of rwlock allows for it to have multiple owners
> (read locks need to have them), the procedure is mostly the
> same. However, this not being POSIX, nobody (yet) has asked for it.
> 

I don't think rwlocks work well with PI.  You can implement it, but it's
like implementing multiple inheritance for Object Oriented languages.
Java didn't implement it because they say keeping it out makes the code
cleaner (probably true), but the real reason I bet, was that
implementing it makes everything much more complex.  The same goes with
rwlocks with multiple readers and PI. Without it makes for a cleaner
solution (for users as well as developers), and with it, it just makes
everything more complex.

-- Steve


-
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: Fortuna

[David Wagner]

>First, a reminder that the design goal of /dev/random proper is
>information-theoretic security.  That is, it should be secure against
>an attacker with infinite computational power.

I am skeptical.
I have never seen any convincing evidence for this claim,
and I suspect that there are cases in which /dev/random fails
to achieve this standard.

And it seems I am not the only one.  See, e.g., Section 5.3 of:
http://eprint.iacr.org/2005/029

Fortunately, it doesn't matter whether /dev/random provides
information-theoretic security.  I have reasonable confidence that
it provides computational security, and that is all that applications
need.
-
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: Fortuna

[David Wagner]

Matt Mackall  wrote:
>While it may have some good properties, it lacks
>some that random.c has, particularly robustness in the face of failure
>of crypto primitives.

It's probably not a big deal, because I'm not worried about the
failure of standard crypto primitives, but--

Do you know of any analysis to back up the claim that /dev/random
will be robust in the failure of crypto primitives?  I have never
seen anyone try to do such an analysis, but maybe you know of something
that I don't.
-
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] tpm: Stop taking over the non-unique lpc bus PCI ID, Also timer, stack and enum fixes

[Greg KH]

On Fri, Apr 15, 2005 at 05:06:06PM -0500, Kylene Hall wrote:
> This patch is against the 2.6.12-rc2 kernel source.  It changes the tpm 
> drivers from defining a pci driver structure to a format similar to the 
> drivers/char/watchdog/i8xx_tco driver.  This is necessary because the 
> lpc_bus only has one PCI ID and claiming that ID in the pci driver probe 
> process prevents other drivers from finding their hardware.

NO!  DO NOT use pci_find_device().  It is broken for systems with pci
hotplug (which means any pci system).  Please use the way the driver
currently works, that is correct.

> This patch 
> also fixes numerous problems that were pointed out with timer 
> manipulations, large stack objects, lack of enums and defined constants.

Why not split these up into the proper individual patches?  Remember,
one patch per "change".

> Still lingering:
> 
> How can I receive Hotplug and ACPI events without being a PCI driver?

You can't, so don't.

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: SCSI opcode 0x80 and 3ware Escalade 7000 ATA RAID

[Kyle Moffett]

On Apr 15, 2005, at 18:50, adam radford wrote:
Make sure you are are using the 3ware character ioctl interface at
/dev/twe0 (dynamic major, controller number minor) for your
smartmontools, not /dev/sda.
Hmm, I don't have any /dev/twe* here.  I _do_ have hotplug, udev, etc,
installed, and this is a 2.6 machine, so I'm not sure what could be 
wrong.
How recent was this change?

The old interface from smartmontools used SCSI_IOCTL_SEND_COMMAND
ioctls with a special passthru opcode of 0x80 that would get passed
to the driver.  This interface is deprecated in the driver and the
kernel.
Ok.  Now if only I could find it.  Is there anyplace in sysfs that I
can check manually to see what the dynamic major is?  I'd like to
try creating the device by hand if I can't get Debian hotplug to see
it.
Cheers,
Kyle Moffett
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$
L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r  
!y?(-)
--END GEEK CODE BLOCK--

-
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: [RFC] Add support for semaphore-like structure with support for asynchronous I/O

[Benjamin LaHaise]

On Fri, Apr 15, 2005 at 03:42:54PM -0700, Trond Myklebust wrote:
> AFAICS You grab the wait_queue_t lock once in down()/__mutex_lock()
> order to try to take the lock (or queue the waiter if that fails), then
> once more in order to pass the mutex on to the next waiter on
> up()/mutex_unlock(). That is more or less the exact same thing I was
> doing with iosems using bog-standard waitqueues, and which Ben has
> adapted to his mutexes. What am I missing?

I didn't quite see that either.

What about the use of atomic operations on frv?  Are they more lightweight 
than a semaphore, making for a better fastpath?

-ben
-- 
"Time is what keeps everything from happening all at once." -- John Wheeler
-
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: FUSYN and RT

[Inaky Perez-Gonzalez]

> Bill Huey (hui) <[EMAIL PROTECTED]> writes:

> Ok, I've been thinking about these issues and I believe there are a
> number of misunderstandings here. The user and kernel space mutexes
> need to be completely different implementations. I'll have more on
> this later.

> First of all, priority transitivity should be discontinuous at the
> user/kernel space boundary, but be propagated by the scheduler, via
> an API or hook, upon a general priority boost to the thread in
> question.

This is not necessarily true. My temperature-regulating thread should
be able to promote a task so it works around priority invertion, no
matter if they are sharing a kernel or user space lock. 

By following your method, the pi engine becomes unnecesarily complex;
you have actually two engines following two different propagation
chains (one kernel, one user). If your mutexes/locks/whatever are the
same with a different cover, then you can simplify the whole
implementation by leaps.

> With all of that in place, you do a couple of things for the mutex
> implementation. First, you convert as much code of the current RT
> mutex code to be type polymorphic as you can:

> ...

> I'd apply these implementation ideas across both mutexes, but keep
> the individual mutexes functionality distinct. I look at this
> problem from more of a reusability perspective than anything else.
 
You are talking of what is implemented in fusyn already; the only
differences are that (a) I don't use macros, but funcition pointers
(mutex ops) and (b) transitivity across user/kernel space is allowed.

> There will be problems trying to implement a Posix read/write lock

As long as the concept of rwlock allows for it to have multiple owners
(read locks need to have them), the procedure is mostly the
same. However, this not being POSIX, nobody (yet) has asked for it.

-- 

Inaky

-
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] sched: fix sched domain degenerate

[Siddha, Suresh B]

On Fri, Apr 15, 2005 at 11:03:20PM +1000, Nick Piggin wrote:
> Index: linux-2.6/kernel/sched.c
> ===
> --- linux-2.6.orig/kernel/sched.c 2005-04-15 22:52:25.0 +1000
> +++ linux-2.6/kernel/sched.c  2005-04-15 22:58:54.0 +1000
> @@ -4844,7 +4844,14 @@ static int __devinit sd_parent_degenerat
>   /* WAKE_BALANCE is a subset of WAKE_AFFINE */
>   if (cflags & SD_WAKE_AFFINE)
>   pflags &= ~SD_WAKE_BALANCE;
> - if ((~sd->flags) & parent->flags)
> + /* Flags needing groups don't count if only 1 group in parent */
> + if (parent->groups == parent->groups->next) {
> + pflags &= ~(SD_LOAD_BALANCE |
> + SD_BALANCE_NEWIDLE |
> + SD_BALANCE_FORK |
> + SD_BALANCE_EXEC);
> + }

This patch works fine and I like this fix. But should n't we be adding 
SD_WAKE_AFFINE and SD_WAKE_BALANCE to this list?

And about SD_BALANCE_FORK, now that we have multi level sbe/sbf, we should 
add this flag to SD_CPU/SIBLING_INIT too..

thanks,
suresh
-
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: [SATA] status reports updated

[Bodo Eggert <[EMAIL PROTECTED]>]

Bodo Eggert <[EMAIL PROTECTED]> wrote:
> Tomasz Chmielewski <[EMAIL PROTECTED]> wrote:

>> Is there a way to check what firmware a drive has
> 
> The obvious one: hdparm


Or, since hdparm doesn't work for SCSI devices,
cat /sys/block/sd$n/device/rev

(might depend on the vendor)
-- 
Funny quotes:
21. Support bacteria - they're the only culture some people have.

Friß, Spammer: [EMAIL PROTECTED] [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: intercepting syscalls

[Bodo Eggert <[EMAIL PROTECTED]>]

Richard B. Johnson <[EMAIL PROTECTED]> wrote:

> LD_PRELOAD some custom 'C' runtime library functions, grab open()
> read(), write(), etc.

This will work wonderfully with static binaries.
-- 
"Bravery is being the only one who knows you're afraid."
-David Hackworth

-
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: [SATA] status reports updated

[Måns Rullgård]

Tomasz Chmielewski <[EMAIL PROTECTED]> writes:

> Andre Tomt wrote:
>> Tomasz Chmielewski wrote:
>> <
>>
>>> [1] although my drive is blacklisted (Seagate barracuda -
>>> ST3200822AS), I "unblacklisted" it to get full performance - it's
>>> under heavy stress for 12th hour, and still no error.
>> It could be that your drive has newer firmware. Too bad firmware
>> upgrades for HD's are hard to come by nowadays.
>
> Is there a way to check what firmware a drive has (either by using
> some software - which would be the best option, or by reading a label
> on a drive)?

Seagate drives have the firmware version printed on the label.  The
version is also visible in "dmesg" output:

  Vendor: ATA   Model: ST3160827AS   Rev: 3.03
  Type:   Direct-Access  ANSI SCSI revision: 05

The "Rev" number is the firmware version.

-- 
Måns Rullgård
[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: 2.6.12-rc2-mm3

[Benjamin Herrenschmidt]

On Fri, 2005-04-15 at 20:23 +0200, Juergen Kreileder wrote:
> Juergen Kreileder <[EMAIL PROTECTED]> writes:
> 
> > Andrew Morton <[EMAIL PROTECTED]> writes:
> >
> >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> >
> > I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
> 
> I think I finally found the culprit.  Both rc2-mm3 and rc1-mm1 work
> fine when I reverse the timer-* patches.
> 
> Any idea?  Bug in my ppc64 gcc?

Or a bug in those patches, I'll have a look as soon as I find 5 minutes.

Ben.


-
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: ACPI/HT or Packet Scheduler BUG?

[Thomas Graf]

* Steven Rostedt <[EMAIL PROTECTED]> 2005-04-15 17:54
> > ==
> >   list_for_each_entry(cq, , list)
> >list_for_each_entry_safe(q, n, >dev->qdisc_list, list)
> > if (TC_H_MAJ(q->parent) == TC_H_MAJ(cq->handle)) {
> >  if (q->ops->cl_ops == NULL)
> >   list_del_init(>list);
> >  else
> >   list_move_tail(>list, );
> > }
> >   list_for_each_entry_safe(cq, n, , list)
> >list_del_init(>list);
> > ==
> > 
> > ...and it happens when q->ops->cl_ops is NULL and 
> > list_del_init(>list) is executed.
> > 
> > The stuff from include/linux/list.h looks ok, it seems like one 
> > of those two iterations (list_for_each_entry() and 
> > list_for_each_entry_safe()) enters an endless loop when an element is 
> > removed from the list under some circumstances.
> 
> There's a comment above qdisc_destroy that says:
> 
> /* Under dev->queue_lock and BH! */
> 
> I'm not so sure this is the case.

It's not, we should change the comment. qdisc_destroy calls for inner
leaf qdiscs comming from rcu scheduled __qdisc_destroy -> qdisc::destroy()
-> qdisc_destroy() will not have a lock on queue_lock but it shouldn't be
a problem since the qdiscs cannot be found anymore.

Another case were it's not locked is upon a deletion of a class where
the class deletes its inner qdisc, although there is only one case
how this can happen and that's under rtnl semaphore so there is no
way we can have a dumper at the same time.

A wild guess would be that one of the many wrong locking places where
dev->queue_lock is acquired but qdisc_tree_lock is not is the problem.
tc_dump_qdisc assumed that locking on qdisc_tree_lock is enough which
is absolutely right, still most callers to qdisc_destroy only lock
on dev->queue_lock for the modification of the tree, which _was_ fine
before we used list.h since the unlinking was atomic. This is no news
and Patrick's patch in 2.6.10 ought to have fixed this by unlinking
inner leaf qdiscs from dev->qdisc_list and thus preventing them to
be found by anyone during unlocked calls to destroy_qdisc.

So... we might have a unlocked qdisc_destroy call for a qdisc not
properly unlinked from dev->qdisc_list.
-
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: SCSI opcode 0x80 and 3ware Escalade 7000 ATA RAID

[adam radford]

Make sure you are are using the 3ware character ioctl interface
at /dev/twe0 (dynamic major, controller number minor) for your smartmontools, 
not /dev/sda.  

i.e.  smartctl -a -d 3ware,X /dev/tweY

where X = port # of the drive whose information you want, Y=controller #.

The old interface from smartmontools used SCSI_IOCTL_SEND_COMMAND ioctls
with a special passthru opcode of 0x80 that would get passed to the
driver.  This interface
is deprecated in the driver and the kernel.

-Adam

On 4/15/05, Kyle Moffett <[EMAIL PROTECTED]> wrote:
> I've been getting the following message in syslog on a couple of my
> servers
> recently:
> 
> > Apr 15 16:41:18 king kernel: scsi: unknown opcode 0x80
> 
> I've tracked it down to the SCSI opcode verification patch that went in
> a
> while back.  I also determined that the trigger was our smartd/smartctl
> runs,
> which execute tests and get status on a regular basis.  Our kernel is
> latest
> Debian kernel-image-2.6.8-686-smp, although I've verified identical
> behavior
> with a recent kernel.org kernel.
> 
> The below strace run generates exactly 8 warnings every time.
> 
> On another (unrelated) note, we also get the following messages at the
> rate
> at which our Cisco does IPv6 router-announcement broadcasts.  This is on
> every kernel that we have, from 2.4 through 2.6.  Is there something
> wrong
> with our setup, or is this just a spurious error?  (NOTE: I don't know
> for
> sure that our Cisco's set up properly, we're all new at IPv6 here, and
> we're
> not actually relying on the advertising yet, so...)
> 
> > Apr 15 18:01:27 king kernel: IPv6 addrconf: prefix with wrong length 49
> 
> I'll get a packet trace of necessary.
> 
> Thanks for your help!
> 
> Here's an example smartctl log (Without the console warnings).
> > # strace -o smart.trace smartctl /dev/sda -d 3ware,0 -a
> > smartctl version 5.32 Copyright (C) 2002-4 Bruce Allen
> > Home page is http://smartmontools.sourceforge.net/
> >
> > === START OF INFORMATION SECTION ===
> > Device Model: Maxtor 6Y200P0
> > Serial Number:Y60PVCZE
> > Firmware Version: YAR41BW0
> > Device is:In smartctl database [for details use: -P show]
> > ATA Version is:   7
> > ATA Standard is:  ATA/ATAPI-7 T13 1532D revision 0
> > Local Time is:Fri Apr 15 17:25:49 2005 EDT
> > SMART support is: Available - device has SMART capability.
> > SMART support is: Enabled
> >
> > === START OF READ SMART DATA SECTION ===
> > SMART overall-health self-assessment test result: PASSED
> >
> > General SMART Values:
> > Offline data collection status:  (0x82) Offline data collection
> > activity
> > was completed without error.
> > Auto Offline Data Collection:
> > Enabled.
> > Self-test execution status:  (   0) The previous self-test routine
> > completed
> > without error or no self-test
> > has ever
> > been run.
> > Total time to complete Offline
> > data collection: ( 243) seconds.
> > Offline data collection
> > capabilities:(0x5b) SMART execute Offline
> > immediate.
> > Auto Offline data collection
> > on/off support.
> > Suspend Offline collection
> > upon new
> > command.
> > Offline surface scan supported.
> > Self-test supported.
> > No Conveyance Self-test
> > supported.
> > Selective Self-test supported.
> > SMART capabilities:(0x0003) Saves SMART data before
> > entering
> > power-saving mode.
> > Supports SMART auto save timer.
> > Error logging capability:(0x01) Error logging supported.
> > No General Purpose Logging
> > support.
> > Short self-test routine
> > recommended polling time:(   2) minutes.
> > Extended self-test routine
> > recommended polling time:(  91) minutes.
> >
> > SMART Attributes Data Structure revision number: 16
> > Vendor Specific SMART Attributes with Thresholds:
> > ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE
> > UPDATED  WHEN_FAILED RAW_VALUE
> >   3 Spin_Up_Time0x0027   252   252   063Pre-fail
> > Always   -   5945
> >   4 Start_Stop_Count0x0032   253   253   000Old_age
> > Always   -   17
> >   5 Reallocated_Sector_Ct   0x0033   253   253   063Pre-fail
> > Always   -   1
> >   6 Read_Channel_Margin 0x0001   253   253   100Pre-fail
> > Offline  -   0
> >   7 Seek_Error_Rate 0x000a   253   252   000Old_age
> > Always   -   0
> >   8 

Re: FUSYN and RT

[hui]

On Wed, Apr 13, 2005 at 11:46:40AM -0400, Steven Rostedt wrote:
> On Tue, 2005-04-12 at 17:27 -0700, Daniel Walker wrote:
> > There is a great big snag in my assumptions. It's possible for a process
> > to hold a fusyn lock, then block on an RT lock. In that situation you
> > could have a high priority user space process be scheduled then block on
> > the same fusyn lock but the PI wouldn't be fully transitive , plus there
> > will be problems when the RT mutex tries to restore the priority. 
> > 
> > We could add simple hooks to force the RT mutex to fix up it's PI, but
> > it's not a long term solution.

Ok, I've been thinking about these issues and I believe there are a number
of misunderstandings here. The user and kernel space mutexes need to be
completely different implementations. I'll have more on this later.

First of all, priority transitivity should be discontinuous at the user/kernel
space boundary, but be propagated by the scheduler, via an API or hook,
upon a general priority boost to the thread in question.

You have thread A blocked in the kernel holding is onto userspace mutex 1a
and kernel mutex 2a. Thread A is priority boosted by a higher priority
thread B trying to acquire mutex 1a. The transitivity operation propagates
through the rest of the lock graph in userspace, via depth first search,
as usual. When it hits the last userspace mutex in question, this portion
of the propagation activity stops. Next, the scheduler itself finds out
that thread A has had it's priority altered because of a common priority
change API and starts another priority propagation operation in kernel
space to mutex 1b. There you have it. It's complete from user to kernel
space using a scheduler event/hook/api to propagate priority changes
into the kernel.

With all of that in place, you do a couple of things for the mutex
implementation. First, you convert as much code of the current RT mutex
code to be type polymorphic
as you can:

1) You use Daniel Walker's PI list handling for wait queue insertion for
   both mutex implementation. This is done since it's already a library
   and is already generic.

2) Then you generalize the dead lock detection code so that things like
   "what to do in a deadlock case" is determine at the instantiation of
   the code. You might have to use C preprocessor macros to do a generic
   implementation and then fill in the parametric values for creating a
   usable instance.

3) Make the grab owner code generic.

4) ...more part of the RT mutex...
   etc...

> How hard would it be to use the RT mutex PI for the priority inheritance
> for fusyn?  I only work with the RT mutex now and haven't looked at the
> fusyn.  Maybe Ingo can make a separate PI system with its own API that
> both the fusyn and RT mutex can use. This way the fusyn locks can still
> be separate from the RT mutex locks but still work together. 

I'd apply these implementation ideas across both mutexes, but keep the
individual mutexes functionality distinct. I look at this problem from
more of a reusability perspective than anything else.
 
> Basically can the fusyn work with the rt_mutex_waiter?  That's what I
> would pull into its own subsystem.  Have another structure that would
> reside in both the fusyn and RT mutex that would take over for the
> current rt_mutex that is used in pi_setprio and task_blocks_on_lock in
> rt.c.  So if both locks used the same PI system, then this should all be
> cleared up. 

Same thing...

There will be problems trying to implement a Posix read/write lock using
this method and the core RT mutex might have to be fundamentally altered
to handle recursion of some sort, decomposed into smaller bits and
recomposed into something else.

bill

-
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: [SATA] status reports updated

[Bodo Eggert <[EMAIL PROTECTED]>]

Tomasz Chmielewski <[EMAIL PROTECTED]> wrote:

> Is there a way to check what firmware a drive has

The obvious one: hdparm
-- 
"Just because you are paranoid, do'nt mean they're not after you."
-- K.Cobain

Friß, Spammer: [EMAIL PROTECTED] [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: [RFC] Add support for semaphore-like structure with support for asynchronous I/O

[Trond Myklebust]

fr den 15.04.2005 Klokka 17:13 (+0100) skreiv David Howells:
> Can I suggest you don't use a wait_queue_t in your mutex? The way you've
> implemented your mutex you appear to have to take spinlocks and disable
> interrupts a lot more than is necessary.

> You might want to look at how I've implemented semaphores for the frv arch:
> 
>   include/asm-frv/semaphore.h
>   arch/frv/kernel/semaphore.c
> 
> On FRV disabling interrupts is quite expensive, so I've made my own simple
> semaphores that don't need to take spinlocks and disable interrupts in the
> down() path once the sleeping task has been queued[*]. These work in exactly
> the same way as rwsems.

> The point being that since up() needs to take the semaphore's spinlock
> anyway
> so that it can access the list, up() does all the necessary dequeuing
> of tasks
> before waking them up.

I'm looking at the code, and I'm completely failing to see your point.
Exactly how is that scheme incompatible with use of wait_queue_t?

AFAICS You grab the wait_queue_t lock once in down()/__mutex_lock()
order to try to take the lock (or queue the waiter if that fails), then
once more in order to pass the mutex on to the next waiter on
up()/mutex_unlock(). That is more or less the exact same thing I was
doing with iosems using bog-standard waitqueues, and which Ben has
adapted to his mutexes. What am I missing?

One of the motivations for doing that as far as the iosems were
concerned, BTW, was to avoid adding to this ecology of functionally
identical structures that we have for semaphores, rwsems, and wait
queues.

Cheers,
  Trond

-- 
Trond Myklebust <[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/

SCSI opcode 0x80 and 3ware Escalade 7000 ATA RAID

[Kyle Moffett]

I've been getting the following message in syslog on a couple of my 
servers
recently:

Apr 15 16:41:18 king kernel: scsi: unknown opcode 0x80
I've tracked it down to the SCSI opcode verification patch that went in 
a
while back.  I also determined that the trigger was our smartd/smartctl 
runs,
which execute tests and get status on a regular basis.  Our kernel is 
latest
Debian kernel-image-2.6.8-686-smp, although I've verified identical 
behavior
with a recent kernel.org kernel.

The below strace run generates exactly 8 warnings every time.
On another (unrelated) note, we also get the following messages at the 
rate
at which our Cisco does IPv6 router-announcement broadcasts.  This is on
every kernel that we have, from 2.4 through 2.6.  Is there something 
wrong
with our setup, or is this just a spurious error?  (NOTE: I don't know 
for
sure that our Cisco's set up properly, we're all new at IPv6 here, and 
we're
not actually relying on the advertising yet, so...)

Apr 15 18:01:27 king kernel: IPv6 addrconf: prefix with wrong length 49
I'll get a packet trace of necessary.
Thanks for your help!
Here's an example smartctl log (Without the console warnings).
# strace -o smart.trace smartctl /dev/sda -d 3ware,0 -a
smartctl version 5.32 Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION ===
Device Model: Maxtor 6Y200P0
Serial Number:Y60PVCZE
Firmware Version: YAR41BW0
Device is:In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  ATA/ATAPI-7 T13 1532D revision 0
Local Time is:Fri Apr 15 17:25:49 2005 EDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status:  (0x82) Offline data collection 
activity
was completed without error.
Auto Offline Data Collection: 
Enabled.
Self-test execution status:  (   0) The previous self-test routine 
completed
without error or no self-test 
has ever
been run.
Total time to complete Offline
data collection: ( 243) seconds.
Offline data collection
capabilities:(0x5b) SMART execute Offline 
immediate.
Auto Offline data collection 
on/off support.
Suspend Offline collection 
upon new
command.
Offline surface scan supported.
Self-test supported.
No Conveyance Self-test 
supported.
Selective Self-test supported.
SMART capabilities:(0x0003) Saves SMART data before 
entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability:(0x01) Error logging supported.
No General Purpose Logging 
support.
Short self-test routine
recommended polling time:(   2) minutes.
Extended self-test routine
recommended polling time:(  91) minutes.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE  
UPDATED  WHEN_FAILED RAW_VALUE
  3 Spin_Up_Time0x0027   252   252   063Pre-fail  
Always   -   5945
  4 Start_Stop_Count0x0032   253   253   000Old_age   
Always   -   17
  5 Reallocated_Sector_Ct   0x0033   253   253   063Pre-fail  
Always   -   1
  6 Read_Channel_Margin 0x0001   253   253   100Pre-fail  
Offline  -   0
  7 Seek_Error_Rate 0x000a   253   252   000Old_age   
Always   -   0
  8 Seek_Time_Performance   0x0027   251   248   187Pre-fail  
Always   -   47575
  9 Power_On_Minutes0x0032   220   220   000Old_age   
Always   -   849h+05m
 10 Spin_Retry_Count0x002b   252   252   157Pre-fail  
Always   -   0
 11 Calibration_Retry_Count 0x002b   253   252   223Pre-fail  
Always   -   0
 12 Power_Cycle_Count   0x0032   253   253   000Old_age   
Always   -   19
192 Power-Off_Retract_Count 0x0032   253   253   000Old_age   
Always   -   0
193 Load_Cycle_Count0x0032   253   253   000Old_age   
Always   -   0
194 Temperature_Celsius 0x0032   253   253   000Old_age   
Always   -   12
195 Hardware_ECC_Recovered  0x000a   253   252   000Old_age   
Always   -   5743
196 Reallocated_Event_Count 0x0008   253   253   000Old_age  

Slab Corruption and RT

[Daniel Walker]

I get Slab corruption while repeatedly loading and unloading small (3k) 
executables that just loop calling gettimeofday().. The 
"last user" is alway __mmdrop() . This only happens under RT ..

I think this is related to a problem observed by Steven Rostedt . 

Another trigger is to run bonnie++ with 2timer_test (from high res 
timers/libposixtime) run repeatedly. In this case, you end up Slab 
corruption and with a corrupted timer list which leads to an OOPS.


Daniel



<3>Slab corruption: start=c1972424, len=940
Slab corruption: start=c1972424, len=940
<3>Redzone: 0x5a2cf071/0x5a2cf071.
Redzone: 0x5a2cf071/0x5a2cf071.
<3>Last user: []Last user: 
[](__mmdrop+0xa0/0xe0)(__mmdrop+0xa0/0xe0)

<3>0c0:0c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6a 6a 6b 6b 6b 
6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b

<3>Prev obj: start=c197206c, len=940
Prev obj: start=c197206c, len=940
<3>Redzone: 0x170fc2a5/0x170fc2a5.
Redzone: 0x170fc2a5/0x170fc2a5.
<3>Last user: []Last user: 
[](mm_alloc+0x1c/0x74)(mm_alloc+0x1c/0x74)

<3>000:000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00

<3>010:010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 40 40 00 00 00 00 af af c1 c1

<3>Next obj: start=c19727dc, len=940
Next obj: start=c19727dc, len=940
<3>Redzone: 0x170fc2a5/0x170fc2a5.
Redzone: 0x170fc2a5/0x170fc2a5.
<3>Last user: []Last user: 
[](mm_alloc+0x1c/0x74)(mm_alloc+0x1c/0x74)

<3>000:000: 9c 9c 71 71 f9 f9 c1 c1 94 94 2d 2d c4 c4 c1 c1 1c 1c 7f 7f f9 
f9 c1 c1 68 68 dc dc 02 02 c0 c0

<3>010:010: 78 78 2c 2c 07 07 c0 c0 00 00 00 00 00 00 40 40 00 00 20 20 1a 
1a 40 40 00 00 00 00 a7 a7 c1 c1




-
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] tpm: Stop taking over the non-unique lpc bus PCI ID, Also timer, stack and enum fixes

[Kylene Hall]

This patch is against the 2.6.12-rc2 kernel source.  It changes the tpm 
drivers from defining a pci driver structure to a format similar to the 
drivers/char/watchdog/i8xx_tco driver.  This is necessary because the 
lpc_bus only has one PCI ID and claiming that ID in the pci driver probe 
process prevents other drivers from finding their hardware.  This patch 
also fixes numerous problems that were pointed out with timer 
manipulations, large stack objects, lack of enums and defined constants.

Still lingering:

How can I receive Hotplug and ACPI events without being a PCI driver?

The first person to the lpc bus needs to call pci_enable_device and the 
last to leave one should call pci_disable_device, how as a device driver 
on this bus do I know if I am the first or last one and need to make the 
appropriate call?

Thanks,
Kylie Hall

Signed-off-by: Kylene Hall <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.12-rc2/drivers/char/tpm/tpm_atmel.c 
linux-2.6.12-rc2-tpmdd/drivers/char/tpm/tpm_atmel.c
--- linux-2.6.12-rc2/drivers/char/tpm/tpm_atmel.c   2005-04-15 
16:31:21.0 -0500
+++ linux-2.6.12-rc2-tpmdd/drivers/char/tpm/tpm_atmel.c 2005-04-15 
16:26:17.0 -0500
@@ -22,17 +22,22 @@
 #include "tpm.h"
 
 /* Atmel definitions */
-#defineTPM_ATML_BASE   0x400
+enum {
+   TPM_ATML_BASE = 0x400
+};
 
 /* write status bits */
-#defineATML_STATUS_ABORT   0x01
-#defineATML_STATUS_LASTBYTE0x04
-
+enum {
+   ATML_STATUS_ABORT = 0x01,
+   ATML_STATUS_LASTBYTE = 0x04
+};
 /* read status bits */
-#defineATML_STATUS_BUSY0x01
-#defineATML_STATUS_DATA_AVAIL  0x02
-#defineATML_STATUS_REWRITE 0x04
-
+enum {
+   ATML_STATUS_BUSY = 0x01,
+   ATML_STATUS_DATA_AVAIL = 0x02,
+   ATML_STATUS_REWRITE = 0x04,
+   ATML_STATUS_READY = 0x08
+};
 
 static int tpm_atml_recv(struct tpm_chip *chip, u8 * buf, size_t count)
 {
@@ -48,8 +53,7 @@ static int tpm_atml_recv(struct tpm_chip
for (i = 0; i < 6; i++) {
status = inb(chip->vendor->base + 1);
if ((status & ATML_STATUS_DATA_AVAIL) == 0) {
-   dev_err(>pci_dev->dev,
-   "error reading header\n");
+   dev_err(chip->dev, "error reading header\n");
return -EIO;
}
*buf++ = inb(chip->vendor->base);
@@ -60,13 +64,12 @@ static int tpm_atml_recv(struct tpm_chip
size = be32_to_cpu(*native_size);
 
if (count < size) {
-   dev_err(>pci_dev->dev,
+   dev_err(chip->dev,
"Recv size(%d) less than available space\n", size);
for (; i < size; i++) { /* clear the waiting data anyway */
status = inb(chip->vendor->base + 1);
if ((status & ATML_STATUS_DATA_AVAIL) == 0) {
-   dev_err(>pci_dev->dev,
-   "error reading data\n");
+   dev_err(chip->dev, "error reading data\n");
return -EIO;
}
}
@@ -77,8 +80,7 @@ static int tpm_atml_recv(struct tpm_chip
for (; i < size; i++) {
status = inb(chip->vendor->base + 1);
if ((status & ATML_STATUS_DATA_AVAIL) == 0) {
-   dev_err(>pci_dev->dev,
-   "error reading data\n");
+   dev_err(chip->dev, "error reading data\n");
return -EIO;
}
*buf++ = inb(chip->vendor->base);
@@ -87,7 +89,7 @@ static int tpm_atml_recv(struct tpm_chip
/* make sure data available is gone */
status = inb(chip->vendor->base + 1);
if (status & ATML_STATUS_DATA_AVAIL) {
-   dev_err(>pci_dev->dev, "data available is stuck\n");
+   dev_err(chip->dev, "data available is stuck\n");
return -EIO;
}
 
@@ -98,9 +100,9 @@ static int tpm_atml_send(struct tpm_chip
 {
int i;
 
-   dev_dbg(>pci_dev->dev, "tpm_atml_send: ");
+   dev_dbg(chip->dev, "tpm_atml_send: ");
for (i = 0; i < count; i++) {
-   dev_dbg(>pci_dev->dev, "0x%x(%d) ", buf[i], buf[i]);
+   dev_dbg(chip->dev, "0x%x(%d) ", buf[i], buf[i]);
outb(buf[i], chip->vendor->base);
}
 
@@ -112,6 +114,27 @@ static void tpm_atml_cancel(struct tpm_c
outb(ATML_STATUS_ABORT, chip->vendor->base + 1);
 }
 
+static u8 tpm_atml_status(struct tpm_chip *chip)
+{
+   u8 status;
+
+   status = inb(chip->vendor->base + 1);
+
+   return status;
+}
+
+static struct pci_device_id tpm_pci_tbl[] __devinitdata = {
+   {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_0)},
+   {PCI_DEVICE(PCI_VENDOR_ID_INTEL, 

Re: ACPI/HT or Packet Scheduler BUG?

[Steven Rostedt]

Don't think the issue is the same. This problem is happening with
Tarhon-Onu Victor.  I'm including his previous two posts from LKML here.
So you can read the whole thing in one letter.  He states that the
problem started in 2.6.10-rc2 and looking at a diff, between rc1 and rc2
the list walk was added in qdisc_destroy.  Take a look at his scripts
and you may see that on a SMP machine, this my have a race condition.

-- Steve

>From April 8th:


I am not subscribed to this list so please CC me if you post a 
reply, if you need additional info or if you suggest a patch (in which 
I would be very interested).

Occurrence:
- the kernels must be compiled with Hyper Threading support (and
the CPU/MB must support it);
- a (tc) process is reading statistics from the htb tree and
another
tries to delete or deletes the tree.
The bug will not occur if the system is booted with acpi=off or 
if it's not SMP (HT) capable. I reproduced the bug on
2.6.10-1.770_FCsmp 
(Fedora Core update package) and vanilla 2.6.11, 2.6.11.5, 2.6.11.6, 
2.6.12-rc1 and 2.6.12-rc2 compiled with SMP and ACPI support in order
to 
enable Hyper Threading (with and without preempt, with or without SMT 
support). The compiler I used is GCC version 3.4.2 (from Fedora Core 3).

Result: almost all the time the system hangs but still can 
execute SysRq commands.

How I tested

On a console I was running a script that initializes a htb tree 
on an interface (dummy0) in an endless loop:
while /bin/true; do . htbdown.dummy0.sh; done
...and on another console I run tc -s also in an endless loop:
while /bin/true; do tc -s class sh dev dummy0; done

After a while (sometimes after 2 runs of the htbdown.dummy0.sh 
script, sometimes after 20) the system hangs. It still responds to
SysRq 
commands and I was able to see the two tc processes running. Sometimes
I 
still have ping replies from it and one time, just one time in 2 days I 
still was able to log in remotely.
There are no printk messages, or no other warnings or errors 
printed in the system log or kernel log. It just hangs and it seems
like 
something is wasting all the CPU power: when I still was able to log in 
I noticed that one of the two virtual CPUs was 100% with system 
interrupts and the other was 100% system. I wasn't able to strace any
of 
the two running tc's.
What I was able to paste with the mouse in my console, to catch 
in a typescript and also the script that initializes the htb tree on 
dummy0 can be found at ftp://blackblue.iasi.rdsnet.ro/pub/various/k/ .
The test host is a 3.0GHz Intel Prescott and I first noticed
the 
bug on a system with a 2.8GHz Intel Northwood, both having motherboards 
with Intel chipset (865GBF). I am not able to test it in other SMP 
environments (Intel Xeon or Itanium, AMD Opteron, Dual P3, etc), so I'm 
not able to tell if it's an ACPI bug, a SMP bug or a Packet Scheduler 
bug.



>From April 12th:


On Fri, 8 Apr 2005, Tarhon-Onu Victor wrote:

>   I am not subscribed to this list so please CC me if you post a
reply, 
> if you need additional info or if you suggest a patch (in which I
would be 
> very interested).
>
[snip]
> (Intel Xeon or Itanium, AMD Opteron, Dual P3, etc), so I'm not able to
tell 
> if it's an ACPI bug, a SMP bug or a Packet Scheduler bug.

It seems like this bug is a packed scheduler one and it was 
introduced in 2.6.10-rc2. In the summary of changes from 2.6.10-rc1 to 
2.6.10-rc2 there are a lot of changes announced for the packet 
scheduler.
I removed all the changes of the packet scheduler files from
the 
incremental patch 2.6.10-rc1 to 2.6.10-rc2, I applied it to 2.6.10-rc1 
and the new 2.6.10-rc2-whithout-sched-changes does not hang.
So the problem should be looked in that changes to the pkt
sched 
API, the patch containing only those changes is at 
ftp://blackblue.iasi.rdsnet.ro/pub/various/k/patch-2.6.10-sched_changes-from_rc1-to-rc2.gz



On Fri, 2005-04-15 at 17:44 -0400, jamal wrote:
> Didnt see the beginings of this thread - please post on netdev instead
> of lkml network related questions.
> 
> The real cause seems to be an ARP issue from what i saw in the oops
> posted a while back:
> --
> [4294692.342000] Call Trace:
> [4294692.342000]  [] show_stack+0xa6/0xe0
> [4294692.342000]  [] show_registers+0x15b/0x1f0
> [4294692.342000]  [] die+0x141/0x2d0
> [4294692.342000]  [] do_page_fault+0x22e/0x6a6
> [4294692.342000]  [] error_code+0x4f/0x54
> [4294692.342000]  [] qdisc_restart+0xba/0x730
> [4294692.342000]  [] dev_queue_xmit+0x13e/0x640
> [4294692.342000]  [] arp_solicit+0xfc/0x210
> [4294692.342000]  [] neigh_timer_handler+0x13e/0x320
> [4294692.342000]  [] run_timer_softirq+0x130/0x490
> [4294692.342000]  [] __do_softirq+0x42/0xa0
> [4294692.342000]  [] do_softirq+0x51/0x60
> -
> 
> Is this the same issue?
> Can you describe how you create this issue; 

Re: Leaks in mmap address space: 2.6.11.4

[Wolfgang Wander]

Here is another program that illustrates the problem which this time
in C and without using glibc allocation schemes.

--
/* run in 32 bit mode on 64Bit kernel, >4GB of RAM is helpful */

#include 
#include 
#include 
#include 

#define bsz 600 /* number of mmaps to keep */
#define large 950   /* some odd large number */
#define success 100 /* number of iterations before we believe we are ok*/

/* program fails here on 2.6.11.4 kernel after 52K 
iterations 
   with a fragmented /proc/self/mmap, 2.4 kernels 
behave fine */
void
aLLocator()
{

  char* bvec[bsz];
  unsigned int i;
  memset( bvec,0,sizeof(bvec));
 
  for(  i = 0; i < success ; ++i ) {
unsigned oidx;
unsigned kidx;
int len;
kidx = i % bsz;
oidx = (i+bsz/10) % bsz;
len = (oidx & 7) ? ((oidx&7)* 1048576) : large;
if( bvec[oidx] ) { munmap( bvec[oidx], len ); bvec[oidx] = 0; }
len = (kidx & 7) ? ((kidx&7)* 1048576) : large;
bvec[kidx] = (char*)(mmap(0, len, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0));
if( bvec[kidx] == (char*)(-1) ) {
  printf("Failed after %d rounds\n", i);
  break;
}
  }
}

int main() {
  FILE *f;
  int c;

  aLLocator();

  f = fopen( "/proc/self/maps", "r" );
  while( (c = fgetc(f)) != EOF )
putchar(c);
  fclose(f);
  
  return 0;
}
--

Wolfgang Wander writes:
 > Hi,
 > 
 >   we are running some pretty large applications in 32bit mode on 64bit
 >   AMD kernels (8GB Ram, Dual AMD64 CPUs, SMP).  Kernel is 2.6.11.4 or
 >   2.4.21.
 > 
 >   Some of these applications run consistently out of memory but only
 >   on 2.6 machines.  In fact large memory allocations that libc answers
 >   with private mmaps seem to contribute to the problem: 2.4 kernels
 >   are able to combine these mmaps to large chunks whereas 2.6
 >   generates a rather fragmented /proc/self/maps table.
 > 
 >   The following C++ program reproduces the error (compiled statically
 >   on a 32bit machine to get exactly the same executable for 2.4 and
 >   2.6 environments):
-
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] char/tpm: use msleep(), clean-up timers, fix typo

[Nish Aravamudan]

On 4/15/05, Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 15, 2005 at 01:44:55PM -0700, Nish Aravamudan wrote:
> > On 4/15/05, Kylene Hall <[EMAIL PROTECTED]> wrote:
> > > I have tested this patch and agree that using msleep is the right.  Please
> > > apply this patch to the tpm driver.  One hunk might fail b/c the
> > > typo has been fixed already.
> >
> > Would you like me to respin the patch, Greg? Or is the failed hunk ok?
> 
> I'm sorry, but I am not in charge of accepting patches for the tpm
> driver.  Why not go through the listed maintainer for this process, they
> should know how to get it into the mainline kernel tree properly.  If
> not, why would they be listed as the maintainer?  :)

Kylene, there is no entry in MAINTAINERS as of 2.6.12-rc2 for the TPM
driver? Should there be?

I am assuming tpmdd_devel can take care of merging the patch and
pushing to mainline? Please do so.

Thanks,
Nish
-
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] char/tpm: use msleep(), clean-up timers, fix typo

[Nish Aravamudan]

On 4/15/05, Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 15, 2005 at 01:44:55PM -0700, Nish Aravamudan wrote:
> > On 4/15/05, Kylene Hall <[EMAIL PROTECTED]> wrote:
> > > I have tested this patch and agree that using msleep is the right.  Please
> > > apply this patch to the tpm driver.  One hunk might fail b/c the
> > > typo has been fixed already.
> >
> > Would you like me to respin the patch, Greg? Or is the failed hunk ok?
> 
> I'm sorry, but I am not in charge of accepting patches for the tpm
> driver.  Why not go through the listed maintainer for this process, they
> should know how to get it into the mainline kernel tree properly.  If
> not, why would they be listed as the maintainer?  :)

Sorry about that Greg, I was just mixed-up since you had pushed the
original patch in; my fault. Will remove you from my other reply.

Thanks,
Nish
-
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: ACPI/HT or Packet Scheduler BUG?

[jamal]

Didnt see the beginings of this thread - please post on netdev instead
of lkml network related questions.

The real cause seems to be an ARP issue from what i saw in the oops
posted a while back:
--
[4294692.342000] Call Trace:
[4294692.342000]  [] show_stack+0xa6/0xe0
[4294692.342000]  [] show_registers+0x15b/0x1f0
[4294692.342000]  [] die+0x141/0x2d0
[4294692.342000]  [] do_page_fault+0x22e/0x6a6
[4294692.342000]  [] error_code+0x4f/0x54
[4294692.342000]  [] qdisc_restart+0xba/0x730
[4294692.342000]  [] dev_queue_xmit+0x13e/0x640
[4294692.342000]  [] arp_solicit+0xfc/0x210
[4294692.342000]  [] neigh_timer_handler+0x13e/0x320
[4294692.342000]  [] run_timer_softirq+0x130/0x490
[4294692.342000]  [] __do_softirq+0x42/0xa0
[4294692.342000]  [] do_softirq+0x51/0x60
-

Is this the same issue?
Can you describe how you create this issue; kernel version etc.

cheers,
jamal

On Fri, 2005-15-04 at 17:37 -0400, Steven Rostedt wrote:
> On Thu, 2005-04-14 at 18:46 +0300, Tarhon-Onu Victor wrote:
> > On Tue, 12 Apr 2005, Tarhon-Onu Victor wrote:
> > 
> > >   So the problem should be looked in that changes to the pkt sched API, 
> > > the patch containing only those changes is at
> > 
> > The bug is in this portion of code from net/sched/sch_generic.c, 
> > in the qdisc_destroy() function:
> > 
> > ==
> >   list_for_each_entry(cq, , list)
> >list_for_each_entry_safe(q, n, >dev->qdisc_list, list)
> > if (TC_H_MAJ(q->parent) == TC_H_MAJ(cq->handle)) {
> >  if (q->ops->cl_ops == NULL)
> >   list_del_init(>list);
> >  else
> >   list_move_tail(>list, );
> > }
> >   list_for_each_entry_safe(cq, n, , list)
> >list_del_init(>list);
> > ==
> > 
> > ...and it happens when q->ops->cl_ops is NULL and 
> > list_del_init(>list) is executed.
> > 
> > The stuff from include/linux/list.h looks ok, it seems like one 
> > of those two iterations (list_for_each_entry() and 
> > list_for_each_entry_safe()) enters an endless loop when an element is 
> > removed from the list under some circumstances.
> 
> There's a comment above qdisc_destroy that says:
> 
> /* Under dev->queue_lock and BH! */
> 
> I'm not so sure this is the case.  I've included the emails of those
> listed as Authors of sch_generic.c and sch_htb.c, hopefully they are the
> ones who can help (if not, sorry to bother you).  
> 
> The list.h is fine, but if another task goes down this list when it
> list_del_init is done, there's a chance that the reading task can get to
> the deleted item just as it is being deleted, and has pointed itself to
> itself. p->next == p.  This would go into an infinite loop.  
> 
> The reason sysrq works is because this doesn't stop interrupts. But put
> a local_irq_save around that list and run your test, I bet you won't be
> able to do anything, but power off with the big button.
> 
> Hope someone can help. I don't know the queue disciplines well enough to
> make a proper fix.
> 
> -- Steve
> 
> 
> 

-
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: ACPI/HT or Packet Scheduler BUG?

[Steven Rostedt]

On Thu, 2005-04-14 at 18:46 +0300, Tarhon-Onu Victor wrote:
> On Tue, 12 Apr 2005, Tarhon-Onu Victor wrote:
> 
> > So the problem should be looked in that changes to the pkt sched API, 
> > the patch containing only those changes is at
> 
>   The bug is in this portion of code from net/sched/sch_generic.c, 
> in the qdisc_destroy() function:
> 
> ==
>   list_for_each_entry(cq, , list)
>list_for_each_entry_safe(q, n, >dev->qdisc_list, list)
> if (TC_H_MAJ(q->parent) == TC_H_MAJ(cq->handle)) {
>  if (q->ops->cl_ops == NULL)
>   list_del_init(>list);
>  else
>   list_move_tail(>list, );
> }
>   list_for_each_entry_safe(cq, n, , list)
>list_del_init(>list);
> ==
> 
>   ...and it happens when q->ops->cl_ops is NULL and 
> list_del_init(>list) is executed.
> 
>   The stuff from include/linux/list.h looks ok, it seems like one 
> of those two iterations (list_for_each_entry() and 
> list_for_each_entry_safe()) enters an endless loop when an element is 
> removed from the list under some circumstances.

There's a comment above qdisc_destroy that says:

/* Under dev->queue_lock and BH! */

I'm not so sure this is the case.  I've included the emails of those
listed as Authors of sch_generic.c and sch_htb.c, hopefully they are the
ones who can help (if not, sorry to bother you).  

The list.h is fine, but if another task goes down this list when it
list_del_init is done, there's a chance that the reading task can get to
the deleted item just as it is being deleted, and has pointed itself to
itself. p->next == p.  This would go into an infinite loop.  

The reason sysrq works is because this doesn't stop interrupts. But put
a local_irq_save around that list and run your test, I bet you won't be
able to do anything, but power off with the big button.

Hope someone can help. I don't know the queue disciplines well enough to
make a proper fix.

-- Steve


-
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] SELinux: fix deadlock on dcache lock

[Stephen Smalley]

This patch fixes a deadlock on the dcache lock detected during testing
at IBM by moving the logging of the current executable information
from the SELinux avc_audit function to audit_log_exit (via an
audit_log_task_info helper) for processing upon syscall exit.  For
consistency, the patch also removes the logging of other task-related
information from avc_audit, deferring handling to audit_log_exit
instead.  This allows simplification of the avc_audit code, allows the
exe information to be obtained more reliably, always includes the comm
information (useful for scripts), and avoids including bogus task
information for checks performed from irq or softirq.  Please apply.

Signed-off-by:  Stephen Smalley <[EMAIL PROTECTED]>
Signed-off-by:  James Morris <[EMAIL PROTECTED]>

--

 kernel/auditsc.c   |   28 
 security/selinux/avc.c |   34 --
 2 files changed, 28 insertions(+), 34 deletions(-)

= kernel/auditsc.c 1.10 vs edited =
--- 1.10/kernel/auditsc.c   2005-03-17 11:33:20 -05:00
+++ edited/kernel/auditsc.c 2005-04-15 09:22:15 -04:00
@@ -610,6 +610,33 @@
printk(KERN_ERR "audit: freed %d contexts\n", count);
 }
 
+static void audit_log_task_info(struct audit_buffer *ab)
+{
+   char name[sizeof(current->comm)];
+   struct mm_struct *mm = current->mm;
+   struct vm_area_struct *vma;
+
+   get_task_comm(name, current);
+   audit_log_format(ab, " comm=%s", name);
+
+   if (!mm)
+   return;
+
+   down_read(>mmap_sem);
+   vma = mm->mmap;
+   while (vma) {
+   if ((vma->vm_flags & VM_EXECUTABLE) &&
+   vma->vm_file) {
+   audit_log_d_path(ab, "exe=",
+vma->vm_file->f_dentry,
+vma->vm_file->f_vfsmnt);
+   break;
+   }
+   vma = vma->vm_next;
+   }
+   up_read(>mmap_sem);
+}
+
 static void audit_log_exit(struct audit_context *context)
 {
int i;
@@ -639,6 +666,7 @@
  context->gid,
  context->euid, context->suid, context->fsuid,
  context->egid, context->sgid, context->fsgid);
+   audit_log_task_info(ab);
audit_log_end(ab);
while (context->aux) {
struct audit_aux_data *aux;
= security/selinux/avc.c 1.23 vs edited =
--- 1.23/security/selinux/avc.c 2005-03-28 17:21:18 -05:00
+++ edited/security/selinux/avc.c   2005-04-15 09:22:16 -04:00
@@ -532,7 +532,6 @@
u16 tclass, u32 requested,
struct av_decision *avd, int result, struct avc_audit_data *a)
 {
-   struct task_struct *tsk = current;
struct inode *inode = NULL;
u32 denied, audited;
struct audit_buffer *ab;
@@ -556,39 +555,6 @@
audit_log_format(ab, "avc:  %s ", denied ? "denied" : "granted");
avc_dump_av(ab, tclass,audited);
audit_log_format(ab, " for ");
-   if (a && a->tsk)
-   tsk = a->tsk;
-   if (tsk && tsk->pid) {
-   struct mm_struct *mm;
-   struct vm_area_struct *vma;
-   audit_log_format(ab, " pid=%d", tsk->pid);
-   if (tsk == current)
-   mm = current->mm;
-   else
-   mm = get_task_mm(tsk);
-   if (mm) {
-   if (down_read_trylock(>mmap_sem)) {
-   vma = mm->mmap;
-   while (vma) {
-   if ((vma->vm_flags & VM_EXECUTABLE) &&
-   vma->vm_file) {
-   audit_log_d_path(ab, "exe=",
-   vma->vm_file->f_dentry,
-   vma->vm_file->f_vfsmnt);
-   break;
-   }
-   vma = vma->vm_next;
-   }
-   up_read(>mmap_sem);
-   } else {
-   audit_log_format(ab, " comm=%s", tsk->comm);
-   }
-   if (tsk != current)
-   mmput(mm);
-   } else {
-   audit_log_format(ab, " comm=%s", tsk->comm);
-   }
-   }
if (a) {
switch (a->type) {
case AVC_AUDIT_DATA_IPC:


-- 
Stephen Smalley <[EMAIL PROTECTED]>
National Security Agency

-
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] tpm: fix gcc printk warnings

[Kylene Jo Hall]

The patch that was attached to this orginal message looks good to me and
can be applied to the Tpm driver.

Thanks,
Kylie

On Mon, 2005-03-14 at 15:16 -0800, Randy.Dunlap wrote:
> Andrew Morton wrote:
> > "Randy.Dunlap" <[EMAIL PROTECTED]> wrote:
> > 
> > Nope.  Please use %Z for size_t args.
> 
> Yeps.  Here it is.
> 

-
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] char/tpm: use msleep(), clean-up timers, fix typo

[Greg KH]

On Fri, Apr 15, 2005 at 01:44:55PM -0700, Nish Aravamudan wrote:
> On 4/15/05, Kylene Hall <[EMAIL PROTECTED]> wrote:
> > I have tested this patch and agree that using msleep is the right.  Please
> > apply this patch to the tpm driver.  One hunk might fail b/c the
> > typo has been fixed already.
> 
> Would you like me to respin the patch, Greg? Or is the failed hunk ok?

I'm sorry, but I am not in charge of accepting patches for the tpm
driver.  Why not go through the listed maintainer for this process, they
should know how to get it into the mainline kernel tree properly.  If
not, why would they be listed as the maintainer?  :)

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: intercepting syscalls

[Daniel Souza]

Yes, this can be done by overwriting libc calls or patching httpd
process at runtime to overwrite open() at libc address map, and get
open() calls trapped just for apache. BUT, let's figure a scenario: GD
has a buffer overflow bug that when it tries to get the size of a
existing malformed image (that can be uploaded by any user at web
app), it segfaults. It's a exploitable bug, and a attacker sucessfully
exploit it, binding a shell. Shellcodes don't make use of libc calls.
Instead, they use direct asm calls to trigger system calls that they
need to use (execve(), dup() for example of a connect-back shellcode).
Your method will not trigger that exploitation, but a kernel-level
wrapper will see that "/bin/sh" got executed by httpd, what is...
unacceptable. Yes, I can patch the whole libc and expect when the
attacker issue any "ls -la" that WILL be triggered by your patched
libc wrapper. But I dont like userland patches like that (in fact, I
prefer to avoid libc hackings like that). Imagine a libc wrapper that
inside a read(), it makes a syslog() or anything to log... a simple
strace will catch it up.

Returning to the topic context... the kernel sees everything. Libc
just accept that and live with, as a wife =) I prefer to be the
husband one...



-- 
# (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil
-
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: intercepting syscalls

[Steven Rostedt]

On Fri, 2005-04-15 at 15:59 -0400, Igor Shmukler wrote:
> Daniel,
> Thank you very much. I will check this out.
> A thanks to everyone else who contributed. I would still love to know
> why this is a bad idea.

Hi Igor,

Below, I think Daniel is either showing you that it can be abused in a
root kit (like SuckIT) or how SuckIT does it to help you out (or both).
Anyway, another reason is that Linus believes that modules should mainly
be for things like drivers. Stuff that you don't need because you don't
have the device. But anything else, it should be part of the kernel that
may or may not be turned off. 

The biggest part of this is that there are people out there that would
try to get around the GPL of the kernel by adding their proprietary
modules and not release the code.  By keeping things like system calls
away from modules, it makes it harder to modify the kernel via a module.
If you are adding a functionality to the kernel, it is considered better
to try to submit it and have it become part of the kernel.

Maybe it would be easier to create your own patched libc? Argh! probably
not!

-- Steve



> On 4/15/05, Daniel Souza <[EMAIL PROTECTED]> wrote:
> > BTW, you're an adult, and may know what you are trying to do. listen
> > to the LKML guys, it's not a good idea.
> > 
> > /* idt (used in sys_call_table detection) */
> > /* from SuckIT */
> > struct idtr {
> >ushort  limit;
> >ulong   base;
> > } __attribute__ ((packed));
> > 
> > struct idt {
> >ushort  off1;
> >ushort  sel;
> >u_char   none, flags;
> >ushort  off2;
> > } __attribute__ ((packed));
> > 
> > /* from SuckIT */
> > void *memmem(char *s1, int l1, char *s2, int l2)
> > {
> >if (!l2)
> >return s1;
> >while (l1 >= l2)
> >{
> >l1--;
> >if (!memcmp(s1,s2,l2))
> >return s1;
> >s1++;
> >}
> >return(NULL);
> > }
> > 
> > /* from SuckIT */
> > ulong   get_sct(ulong ep, ulong *pos)
> > {
> >#define SCLEN 512
> >char code[SCLEN];
> >char *p;
> >ulong r;
> > 
> >memcpy(, (void *)ep, SCLEN);
> >p = (char *) memmem(code, SCLEN, "\xff\x14\x85", 3);
> >if (!p)
> >return 0;
> >pos[0] = ep + ((p + 3) - code);
> >r =  *(ulong *) (p + 3);
> >p = (char *) memmem(p+3, SCLEN - (p-code) - 3, "\xff\x14\x85", 3);
> >if (!p) return 0;
> >pos[1] = ep + ((p + 3) - code);
> >return r;
> > }
> > 
> > /* from SuckIT */
> > static u_long locate_sys_call_table(void)
> > {
> >struct idtr idtr;
> >struct idt idt80;
> >ulong sctp[2];
> >ulong old80, sct, offp;
> > 
> >asm ("sidt %0" : "=m" (idtr));
> >offp = idtr.base + (0x80 * sizeof(idt80));
> >memcpy(, (void *)offp, sizeof(idt80));
> >old80 = idt80.off1 | (idt80.off2 << 16);
> >sct = get_sct(old80, sctp);
> >return(sct);
> > }
> > 
> > to use...
> > 
> >u_long sct_addr;
> > 
> >sct_addr = locate_sys_call_table();
> >if ( !sct_addr )
> >{
> >OSARO_DOLOG("cannot find sys_call_table. aborting.");
> >return(EACCES);
> >}
> >sys_call_table = (void *)sct_addr;
> > 
> > --
> > # (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil
> >
> -
> 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/
-- 
Steven Rostedt
Senior Engineer
Kihon Technologies

-
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: Adaptec 2010S i2o + x86_64 doesn't work

[Alan Cox]

On Gwe, 2005-04-15 at 19:16, Arjan van de Ven wrote:
> are you sure the HW isn't 31 bit by accident ? 

It is reported working with mem=3840 so its not 31bit, and I2O requires
32bit DMA, with option for 64bit.

Alan

-
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] char/tpm: use msleep(), clean-up timers, fix typo

[Nish Aravamudan]

On 4/15/05, Kylene Hall <[EMAIL PROTECTED]> wrote:
> I have tested this patch and agree that using msleep is the right.  Please
> apply this patch to the tpm driver.  One hunk might fail b/c the
> typo has been fixed already.

Would you like me to respin the patch, Greg? Or is the failed hunk ok?

Thanks,
Nish
-
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: intercepting syscalls

[Richard B. Johnson]

On Fri, 15 Apr 2005, Daniel Souza wrote:
On 4/15/05, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Fri, 2005-04-15 at 13:10 -0700, Daniel Souza wrote:
You're welcome, Igor. I needed to intercept syscalls in a little
project that I were implementing, to keep track of filesystem changes,
I assume you weren't about tracking file content changing... since you
can't do that with syscall hijacking.. (that is a common misconception
by people who came from a MS Windows environment and did things like
anti virus tools there this way)
No, I was tracking file creations/modifications/attemps of
access/directory creations|modifications/file movings/program
executions with some filter exceptions (avoid logging library loads by
ldd to preserve disk space).
It was a little module that logs file changes and program executions
to syslog (showing owner,pid,ppid,process name, return of
operation,etc), that, used with remote syslog logging to a 'strictly
secure' machine (just receive logs), keep security logs of everything
(like, it was possible to see apache running commands as "ls -la /" or
"ps aux", that, in fact, were signs of intrusion of try of intrusion,
because it's not a usual behavior of httpd. Maybe anyone exploited a
php page to execute arbitrary scripts...)
--
The requirements can be easily met in user-mode, probably
a lot easier than anything in the kernel.
LD_PRELOAD some custom 'C' runtime library functions, grab open()
read(), write(), etc. Write information to a pipe. Secure reader
daemon logs whatever it wants, based upon configuration settings.
After writing information to the pipe, executes the appropriate
syscall.
Done, no hacks, everything working in the correct context.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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: intercepting syscalls

[Petr Baudis]

Dear diary, on Fri, Apr 15, 2005 at 08:04:37PM CEST, I got a letter
where Igor Shmukler <[EMAIL PROTECTED]> told me that...
> We HAVE to intercept system calls.

Why? What do you need to do?

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
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: intercepting syscalls

[Chris Wright]

* Daniel Souza ([EMAIL PROTECTED]) wrote:
> No, I was tracking file creations/modifications/attemps of
> access/directory creations|modifications/file movings/program
> executions with some filter exceptions (avoid logging library loads by
> ldd to preserve disk space).
> 
> It was a little module that logs file changes and program executions
> to syslog (showing owner,pid,ppid,process name, return of
> operation,etc), that, used with remote syslog logging to a 'strictly
> secure' machine (just receive logs), keep security logs of everything
> (like, it was possible to see apache running commands as "ls -la /" or
> "ps aux", that, in fact, were signs of intrusion of try of intrusion,
> because it's not a usual behavior of httpd. Maybe anyone exploited a
> php page to execute arbitrary scripts...)

This is what the audit subsystem is working towards.  Full tracking
isn't quite there yet, but getting closer.

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
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] char/tpm: use msleep(), clean-up timers, fix typo

[Kylene Hall]

I have tested this patch and agree that using msleep is the right.  Please 
apply this patch to the tpm driver.  One hunk might fail b/c the 
typo has been fixed already.

Thanks,
Kylie Hall

On Fri, 11 Mar 2005, Nishanth Aravamudan wrote:

> Not sure what happened to the original mail, but I'm not seeing it
> yet...
> 
> On Wed, Mar 09, 2005 at 04:42:01PM -0800, Greg KH wrote:
> > ChangeSet 1.2035, 2005/03/09 10:12:19-08:00, [EMAIL PROTECTED]
> > 
> > [PATCH] Add TPM hardware enablement driver
> > 
> > This patch is a device driver to enable new hardware.  The new hardware is
> > the TPM chip as described by specifications at
> > .  The TPM chip will enable you to
> > use hardware to securely store and protect your keys and personal data.
> > To use the chip according to the specification, you will need the Trusted
> > Software Stack (TSS) of which an implementation for Linux is available at:
> > .
> 
> Here is a patch that removes all callers of schedule_timeout() as I
> previously mentioned:
> 
> Description: The TPM driver unnecessarily uses timers when it simply
> needs to maintain a maximum delay via time_before(). msleep() is used
> instead of schedule_timeout() to guarantee the task delays as expected.
> While compile-testing, I found a typo in the driver, using tpm_chp
> instead of tpm_chip. Remove the now unused timer callback function and
> change TPM_TIMEOUT's units to milliseconds. Patch is compile-tested.
> 
> Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
> 
> diff -urpN 2.6.11-v/drivers/char/tpm/tpm.c 2.6.11/drivers/char/tpm/tpm.c
> --- 2.6.11-v/drivers/char/tpm/tpm.c   2005-03-10 10:50:00.0 -0800
> +++ 2.6.11/drivers/char/tpm/tpm.c 2005-03-10 11:00:50.0 -0800
> @@ -19,7 +19,7 @@
>   * 
>   * Note, the TPM chip is not interrupt driven (only polling)
>   * and can have very long timeouts (minutes!). Hence the unusual
> - * calls to schedule_timeout.
> + * calls to msleep.
>   *
>   */
>  
> @@ -52,14 +52,6 @@ static void user_reader_timeout(unsigned
>   up(>buffer_mutex);
>  }
>  
> -void tpm_time_expired(unsigned long ptr)
> -{
> - int *exp = (int *) ptr;
> - *exp = 1;
> -}
> -
> -EXPORT_SYMBOL_GPL(tpm_time_expired);
> -
>  /*
>   * Initialize the LPC bus and enable the TPM ports
>   */
> @@ -135,6 +127,7 @@ static ssize_t tpm_transmit(struct tpm_c
>   ssize_t len;
>   u32 count;
>   __be32 *native_size;
> + unsigned long stop;
>  
>   native_size = (__force __be32 *) (buf + 2);
>   count = be32_to_cpu(*native_size);
> @@ -155,28 +148,16 @@ static ssize_t tpm_transmit(struct tpm_c
>   return len;
>   }
>  
> - down(>timer_manipulation_mutex);
> - chip->time_expired = 0;
> - init_timer(>device_timer);
> - chip->device_timer.function = tpm_time_expired;
> - chip->device_timer.expires = jiffies + 2 * 60 * HZ;
> - chip->device_timer.data = (unsigned long) >time_expired;
> - add_timer(>device_timer);
> - up(>timer_manipulation_mutex);
> -
> + stop = jiffies + 2 * 60 * HZ;
>   do {
>   u8 status = inb(chip->vendor->base + 1);
>   if ((status & chip->vendor->req_complete_mask) ==
>   chip->vendor->req_complete_val) {
> - down(>timer_manipulation_mutex);
> - del_singleshot_timer_sync(>device_timer);
> - up(>timer_manipulation_mutex);
>   goto out_recv;
>   }
> - set_current_state(TASK_UNINTERRUPTIBLE);
> - schedule_timeout(TPM_TIMEOUT);
> + msleep(TPM_TIMEOUT); /* CHECK */
>   rmb();
> - } while (!chip->time_expired);
> + } while (time_before(jiffies, stop));
>  
>  
>   chip->vendor->cancel(chip);
> @@ -219,7 +200,7 @@ static ssize_t show_pcrs(struct device *
>   int i, j, index, num_pcrs;
>   char *str = buf;
>  
> - struct tpm_chp *chip =
> + struct tpm_chip *chip =
>   pci_get_drvdata(container_of(dev, struct pci_dev, dev));
>   if (chip == NULL)
>   return -ENODEV;
> @@ -450,10 +431,8 @@ ssize_t tpm_write(struct file * file, co
>  
>   /* cannot perform a write until the read has cleared
>  either via tpm_read or a user_read_timer timeout */
> - while (atomic_read(>data_pending) != 0) {
> - set_current_state(TASK_UNINTERRUPTIBLE);
> - schedule_timeout(TPM_TIMEOUT);
> - }
> + while (atomic_read(>data_pending) != 0)
> + msleep(TPM_TIMEOUT);
>  
>   down(>buffer_mutex);
>  
> diff -urpN 2.6.11-v/drivers/char/tpm/tpm.h 2.6.11/drivers/char/tpm/tpm.h
> --- 2.6.11-v/drivers/char/tpm/tpm.h   2005-03-10 10:50:00.0 -0800
> +++ 2.6.11/drivers/char/tpm/tpm.h 2005-03-10 10:58:12.0 -0800
> @@ -24,7 +24,7 @@
>  #include 
>  #include 
>  
> -#define TPM_TIMEOUT msecs_to_jiffies(5)
> +#define 

Re: Serverworks LE and MTRR write-combining question

[Lee Revell]

On Thu, 2005-04-14 at 19:34 -0400, Lee Revell wrote:
> Here's the patch from that thread against 2.6.12-rc2.  It also fixes an
> unrelated typo in nearby code.  Obviously untested, as I don't have the
> hardware ;-)
> 
> Summary: Enable write combining for server works LE rev > 6 per
> http://www.ussg.iu.edu/hypermail/linux/kernel/0104.3/1007.html

OK, Mike has tested my patch with a rev 6 chipset and report that write
combining works fine.  Andrew, please apply.

Lee



-
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: intercepting syscalls

[Daniel Souza]

On 4/15/05, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-04-15 at 13:10 -0700, Daniel Souza wrote:
> > You're welcome, Igor. I needed to intercept syscalls in a little
> > project that I were implementing, to keep track of filesystem changes,
> 
> I assume you weren't about tracking file content changing... since you
> can't do that with syscall hijacking.. (that is a common misconception
> by people who came from a MS Windows environment and did things like
> anti virus tools there this way)

No, I was tracking file creations/modifications/attemps of
access/directory creations|modifications/file movings/program
executions with some filter exceptions (avoid logging library loads by
ldd to preserve disk space).

It was a little module that logs file changes and program executions
to syslog (showing owner,pid,ppid,process name, return of
operation,etc), that, used with remote syslog logging to a 'strictly
secure' machine (just receive logs), keep security logs of everything
(like, it was possible to see apache running commands as "ls -la /" or
"ps aux", that, in fact, were signs of intrusion of try of intrusion,
because it's not a usual behavior of httpd. Maybe anyone exploited a
php page to execute arbitrary scripts...)

-- 
# (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil
-
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: intercepting syscalls

[Arjan van de Ven]

On Fri, 2005-04-15 at 13:10 -0700, Daniel Souza wrote:
> You're welcome, Igor. I needed to intercept syscalls in a little
> project that I were implementing, to keep track of filesystem changes,

I assume you weren't about tracking file content changing... since you
can't do that with syscall hijacking.. (that is a common misconception
by people who came from a MS Windows environment and did things like
anti virus tools there this way)



-
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: intercepting syscalls

[Daniel Souza]

You're welcome, Igor. I needed to intercept syscalls in a little
project that I were implementing, to keep track of filesystem changes,
and others. I use that way, but I know that it's a ugly hack that can
work only under x86. Overwrite syscalls can slow down the whole
system, and a improper wrapper can freeze the system and behave in a
unexpected way (imagine a non-freed memory allocation in a sys_read
wrapper...), and others. I never planned to use it at production.

If you're trying to do something to be public and widely used, I
believe that a better approach is to create a layer to be used in
syscalls operations, or something like that (stills ugly, but now it's
a "good-programming-practice" thing).

For example, from a kernel to other, the way that sys_write works
internally may change, and your code can mess with the whole thing.
Trap system calls are not a portable and clean way to reach your
goals. In fact, there's not a reliable way yet. (that I know)

I agree that a mechanism to wrap system calls can be very useful.

-- 
# (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil
-
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/

[ANNOUNCE] Kernel Mentors Project

[Matt Mackall]

Perhaps the hardest part of becoming a kernel developer is submitting
your first major feature. There are technical and social hurdles to
overcome and the process can be daunting to someone who is new to the
community.

Thus, I'm proposing an informal project to get experienced developers
to mentor new developers and coach them on the best ways to get their
code ready for submission.

Developers will submit a description of their project and its current
state as well as pointer to the code to the kernel-mentors mailing
list. Mentors will pick for themselves which projects and developers
they'd like to work with and offer their assistance. 

The mentor will help the developer get their code accepted by:
- reviewing the code and suggesting how to improve it further
- acquainting the developer with best practices for code submission
- letting the developer know what to expect in the submission process

For their part, new developers will be expected to use the feedback
they're given productively and eventually get their code merged!

The project list is at [EMAIL PROTECTED] with a web interface at:

http://selenic.com/mailman/listinfo/kernel-mentors

If you're interested in helping out, come join us.

-- 
Mathematics is the supreme nostalgia of our time.
-
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: intercepting syscalls

[Randy.Dunlap]

On Fri, 15 Apr 2005 15:41:34 -0400 Igor Shmukler wrote:

| Hello,
| 
| Thanks to everyone for replying.
| It is surprising to me that linux-kernel people decided to disallow
| interception of system calls.
| I don't really see any upside to this.

Upside ?

| I guess if there is no clean way to do this, we will have to resort to
| quick and dirty.
| 
| Can anyone point to a discussion that yielded this decision. Perhaps,
| I need to educate myself. I stumbled upon comments that this can lead
| to mess, but pretty much anything in LKM can cause problems. I don't
| think that hiding commonly used convenient interfaces just because
| they can be abused is a valid reason, hence I would love to know what
| is the real reason.

What "commonly used convenient interfaces"?


I don't claim to remember all of the reasons.  A couple of them are:

a.  it's racy
b.  it's not architecture-independent


| Thank you,
| 
| Igor
| 
| 
| On 4/15/05, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
| > On Fri, 2005-04-15 at 14:04 -0400, Igor Shmukler wrote:
| > > Hello,
| > > We are working on a LKM for the 2.6 kernel.
| > > We HAVE to intercept system calls. I understand this could be
| > > something developers are no encouraged to do these days, but we need
| > > this.
| > 
| > your module is GPL licensed right ? (You're depending on deep internals
| > after all)
| > 
| > Why do you *have* to intercept system calls... can't you instead use the
| > audit infrastructure to get that information ?
| > 
| > What is the URL of your current code so that we can provide reasonable
| > recommendations ?
| -


---
~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: intercepting syscalls

[Igor Shmukler]

Daniel,
Thank you very much. I will check this out.
A thanks to everyone else who contributed. I would still love to know
why this is a bad idea.
Igor.

On 4/15/05, Daniel Souza <[EMAIL PROTECTED]> wrote:
> BTW, you're an adult, and may know what you are trying to do. listen
> to the LKML guys, it's not a good idea.
> 
> /* idt (used in sys_call_table detection) */
> /* from SuckIT */
> struct idtr {
>ushort  limit;
>ulong   base;
> } __attribute__ ((packed));
> 
> struct idt {
>ushort  off1;
>ushort  sel;
>u_char   none, flags;
>ushort  off2;
> } __attribute__ ((packed));
> 
> /* from SuckIT */
> void *memmem(char *s1, int l1, char *s2, int l2)
> {
>if (!l2)
>return s1;
>while (l1 >= l2)
>{
>l1--;
>if (!memcmp(s1,s2,l2))
>return s1;
>s1++;
>}
>return(NULL);
> }
> 
> /* from SuckIT */
> ulong   get_sct(ulong ep, ulong *pos)
> {
>#define SCLEN 512
>char code[SCLEN];
>char *p;
>ulong r;
> 
>memcpy(, (void *)ep, SCLEN);
>p = (char *) memmem(code, SCLEN, "\xff\x14\x85", 3);
>if (!p)
>return 0;
>pos[0] = ep + ((p + 3) - code);
>r =  *(ulong *) (p + 3);
>p = (char *) memmem(p+3, SCLEN - (p-code) - 3, "\xff\x14\x85", 3);
>if (!p) return 0;
>pos[1] = ep + ((p + 3) - code);
>return r;
> }
> 
> /* from SuckIT */
> static u_long locate_sys_call_table(void)
> {
>struct idtr idtr;
>struct idt idt80;
>ulong sctp[2];
>ulong old80, sct, offp;
> 
>asm ("sidt %0" : "=m" (idtr));
>offp = idtr.base + (0x80 * sizeof(idt80));
>memcpy(, (void *)offp, sizeof(idt80));
>old80 = idt80.off1 | (idt80.off2 << 16);
>sct = get_sct(old80, sctp);
>return(sct);
> }
> 
> to use...
> 
>u_long sct_addr;
> 
>sct_addr = locate_sys_call_table();
>if ( !sct_addr )
>{
>OSARO_DOLOG("cannot find sys_call_table. aborting.");
>return(EACCES);
>}
>sys_call_table = (void *)sct_addr;
> 
> --
> # (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil
>
-
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: intercepting syscalls

[Daniel Souza]

BTW, you're an adult, and may know what you are trying to do. listen
to the LKML guys, it's not a good idea.

/* idt (used in sys_call_table detection) */
/* from SuckIT */
struct idtr {
   ushort  limit;
   ulong   base;
} __attribute__ ((packed));

struct idt {
   ushort  off1;
   ushort  sel;
   u_char   none, flags;
   ushort  off2;
} __attribute__ ((packed));

/* from SuckIT */
void *memmem(char *s1, int l1, char *s2, int l2)
{
   if (!l2)
   return s1;
   while (l1 >= l2)
   {
   l1--;
   if (!memcmp(s1,s2,l2))
   return s1;
   s1++;
   }
   return(NULL);
}

/* from SuckIT */
ulong   get_sct(ulong ep, ulong *pos)
{
   #define SCLEN 512
   char code[SCLEN];
   char *p;
   ulong r;

   memcpy(, (void *)ep, SCLEN);
   p = (char *) memmem(code, SCLEN, "\xff\x14\x85", 3);
   if (!p)
   return 0;
   pos[0] = ep + ((p + 3) - code);
   r =  *(ulong *) (p + 3);
   p = (char *) memmem(p+3, SCLEN - (p-code) - 3, "\xff\x14\x85", 3);
   if (!p) return 0;
   pos[1] = ep + ((p + 3) - code);
   return r;
}

/* from SuckIT */
static u_long locate_sys_call_table(void)
{
   struct idtr idtr;
   struct idt idt80;
   ulong sctp[2];
   ulong old80, sct, offp;

   asm ("sidt %0" : "=m" (idtr));
   offp = idtr.base + (0x80 * sizeof(idt80));
   memcpy(, (void *)offp, sizeof(idt80));
   old80 = idt80.off1 | (idt80.off2 << 16);
   sct = get_sct(old80, sctp);
   return(sct);
}

to use...

   u_long sct_addr;

   sct_addr = locate_sys_call_table();
   if ( !sct_addr )
   {
   OSARO_DOLOG("cannot find sys_call_table. aborting.");
   return(EACCES);
   }
   sys_call_table = (void *)sct_addr;


-- 
# (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil
-
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: intercepting syscalls

[Igor Shmukler]

Hello,

Thanks to everyone for replying.
It is surprising to me that linux-kernel people decided to disallow
interception of system calls.
I don't really see any upside to this.
I guess if there is no clean way to do this, we will have to resort to
quick and dirty.

Can anyone point to a discussion that yielded this decision. Perhaps,
I need to educate myself. I stumbled upon comments that this can lead
to mess, but pretty much anything in LKM can cause problems. I don't
think that hiding commonly used convenient interfaces just because
they can be abused is a valid reason, hence I would love to know what
is the real reason.

Thank you,

Igor


On 4/15/05, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-04-15 at 14:04 -0400, Igor Shmukler wrote:
> > Hello,
> > We are working on a LKM for the 2.6 kernel.
> > We HAVE to intercept system calls. I understand this could be
> > something developers are no encouraged to do these days, but we need
> > this.
> 
> your module is GPL licensed right ? (You're depending on deep internals
> after all)
> 
> Why do you *have* to intercept system calls... can't you instead use the
> audit infrastructure to get that information ?
> 
> What is the URL of your current code so that we can provide reasonable
> recommendations ?
-
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 Rootkits

[Daniel Souza]

On 4/15/05, Lee Revell <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-04-15 at 11:40 -0700, Daniel Souza wrote:
> > A way to "protect" system calls is, after boot a trusted kernel image,
> > take a MD5 of the syscalls functions implementations (the opcodes that
> > are part of sys_read for example) and store it in a secure place.
>
> That's the problem, once the kernel is compromised there's no such thing
> as a secure place.  Solving this problem requires things like "trusted
> computing" aka hardware support.

yes, hardware support like a floppy disk or a memory key with the
read-only switch turned on after a sucessful boot storing the
hashes... paranoia that works  =) Or just print them, and when in
doubt if your kernel is patched, take another checksum of system calls
and compare to paper... =)

Ok, kidding apart, there's no way to safely protect the system against
memory patching. Maybe, some hardware lock that will keep a "code
segment block" of kernel memory as read-only and a separated segment
for data (as read-write), and after the boot and kernel load, this
lock is activated by a asm call or something like that. This stills
not functional, to not mention impossible. You can implement ways to
make kernel memory patching harder, like avoid any mechanism that can
give direct access to memory like /dev/mem, or /dev/kmem (or patch
them to avoid access to specific areas, because some applications like
Xorg uses direct memory access with that mechanisms to do they duty.)
In fact, avoid any mechanism that can be used by userspace processes
to read/write memory data above 0xc0. This will also not avoid
kernelspace exploitation from programming bugs (like recent (?) VMA
problems, and ancient ptrace bugs that could lead to privilege
elevation). It's just a mechanism to help securing a system.

Or just try grsec =)

-- 
# (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil
-
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 Rootkits

[Daniel Souza]

On 4/15/05, Allison <[EMAIL PROTECTED]> wrote:
> Isn't the kernel code segment marked read-only ? How can the module
> write into the function text in the kernel ? Shouldn't this cause some
> kind of protection fault ?

The kernel code segment is totally unacessible to userspace programs,
and to kernel itself, is marked read-write. A module runs at kernel
level, so, it has +rw to kernel memory. Each process has a task
structure that defines the top of memory that the user process can
access (current->fs). In normal processes, this is 0xbf (the last
adressable memory in user mode). After that, 0xc0, starts the
kernel code. If, by using any method, a user process receives a
(current->fs = KERNEL_DS), it will be able to fully access the kernel
memory. As mentioned, this is unsual.

-- 
# (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil
-
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: [SATA] status reports updated

[Tomasz Chmielewski]

Andre Tomt wrote:
Tomasz Chmielewski wrote:
<
[1] although my drive is blacklisted (Seagate barracuda - 
ST3200822AS), I "unblacklisted" it to get full performance - it's 
under heavy stress for 12th hour, and still no error.

It could be that your drive has newer firmware. Too bad firmware 
upgrades for HD's are hard to come by nowadays.
Is there a way to check what firmware a drive has (either by using some 
software - which would be the best option, or by reading a label on a 
drive)?

If so, we might compile some list to be put in the FAQ?
There was also a post on the list - 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0503.1/0827.html - 
suggesting that upgrading Silicon Image BIOS helped resolving these 
problems.

So it might be newer drive firmware, or newer SATA card BIOS (or both) 
that makes my "sil + seagate" combination usable.

Tomek
--
Startuj z INTERIA.PL! >>> http://link.interia.pl/f186c 

-
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: Fortuna

[Matt Mackall]

On Fri, Apr 15, 2005 at 12:22:25PM -0400, Jean-Luc Cooke wrote:
> And the argument that "random.c doesn't rely on the strength of crypto
> primitives" is kinda lame, though I see where you're coming from.  random.c's
> entropy mixing and output depends on the (endian incorrect) SHA-1
> implementation hard coded in that file to be pre-image resistant.  If that
> fails (and a few other things) then it's broken.

You really ought to look at the _current_ implementation. There is no
SHA1 code in random.c. 

-- 
Mathematics is the supreme nostalgia of our time.
-
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: intercepting syscalls

[Zan Lynx]

On Fri, 2005-04-15 at 14:04 -0400, Igor Shmukler wrote:
> Hello,
> We are working on a LKM for the 2.6 kernel.
> We HAVE to intercept system calls. I understand this could be
> something developers are no encouraged to do these days, but we need
> this.
> Patching kernel to export sys_call_table is not an option. The fast
> and dirty way to do this would be by using System.map, but I would
> rather we find a cleaner approach.

These ideas are hardly a clean approach but might work although I
haven't tried:

Hook into an existing kernel function that is exported to modules that
can be called by a system call, like a /proc or /sys file.  On a
sys_read or sys_write to your /proc file, perform a stack trace back to
the system call, then search and adjust to find the system call table
pointer.

You might also be able to look at the int $80 vector and grub through
the machine code to find it.

Of course, anything like this will probably only work on x86 and need to
be rewritten for each architecture.  Very messy.
-- 
Zan Lynx <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: [SATA] status reports updated

[Andre Tomt]

Tomasz Chmielewski wrote:
<
[1] although my drive is blacklisted (Seagate barracuda - ST3200822AS), 
I "unblacklisted" it to get full performance - it's under heavy stress 
for 12th hour, and still no error.
It could be that your drive has newer firmware. Too bad firmware 
upgrades for HD's are hard to come by nowadays.

--
Cheers,
André Tomt
-
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 Rootkits

[Lee Revell]

On Fri, 2005-04-15 at 11:40 -0700, Daniel Souza wrote:
> A way to "protect" system calls is, after boot a trusted kernel image,
> take a MD5 of the syscalls functions implementations (the opcodes that
> are part of sys_read for example) and store it in a secure place.

That's the problem, once the kernel is compromised there's no such thing
as a secure place.  Solving this problem requires things like "trusted
computing" aka hardware support.

Lee

-
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 Rootkits

[Andre Tomt]

Lennart Sorensen wrote:
Well you could build a monilithic kernel with module loading turned off
entirely, but that doesn't prevent replacing libc which most programs
use to make those system calls.
As pointed out elsewhere, modules is not the only way to load kernel 
code live. Modules is just a cleaner interface for it. Rootkits capable 
of loading their kernel code without involving the module system has 
existed for ages.

Could make the filesystem readonly,
that would prevent writing a module to load into the kernel, and
replacing libc as long as you make it imposible to remount the
filesystem at all.
Don't hold your breath - code can be inserted without involving actual 
files. It just makes things less persistent.

--
Cheers,
André Tomt
-
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 Rootkits

[Allison]

Isn't the kernel code segment marked read-only ? How can the module
write into the function text in the kernel ? Shouldn't this cause some
kind of protection fault ?

thanks,
Allison

Lee Revell wrote:
> On Fri, 2005-04-15 at 18:15 +, Allison wrote:
> > Once these are loaded into the kernel, is there no way the kernel
> > functions can be protected ?
> 
> No.  If the attacker can load arbitrary code into the kernel, game over.
> Think about it.
> 
> Lee
> 
> -
> 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: Re: where is current kernel ?

[Petr Baudis]

Dear diary, on Fri, Apr 15, 2005 at 09:15:00PM CEST, I got a letter
where [EMAIL PROTECTED] told me that...
> From: Petr Baudis <[EMAIL PROTECTED]>
> > Linus stopped merging stuff to his kernel for few days in order to
> > develop his (at least temporary) alternative to BK, called "git".
> > See the mailing list archives for details.
> 
> I have received many GIT commits recently to the old bk-commits mailing list.

And they are clearly marked as "GIT testing". It isn't nothing official
and they can go away randomly - they are mainly for testing git and they
are not guaranteed to stay around. :-)

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
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: where is current kernel ?

[Tom . Duffy]

From: Petr Baudis <[EMAIL PROTECTED]>
> Linus stopped merging stuff to his kernel for few days in order to
> develop his (at least temporary) alternative to BK, called "git".
> See the mailing list archives for details.

I have received many GIT commits recently to the old bk-commits mailing list.

-tduffy
-
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: where is current kernel ?

[Petr Baudis]

Dear diary, on Fri, Apr 15, 2005 at 01:33:45PM CEST, I got a letter
where Maciej Soltysiak <[EMAIL PROTECTED]> told me that...
> Hi,

Hello,

> Is there currently a kernel tree that Linus is working ?
> I mean, now that we have 2.6.12-rc2 not being
> developed with BK, is that code getting fixes and other patches
> as we speak or the development will continue in a while someplace
> else ?

Linus stopped merging stuff to his kernel for few days in order to
develop his (at least temporary) alternative to BK, called "git".
See the mailing list archives for details.

Kind regards,

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
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: [SATA] status reports updated

[Joe Harvell]

http://marc.theaimsgroup.com/?l=linux-ide=111029414823303=2
http://marc.theaimsgroup.com/?l=linux-ide=111054989026053=2
http://marc.theaimsgroup.com/?l=linux-ide=111214149529209=2
http://marc.theaimsgroup.com/?l=linux-ide=111230129320297=2

On Fri, 2005-04-15 at 13:29, Jeff Garzik wrote:
> Joe Harvell wrote:
> > Jeff:
> > 
> > You need to add a comment about the SATAII TX2/TX4 boards indicating
> > users have experienced data corruption with the sata_promise driver and
> > the SATAII TX4 board.
> > 
> > I've posted several emails to linux-ide about this.  Why haven't you
> > responded?
> 
> I've seen reports on the SX4, but not on the SATAII TX4.
> 
> URLs to messages you posted?
> 
>   JEff
> 
-- 
Joe Harvell
[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: [SATA] status reports updated

[Tomasz Chmielewski]

Jeff Garzik wrote:
My Linux SATA software/hardware status reports have just been updated. 
To see where libata (SATA) support stands for a particular piece of 
hardware, or a particular feature, go to

http://linux.yyz.us/sata/
A nice thing in FAQ would be some info on problematic (blacklisted) SATA 
hardware that runs on Linux (vide "poor SATA performance under 2.6.11 
(with < 2.6.11 is OK)?" thread), like Silicon Image 311x controllers + 
some Seagate drives [1].

Tomek
[1] although my drive is blacklisted (Seagate barracuda - ST3200822AS), 
I "unblacklisted" it to get full performance - it's under heavy stress 
for 12th hour, and still no error.

--
Teraz na tapecie mamy najwiekszego z silaczy. 
Sciagnij >> http://link.interia.pl/f1873 <<

-
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 Rootkits

[Daniel Souza]

PS: suckit is not loaded as a kernel module. it uses interrupt gates
to allocate kernel memory and install itself in that memory block,
patching some syscalls and doing other stuffs.

A way to "protect" system calls is, after boot a trusted kernel image,
take a MD5 of the syscalls functions implementations (the opcodes that
are part of sys_read for example) and store it in a secure place. To
verify the integrity of system calls, we can check the current
checksum with the stored ones. Of course, there are other ways to trap
syscalls and hook the system instead of just replace the syscall table
or add JMPs to the start of functions implementation. In that way,
everytime somebody will find another way to trick the system and
bypass this 'protection'.

-- 
# (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil
-
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 Rootkits

[Lennart Sorensen]

On Fri, Apr 15, 2005 at 06:15:37PM +, Allison wrote:
> I got the terminology mixed up. I guess what I really want to know is,
> what are the different types of exploits by which rootkits
> (specifically the ones that modify the kernel) can get installed on
> your system.(other than buffer overflow and somebody stealing the root
> password)
> 
> I know that SucKIT is a rootkit that gets loaded as a kernel module
> and adds new system calls. Some other rootkits change machine
> instructions in several kernel functions.
> 
> Once these are loaded into the kernel, is there no way the kernel
> functions can be protected ?

Well you could build a monilithic kernel with module loading turned off
entirely, but that doesn't prevent replacing libc which most programs
use to make those system calls.  Could make the filesystem readonly,
that would prevent writing a module to load into the kernel, and
replacing libc as long as you make it imposible to remount the
filesystem at all.

Len Sorensen
-
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 Rootkits

[Lee Revell]

On Fri, 2005-04-15 at 18:15 +, Allison wrote:
> Once these are loaded into the kernel, is there no way the kernel
> functions can be protected ?

No.  If the attacker can load arbitrary code into the kernel, game over.
Think about it.

Lee

-
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: Kernel Rootkits

[Petr Baudis]

Dear diary, on Fri, Apr 15, 2005 at 08:15:37PM CEST, I got a letter
where Allison <[EMAIL PROTECTED]> told me that...
> hi,

Hello,

> I got the terminology mixed up. I guess what I really want to know is,
> what are the different types of exploits by which rootkits
> (specifically the ones that modify the kernel) can get installed on
> your system.(other than buffer overflow and somebody stealing the root
> password)
> 
> I know that SucKIT is a rootkit that gets loaded as a kernel module
> and adds new system calls. Some other rootkits change machine
> instructions in several kernel functions.

I think you are still confused. You are mixing two things:

(1) Getting enough access to the machine to load the rootkit

(2) Loading the rootkit smart enough to slip any detectors

The first part basically involves getting root access to the machine.
This is so broad area that it is out of scope of this mail, I guess, but
innumerable types of vulnerabilities exist, ranging from silly bugs in
programs running as root, to in-kernel bugs which let you elevate your
permissions from a regular user to superuser (root).

The second part is very broad too, I think you would be better off by
doing some research on your own - there are plenty of resources on the
net w.r.t. this. (I hope you are asking only in order to defend
yourself! ;-) Basically, rootkits can range from a set of
custom-tailored binaries like ps and ls which will hide the cracker's
files from you, to linux kernel modules which the attacker will load as
a regular kernel module, but which will then usually hide itself and
then again hide the cracker's files from you, only better. These are
already kind of old-fashioned now, though. E.g. the SucKIT rootkit
installs itself to the kernel by bypassing the traditional kernel module
installing mechanism and writing itself directly to the memory,
overriding certain kernel structures and therefore taking control over
it.

> Once these are loaded into the kernel, is there no way the kernel
> functions can be protected ?

once they are in the kernel, they can do anything they want. That's the
point of being in the kernel, after all.

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
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 Rootkits

[Daniel Souza]

In fact, LKM's are not the unique way to make code run in kernel. In
fact, we can install a kernel rootkit even when LKM support is
disabled. For example, by patching the kernel memory, you can modify
the behavior of kernel on-the-fly without restart the machine, just
inserting code in the right memory addresses (generally writing to
/dev/mem or /dev/kmem or using another methods like set a userspace
memory limit to KERNEL_DS and write to addressable kernel memory. You
can also insert code into existing kernel modules (for example, your
NIC driver) to be executed when the kernel shuts up). LKMs have the
advantage of relocation (i.e., the kernel's internal function adresses
are "readressed" to fit the existent function addresses and a call to
printk will point to the start of printk function at kernel memory).
Inject executable code at kernel memory can be done without LKM
support, but also, is not automatically relocated. There are some
tricks to make injected code work fine like use only non-global
variables and allocate needed memory space in the stack, or made a
hard relocation of binary code to be injected before the injection,
etc.

Google for things like "suckit". phrack is also a good start.

-- 
# (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil
-
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: Adaptec 2010S i2o + x86_64 doesn't work

[Markus Lidel]

Hello,
Arjan van de Ven wrote:
On Fri, 2005-04-15 at 20:10 +0200, Markus Lidel wrote:
Alan Cox wrote:
On Gwe, 2005-04-15 at 17:15, Miquel van Smoorenburg wrote:
However, I removed 2 GB from the box as Alan sugggested and now the box
comes up just fine with a 64-bit 2.6.11.6 kernel! I've put the 4GB back,
and booted with the kernel "mem=2048" command line option - that also
works, the i2o_block driver sees the adaptec controller just fine.
And I just booted it with "mem=3840M" and that works too.
So the problem appears to be 4 GB memory in 64 bit mode, on this box.
Or the driver is incorrectly handling 64/32bit DMA limit masks which
would be my first guess here, and would explain why it works on AMD
Athlon64 boxes.
Hmmm, i only set DMA_32BIT_MASK and don't do anything special on 64-bit 
systems... Is there anything else to do for correct DMA mapping?
are you sure the HW isn't 31 bit by accident ? 
I don't know :-( But if the controller could only handle 31-bit DMA, 
wouldn't the 32-bit kernel with 4 GB also have the same problems?


Best regards,
Markus Lidel
--
Markus Lidel (Senior IT Consultant)
Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany
Phone:  +49 82 82/99 51-0
Fax:+49 82 82/99 51-11
E-Mail: [EMAIL PROTECTED]
URL:http://www.shadowconnect.com
-
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: [SATA] status reports updated

[Jeff Garzik]

Joe Harvell wrote:
Jeff:
You need to add a comment about the SATAII TX2/TX4 boards indicating
users have experienced data corruption with the sata_promise driver and
the SATAII TX4 board.
I've posted several emails to linux-ide about this.  Why haven't you
responded?
I've seen reports on the SX4, but not on the SATAII TX4.
URLs to messages you posted?
JEff
-
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.6.12-rc2-mm3

[Juergen Kreileder]

Juergen Kreileder <[EMAIL PROTECTED]> writes:

> Andrew Morton <[EMAIL PROTECTED]> writes:
>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.

I think I finally found the culprit.  Both rc2-mm3 and rc1-mm1 work
fine when I reverse the timer-* patches.

Any idea?  Bug in my ppc64 gcc?


Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
-
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: Fortuna

[Theodore Ts'o]

On Fri, Apr 15, 2005 at 03:38:01PM -, [EMAIL PROTECTED] wrote:
> 
> First of all, people *on* the netowrk path can just *see* the packets.
> Or modify them.  Or whatever.
> The point is to prevent hijacking by people *not* on the path.

Yes, you're correct of course.  Of course, I'll note that people who
*not* on the path have to not only guess the ISN, but they also have
to somehow know that there is a TCP connection between hosts A and B,
and what ports they are using.  Someone not on the path isn't
necessarily going to know this, unless there are publically accessible
SNMP-enabled routers that are overly free with this sort of
information.  (Loose lips sink ships!)

> Further, if I capture ISNs from A and B in the same rekey interval as
> the initiation of the connection I'm trying to hijack, and that
> connection proceeds slowly, then I have the lifetime of the connection
> to solve the crypto problem.

True, although the longer it takes to break the crypto, the greater
the uncertainty of how much data has gone across the connection, which
makes the problem harder in other ways.

> > Furthermore, if you really cared about preventing TCP hijacks, the
> > only real way to do this is to use Real Crypto.  And these days, Cisco
> > boxes support Kerberized telnets and ssh connections, which is the
> > real Right Answer.
> 
> It's just so high-level.  While ipsec is the most general solution,
> setting it up is a PITA.  I've often thought about trying to add a TCP
> option for stream encryption what could provide opportunistic encryption
> for everyone.

But ssh is pretty easy, and even if you completely ignore the host key
issue (to protect you against man-in-the-middle attacks), a simple
diffie-helman type approach is plenty to protect you against the class
of attacks which the randomized ISN buys you.  

- Ted
-
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: intercepting syscalls

[Timur Tabi]

Igor Shmukler wrote:
Hello,
We are working on a LKM for the 2.6 kernel.
We HAVE to intercept system calls. I understand this could be
something developers are no encouraged to do these days, but we need
this.
Too bad.
Patching kernel to export sys_call_table is not an option. The fast
and dirty way to do this would be by using System.map, but I would
rather we find a cleaner approach.
There is none.  And even System.map can be unreliable.  Some distros/kernels only include 
exported symbols in System.map, and sys_call_table is not exported in 2.6.

I did some research on google and I know this issue has been raised
before, but unfortunately I could not find a coherent answer.
Does anyone know of any tutorial or open source code where I could
look at how this is done? I think that IDT should give me the entry
point, but where do I get system call table address?
You don't.
You're just going to have to accept that fact that what you want to do, the way you want 
to do it, is just not going to happen.  Sorry.

Your best bet is to design and implement a clean and safe mechanisming for intercepting 
system calls, and submit that to the kernel.  It will probably get rejected, but it still 
might be worth a shot.

--
Timur Tabi
Staff Software Engineer
[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: [SATA] status reports updated

[Joe Harvell]

Jeff:

You need to add a comment about the SATAII TX2/TX4 boards indicating
users have experienced data corruption with the sata_promise driver and
the SATAII TX4 board.

I've posted several emails to linux-ide about this.  Why haven't you
responded?

Promise TX2/TX4
Summary: No TCQ/NCQ. Full SATA control including hotplug and PM on all. 

[snip]

Update 2005/04/15: Support for the NCQ-capable SATAII TX2/TX4 boards was
recently added. NCQ support is waiting on libata core.


On Fri, 2005-04-15 at 13:09, Jeff Garzik wrote:
> My Linux SATA software/hardware status reports have just been updated. 
> To see where libata (SATA) support stands for a particular piece of 
> hardware, or a particular feature, go to
> 
>   http://linux.yyz.us/sata/
> 
> I've still got several patches from EMC (Brett) and IBM (Albert) to go 
> through, as well as a few scattered ones from random authors.
> 
> I'm still working in BitKeeper for the time being.
> 
>   Jeff
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Joe Harvell
[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: Kernel Rootkits

[Allison]

hi,

I got the terminology mixed up. I guess what I really want to know is,
what are the different types of exploits by which rootkits
(specifically the ones that modify the kernel) can get installed on
your system.(other than buffer overflow and somebody stealing the root
password)

I know that SucKIT is a rootkit that gets loaded as a kernel module
and adds new system calls. Some other rootkits change machine
instructions in several kernel functions.

Once these are loaded into the kernel, is there no way the kernel
functions can be protected ?

thanks,
Allison
-
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: Adaptec 2010S i2o + x86_64 doesn't work

[Arjan van de Ven]

On Fri, 2005-04-15 at 20:10 +0200, Markus Lidel wrote:
> Hello,
> 
> Alan Cox wrote:
> > On Gwe, 2005-04-15 at 17:15, Miquel van Smoorenburg wrote:
> >>However, I removed 2 GB from the box as Alan sugggested and now the box
> >>comes up just fine with a 64-bit 2.6.11.6 kernel! I've put the 4GB back,
> >>and booted with the kernel "mem=2048" command line option - that also
> >>works, the i2o_block driver sees the adaptec controller just fine.
> >>And I just booted it with "mem=3840M" and that works too.
> >>So the problem appears to be 4 GB memory in 64 bit mode, on this box.
> 
> OK, i never tried it with 4 GB so it really could be a problem...
> 
> > Or the driver is incorrectly handling 64/32bit DMA limit masks which
> > would be my first guess here, and would explain why it works on AMD
> > Athlon64 boxes.
> 
> Hmmm, i only set DMA_32BIT_MASK and don't do anything special on 64-bit 
> systems... Is there anything else to do for correct DMA mapping?


are you sure the HW isn't 31 bit by accident ? 

-
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: intercepting syscalls

[Arjan van de Ven]

On Fri, 2005-04-15 at 14:04 -0400, Igor Shmukler wrote:
> Hello,
> We are working on a LKM for the 2.6 kernel.
> We HAVE to intercept system calls. I understand this could be
> something developers are no encouraged to do these days, but we need
> this.

your module is GPL licensed right ? (You're depending on deep internals
after all)

Why do you *have* to intercept system calls... can't you instead use the
audit infrastructure to get that information ?

What is the URL of your current code so that we can provide reasonable
recommendations ?


-
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: intercepting syscalls

[Chris Wright]

* Igor Shmukler ([EMAIL PROTECTED]) wrote:
> We are working on a LKM for the 2.6 kernel.
> We HAVE to intercept system calls. I understand this could be
> something developers are no encouraged to do these days, but we need
> this.

I don't think you'll find much empathy or support here.  This is seriously
discouraged.  It's usually the beginning of many ugly and suspect things
being done in a module.

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
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/