Re: [PATCH] Re: cciss: warning: right shift count >= width of type

[Al Viro]

On Sun, Aug 12, 2007 at 03:21:57AM +0200, Rene Herman wrote:
> @@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
>   } else {
>   c->Request.CDBLen = 16;
>   c->Request.CDB[1]= 0;
> - c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
> - c->Request.CDB[3]= (start_blk >> 48) & 0xff;
> - c->Request.CDB[4]= (start_blk >> 40) & 0xff;
> - c->Request.CDB[5]= (start_blk >> 32) & 0xff;
> - c->Request.CDB[6]= (start_blk >> 24) & 0xff;
> - c->Request.CDB[7]= (start_blk >> 16) & 0xff;
> - c->Request.CDB[8]= (start_blk >>  8) & 0xff;
> + c->Request.CDB[2]= ((u64)start_blk >> 56) & 0xff;   
> //MSB
> + c->Request.CDB[3]= ((u64)start_blk >> 48) & 0xff;
> + c->Request.CDB[4]= ((u64)start_blk >> 40) & 0xff;
> + c->Request.CDB[5]= ((u64)start_blk >> 32) & 0xff;
> + c->Request.CDB[6]= ((u64)start_blk >> 24) & 0xff;
> + c->Request.CDB[7]= ((u64)start_blk >> 16) & 0xff;
> + c->Request.CDB[8]= ((u64)start_blk >>  8) & 0xff;

put_unaligned(cpu_to_be64(start_blk), &c->Request.CDB[2]);

which is what's happening here anyway.
-
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] - Add "def_bool" Kconfig format documentation

[Robert P. J. Day]

On Sat, 11 Aug 2007, Randy Dunlap wrote:

> On Tue, 07 Aug 2007 00:29:40 +0200 Vincent Legoll wrote:
>
> > Hello,
> >
> > here is a small documentation patch for the KConfig file format
> > "def_bool" type definition that was missing.
>
> There are also def_boolean and def_tristate.

while the parser recognizes "def_boolean", it's not used anywhere in
the tree.  perhaps it can simply be dropped in favour of def_bool.

rday
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page

-
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] [1/2] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

[Joe Perches]

I grew weary of looking up the appropriate
maintainer email address(es) to CC: for a patch.

I added flags to the MAINTAINERS file

F:  file pattern

for each maintained block and a script to parse
the modified blocks for maintainer and list
email addresses.

perl scripts/get_maintainer.pl 

gives the appropriate maintainer(s).

Please apply.

cheers,  Joe

--- /dev/null   2007-08-10 07:32:20.684406250 -0700
+++ scripts/get_maintainer.pl   2007-08-11 22:33:30.0 -0700
@@ -0,0 +1,212 @@
+#!/usr/bin/perl -w
+# (c) 2007, Joe Perches <[EMAIL PROTECTED]>
+#   created from checkpatch.pl
+# Licensed under the terms of the GNU GPL License version 2
+
+use strict;
+
+my $P = $0;
+$P =~ [EMAIL PROTECTED]/@@g;
+
+my $V = '0.01';
+
+use Getopt::Long qw(:config no_auto_abbrev);
+
+my $tree = "./";
+my $email_maintainer = 1;
+my $email_list = 1;
+my $email_subscriber_list = 0;
+
+my %saw;
+
+GetOptions(
+  'tree=s' => \$tree,
+  'm!' => \$email_maintainer,
+  'l!' => \$email_list,
+  's!' => \$email_subscriber_list,
+  ) or exit;
+
+my $exit = 0;
+
+if ($#ARGV < 0 ||
+($email_maintainer == 0 && $email_list == 0 && $email_subscriber_list == 
0)) {
+print "usage: $P [options] patchfile\n";
+print "version: $V\n";
+print "  --tree [path] => linux kernel source path\n";
+print "  --m => include maintainer(s) if any\n";
+print "  --l => include list(s) if any\n";
+print "  --s => include subscriber only list(s) if any\n";
+print "Default: [--m --l]\n";
+print "Be sure to select something...\n";
+exit(1);
+}
+
+if ($tree && !top_of_kernel_tree($tree)) {
+if (${tree} ne "") {
+   print "'${tree}' ";
+} else {
+   print "The current directory ";
+}
+print "doesn't appear to be a linux kernel source tree\n";
+exit(2);
+}
+
+## Read MAINTAINERS for type/value pairs
+
+my @typevalue = ();
+open(MAINT, "<${tree}MAINTAINERS") || die "$P: Can't open 
${tree}MAINTAINERS\n";
+while () {
+if (m/^(\C):\s*(.*)/) {
+   my $type = $1;
+   my $value = $2;
+   if ($type eq "F") {  ##Filename pattern matching
+   $value =~ [EMAIL PROTECTED]@[EMAIL PROTECTED];   ##Convert . to 
\.
+   $value =~ s/\*/\.\*/g;   ##Convert * to .*
+   }
+   push(@typevalue, "$type:$value");
+} elsif (!/^(\s)*$/) {
+   push(@typevalue, $_);
+}
+}
+close(MAINT);
+
+## Find the patched filenames
+
+my @patchedfiles = ();
+open(PATCH, "<$ARGV[0]") or die "Can't open $ARGV[0]\n";
+while () {
+if (m/^\+\+\+\s+(\S+)/) {
+   my $file = $1;
+   $file =~ [EMAIL PROTECTED]/]*/@@;
+   $file =~ [EMAIL PROTECTED]@@;
+   push(@patchedfiles, $file);
+}
+}
+close(PATCH);
+
+# Sort and uniq patchedfiles
+
+undef %saw;
[EMAIL PROTECTED] = sort @patchedfiles;
[EMAIL PROTECTED] = grep(!$saw{$_}++, @patchedfiles);
+
+# Find responsible parties
+
+my @email_to = ();
+foreach (@patchedfiles) {
+my $patchedfile = $_;
+my $tvi = 0;
+
+foreach (@typevalue) {
+   if (m/^(\C):(.*)/) {
+   my $type = $1;
+   my $value = $2;
+   if ($type eq 'F') {
+   if (file_match_pattern($patchedfile, $value)) {
+   my $ptvi = $tvi - 1;
+   while ($ptvi >= 0) {
+   my $tv = $typevalue[$ptvi];
+   if ($tv =~ m/^(\C):(.*)/) {
+   my $ptype = $1;
+   my $pvalue = $2;
+   if ($ptype eq "L") {
+   my $subscr = $pvalue;
+   if ($subscr =~ m/\s*\(subscribers-only\)/) {
+   if ($email_subscriber_list > 0) {
+   $subscr =~ s/\s*\(subscribers-only\)//g;
+   push(@email_to, $subscr);
+   }
+   } else {
+   if ($email_list > 0) {
+   push(@email_to, $pvalue);
+   }
+   }
+   } elsif ($ptype eq "M") {
+   if ($email_maintainer > 0) {
+   if ($ptvi >= 0) {
+   my $tv = $typevalue[$ptvi - 1];
+   if ($tv =~ m/^(\C):(.*)/) {
+   if ($1 eq "P") {
+   push(@email_to, "$2 <$pvalue>");
+   } else {
+   push(@email_to, $pvalue);
+   }
+   }
+   } else {
+   push(@email_to, $pvalue);
+  

Re: [PATCH] make atomic_t volatile on all architectures

[Linus Torvalds]

On Sun, 12 Aug 2007, Segher Boessenkool wrote:
>
> Note that last line.

Segher, how about you just accept that Linux uses gcc as per reality, and 
that sometimes the reality is different from your expectations?

"+m" works. We use it. It's better than the alternatives. Pointing to 
stale documentation doesn't change anything.

The same is true of accesses through a volatile pointer. The kernel has 
done that for a *loong* time (all MMIO IO is done that way), and it's 
totally pointless to say that "volatile" isn't guaranteed to do what it 
does. It works, and quite frankly, if it didn't work, it would be a gcc 
BUG.

And again, this is not a "C standard" issue. It's a "sane implementation" 
issue. Linux expects the compiler to be sane. If it isn't, that's not our 
problem. gcc *is* sane, and I don't see why you constantly act as if it 
wasn't.

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

[GIT PATCH] ACPI patches for 2.6.23-rc2

[Len Brown]

Hi Linus,

please pull from: 

git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release

This will update the files shown below.

thanks!

-Len

ps. individual patches are available on [EMAIL PROTECTED]
and a consolidated plain patch is available here:
ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.23/acpi-release-20070126-2.6.23-rc2.diff.gz

 Documentation/kernel-parameters.txt |   22 ++
 Documentation/thinkpad-acpi.txt |4 
 arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c |   41 +---
 drivers/acpi/asus_acpi.c|1 
 drivers/acpi/battery.c  |   47 +
 drivers/acpi/bay.c  |2 
 drivers/acpi/dock.c |6 
 drivers/acpi/ec.c   |  113 +---
 drivers/acpi/event.c|2 
 drivers/acpi/processor_idle.c   |   14 +
 drivers/acpi/processor_perflib.c|6 
 drivers/acpi/sbs.c  |6 
 drivers/acpi/tables/tbxface.c   |   23 ++
 drivers/acpi/thermal.c  |  143 ++--
 drivers/char/sonypi.c   |7 
 drivers/misc/Kconfig|   22 +-
 drivers/misc/sony-laptop.c  |7 
 drivers/misc/thinkpad_acpi.c|   10 -
 drivers/misc/thinkpad_acpi.h|2 
 include/acpi/processor.h|2 
 20 files changed, 311 insertions(+), 169 deletions(-)

through these commits:

Adrian Bunk (4):
  sony-laptop: sony_nc_ids[] can become static.
  ACPI: EC: acpi_ec_remove(): fix use-after-free
  ACPI: sbs: remove dead code
  ACPI: static

Alexey Starikovskiy (5):
  ACPI: EC: Remove noisy debug printk fron EC driver.
  ACPI: Battery: Synchronize battery operations.
  ACPI: EC: If ECDT is not found, look up EC in DSDT.
  ACPI: EC: Switch from boot_ec as soon as we find its desc in DSDT.
  ACPI EC: remove potential deadlock from EC

Eugene Teo (1):
  sonypi: fix ids member of struct acpi_driver

Fenghua Yu (1):
  acpi-cpufreq: Fix some x86/x86-64 acpi-cpufreq driver issues

Henrique de Moraes Holschuh (3):
  ACPI: thinkpad-acpi: fix the module init failure path
  ACPI: thinkpad-acpi: change thinkpad-acpi input default and kconfig help
  ACPI: thinkpad-acpi: fix sysfs paths in documentation

Holger Macht (1):
  ACPI: dock: Send key=value pair instead of plain value

Jesper Juhl (1):
  asus_acpi: fix possible double free (found by Coverity)

Len Brown (8):
  ACPI: add "acpi_no_auto_ssdt" bootparam
  ACPI: EC: fix build warning
  ACPI: thermal: create "thermal.off=1" to disable ACPI thermal support
  ACPI: thermal: expose "thermal.tzp=" to set global polling frequency
  ACPI: thermal: create "thermal.psv=" to override passive trip points
  ACPI: thermal: create "thermal.nocrt" to disable critical actions
  ACPI: thermal: create "thermal.act=" to disable or override active trip 
point
  ACPI: thermal: add DMI hooks to handle AOpen's broken Award BIOS

Mattia Dongili (1):
  sony-laptop: restore the last user requested brightness level on resume.

Meelis Roos (1):
  ACPI: EC: fix run-together printk lines

Stephan Berberig (1):
  ACPI: bay: send envp with uevent - fix

Venki Pallipadi (1):
  ACPI: fix "Time Problems with 2.6.23-rc1-gf695baf2"

with this log:

commit 4e54e9f4423a86aa21b70cb9d339cb09f275188f
Merge: 27196c3... bc90a01...
Author: Len Brown <[EMAIL PROTECTED]>
Date:   Sun Aug 12 00:21:22 2007 -0400

Pull sbs into release branch

commit 27196c30db1ed4ab09c2071149b3324a1a53cfb9
Merge: ad17b20... 5010929...
Author: Len Brown <[EMAIL PROTECTED]>
Date:   Sun Aug 12 00:21:08 2007 -0400

Pull processor into release branch

commit ad17b209dca860a570e4ca75312c9f4d32672402
Merge: d88da66... e13d874...
Author: Len Brown <[EMAIL PROTECTED]>
Date:   Sun Aug 12 00:20:59 2007 -0400

Pull fluff into release branch

commit d88da66f9397f06f3a7b4e5148bd5e71cb9d7952
Merge: 6712a4f... 199e9e7...
Author: Len Brown <[EMAIL PROTECTED]>
Date:   Sun Aug 12 00:20:41 2007 -0400

Pull ec into release branch

commit 6712a4fbb14a466d259e53a5314d8011ecab3d7b
Merge: d8dd3cb... 66b5682...
Author: Len Brown <[EMAIL PROTECTED]>
Date:   Sun Aug 12 00:20:33 2007 -0400

Pull dock-bay into release branch

commit d8dd3cbcf1b30c315a28f65cb719bb2d7105a317
Merge: fc0dc4d... 0b5bfa1...
Author: Len Brown <[EMAIL PROTECTED]>
Date:   Sun Aug 12 00:19:23 2007 -0400

Pull bugzilla-8842 into release branch

commit fc0dc4d3aa9c73e275accf2966e0bdf16bff45f1
Merge: 53fdc51... 3bd92ba...
Author: Len Brown <[EMAIL PROTECTED]>
Date:   Sun Aug 12 00:18:11 2007 -0400

Pull bugzilla-8768 into release branch

commit 53fdc5185c994ad6def3729a905ac4a47c477c9d
Merge: 3b6919e... 67effe8...
Author: Len Brown <[EMAIL PROTECTED]>
Date:   Sun Aug 12 00:17:59 2007 -

Re: [PATCH] make atomic_t volatile on all architectures

[Segher Boessenkool]

You'd have to use "+m".


Yes, though I would use "=m" on the output list and "m" on the input
list. The reason is that I've seen gcc fall on its face with an ICE on
s390 due to "+m". The explanation I've got from our compiler people was
quite esoteric, as far as I remember gcc splits "+m" to an input 
operand

and an output operand. Now it can happen that the compiler chooses two
different registers to access the same memory location. "+m" requires
that the two memory references are identical which causes the ICE if
they are not.


The problem is very nicely described here, last paragraph:


It's not a problem anymore in (very) recent GCC, although
that of course won't help you in the kernel (yet).


I do not know if the current compilers still do this. Has
anyone else seen this happen ?


In recent GCC, it's actually documented:

 The ordinary output operands must be write-only; GCC will assume that
the values in these operands before the instruction are dead and need
not be generated.  Extended asm supports input-output or read-write
operands.  Use the constraint character `+' to indicate such an operand
and list it with the output operands.  You should only use read-write
operands when the constraints for the operand (or the operand in which
only some of the bits are to be changed) allow a register.

Note that last line.


Segher

-
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: [BUGFIX] NULL pointer dereference in __vm_enough_memory()

[WU Fengguang]

On Sat, Aug 11, 2007 at 11:31:09PM +0530, Balbir Singh wrote:
> Andrew Morton wrote:
> > On Sat, 11 Aug 2007 20:00:12 +0530 "Balbir Singh" <[EMAIL PROTECTED]> wrote:
> >>>
> >> Shouldn't we just not stop vm accounting for kernel threads?
> >>
> > 
> > Could be.  It'd help heaps if we knew which patch in -mm caused
> > this, but from a quick peek it seems to me that mainline should be
> > vulnerable as well.
> 
> Thats a valid point. It would be interesting to see what the overcommit
> setting was, when the panic occurred.

FYI, I do have nondefault overcommit settings:

vm.overcommit_memory = 2
vm.lowmem_reserve_ratio = 1 1

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

Re: [BUGFIX] NULL pointer dereference in __vm_enough_memory()

[WU Fengguang]

On Sat, Aug 11, 2007 at 10:00:15AM -0700, Andrew Morton wrote:
> On Sat, 11 Aug 2007 20:00:12 +0530 "Balbir Singh" <[EMAIL PROTECTED]> wrote:
> 
> > On 8/11/07, Fengguang Wu <[EMAIL PROTECTED]> wrote:
> 
> hm, both people who replied to this removed Fengguang from cc.  Disagreement
> between headers and MUAs, perhaps?

Hehe, my email setup is somehow complicated. I'd better not to intermix
[EMAIL PROTECTED] and [EMAIL PROTECTED] in one single mail :)

-
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: [BUGFIX] NULL pointer dereference in __vm_enough_memory()

[Cyrill Gorcunov]

[Fengguang Wu - Sun, Aug 12, 2007 at 01:29:15PM +0800]
| On Sat, Aug 11, 2007 at 06:17:14PM +0400, Cyrill Gorcunov wrote:
| > [Fengguang Wu - Sat, Aug 11, 2007 at 09:21:31PM +0800]
| > | Andrew,
| > | 
| > | I'm not sure if this patch is the right fix for the bug.  But it do
| > | stops the oops message. The bug also happens in 
2.6.23-rc1-mm2/2.6.23-rc2-mm2.
| > | I'm running debian/sid. The .config is attached.
| > | 
| > |
| > 
| > [...snip...]
| > 
| > Even if you're right you have to make the same patch for
| > mm/nommu.c but I've an anticipation the problem is growing
| > up from another point (and I'm really hoping that I'm wrong ;)
| 
| Thank you, the patch is updated to:
| ===
| 
| Fix possible NULL pointer deference on __vm_enough_memory().
| 
| Cc: Cyrill Gorcunov <[EMAIL PROTECTED]>
| Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
| ---
|  mm/mmap.c  |3 ++-
|  mm/nommu.c |3 ++-
|  2 files changed, 4 insertions(+), 2 deletions(-)
| 
| --- linux-2.6.23-rc2-mm2.orig/mm/mmap.c
| +++ linux-2.6.23-rc2-mm2/mm/mmap.c
| @@ -166,7 +166,8 @@ int __vm_enough_memory(long pages, int c
|  
|   /* Don't let a single process grow too big:
|  leave 3% of the size of this process for other processes */
| - allowed -= current->mm->total_vm / 32;
| + if (current->mm)
| + allowed -= current->mm->total_vm / 32;
|  
|   /*
|* cast `allowed' as a signed long because vm_committed_space
| --- linux-2.6.23-rc2-mm2.orig/mm/nommu.c
| +++ linux-2.6.23-rc2-mm2/mm/nommu.c
| @@ -1342,7 +1342,8 @@ int __vm_enough_memory(long pages, int c
|  
|   /* Don't let a single process grow too big:
|  leave 3% of the size of this process for other processes */
| - allowed -= current->mm->total_vm / 32;
| + if (current->mm)
| + allowed -= current->mm->total_vm / 32;
|  
|   /*
|* cast `allowed' as a signed long because vm_committed_space
| 

ok, lets wait for some mature developer comments

Cyrill

-
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: [BUGFIX] NULL pointer dereference in __vm_enough_memory()

[Fengguang Wu]

On Sat, Aug 11, 2007 at 06:17:14PM +0400, Cyrill Gorcunov wrote:
> [Fengguang Wu - Sat, Aug 11, 2007 at 09:21:31PM +0800]
> | Andrew,
> | 
> | I'm not sure if this patch is the right fix for the bug.  But it do
> | stops the oops message. The bug also happens in 
> 2.6.23-rc1-mm2/2.6.23-rc2-mm2.
> | I'm running debian/sid. The .config is attached.
> | 
> |
> 
> [...snip...]
> 
> Even if you're right you have to make the same patch for
> mm/nommu.c but I've an anticipation the problem is growing
> up from another point (and I'm really hoping that I'm wrong ;)

Thank you, the patch is updated to:
===

Fix possible NULL pointer deference on __vm_enough_memory().

Cc: Cyrill Gorcunov <[EMAIL PROTECTED]>
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
 mm/mmap.c  |3 ++-
 mm/nommu.c |3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

--- linux-2.6.23-rc2-mm2.orig/mm/mmap.c
+++ linux-2.6.23-rc2-mm2/mm/mmap.c
@@ -166,7 +166,8 @@ int __vm_enough_memory(long pages, int c
 
/* Don't let a single process grow too big:
   leave 3% of the size of this process for other processes */
-   allowed -= current->mm->total_vm / 32;
+   if (current->mm)
+   allowed -= current->mm->total_vm / 32;
 
/*
 * cast `allowed' as a signed long because vm_committed_space
--- linux-2.6.23-rc2-mm2.orig/mm/nommu.c
+++ linux-2.6.23-rc2-mm2/mm/nommu.c
@@ -1342,7 +1342,8 @@ int __vm_enough_memory(long pages, int c
 
/* Don't let a single process grow too big:
   leave 3% of the size of this process for other processes */
-   allowed -= current->mm->total_vm / 32;
+   if (current->mm)
+   allowed -= current->mm->total_vm / 32;
 
/*
 * cast `allowed' as a signed long because vm_committed_space

-
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: CFS review

[Ingo Molnar]

* Willy Tarreau <[EMAIL PROTECTED]> wrote:

> > 1. Two simple busy loops, one of them is reniced to 15, according to 
> > my calculations the reniced task should get about 3.4% 
> > (1/(1.25^15+1)), but I get this:
> > 
> >   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
> >  4433 roman 20   0  1532  300  244 R 99.2  0.2   5:05.51 l
> >  4434 roman 35  15  1532   72   16 R  0.7  0.1   0:10.62 l
> 
> Could this be caused by typos in some tables like you have found in 
> wmult ?

note that the typo was not in the weight table but in the inverse weight 
table which didnt really affect CPU utilization (that's why we didnt 
notice the typo sooner). Regarding the above problem with nice +15 being 
beefier than intended i'd suggest to re-test with a doubled 
/proc/sys/kernel/sched_runtime_limit value, or with:

  echo 30 > /proc/sys/kernel/sched_features

(which turns off sleeper fairness)

> >  4477 roman  5 -15  1532   68   16 R  8.6  0.1   0:07.63 l
> >  4476 roman  5 -15  1532   68   16 R  9.6  0.1   0:07.38 l
> >  4475 roman  5 -15  1532   68   16 R  1.3  0.1   0:07.09 l
> >  4474 roman  5 -15  1532   68   16 R  2.3  0.1   0:07.97 l
> >  4473 roman  5 -15  1532  296  244 R  1.0  0.2   0:07.73 l
> 
> Do you see this only at -15, or starting with -15 and below ?

i think this was scheduling jitter caused by the larger granularity of 
negatively reniced tasks. This got improved recently, with latest -git i 
get:

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 3108 root   5 -15  1576  248  196 R  5.0  0.0   0:07.26 loop_silent
 3109 root   5 -15  1576  248  196 R  5.0  0.0   0:07.26 loop_silent
 3110 root   5 -15  1576  248  196 R  5.0  0.0   0:07.26 loop_silent
 3111 root   5 -15  1576  244  196 R  5.0  0.0   0:07.26 loop_silent
 3112 root   5 -15  1576  248  196 R  5.0  0.0   0:07.26 loop_silent
 3113 root   5 -15  1576  248  196 R  5.0  0.0   0:07.26 loop_silent

that's picture-perfect CPU time distribution. But, and that's fair to 
say, i never ran such an artificial workload of 20x nice -15 infinite 
loops (!) before, and boy does interactivity suck (as expected) ;)

Ingo
-
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: Driver-level memory management

[Paul Mundt]

On Sat, Aug 11, 2007 at 09:14:00PM -0600, Michael Bourgeous wrote:
> I'm working on a driver for older HDTV cards based on the TL880 chip.
> These cards typically have 16MB of their own memory, which is
> available to me over the PCI bus.  Various functions of the card
> require me to manage this memory, allocating and freeing chunks of it
> as necessary.  I can easily include my own allocation and management
> code, but I'm sure this is a problem that has been solved before.
> I've found two interesting sets of functions, the kmem_cache_* and
> mempool_* functions, but neither does quite what I'm looking for.  So,
> in a sentence, my question is this: Does the kernel provide memory
> pool functions that would allow me to call the appropriate equivalent
> of kmalloc/kfree, using the card's memory as the pool instead of
> actually allocating physical or virtual memory?
> 
Many platforms have similar requirements for DMA, both in terms of bounce
buffers and consistent allocations. If you're looking at this
specifically for DMA, then things like dma_declare_coherent_memory() and
the corresponding alloc/free routines that go along with it will do what
you need. If you require something more generalized, you can still
abstract what you need fairly trivially.

There are a few examples of bitmap based region management in the kernel
you can look at. arch/i386/kernel/pci-dma.c implements the aforementioned
DMA ops, and arch/sh/kernel/cpu/sh4/sq.c does something similar, albeit
with a larger address range (64MB). A simple bitmap approach from one or
the other should work fine for your 16MB case.
-
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] - Add "def_bool" Kconfig format documentation

[Randy Dunlap]

On Tue, 07 Aug 2007 00:29:40 +0200 Vincent Legoll wrote:

> Hello,
> 
> here is a small documentation patch for the KConfig file format
> "def_bool" type definition that was missing.

There are also def_boolean and def_tristate.
I suppose that I should resubmit this patch:
  http://marc.info/?l=linux-kernel&m=115471883121076&w=2


> I hope the patch is not mangled...
> 
> >From 4742eb7a3169001304524e82a88ec1c94f70aa56 Mon Sep 17 00:00:00 2001
> From: Vincent Legoll <[EMAIL PROTECTED]>
> Date: Sat, 4 Aug 2007 16:50:06 +0200
> Subject: [PATCH] - Add "def_bool" Kconfig format documentation
> 
> 
> Signed-off-by: Vincent Legoll <[EMAIL PROTECTED]>
> ---
>  Documentation/kbuild/kconfig-language.txt |8 
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/kbuild/kconfig-language.txt 
> b/Documentation/kbuild/kconfig-language.txt
> index 536d5bf..27b8af9 100644
> --- a/Documentation/kbuild/kconfig-language.txt
> +++ b/Documentation/kbuild/kconfig-language.txt
> @@ -77,6 +77,14 @@ applicable everywhere (see syntax).
>Optionally, dependencies only for this default value can be added
> with
>"if".
>  
> +- boolean type definition with a default value: "def_bool" 
> +  So these two examples are equivalent:
> +  
> +def_bool 
> +  and
> +bool
> +default 
> +  
>  - dependencies: "depends on"/"requires" 
>This defines a dependency for this menu entry. If multiple
>dependencies are defined, they are connected with '&&'. Dependencies
> -- 


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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] sysdev: remove global sysdev drivers list

[Akinobu Mita]

No one uses sysdev_drivers. Because no one calls sysdev_driver_register
with NULL class.

And it is difficult to imagine that someone want to implement a global
sysdev driver which is called with all sys_device on any kind of
sysdev_class.

So this patch removes global sysdev_drivers list.

Cc: Tejun Heo <[EMAIL PROTECTED]>
Cc: Cornelia Huck <[EMAIL PROTECTED]>
Cc: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>

---
 drivers/base/sys.c |   66 +
 1 file changed, 12 insertions(+), 54 deletions(-)

Index: 2.6-git/drivers/base/sys.c
===
--- 2.6-git.orig/drivers/base/sys.c
+++ 2.6-git/drivers/base/sys.c
@@ -153,25 +153,22 @@ void sysdev_class_unregister(struct sysd
 EXPORT_SYMBOL_GPL(sysdev_class_register);
 EXPORT_SYMBOL_GPL(sysdev_class_unregister);
 
-
-static LIST_HEAD(sysdev_drivers);
 static DEFINE_MUTEX(sysdev_drivers_lock);
 
 /**
  * sysdev_driver_register - Register auxillary driver
- * @cls:   Device class driver belongs to.
+ * @cls:   Device class driver belongs to.
  * @drv:   Driver.
  *
- * If @cls is valid, then @drv is inserted into @cls->drivers to be
+ * @drv is inserted into @cls->drivers to be
  * called on each operation on devices of that class. The refcount
  * of @cls is incremented.
- * Otherwise, @drv is inserted into sysdev_drivers, and called for
- * each device.
  */
 
-int sysdev_driver_register(struct sysdev_class * cls,
-  struct sysdev_driver * drv)
+int sysdev_driver_register(struct sysdev_class *cls, struct sysdev_driver *drv)
 {
+   int err = 0;
+
mutex_lock(&sysdev_drivers_lock);
if (cls && kset_get(&cls->kset)) {
list_add_tail(&drv->entry, &cls->drivers);
@@ -182,10 +179,12 @@ int sysdev_driver_register(struct sysdev
list_for_each_entry(dev, &cls->kset.list, kobj.entry)
drv->add(dev);
}
-   } else
-   list_add_tail(&drv->entry, &sysdev_drivers);
+   } else {
+   err = -EINVAL;
+   WARN_ON(1);
+   }
mutex_unlock(&sysdev_drivers_lock);
-   return 0;
+   return err;
 }
 
 
@@ -206,6 +205,8 @@ void sysdev_driver_unregister(struct sys
drv->remove(dev);
}
kset_put(&cls->kset);
+   } else {
+   WARN_ON(1);
}
mutex_unlock(&sysdev_drivers_lock);
 }
@@ -251,12 +252,6 @@ int sysdev_register(struct sys_device * 
 * code that should have called us.
 */
 
-   /* Notify global drivers */
-   list_for_each_entry(drv, &sysdev_drivers, entry) {
-   if (drv->add)
-   drv->add(sysdev);
-   }
-
/* Notify class auxillary drivers */
list_for_each_entry(drv, &cls->drivers, entry) {
if (drv->add)
@@ -272,11 +267,6 @@ void sysdev_unregister(struct sys_device
struct sysdev_driver * drv;
 
mutex_lock(&sysdev_drivers_lock);
-   list_for_each_entry(drv, &sysdev_drivers, entry) {
-   if (drv->remove)
-   drv->remove(sysdev);
-   }
-
list_for_each_entry(drv, &sysdev->cls->drivers, entry) {
if (drv->remove)
drv->remove(sysdev);
@@ -320,12 +310,6 @@ void sysdev_shutdown(void)
struct sysdev_driver * drv;
pr_debug(" %s\n", kobject_name(&sysdev->kobj));
 
-   /* Call global drivers first. */
-   list_for_each_entry(drv, &sysdev_drivers, entry) {
-   if (drv->shutdown)
-   drv->shutdown(sysdev);
-   }
-
/* Call auxillary drivers next. */
list_for_each_entry(drv, &cls->drivers, entry) {
if (drv->shutdown)
@@ -354,12 +338,6 @@ static void __sysdev_resume(struct sys_d
if (drv->resume)
drv->resume(dev);
}
-
-   /* Call global drivers. */
-   list_for_each_entry(drv, &sysdev_drivers, entry) {
-   if (drv->resume)
-   drv->resume(dev);
-   }
 }
 
 /**
@@ -393,15 +371,6 @@ int sysdev_suspend(pm_message_t state)
list_for_each_entry(sysdev, &cls->kset.list, kobj.entry) {
pr_debug(" %s\n", kobject_name(&sysdev->kobj));
 
-   /* Call global drivers first. */
-   list_for_each_entry(drv, &sysdev_drivers, entry) {
-   if (drv->suspend) {
-   ret = drv->suspend(sysdev, state);
- 

Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel

[Kyle Moffett]

Linus and AKPM pulled from CC, I'm sure they're bored to tears by  
now ;-).


On Aug 11, 2007, at 21:21:55, Casey Schaufler wrote:

--- Kyle Moffett <[EMAIL PROTECTED]> wrote:

On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
It would be instructive for those who are not well versed in the  
nuances of SELinux policy if you actually spelled out the whole  
thing, rather than using "## and more ##". Part of the point of  
Smack is the makeup of the full list that would be required here.


Well, yes, but how exactly do you define "read", "write", and  
"execute" for the full list of SELinux object classes found here:   
http://www.tresys.com/selinux/obj_perms_help.html


Smack is designed to treat objects as consistantly as is  
reasonable.  The list of object classes defined by SELinux is great  
for a system designed to treat accesses with the highest possible  
granularity. This is not a design goal for Smack.


I was considering compiling the complete list, but such an  
exercise would take me at least an hour to do properly and which  
categories individual permissions should be placed in could be  
argued for weeks.


I will be happy to consider your arguement when you are willing to  
present the complete argument.


Here's my complete argument:

Regardless of how you categorize "read", "write", "execute", and  
"doesnt-need-protection" in your policy language, I can write an  
SELinux policy and a list of labels which expresses that policy.   
Moreover, without too much work I can probably write a Perl script to  
do it for you.  On the other hand I can only do that if you tell me  
exactly how you want to categorize those things, though.  In my  
personal opinion they cannot be reasonably categorized without  
breaking all sorts of tools or leaving gaping holes; precisely the  
reason that SELinux uses such a fine-grained list.


Specifically, do you classify the bind() syscall as a "read" or a  
"write" operation.


Neither. Bind attaches a name (port number) to a socket (which is a  
data structure that is part of your process) from a global  
namespace.  No objects are involved, hence no accesses.


So "bind()" doesn't present a security hole at all and any program  
may bind to any port?  Sounds fun!  I'm sure lots of crackers would  
love to get ahold of an account on such a web-server; what havoc they  
could wreak!  Even the <1024 restriction doesn't sufficiently limit  
things these days, as many critical services use ports >=1024.



And now to describe these rules:


Smack defines and uses these labels:
  "*" - pronounced "star"
  "_" - pronounced "floor"
  "^" - pronounced "hat"
  "?" - pronounced "huh"

The access rules enforced by Smack are, in order:

1. Any access requested by a task labeled "*" is denied.
2. A read or execute access requested by a task labeled "^" is  
permitted.
3. A read or execute access requested on an object labeled "_"  
is permitted.

4. Any access requested on an object labeled "*" is permitted.
5. Any access requested by a task on an object with the same  
label is permitted.
6. Any access requested that is explicitly defined in the  
loaded rule set is permitted.

7. Any other access is denied.


## These are calls to the above macros which plug in the  
necessary arguments

r(hat, {*})
x(hat, {*})
r(~{star}, floor)
x(~{star}, floor)
r(~{star}, star)
w(~{star}, star)
x(~{star}, star)
r(~{star}, self)
w(~{star}, self)
x(~{star}, self)
## Include your "loaded rule set" here ##


What would that look like?


The same kind of thing as the r, x, and w above, with occasional  
"type my_type_t; role rr types my_type_t;" to declare a type  
before use.  If you wanted to add support for attributes which  
apply to multiple types, you could put those after a comma after  
the "type my_type_t" portion of the type declaration.


Well, I'm interested in seeing the actual code, not "the same kind  
of thing" as arguement.


Ok, you want sample policy to match your "MLS" sample?  For  
convenience here's one more macro:

define(`rx',`r(`$1',`$2') x(`$1',`$2')')

type unclass;
type c;
type s;
type ts;
rx(c, unclass)
rx(s, c)
rx(s, unclass)
rx(ts, s)
rx(ts, c)
rx(ts, unclass)

In case you don't have the policy you typed into your email, it looks  
almost identical with a few exceptions for slightly modified syntax:

CUnclass rx
SC   rx
SUnclass rx
TS   S   rx
TS   C   rx
TS   Unclass rx


Smack rule sets can be easily defined that describe  
Bell&LaPadula sensitivity, Biba integrity, and a variety of  
interesting configurations. Smack rule sets can be modified on  
the fly to accomodate changes in the operating environment or  
even the time of day.


SELinux can do this as well.  It even includes support for  
conditional policy:


bool foo_can_do_logging true;
if (foo_can_do_logging) {
allow foo_t foo_log_t:file { create read getattr append };
}


You have to build the booleans into the policy in advance.


Wel

Re: CFS review

[Ingo Molnar]

* Al Boldi <[EMAIL PROTECTED]> wrote:

> That's because granularity increases when decreasing nice, and results 
> in larger timeslices, which affects smoothness negatively.  chew.c 
> easily shows this problem with 2 background cpu-hogs at the same 
> nice-level.
> 
> pid 908, prio   0, out for8 ms, ran for4 ms, load  37%
> pid 908, prio   0, out for8 ms, ran for4 ms, load  37%
> pid 908, prio   0, out for8 ms, ran for2 ms, load  26%
> pid 908, prio   0, out for8 ms, ran for4 ms, load  38%
> pid 908, prio   0, out for2 ms, ran for1 ms, load  47%
> 
> pid 908, prio  -5, out for   23 ms, ran for3 ms, load  14%
> pid 908, prio  -5, out for   17 ms, ran for9 ms, load  35%

yeah. Incidentally, i refined this last week and those nice-level 
granularity changes went into the upstream scheduler code a few days 
ago:

  commit 7cff8cf61cac15fa29a1ca802826d2bcbca66152
  Author: Ingo Molnar <[EMAIL PROTECTED]>
  Date:   Thu Aug 9 11:16:52 2007 +0200

  sched: refine negative nice level granularity

  refine the granularity of negative nice level tasks: let them
  reschedule more often to offset the effect of them consuming
  their wait_runtime proportionately slower. (This makes nice-0
  task scheduling smoother in the presence of negatively
  reniced tasks.)

  Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>

so could you please re-check chew jitter behavior with the latest 
kernel? (i've attached the standalone patch below, it will apply cleanly 
to rc2 too.)

when testing this, you might also want to try chew-max:

   http://redhat.com/~mingo/cfs-scheduler/tools/chew-max.c

i added a few trivial enhancements to chew.c: it tracks the maximum 
latency, latency fluctuations (noise of scheduling) and allows it to be 
run for a fixed amount of time.

NOTE: if you run chew from any indirect terminal (xterm, ssh, etc.) it's 
best to capture/report chew numbers like this:

  ./chew-max 60 > chew.log

otherwise the indirect scheduling activities of the chew printout will 
disturb the numbers.

> It looks like the larger the granularity, the more unpredictable it 
> gets, which probably means that this unpredictability exists even at 
> smaller granularity but is only exposed with larger ones.

this should only affect non-default nice levels. Note that 99.9%+ of all 
userspace Linux CPU time is spent on default nice level 0, and that is 
what controls the design. So the approach was always to first get nice-0 
right, and then to adjust the non-default nice level behavior too, 
carefully, without hurting nice-0 - to refine all the workloads where 
people (have to) use positive or negative nice levels. In any case, 
please keep re-testing this so that we can adjust it.

Ingo

->
commit 7cff8cf61cac15fa29a1ca802826d2bcbca66152
Author: Ingo Molnar <[EMAIL PROTECTED]>
Date:   Thu Aug 9 11:16:52 2007 +0200

sched: refine negative nice level granularity

refine the granularity of negative nice level tasks: let them
reschedule more often to offset the effect of them consuming
their wait_runtime proportionately slower. (This makes nice-0
task scheduling smoother in the presence of negatively
reniced tasks.)

Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>

diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index 7a632c5..e91db32 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -222,21 +222,25 @@ niced_granularity(struct sched_entity *curr, unsigned 
long granularity)
 {
u64 tmp;
 
+   if (likely(curr->load.weight == NICE_0_LOAD))
+   return granularity;
/*
-* Negative nice levels get the same granularity as nice-0:
+* Positive nice levels get the same granularity as nice-0:
 */
-   if (likely(curr->load.weight >= NICE_0_LOAD))
-   return granularity;
+   if (likely(curr->load.weight < NICE_0_LOAD)) {
+   tmp = curr->load.weight * (u64)granularity;
+   return (long) (tmp >> NICE_0_SHIFT);
+   }
/*
-* Positive nice level tasks get linearly finer
+* Negative nice level tasks get linearly finer
 * granularity:
 */
-   tmp = curr->load.weight * (u64)granularity;
+   tmp = curr->load.inv_weight * (u64)granularity;
 
/*
 * It will always fit into 'long':
 */
-   return (long) (tmp >> NICE_0_SHIFT);
+   return (long) (tmp >> WMULT_SHIFT);
 }
 
 static inline void
-
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] Smack: Simplified Mandatory Access Control Kernel

[Keith Owens]

Casey Schaufler (on Sat, 11 Aug 2007 10:57:31 -0700) wrote:
>Smack is the Simplified Mandatory Access Control Kernel.
>
> [snip]
>
>Smack defines and uses these labels:
>
>"*" - pronounced "star"
>"_" - pronounced "floor"
>"^" - pronounced "hat"
>"?" - pronounced "huh"
>
>The access rules enforced by Smack are, in order:
>
>1. Any access requested by a task labeled "*" is denied.
>2. A read or execute access requested by a task labeled "^"
>   is permitted.
>3. A read or execute access requested on an object labeled "_"
>   is permitted.
>4. Any access requested on an object labeled "*" is permitted.
>5. Any access requested by a task on an object with the same
>   label is permitted.
>6. Any access requested that is explicitly defined in the loaded
>   rule set is permitted.
>7. Any other access is denied.

Some security systems that have the concept of "no default access"
(task labeled "*") also allow access by those tasks but only if there
is an explicit rule giving access to the task.  IOW, rule 6 is applied
before rule 1.  In my experience this simplifies special cases where a
task should only have access to a very small set of resources.  I'm
curious why smack goes the other 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: Are we properly prepared to handle 3 Socket setups?

[Rene Herman]

On 08/12/2007 05:29 AM, Roland Dreier wrote:


 > /*
 >  * Maximum threshold is 125
 >  */
 > threshold = min(125, threshold);
 > 
 > as either the comment or the code is wrong and it seems it's the

 > code.

What's the problem?  That line sets threshold to the smaller of the
current value or 125, which is exactly what one would want to do if
the maximum value is 125.  Just do a couple of examples: eg if threshold
is 100 going into that line, then the value is left alone; if
threshold is 150 then it gets set to 125; and that seems exactly correct.


Crap, need bed, sorry (the fls/ilog2 things still stand -- quite possibly 
both not a problem either).


Rene.

-
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] Smack: Simplified Mandatory Access Control Kernel

[Keith Owens]

Casey Schaufler (on Sat, 11 Aug 2007 12:56:42 -0700 (PDT)) wrote:
>
>--- Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include "../../net/netlabel/netlabel_domainhash.h"
>> 
>> can't you move this header to include/ instead?
>
>Paul Moore, the developer of netlabel, promised to work out
>the right solution for this with me at a future date. He
>doesn't want to move the header, and I respect that.

foo.c has

#include "netlabel_domainhash.h"

Makefile has CFLAGS_foo.o += -I$(srctree)/net/netlabel

I prefer to use -I $(srctree)/net/netlabel for readability but '-I '
breaks on SuSE builds for some reason that I cannot be bothered working
out.  -I$(srctree)/net/netlabel works.

>> > +  doip = kmalloc(sizeof(struct cipso_v4_doi), GFP_KERNEL);
>> > +  if (doip == NULL)
>> > +  panic("smack:  Failed to initialize cipso DOI.\n");
>> > +  doip->map.std = NULL;
>> > +
>> > +  ndmp = kmalloc(sizeof(struct netlbl_dom_map), GFP_KERNEL);
>> > +  if (ndmp == NULL)
>> > +  panic("smack:  Failed to initialize cipso ndmp.\n");
>> 
>> 
>> is panic() really the right thing here? It's usually considered quite
>> rude ;)
>
>It's really early in start-up and if you're out of memory at that
>point you are not going very far into the future.

Not to mention that you might end up running with an insecure system.
Security must be failsafe.

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

[BUG] Kernel panic - not syncing: VFS

[charles gagalac]

i'm getting the following kernel panic when booting:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

a bisect generated the commit below:

3320ad994afb2c44ad34b3b34c3c5cf0da297331 is first bad commit
commit 3320ad994afb2c44ad34b3b34c3c5cf0da297331
Author: dean gaudet
Date:   Fri Aug 10 22:30:59 2007 +0200

x86: Work around mmio config space quirk on AMD Fam10h

Some broken devices have been discovered to require %al/%ax/%eax registers
for MMIO config space accesses.  Modify mmconfig.c to use these registers
explicitly (rather than modify the global readb/writeb/etc inlines).

AK: also changed i386 to always use eax
AK: moved change to extended space probing to different patch
AK: reworked with inlines according to Linus' requirements.
AK: improve comments.
-
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/

[RFC] FUSE: mnotify (was: [RFC] VFS: mnotify)

[Al Boldi]

Al Boldi wrote:
> Jakob Oestergaard wrote:
> > Why on earth would you cripple the kernel defaults for ext3 (which is a
> > fine FS for boot/root filesystems), when the *fundamental* problem you
> > really want to solve lie much deeper in the implementation of the
> > filesystem?  Noatime doesn't solve the problem, it just makes it "less
> > horrible".
>
> inotify could easily solve the atime problem, but it's got the drawback of
> forcing the user to register each and every file/dir of interest, which
> isn't really reasonable on TB-filesystems.
>
> It could be feasible to introduce mnotify, which would notify the user of
> meta changes, like atime, across the filesystem.  Something like mnotify
> could also be helpful in CoW situations, provided it supported an in-sync
> interface.

Here is an idea:  Could FUSE be used to produce mnotify behaviour?


Thanks!

--
Al

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

reset during bootup - 2.6.23-rc2 (git d23cf676)

[Dan Merillat]

This one is going to be fun, since it's a hard reset back to bios, no
OOPS or anything shown.  It may be about the time RadeonFB kicks in,
but it's impossible to tell.  I'd guess 15-20 lines into dmesg.

I'm in the process of bisecting, currently 94c18227..d23cf676.

Any guesses of a specific patch to check?
-
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: Are we properly prepared to handle 3 Socket setups?

[Roland Dreier]

 > /*
 >  * Maximum threshold is 125
 >  */
 > threshold = min(125, threshold);
 > 
 > as either the comment or the code is wrong and it seems it's the
 > code.

What's the problem?  That line sets threshold to the smaller of the
current value or 125, which is exactly what one would want to do if
the maximum value is 125.  Just do a couple of examples: eg if threshold
is 100 going into that line, then the value is left alone; if
threshold is 150 then it gets set to 125; and that seems exactly correct.

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

[GIT PULL] sh64 updates for 2.6.23-rc3

[Paul Mundt]

Please pull from:

master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh64-2.6.git

Which contains:

Jesper Juhl (1):
  sh64: arch/sh64/kernel/signal.c: duplicate include removal

Michal Piotrowski (1):
  sh64: arch/sh64/kernel/setup.c: duplicate include removal.

Paul Mundt (1):
  sh64: Add missing dma_sync_single_for_*().

 arch/sh64/kernel/setup.c   |4 
 arch/sh64/kernel/signal.c  |1 -
 include/asm-sh64/dma-mapping.h |   18 ++
 3 files changed, 18 insertions(+), 5 deletions(-)
-
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: Documentation files in html format?

[Sam Ravnborg]

> Hi Sam,
> 
> Sorry for the late question (I've been away :).
> 
> Was your makefiles.txt conversion done totally by hand?
Yes. A few search&replace, the rest manual.

> Could it be automated?
For text with a unifom structure like makefiles.txt - yes.

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

[GIT PULL] sh updates for 2.6.23-rc3

[Paul Mundt]

Please pull from:

master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.23.git

Which contains:

Paul Mundt (3):
  sh: Fix PTRACE_PEEKTEXT/PEEKDATA fallout from generic_ptrace_peekdata().
  sh: panic on machvec section misalignment.
  sh: Add missing dma_sync_single_range_for_*().

 arch/sh/kernel/machvec.c |7 +++
 arch/sh/kernel/ptrace.c  |1 +
 include/asm-sh/dma-mapping.h |   19 +++
 3 files changed, 27 insertions(+)
-
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: Are we properly prepared to handle 3 Socket setups?

[Rene Herman]

On 08/12/2007 03:52 AM, Jesper Juhl wrote:


On 12/08/07, Rene Herman <[EMAIL PROTECTED]> wrote:

On 08/12/2007 03:08 AM, Jesper Juhl wrote:


This may be a little off topic, but I think it's interresting enough
to warrent a single mail.

I just saw a news article (http://www.theinquirer.net/?article=41610)
about a 3 Socket Opteron motherboard and couldn't help but wonder if
we are prepared to deal with such a beast, so I thought I'd inform
everyone :-)

I'm guessing equipping such a board with 3 single core CPU's could
show up some interresting corner cases in schedular code and
elsewhere, I'll bet we have some assumptions somewhere about
nr_of_cpus being an even number...

I would hope the N=1 case will have flushed out enough of those... :-|


Hehe, true, but I was thinking more of nr_of_cpus is an odd number > 1. :-)
Just thinking of having to divide things by 3 makes me worry ;-)  ...


It's not a hugely strange worry no. Grepping around (for num_online_cpus for 
example) didn't throw up any glaring bugs I believe.


A possible problem in mm/vmstat.c:calculate_threshold() where 3 CPUs would 
be treated as 2 through an fls(). No idea about that code and if that would 
be a problem.


The line just below where it does that _does_ seem to have a problem:

/*
 * Maximum threshold is 125
 */
threshold = min(125, threshold);

as either the comment or the code is wrong and it seems it's the code. Added 
Andrew Morton to the CC for that.


CFS (v19.1) has an ilog2 on num_online_cpus() in 
kernel/sched.c:sched_init_granularity() but this seems not a problem. Added 
Ingo Molnar.


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

Driver-level memory management

[Michael Bourgeous]

Hello everyone,

I'm working on a driver for older HDTV cards based on the TL880 chip.
These cards typically have 16MB of their own memory, which is
available to me over the PCI bus.  Various functions of the card
require me to manage this memory, allocating and freeing chunks of it
as necessary.  I can easily include my own allocation and management
code, but I'm sure this is a problem that has been solved before.
I've found two interesting sets of functions, the kmem_cache_* and
mempool_* functions, but neither does quite what I'm looking for.  So,
in a sentence, my question is this: Does the kernel provide memory
pool functions that would allow me to call the appropriate equivalent
of kmalloc/kfree, using the card's memory as the pool instead of
actually allocating physical or virtual memory?

By the way, I am not subscribed to the LKML, so please include my
address in any responses.

Thanks,
Mike Bourgeous
http://myhd.sf.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: Documentation files in html format?

[Randy Dunlap]

On Sat, 11 Aug 2007 16:17:19 +0200 Willy Tarreau wrote:

> On Sat, Aug 11, 2007 at 10:19:25AM -0400, J. Bruce Fields wrote:
> > On Fri, Aug 10, 2007 at 10:51:17PM +0200, Willy Tarreau wrote:
> > > The problem I have with asciidoc is that it's a nightmare to get it
> > > to work. It's what GIT uses, and after spending a whole day trying
> > > to *build* that thing, I finally resigned and asked Junio if he could
> > > publish the pre-formatted manpages himself, which he agreed to.
> > 
> > I wasn't actually suggesting we use the asciidoc tools--that's a
> > separate question.  We could ignore them, or wait till they solve
> > whatever problems they may have.
> > 
> > I was just suggesting that if we took your suggestion of standardizing
> > on plain text plus some conventions for formatting lists and headers and
> > such, one easy way to do that might just be to adopt the asciidoc format
> > (or some subset thereof).  Is there any part of the asciidoc *syntax*
> > that you object to?
> 
> Not particularly. It's just slightly less readable as plain text but
> OTOH produces nice documents when you have a working toolchain. But
> that's a language which needs to be learned, as every such language.
> Plain text on the contrary, requires no learning. The conventions are
> more like suggestions to newcomers. Everyone is free to proceed as he
> wants, judging by the result while writing the text.

[resend, sorry about duplicates]

but if we use something richer than plain text, I think that we
shouldn't need to invent yet another markup language.
Just use HTML or asciidoc or MarkDown etc...

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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: Documentation files in html format?

[Randy Dunlap]

On Fri, 10 Aug 2007 22:17:04 +0200 Willy Tarreau wrote:

> Hi Stephen,
> 
> On Thu, Aug 09, 2007 at 11:31:22AM +0100, Stephen Hemminger wrote:
> > Since the network device documentation needs a rewrite, I was thinking
> > of using basic html format instead of just plain text. But since this would
> > be starting an new precedent for kernel documentation, some it seemed
> > like a worthwhile topic for discussion.
> 
> I've read pro-plain text arguments, so I'll not repeat them. I also see
> another advantage to plain text : it's very easy to draw ascii-art
> diagrams of anything. It only takes a few minutes, is always inline
> and readable with any tool. Look at the bonding doc I wrote and updated
> in 2000, people have updated or duplicated some of the diagrams when
> they have added features. Something they would definitely not have done
> if it had required some strange tool.
> 
> Also, the advantage of plain text is that it stays compatible with
> everything though the years. Had I used some random tool in 2000 for
> this, I'm not sure the tool would still exist right now. Look at RFCs.

[resend, sorry about duplicates]

This is getting dangerously close to an XML discussion.  ;)

ISTM (from reading the IETF mailing list) that the recommended tools
for generating plaintext RFCs are either
a) xml2rfc (from http://tools.ietf.org/inventory/author-tools)
or
b) an MS Word plugin/macro/whatever.

There is also an xml RFC to pdf/ps converter here:
http://www.arkko.com/tools/xml2pdfrfc.html


> Nothing fancy, just readable. Even the TCP FSM in rfc793 from 26 years
> ago is readable, understandable, and updatable by anybody (though it's
> a little mit messy). And it's somewhat an extreme case ;-)
> 
> I'd prefer that you define some writing conventions for plain-text
> documents that anyone should try follow, starting with the 80-cols
> limit to make Davem happy. I think that many of us can help define
> such a "standard" indicating how to underline subtitles, how to
> enumerate a list, how to avoid using tabs, how to write boxes and
> arrows in their diagrams, etc...

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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: Documentation files in html format?

[Randy Dunlap]

On Fri, 10 Aug 2007 22:12:35 +0200 Sam Ravnborg wrote:

> > 
> > What primary requirements does in-tree Linux kernel documentation have
> > to fulfill in general?
> 
> Skipping the obvious ones such as correct, up-to-date etc.
> o Readable as-is
> o Grepable
> o buildable as structured documents or almost like a single book
> o Easy to replicate structure
> o Maintainable in any decent text-editor (emacs, vim, whatever)
> 
> > I've got a hunch that the most suitable format for Linux kernel
> > documentation, after careful consideration of what we want from it and
> > how we author and maintain it, will turn out to be...
> > 
> > ...plaintext.
> Asciidoc is quite close to plaintext and it looks to me that the
> formatting possibilities are quite good.
> 
> I spend an hour experimenting a little with
> Documentation/kbuild/makefiles.txt.

[resend, sorry about duplicates]

Hi Sam,

Sorry for the late question (I've been away :).

Was your makefiles.txt conversion done totally by hand?
Could it be automated?

or maybe there is not enough volume to even worry about that.

Yes, evaluating asciidoc has been on my radar (todo list) for
some time now.


> Diff below shows quite a lot of changes but for the most
> this is removal of the indent tab.
> Most likely I could have tweaked asciidoc to accept this
> but wanted to use default config.
> 
> The resulting html page can be seen here:
> http://www.ravnborg.org/kbuild/makefiles.html
> 
> Produced using:
> asciidoc -a toc -a numbered makefiles.txt
> 
> I would say that the asciidoc formatted plaintext text
> are readable despite the simple markup.
> And someone coming later will have no problems to follow
> the original markup.
> 
> Btw. is is not a full conversion, I stopped after a few chapters.
> asciidoc should be able to produce the index automatically
> but I had no luck but then I did not try hard either.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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] Re: cciss: warning: right shift count >= width of type

[Rene Herman]

On 08/12/2007 03:25 AM, Rene Herman wrote:


On 08/12/2007 02:56 AM, Jesper Juhl wrote:


(whoops, forgot to add maintainer to Cc - now added)


Ehm... too late...


Useless followup though -- hp.com rejects me as it feels the SPF neutral 
results gmail sends due to me not using the gmail SMTP server and/or web 
interface is something it wants to listen to.


I see you are @gmail as well, which depending on how you use it might mean 
your are also not able to reach @hp. If anyone can get HP to fix their mail 
setup, that'd be useful.


Rene.





On 12/08/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:

Hi,

I've been building some randconfig kernels lately and I've noticed
this in a few builds :

drivers/block/cciss.c:2614: warning: right shift count >= width of type
drivers/block/cciss.c:2615: warning: right shift count >= width of type
drivers/block/cciss.c:2616: warning: right shift count >= width of type

The code in question is this :

static void do_cciss_request(struct request_queue *q)
{
...
sector_t start_blk;
...
c->Request.CDB[2]= (start_blk >> 56) & 
0xff;//MSB

c->Request.CDB[3]= (start_blk >> 48) & 0xff;
c->Request.CDB[4]= (start_blk >> 40) & 0xff;
...
}


The problem stems from these lines in include/linux/types.h :
...
#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif
...

So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 
bits wide.

Thus it seems gcc is absolutely right in complaining about those
56, 48 & 40 bit shifts, since they are indeed wider than the type
in the "!CONFIG_LBD on a 32bit arch" case.


I must admit that I have no idear what the proper way to deal with
that is, so I'll just report it so hopefully someone else can fix it.

By the way; I'm building current Linus git tree, head at commit
ac07860264bd2b18834d3fa3be47032115524cea


Well, given that it's explicitly treating start_blk as a 64-bit value, 
the proper fix is probably to cast start_blk to an actual (guaranteed) 
64-bit value. Untested, uncompiled, and someone else may disagree:


Rene.



-
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: Are we properly prepared to handle 3 Socket setups?

[Jesper Juhl]

On 12/08/07, Rene Herman <[EMAIL PROTECTED]> wrote:
> On 08/12/2007 03:08 AM, Jesper Juhl wrote:
>
> > This may be a little off topic, but I think it's interresting enough
> > to warrent a single mail.
> >
> > I just saw a news article (http://www.theinquirer.net/?article=41610)
> > about a 3 Socket Opteron motherboard and couldn't help but wonder if
> > we are prepared to deal with such a beast, so I thought I'd inform
> > everyone :-)
> >
> > I'm guessing equipping such a board with 3 single core CPU's could
> > show up some interresting corner cases in schedular code and
> > elsewhere, I'll bet we have some assumptions somewhere about
> > nr_of_cpus being an even number...
>
> I would hope the N=1 case will have flushed out enough of those... :-|
>
Hehe, true, but I was thinking more of nr_of_cpus is an odd number > 1. :-)
Just thinking of having to divide things by 3 makes me worry ;-)  ...

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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] Re: cciss: warning: right shift count >= width of type

[Rene Herman]

On 08/12/2007 02:28 AM, Jesper Juhl wrote:

I've been building some randconfig kernels lately and I've noticed 
this in a few builds : 


drivers/block/cciss.c:2614: warning: right shift count >= width of type
drivers/block/cciss.c:2615: warning: right shift count >= width of type
drivers/block/cciss.c:2616: warning: right shift count >= width of type

The code in question is this : 


static void do_cciss_request(struct request_queue *q)
{
...
sector_t start_blk;
...
c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
c->Request.CDB[3]= (start_blk >> 48) & 0xff;
c->Request.CDB[4]= (start_blk >> 40) & 0xff;
...
}


The problem stems from these lines in include/linux/types.h : 
...

#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif
...

So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
Thus it seems gcc is absolutely right in complaining about those 
56, 48 & 40 bit shifts, since they are indeed wider than the type 
in the "!CONFIG_LBD on a 32bit arch" case.



I must admit that I have no idear what the proper way to deal with 
that is, so I'll just report it so hopefully someone else can fix it.


By the way; I'm building current Linus git tree, head at commit 
ac07860264bd2b18834d3fa3be47032115524cea


Well, given that it's explicitly treating start_blk as a 64-bit value, the 
proper fix is probably to cast start_blk to an actual (guaranteed) 64-bit 
value. Untested, uncompiled, and someone else may disagree:


Rene.
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 5acc6c4..fa2eec8 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
} else {
c->Request.CDBLen = 16;
c->Request.CDB[1]= 0;
-   c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
-   c->Request.CDB[3]= (start_blk >> 48) & 0xff;
-   c->Request.CDB[4]= (start_blk >> 40) & 0xff;
-   c->Request.CDB[5]= (start_blk >> 32) & 0xff;
-   c->Request.CDB[6]= (start_blk >> 24) & 0xff;
-   c->Request.CDB[7]= (start_blk >> 16) & 0xff;
-   c->Request.CDB[8]= (start_blk >>  8) & 0xff;
+   c->Request.CDB[2]= ((u64)start_blk >> 56) & 0xff;   
//MSB
+   c->Request.CDB[3]= ((u64)start_blk >> 48) & 0xff;
+   c->Request.CDB[4]= ((u64)start_blk >> 40) & 0xff;
+   c->Request.CDB[5]= ((u64)start_blk >> 32) & 0xff;
+   c->Request.CDB[6]= ((u64)start_blk >> 24) & 0xff;
+   c->Request.CDB[7]= ((u64)start_blk >> 16) & 0xff;
+   c->Request.CDB[8]= ((u64)start_blk >>  8) & 0xff;
c->Request.CDB[9]= start_blk & 0xff;
c->Request.CDB[10]= (creq->nr_sectors >>  24) & 0xff;
c->Request.CDB[11]= (creq->nr_sectors >>  16) & 0xff;

[PATCH] Re: cciss: warning: right shift count >= width of type

[Rene Herman]

On 08/12/2007 02:56 AM, Jesper Juhl wrote:


(whoops, forgot to add maintainer to Cc - now added)


Ehm... too late...


On 12/08/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:

Hi,

I've been building some randconfig kernels lately and I've noticed
this in a few builds :

drivers/block/cciss.c:2614: warning: right shift count >= width of type
drivers/block/cciss.c:2615: warning: right shift count >= width of type
drivers/block/cciss.c:2616: warning: right shift count >= width of type

The code in question is this :

static void do_cciss_request(struct request_queue *q)
{
...
sector_t start_blk;
...
c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
c->Request.CDB[3]= (start_blk >> 48) & 0xff;
c->Request.CDB[4]= (start_blk >> 40) & 0xff;
...
}


The problem stems from these lines in include/linux/types.h :
...
#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif
...

So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
Thus it seems gcc is absolutely right in complaining about those
56, 48 & 40 bit shifts, since they are indeed wider than the type
in the "!CONFIG_LBD on a 32bit arch" case.


I must admit that I have no idear what the proper way to deal with
that is, so I'll just report it so hopefully someone else can fix it.

By the way; I'm building current Linus git tree, head at commit
ac07860264bd2b18834d3fa3be47032115524cea


Well, given that it's explicitly treating start_blk as a 64-bit value, the 
proper fix is probably to cast start_blk to an actual (guaranteed) 64-bit 
value. Untested, uncompiled, and someone else may disagree:


Rene.
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 5acc6c4..fa2eec8 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
} else {
c->Request.CDBLen = 16;
c->Request.CDB[1]= 0;
-   c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
-   c->Request.CDB[3]= (start_blk >> 48) & 0xff;
-   c->Request.CDB[4]= (start_blk >> 40) & 0xff;
-   c->Request.CDB[5]= (start_blk >> 32) & 0xff;
-   c->Request.CDB[6]= (start_blk >> 24) & 0xff;
-   c->Request.CDB[7]= (start_blk >> 16) & 0xff;
-   c->Request.CDB[8]= (start_blk >>  8) & 0xff;
+   c->Request.CDB[2]= ((u64)start_blk >> 56) & 0xff;   
//MSB
+   c->Request.CDB[3]= ((u64)start_blk >> 48) & 0xff;
+   c->Request.CDB[4]= ((u64)start_blk >> 40) & 0xff;
+   c->Request.CDB[5]= ((u64)start_blk >> 32) & 0xff;
+   c->Request.CDB[6]= ((u64)start_blk >> 24) & 0xff;
+   c->Request.CDB[7]= ((u64)start_blk >> 16) & 0xff;
+   c->Request.CDB[8]= ((u64)start_blk >>  8) & 0xff;
c->Request.CDB[9]= start_blk & 0xff;
c->Request.CDB[10]= (creq->nr_sectors >>  24) & 0xff;
c->Request.CDB[11]= (creq->nr_sectors >>  16) & 0xff;

Re: Are we properly prepared to handle 3 Socket setups?

[Rene Herman]

On 08/12/2007 03:08 AM, Jesper Juhl wrote:


This may be a little off topic, but I think it's interresting enough
to warrent a single mail.

I just saw a news article (http://www.theinquirer.net/?article=41610)
about a 3 Socket Opteron motherboard and couldn't help but wonder if
we are prepared to deal with such a beast, so I thought I'd inform
everyone :-)

I'm guessing equipping such a board with 3 single core CPU's could
show up some interresting corner cases in schedular code and
elsewhere, I'll bet we have some assumptions somewhere about
nr_of_cpus being an even number...


I would hope the N=1 case will have flushed out enough of those... :-|

Rene.
-
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] Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Andi Kleen <[EMAIL PROTECTED]> wrote:

> Casey Schaufler <[EMAIL PROTECTED]> writes:
> 
> > Smack is the Simplified Mandatory Access Control Kernel.
> 
> I like the simplified part.
> 
> > +static int smk_get_access(smack_t sub, smack_t obj)
> > +{
> > +   struct smk_list_entry *sp = smack_list;
> > +
> > +   for (; sp != NULL; sp = sp->smk_next)
> > +   if (sp->smk_rule.smk_subject == sub &&
> > +   sp->smk_rule.smk_object == obj)
> > +   return sp->smk_rule.smk_access;
> 
> Do I miss something, or is there really no locking for the reader side
> of the list? That looks dangerous. Of course a global lock for readers 
> would be likely a scaling disaster. You could use RCU.

Entries are never deleted, although they can be modified.

> Or if you assume rules are changed only very infrequently it might
> be more cache friendly to compile all the rules into a linear buffer
> and then just replace the whole buffer atomically with a RCU
> grace period on cahnges.

Individual entries can be modified without changing the whole
thing, but they shouldn't change often.

> It doesn't look like it would scale to larger numbers of rules though.
> Is that intended? Would caching of decisions fit into the design?

I put some thought into clever schemes for supporting large rule sets
well but decided to go ahead with the simplest possible mechanism
because I expect that in real deployments the number of rules will
be small. In fact, experiance says that virtually all access choices
will be covered either by the subject==object case or the subject can
read floor case. Cacheing, hashing, and 2D structures are all
possibilties that I would be happy to entertain as enhancements.

> Also in general code style would need some improvements;
> e.g. no externs in .c; no ../.. include hacks etc.
> You also seem weak on the Documentation front.

Yes, it is pretty sparse.

> Other than that it looks reasonably clean (haven't read all of it)

Thank you for your comments. I think the next version will be improved.


Casey Schaufler
[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: [PATCH] Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Kyle Moffett <[EMAIL PROTECTED]> wrote:

> On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
> >> [SELinux...] which can do *all* of this, completely and without  
> >> exceptions,
> >
> > That's quite a strong assertion.
> 
> It is, but I stand by it.  If anyone can point out some portion of  
> this which *cannot* be implemented as SELinux policy I will humbly  
> step completely out of this discussion.

Ok. I accept that you believe that this.

> >> but one does have to have complexity in order to handle everything  
> >> from CD burning in X, to Apache daemons, to only allowing Top- 
> >> Secret-level logins over the IPsec tunnel on the Top Secret  
> >> network, etc.
> >
> > I do not agree with you. The MLS systems from the 1990's could do  
> > all that (except the IPsec tunnel, the function of which was  
> > preceeded by TSIG interfaces and protocols) without the complexity  
> > required by SELinux policy.
> 
> No, most/all of the MLS systems from the 1990s did not integrate Bell- 
> LaPadula, Type Enforcement, and Role-Based-Access-Control together.

Err, that wasn't the claim I was refuting. I was refuting the claim
that performing those actions required complexity. The claim I was
refering to said nothing about any of those features or anything about
their integration.

> In addition, none of the MLS systems from the 1990s had modifiable  
> constraints the way SELinux does (for example I can modify the  
> fundamental policy to allow a process whose domain has the  
> "i_am_special" attribute to override the BLP model for certain target  
> types in certain special situations, all depending on how I apply  
> that attribute and those types).

That's fine, but hardly relevent to the fact that the 1990's systems
performed the list of functions.
 
> >> For  example, this set of rules basically defines your described  
> >> "read-vs-write-vs-exec" policy as best I can figure out:
> >>
> >> user uu roles rr;
> >>
> >> role rr types { star floor hat huh };
> >>
> >> define(`r',`
> >> allow $1 $2:file { read getattr };
> >> allow $1 $2:socket { read getattr getopt recvfrom recv_msg };
> >> allow $1 $2:ipc { getattr read associate unix_read };
> >> ## List of more "read" allow rules for different types of  
> >> objects... ##
> >> ')
> >
> > It would be instructive for those who are not well versed in the  
> > nuances of SELinux policy if you actually spelled out the whole  
> > thing, rather than using "## and more ##". Part of the point of  
> > Smack is the makeup of the full list that would be required here.
> 
> Well, yes, but how exactly do you define "read", "write", and  
> "execute" for the full list of SELinux object classes found here:
> http://www.tresys.com/selinux/obj_perms_help.html

Smack is designed to treat objects as consistantly as is reasonable.
The list of object classes defined by SELinux is great for a system
designed to treat accesses with the highest possible granularity.
This is not a design goal for Smack.

> I was considering compiling the complete list, but such an exercise  
> would take me at least an hour to do properly and which categories  
> individual permissions should be placed in could be argued for  
> weeks. 

I will be happy to consider your arguement when you are willing
to present the complete argument.

> The SELinux reference policy doesn't even completely qualify  
> all of those things with MLS restrictions, and they're the ones who  
> got the hooks implemented originally.

That doesn't help your case any.

> Specifically, do you classify the bind() syscall as a "read" or a  
> "write" operation.

Neither. Bind attaches a name (port number) to a socket (which is a
data structure that is part of your process) from a global namespace.
No objects are involved, hence no accesses.

> How would you classify accept()?

I don't. Accept happens after a TCP connection has been established.
The access control is all mediated long before the accept'er finds
out about it.

> In order to  
> support the full range of security controls that Linux has hooks for,  
> you would need to identify a list of how to define "read", "write",  
> and "execute" for every object-class in that massive list.   
> Furthermore you would need to ensure that the definitions work for  
> every process.  From the variations between different portions of the  
> SELinux ref policy, I contend that there is no single definition of  
> "read", or "write" which works for all usages of a given object-class.

There certainly isn't in SELinux. I don't subscribe the the list
of SELinux object classes. We can argue a long time over whether a
socket is an object or not, and it won't help any real world application
one bit.

> >> And now to describe these rules:
> >>
> >>> Smack defines and uses these labels:
> >>>   "*" - pronounced "star"
> >>>   "_" - pronounced "floor"
> >>>   "^" - pronounced "hat"
> >>>   "?" - pronounced "huh"
> >>>
> >>> The access rules enforced by Smack are, in or

Are we properly prepared to handle 3 Socket setups?

[Jesper Juhl]

Hi,

This may be a little off topic, but I think it's interresting enough
to warrent a single mail.

I just saw a news article (http://www.theinquirer.net/?article=41610)
about a 3 Socket Opteron motherboard and couldn't help but wonder if
we are prepared to deal with such a beast, so I thought I'd inform
everyone :-)

I'm guessing equipping such a board with 3 single core CPU's could
show up some interresting corner cases in schedular code and
elsewhere, I'll bet we have some assumptions somewhere about
nr_of_cpus being an even number... In any case it would be an
interresting box to test on, so for those of you employed by big
business with the cash to purchase a test box, it would at least be an
interresting one to add to the mix :)

Anyway, just wanted to give everyone a heads-up, bye bye...

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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: cciss: warning: right shift count >= width of type

[Jesper Juhl]

(whoops, forgot to add maintainer to Cc - now added)

On 12/08/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've been building some randconfig kernels lately and I've noticed
> this in a few builds :
>
> drivers/block/cciss.c:2614: warning: right shift count >= width of type
> drivers/block/cciss.c:2615: warning: right shift count >= width of type
> drivers/block/cciss.c:2616: warning: right shift count >= width of type
>
> The code in question is this :
>
> static void do_cciss_request(struct request_queue *q)
> {
> ...
> sector_t start_blk;
> ...
> c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
> c->Request.CDB[3]= (start_blk >> 48) & 0xff;
> c->Request.CDB[4]= (start_blk >> 40) & 0xff;
> ...
> }
>
>
> The problem stems from these lines in include/linux/types.h :
> ...
> #ifdef CONFIG_LBD
> typedef u64 sector_t;
> #else
> typedef unsigned long sector_t;
> #endif
> ...
>
> So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
> Thus it seems gcc is absolutely right in complaining about those
> 56, 48 & 40 bit shifts, since they are indeed wider than the type
> in the "!CONFIG_LBD on a 32bit arch" case.
>
>
> I must admit that I have no idear what the proper way to deal with
> that is, so I'll just report it so hopefully someone else can fix it.
>
> By the way; I'm building current Linus git tree, head at commit
> ac07860264bd2b18834d3fa3be47032115524cea
>
>
> Kind regards,
>   Jesper Juhl
>
>
>


-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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/

cciss: warning: right shift count >= width of type

[Jesper Juhl]

Hi,

I've been building some randconfig kernels lately and I've noticed 
this in a few builds : 

drivers/block/cciss.c:2614: warning: right shift count >= width of type
drivers/block/cciss.c:2615: warning: right shift count >= width of type
drivers/block/cciss.c:2616: warning: right shift count >= width of type

The code in question is this : 

static void do_cciss_request(struct request_queue *q)
{
...
sector_t start_blk;
...
c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
c->Request.CDB[3]= (start_blk >> 48) & 0xff;
c->Request.CDB[4]= (start_blk >> 40) & 0xff;
...
}


The problem stems from these lines in include/linux/types.h : 
...
#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif
...

So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
Thus it seems gcc is absolutely right in complaining about those 
56, 48 & 40 bit shifts, since they are indeed wider than the type 
in the "!CONFIG_LBD on a 32bit arch" case.


I must admit that I have no idear what the proper way to deal with 
that is, so I'll just report it so hopefully someone else can fix it.

By the way; I'm building current Linus git tree, head at commit 
ac07860264bd2b18834d3fa3be47032115524cea


Kind regards,
  Jesper Juhl


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

mtd: build failure in drivers/mtd/chips/chipreg.c / include/linux/mtd/map.h

[Jesper Juhl]

Trying to build current Linus git tree (head at 
ac07860264bd2b18834d3fa3be47032115524cea) using the attached config 
file (generated by 'make randconfig') the build fails for me with : 

...
  CC  drivers/mtd/chips/chipreg.o
In file included from drivers/mtd/chips/chipreg.c:13:
include/linux/mtd/map.h:128:2: error: #error "No bus width supported. What's 
the point?"
In file included from drivers/mtd/chips/chipreg.c:13:
include/linux/mtd/map.h:162: error: 'MAX_MAP_BANKWIDTH' undeclared here (not in 
a function)
include/linux/mtd/map.h: In function 'map_word_equal':
include/linux/mtd/map.h:249: error: implicit declaration of function 'map_words'
include/linux/mtd/map.h: In function 'map_word_load':
include/linux/mtd/map.h:316: error: implicit declaration of function 
'map_bankwidth_is_large'
include/linux/mtd/map.h: In function 'map_word_ff':
include/linux/mtd/map.h:355: error: implicit declaration of function 
'map_bankwidth'
make[3]: *** [drivers/mtd/chips/chipreg.o] Error 1
make[2]: *** [drivers/mtd/chips] Error 2
make[1]: *** [drivers/mtd] Error 2
make: *** [drivers] Error 2


This is on a Slackware Linux 12.0 system with the following 
environment : 

$ scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux dragon 2.6.22-g1db6178c #1 SMP PREEMPT Sat Jul 14 04:10:50 CEST 2007 i686 
AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux

Gnu C  4.1.2
Gnu make   3.81
binutils   Binutils
util-linux 2.12r
mount  2.12r
module-init-tools  3.2.2
e2fsprogs  1.39
jfsutils   1.1.11
reiserfsprogs  3.6.19
xfsprogs   2.8.16
pcmciautils014
quota-tools3.13.
PPP2.4.4
Linux C Library2.5
Dynamic linker (ldd)   2.5
Linux C++ Library  6.0.8
Procps 3.2.7
Net-tools  1.60
Kbd1.12
oprofile   0.9.2
Sh-utils   6.9
udev   111
Modules Loaded snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss 
snd_mixer_oss lp snd_emu10k1 snd_rawmidi firmware_class snd_ac97_codec nvidia 
ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem agpgart 
sg snd_hwdep evdev ehci_hcd via_rhine k8temp

I've also attached a complete build log. If you need any further details, just 
ask.


Kind regards,
  Jesper Juhl




config.70.gz
Description: GNU Zip compressed data


build.log.70.gz
Description: GNU Zip compressed data

mtd: build failure - error: implicit declaration of function 'cfi_interleave'

[Jesper Juhl]

Trying to build current Linus git tree (head at 
ac07860264bd2b18834d3fa3be47032115524cea) using the attached config 
file (generated by 'make randconfig') the build fails for me with : 

...
  CC  drivers/mtd/rfd_ftl.o
  CC  drivers/mtd/chips/chipreg.o
  CC  drivers/mtd/chips/cfi_probe.o
In file included from drivers/mtd/chips/cfi_probe.c:19:
include/linux/mtd/cfi.h: In function 'cfi_build_cmd':
include/linux/mtd/cfi.h:293: error: implicit declaration of function 
'cfi_interleave'
make[3]: *** [drivers/mtd/chips/cfi_probe.o] Error 1
make[2]: *** [drivers/mtd/chips] Error 2
make[1]: *** [drivers/mtd] Error 2
make: *** [drivers] Error 2


This is on a Slackware Linux 12.0 system with the following 
environment : 

$ scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux dragon 2.6.22-g1db6178c #1 SMP PREEMPT Sat Jul 14 04:10:50 CEST 2007 i686 
AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux

Gnu C  4.1.2
Gnu make   3.81
binutils   Binutils
util-linux 2.12r
mount  2.12r
module-init-tools  3.2.2
e2fsprogs  1.39
jfsutils   1.1.11
reiserfsprogs  3.6.19
xfsprogs   2.8.16
pcmciautils014
quota-tools3.13.
PPP2.4.4
Linux C Library2.5
Dynamic linker (ldd)   2.5
Linux C++ Library  6.0.8
Procps 3.2.7
Net-tools  1.60
Kbd1.12
oprofile   0.9.2
Sh-utils   6.9
udev   111
Modules Loaded snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss 
snd_mixer_oss lp snd_emu10k1 snd_rawmidi firmware_class snd_ac97_codec nvidia 
ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem agpgart 
sg snd_hwdep evdev ehci_hcd via_rhine k8temp

I've also attached a complete build log. If you need any further details, just 
ask.


Kind regards,
  Jesper Juhl




build.log.55.gz
Description: GNU Zip compressed data


config.55.gz
Description: GNU Zip compressed data

Build failure in advansys driver - error: implicit declaration of function 'to_pci_dev'

[Jesper Juhl]

Trying to build current Linus git tree (head at 
ac07860264bd2b18834d3fa3be47032115524cea) using the attached config 
file (generated by 'make randconfig') the build fails for me with : 

...
  CC  drivers/scsi/advansys.o
drivers/scsi/advansys.c:794:2: warning: #warning this driver is still not 
properly converted to the DMA API
drivers/scsi/advansys.c: In function 'advansys_board_found':
drivers/scsi/advansys.c:17781: error: implicit declaration of function 
'to_pci_dev'
drivers/scsi/advansys.c:17781: warning: pointer/integer type mismatch in 
conditional expression
drivers/scsi/advansys.c:17788: warning: unused variable 'pci_memory_address'
drivers/scsi/advansys.c:17781: warning: unused variable 'pdev'
make[2]: *** [drivers/scsi/advansys.o] Error 1
make[1]: *** [drivers/scsi] Error 2
make: *** [drivers] Error 2

This is on a Slackware Linux 12.0 system with the following 
environment : 

$ scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux dragon 2.6.22-g1db6178c #1 SMP PREEMPT Sat Jul 14 04:10:50 CEST 2007 i686 
AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux

Gnu C  4.1.2
Gnu make   3.81
binutils   Binutils
util-linux 2.12r
mount  2.12r
module-init-tools  3.2.2
e2fsprogs  1.39
jfsutils   1.1.11
reiserfsprogs  3.6.19
xfsprogs   2.8.16
pcmciautils014
quota-tools3.13.
PPP2.4.4
Linux C Library2.5
Dynamic linker (ldd)   2.5
Linux C++ Library  6.0.8
Procps 3.2.7
Net-tools  1.60
Kbd1.12
oprofile   0.9.2
Sh-utils   6.9
udev   111
Modules Loaded snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss 
snd_mixer_oss lp snd_emu10k1 snd_rawmidi firmware_class snd_ac97_codec nvidia 
ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem agpgart 
sg snd_hwdep evdev ehci_hcd via_rhine k8temp

I've also attached a complete build log. If you need any further details, just 
ask.


Kind regards,
  Jesper Juhl




config.24.gz
Description: GNU Zip compressed data


build.log.24.gz
Description: GNU Zip compressed data

Re: encrypted hibernation (was Re: Hibernation considerations)

[Dr. David Alan Gilbert]

* Pavel Machek ([EMAIL PROTECTED]) wrote:
> Hi!
> 
> > > > Two things which I think would be nice to consider are:
> > > >1) Encryption - I'd actually prefer if my luks device did not
> > > >remember the key accross a hibernation; I want to be forced to
> > > >reenter the phrase.  However I don't know what the best thing
> > > >to do to partitions/applications using the luks device is.
> > > 
> > > Encryption is possible with both the userland hibernation (aka uswsusp) 
> > > and
> > > TuxOnIce (formerly known as suspend2).  Still, I don't consider it as a 
> > > "must
> > > have" feature for a framework to be generally useful (many users don't 
> > > use it
> > > anyway).
> > 
> > If a user uses an encrypted filesystem, then he also needs an encrypted
> > swap and encrypted hibernation image: Otherwise the fileystem encryption
> > is not very useful.
> 
> Actually, we can do most of that stuff already. 
> 
> We can encrypt filesystems, encrypt swaps (LVM), and encrypt hibernation.

But can you do what my original question was; find a way to lose a luks
encrypted device key and cleanly unmount the filesystem that was
using it?  (and preferably put it all back together after resume).

Dave
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.org   |___/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: two questions about the boot_delay

[Randy Dunlap]

On Wed, 8 Aug 2007 07:39:33 + Dave Young wrote:

> Hi,
> I have tried the "slow down printk" , and I have two questions.
> 
> 1. why it depends the DEBUG_KERNEL? Sometimes we only need boot_delay
> to see the printk infomations.  How about set it as a standalone
> config option?

Is depending on DEBUG_KERNEL a problem?  If so, why?

It sure seems like a kernel debug option to me, although
I have no strong preference pro or con on this.

> 2. In My system if I boot with boot_delay=200 the early part of
> booting will be very slow, eapecially at the very beginning (after the
> compressing  and start kernel, it nearly stop here many minutes).
> 
> And I wonder if we can simply use mdelay in the boot_delay_msec(). I
> tested the mdelay , and the result is more accurate.

I wasn't convinced that loops_per_jiffy was always set for all
architectures that early during boot.  Did you audit and verify that
it is set early enough to use during boot_delay_msec()?
and if so, for all architectures?
What architectures did you test this on?


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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] Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Jan Engelhardt <[EMAIL PROTECTED]> wrote:

> 
> On Aug 11 2007 10:57, Casey Schaufler wrote:
> >
> >"*" - pronounced "star"
> wall
> >"_" - pronounced "floor"
> floor
> >"^" - pronounced "hat"
> roof
> >"?" - pronounced "huh"
> it's dark in here :)

It's almost worth considering the change for the joke. Almost.

> >+config SECURITY_SMACK
> >+bool "Simplified Mandatory Access Control Kernel Support"
> >+depends on NETLABEL && SECURITY_NETWORK
> 
> Is this a hard dependency, or can this work without network sec labels?

Smack uses netlabel to communicate label information even locally.
Without this only processes running with the ambient label would
be able to use sockets.

> >+default n
> >+help
> >+  This selects the Simplified Mandatory Access Control Kernel.
> >+  SMACK is useful for sensitivity, integrity, and a variety
> >+  of other madatory security schemes.
> >+  If you are unsure how to answer this question, answer N.
> 
> I smell broken tabs.

Yup. Fixed.
 
> >+++ linux-2.6.22/security/smack/Makefile 2007-07-10 01:08:05.0 
> >-0700
> >@@ -0,0 +1,8 @@
> >+#
> >+# Makefile for the SMACK LSM
> >+#
> >+
> >+obj-$(CONFIG_SECURITY_SMACK) := smack.o
> >+
> >+smack-y := smack_lsm.o smack_access.o smackfs.o
> 
> smack-objs :=

Added.

> >+++ linux-2.6.22/security/smack/smack_access.c   2007-07-24 
> >15:36:18.0
> -0700
> >@@ -0,0 +1,113 @@
> >+extern struct smk_list_entry *smack_list;
> >+
> >+static int smk_get_access(smack_t sub, smack_t obj)
> >+{
> >+struct smk_list_entry *sp = smack_list;
> 
> proposes const struct. should be used elsewhere too.

I've hit a few places.

> >+if (sub == SMK_STAR)
> 
> I just remember MechWarrior2 (game from Activison), where SMK stood for their
> movie format... it's also a nice abbreviation for Seamonkey (browser suite).

Err, yeah. Okay.

> >+if (sub == SMK_HAT && ((request & MAY_ANYREAD) == request))
> >+return 0;
> >+
> >+if (obj == SMK_FLOOR && ((request & MAY_ANYREAD) == request))
> >+return 0;
> 
> Redundant parentheses, be gone.

Done.

> Never was it easier to say what ^ is called in your language :)
> 
>   if (sub == '^' && ...)
>   return 0;
>   if (obj == '_' && ...)
>
> >+/*
> >+ * The value that this adds is that everything after any
> >+ * character that's not allowed in a smack will be null
> >+ */
> >+smack_t smk_from_string(char *str)
> >+{
> >+smack_t smack = 0LL;
> 
> "smack_t smack = 0;" is enough here.

Ok.

> >+char *cp;
> >+int i;
> >+
> >+for (cp = (char *)&smack, i = 0; i < sizeof(smack_t); str++,cp++,i++) {
> 
> Whatever it tries to do, this is not endian-safe. Except if @str
> actually points to another smack_t. Yuck.

Small string stuck in a large integer. The only operation is
comparison. Big or little endian the string will come out right,
and that's what's important.

> >+if (*str <= ' ' || *str > '~')
> >+return smack;
> >+*cp = *str;
> >+}
> >+/*
> >+ * Too long.
> >+ */
> >+return SMK_INVALID;
> >+}
> >diff -uprN -X linux-2.6.22-base/Documentation/dontdiff
> linux-2.6.22-base/security/smack/smackfs.c
> linux-2.6.22/security/smack/smackfs.c
> >--- linux-2.6.22-base/security/smack/smackfs.c   1969-12-31 
> >16:00:00.0
> -0800
> >+++ linux-2.6.22/security/smack/smackfs.c2007-07-24 21:51:30.0
> -0700
> 
> Can't securityfs and/or sysfs be used?

I have to look into that for the configuration values. I don't
think I can do it for the symlinks.

> >+enum smk_inos {
> >+SMK_ROOT_INO =  2,
> >+SMK_LOAD =  3,  /* load policy */
> >+SMK_LINKS = 4,  /* symlinks */
> >+SMK_CIPSO = 5,  /* load label -> CIPSO mapping */
> >+SMK_DOI =   6,  /* CIPSO DOI */
> >+SMK_DIRECT =7,  /* CIPSO level indicating direct label */
> >+SMK_AMBIENT =   8,  /* internet ambient label */
> >+SMK_NLTYPE =9,  /* label scheme to use by default */
> >+SMK_TMP =   100,/* MUST BE LAST! /smack/tmp */
> >+};
> 
> Generally, =s are aligned too.

It's pretty inconsistant, but that's what I prefer, too. I'll do it.

> >+static struct smk_cipso_entry smack_cipso_floor = {
> >+.smk_next = NULL,
> >+.smk_smack = SMK_FLOOR,
> >+.smk_level = 0,
> >+.smk_catset = 0LL,
> >+};
> 
> const me.

This is the correct tinitial value, but could be changed.

> >+/*
> >+ * '  \n\0' 
> >+ */
> 
> I wonder why it's limited to 8 characters? Ah right.. sizeof(smack_t).
> uhm.. are you trying to tell me that smack_t [typedef'ed to u64]
> are actually meant as a char[8]? (/me scrathces head)

Yes. "s == o" vs "strcmp(s,o) == 0".

> >+for (cp = result; slp != NULL; slp = slp->smk_next) {
> >+srp = &slp->smk_rule;
> >+sprintf(cp, "%-8s %-8s",
> >+(char *)&srp->smk_subject,

Re: [PATCH 00/23] per device dirty throttling -v8

[Valerie Henson]

On Wed, Aug 08, 2007 at 05:54:57PM -0700, Martin Bligh wrote:
> Andrew Morton wrote:
> >On Wed, 08 Aug 2007 14:10:15 -0700
> >"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
> >
> >>Why isn't this easily fixable by just adding an additional dirty
> >>flag that says atime has changed? Then we only cause a write
> >>when we remove the inode from the inode cache, if only atime
> >>is updated.
> >
> >I think that could be made to work, and it would fix the performance
> >issue.
> >
> >It is a behaviour change.  At present ext3 (for example) commits everything
> >every five seconds.  After a change like this, a crash+recovery could cause
> >a file's atime to go backwards by an arbitrarily large time interval - it
> >could easily be months.
> 
> A second pdflush / workqueue at a slower rate would alleviate that.

This becomes delayed atime writes.  I'm not sure that it's better to
batch up the writes and do them all in one big seeky go, or to trickle
them out as they are done.  Best of all is not to do them at all.

Note when talking about saving up atime updates to write out that the
final write is going to be sloow.  Inodes are typically 128 bytes,
and you may have to do a seek between every one.  Currents disks can
do on the order of 100 seeks a second.  So do a find on 1000 files and
you've just created 10 seconds of I/O hanging out in memory.

-VAL
-
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 5/5] Add a 00-INDEX file to Documentation/watchdog/

[Jesper Juhl]

Add a 00-INDEX file to Documentation/watchdog/


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 00-INDEX |   10 ++
 1 file changed, 10 insertions(+)

--- /dev/null   2005-11-21 04:22:37.0 +0100
+++ linux-2.6/Documentation/watchdog/00-INDEX   2007-08-12 00:06:01.0 
+0200
@@ -0,0 +1,10 @@
+00-INDEX
+   - this file.
+pcwd-watchdog.txt
+   - documentation for Berkshire Products PC Watchdog ISA cards.
+src/
+   - directory holding watchdog related example programs.
+watchdog-api.txt
+   - description of the Linux Watchdog driver API.
+wdt.txt
+   - description of the Watchdog Timer Interfaces for Linux.



-
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 4/5] Add a 00-INDEX file to Documentation/telephony/

[Jesper Juhl]

Add a 00-INDEX file to Documentation/telephony/


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 00-INDEX |4 
 1 file changed, 4 insertions(+)

--- /dev/null   2005-11-21 04:22:37.0 +0100
+++ linux-2.6/Documentation/telephony/00-INDEX  2007-08-11 23:55:54.0 
+0200
@@ -0,0 +1,4 @@
+00-INDEX
+   - this file.
+ixj.txt
+   - document describing the Quicknet drivers.



-
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 3/5] Add a 00-INDEX file to Documentation/sysctl/

[Jesper Juhl]

Add a 00-INDEX file to Documentation/sysctl/


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 00-INDEX |   16 
 1 file changed, 16 insertions(+)

--- /dev/null   2005-11-21 04:22:37.0 +0100
+++ linux-2.6/Documentation/sysctl/00-INDEX 2007-08-11 23:52:50.0 
+0200
@@ -0,0 +1,16 @@
+00-INDEX
+   - this file.
+README
+   - general information about /proc/sys/ sysctl files.
+abi.txt
+   - documentation for /proc/sys/abi/*.
+ctl_unnumbered.txt
+   - explanation of why one should not add new binary sysctl numbers.
+fs.txt
+   - documentation for /proc/sys/fs/*.
+kernel.txt
+   - documentation for /proc/sys/kernel/*.
+sunrpc.txt
+   - documentation for /proc/sys/sunrpc/*.
+vm.txt
+   - documentation for /proc/sys/vm/*.



-
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 2/5] Add a 00-INDEX file to Documentation/mips/

[Jesper Juhl]

Add a 00-INDEX file to Documentation/mips/


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 00-INDEX |8 
 1 file changed, 8 insertions(+)

--- /dev/null   2005-11-21 04:22:37.0 +0100
+++ linux-2.6/Documentation/mips/00-INDEX   2007-08-11 22:56:26.0 
+0200
@@ -0,0 +1,8 @@
+00-INDEX
+   - this file.
+AU1xxx_IDE.README
+   - README for MIPS AU1XXX IDE driver.
+GT64120.README
+   - README for dir with info on MIPS boards using GT-64120 or GT-64120A.
+time.README
+   - README for MIPS time services.



-
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 0/5] Add some missing Documentation/*/00-INDEX files

[Jesper Juhl]

Hi,

Rob Landley is trying to organize Linux kernel documentation. One 
thing he is doing is generating index.html files based on our 
00-INDEX files in the Documentation directory. He has met with a 
small problem however, since not all subdirectories inside 
Documentation contain such a file, nor are all the files that do 
exist up to date, his index.html files turn up rather incomplete.

In a reply to a recent post to linux-doc, where Rob also posted his 
script for generating the index.html files, I offered to help out 
with that situation and create (at least some of) the missing 
00-INDEX files. These patches represent the first five files I've 
created.
The reason I'm not submitting more files at this time is simply 
that I want to get some feedback before wasting too much time 
creating these files if it turns out that for some reason they are 
not wanted. This is also the reason why I'm cross posting to LKML 
at this time, since I suspect that not very many people currently 
read linux-doc.

So please do the ACK/NACK/Merge dance with these patches and 
let me know if more are wanted or not. :-)


Kind regards,
  Jesper Juhl <[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/

[PATCH 1/5] Add a 00-INDEX file to Documentation/auxdisplay/

[Jesper Juhl]

Add a 00-INDEX file to Documentation/auxdisplay/


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 00-INDEX |8 
 1 file changed, 8 insertions(+)

--- /dev/null   2005-11-21 04:22:37.0 +0100
+++ linux-2.6/Documentation/auxdisplay/00-INDEX 2007-08-11 23:58:49.0 
+0200
@@ -0,0 +1,8 @@
+00-INDEX
+   - this file.
+cfag12864b
+   - documentation for the cfag12864b LCD driver.
+cfag12864b-example.c
+   - cfag12864b LCD userspace example program.
+ks0108
+   - documentation for the ks0108 LCD controller driver.


-
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] Smack: Simplified Mandatory Access Control Kernel

[Andi Kleen]

Casey Schaufler <[EMAIL PROTECTED]> writes:

> Smack is the Simplified Mandatory Access Control Kernel.

I like the simplified part.

> +static int smk_get_access(smack_t sub, smack_t obj)
> +{
> + struct smk_list_entry *sp = smack_list;
> +
> + for (; sp != NULL; sp = sp->smk_next)
> + if (sp->smk_rule.smk_subject == sub &&
> + sp->smk_rule.smk_object == obj)
> + return sp->smk_rule.smk_access;

Do I miss something, or is there really no locking for the reader side
of the list? That looks dangerous. Of course a global lock for readers 
would be likely a scaling disaster. You could use RCU.

Or if you assume rules are changed only very infrequently it might
be more cache friendly to compile all the rules into a linear buffer
and then just replace the whole buffer atomically with a RCU
grace period on cahnges.

It doesn't look like it would scale to larger numbers of rules though.
Is that intended? Would caching of decisions fit into the design?

Also in general code style would need some improvements;
e.g. no externs in .c; no ../.. include hacks etc.
You also seem weak on the Documentation front.
Other than that it looks reasonably clean (haven't read all of it)

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

Re: [PATCH 3/3] ACPI: thinkpad-acpi: change thinkpad-acpi input default and kconfig help

[Henrique de Moraes Holschuh]

On Sat, 11 Aug 2007, Michael S. Tsirkin wrote:
> > Quoting Henrique de Moraes Holschuh <[EMAIL PROTECTED]>:
> > Subject: [PATCH 3/3] ACPI: thinkpad-acpi: change thinkpad-acpi input 
> > default and kconfig help
> > 
> > The current kconfig help text was misleading users.  Also, the default for
> > an input-layer-optimized support caused way too many problems without
> > up-to-date userspace in place.
> > 
> > So, rework the help text, and change the default to N.  Note that
> > distributions are supposed to enable this option as soon as they update HAL
> > to a version that handles the thinkpad-acpi new input layer interface.
> 
> I don't really know the details here, so I could be completely wrong.

You can get up to speed through the archives of the ibm-acpi-devel
mailinglist at sourceforge.net (or gmane.org).

> However, generally, forcing HAL and kernel to be in sync really
> looks to me like a non-ideal way to handle interface change.

True.  But so far I didn't find any better way.  Sending hot key events over
the input layer and as an ACPI event at the same time is bound to cause
problems that are not that easy to work around, while configuring the driver
to send one of the two will always work, and autodetecting which channel to
use to deliver events is basically impossible (HAL, for example, always
opens the ACPI event sink, AND all input devices that issue EV_KEY).

I *can* make the compile-time option a module parameter, though.  That
wouldn't be much of a problem, and the compile-time option would select the
default for that parameter, but it would be easier to override it at run
time (you can already do it, but it requires reprogramming various driver
parameters using sysfs and the input device IOCTLs).

Would a module parameter address enough of your concerns?  Kconfig would
only set the default for that parameter, then...

> For example, this would mean that one can't use the same kernel
> for multiple distributions, and for a person like me
> that needs to switch distros all the time, it seems like a pain.

Setup the driver at boot time, then.  You can change its behaviour through
sysfs and some utility that can reprogram an input layer device keymap.  Or,
if I add a module parameter that duplicates the compile-time parameter, you
just need to use the module parameter.

> Could not the kernel expose both new and old interfaces
> somehow, so that HAL can be updated without recompiling the kernel?

It exposes all interfaces, all the time.  But you have to configure their
behaviour, and since you can't have both active at the same time, you need
to cause the driver to use the one your userland expects.

Also, there is a matter of the default of the hot key functionality (enabled
or disabled, and its masks) which used not to matter much as the driver was
basically useless without a lot configuration from userspace, but that is
not true anymore when dealing with input devices.

> For example, there could be a sysfs interface which let the HAL set
> the desired interface version.

HAL already can do that if it wants.  However, driver autodetection
information is lost when the input device is not enabled by default (you
lose the autodetected keymap).

This could be fixed by selecting whether to send events over ACPI or the
input device in a different way (but I found no better compromise than the
one I used.  Suggestions?).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
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] Re: 2.6.23-rc2-mm2: sata disk going slow

[Hugh Dickins]

Why is the G5 so slow with 2.6.23-rc2-mm2?  hdparm -t shows 1.8MB/sec
instead of 58MB/sec.  alpm-increase-number-of-allowable-device-flags.patch
(raising ATA_DFLAG_CFG_MASK) turns out to be the guilty party: though the
problem doesn't appear until the next patch, which adds ATA_DFLAG_IPM as
the same bit as ATA_DFLAG_PIO.  Here's a hotfix against top of -rc2-mm2.

Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
---

 include/linux/libata.h |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- 2.6.23-rc2-mm2/include/linux/libata.h   2007-08-10 12:14:36.0 
+0100
+++ linux/include/linux/libata.h2007-08-11 20:21:59.0 +0100
@@ -143,9 +143,9 @@ enum {
ATA_DFLAG_IPM   = (1 << 8), /* device supports IPM */
ATA_DFLAG_CFG_MASK  = (1 << 12) - 1,
 
-   ATA_DFLAG_PIO   = (1 << 8), /* device limited to PIO mode */
-   ATA_DFLAG_NCQ_OFF   = (1 << 9), /* device limited to non-NCQ mode */
-   ATA_DFLAG_SPUNDOWN  = (1 << 10), /* XXX: for spindown_compat */
+   ATA_DFLAG_PIO   = (1 << 12), /* device limited to PIO mode */
+   ATA_DFLAG_NCQ_OFF   = (1 << 13), /* device limited to non-NCQ mode 
*/
+   ATA_DFLAG_SPUNDOWN  = (1 << 14), /* XXX: for spindown_compat */
ATA_DFLAG_INIT_MASK = (1 << 16) - 1,
 
ATA_DFLAG_DETACH= (1 << 16),
-
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: Weird network problems with 2.6.23-rc2

[Jiri Kosina]

On Sat, 11 Aug 2007, Shish wrote:

> Something seems to have broken in 2.6.23-rc2, and I'm not sure what, or
> where I should look for further debugging. The info I have:
> 
> On my 2.6.23-rc2 desktop, things run fine.
> 
> On my test server, built from the same source tree, networking goes
> strange every few minutes, with the following symptoms:
> 
> o) running ping against the server, the first ping goes through;
> further pings go AWOL until about icmp_seq=30, when I get 4-5 icmp
> replies (marked as DUP!), then no pings for a while, then dups, and so
> on.
> 
> o) the server doesn't see ARP replies. According to tcpdump, the server
> will send eg "who has 192.168.0.2? tell 192.168.0.1"; the client in
> question will recieve the packet and send a response, but nothing shows
> up in the server-side tcpdump.
> 
> o) after a few minutes of random network troubles, everything will work
> fine again, (ping is normal, arp replies are seen, tcp sessions work)
> for a few minutes.
> 
> o) The server's dmesg shows lots of "short udp packet" messages
> 
> o) ifdown then ifup'ing the interfaces fixes things, temporarily.
> 
> Reverting to 2.6.22, everything seems to be running fine (but no lguest,
> which is what I came for :( )
> 
> I've also tried with the latest code from git, the behaviour is the same
> as 2.6.23-rc2.

This needs to go to netdev, CC added.

Also, git-bisect will help a lot here to find the commit which caused the 
regression you are seeing.

-- 
Jiri Kosina
-
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] tuxonice-head 070811

[Steven]

Small problem with kernel/power/tuxonice_checksum.c which causes 
compilation to fail with wrong type for get_next_bit_on

--- tuxonice_checksum.c.orig2007-08-11 14:22:52.0 -0700
+++ tuxonice_checksum.c 2007-08-11 14:23:01.0 -0700
@@ -292,7 +292,7 @@
if (check)
toi_num_resaved = 0;
 
-   BITMAP_FOR_EACH_SET(pageset2_map, pfn) {
+   BITMAP_FOR_EACH_SET(&pageset2_map, pfn) {
int ret;
if (index % CHECKSUMS_PER_PAGE) {
this_checksum += CHECKSUM_SIZE;

-
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] Smack: Simplified Mandatory Access Control Kernel

[Kyle Moffett]

On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
[SELinux...] which can do *all* of this, completely and without  
exceptions,


That's quite a strong assertion.


It is, but I stand by it.  If anyone can point out some portion of  
this which *cannot* be implemented as SELinux policy I will humbly  
step completely out of this discussion.



but one does have to have complexity in order to handle everything  
from CD burning in X, to Apache daemons, to only allowing Top- 
Secret-level logins over the IPsec tunnel on the Top Secret  
network, etc.


I do not agree with you. The MLS systems from the 1990's could do  
all that (except the IPsec tunnel, the function of which was  
preceeded by TSIG interfaces and protocols) without the complexity  
required by SELinux policy.


No, most/all of the MLS systems from the 1990s did not integrate Bell- 
LaPadula, Type Enforcement, and Role-Based-Access-Control together.   
In addition, none of the MLS systems from the 1990s had modifiable  
constraints the way SELinux does (for example I can modify the  
fundamental policy to allow a process whose domain has the  
"i_am_special" attribute to override the BLP model for certain target  
types in certain special situations, all depending on how I apply  
that attribute and those types).


For  example, this set of rules basically defines your described  
"read-vs-write-vs-exec" policy as best I can figure out:


user uu roles rr;

role rr types { star floor hat huh };

define(`r',`
allow $1 $2:file { read getattr };
allow $1 $2:socket { read getattr getopt recvfrom recv_msg };
allow $1 $2:ipc { getattr read associate unix_read };
## List of more "read" allow rules for different types of  
objects... ##

')


It would be instructive for those who are not well versed in the  
nuances of SELinux policy if you actually spelled out the whole  
thing, rather than using "## and more ##". Part of the point of  
Smack is the makeup of the full list that would be required here.


Well, yes, but how exactly do you define "read", "write", and  
"execute" for the full list of SELinux object classes found here:

http://www.tresys.com/selinux/obj_perms_help.html

I was considering compiling the complete list, but such an exercise  
would take me at least an hour to do properly and which categories  
individual permissions should be placed in could be argued for  
weeks.  The SELinux reference policy doesn't even completely qualify  
all of those things with MLS restrictions, and they're the ones who  
got the hooks implemented originally.


Specifically, do you classify the bind() syscall as a "read" or a  
"write" operation.  How would you classify accept()?  In order to  
support the full range of security controls that Linux has hooks for,  
you would need to identify a list of how to define "read", "write",  
and "execute" for every object-class in that massive list.   
Furthermore you would need to ensure that the definitions work for  
every process.  From the variations between different portions of the  
SELinux ref policy, I contend that there is no single definition of  
"read", or "write" which works for all usages of a given object-class.



And now to describe these rules:


Smack defines and uses these labels:
  "*" - pronounced "star"
  "_" - pronounced "floor"
  "^" - pronounced "hat"
  "?" - pronounced "huh"

The access rules enforced by Smack are, in order:

1. Any access requested by a task labeled "*" is denied.
2. A read or execute access requested by a task labeled "^"
   is permitted.
3. A read or execute access requested on an object labeled "_"
   is permitted.
4. Any access requested on an object labeled "*" is permitted.
5. Any access requested by a task on an object with the same
   label is permitted.
6. Any access requested that is explicitly defined in the loaded
   rule set is permitted.
7. Any other access is denied.


## These are calls to the above macros which plug in the necessary
arguments
r(hat, {*})
x(hat, {*})
r(~{star}, floor)
x(~{star}, floor)
r(~{star}, star)
w(~{star}, star)
x(~{star}, star)
r(~{star}, self)
w(~{star}, self)
x(~{star}, self)
## Include your "loaded rule set" here ##


What would that look like?


The same kind of thing as the r, x, and w above, with occasional  
"type my_type_t; role rr types my_type_t;" to declare a type before  
use.  If you wanted to add support for attributes which apply to  
multiple types, you could put those after a comma after the "type  
my_type_t" portion of the type declaration.


Smack rule sets can be easily defined that describe Bell&LaPadula  
sensitivity, Biba integrity, and a variety of interesting  
configurations. Smack rule sets can be modified on the fly to  
accomodate changes in the operating environment or even the time  
of day.


SELinux can do this as well.  It even includes support for  
conditional policy:


bool foo_can_do_logging true;
if (foo_can_do_logging) {
allow foo_t foo_log_t:file { create read getattr a

Re: resume from ram much slower

[Rafael J. Wysocki]

On Saturday, 11 August 2007 11:04, Arkadiusz Miskiewicz wrote:
> On Friday 10 of August 2007, Rafael J. Wysocki wrote:
> > On Friday, 10 August 2007 18:48, Arkadiusz Miskiewicz wrote:
> > > Hi,
> > >
> > > Starting 1-2 weeks ago I have very long resume from
> > > ram times. It takes more than 1 min to resume. Does anyone see such
> > > behaviour?
> > >
> > > Kernel from yesterday git, thinkpad z60m, suspend.sf.net tools 20070801
> > >
> > > "ACPI handle has no context!" are interesting btw.
> >
> > Let's try to find out something.
> >
> > Please apply the patch below and see if anything changes.
> 
> dmesg below. Nothing changes. I guess bisecting is going to be needed.

Yes, I guess so.
-
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: [3/3] 2.6.23-rc2: known regressions v2

[Rafael J. Wysocki]

On Saturday, 11 August 2007 12:53, Meelis Roos wrote:
> > > > 3. Can you please check if this patch changes anything:
> > > > http://marc.info/?l=linux-mm-commits&m=118669680811669&w=2
> > > 
> > > Tried it on current git, kernel/power/Kconfig gave 2 rejects.
> > > Tried on 2.6.23-rc2, still 2 rejects from the same file, .rej below:
> > 
> > Sorry, but:
> > 
> > [EMAIL PROTECTED]:~/src/linux-2.6> git-pull 
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > Already up-to-date.
> > [EMAIL PROTECTED]:~/src/linux-2.6> cat 
> > ~/pm-fix-dependencies-of-config_suspend-and-config_hibernation-updated-3x.patch
> >  | patch -p1
> > patching file arch/x86_64/defconfig
> > patching file include/linux/cpu.h
> > patching file kernel/cpu.c
> > patching file kernel/power/Kconfig
> > 
> > How come?
> 
> Hmm, must have been mangled on the web (downloaded via wget so should be 
> byte-by-byte exact). I now downloaded it from akpm-s broken-out tarball 
> and this one applied fine.
> 
> The patch changes the warning to a different warning, it's now
> kernel/power/Kconfig:79:warning: 'select' used by config symbol 
> 'PM_SLEEP_SMP' refers to undefined symbol 'HOTPLUG_CPU'
> 
> The warning also appears when running just "make ARCH=ppc" after
> "make ARCH=ppc oldconfig".

Yes, I have reproduced it now.

Well, it's clearly a false positive, since none of the options PM_SLEEP_SMP
depends on is set in your .config.  Also, it seems to be ppc-specific (for
example, if I change the architecture to powerpc, the warning doesn't show up).

The only problem I see here is that the warning in fact should not be printed,
but I don't know how to make the build system stop printing it.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
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] Minor fix to Documentation/powerpc/00-INDEX

[Randy Dunlap]

On Thu, 9 Aug 2007 23:42:35 -0500 Rob Landley wrote:

> Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
> 
> I have a python script to convert 00-INDEX files into index.html files, and a
> second script to show 404 errors in the result as well as files/directories
> nothing links to.   (It's not very useful yet, but in case you're wondering
> http://kernel.org/doc/docdiridx.py and http://kernel.org/doc/doclinkcheck.py
> .)
> 
> Anyway, my simple index.html generator breaks on the Documentation/powerpc
> directory because one of the description lines is two lines long.  This
> patch joins those two lines together into one line.  This is the only
> instance (so far) of this problem.

If Paul wants to merge this, then OK, but I'm not aware of any rule
that the file descriptions inside INDEX files must be only one line
long... is that documented somewhere?  (if so, where?)

Maybe the script should allow for this?

> ---
> 
> In case you're wondering, here are the current the 404 errors in the
> various 00-INDEX files.  Fixing all this is on my todo list:
> 
> Documentation/ecryptfs.txt
> Documentation/time_interpolators.txt
> Documentation/arm/SA1100
> Documentation/arm/XScale
> Documentation/arm/empeg
> Documentation/arm/nwfpe
> Documentation/isdn/README.eicon
> Documentation/fb/clgenfb.txt
> Documentation/networking/ethertap.txt
> Documentation/filesystems/reiser4.txt
> Documentation/scsi/AM53C974.txt
> Documentation/scsi/ChangeLog
> 
> The "files and directories not linked to" list is 679 lines long.
> 
> diff -r /dev/null Documentation/powerpc/00-INDEX
> --- a/Documentation/powerpc/00-INDEX  Thu Aug 09 08:40:21 2007 -0700
> +++ b/Documentation/powerpc/00-INDEX  Thu Aug 09 20:49:03 2007 -0500
> @@ -6,8 +6,7 @@ 00-INDEX
>  00-INDEX
>   - this file
>  cpu_features.txt
> - - info on how we support a variety of CPUs with minimal compile-time
> - options.
> + - info on how we support a variety of CPUs with minimal compile-time 
> options.
>  eeh-pci-error-recovery.txt
>   - info on PCI Bus EEH Error Recovery
>  hvcs.txt


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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: joydev.c and saitek cyborg evo force

[Renato Golin]

On 11/08/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> Force feedback functionality shouldn't be influenced in any means by this
> patch - FF implementation doesn't care about the values of the
> input_dev->abs{max,min,fuzz,flat}.

So it means the patch should work for all other joysticks as well?
That's good news... ;)


> But it is questionable whether your joystick is fully compliant with PID
> protocol or it implements some sort of vendor-specific one.

I wouldn't be surprised if it's vendor-specific, as their original
driver doesn't work quite well, I had to download a patched driver
from their website. Also, they seem to work it around (as I did) with
the auto-calibration.

Thanks for the help!

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
-
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: joydev.c and saitek cyborg evo force

[Jiri Kosina]

On Sat, 11 Aug 2007, Renato Golin wrote:

> fixes perfectly. But it probably breaks the output range and kills the 
> force-feedback.

Thanks for testing.

Force feedback functionality shouldn't be influenced in any means by this 
patch - FF implementation doesn't care about the values of the 
input_dev->abs{max,min,fuzz,flat}.

But it is questionable whether your joystick is fully compliant with PID 
protocol or it implements some sort of vendor-specific one.

> I couldn't find fftest for debian (the package with jstest doesn't
> have it) but I'll compile and run here to test.

Thanks.

-- 
Jiri Kosina
SUSE Labs
-
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] Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Kyle Moffett <[EMAIL PROTECTED]> wrote:

> On Aug 11, 2007, at 13:57:31, Casey Schaufler wrote:
> > Smack implements mandatory access control (MAC) using labels  
> > attached to tasks and data containers, including files, SVIPC, and  
> > other tasks. Smack is a kernel based scheme that requires an  
> > absolute minimum of application support and a very small amount of  
> > configuration data.
> 
> For starters, we would appear to already have a very capable  
> labelling system 

I am not going to argue that SELinux is not a capable
labelling system. SELinux is a fine implementation of
of Type Enforcement.

> which can do *all* of this, completely and without  
> exceptions,

That's quite a strong assertion.

> in a much more flexible way.

Indeed, SELinux provides tremendous flexibility.

> Admittedly it's more complicated,

Yes, it is.

> but one does have to have complexity in order to handle  
> everything from CD burning in X, to Apache daemons, to only allowing  
> Top-Secret-level logins over the IPsec tunnel on the Top Secret  
> network, etc.

I do not agree with you. The MLS systems from the 1990's could do all
that (except the IPsec tunnel, the function of which was preceeded by
TSIG interfaces and protocols) without the complexity required by
SELinux policy.

> Do you see any particular reason this couldn't be  
> implemented as a very *very* simplified SELinux wrapper?

I would be interested to see the attempt made, but I have no interest
in doing so myself. I think that some of the reasons will come out
as we progress through your examples.

> For  
> example, this set of rules basically defines your described "read-vs- 
> write-vs-exec" policy as best I can figure out:
> 
> user uu roles rr;
> 
> role rr types { star floor hat huh };
> 
> define(`r',`
> allow $1 $2:file { read getattr };
> allow $1 $2:socket { read getattr getopt recvfrom recv_msg };
> allow $1 $2:ipc { getattr read associate unix_read };
> ## List of more "read" allow rules for different types of objects... ##
> ')

It would be instructive for those who are not well versed in the
nuances of SELinux policy if you actually spelled out the whole
thing, rather than using "## and more ##". Part of the point of
Smack is the makeup of the full list that would be required here.

> define(`w',`
> allow $1 $2:file { ioctl write create setattr lock append unlink link  
> rename swapon quotaon mounton };
> allow $1 $2:socket { ioctl write create setattr lock append bind  
> connect listen accept setopt shutdown sendto send_msg name_bind };
> allow $1 $2:ipc { create destroy setattr write unix_write };
> ## List of more "write" allow rules for different types of objects... ##
> ')

Again, I suggest you present the complete list.

> define(`x',`
> allow $1 $2:file { execute };
> allow $1 $2:dir { search };
> ## List of more "execute" allow rules for different types of  
> objects... ##
> ')

Here too. 

> And now to describe these rules:
> 
> > Smack defines and uses these labels:
> >   "*" - pronounced "star"
> >   "_" - pronounced "floor"
> >   "^" - pronounced "hat"
> >   "?" - pronounced "huh"
> >
> > The access rules enforced by Smack are, in order:
> >
> > 1. Any access requested by a task labeled "*" is denied.
> > 2. A read or execute access requested by a task labeled "^"
> >is permitted.
> > 3. A read or execute access requested on an object labeled "_"
> >is permitted.
> > 4. Any access requested on an object labeled "*" is permitted.
> > 5. Any access requested by a task on an object with the same
> >label is permitted.
> > 6. Any access requested that is explicitly defined in the loaded
> >rule set is permitted.
> > 7. Any other access is denied.
> 
> ## These are calls to the above macros which plug in the necessary  
> arguments
> r(hat, {*})
> x(hat, {*})
> r(~{star}, floor)
> x(~{star}, floor)
> r(~{star}, star)
> w(~{star}, star)
> x(~{star}, star)
> r(~{star}, self)
> w(~{star}, self)
> x(~{star}, self)
> ## Include your "loaded rule set" here ##

What would that look like?


> > Rules may be explicitly defined by writing subject,object,access  
> > triples to /smack/load.
> 
> Maybe worth a little utility to convert a file full of  
> "subject,object,access" triples to an appropriate SELinux policy  
> would be appropriate?

Maybe. It would at least be educational for comparisons by those
looking to choose between the schemes.
 
> > Smack rule sets can be easily defined that describe Bell&LaPadula  
> > sensitivity, Biba integrity, and a variety of interesting  
> > configurations. Smack rule sets can be modified on the fly to  
> > accomodate changes in the operating environment or even the time of  
> > day.
> 
> SELinux can do this as well.  It even includes support for  
> conditional policy:
> 
> bool foo_can_do_logging true;
> if (foo_can_do_logging) {
>   allow foo_t foo_log_t:file { create read getattr append };
> }

You have to build the booleans into the policy in advance.

> The

Re: [linux-usb-devel] 2.6.23-rc2-mm2

[David Brownell]

On Friday 10 August 2007, Gabriel C wrote:
> Getting that with gcc 4.2.1 :
>
> drivers/usb/host/ohci-dbg.c: In function 'show_registers':
> drivers/usb/host/ohci-dbg.c:620: warning: the address of 'next' will always 
> evaluate as 'true'
> drivers/usb/host/ohci-dbg.c:639: warning: the address of 'next' will always 
> evaluate as 'true'

Seems like a pretty annoying warning to have added ... the relevant
test *expects* to have two constant branches, where the compiler
optimizes one out of existence.

Does this patch get rid of it?

---
 drivers/usb/host/ohci-dbg.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- g26.orig/drivers/usb/host/ohci-dbg.c2007-08-11 13:51:42.0 
-0700
+++ g26/drivers/usb/host/ohci-dbg.c 2007-08-11 13:52:07.0 -0700
@@ -74,7 +74,7 @@ urb_print (struct urb * urb, char * str,
 
 #define ohci_dbg_sw(ohci, next, size, format, arg...) \
do { \
-   if (next) { \
+   if (next != NULL) { \
unsigned s_len; \
s_len = scnprintf (*next, *size, format, ## arg ); \
*size -= s_len; *next += s_len; \
-
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] Add missing newlines to some uses of dev_ messages

[David Brownell]

On Saturday 11 August 2007, Jean Delvare wrote:
> Note that there are 3 more messages to fix in
> drivers/i2c/chips/menelaus.c (3 calls to pr_err.)

I'd hope those will get fixed by final versions of the
patches I've seen floating around definining a standard
pr_err() ... not fixing them here allows the two patches
to not conflict.  :)

- Dave

-
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] Smack: Simplified Mandatory Access Control Kernel

[Jan Engelhardt]

On Aug 11 2007 10:57, Casey Schaufler wrote:
>
>"*" - pronounced "star"
wall
>"_" - pronounced "floor"
floor
>"^" - pronounced "hat"
roof
>"?" - pronounced "huh"
it's dark in here :)

>+config SECURITY_SMACK
>+  bool "Simplified Mandatory Access Control Kernel Support"
>+  depends on NETLABEL && SECURITY_NETWORK

Is this a hard dependency, or can this work without network sec labels?

>+  default n
>+  help
>+This selects the Simplified Mandatory Access Control Kernel.
>+SMACK is useful for sensitivity, integrity, and a variety
>+  of other madatory security schemes.
>+If you are unsure how to answer this question, answer N.

I smell broken tabs.

>+++ linux-2.6.22/security/smack/Makefile   2007-07-10 01:08:05.0 
>-0700
>@@ -0,0 +1,8 @@
>+#
>+# Makefile for the SMACK LSM
>+#
>+
>+obj-$(CONFIG_SECURITY_SMACK) := smack.o
>+
>+smack-y := smack_lsm.o smack_access.o smackfs.o

smack-objs :=

>+++ linux-2.6.22/security/smack/smack_access.c 2007-07-24 15:36:18.0 
>-0700
>@@ -0,0 +1,113 @@
>+extern struct smk_list_entry *smack_list;
>+
>+static int smk_get_access(smack_t sub, smack_t obj)
>+{
>+  struct smk_list_entry *sp = smack_list;

proposes const struct. should be used elsewhere too.

>+  if (sub == SMK_STAR)

I just remember MechWarrior2 (game from Activison), where SMK stood for their
movie format... it's also a nice abbreviation for Seamonkey (browser suite).

>+  if (sub == SMK_HAT && ((request & MAY_ANYREAD) == request))
>+  return 0;
>+
>+  if (obj == SMK_FLOOR && ((request & MAY_ANYREAD) == request))
>+  return 0;

Redundant parentheses, be gone.

Never was it easier to say what ^ is called in your language :)

if (sub == '^' && ...)
return 0;
if (obj == '_' && ...)


>+/*
>+ * The value that this adds is that everything after any
>+ * character that's not allowed in a smack will be null
>+ */
>+smack_t smk_from_string(char *str)
>+{
>+  smack_t smack = 0LL;

"smack_t smack = 0;" is enough here.

>+  char *cp;
>+  int i;
>+
>+  for (cp = (char *)&smack, i = 0; i < sizeof(smack_t); str++,cp++,i++) {

Whatever it tries to do, this is not endian-safe. Except if @str
actually points to another smack_t. Yuck.

>+  if (*str <= ' ' || *str > '~')
>+  return smack;
>+  *cp = *str;
>+  }
>+  /*
>+   * Too long.
>+   */
>+  return SMK_INVALID;
>+}
>diff -uprN -X linux-2.6.22-base/Documentation/dontdiff 
>linux-2.6.22-base/security/smack/smackfs.c 
>linux-2.6.22/security/smack/smackfs.c
>--- linux-2.6.22-base/security/smack/smackfs.c 1969-12-31 16:00:00.0 
>-0800
>+++ linux-2.6.22/security/smack/smackfs.c  2007-07-24 21:51:30.0 
>-0700

Can't securityfs and/or sysfs be used?

>+enum smk_inos {
>+  SMK_ROOT_INO =  2,
>+  SMK_LOAD =  3,  /* load policy */
>+  SMK_LINKS = 4,  /* symlinks */
>+  SMK_CIPSO = 5,  /* load label -> CIPSO mapping */
>+  SMK_DOI =   6,  /* CIPSO DOI */
>+  SMK_DIRECT =7,  /* CIPSO level indicating direct label */
>+  SMK_AMBIENT =   8,  /* internet ambient label */
>+  SMK_NLTYPE =9,  /* label scheme to use by default */
>+  SMK_TMP =   100,/* MUST BE LAST! /smack/tmp */
>+};

Generally, =s are aligned too.

>+static struct smk_cipso_entry smack_cipso_floor = {
>+.smk_next = NULL,
>+.smk_smack = SMK_FLOOR,
>+.smk_level = 0,
>+.smk_catset = 0LL,
>+};

const me.

>+/*
>+ * '  \n\0' 
>+ */

I wonder why it's limited to 8 characters? Ah right.. sizeof(smack_t).
uhm.. are you trying to tell me that smack_t [typedef'ed to u64]
are actually meant as a char[8]? (/me scrathces head)

>+  for (cp = result; slp != NULL; slp = slp->smk_next) {
>+  srp = &slp->smk_rule;
>+  sprintf(cp, "%-8s %-8s",
>+  (char *)&srp->smk_subject, (char *)&srp->smk_object);

I like (const char *).

>+  printk("%s:%d bad scan\n",
>+  __FUNCTION__, __LINE__);

__FUNCTION__ is a GNU extension, C99 uses __func__.
Not sure what they've got for __LINE__.

>+  if (strchr(modestr, 'r') || strchr(modestr, 'R'))
>+  rule.smk_access |= MAY_READ;
>+  if (strchr(modestr, 'w') || strchr(modestr, 'W'))
>+  rule.smk_access |= MAY_WRITE;
>+  if (strchr(modestr, 'x') || strchr(modestr, 'X'))
>+  rule.smk_access |= MAY_EXEC;
>+  if (strchr(modestr, 'a') || strchr(modestr, 'A'))
>+  rule.smk_access |= MAY_APPEND;

There's strpbrk() available for you.

>+static char *smk_digit(char *cp)
>+{
>+  for (; *cp != '\0'; cp++)
>+  if (*cp >= '0' && *cp <= '9')
>+  return cp;
>+
>+  return NUL

Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Arjan van de Ven <[EMAIL PROTECTED]> wrote:

> > +extern struct smk_list_entry *smack_list;
> 
> any reason to invent your own list rather than just using list.h?

The list.h mechanisms are fine, but heavier than I require.
I'm willing to give in on it, but I don't see an advantage.

> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "../../net/netlabel/netlabel_domainhash.h"
> 
> can't you move this header to include/ instead?

Paul Moore, the developer of netlabel, promised to work out
the right solution for this with me at a future date. He
doesn't want to move the header, and I respect that.

> > +
> > +static struct file_operations smk_load_ops = {
> > +   .read   = smk_read_load,
> > +   .write  = smk_write_load,
> > +};
> 
> make that a const please

Will do.

> > +
> > +   doip = kmalloc(sizeof(struct cipso_v4_doi), GFP_KERNEL);
> > +   if (doip == NULL)
> > +   panic("smack:  Failed to initialize cipso DOI.\n");
> > +   doip->map.std = NULL;
> > +
> > +   ndmp = kmalloc(sizeof(struct netlbl_dom_map), GFP_KERNEL);
> > +   if (ndmp == NULL)
> > +   panic("smack:  Failed to initialize cipso ndmp.\n");
> 
> 
> is panic() really the right thing here? It's usually considered quite
> rude ;)

It's really early in start-up and if you're out of memory at that
point you are not going very far into the future.

> > +static struct file_operations smk_cipso_ops = {
> > +   .read   = smk_read_cipso,
> > +   .write  = smk_write_cipso,
> > +};
> 
> another candidate for const

Will do that, too.

> > +static void *smackfs_follow_link(struct dentry *dentry, struct nameidata
> *nd)
> > +{
> 
> 
> this one deserves a comment; are you implementing magic symlinks here?

Yup.

Casey Schaufler
[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.23-rc2-mm1: rcutorture xtime usage

[Paul E. McKenney]

On Sat, Aug 11, 2007 at 08:09:09PM +0200, Ingo Molnar wrote:
> 
> * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> 
> > Add an EXPORT_SYMBOL_GPL() for cpu_clock() and make rcutorture.c use it.
> > Compiles, but not yet tested.
> > 
> > Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
> 
> > --- linux-2.6.23-rc2/kernel/sched.c 2007-08-03 19:49:55.0 -0700
> > +++ linux-2.6.23-rc2-rcutorturesched/kernel/sched.c 2007-08-10 
> > 17:22:57.0 -0700
> > @@ -394,6 +394,8 @@ unsigned long long cpu_clock(int cpu)
> > return now;
> >  }
> >  
> > +EXPORT_SYMBOL_GPL(cpu_clock);
> 
> sure enough,
> 
> Acked-by: Ingo Molnar <[EMAIL PROTECTED]>

Thank you!

Just for the record, given that the xtime API that it replaces
was EXPORT_SYMBOL(), I would have not objection to this also being
EXPORT_SYMBOL().  That said, I know of no specific reason for it being
other than EXPORT_SYMBOL_GPL().

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

Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel

[Kyle Moffett]

On Aug 11, 2007, at 13:57:31, Casey Schaufler wrote:
Smack implements mandatory access control (MAC) using labels  
attached to tasks and data containers, including files, SVIPC, and  
other tasks. Smack is a kernel based scheme that requires an  
absolute minimum of application support and a very small amount of  
configuration data.


For starters, we would appear to already have a very capable  
labelling system which can do *all* of this, completely and without  
exceptions, in a much more flexible way.  Admittedly it's more  
complicated, but one does have to have complexity in order to handle  
everything from CD burning in X, to Apache daemons, to only allowing  
Top-Secret-level logins over the IPsec tunnel on the Top Secret  
network, etc.  Do you see any particular reason this couldn't be  
implemented as a very *very* simplified SELinux wrapper?  For  
example, this set of rules basically defines your described "read-vs- 
write-vs-exec" policy as best I can figure out:


user uu roles rr;

role rr types { star floor hat huh };

define(`r',`
allow $1 $2:file { read getattr };
allow $1 $2:socket { read getattr getopt recvfrom recv_msg };
allow $1 $2:ipc { getattr read associate unix_read };
## List of more "read" allow rules for different types of objects... ##
')

define(`w',`
allow $1 $2:file { ioctl write create setattr lock append unlink link  
rename swapon quotaon mounton };
allow $1 $2:socket { ioctl write create setattr lock append bind  
connect listen accept setopt shutdown sendto send_msg name_bind };

allow $1 $2:ipc { create destroy setattr write unix_write };
## List of more "write" allow rules for different types of objects... ##
')

define(`x',`
allow $1 $2:file { execute };
allow $1 $2:dir { search };
## List of more "execute" allow rules for different types of  
objects... ##

')


And now to describe these rules:


Smack defines and uses these labels:
  "*" - pronounced "star"
  "_" - pronounced "floor"
  "^" - pronounced "hat"
  "?" - pronounced "huh"

The access rules enforced by Smack are, in order:

1. Any access requested by a task labeled "*" is denied.
2. A read or execute access requested by a task labeled "^"
   is permitted.
3. A read or execute access requested on an object labeled "_"
   is permitted.
4. Any access requested on an object labeled "*" is permitted.
5. Any access requested by a task on an object with the same
   label is permitted.
6. Any access requested that is explicitly defined in the loaded
   rule set is permitted.
7. Any other access is denied.


## These are calls to the above macros which plug in the necessary  
arguments

r(hat, {*})
x(hat, {*})
r(~{star}, floor)
x(~{star}, floor)
r(~{star}, star)
w(~{star}, star)
x(~{star}, star)
r(~{star}, self)
w(~{star}, self)
x(~{star}, self)
## Include your "loaded rule set" here ##


Rules may be explicitly defined by writing subject,object,access  
triples to /smack/load.


Maybe worth a little utility to convert a file full of  
"subject,object,access" triples to an appropriate SELinux policy  
would be appropriate?



Smack rule sets can be easily defined that describe Bell&LaPadula  
sensitivity, Biba integrity, and a variety of interesting  
configurations. Smack rule sets can be modified on the fly to  
accomodate changes in the operating environment or even the time of  
day.


SELinux can do this as well.  It even includes support for  
conditional policy:


bool foo_can_do_logging true;
if (foo_can_do_logging) {
allow foo_t foo_log_t:file { create read getattr append };
}

The SELinux tools also have support for policy modules, so you can  
extend the policy without modifying the base system.  Plus the stuff  
has been very heavily tested and even supports X (as soon as the beta  
X code gets improved and merged in the upstream X.org codebase).




Some practical use cases:

Hierarchical levels. The less common of the two usual uses for MLS  
systems is to define hierarchical levels, often unclassified,  
confidential, secret, and so on. To set up smack to support this,  
these rules could be defined:


   CUnclass rx
   SC   rx
   SUnclass rx
   TS   S   rx
   TS   C   rx
   TS   Unclass rx

A TS process can read S, C, and Unclass data, but cannot write it.
An S process can read C and Unclass. Note that specifying that
TS can read S and S can read C does not imply TS can read C, it
has to be explicitly stated.


The big problem here is the duplication.  Say you have a locked-down  
Apache configuration and you want to run 2 apache processes, one at  
Secret and one at Top-Secret.  Under your model you have to copy- 
paste the policy and make sure to apply fixes/changes to both  
places.  Under SELinux, you can have processes as:

  system_u:system_r:httpd_t:Secret:UFOSightings,AlienDissection
  system_u:system_r:httpd_t:TopSecret:NukeTests

They can only read and write objects for which multiple conditions  
are true:  First, the object 

Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel

[Arjan van de Ven]

> +extern struct smk_list_entry *smack_list;

any reason to invent your own list rather than just using list.h?



> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "../../net/netlabel/netlabel_domainhash.h"

can't you move this header to include/ instead?



> +
> +static struct file_operations smk_load_ops = {
> + .read   = smk_read_load,
> + .write  = smk_write_load,
> +};

make that a const please

> +
> + doip = kmalloc(sizeof(struct cipso_v4_doi), GFP_KERNEL);
> + if (doip == NULL)
> + panic("smack:  Failed to initialize cipso DOI.\n");
> + doip->map.std = NULL;
> +
> + ndmp = kmalloc(sizeof(struct netlbl_dom_map), GFP_KERNEL);
> + if (ndmp == NULL)
> + panic("smack:  Failed to initialize cipso ndmp.\n");


is panic() really the right thing here? It's usually considered quite
rude ;)


> +static struct file_operations smk_cipso_ops = {
> + .read   = smk_read_cipso,
> + .write  = smk_write_cipso,
> +};

another candidate for const


> +static void *smackfs_follow_link(struct dentry *dentry, struct nameidata *nd)
> +{


this one deserves a comment; are you implementing magic symlinks here?



-
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: Documentation files in html format?

[Rene Herman]

On 08/11/2007 08:31 AM, Stefan Richter wrote:


Rene Herman wrote:

On 08/10/2007 10:12 PM, Sam Ravnborg wrote:


What primary requirements does in-tree Linux kernel documentation have
to fulfill in general?

Skipping the obvious ones such as correct, up-to-date etc.
o Readable as-is
o Grepable
o buildable as structured documents or almost like a single book
o Easy to replicate structure
o Maintainable in any decent text-editor (emacs, vim, whatever)


Low entry barrier for patches from unsuspecting occasional contributors?


Indeed, and AsciiDoc seems to fit nicely; it's easy to work from example. 
Look at:


http://www.methods.co.nz/asciidoc/asciidoc.txt

which is the source for:

http://www.methods.co.nz/asciidoc/asciidoc.css-embedded.html

In fact, one of the more important things for lowering the entry barrier is 
providing contributors with infrastructure so that a contributor is free to 
concentrate more on the what than the how and as was already argued in this 
thread, when you start laying down structure and rules for Documentation/, 
you end up with something close to AsciiDoc anyway.



Easy to put online?


http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=Documentation
http://lxr.linux.no/source/Documentation/
http://users.sosdg.org/~qiyong/lxr/source/Documentation/
http://www.linux-m32r.org/lxr/http/source/Documentation/
http://lxr.free-electrons.com/source/Documentation/


Easy to put online in a nice way. Compare:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kbuild/makefiles.txt;h=e08ef8759a0780caaa237a5a88ad8d921208af98;hb=HEAD

and

http://www.ravnborg.org/kbuild/makefiles.html

as Sam posted. I certainly think the latter reads nicer (it's missing the 
table of content for now, but that appears to be a tool option).



(I admit though that formats like asciidoc or docbook are beneficial for
larger documentation files which want chapters, table of contents, and
internal crossreferences.)


I personally wouldn't want to rudely outlaw plain text -- the discussion 
happened due to someone suggesting redoing some documentation in HTML. Some 
people suggested DocBook (hnnng!) and now asciidoc.


I think that DocBook is a bloody trainwreck (yes, "make pdfdocs" bombs out 
for me at the moment as well -- has it ever been different) but that some 
simple formatting quite often makes for an improvement over plain text.


HTML directly would do as far as I'm concerned, but AsciiDoc can also 
generate that and additionally imposes more structure (in the sense of 
uniformity) than direct HTML would. On the downside it still requires some 
external software, on the upside it directly translates to many more formats 
when viewed as a DocBook pre-processor.


Works for me...

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

[2.6.20.16 review 04/28] make freezeable workqueues singlethread

[Willy Tarreau]

It is a known fact that freezeable multithreaded workqueues doesn't like
CPU_DEAD. We keep them only for the incoming CPU-hotplug rework.

Sadly, we can't just kill create_freezeable_workqueue() right now, make
them singlethread.

Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
Cc: "Rafael J. Wysocki" <[EMAIL PROTECTED]>
Cc: Gautham R Shenoy <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 include/linux/workqueue.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 2a7b38d..1a76bda 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -162,7 +162,7 @@ extern struct workqueue_struct *__create_workqueue(const 
char *name,
int singlethread,
int freezeable);
 #define create_workqueue(name) __create_workqueue((name), 0, 0)
-#define create_freezeable_workqueue(name) __create_workqueue((name), 0, 1)
+#define create_freezeable_workqueue(name) __create_workqueue((name), 1, 1)
 #define create_singlethread_workqueue(name) __create_workqueue((name), 1, 0)
 
 extern void destroy_workqueue(struct workqueue_struct *wq);
-- 
1.5.2.4

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

[2.6.20.16 review 27/28] NTP: remove clock_was_set() call to prevent deadlock

[Willy Tarreau]

The clock_was_set() call in seconds_overflow() which happens only when
leap seconds are inserted / deleted is wrong in two aspects:

1. it results in a call to on_each_cpu() with interrupts disabled
2. it is potential deadlock source vs. call_lock in smp_call_function()

The only possible side effect of the removal might be, that an absolute
CLOCK_REALTIME timer fires 1 second too late, in the rare case of leap
second deletion and an absolute CLOCK_REALTIME timer which expires in
the affected time frame. It will never fire too early.

This was probably observed by the reporter of a June 30th -> July 1st
hang: http://lkml.org/lkml/2007/7/3/

A similar problem was observed by Dave Jones, who provided a screen shot
with a lockdep back trace, which allowed to analyse the problem.

Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Cc: john stultz <[EMAIL PROTECTED]>
Cc: Dave Jones <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Vincent Fortier <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 kernel/time/ntp.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 3afeaa3..64744bb 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -116,7 +116,6 @@ void second_overflow(void)
 */
time_interpolator_update(-NSEC_PER_SEC);
time_state = TIME_OOP;
-   clock_was_set();
printk(KERN_NOTICE "Clock: inserting leap second "
"23:59:60 UTC
");
}
@@ -131,7 +130,6 @@ void second_overflow(void)
 */
time_interpolator_update(NSEC_PER_SEC);
time_state = TIME_WAIT;
-   clock_was_set();
printk(KERN_NOTICE "Clock: deleting leap second "
"23:59:59 UTC
");
}
-- 
1.5.2.4

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

[2.6.20.16 review 11/28] rt-mutex: Fix chain walk early wakeup bug

[Willy Tarreau]

Alexey Kuznetsov found some problems in the pi-futex code.

One of the root causes is:

When a wakeup happens, we do not to stop the chain walk so we
we follow a non existing locking chain.

Drop out when this happens.

Cc: Alexey Kuznetsov <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 kernel/rtmutex.c |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
index 9b08847..dd5feae 100644
--- a/kernel/rtmutex.c
+++ b/kernel/rtmutex.c
@@ -212,6 +212,19 @@ static int rt_mutex_adjust_prio_chain(struct task_struct 
*task,
if (!waiter || !waiter->task)
goto out_unlock_pi;
 
+   /*
+* Check the orig_waiter state. After we dropped the locks,
+* the previous owner of the lock might have released the lock
+* and made us the pending owner:
+*/
+   if (orig_waiter && !orig_waiter->task)
+   goto out_unlock_pi;
+
+   /*
+* Drop out, when the task has no waiters. Note,
+* top_waiter can be NULL, when we are in the deboosting
+* mode!
+*/
if (top_waiter && (!task_has_pi_waiters(task) ||
   top_waiter != task_top_pi_waiter(task)))
goto out_unlock_pi;
-- 
1.5.2.4

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

[2.6.20.16 review 10/28] rt-mutex: Fix stale return value

[Willy Tarreau]

Alexey Kuznetsov found some problems in the pi-futex code.

The major problem is a stale return value in rt_mutex_slowlock():

When the pi chain walk returns -EDEADLK, but the waiter was woken up
during the phases where the locks were dropped, the rtmutex could be
acquired, but due to the stale return value -EDEADLK returned to the
caller.

Reset the return value in the woken up path.

Cc: Alexey Kuznetsov <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 kernel/rtmutex.c |   11 +--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
index 4ab17da..9b08847 100644
--- a/kernel/rtmutex.c
+++ b/kernel/rtmutex.c
@@ -659,9 +659,16 @@ rt_mutex_slowlock(struct rt_mutex *lock, int state,
 * all over without going into schedule to try
 * to get the lock now:
 */
-   if (unlikely(!waiter.task))
+   if (unlikely(!waiter.task)) {
+   /*
+* Reset the return value. We might
+* have returned with -EDEADLK and the
+* owner released the lock while we
+* were walking the pi chain.
+*/
+   ret = 0;
continue;
-
+   }
if (unlikely(ret))
break;
}
-- 
1.5.2.4

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

[2.6.20.16 review 22/28] POWERPC: Fix subtle FP state corruption bug in signal return on SMP

[Willy Tarreau]

This fixes a bug which can cause corruption of the floating-point state
on return from a signal handler.  If we have a signal handler that has
used the floating-point registers, and it happens to context-switch to
another task while copying the interrupted floating-point state from the
user stack into the thread struct (e.g. because of a page fault, or
because it gets preempted), the context switch code will think that the
FP registers contain valid FP state that needs to be copied into the
thread_struct, and will thus overwrite the values that the signal return
code has put into the thread_struct.

This can occur because we clear the MSR bits that indicate the presence
of valid FP state after copying the state into the thread_struct.  To fix
this we just move the clearing of the MSR bits to before the copy.  A
similar potential problem also occurs with the Altivec state, and this
fixes that in the same way.

Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 arch/powerpc/kernel/signal_64.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
index f72e8e8..a84304e 100644
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -177,6 +177,13 @@ static long restore_sigcontext(struct pt_regs *regs, 
sigset_t *set, int sig,
 */
discard_lazy_cpu_state();
 
+   /*
+* Force reload of FP/VEC.
+* This has to be done before copying stuff into current->thread.fpr/vr
+* for the reasons explained in the previous comment.
+*/
+   regs->msr &= ~(MSR_FP | MSR_FE0 | MSR_FE1 | MSR_VEC);
+
err |= __copy_from_user(¤t->thread.fpr, &sc->fp_regs, 
FP_REGS_SIZE);
 
 #ifdef CONFIG_ALTIVEC
@@ -198,9 +205,6 @@ static long restore_sigcontext(struct pt_regs *regs, 
sigset_t *set, int sig,
current->thread.vrsave = 0;
 #endif /* CONFIG_ALTIVEC */
 
-   /* Force reload of FP/VEC */
-   regs->msr &= ~(MSR_FP | MSR_FE0 | MSR_FE1 | MSR_VEC);
-
return err;
 }
 
-- 
1.5.2.4

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

[2.6.20.16 review 06/28] e1000: disable polling before registering netdevice

[Willy Tarreau]

To assure the symmetry of poll enable/disable in up/down, we should
initialize the netdevice to be poll_disabled at load time. Doing
this after register_netdevice leaves us open to another race, so
lets move all the netif_* calls above register_netdevice so the
stack starts out how we expect it to be.

Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Cc: Herbert Xu <[EMAIL PROTECTED]>
Cc: Doug Chapman <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/net/e1000/e1000_main.c |   11 +++
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index c6259c7..40bdcf9 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1157,13 +1157,16 @@ e1000_probe(struct pci_dev *pdev,
!e1000_check_mng_mode(&adapter->hw))
e1000_get_hw_control(adapter);
 
-   strcpy(netdev->name, "eth%d");
-   if ((err = register_netdev(netdev)))
-   goto err_register;
-
/* tell the stack to leave us alone until e1000_open() is called */
netif_carrier_off(netdev);
netif_stop_queue(netdev);
+#ifdef CONFIG_E1000_NAPI
+   netif_poll_disable(netdev);
+#endif
+
+   strcpy(netdev->name, "eth%d");
+   if ((err = register_netdev(netdev)))
+   goto err_register;
 
DPRINTK(PROBE, INFO, "Intel(R) PRO/1000 Network Connection
");
 
-- 
1.5.2.4

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

[2.6.20.16 review 25/28] serial: clear proper MPSC interrupt cause bits

[Willy Tarreau]

The interrupt clearing code in mpsc_sdma_intr_ack() mistakenly clears the
interrupt for both controllers instead of just the one its supposed to.
This can result in the other controller appearing to hang because its
interrupt was effectively lost.

So, don't clear the interrupt cause bits for both MPSC controllers when
clearing the interrupt for one of them.  Just clear the one that is
supposed to be cleared.

Signed-off-by: Jay Lubomirski <[EMAIL PROTECTED]>
Acked-by: Mark A. Greer <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/serial/mpsc.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/serial/mpsc.c b/drivers/serial/mpsc.c
index 3d2fcc5..64ed5ef 100644
--- a/drivers/serial/mpsc.c
+++ b/drivers/serial/mpsc.c
@@ -502,7 +502,8 @@ mpsc_sdma_intr_ack(struct mpsc_port_info *pi)
 
if (pi->mirror_regs)
pi->shared_regs->SDMA_INTR_CAUSE_m = 0;
-   writel(0, pi->shared_regs->sdma_intr_base + SDMA_INTR_CAUSE);
+   writeb(0x00, pi->shared_regs->sdma_intr_base + SDMA_INTR_CAUSE +
+  pi->port.line);
return;
 }
 
-- 
1.5.2.4

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

[2.6.20.16 review 26/28] i386: fix infinite loop with singlestep int80 syscalls

[Willy Tarreau]

The commit 635cf99a80f4ebee59d70eb64bb85ce829e4591f introduced a
regression.  Executing a ptrace single step after certain int80
accesses will infinitely loop and never advance the PC.

The TIF_SINGLESTEP check should be done on the return from the syscall
and not before it.

The new test case is below:

/* Test whether singlestep through an int80 syscall works.
 */
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

static int child, status;
static struct user_regs_struct regs;

static void do_child()
{
char str[80] = "child: int80 test
";

ptrace(PTRACE_TRACEME, 0, 0, 0);
kill(getpid(), SIGUSR1);
write(fileno(stdout),str,strlen(str));
asm ("int $0x80" : : "a" (20)); /* getpid */
}

static void do_parent()
{
unsigned long eip, expected = 0;
again:
waitpid(child, &status, 0);
if (WIFEXITED(status) || WIFSIGNALED(status))
return;

if (WIFSTOPPED(status)) {
ptrace(PTRACE_GETREGS, child, 0, ®s);
eip = regs.eip;
if (expected)
fprintf(stderr, "child stop @ %08lx, expected %08lx %s
",
eip, expected,
eip == expected ? "" : " <== ERROR");

if (*(unsigned short *)eip == 0x80cd) {
fprintf(stderr, "int 0x80 at %08x
", (unsigned int)eip);
expected = eip + 2;
} else
expected = 0;

ptrace(PTRACE_SINGLESTEP, child, NULL, NULL);
}
goto again;
}

int main(int argc, char * const argv[])
{
child = fork();
if (child)
do_parent();
else
do_child();
return 0;
}

Signed-off-by: Jason Wessel <[EMAIL PROTECTED]>
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Chuck Ebbert <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 arch/i386/kernel/entry.S |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/i386/kernel/entry.S b/arch/i386/kernel/entry.S
index 5e47683..9bf056e 100644
--- a/arch/i386/kernel/entry.S
+++ b/arch/i386/kernel/entry.S
@@ -367,10 +367,6 @@ ENTRY(system_call)
CFI_ADJUST_CFA_OFFSET 4
SAVE_ALL
GET_THREAD_INFO(%ebp)
-   testl $TF_MASK,PT_EFLAGS(%esp)
-   jz no_singlestep
-   orl $_TIF_SINGLESTEP,TI_flags(%ebp)
-no_singlestep:
# system call tracing in operation / 
emulation
/* Note, _TIF_SECCOMP is bit number 8, and so it needs testw and not 
testb */
testw 
$(_TIF_SYSCALL_EMU|_TIF_SYSCALL_TRACE|_TIF_SECCOMP|_TIF_SYSCALL_AUDIT),TI_flags(%ebp)
@@ -385,6 +381,10 @@ syscall_exit:
# setting need_resched or sigpending
# between sampling and the iret
TRACE_IRQS_OFF
+   testl $TF_MASK,PT_EFLAGS(%esp)  # If tracing set singlestep flag on exit
+   jz no_singlestep
+   orl $_TIF_SINGLESTEP,TI_flags(%ebp)
+no_singlestep:
movl TI_flags(%ebp), %ecx
testw $_TIF_ALLWORK_MASK, %cx   # current->work
jne syscall_exit_work
-- 
1.5.2.4

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

[2.6.20.16 review 28/28] sky2: workaround for lost IRQ

[Willy Tarreau]

This patch restores a couple of workarounds from 2.6.16:
 * restart transmit moderation timer in case it expires during IRQ routine
 * default to having 10 HZ watchdog timer.
At this point it more important not to hang than to worry about the
power cost.

Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/net/sky2.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 38e75cf..aec8c59 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -95,7 +95,7 @@ static int disable_msi = 0;
 module_param(disable_msi, int, 0);
 MODULE_PARM_DESC(disable_msi, "Disable Message Signaled Interrupt (MSI)");
 
-static int idle_timeout = 0;
+static int idle_timeout = 100;
 module_param(idle_timeout, int, 0);
 MODULE_PARM_DESC(idle_timeout, "Watchdog timer for lost interrupts (ms)");
 
@@ -2341,6 +2341,13 @@ static int sky2_poll(struct net_device *dev0, int 
*budget)
 
work_done = sky2_status_intr(hw, work_limit);
if (work_done < work_limit) {
+   /* Bug/Errata workaround?
+* Need to kick the TX irq moderation timer.
+*/
+   if (sky2_read8(hw, STAT_TX_TIMER_CTRL) == TIM_START) {
+   sky2_write8(hw, STAT_TX_TIMER_CTRL, TIM_STOP);
+   sky2_write8(hw, STAT_TX_TIMER_CTRL, TIM_START);
+   }
netif_rx_complete(dev0);
 
sky2_read32(hw, B0_Y2_SP_LISR);
-- 
1.5.2.4

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

[2.6.20.16 review 23/28] mm: kill validate_anon_vma to avoid mapcount BUG

[Willy Tarreau]

validate_anon_vma gave a useful check on the integrity of the anon_vma list
when Andrea was developing obj rmap; but it was not enabled in SLES9
itself, nor in mainline, until Nick changed commented-out RMAP_DEBUG to
configurable CONFIG_DEBUG_VM in 2.6.17.  Now Petr Vandrovec reports that
its BUG_ON(mapcount > 10) can easily crash a CONFIG_DEBUG_VM=y system.

That limit was just an arbitrary number to protect against an infinite
loop.  We could raise it to something enormous (depending on sizeof struct
vma and size of memory?); but I rather think validate_anon_vma has outlived
its usefulness, and is better just removed - which gives a magnificent
performance boost to anything like Petr's test program ;)

Of course, a very long anon_vma list is bad news for preemption latency,
and I believe there has been one recent report of such: let's not forget
that, but validate_anon_vma only makes it worse not better.

Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
Cc: Petr Vandrovec <[EMAIL PROTECTED]>
Acked-by: Nick Piggin <[EMAIL PROTECTED]>
Cc: Andrea Arcangeli <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 mm/rmap.c |   24 +---
 1 files changed, 1 insertions(+), 23 deletions(-)

diff --git a/mm/rmap.c b/mm/rmap.c
index 7ce69c1..c30781c 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -53,24 +53,6 @@
 
 struct kmem_cache *anon_vma_cachep;
 
-static inline void validate_anon_vma(struct vm_area_struct *find_vma)
-{
-#ifdef CONFIG_DEBUG_VM
-   struct anon_vma *anon_vma = find_vma->anon_vma;
-   struct vm_area_struct *vma;
-   unsigned int mapcount = 0;
-   int found = 0;
-
-   list_for_each_entry(vma, &anon_vma->head, anon_vma_node) {
-   mapcount++;
-   BUG_ON(mapcount > 10);
-   if (vma == find_vma)
-   found = 1;
-   }
-   BUG_ON(!found);
-#endif
-}
-
 /* This must be called under the mmap_sem. */
 int anon_vma_prepare(struct vm_area_struct *vma)
 {
@@ -121,10 +103,8 @@ void __anon_vma_link(struct vm_area_struct *vma)
 {
struct anon_vma *anon_vma = vma->anon_vma;
 
-   if (anon_vma) {
+   if (anon_vma)
list_add_tail(&vma->anon_vma_node, &anon_vma->head);
-   validate_anon_vma(vma);
-   }
 }
 
 void anon_vma_link(struct vm_area_struct *vma)
@@ -134,7 +114,6 @@ void anon_vma_link(struct vm_area_struct *vma)
if (anon_vma) {
spin_lock(&anon_vma->lock);
list_add_tail(&vma->anon_vma_node, &anon_vma->head);
-   validate_anon_vma(vma);
spin_unlock(&anon_vma->lock);
}
 }
@@ -148,7 +127,6 @@ void anon_vma_unlink(struct vm_area_struct *vma)
return;
 
spin_lock(&anon_vma->lock);
-   validate_anon_vma(vma);
list_del(&vma->anon_vma_node);
 
/* We must garbage collect the anon_vma if it's empty */
-- 
1.5.2.4

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

[2.6.20.16 review 24/28] saa7134: fix thread shutdown handling

[Willy Tarreau]

This patch changes the test for the thread pid from >= 0 to > 0.

When the saa7134 driver initialization fails after a certain point, it goes
through the complete shutdown process for the driver.  Part of shutting it
down includes tearing down the thread for tv audio.

The test for tearing down the thread tests for >= 0.  Since the dev
structure is kzalloc'd, the test will always be true if we haven't tried to
start the thread yet.  We end up waiting on pid 0 to complete, which will
never happen, so we lock up.

This bug was observed in Novell Bugzilla 284718, when request_irq() failed.

Signed-off-by: Jeff Mahoney <[EMAIL PROTECTED]>
Acked-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/media/video/saa7134/saa7134-tvaudio.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/saa7134/saa7134-tvaudio.c 
b/drivers/media/video/saa7134/saa7134-tvaudio.c
index dd759d6..36b3fa3 100644
--- a/drivers/media/video/saa7134/saa7134-tvaudio.c
+++ b/drivers/media/video/saa7134/saa7134-tvaudio.c
@@ -1006,7 +1006,7 @@ int saa7134_tvaudio_init2(struct saa7134_dev *dev)
 int saa7134_tvaudio_fini(struct saa7134_dev *dev)
 {
/* shutdown tvaudio thread */
-   if (dev->thread.pid >= 0) {
+   if (dev->thread.pid > 0) {
dev->thread.shutdown = 1;
wake_up_interruptible(&dev->thread.wq);
wait_for_completion(&dev->thread.exit);
-- 
1.5.2.4

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

[2.6.20.16 review 15/28] dm crypt: disable barriers

[Willy Tarreau]

Disable barriers in dm-crypt because of current workqueue processing can
reorder requests.

This must be addresed later but for now disabling barriers is needed to
prevent data corruption.

Signed-off-by: Milan Broz <[EMAIL PROTECTED]>
Signed-off-by: Alasdair G Kergon <[EMAIL PROTECTED]>
Cc: Jens Axboe <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/md/dm-crypt.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 4c2471e..f68677d 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -954,6 +954,9 @@ static int crypt_map(struct dm_target *ti, struct bio *bio,
struct crypt_config *cc = ti->private;
struct crypt_io *io;
 
+   if (bio_barrier(bio))
+   return -EOPNOTSUPP;
+
io = mempool_alloc(cc->io_pool, GFP_NOIO);
io->target = ti;
io->base_bio = bio;
-- 
1.5.2.4

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

[2.6.20.16 review 19/28] sched: fix next_interval determination in idle_balance()

[Willy Tarreau]

Fix massive SMP imbalance on NUMA nodes observed on 2.6.21.5 with CFS.
(and later on reproduced without CFS as well).

The intervals of domains that do not have SD_BALANCE_NEWIDLE must be
considered for the calculation of the time of the next balance.
Otherwise we may defer rebalancing forever and nodes might stay idle for
very long times.

Siddha also spotted that the conversion of the balance interval to
jiffies is missing. Fix that to.

From: Srivatsa Vaddagiri <[EMAIL PROTECTED]>

also continue the loop if !(sd->flags & SD_LOAD_BALANCE).

Tested-by: Paul E. McKenney <[EMAIL PROTECTED]>

It did in fact trigger under all three of mainline, CFS, and -rt
including CFS -- see below for a couple of emails from last Friday
giving results for these three on the AMD box (where it happened) and on
a single-quad NUMA-Q system (where it did not, at least not with such
severity).

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 kernel/sched.c |   22 +-
 1 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
index 62db30c..907ab05 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -2814,17 +2814,21 @@ static void idle_balance(int this_cpu, struct rq 
*this_rq)
unsigned long next_balance = jiffies + 60 *  HZ;
 
for_each_domain(this_cpu, sd) {
-   if (sd->flags & SD_BALANCE_NEWIDLE) {
+   unsigned long interval;
+
+   if (!(sd->flags & SD_LOAD_BALANCE))
+   continue;
+
+   if (sd->flags & SD_BALANCE_NEWIDLE)
/* If we've pulled tasks over stop searching: */
pulled_task = load_balance_newidle(this_cpu,
-   this_rq, sd);
-   if (time_after(next_balance,
- sd->last_balance + sd->balance_interval))
-   next_balance = sd->last_balance
-   + sd->balance_interval;
-   if (pulled_task)
-   break;
-   }
+   this_rq, sd);
+
+   interval = msecs_to_jiffies(sd->balance_interval);
+   if (time_after(next_balance, sd->last_balance + interval))
+   next_balance = sd->last_balance + interval;
+   if (pulled_task)
+   break;
}
if (!pulled_task)
/*
-- 
1.5.2.4

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

[2.6.20.16 review 17/28] dm crypt: fix avoid cloned bio ref after free

[Willy Tarreau]

Do not access the bio after generic_make_request

We should never access a bio after generic_make_request - there's no guarantee
it still exists.

Signed-off-by: Olaf Kirch <[EMAIL PROTECTED]>
Signed-off-by: Alasdair G Kergon <[EMAIL PROTECTED]>
Cc: Jens Axboe <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/md/dm-crypt.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index bffaf1c..28831a9 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -655,9 +655,12 @@ static void process_write(struct crypt_io *io)
 
generic_make_request(clone);
 
+   /* Do not reference clone after this - it
+* may be gone already. */
+
/* out of memory -> run queues */
if (remaining)
-   congestion_wait(bio_data_dir(clone), HZ/100);
+   congestion_wait(WRITE, HZ/100);
}
 }
 
-- 
1.5.2.4

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

[2.6.20.16 review 21/28] audit: fix oops removing watch if audit disabled

[Willy Tarreau]

Removing a watched file will oops if audit is disabled (auditctl -e 0).

To reproduce:
- auditctl -e 1
- touch /tmp/foo
- auditctl -w /tmp/foo
- auditctl -e 0
- rm /tmp/foo (or mv)

Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Cc: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 kernel/auditfilter.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index 9c8c232..5a75657 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -905,7 +905,7 @@ static void audit_update_watch(struct audit_parent *parent,
 
/* If the update involves invalidating rules, do the inode-based
 * filtering now, so we don't omit records. */
-   if (invalidating &&
+   if (invalidating && current->audit_context &&
audit_filter_inodes(current, current->audit_context) == 
AUDIT_RECORD_CONTEXT)
audit_set_auditable(current->audit_context);
 
-- 
1.5.2.4

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

[2.6.20.16 review 16/28] dm crypt: fix call to clone_init

[Willy Tarreau]

Call clone_init early

We need to call clone_init as early as possible - at least before call
bio_put(clone) in any error path.  Otherwise, the destructor will try to
dereference bi_private, which may still be NULL.

Signed-off-by: Olaf Kirch <[EMAIL PROTECTED]>
Signed-off-by: Alasdair G Kergon <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/md/dm-crypt.c |   12 +++-
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index f68677d..bffaf1c 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -107,6 +107,8 @@ struct crypt_config {
 
 static struct kmem_cache *_crypt_io_pool;
 
+static void clone_init(struct crypt_io *, struct bio *);
+
 /*
  * Different IV generation algorithms:
  *
@@ -379,9 +381,10 @@ static int crypt_convert(struct crypt_config *cc,
  * May return a smaller bio when running out of pages
  */
 static struct bio *
-crypt_alloc_buffer(struct crypt_config *cc, unsigned int size,
+crypt_alloc_buffer(struct crypt_io *io, unsigned int size,
struct bio *base_bio, unsigned int *bio_vec_idx)
 {
+   struct crypt_config *cc = io->target->private;
struct bio *clone;
unsigned int nr_iovecs = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
gfp_t gfp_mask = GFP_NOIO | __GFP_HIGHMEM;
@@ -396,7 +399,7 @@ crypt_alloc_buffer(struct crypt_config *cc, unsigned int 
size,
if (!clone)
return NULL;
 
-   clone->bi_destructor = dm_crypt_bio_destructor;
+   clone_init(io, clone);
 
/* if the last bio was not complete, continue where that one ended */
clone->bi_idx = *bio_vec_idx;
@@ -562,6 +565,7 @@ static void clone_init(struct crypt_io *io, struct bio 
*clone)
clone->bi_end_io  = crypt_endio;
clone->bi_bdev= cc->dev->bdev;
clone->bi_rw  = io->base_bio->bi_rw;
+   clone->bi_destructor = dm_crypt_bio_destructor;
 }
 
 static void process_read(struct crypt_io *io)
@@ -585,7 +589,6 @@ static void process_read(struct crypt_io *io)
}
 
clone_init(io, clone);
-   clone->bi_destructor = dm_crypt_bio_destructor;
clone->bi_idx = 0;
clone->bi_vcnt = bio_segments(base_bio);
clone->bi_size = base_bio->bi_size;
@@ -615,7 +618,7 @@ static void process_write(struct crypt_io *io)
 * so repeat the whole process until all the data can be handled.
 */
while (remaining) {
-   clone = crypt_alloc_buffer(cc, base_bio->bi_size,
+   clone = crypt_alloc_buffer(io, base_bio->bi_size,
   io->first_clone, &bvec_idx);
if (unlikely(!clone)) {
dec_pending(io, -ENOMEM);
@@ -631,7 +634,6 @@ static void process_write(struct crypt_io *io)
return;
}
 
-   clone_init(io, clone);
clone->bi_sector = cc->start + sector;
 
if (!io->first_clone) {
-- 
1.5.2.4

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

[2.6.20.16 review 08/28] x86_64: allocate sparsemem memmap above 4G

[Willy Tarreau]

On systems with huge amount of physical memory, VFS cache and memory memmap
may eat all available system memory under 4G, then the system may fail to
allocate swiotlb bounce buffer.

There was a fix for this issue in arch/x86_64/mm/numa.c, but that fix dose
not cover sparsemem model.

This patch add fix to sparsemem model by first try to allocate memmap above
4G.

Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]>
Acked-by: Suresh Siddha <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
[chrisw: trivial backport]
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 arch/x86_64/mm/init.c   |6 ++
 include/linux/bootmem.h |1 +
 mm/sparse.c |   11 +++
 3 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/x86_64/mm/init.c b/arch/x86_64/mm/init.c
index 2968b90..2489aa7 100644
--- a/arch/x86_64/mm/init.c
+++ b/arch/x86_64/mm/init.c
@@ -766,3 +766,9 @@ int in_gate_area_no_task(unsigned long addr)
 {
return (addr >= VSYSCALL_START) && (addr < VSYSCALL_END);
 }
+
+void *alloc_bootmem_high_node(pg_data_t *pgdat, unsigned long size)
+{
+   return __alloc_bootmem_core(pgdat->bdata, size,
+   SMP_CACHE_BYTES, (4UL*1024*1024*1024), 0);
+}
diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h
index 2275f27..8f820e4 100644
--- a/include/linux/bootmem.h
+++ b/include/linux/bootmem.h
@@ -59,6 +59,7 @@ extern void *__alloc_bootmem_core(struct bootmem_data *bdata,
  unsigned long align,
  unsigned long goal,
  unsigned long limit);
+extern void *alloc_bootmem_high_node(pg_data_t *pgdat, unsigned long size);
 
 #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
 extern void reserve_bootmem(unsigned long addr, unsigned long size);
diff --git a/mm/sparse.c b/mm/sparse.c
index ac26eb0..faa08e2 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -209,6 +209,12 @@ static int sparse_init_one_section(struct mem_section *ms,
return 1;
 }
 
+__attribute__((weak))
+void *alloc_bootmem_high_node(pg_data_t *pgdat, unsigned long size)
+{
+   return NULL;
+}
+
 static struct page *sparse_early_mem_map_alloc(unsigned long pnum)
 {
struct page *map;
@@ -219,6 +225,11 @@ static struct page *sparse_early_mem_map_alloc(unsigned 
long pnum)
if (map)
return map;
 
+   map = alloc_bootmem_high_node(NODE_DATA(nid),
+   sizeof(struct page) * PAGES_PER_SECTION);
+   if (map)
+   return map;
+
map = alloc_bootmem_node(NODE_DATA(nid),
sizeof(struct page) * PAGES_PER_SECTION);
if (map)
-- 
1.5.2.4

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

[2.6.20.16 review 09/28] sparsemem: fix oops in x86_64 show_mem

[Willy Tarreau]

We aren't sampling for holes in memory. Thus we encounter a section hole with
empty section map pointer for SPARSEMEM and OOPs for show_mem. This issue
has been seen in 2.6.21, current git and current mm. This patch is for
2.6.21 stable. It was tested against sparsemem.

Previous to commit f0a5a58aa812b31fd9f197c4ba48245942364eae memory_present
was called for node_start_pfn to node_end_pfn. This would cover the hole(s)
with reserved pages and valid sections. Most SPARSEMEM supported arches
do a pfn_valid check in show_mem before computing the page structure address.

This issue was brought to my attention on IRC by Arnaldo Carvalho de Melo at
[EMAIL PROTECTED] Thanks to Arnaldo for testing.

Signed-off-by: Bob Picco <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 arch/x86_64/mm/init.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/x86_64/mm/init.c b/arch/x86_64/mm/init.c
index 2489aa7..e67cc4f 100644
--- a/arch/x86_64/mm/init.c
+++ b/arch/x86_64/mm/init.c
@@ -72,6 +72,8 @@ void show_mem(void)
 
for_each_online_pgdat(pgdat) {
for (i = 0; i < pgdat->node_spanned_pages; ++i) {
+   if (!pfn_valid(pgdat->node_start_pfn + i))
+   continue;
page = pfn_to_page(pgdat->node_start_pfn + i);
total++;
if (PageReserved(page))
-- 
1.5.2.4

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

[2.6.20.16 review 14/28] md: Fix bug in error handling during raid1 repair.

[Willy Tarreau]

If raid1/repair (which reads all block and fixes any differences
it finds) hits a read error, it doesn't reset the bio for writing
before writing correct data back, so the read error isn't fixed,
and the device probably gets a zero-length write which it might
complain about.

Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/md/raid1.c |   21 ++---
 1 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 97ee870..b20c6e9 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -1235,17 +1235,24 @@ static void sync_request_write(mddev_t *mddev, r1bio_t 
*r1_bio)
}
r1_bio->read_disk = primary;
for (i=0; iraid_disks; i++)
-   if (r1_bio->bios[i]->bi_end_io == end_sync_read &&
-   test_bit(BIO_UPTODATE, &r1_bio->bios[i]->bi_flags)) 
{
+   if (r1_bio->bios[i]->bi_end_io == end_sync_read) {
int j;
int vcnt = r1_bio->sectors >> (PAGE_SHIFT- 9);
struct bio *pbio = r1_bio->bios[primary];
struct bio *sbio = r1_bio->bios[i];
-   for (j = vcnt; j-- ; )
-   if 
(memcmp(page_address(pbio->bi_io_vec[j].bv_page),
-  
page_address(sbio->bi_io_vec[j].bv_page),
-  PAGE_SIZE))
-   break;
+
+   if (test_bit(BIO_UPTODATE, &sbio->bi_flags)) {
+   for (j = vcnt; j-- ; ) {
+   struct page *p, *s;
+   p = pbio->bi_io_vec[j].bv_page;
+   s = sbio->bi_io_vec[j].bv_page;
+   if (memcmp(page_address(p),
+  page_address(s),
+  PAGE_SIZE))
+   break;
+   }
+   } else
+   j = 0;
if (j >= 0)
mddev->resync_mismatches += 
r1_bio->sectors;
if (j < 0 || test_bit(MD_RECOVERY_CHECK, 
&mddev->recovery)) {
-- 
1.5.2.4

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

[2.6.20.16 review 13/28] md: Fix two raid10 bugs.

[Willy Tarreau]

1/ When resyncing a degraded raid10 which has more than 2 copies of each block,
  garbage can get synced on top of good data.

2/ We round the wrong way in part of the device size calculation, which
  can cause confusion.

Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/md/raid10.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 82249a6..9eb66c1 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1867,6 +1867,7 @@ static sector_t sync_request(mddev_t *mddev, sector_t 
sector_nr, int *skipped, i
int d = r10_bio->devs[i].devnum;
bio = r10_bio->devs[i].bio;
bio->bi_end_io = NULL;
+   clear_bit(BIO_UPTODATE, &bio->bi_flags);
if (conf->mirrors[d].rdev == NULL ||
test_bit(Faulty, &conf->mirrors[d].rdev->flags))
continue;
@@ -2037,6 +2038,11 @@ static int run(mddev_t *mddev)
/* 'size' is now the number of chunks in the array */
/* calculate "used chunks per device" in 'stride' */
stride = size * conf->copies;
+
+   /* We need to round up when dividing by raid_disks to
+* get the stride size.
+*/
+   stride += conf->raid_disks - 1;
sector_div(stride, conf->raid_disks);
mddev->size = stride  << (conf->chunk_shift-1);
 
-- 
1.5.2.4

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

[2.6.20.16 review 02/28] md: Avoid overflow in raid0 calculation with large components.

[Willy Tarreau]

If a raid0 has a component device larger than 4TB, and is accessed on
a 32bit machines, then as 'chunk' is unsigned lock,
   chunk << chunksize_bits
can overflow (this can be as high as the size of the device in KB).
chunk itself will not overflow (without triggering a BUG).

So change 'chunk' to be 'sector_t, and get rid of the 'BUG' as it becomes
impossible to hit.

Cc: "Jeff Zheng" <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/md/raid0.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
index dfe3214..2c404f7 100644
--- a/drivers/md/raid0.c
+++ b/drivers/md/raid0.c
@@ -415,7 +415,7 @@ static int raid0_make_request (request_queue_t *q, struct 
bio *bio)
raid0_conf_t *conf = mddev_to_conf(mddev);
struct strip_zone *zone;
mdk_rdev_t *tmp_dev;
-   unsigned long chunk;
+   sector_t chunk;
sector_t block, rsect;
const int rw = bio_data_dir(bio);
 
@@ -470,7 +470,6 @@ static int raid0_make_request (request_queue_t *q, struct 
bio *bio)
 
sector_div(x, zone->nb_dev);
chunk = x;
-   BUG_ON(x != (sector_t)chunk);
 
x = block >> chunksize_bits;
tmp_dev = zone->dev[sector_div(x, zone->nb_dev)];
-- 
1.5.2.4

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

[2.6.20.16 review 01/28] i386: Fix K8/core2 oprofile on multiple CPUs

[Willy Tarreau]

Only try to allocate MSRs once instead of for every CPU.

This assumes the MSRs are the same on all CPUs which is currently
true. P4-HT is a special case for different SMT threads, but the code
always saves/restores all MSRs so it works identical.

Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 arch/i386/oprofile/nmi_int.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/arch/i386/oprofile/nmi_int.c b/arch/i386/oprofile/nmi_int.c
index 3700eef..be4a9a8 100644
--- a/arch/i386/oprofile/nmi_int.c
+++ b/arch/i386/oprofile/nmi_int.c
@@ -131,7 +131,6 @@ static void nmi_save_registers(void * dummy)
 {
int cpu = smp_processor_id();
struct op_msrs * msrs = &cpu_msrs[cpu];
-   model->fill_in_addresses(msrs);
nmi_cpu_save_registers(msrs);
 }
 
@@ -195,6 +194,7 @@ static struct notifier_block profile_exceptions_nb = {
 static int nmi_setup(void)
 {
int err=0;
+   int cpu;
 
if (!allocate_msrs())
return -ENOMEM;
@@ -207,6 +207,13 @@ static int nmi_setup(void)
/* We need to serialize save and setup for HT because the subset
 * of msrs are distinct for save and setup operations
 */
+
+   /* Assume saved/restored counters are the same on all CPUs */
+   model->fill_in_addresses(&cpu_msrs[0]);
+   for_each_possible_cpu (cpu) {
+   if (cpu != 0)
+   cpu_msrs[cpu] = cpu_msrs[0];
+   }
on_each_cpu(nmi_save_registers, NULL, 0, 1);
on_each_cpu(nmi_cpu_setup, NULL, 0, 1);
nmi_enabled = 1;
-- 
1.5.2.4

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

[2.6.20.16 review 05/28] Char: cyclades, fix deadlock

[Willy Tarreau]

An omitted unlock.

Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/char/cyclades.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/char/cyclades.c b/drivers/char/cyclades.c
index 3ffa080..e4e0ccb 100644
--- a/drivers/char/cyclades.c
+++ b/drivers/char/cyclades.c
@@ -1102,6 +1102,7 @@ static void cyy_intr_chip(struct cyclades_card *cinfo, 
int chip,
 
if (data & info->ignore_status_mask) {
info->icount.rx++;
+   spin_unlock(&cinfo->card_lock);
return;
}
if (tty_buffer_request_room(tty, 1)) {
-- 
1.5.2.4

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

[2.6.20.16 review 00/28] 2.6.20.16 -stable review

[Willy Tarreau]

I proposed Chris and Greg to continue issuing a few more 2.6.20 releases
during the time needed for 2.6.21 and 2.6.22 to show a significant drop
in their patch rates, which hopefully will be just a matter of a few
releases.

My goal is *not* to do all the hard work they do, but just to backport
from their patches those which are meaningful for 2.6.20. For this
reason, 2.6.20 releases will always be slightly late and should not
contain patches not merged in more recent releases.

My intent with this version is to catch up with 2.6.21.7. Other patches
are already pending for future releases, but one thing at a time. I'm
trying to follow the same review/release process, so 28 patches will
be posted for review in response to this message.

If some people think it's useless to repost individual patches that have
already been reviewed in more recent versions, I'm open to adapting the
process (eg: switch to one mail for -rc and one for release like Adrian
does with 2.6.16).

The rolled up patch can be found here :
   ftp.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.20.16-rc1.gz

Responses should be made by August 13, 2007, 20:00:00 UTC. Anything
received after that time might be too late.

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

[2.6.20.16 review 03/28] md: Dont write more than is required of the last page of a bitmap

[Willy Tarreau]

It is possible that real data or metadata follows the bitmap
without full page alignment.
So limit the last write to be only the required number of bytes,
rounded up to the hard sector size of the device.

Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/md/bitmap.c |   17 -
 include/linux/raid/bitmap.h |1 +
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
index cef1287..550ac72 100644
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -255,19 +255,25 @@ static struct page *read_sb_page(mddev_t *mddev, long 
offset, unsigned long inde
 
 }
 
-static int write_sb_page(mddev_t *mddev, long offset, struct page *page, int 
wait)
+static int write_sb_page(struct bitmap *bitmap, struct page *page, int wait)
 {
mdk_rdev_t *rdev;
struct list_head *tmp;
+   mddev_t *mddev = bitmap->mddev;
 
ITERATE_RDEV(mddev, rdev, tmp)
if (test_bit(In_sync, &rdev->flags)
-   && !test_bit(Faulty, &rdev->flags))
+   && !test_bit(Faulty, &rdev->flags)) {
+   int size = PAGE_SIZE;
+   if (page->index == bitmap->file_pages-1)
+   size = roundup(bitmap->last_page_size,
+  bdev_hardsect_size(rdev->bdev));
md_super_write(mddev, rdev,
-  (rdev->sb_offset<<1) + offset
+  (rdev->sb_offset<<1) + bitmap->offset
   + page->index * (PAGE_SIZE/512),
-  PAGE_SIZE,
+  size,
   page);
+   }
 
if (wait)
md_super_wait(mddev);
@@ -282,7 +288,7 @@ static int write_page(struct bitmap *bitmap, struct page 
*page, int wait)
struct buffer_head *bh;
 
if (bitmap->file == NULL)
-   return write_sb_page(bitmap->mddev, bitmap->offset, page, wait);
+   return write_sb_page(bitmap, page, wait);
 
bh = page_buffers(page);
 
@@ -923,6 +929,7 @@ static int bitmap_init_from_disk(struct bitmap *bitmap, 
sector_t start)
}
 
bitmap->filemap[bitmap->file_pages++] = page;
+   bitmap->last_page_size = count;
}
paddr = kmap_atomic(page, KM_USER0);
if (bitmap->flags & BITMAP_HOSTENDIAN)
diff --git a/include/linux/raid/bitmap.h b/include/linux/raid/bitmap.h
index 6db9a4c..dd5a05d 100644
--- a/include/linux/raid/bitmap.h
+++ b/include/linux/raid/bitmap.h
@@ -232,6 +232,7 @@ struct bitmap {
struct page **filemap; /* list of cache pages for the file */
unsigned long *filemap_attr; /* attributes associated w/ filemap pages 
*/
unsigned long file_pages; /* number of pages in the file */
+   int last_page_size; /* bytes in the last page */
 
unsigned long flags;
 
-- 
1.5.2.4

-- 
-
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.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip

[Andrey Borzenkov]

On Saturday 30 June 2007, Bjorn Helgaas wrote:
> On Saturday 30 June 2007 01:16:18 am Andrey Borzenkov wrote:
> > > This patch fixes the 2.6.22 regression:
> > > "no irda0 interface (2.6.21 was OK), smsc does not find chip"
> >
> > does not work, sorry.
>
> Sigh ;-)  Thanks for your patience in dealing with this.
>

This stopped working again in 2.6.23-rc. In 2.6.22 we decided to disable PnP 
by default; it is apparently enabled now and fails to activte IrDA 
completely. So it moves to post-2.6.22 regressions :)

let me know which information you need

[ 2192.666450] pnp: PnP ACPI init
[ 2192.666589] ACPI: bus type pnp registered
[ 2192.686035] pnp: Device 00:0a activated.
[ 2192.686089]  00:0a: SMCf010 not responding at SIR 0x100, FIR 0x2e8; 
auto-configuring
[ 2192.687610] pnp: Device 00:0a disabled.
[ 2192.693179] pnp: Device 00:0a activated.
[ 2192.693210]  00:0a: not responding at SIR 0x100, FIR 0x2e8; swapping 
SIR/FIR and reconfiguring
[ 2192.694720] pnp: Device 00:0a disabled.
[ 2192.701232] pnp: Device 00:0a activated.
[ 2192.701259]  00:0a: responds at SIR 0x2e8, FIR 0x100
[ 2192.709309] pnp: PnP ACPI: found 12 devices
[ 2192.709351] ACPI: ACPI bus type pnp unregistered



[ 2207.986550] Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC 
IrDA chip, pre-configuring device.
[ 2207.986587] Activated ALi 1533 ISA bridge port 0x02e8.
[ 2207.986602] Activated ALi 1533 ISA bridge port 0x02f8.
[ 2207.986817] found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): 
LPC47N227
[ 2207.986851] smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, 
mode: 0x0e
[ 2207.986873] smsc_ircc_present: can't get sir_base of 0x2e8




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