date:20071030

Re: [PATCH]bluetooth: hci_sysfs connection bus_id add support for diffrent hci device

2007-10-30 Thread Marcel Holtmann

Hi Dave,

> > diff -upr linux/net/bluetooth/hci_sysfs.c 
> > linux.new/net/bluetooth/hci_sysfs.c
> > --- linux/net/bluetooth/hci_sysfs.c 2007-10-31 10:21:00.0 +0800
> > +++ linux.new/net/bluetooth/hci_sysfs.c 2007-10-31 10:21:55.0 
> > +0800
> > @@ -302,7 +302,8 @@ void hci_conn_add_sysfs(struct hci_conn 
> > conn->dev.release = bt_release;
> >  
> > snprintf(conn->dev.bus_id, BUS_ID_SIZE,
> > -   "%s%2.2X%2.2X%2.2X%2.2X%2.2X%2.2X",
> > +   "%s%s%2.2X%2.2X%2.2X%2.2X%2.2X%2.2X",
> > +   hdev->name,
> > conn->type == ACL_LINK ? "acl" : "sco",
> > ba->b[5], ba->b[4], ba->b[3],
> > ba->b[2], ba->b[1], ba->b[0]);
> 
> This might not work.
> 
> Your device's name is already 15 characters long,
> BUS_ID_SIZE is 20, and it seems hdev->name could
> easily overflow the 4 or 5 characters of space
> remaining.

and should also be not needed since their parents are different. However
we had to add the connections to a bus. Otherwise the userspace will
never see them. I have to think about the right solution for this
problem.

Regards

Marcel


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Swap delay accounting, include lock_page() delays

2007-10-30 Thread Balbir Singh



Reported-by: Nick Piggin <[EMAIL PROTECTED]>

The delay incurred in lock_page() should also be accounted in swap delay
accounting

Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---

 mm/memory.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN mm/swapfile.c~fix-delay-accounting-swap-accounting mm/swapfile.c
diff -puN mm/memory.c~fix-delay-accounting-swap-accounting mm/memory.c
--- linux-2.6-latest/mm/memory.c~fix-delay-accounting-swap-accounting   
2007-10-31 12:58:05.0 +0530
+++ linux-2.6-latest-balbir/mm/memory.c 2007-10-31 13:02:50.0 +0530
@@ -2084,9 +2084,9 @@ static int do_swap_page(struct mm_struct
count_vm_event(PGMAJFAULT);
}
 
-   delayacct_clear_flag(DELAYACCT_PF_SWAPIN);
mark_page_accessed(page);
lock_page(page);
+   delayacct_clear_flag(DELAYACCT_PF_SWAPIN);
 
/*
 * Back out if somebody else already faulted in this pte.
_

-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Huawei E220 and usb storage

2007-10-30 Thread Norbert Preining

On Di, 30 Okt 2007, Pete Zaitcev wrote:
> > printk(KERN_ERR "ENTERING usb_stor_huawei_e220_init!\n");
> > at the beginning of the function but it never showed up in my log files.
> > So it seems that the UNUSUAL_DEV entry does not match.
> 
> This doesn't seem to be possible, considering the /proc/bus/usb/devices
> that you posted. I would rather suspect that you forgot to perform

Compiling both -- usb-storage and option/usb-serial -- as modules did
work.

Ok, thanks a lot.

I assume that is because the built-in usb-serial/option did grab the
device so the init function wasn't executed. Putting both into modules
allowed that usb-storage grabbed the device first.

Anyway, my interpretation without any knowledge.

Best wishes

Norbert

---
Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
SCONSER (n.)
A person who looks around then when talking to you, to see if there's
anyone more interesting about.
--- Douglas Adams, The Meaning of Liff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 regression: accessing invalid mmap'ed memory from gdb causes unkillable spinning

2007-10-30 Thread David Miller

From: Nick Piggin <[EMAIL PROTECTED]>
Date: Wed, 31 Oct 2007 08:41:06 +0100

> On Tue, Oct 30, 2007 at 11:56:00PM -0700, David Miller wrote:
> > From: Nick Piggin <[EMAIL PROTECTED]>
> > Date: Wed, 31 Oct 2007 07:42:21 +0100
> > 
> > Anyways, my core suggestion is to add a hook here so platforms can
> > do the remote register fetch if they want.
> 
> You could possibly even do a generic "best effort" kind of thing with
> regular IPIs, that will timeout and continue if some CPUs don't handle
> them, and should be pretty easy to get working with existing smp_call_
> function stuff. Not exactly clean, but it would be better than nothing.

Without a doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 regression: accessing invalid mmap'ed memory from gdb causes unkillable spinning

2007-10-30 Thread Nick Piggin

On Tue, Oct 30, 2007 at 11:56:00PM -0700, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Wed, 31 Oct 2007 07:42:21 +0100
> 
> > Sysrq+T fails to show the stack trace of a running task. Presumably this
> > is to avoid a garbled stack, however it can often be useful, and besides
> > there is no guarantee that the task won't start running in the middle of
> > show_stack(). If there are any correctness issues, then the archietcture
> > would have to take further steps to ensure the task is not running.
> > 
> > Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
> 
> This is useful.
> 
> Even more useful would be a show_regs() on the cpu where running tasks
> are running.  If not a full show_regs() at least a program counter.

Yes, that's something I've needed as well. And I doubt that we're
very unusual among kernel developers in this regard ;)
 

> That's usually what you're trying to debug and we provide nearly no
> way to handle: some task is stuck in a loop in kernel mode and you
> need to know exactly where that is.
> 
> This is pretty easy to do on sparc64.  In fact I can capture remote
> cpu registers even when that CPU's interrupts are disabled.  I suppose
> other arches could do a NMI'ish register capture like this as well.
> 
> I have a few bug reports that I can't make more progress on because I
> currently can't ask users to do something to fetch the registers on
> the seemingly hung processor.  This is why I'm harping on this so
> much :-)
> 
> Anyways, my core suggestion is to add a hook here so platforms can
> do the remote register fetch if they want.

You could possibly even do a generic "best effort" kind of thing with
regular IPIs, that will timeout and continue if some CPUs don't handle
them, and should be pretty easy to get working with existing smp_call_
function stuff. Not exactly clean, but it would be better than nothing.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: tipc_config.h requires linux/string.h, which does not exist in exported headers

2007-10-30 Thread Alex Riesen

David Miller, Wed, Oct 31, 2007 05:56:16 +0100:
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 836062b..c5d3fca 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -3,16 +3,14 @@
>  
>  /* We don't want strings.h stuff being user by user stuff by accident */
>  

While at it, could you fix this typo: "being use_d_ by user stuff by accident"?

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

Re: [dm-devel] Re: dm: bounce_pfn limit added

2007-10-30 Thread Hannes Reinecke

Vasily Averin wrote:
> Alasdair G Kergon wrote:
>> So currently we treat bounce_pfn as a property that does not need to be
>> propagated through the stack.
>>
>> But is that the right approach?
>> - Is there a blk_queue_bounce() missing either from dm or elsewhere?
>>   (And BTW can the bio_alloc() that lurks within lead to deadlock?)
>>
>> Firstly, what's going wrong?
>> - What is the dm table you are using?  (output of 'dmsetup table')
>>   - Which dm targets and with how many underlying devices?
>> - Which underlying driver?
>> - Is this direct I/O to the block device from userspace, or via some
>> filesystem or what?
> 
> On my testnode I have  6 Gb memory (1Gb normal zone for i386 kernels),
> i2o hardware and lvm over i2o.
> 
> [EMAIL PROTECTED] ~]# dmsetup table
> vzvg-vz: 0 10289152 linear 80:5 384
> vzvg-vzt: 0 263127040 linear 80:5 10289536
> [EMAIL PROTECTED] ~]# cat /proc/partitions
> major minor  #blocks  name
> 
>   80 0  143374336 i2o/hda
>   80 1 514048 i2o/hda1
>   80 24096575 i2o/hda2
>   80 32040255 i2o/hda3
>   80 4  1 i2o/hda4
>   80 5  136721151 i2o/hda5
>  253 05144576 dm-0
>  253 1  131563520 dm-1
> 
> Diotest from LTP test suite with ~1Mb buffer size and files on dm-over-i2o
> paritions corrupts i2o_iop0_msg_inpool slab.
> 
> I2o on this node is able to handle only requests with up to 38 segments. 
> Device
> mapper correctly creates such requests and as you know it uses
> max_pfn=BLK_BOUNCE_ANY. When this request translates to underlying device, it
> clones bio and cleans BIO_SEG_VALID flag.
> 
> In this way underlying device calls blk_recalc_rq_segments() to recount number
> of segments. However blk_recalc_rq_segments uses bounce_pfn=BLK_BOUNCE_HIGH
> taken from underlying device. As result number of segments become over than
> max_hw_segments limit.
> 
> Unfortunately there is not any checks and when i2o driver handles this 
> incorrect
> request it fills the memory out of i2o_iop0_msg_inpool slab.
> 
We actually had a similar issue with some raid drivers (gdth iirc), and Neil 
Brown
did a similar patch for it. These were his comments on it:
>
> dm handles max_hw_segments by using an 'io_restrictions' structure
> that keeps the most restrictive values from all component devices.
>
> So it should not allow more than max_hw_segments.
> 
> However I just notices that it does not preserve bounce_pfn as a restriction.
> So when the request gets down to the driver, it may be split up in to more
> segments than was expected up at the dm level.
> 
So I guess we should take this.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries & Storage
[EMAIL PROTECTED] +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 09/14] Blackfin SPI driver: Fix SPI driver to work with SPI flash ST25P16 on bf548

2007-10-30 Thread Bryan Wu


On Wed, 2007-10-31 at 00:11 -0700, David Brownell wrote:
> On Tuesday 30 October 2007, Bryan Wu wrote:
> > Maybe there are some confusion of mixing up the spi_trasnfer.speed_hz
> > with the spi_device.max_speed_hz.
> > 
> > spi_device.max_speed_hz comes from spi_board_info.max_speed_hz, it is
> > for the default max speed value.
> 
> It's initialized from board_info, yes.  Drivers can override it
> using spi_setup().
> 
> One would expect they only override _downwards_ but that's not
> guaranteed anywhere.  A driver might have a way to establish that
> this particular board can run faster, for example.
> 

IMO, the spi_transfer.speed_hz <= spi_board_info.max_speed_hz and if
spi_trasnfer.speed_hz is 0, we should use spi_board_info.max_speed_hz.
>From the meaning of max_speed_hz, the spi_transfer.speed_hz should not
beyond max_speed_hz.

In your explanation, the max_speed_hz is just a default value. the
transfer speed_hz can beyond max_speed_hz. We found the bug in M25P16
should be related this missing checking of the transfer  speed_hz.

> 
> > spi_transfer.speed_hz comes from upper applications for each spi
> > transfer setting.
> 
> Certainly; all spi_transfer records come from applications!
> If that value is zero, that transfer segment uses the limit
> from the spi_device ... otherwise, it can differ.  Again,
> the limits can vary based on devise characteristics; maybe
> it can't feed data as fast for some commands.
> 
> (ISTR the M25P16 in $SUBJECT has two read commands, one of
> which is only usable at clock rates below 33 MHz or so, but
> most other commands can work above that speed just fine.)
> 
OK, We check it on Blackfin board.
-Bryan Wu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Major SATA / EXT3 Issue?

2007-10-30 Thread Theodore Tso

On Tue, Oct 30, 2007 at 03:59:24PM +0200, Heikki Orsila wrote:
> 3. fsck -p on boot failed
> 
> (it is very probable not many files were corrupted at this stage)

Maybe...
> 
> 4. I ran fsck.ext3 -y
> 
> => that corrupted lots and lots of files. This went 
> into a loop, the fsck.ext3 restarted checking over and over again.

It's possible that e2fsck corrupted the files, but they also could
have been corrupted earlier by the earlier I/O errors.  There are some
relatively rare filesystem corruptions which e2fsck doesn't handle as
gracefully as it should, though, I will admit.  I would need to see
the e2fsck transcript to be sure. 

Were there any messages about needing to relocate inode tables by any
chance?

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

[2.6.24-rc1-git] Warning with make tags and cscope

2007-10-30 Thread Kamalesh Babulal

Hi,

Get following warning while building tags and cscope index files

$ make tags -j 2
  MAKE   tags
find: arch/i386: No such file or directory
find: arch/i386: No such file or directory
find: arch/i386: No such file or directory
$ make cscope -j 2
  FILELST cscope.files
find: arch/i386: No such file or directory
  MAKEcscope.out

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 0/2] readdir() as an inode operation

2007-10-30 Thread Theodore Tso

On Tue, Oct 30, 2007 at 04:26:04PM +0100, Jan Kara wrote:
> > This is a first try to move readdir() to become an inode operation. This is
> > necessary for a VFS implementation of "something like union-mounts" where a
> > readdir() needs to read the directory contents of multiple directories.
> > Besides that the new interface is no longer giving the struct file to the
> > filesystem implementations anymore.
> > 
> > Comments, please?
>   Hmm, are you sure there are no users which keep some per-struct-file
> information for directories? File offset is one such obvious thing which
> you've handled but actually filesystem with more complicated structure
> of directory may remember some hints about where we really are, keep
> some readahead information or so...

For example, the ext3 filesystem, when it is supported hash tree, does
exactly this.  See ext3_htree_store_dirent() in fs/ext3/dir.c and
ext3_htree_fill_tree() in fs/ext3/namei.c.

So your patch would break ext3 htree support.

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

[RFC] mempolicy minor code cleanups

2007-10-30 Thread Paul Jackson

From: Paul Jackson <[EMAIL PROTECTED]>

Some minor code cleanups for mm/mempolicy.c.

This patch should have been sent out before,
to be applied first to 2.6.23-mm1, -before-
another patch I sent out an hour ago:

[RFC] cpuset relative memory policies - second choice

Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>

---
 include/linux/mempolicy.h |5 +++--
 mm/mempolicy.c|   20 ++--
 2 files changed, 13 insertions(+), 12 deletions(-)

--- 2.6.23-mm1.orig/include/linux/mempolicy.h   2007-10-30 03:29:37.0 
-0700
+++ 2.6.23-mm1/include/linux/mempolicy.h2007-10-30 04:14:58.0 
-0700
@@ -23,7 +23,8 @@
 
 /* Flags for mbind */
 #define MPOL_MF_STRICT (1<<0)  /* Verify existing pages in the mapping */
-#define MPOL_MF_MOVE   (1<<1)  /* Move pages owned by this process to conform 
to mapping */
+#define MPOL_MF_MOVE   (1<<1)  /* Move pages owned by this process to conform
+   to mapping */
 #define MPOL_MF_MOVE_ALL (1<<2)/* Move every page to conform to 
mapping */
 #define MPOL_MF_INTERNAL (1<<3)/* Internal flags start here */
 
@@ -48,7 +49,7 @@ struct mm_struct;
  * the process policy is used. Interrupts ignore the memory policy
  * of the current process.
  *
- * Locking policy for interlave:
+ * Locking policy for interleave:
  * In process context there is no locking because only the process accesses
  * its own state. All vma manipulation is somewhat protected by a down_read on
  * mmap_sem.
--- 2.6.23-mm1.orig/mm/mempolicy.c  2007-10-30 03:29:37.0 -0700
+++ 2.6.23-mm1/mm/mempolicy.c   2007-10-30 04:15:05.0 -0700
@@ -25,7 +25,7 @@
  *to the last. It would be better if bind would truly restrict
  *the allocation to memory nodes instead
  *
- * preferred   Try a specific node first before normal fallback.
+ * preferred  Try a specific node first before normal fallback.
  *As a special case node -1 here means do the allocation
  *on the local CPU. This is normally identical to default,
  *but useful to set in a VMA when you have a non default
@@ -541,7 +541,7 @@ static long do_get_mempolicy(int *policy
if (flags & (MPOL_F_NODE|MPOL_F_ADDR))
return -EINVAL;
*policy = 0;/* just so it's initialized */
-   *nmask  = cpuset_current_mems_allowed;
+   *nmask = cpuset_current_mems_allowed;
return 0;
}
 
@@ -688,7 +688,7 @@ int do_migrate_pages(struct mm_struct *m
 
tmp = *from_nodes;
while (!nodes_empty(tmp)) {
-   int s,d;
+   int s, d;
int source = -1;
int dest = 0;
 
@@ -783,6 +783,8 @@ static long do_mbind(unsigned long start
if (mpol_check_policy(mode, nmask))
return -EINVAL;
 
+   cpuset_update_task_memory_state();
+
new = mpol_new(mode, nmask);
if (IS_ERR(new))
return PTR_ERR(new);
@@ -794,7 +796,7 @@ static long do_mbind(unsigned long start
if (!new)
flags |= MPOL_MF_DISCONTIG_OK;
 
-   pr_debug("mbind %lx-%lx mode:%ld nodes:%lx\n",start,start+len,
+   pr_debug("mbind %lx-%lx mode:%ld nodes:%lx\n", start, start+len,
 mode, nmask ? nodes_addr(*nmask)[0] : -1);
 
down_write(&mm->mmap_sem);
@@ -898,10 +900,8 @@ asmlinkage long sys_mbind(unsigned long 
err = get_nodes(&nodes, nmask, maxnode);
if (err)
return err;
-#ifdef CONFIG_CPUSETS
/* Restrict the nodes to the allowed nodes in the cpuset */
-   nodes_and(nodes, nodes, current->mems_allowed);
-#endif
+   nodes_and(nodes, nodes, cpuset_current_mems_allowed);
return do_mbind(start, len, mode, &nodes, flags);
 }
 
@@ -1384,7 +1384,7 @@ EXPORT_SYMBOL(alloc_pages_current);
 
 /*
  * If mpol_copy() sees current->cpuset == cpuset_being_rebound, then it
- * rebinds the mempolicy its copying by calling mpol_rebind_policy()
+ * rebinds the mempolicy it's copying by calling mpol_rebind_policy()
  * with the mems_allowed returned by cpuset_mems_allowed().  This
  * keeps mempolicies cpuset relative after its cpuset moves.  See
  * further kernel/cpuset.c update_nodemask().
@@ -1741,9 +1741,9 @@ static void mpol_rebind_policy(struct me
case MPOL_INTERLEAVE:
nodes_remap(tmp, pol->v.nodes, *mpolmask, *newmask);
pol->v.nodes = tmp;
-   *mpolmask = *newmask;
current->il_next = node_remap(current->il_next,
*mpolmask, *newmask);
+   *mpolmask = *newmask;
break;
case MPOL_PREFERRED:
pol->v.preferred_node = node_remap(pol->v.preferred_node,
@@ -1763,7 +1763,7 @@ static void mpol_rebind_policy(struct me
 
zonelist = bin

Re: [dm-devel] Re: dm: bounce_pfn limit added

2007-10-30 Thread Vasily Averin

Alasdair G Kergon wrote:
> So currently we treat bounce_pfn as a property that does not need to be
> propagated through the stack.
> 
> But is that the right approach?
> - Is there a blk_queue_bounce() missing either from dm or elsewhere?
>   (And BTW can the bio_alloc() that lurks within lead to deadlock?)
> 
> Firstly, what's going wrong?
> - What is the dm table you are using?  (output of 'dmsetup table')
>   - Which dm targets and with how many underlying devices?
> - Which underlying driver?
> - Is this direct I/O to the block device from userspace, or via some
> filesystem or what?

On my testnode I have  6 Gb memory (1Gb normal zone for i386 kernels),
i2o hardware and lvm over i2o.

[EMAIL PROTECTED] ~]# dmsetup table
vzvg-vz: 0 10289152 linear 80:5 384
vzvg-vzt: 0 263127040 linear 80:5 10289536
[EMAIL PROTECTED] ~]# cat /proc/partitions
major minor  #blocks  name

  80 0  143374336 i2o/hda
  80 1 514048 i2o/hda1
  80 24096575 i2o/hda2
  80 32040255 i2o/hda3
  80 4  1 i2o/hda4
  80 5  136721151 i2o/hda5
 253 05144576 dm-0
 253 1  131563520 dm-1

Diotest from LTP test suite with ~1Mb buffer size and files on dm-over-i2o
paritions corrupts i2o_iop0_msg_inpool slab.

I2o on this node is able to handle only requests with up to 38 segments. Device
mapper correctly creates such requests and as you know it uses
max_pfn=BLK_BOUNCE_ANY. When this request translates to underlying device, it
clones bio and cleans BIO_SEG_VALID flag.

In this way underlying device calls blk_recalc_rq_segments() to recount number
of segments. However blk_recalc_rq_segments uses bounce_pfn=BLK_BOUNCE_HIGH
taken from underlying device. As result number of segments become over than
max_hw_segments limit.

Unfortunately there is not any checks and when i2o driver handles this incorrect
request it fills the memory out of i2o_iop0_msg_inpool slab.

Thank you,
Vasily Averin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 09/14] Blackfin SPI driver: Fix SPI driver to work with SPI flash ST25P16 on bf548

2007-10-30 Thread David Brownell

On Tuesday 30 October 2007, Bryan Wu wrote:
> Maybe there are some confusion of mixing up the spi_trasnfer.speed_hz
> with the spi_device.max_speed_hz.
> 
> spi_device.max_speed_hz comes from spi_board_info.max_speed_hz, it is
> for the default max speed value.

It's initialized from board_info, yes.  Drivers can override it
using spi_setup().

One would expect they only override _downwards_ but that's not
guaranteed anywhere.  A driver might have a way to establish that
this particular board can run faster, for example.

> spi_transfer.speed_hz comes from upper applications for each spi
> transfer setting.

Certainly; all spi_transfer records come from applications!
If that value is zero, that transfer segment uses the limit
from the spi_device ... otherwise, it can differ.  Again,
the limits can vary based on devise characteristics; maybe
it can't feed data as fast for some commands.

(ISTR the M25P16 in $SUBJECT has two read commands, one of
which is only usable at clock rates below 33 MHz or so, but
most other commands can work above that speed just fine.)

- 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]bluetooth: hci_sysfs connection bus_id add support for diffrent hci device

2007-10-30 Thread David Miller

From: Dave Young <[EMAIL PROTECTED]>
Date: Wed, 31 Oct 2007 10:30:17 +0800

> diff -upr linux/net/bluetooth/hci_sysfs.c linux.new/net/bluetooth/hci_sysfs.c
> --- linux/net/bluetooth/hci_sysfs.c   2007-10-31 10:21:00.0 +0800
> +++ linux.new/net/bluetooth/hci_sysfs.c   2007-10-31 10:21:55.0 
> +0800
> @@ -302,7 +302,8 @@ void hci_conn_add_sysfs(struct hci_conn 
>   conn->dev.release = bt_release;
>  
>   snprintf(conn->dev.bus_id, BUS_ID_SIZE,
> - "%s%2.2X%2.2X%2.2X%2.2X%2.2X%2.2X",
> + "%s%s%2.2X%2.2X%2.2X%2.2X%2.2X%2.2X",
> + hdev->name,
>   conn->type == ACL_LINK ? "acl" : "sco",
>   ba->b[5], ba->b[4], ba->b[3],
>   ba->b[2], ba->b[1], ba->b[0]);

This might not work.

Your device's name is already 15 characters long,
BUS_ID_SIZE is 20, and it seems hdev->name could
easily overflow the 4 or 5 characters of space
remaining.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] af_key: suppress a warning for 64k pages.

2007-10-30 Thread David Miller

From: Stephen Rothwell <[EMAIL PROTECTED]>
Date: Wed, 31 Oct 2007 16:24:52 +1100

> On PowerPC allmodconfig build we get this:
> 
> net/key/af_key.c:400: warning: comparison is always false due to limited 
> range of data type
> 
> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>

Applied, thanks Stephen.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 regression: accessing invalid mmap'ed memory from gdb causes unkillable spinning

2007-10-30 Thread David Miller

From: Nick Piggin <[EMAIL PROTECTED]>
Date: Wed, 31 Oct 2007 07:42:21 +0100

> Sysrq+T fails to show the stack trace of a running task. Presumably this
> is to avoid a garbled stack, however it can often be useful, and besides
> there is no guarantee that the task won't start running in the middle of
> show_stack(). If there are any correctness issues, then the archietcture
> would have to take further steps to ensure the task is not running.
> 
> Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

This is useful.

Even more useful would be a show_regs() on the cpu where running tasks
are running.  If not a full show_regs() at least a program counter.

That's usually what you're trying to debug and we provide nearly no
way to handle: some task is stuck in a loop in kernel mode and you
need to know exactly where that is.

This is pretty easy to do on sparc64.  In fact I can capture remote
cpu registers even when that CPU's interrupts are disabled.  I suppose
other arches could do a NMI'ish register capture like this as well.

I have a few bug reports that I can't make more progress on because I
currently can't ask users to do something to fetch the registers on
the seemingly hung processor.  This is why I'm harping on this so
much :-)

Anyways, my core suggestion is to add a hook here so platforms can
do the remote register fetch if they want.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: pdflush stuck in D state with v2.6.24-rc1-192-gef49c32

2007-10-30 Thread Fengguang Wu

On Tue, Oct 30, 2007 at 10:52:45PM -0500, Florin Iucha wrote:
> On Tue, Oct 30, 2007 at 07:02:42PM -0500, Florin Iucha wrote:
> > I have added the patches and started a linux kernel compilation, and
> > something really interesting happens.  I run the build with the
> > equivalent of "make -j3" and in a separate console I am watching the
> > build with 'top'.  The build consumes 98% of both CPUs.  If I stop the
> > output in the build console with "Ctrl-S", one core goes to idle,
> > while the other is in 50% waiting, then goes to 75% waiting.  When I
> > resume the build with "Ctrl-Q", the build starts to use both CPUs at
> > 98-99%.  The NFS4 use was minimal, as I did not login with Gnome, but
> > just logged on the console.  Also, the CPU that is in 75% waiting
> > state changes occasionally.  'Top' shows pdflush in D state, using
> > 5-6% of CPU.
> 
> I forgot the traces:
> 
>http://iucha.net/2.6.24-rc1/fw.1.gz
>http://iucha.net/2.6.24-rc1/fw.2.gz
>http://iucha.net/2.6.24-rc1/fw.3.gz

Sorry for the delay - I've been fixing our server today.

[  263.685691] mm/page-writeback.c 655 wb_kupdate: pdflush(248) 24235 global 
4593 0 0 wc _M tw 1024 sk 0
[  263.789648] requeue_io 301: inode 4031199 size 562 at 08:07(sda7)
[  263.789656] requeue_io 301: inode 4031231 size 329 at 08:07(sda7)
[  263.789660] requeue_io 301: inode 4031255 size 177 at 08:07(sda7)
[  263.789664] requeue_io 301: inode 4031268 size 94 at 08:07(sda7)
[  263.789667] requeue_io 301: inode 4031329 size 88 at 08:07(sda7)
[  263.789671] requeue_io 301: inode 4031351 size 74 at 08:07(sda7)
[  263.789674] requeue_io 301: inode 4031408 size 175 at 08:07(sda7)
[  263.789678] requeue_io 301: inode 4031413 size 129 at 08:07(sda7)
[  263.789681] requeue_io 301: inode 4031415 size 391 at 08:07(sda7)
[  263.789690] mm/page-writeback.c 655 wb_kupdate: pdflush(248) 24235 global 
4593 0 0 wc _M tw 1024 sk 0
[  263.890184] requeue_io 301: inode 4031199 size 562 at 08:07(sda7)
[  263.890191] requeue_io 301: inode 4031231 size 329 at 08:07(sda7)
[  263.890195] requeue_io 301: inode 4031255 size 177 at 08:07(sda7)
[  263.890198] requeue_io 301: inode 4031268 size 94 at 08:07(sda7)
[  263.890202] requeue_io 301: inode 4031329 size 88 at 08:07(sda7)
[  263.890205] requeue_io 301: inode 4031351 size 74 at 08:07(sda7)
[  263.890208] requeue_io 301: inode 4031408 size 175 at 08:07(sda7)
[  263.890212] requeue_io 301: inode 4031413 size 129 at 08:07(sda7)
[  263.890215] requeue_io 301: inode 4031415 size 391 at 08:07(sda7)
[  263.890223] mm/page-writeback.c 655 wb_kupdate: pdflush(248) 24235 global 
4593 0 0 wc _M tw 1024 sk 0

It's about sda7, not NFSv4.

Is it a Reiserfs? We have a fresh fix for it: http://lkml.org/lkml/2007/10/23/93

Thank you,
Fengguang

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 09/14] Blackfin SPI driver: Fix SPI driver to work with SPI flash ST25P16 on bf548

2007-10-30 Thread Bryan Wu


On Tue, 2007-10-30 at 13:05 -0700, David Brownell wrote:
> On Tuesday 30 October 2007, Bryan Wu wrote:
> > Current SPI driver enables SPI controller and set the SPI baud register
> > for each SPI transfer. But, they should never be changed within a SPI
> > message session, in which seveal SPI transfers are pumped.
> 
> That's actually not true.  If a driver sets spi_transfer.max_speed_hz
> to a nonzero value that's different from the previous bit rate (which
> may be spi_device.max_speed_hz), it should be updated before that
> transfer segment.  Example, sometimes data can't be clocked out at
> the same rate commands can be clocked in.
> 
> Similarly with spi_transfer.bits_per_word ... again, it's very possible
> that commands and data have different sizes.
> 
I agree with you here. 

Maybe there are some confusion of mixing up the spi_trasnfer.speed_hz
with the spi_device.max_speed_hz.

spi_device.max_speed_hz comes from spi_board_info.max_speed_hz, it is
for the default max speed value.
spi_transfer.speed_hz comes from upper applications for each spi
transfer setting.

Am I right?

I will fix this later.

> Of course, if those values don't change, there'd be no point in
> reconfiguring any aspect of those communications parameters...
> 
> 
> I'll be forwarding this patch, since this looks like another case
> where the main effect of the patch doesn't match its description
> and since this patch series has taken too long already.  (Does this
> patch even really relate primarily to working with an ST M25P16
> flash part??)  Though it'd be reasonable to be more hard-nosed
> about this and insist on another go-around for thesse patches.
> (Making this the fifth one??)
> 
> But I *STRONGLY* suggest someone revisit the issue of whether those
> two per-transfer options are now being handled correctly.  As well
> as update procedures so that the patch comments start to have a
> direct correspondence to what the patches have changed...
> 

OK, we will test this on our hardware.
Thanks, Dave
-Bryan Wu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Huawei E220 and usb storage

2007-10-30 Thread Norbert Preining

On Di, 30 Okt 2007, Pete Zaitcev wrote:
> This doesn't seem to be possible, considering the /proc/bus/usb/devices
> that you posted. I would rather suspect that you forgot to perform
> some step in your kernel installation, and end using a stale
> usb-storage module.

No.

$ uname -r
2.6.23
$ cd /lib/modules/2.6.23
$ find . -name usb-storage.ko
./kernel/drivers/usb/storage/usb-storage.ko
$ strings ./kernel/drivers/usb/storage/usb-storage.ko | grep -i huawei_e22a
<3>ENTERING usb_stor_huawei_e220_init!
$

So it is there ... and it is the only module.


Best wishes

Norbert

---
Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
`The first ten million years were the worst,' said Marvin,
`and the second ten million, they were the worst too. The
third ten million I didn't enjoy at all. After that I went
into a bit of a decline.'
 --- Marvin reflecting back on his 576,000,003,579 year
 --- career as Milliways' car park attendent.
 --- Douglas Adams, The Hitchhikers Guide to the Galaxy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Huawei E220 and usb storage

2007-10-30 Thread Pete Zaitcev

On Wed, 31 Oct 2007 07:23:56 +0100, Norbert Preining <[EMAIL PROTECTED]> wrote:

> Hmm, in addition I added a
>   printk(KERN_ERR "ENTERING usb_stor_huawei_e220_init!\n");
> at the beginning of the function but it never showed up in my log files.
> So it seems that the UNUSUAL_DEV entry does not match.

This doesn't seem to be possible, considering the /proc/bus/usb/devices
that you posted. I would rather suspect that you forgot to perform
some step in your kernel installation, and end using a stale
usb-storage module.

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

Re: 2.6.23 regression: accessing invalid mmap'ed memory from gdb causes unkillable spinning

2007-10-30 Thread Nick Piggin

On Wed, Oct 31, 2007 at 12:45:35AM +, Duane Griffin wrote:
> Accessing a memory mapped region past the last page containing a valid
> file mapping produces a SIGBUS fault (as it should). Running a program
> that does this under gdb, then accessing the invalid memory from gdb,
> causes it to start consuming 100% CPU and become unkillable. Once in
> that state, SysRq-T doesn't show a stack trace for gdb, although it is
> shown as running and stack traces are dumped for other tasks.


BTW. this has come up for me before, and I have found it useful on
a number of occasions to print the stack of running tasks when they
are looping in the kernel...

Any reason we can't do this?

--
Sysrq+T fails to show the stack trace of a running task. Presumably this
is to avoid a garbled stack, however it can often be useful, and besides
there is no guarantee that the task won't start running in the middle of
show_stack(). If there are any correctness issues, then the archietcture
would have to take further steps to ensure the task is not running.

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c   2007-10-31 06:53:22.0 +1100
+++ linux-2.6/kernel/sched.c2007-10-31 06:56:02.0 +1100
@@ -4900,8 +4900,7 @@
printk(KERN_CONT "%5lu %5d %6d\n", free,
task_pid_nr(p), task_pid_nr(p->parent));
 
-   if (state != TASK_RUNNING)
-   show_stack(p, NULL);
+   show_stack(p, NULL);
 }
 
 void show_state_filter(unsigned long state_filter)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Security Module Framework (Was: LSM conversion to static interface)

2007-10-30 Thread Crispin Cowan

Peter Dolding wrote:
> Lets end the bitrot.  Start having bits go into the main OS security
> features where they should be.
>   
Linus categorically rejected this idea, several times, very clearly.

He did so because the security community cannot agree on a
one-true-standard for what that OS security feature set should be. From
looking at this thread and many others, he is correct; there is no
consensus on what the feature set should be.

So you can wish for the "main OS security features" all you want, but it
is not going to happen without a miraculous degree of consensus abruptly
arising.

On the contrary, security, done well, is a tight fitting suit. It must
be tight, or it allows too much slack and attackers can exploit that. To
make it tight, it must be tailored to the situation at hand. That means
that there may *never* be a consensus on the "one true way", because it
could be that there is no "one true way". It could be that SMACK is best
in some cases, AppArmor in others, SELinux in others yet again, MLS in
others, etc. etc.

I agree with Casey; LSM may not be perfect, but it is a great deal more
consensus than I have seen anywhere else in the security community. Your
desire that AppArmor and SELinux should share code has already happened:
LSM *is* the sharable code base between AppArmor, SELinux, and SMACK and
TOMOYO, and MultiADM, etc.

It certainly can be improved, but it is not in need of wholesale
replacement, and especially not without a clear design that addresses
clearly stated problems that lots of people are having.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

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

Re: [RFC 0/2] readdir() as an inode operation

2007-10-30 Thread Brad Boyer

On Tue, Oct 30, 2007 at 04:26:04PM +0100, Jan Kara wrote:
> > This is a first try to move readdir() to become an inode operation. This is
> > necessary for a VFS implementation of "something like union-mounts" where a
> > readdir() needs to read the directory contents of multiple directories.
> > Besides that the new interface is no longer giving the struct file to the
> > filesystem implementations anymore.
> > 
> > Comments, please?
>   Hmm, are you sure there are no users which keep some per-struct-file
> information for directories? File offset is one such obvious thing which
> you've handled but actually filesystem with more complicated structure
> of directory may remember some hints about where we really are, keep
> some readahead information or so...

The hfsplus code keeps some extra data in the ->private_data of directories,
although I've lost track of the exact benefit from not looking at the code
in some years. As I recall it was a performance enhancement due to the
fact that the data for all directories is effectively in a single file.
I believe it was easier to keep the current position as a structure
rather than just an offset and be careful about the tracking. The hfs
code is almost identical to the hfsplus code in this area.

Brad Boyer
[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] watchdog: add Nano 7240 driver

2007-10-30 Thread Gilles Gigan

Wim,
I made the changes you requested.
Cheers,
Gilles

From: Gilles Gigan<[EMAIL PROTECTED]>

Adds support for the built-in watchdog on EPIC Nano 7240 boards from IEI.

Tested on Nano-7240RS.

Hardware documentation of the platform (including watchdog) can be found
on the IEI website: http://www.ieiworld.com

Signed-off-by: Gilles Gigan <[EMAIL PROTECTED]>

---

 drivers/watchdog/Kconfig   |   13 ++
 drivers/watchdog/Makefile  |1 
 drivers/watchdog/sbc7240_wdt.c |  307 
 3 files changed, 321 insertions(+), 0 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 2792bc1..c9d5ada 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -456,6 +456,19 @@ config SBC8360_WDT
 
  Most people will say N.
 
+config SBC7240_WDT
+   tristate "SBC Nano 7240 Watchdog Timer"
+   depends on X86_32
+   ---help---
+ This is the driver for the hardware watchdog found on the IEI
+ single board computers EPIC Nano 7240 (and likely others). This
+ watchdog simply watches your kernel to make sure it doesn't freeze,
+ and if it does, it reboots your computer after a certain amount of
+ time.
+
+ To compile this driver as a module, choose M here: the
+ module will be called sbc7240_wdt.
+
 config CPU5_WDT
tristate "SMA CPU5 Watchdog"
depends on X86
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 7d9e573..d57bfd0 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_SCx200_WDT) += scx200_wdt.o
 obj-$(CONFIG_PC87413_WDT) += pc87413_wdt.o
 obj-$(CONFIG_60XX_WDT) += sbc60xxwdt.o
 obj-$(CONFIG_SBC8360_WDT) += sbc8360.o
+obj-$(CONFIG_SBC7240_WDT) += sbc7240_wdt.o
 obj-$(CONFIG_CPU5_WDT) += cpu5wdt.o
 obj-$(CONFIG_SMSC37B787_WDT) += smsc37b787_wdt.o
 obj-$(CONFIG_W83627HF_WDT) += w83627hf_wdt.o
diff --git a/drivers/watchdog/sbc7240_wdt.c b/drivers/watchdog/sbc7240_wdt.c
new file mode 100644
index 000..63be21b
--- /dev/null
+++ b/drivers/watchdog/sbc7240_wdt.c
@@ -0,0 +1,307 @@
+/*
+ * NANO7240 SBC Watchdog device driver
+ *
+ * Based on w83877f.c by Scott Jennings,
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation;
+ *
+ * Software distributed under the License is distributed on an "AS IS"
+ * basis, WITHOUT WARRANTY OF ANY KIND, either express or
+ * implied. See the License for the specific language governing
+ * rights and limitations under the License.
+ *
+ * (c) Copyright 2007  Gilles GIGAN <[EMAIL PROTECTED]>
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SBC7240_PREFIX "sbc7240_wdt: "
+
+#define SBC7240_ENABLE_PORT0x443
+#define SBC7240_DISABLE_PORT   0x043
+#define SBC7240_SET_TIMEOUT_PORT   SBC7240_ENABLE_PORT
+#define SBC7240_MAGIC_CHAR 'V'
+
+#define SBC7240_TIMEOUT30
+#define SBC7240_MAX_TIMEOUT255
+static int timeout = SBC7240_TIMEOUT;  /* in seconds */
+module_param(timeout, int, 0);
+MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds. (1<=timeout<="
+__MODULE_STRING(SBC7240_MAX_TIMEOUT) ", default="
+__MODULE_STRING(SBC7240_TIMEOUT) ")");
+
+static int nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, int, 0);
+MODULE_PARM_DESC(nowayout, "Disable watchdog when closing device file");
+
+#define SBC7240_OPEN_STATUS_BIT0
+#define SBC7240_ENABLED_STATUS_BIT 1
+#define SBC7240_EXPECT_CLOSE_STATUS_BIT2
+static unsigned long wdt_status;
+
+/*
+ * Utility routines
+ */
+
+static void wdt_disable(void)
+{
+   /* disable the watchdog */
+   if (test_and_clear_bit(SBC7240_ENABLED_STATUS_BIT, &wdt_status)) {
+   inb_p(SBC7240_DISABLE_PORT);
+   printk(KERN_INFO SBC7240_PREFIX
+  "Watchdog timer is now disabled.\n");
+   }
+}
+
+static void wdt_enable(void)
+{
+   /* enable the watchdog */
+   if (!test_and_set_bit(SBC7240_ENABLED_STATUS_BIT, &wdt_status)) {
+   inb_p(SBC7240_ENABLE_PORT);
+   printk(KERN_INFO SBC7240_PREFIX
+  "Watchdog timer is now enabled.\n");
+   }
+}
+
+static int wdt_set_timeout(int t)
+{
+   if (t < 1 || t > SBC7240_MAX_TIMEOUT) {
+   printk(KERN_ERR SBC7240_PREFIX
+  "timeout value must be 1<=x<=%d\n",
+  SBC7240_MAX_TIMEOUT);
+   return -1;
+   }
+   /* set the timeout */
+   outb_p((unsigned)t, SBC7240_SET_TIMEOUT_PORT);
+   printk(KERN_INFO SBC7240_PREFIX "timeout set to %d seconds\n", t);
+   return

Re: [PATCH 13/14] Blackfin SPI driver: Move cs_chg_udelay to cs_deactive to fix bug when some SPI LCD driver needs delay after cs_deactive

2007-10-30 Thread Bryan Wu


On Tue, 2007-10-30 at 13:18 -0700, David Brownell wrote:
> On Tuesday 30 October 2007, Bryan Wu wrote:
> > @@ -211,6 +211,10 @@ static void cs_deactive(struct driver_data *drv_data, 
> > struct chip_data *chip)
> > flag |= (chip->flag << 8);
> >  
> > write_FLAG(drv_data, flag);
> > +
> > +   /* Move delay here for consistency */
> > +   if (chip->cs_chg_udelay)
> > +   udelay(chip->cs_chg_udelay);
> >  }
> >  
> 
> By the way, if this is something needed very often, that mechanism
> should be moved into the SPI framework.  It wouldn't be polite if
> such LCD drivers could only work on Blackfin boards.  :)

I am not sure whether this LCD needs cs_chg_udelay on other boards.
It is found by Cameron Barfield. Maybe it is some timing requirement for
specific hardware.

-Bryan Wu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2] [POWERPC] Fix region size check in mpc5200 FEC driver

2007-10-30 Thread Grant Likely

From: Grant Likely <[EMAIL PROTECTED]>

Driver shouldn't complain if the register range is larger than what
it expects.  This works around failures with some device trees.

Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---

 drivers/net/fec_mpc52xx.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index fc1cf0b..a8a0ee2 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -879,9 +879,9 @@ mpc52xx_fec_probe(struct of_device *op, const struct 
of_device_id *match)
"Error while parsing device node resource\n" );
return rv;
}
-   if ((mem.end - mem.start + 1) != sizeof(struct mpc52xx_fec)) {
+   if ((mem.end - mem.start + 1) < sizeof(struct mpc52xx_fec)) {
printk(KERN_ERR DRIVER_NAME
-   " - invalid resource size (%lx != %x), check 
mpc52xx_devices.c\n",
+   " - invalid resource size (%lx < %x), check 
mpc52xx_devices.c\n",
(unsigned long)(mem.end - mem.start + 1), sizeof(struct 
mpc52xx_fec));
return -EINVAL;
}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] [POWERPC] mpc5200: Fix Kconfig dependancies on MPC5200 FEC device driver

2007-10-30 Thread Grant Likely

From: Grant Likely <[EMAIL PROTECTED]>

When not building an arch/powerpc kernel, the mpc5200 FEC driver depends
on some symbols which are not defined (BESTCOMM & BESTCOMM_FEC).

This patch flips around the dependancy logic so that it cannot be
selected unless BESTCOMM_FEC is selected first.  Kconfig stops
complaining this way.

Also, the driver only works for arch/powerpc (not arch/ppc) anyway so
it should depend on PPC_MERGE also.

Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---

 drivers/net/Kconfig |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 867cb73..5f800a6 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1883,9 +1883,7 @@ config FEC2
 
 config FEC_MPC52xx
tristate "MPC52xx FEC driver"
-   depends on PPC_MPC52xx
-   select PPC_BESTCOMM
-   select PPC_BESTCOMM_FEC
+   depends on PPC_MERGE && PPC_MPC52xx && PPC_BESTCOMM_FEC
select CRC32
select PHYLIB
---help---

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.24-rc1 regression] AC adapter state does not change after resume

2007-10-30 Thread Alexey Starikovskiy

Andrey Borzenkov wrote:
> On Wednesday 31 October 2007, Alexey Starikovskiy wrote:
>> Andrey Borzenkov wrote:
>>> I suspect new ACPI AC adapter code but have to add some printk's to be
>>> sure.
>>>
>>> To reproduce - plug in AC cord, suspend, unplug, resume - kpowersave and
>>> sysfs still show AC adapter online. Or other way round.
>>>
>>> -andrey
>> Please check if this patch helps.
>>
> 
> It does not even compile :)
> 
> On serious note (after adding forward declaration) - patch half works. It 
> does 
> make "online" return true value (which confirms that underlying ACPI works 
> correctly) but HAL still does not notice it.
> 
> The problem is, with power_supply interface HAL does not use polling, it 
> relies on CHANGE event. This event is apparently never generated if AC 
> adapter state changes on resume. So the obvious fix is to compare AC state 
> before and after suspend in ->resume function and generate synthetic CHANGE 
> event if something has changed.
> 
> This will also make superfluous polling redundant.
Ok, here. This one compiles :)

Regards,
Alex.
ACPI: AC: Update AC state on resume

From: Alexey Starikovskiy <[EMAIL PROTECTED]>

Check if AC state has changed across resume and notify userspace if so.

Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---

 drivers/acpi/ac.c |   17 +
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
index e03de37..06308ff 100644
--- a/drivers/acpi/ac.c
+++ b/drivers/acpi/ac.c
@@ -54,6 +54,7 @@ extern void *acpi_unlock_ac_dir(struct proc_dir_entry *acpi_ac_dir);
 
 static int acpi_ac_add(struct acpi_device *device);
 static int acpi_ac_remove(struct acpi_device *device, int type);
+static int acpi_ac_resume(struct acpi_device *device);
 static int acpi_ac_open_fs(struct inode *inode, struct file *file);
 
 const static struct acpi_device_id ac_device_ids[] = {
@@ -69,6 +70,7 @@ static struct acpi_driver acpi_ac_driver = {
 	.ops = {
 		.add = acpi_ac_add,
 		.remove = acpi_ac_remove,
+		.resume = acpi_ac_resume,
 		},
 };
 
@@ -294,6 +296,21 @@ static int acpi_ac_add(struct acpi_device *device)
 	return result;
 }
 
+static int acpi_ac_resume(struct acpi_device *device)
+{
+	struct acpi_ac *ac;
+	unsigned old_state;
+	if (!device || !acpi_driver_data(device))
+		return -EINVAL;
+	ac = acpi_driver_data(device);
+	old_state = ac->state;
+	if (acpi_ac_get_state(ac))
+		return 0;
+	if (old_state != ac->state)
+		kobject_uevent(&ac->charger.dev->kobj, KOBJ_CHANGE);
+	return 0;
+}
+
 static int acpi_ac_remove(struct acpi_device *device, int type)
 {
 	acpi_status status = AE_OK;

Re: 2.6.23 boot failures on x86-64.

2007-10-30 Thread Zou Nan hai

On Wed, 2007-10-31 at 14:04, Zou Nan hai wrote:
> On Tue, 2007-10-30 at 05:21, Martin Ebourne wrote:
> > On Mon, 2007-10-29 at 15:43 -0400, Dave Jones wrote:
> > > On Mon, Oct 29, 2007 at 08:03:09PM +0100, Andi Kleen wrote:
> > >  > >  > But if allocating bootmem >4G doesn't work on these systems
> > >  > >  > most likely they have more problems anyways. It might be better
> > >  > >  > to find out what goes wrong exactly.
> > >  > > Any ideas on what to instrument ?
> > >  > 
> > >  > See what address the bootmem_alloc_high returns; check if it overlaps
> > >  > with something etc.
> > >  > 
> > >  > Fill the memory on the system and see if it can access all of its 
> > > memory.
> > > 
> > > Martin, as you have one of the affected systems, do you feel up to this?
> > 
> > Faking a node at -1fff
> > Bootmem setup node 0 -1fff
> > sparse_early_mem_map_alloc: returned address 8170b000
> > 
> > My box has 512MB of RAM.
> > 
> > Cheers,
> > 
> > Martin.
> 
> Oops, sorry,
> seem to be a mistake of me.
> I forget to exclude the DMA range.
> 
> Does the following patch fix the issue?
> 
> Thanks
> Zou Nan hai
> 
> --- a/arch/x86/mm/init_64.c   2007-10-31 11:24:11.0 +0800
> +++ b/arch/x86/mm/init_64.c   2007-10-31 12:31:02.0 +0800
> @@ -731,7 +731,7 @@ int in_gate_area_no_task(unsigned long a
>  void * __init 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);
> + SMP_CACHE_BYTES, (4UL*1024*1024*1024), 
> __pa(MAX_DMA_ADDRESS));
>  }
>  
>  const char *arch_vma_name(struct vm_area_struct *vma)
> 
> 
> 
>  

Please ignore the patch, the patch is wrong.

However I think the root cause is when __alloc_bootmem_core fail to
allocate a memory above 4G it will fall back to allocate from the lowest
page. 
Then happens to be allocated in DMA region sometimes...

Since this code path is dead, I am OK to revert the patch.

Suresh and I will check the CONFIG_SPARSE_VMEMMAP path.
Thanks
Zou Nan hai




 
 
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Huawei E220 and usb storage

2007-10-30 Thread Norbert Preining

On Mi, 31 Okt 2007, preining wrote:
> On Di, 30 Okt 2007, Pete Zaitcev wrote:
> > The difference with huaweiAktBbo.c seems that kernel uses a nonzero length.
> > Can you try zero length with the kernel? It's the second argument to the 
> > last.
> 
> I tried with the git patch plus changing the penultimage argument from
> 0x1 to 0.

Hmm, in addition I added a
printk(KERN_ERR "ENTERING usb_stor_huawei_e220_init!\n");
at the beginning of the function but it never showed up in my log files.
So it seems that the UNUSUAL_DEV entry does not match.

Best wishes

Norbert

---
Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
TIDPIT (n.)
The corner of a toenail from which satisfying little black deposits
may be sprung.
--- Douglas Adams, The Meaning of Liff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] cpuset relative memory policies - second choice

2007-10-30 Thread Paul Jackson

From: Paul Jackson <[EMAIL PROTECTED]>

  RFC only so far - has been built and booted, but has received
  almost no testing.

Add a second choice for how node numbers are interpreted and returned
by the NUMA memory policy system calls mbind, set_mempolicy and
get_mempolicy.

The original choice remains the default, for compatibility.

The second choice overcomes some limitations of the first choice in
the interaction between cpusets and these memory policy calls, that
show up when tasks using these calls are also being moved between
different cpusets, especially between cpusets with varying numbers
of allowed nodes in the cpuset 'mems' file.

A new per-task mode, managed using added get_mempolicy calls, controls
which mode applies to subsequently created memory policies.

See the Documentation/vm/numa_memory_policy.txt section MEMORY
POLICIES AND CPUSETS for an explanation of how both these choices
for node numbering work and interact with cpusets.

Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Cc: David Rientjes <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: Andi Kleen <[EMAIL PROTECTED]>

---
 Documentation/vm/numa_memory_policy.txt |  140 +---
 include/linux/mempolicy.h   |   15 +++
 include/linux/sched.h   |1 
 mm/mempolicy.c  |  123 +++-
 4 files changed, 229 insertions(+), 50 deletions(-)

--- 2.6.23-mm1.orig/include/linux/mempolicy.h   2007-10-30 18:04:11.0 
-0700
+++ 2.6.23-mm1/include/linux/mempolicy.h2007-10-30 18:11:07.0 
-0700
@@ -21,6 +21,10 @@
 #define MPOL_F_ADDR(1<<1)  /* look up vma using address */
 #define MPOL_F_MEMS_ALLOWED (1<<2) /* return allowed memories */
 
+#define MPOL_F_MODE_DEFAULT (1<<3) /* set cpuset confined nodemask mode */
+#define MPOL_F_MODE_SYS_WIDE (1<<4) /* set system-wide nodemask mode */
+#define MPOL_F_MODE_GET(1<<5) /* return number mode: old => 1, new 
=> 0 */
+
 /* Flags for mbind */
 #define MPOL_MF_STRICT (1<<0)  /* Verify existing pages in the mapping */
 #define MPOL_MF_MOVE   (1<<1)  /* Move pages owned by this process to conform
@@ -28,6 +32,10 @@
 #define MPOL_MF_MOVE_ALL (1<<2)/* Move every page to conform to 
mapping */
 #define MPOL_MF_INTERNAL (1<<3)/* Internal flags start here */
 
+/* Internal values for mpol_nodemask_mode (just reuse get_mem_policy values) */
+#define MPOL_MODE_DEFAULT  MPOL_F_MODE_DEFAULT  /* relative to this cpuset */
+#define MPOL_MODE_SYS_WIDE MPOL_F_MODE_SYS_WIDE /* original input mask */
+
 #ifdef __KERNEL__
 
 #include 
@@ -64,13 +72,18 @@ struct mm_struct;
 struct mempolicy {
atomic_t refcnt;
short policy;   /* See MPOL_* above */
+   char mpol_nodemask_mode; /* See MPOL_MODE_* above; union c below */
union {
struct zonelist  *zonelist; /* bind */
shortpreferred_node; /* preferred */
nodemask_t   nodes; /* interleave */
/* undefined for default */
} v;
-   nodemask_t cpuset_mems_allowed; /* mempolicy relative to these nodes */
+   /* Cpuset interface: Documentation/vm/numa_memory_policy.txt */
+   union {
+   nodemask_t cpuset_mems_allowed; /* if MPOL_MODE_DEFAULT */
+   nodemask_t original_nodes;  /* if MPOL_MODE_SYS_WIDE */
+   } c;
 };
 
 /*
--- 2.6.23-mm1.orig/mm/mempolicy.c  2007-10-30 18:04:11.0 -0700
+++ 2.6.23-mm1/mm/mempolicy.c   2007-10-30 20:02:10.0 -0700
@@ -175,6 +175,7 @@ static struct zonelist *bind_zonelist(no
 static struct mempolicy *mpol_new(int mode, nodemask_t *nodes)
 {
struct mempolicy *policy;
+   nodemask_t cpuset_centric_nodes;
 
pr_debug("setting mode %d nodes[0] %lx\n",
 mode, nodes ? nodes_addr(*nodes)[0] : -1);
@@ -185,9 +186,27 @@ static struct mempolicy *mpol_new(int mo
if (!policy)
return ERR_PTR(-ENOMEM);
atomic_set(&policy->refcnt, 1);
+
+   policy->mpol_nodemask_mode = current->mpol_nodemask_mode;
+   {
+   char m = current->mpol_nodemask_mode;
+   if (m != MPOL_MODE_DEFAULT && m != MPOL_MODE_SYS_WIDE)
+   printk(KERN_WARNING
+   "mempolicy mpol_new unset mode: %d\n", m);
+   }
+   if (policy->mpol_nodemask_mode == MPOL_MODE_SYS_WIDE) {
+   policy->c.original_nodes = *nodes;
+   nodes_remap(cpuset_centric_nodes, *nodes,
+   node_possible_map,
+   cpuset_current_mems_allowed);
+   } else /* MPOL_MODE_DEFAULT */ {
+   policy->c.cpuset_mems_allowed = cpuset_current_mems_allowed;
+   cpuset_centric_nodes = *nodes;
+   }
+
switch (mode) {
case MPOL_INTERLEAVE:
-   policy->v.nodes

Re: Huawei E220 and usb storage

2007-10-30 Thread Norbert Preining

On Di, 30 Okt 2007, Pete Zaitcev wrote:
> The difference with huaweiAktBbo.c seems that kernel uses a nonzero length.
> Can you try zero length with the kernel? It's the second argument to the last.

I tried with the git patch plus changing the penultimage argument from
0x1 to 0.

The switch of the modem is still not done automatically, but calling
huaweiAktBbo does effect the switch.

In my tests I did NOT reboot since usb-storage was compiled as module
(usbserial and option fix in the kernel). But I made sure that I loaded
the right (the module with the patched code) after removing the old one.

Best wishes

Norbert

---
Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
GALASHIELS (pl.n.)
A form of particularly long sparse sideburns which are part of the
mandatory uniform of British Rail guards.
--- Douglas Adams, The Meaning of Liff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Xen-devel] [patch 30/44] xen: Add support for preemption

2007-10-30 Thread tgh

Thank you for your reply
and what about the kernel thread in the xen hypervisor,are there some
instance of kernel threads running in the hypervisor?
I am not sure ,but somewhere I read that there is no kernel thread in
the xen hypervisor ,is it true or what about it?

Thanks in advance


Jeremy Fitzhardinge 写道:
> tgh wrote:
>   
>> Thank for your reply
>> and I still have several questions
>>   
>> 
>>> Yes, that's the normal mode of operation. The hypervisor will timeslice
>>> multiple vcpus onto a single vcpu.
>>>   
>>> 
>>>   
>> that is ,the VM could be preempted by xen,and could xen hypervisor also
>> be preempted to reschedule other vm or xen kernel thread?and are there
>> the counterpart abstractions in xen for kernel thread in linux?
>>   
>> 
>
> Yes, a vcpu in Xen is the same as a task in the kernel. In the same way
> the kernel multiplexes multiple tasks onto your cpu(s), Xen multiplexes
> multiple vcpus onto your cpu(s). This isn't directly visible to the
> guest kernel, in the same way that user processes can't generally
> observe timeslicing.
>
>   
>>> This patch doesn't relate to that; it's whether a Xen Linux guest's
>>> kernel can be preempted to reschedule processes while running under Xen.
>>>   
>>> 
>>>   
>> that is ,the patch makes the guest's kernel, rather than xen, be able to
>> be preempted ,is it right?
>>   
>> 
>
> Yes. Previous to that change, kernel preemption was disabled when
> compiling Xen support in.
>
> J
>
> ___
> Xen-devel mailing list
> [EMAIL PROTECTED]
> http://lists.xensource.com/xen-devel
>
>
>   

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 boot failures on x86-64.

2007-10-30 Thread Zou Nan hai

On Tue, 2007-10-30 at 05:21, Martin Ebourne wrote:
> On Mon, 2007-10-29 at 15:43 -0400, Dave Jones wrote:
> > On Mon, Oct 29, 2007 at 08:03:09PM +0100, Andi Kleen wrote:
> >  > >  > But if allocating bootmem >4G doesn't work on these systems
> >  > >  > most likely they have more problems anyways. It might be better
> >  > >  > to find out what goes wrong exactly.
> >  > > Any ideas on what to instrument ?
> >  > 
> >  > See what address the bootmem_alloc_high returns; check if it overlaps
> >  > with something etc.
> >  > 
> >  > Fill the memory on the system and see if it can access all of its memory.
> > 
> > Martin, as you have one of the affected systems, do you feel up to this?
> 
> Faking a node at -1fff
> Bootmem setup node 0 -1fff
> sparse_early_mem_map_alloc: returned address 8170b000
> 
> My box has 512MB of RAM.
> 
> Cheers,
> 
> Martin.

Oops, sorry,
seem to be a mistake of me.
I forget to exclude the DMA range.

Does the following patch fix the issue?

Thanks
Zou Nan hai

--- a/arch/x86/mm/init_64.c 2007-10-31 11:24:11.0 +0800
+++ b/arch/x86/mm/init_64.c 2007-10-31 12:31:02.0 +0800
@@ -731,7 +731,7 @@ int in_gate_area_no_task(unsigned long a
 void * __init 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);
+   SMP_CACHE_BYTES, (4UL*1024*1024*1024), 
__pa(MAX_DMA_ADDRESS));
 }
 
 const char *arch_vma_name(struct vm_area_struct *vma)



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

[PATCHv2] selinux: suppress a warning for 64k pages.

2007-10-30 Thread Stephen Rothwell

On PowerPC allmodconfig build we get this:

security/selinux/xfrm.c:214: warning: comparison is always false due to limited 
range of data type

Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
 security/selinux/xfrm.c |   13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)

This version suppresses the warning without ugly ifdefs.
-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]

diff --git a/security/selinux/xfrm.c b/security/selinux/xfrm.c
index 36a191e..e076039 100644
--- a/security/selinux/xfrm.c
+++ b/security/selinux/xfrm.c
@@ -211,26 +211,27 @@ static int selinux_xfrm_sec_ctx_alloc(struct xfrm_sec_ctx 
**ctxp,
if (uctx->ctx_doi != XFRM_SC_ALG_SELINUX)
return -EINVAL;
 
-   if (uctx->ctx_len >= PAGE_SIZE)
+   str_len = uctx->ctx_len;
+   if (str_len >= PAGE_SIZE)
return -ENOMEM;
 
*ctxp = ctx = kmalloc(sizeof(*ctx) +
- uctx->ctx_len + 1,
+ str_len + 1,
  GFP_KERNEL);
 
if (!ctx)
return -ENOMEM;
 
ctx->ctx_doi = uctx->ctx_doi;
-   ctx->ctx_len = uctx->ctx_len;
+   ctx->ctx_len = str_len;
ctx->ctx_alg = uctx->ctx_alg;
 
memcpy(ctx->ctx_str,
   uctx+1,
-  ctx->ctx_len);
-   ctx->ctx_str[ctx->ctx_len] = 0;
+  str_len);
+   ctx->ctx_str[str_len] = 0;
rc = security_context_to_sid(ctx->ctx_str,
-ctx->ctx_len,
+str_len,
 &ctx->ctx_sid);
 
if (rc)
-- 
1.5.3.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/

[PATCH] af_key: suppress a warning for 64k pages.

2007-10-30 Thread Stephen Rothwell

On PowerPC allmodconfig build we get this:

net/key/af_key.c:400: warning: comparison is always false due to limited range 
of data type

Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
 net/key/af_key.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

This version gets rid of the warning without the ugliness of ifdefs.
-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]

diff --git a/net/key/af_key.c b/net/key/af_key.c
index 7969f8a..266f112 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -395,9 +395,9 @@ static inline int pfkey_sec_ctx_len(struct sadb_x_sec_ctx 
*sec_ctx)
 static inline int verify_sec_ctx_len(void *p)
 {
struct sadb_x_sec_ctx *sec_ctx = (struct sadb_x_sec_ctx *)p;
-   int len;
+   int len = sec_ctx->sadb_x_ctx_len;
 
-   if (sec_ctx->sadb_x_ctx_len > PAGE_SIZE)
+   if (len > PAGE_SIZE)
return -EINVAL;
 
len = pfkey_sec_ctx_len(sec_ctx);
-- 
1.5.3.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/

bttv build error (CONFIG_NET=n)

2007-10-30 Thread Randy Dunlap

drivers/media/video/bt8xx/bttv-cards.c calls ip_compute_csum().
However, when CONFIG_NET=n, that produces:

ERROR: "ip_compute_csum" [drivers/media/video/bt8xx/bttv.ko] undefined!

Config symbol VIDEO_BT848 can be made to depend on NET, or the
osprey_eeprom() function can be built depending on some new config
symbol, or bttv could have its own checksum function...

.config attached.

---
~Randy


config-bttv-nonet
Description: Binary data

Re: Multiple MSI messages support

2007-10-30 Thread Roland Dreier

 > My interpretation of this statement is that you have to use MSIX if
 > multiple MSI messages are required on Linux.

Yes, Linux only supports multiple messages with MSI-X, not MSI.  This
is an architectural limitation of "Intel-style" interrupt controllers
(x86 and ia64).  It is also a limitation of the Linux's MSI API, since
there are platforms and devices for which an OS could allocate
multiple MSI messages, but Linux has no interface that allows that.

The historical reason for the Linux interface is simply that Intel
platforms were the first place that MSI/MSI-X was supported.

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

[PATCH 5/6] fix typo in SubmittingPatches

2007-10-30 Thread Greg Kroah-Hartman

From: Keiichi Kii <[EMAIL PROTECTED]>

Fix typo.

Signed-off-by: Keiichi Kii <[EMAIL PROTECTED]>
Cc: Andy Whitcroft <[EMAIL PROTECTED]>
Cc: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 Documentation/SubmittingPatches |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index a30dd44..681e2b3 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -464,8 +464,8 @@ section Linus Computer Science 101.
 Nuff said.  If your code deviates too much from this, it is likely
 to be rejected without further review, and without comment.
 
-Once significant exception is when moving code from one file to
-another in this case you should not modify the moved code at all in
+One significant exception is when moving code from one file to
+another -- in this case you should not modify the moved code at all in
 the same patch which moves it.  This clearly delineates the act of
 moving the code and your changes.  This greatly aids review of the
 actual differences and allows tools to better track the history of
-- 
1.5.3.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/

[PATCH 6/6] add SubmittingPatches to Documentation/ja_JP

2007-10-30 Thread Greg Kroah-Hartman

From: Keiichi Kii <[EMAIL PROTECTED]>

This patch adds SubmittingPatches translated into Japanese to
Documentation/ja_JP directory.

I attach the patch because there is a possibility that MUA
will change the character encoding sometimes.

Signed-off-by: Keiichi KII <[EMAIL PROTECTED]>
Cc: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 Documentation/ja_JP/SubmittingPatches |  556 +
 1 files changed, 556 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/ja_JP/SubmittingPatches

diff --git a/Documentation/ja_JP/SubmittingPatches 
b/Documentation/ja_JP/SubmittingPatches
new file mode 100644
index 000..a9dc124
--- /dev/null
+++ b/Documentation/ja_JP/SubmittingPatches
@@ -0,0 +1,556 @@
+NOTE:
+This is a version of Documentation/SubmittingPatches into Japanese.
+This document is maintained by Keiichi KII <[EMAIL PROTECTED]>
+and the JF Project team .
+If you find any difference between this document and the original file
+or a problem with the translation,
+please contact the maintainer of this file or JF project.
+
+Please also note that the purpose of this file is to be easier to read
+for non English (read: Japanese) speakers and is not intended as a
+fork. So if you have any comments or updates of this file, please try
+to update the original English file first.
+
+Last Updated: 2007/10/24
+==
+ããã¯ã
+linux-2.6.23/Documentation/SubmittingPatches ã®åè¨³
+ã§ãã
+ç¿»è¨³å£ä½ï¼ JF ããã¸ã§ã¯ã < http://www.linux.or.jp/JF/ >
+ç¿»è¨³æ¥ï¼ 2007/10/17
+ç¿»è¨³èï¼ Keiichi Kii 
+æ ¡æ£èï¼ Masanari Kobayashi ãã 
+ Matsukura ãã 
+==
+
+Linux ã«ã¼ãã«ã«å¤æ´ãå ããããã® Howto
+åã¯
+ãã® Linus Torvalds ã®åãæ±ãèª¬ææ¸
+
+Linux 
ã«ã¼ãã«ã«å¤æ´ãå ãããã¨æã£ã¦ããåäººåã¯ä¼ç¤¾ã«ã¨ã£ã¦ããã
+ãã®æç¨¿ã«é¢é£ããä»çµã¿ã«æ£ãã¦ããªããã°ããã®éç¨ã¯æãã¿ãªããã
+ãããã¥ããããã¨ãããã¾ãããã®æç« ã¯ããªãã®å¤æ´ãå¤§ãã«åãå¥ã
+ã¦ããããããããææ¡ãéãããã®ã§ãã
+
+ã³ã¼ããæç¨¿ããåã«ãDocumentation/SubmitChecklist 
ã®é ç®ãªã¹ãã«ç®
+ãéãã¦ãã§ãã¯ãã¦ãã ãããããããªãããã©ã¤ãã¼ãæç¨¿ãããã¨ã
+ã¦ãããªããDocumentation/SubmittingDrivers 
ã«ãç®ãéãã¦ãã ããã
+
+
+ã»ã¯ã·ã§ã³1 ãããã®ä½ãæ¹ã¨éãæ¹
+
+
+1) ã diff -up ã
+
+
+ãããã®ä½æã«ã¯ã diff -up ãåã¯ã diff -uprN 
ããä½¿ã£ã¦ãã ããã
+
+Linux ã«ã¼ãã«ã«å¯¾ããå¨ã¦ã®å¤æ´ã¯ diff(1) 
ã³ãã³ãã«ãããããã®å½¢å¼ã§
+çæãã¦ãã ãããããããä½æããã¨ãã«ã¯ãdiff(1) 
ã³ãã³ãã«ã -u ãå¼
+æ°ãæå®ãã¦ãunified 
å½¢å¼ã®ããããä½æãããã¨ãç¢ºèªãã¦ãã ãããã¾ãã
+å¤æ´ãã©ã® C é¢æ°ã§è¡ãããã®ããè¡¨ç¤ºããã -p 
ãå¼æ°ãä½¿ã£ã¦ãã ããã
+ãã®å¼æ°ã¯çæããå·®åããã£ã¨èªã¿ããããã¦ããã¾ãããããã¯
 Linux
+ã«ã¼ãã«ã½ã¼ã¹ã®ä¸ã®ãµããã£ã¬ã¯ããªã§ã¯ãªã Linux 
ã«ã¼ãã«ã½ã¼ã¹ã®ã«ã¼ã
+ãã£ã¬ã¯ããªãåºæºã«ããªãã¨ããã¾ããã
+
+1åã®ãã¡ã¤ã«ã«ã¤ãã¦ã®ããããä½æããããã«ã¯ãã»ã¨ãã©ã®å ´åã
+ä»¥ä¸ã®ä½æ¥ãè¡ãã°ååã§ãã
+
+   SRCTREE= linux-2.6
+   MYFILE=  drivers/net/mydriver.c
+
+   cd $SRCTREE
+   cp $MYFILE $MYFILE.orig
+   vi $MYFILE  # make your change
+   cd ..
+   diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch
+
+è¤æ°ã®ãã¡ã¤ã«ã«ã¤ãã¦ã®ããããä½æããããã«ã¯ãç´ ã®(
 vanilla )ãã
+ãªãã¡å¤æ´ãå ãã¦ãªã Linux ã«ã¼ãã«ãå±éããèªåã® 
Linux ã«ã¼ãã«
+ã½ã¼ã¹ã¨ã®å·®åãçæããªãã¨ããã¾ãããä¾ãã°ã
+
+   MYSRC= /devel/linux-2.6
+
+   tar xvfz linux-2.6.12.tar.gz
+   mv linux-2.6.12 linux-2.6.12-vanilla
+   diff -uprN -X linux-2.6.12-vanilla/Documentation/dontdiff \
+   linux-2.6.12-vanilla $MYSRC > /tmp/patch
+
+dontdiff ãã¡ã¤ã«ã«ã¯ Linux 
ã«ã¼ãã«ã®ãã«ãããã»ã¹ã®éç¨ã§çæããã
+ãã¡ã¤ã«ã®ä¸è¦§ãã®ã£ã¦ãã¾ããããã¦ããããã¯ããããçæãã
 diff(1)
+ã³ãã³ãã§ç¡è¦ãããã¹ãã§ããdontdiff ãã¡ã¤ã«ã¯ 2.6.12 
ä»¥å¾ã®ãã¼ã¸ã§
+ã³ã® Linux 
ã«ã¼ãã«ã½ã¼ã¹ããªã¼ã«å«ã¾ãã¦ãã¾ããããããåã®ãã¼ã¸ã§ã³
+ã® Linux ã«ã¼ãã«ã½ã¼ã¹ããªã¼ã«å¯¾ãã dontdiff 
ãã¡ã¤ã«ã¯ã
+ãã

[PATCH 4/6] Driver Core: fix bug in device_rename() for SYSFS_DEPRECATED=y

2007-10-30 Thread Greg Kroah-Hartman

From: Kay Sievers <[EMAIL PROTECTED]>

This should fix the sysfs warnings that renaming network devices is
causing to show up with CONFIG_SYSFS_DEPRECATED=y

The code just shouldn't run if class devices are real directories, it's
an update for the symlink in the class directory. Nobody noticed that as
long as the creation of sysfs files silently failed, and we both missed
it before the merge, because we don't run SYSFS_DEPRECATED=y.

Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>
Cc: Larry Finger <[EMAIL PROTECTED]>
Cc: David Miller <[EMAIL PROTECTED]>
Cc: Rafael J. Wysocki <[EMAIL PROTECTED]>
Cc: Tejun Heo <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/base/core.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index c134341..3f4d6aa 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1228,18 +1228,18 @@ int device_rename(struct device *dev, char *new_name)
sysfs_remove_link(&dev->parent->kobj, old_class_name);
}
}
-#endif
-
+#else
if (dev->class) {
sysfs_remove_link(&dev->class->subsys.kobj, old_device_name);
error = sysfs_create_link(&dev->class->subsys.kobj, &dev->kobj,
  dev->bus_id);
if (error) {
-   /* Uh... how to unravel this if restoring can fail? */
dev_err(dev, "%s: sysfs_create_symlink failed (%d)\n",
__FUNCTION__, error);
}
}
+#endif
+
 out:
put_device(dev);
 
-- 
1.5.3.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/

[PATCH 3/6] sysfs: make sysfs_{get,put}_active() static

2007-10-30 Thread Greg Kroah-Hartman

From: Adrian Bunk <[EMAIL PROTECTED]>

sysfs_{get,put}_active() can now become static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 fs/sysfs/dir.c   |4 ++--
 fs/sysfs/sysfs.h |2 --
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 7a8ce9e..3371629 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -132,7 +132,7 @@ struct dentry *sysfs_get_dentry(struct sysfs_dirent *sd)
  * RETURNS:
  * Pointer to @sd on success, NULL on failure.
  */
-struct sysfs_dirent *sysfs_get_active(struct sysfs_dirent *sd)
+static struct sysfs_dirent *sysfs_get_active(struct sysfs_dirent *sd)
 {
if (unlikely(!sd))
return NULL;
@@ -161,7 +161,7 @@ struct sysfs_dirent *sysfs_get_active(struct sysfs_dirent 
*sd)
  * Put an active reference to @sd.  This function is noop if @sd
  * is NULL.
  */
-void sysfs_put_active(struct sysfs_dirent *sd)
+static void sysfs_put_active(struct sysfs_dirent *sd)
 {
struct completion *cmpl;
int v;
diff --git a/fs/sysfs/sysfs.h b/fs/sysfs/sysfs.h
index f841798..ff17f8d 100644
--- a/fs/sysfs/sysfs.h
+++ b/fs/sysfs/sysfs.h
@@ -103,8 +103,6 @@ extern const struct file_operations sysfs_dir_operations;
 extern const struct inode_operations sysfs_dir_inode_operations;
 
 struct dentry *sysfs_get_dentry(struct sysfs_dirent *sd);
-struct sysfs_dirent *sysfs_get_active(struct sysfs_dirent *sd);
-void sysfs_put_active(struct sysfs_dirent *sd);
 struct sysfs_dirent *sysfs_get_active_two(struct sysfs_dirent *sd);
 void sysfs_put_active_two(struct sysfs_dirent *sd);
 void sysfs_addrm_start(struct sysfs_addrm_cxt *acxt,
-- 
1.5.3.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/

[PATCH 2/6] kobject: check for duplicate names in kobject_rename

2007-10-30 Thread Greg Kroah-Hartman

This should catch any duplicate names before we try to tell sysfs to
rename the object.  This happens a lot with older versions of udev and
the network rename scripts.

Cc: David Miller <[EMAIL PROTECTED]>
Cc: Kay Sievers <[EMAIL PROTECTED]>
Cc: Rafael J. Wysocki <[EMAIL PROTECTED]>
Cc: Tejun Heo <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 lib/kobject.c |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/lib/kobject.c b/lib/kobject.c
index 03d4036..a7e3bf4 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -308,6 +308,19 @@ int kobject_rename(struct kobject * kobj, const char 
*new_name)
if (!kobj->parent)
return -EINVAL;
 
+   /* see if this name is already in use */
+   if (kobj->kset) {
+   struct kobject *temp_kobj;
+   temp_kobj = kset_find_obj(kobj->kset, new_name);
+   if (temp_kobj) {
+   printk(KERN_WARNING "kobject '%s' can not be renamed "
+  "to '%s' as '%s' is already in existance.\n",
+  kobject_name(kobj), new_name, new_name);
+   kobject_put(temp_kobj);
+   return -EINVAL;
+   }
+   }
+
devpath = kobject_get_path(kobj, GFP_KERNEL);
if (!devpath) {
error = -ENOMEM;
-- 
1.5.3.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/

[PATCH 1/6] Driver core: remove class_device_*_bin_file

2007-10-30 Thread Greg Kroah-Hartman

These functions are not used by anyone, so remove them from the tree.

The class_device code will be removed soon anyway, so no future users
will ever be possible.


Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/base/class.c   |   18 --
 include/linux/device.h |4 
 2 files changed, 0 insertions(+), 22 deletions(-)

diff --git a/drivers/base/class.c b/drivers/base/class.c
index a863bb0..f6ebe6a 100644
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -257,22 +257,6 @@ void class_device_remove_file(struct class_device * 
class_dev,
sysfs_remove_file(&class_dev->kobj, &attr->attr);
 }
 
-int class_device_create_bin_file(struct class_device *class_dev,
-struct bin_attribute *attr)
-{
-   int error = -EINVAL;
-   if (class_dev)
-   error = sysfs_create_bin_file(&class_dev->kobj, attr);
-   return error;
-}
-
-void class_device_remove_bin_file(struct class_device *class_dev,
- struct bin_attribute *attr)
-{
-   if (class_dev)
-   sysfs_remove_bin_file(&class_dev->kobj, attr);
-}
-
 static ssize_t
 class_device_attr_show(struct kobject * kobj, struct attribute * attr,
   char * buf)
@@ -885,8 +869,6 @@ EXPORT_SYMBOL_GPL(class_device_create);
 EXPORT_SYMBOL_GPL(class_device_destroy);
 EXPORT_SYMBOL_GPL(class_device_create_file);
 EXPORT_SYMBOL_GPL(class_device_remove_file);
-EXPORT_SYMBOL_GPL(class_device_create_bin_file);
-EXPORT_SYMBOL_GPL(class_device_remove_bin_file);
 
 EXPORT_SYMBOL_GPL(class_interface_register);
 EXPORT_SYMBOL_GPL(class_interface_unregister);
diff --git a/include/linux/device.h b/include/linux/device.h
index 2e15822..2c5e49d 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -291,10 +291,6 @@ extern void class_device_put(struct class_device *);
 
 extern void class_device_remove_file(struct class_device *, 
 const struct class_device_attribute *);
-extern int __must_check class_device_create_bin_file(struct class_device *,
-   struct bin_attribute *);
-extern void class_device_remove_bin_file(struct class_device *,
-struct bin_attribute *);
 
 struct class_interface {
struct list_headnode;
-- 
1.5.3.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: [PATCH 00/33] Swap over NFS -v14

2007-10-30 Thread Nick Piggin

On Wednesday 31 October 2007 15:37, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Wed, 31 Oct 2007 14:26:32 +1100
>
> > Is it really worth all the added complexity of making swap
> > over NFS files work, given that you could use a network block
> > device instead?
>
> Don't be misled.  Swapping over NFS is just a scarecrow for the
> seemingly real impetus behind these changes which is network storage
> stuff like iSCSI.

Oh, I'm OK with the network reserves stuff (not the actual patch,
which I'm not really qualified to review, but at least the idea
of it...).

And also I'm not as such against the idea of swap over network.

However, specifically the change to make swapfiles work through
the filesystem layer (ATM it goes straight to the block layer,
modulo some initialisation stuff which uses block filesystem-
specific calls).

I mean, I assume that anybody trying to swap over network *today*
has to be using a network block device anyway, so the idea of
just being able to transparently improve that case seems better
than adding new complexities for seemingly not much gain.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] driver core fixes for 2.6.24-rc1

2007-10-30 Thread Greg KH

Here are some driver core bugfixes and tweaks for 2.6.24-rc1.  It fixes
the much-reported sysfs traceback when renaming network devices when
CONFIG_SYSFS_DEPRECATED is enabled.

There is also a documentation translation and typo fix, and some other
minor things.

Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/

Patches will be sent as a follow-on to this message to lkml for people
to see.

thanks,

greg k-h


 Documentation/SubmittingPatches   |4 +-
 Documentation/ja_JP/SubmittingPatches |  556 +
 drivers/base/class.c  |   18 -
 drivers/base/core.c   |6 +-
 fs/sysfs/dir.c|4 +-
 fs/sysfs/sysfs.h  |2 -
 include/linux/device.h|4 -
 lib/kobject.c |   13 +
 8 files changed, 576 insertions(+), 31 deletions(-)
 create mode 100644 Documentation/ja_JP/SubmittingPatches

---

Adrian Bunk (1):
  sysfs: make sysfs_{get,put}_active() static

Greg Kroah-Hartman (2):
  Driver core: remove class_device_*_bin_file
  kobject: check for duplicate names in kobject_rename

Kay Sievers (1):
  Driver Core: fix bug in device_rename() for SYSFS_DEPRECATED=y

Keiichi Kii (2):
  fix typo in SubmittingPatches
  add SubmittingPatches to Documentation/ja_JP

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] CFS : Use NSEC_PER_MSEC and NSEC_PER_SEC in kernel/sched.c and kernel/sysctl.c

2007-10-30 Thread Eric Dumazet

1) hardcoded 10 value is used five times in places where NSEC_PER_SEC 
might be more readable.


2) A conversion from nsec to msec uses the hardcoded 100 value, which is a 
candidate for NSEC_PER_MSEC.


Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>

diff --git a/kernel/sched.c b/kernel/sched.c
index 3f6bd11..57c539d 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -75,7 +75,7 @@
  */
 unsigned long long __attribute__((weak)) sched_clock(void)
 {
-   return (unsigned long long)jiffies * (10 / HZ);
+   return (unsigned long long)jiffies * (NSEC_PER_SEC / HZ);
 }
 
 /*
@@ -99,8 +99,8 @@ unsigned long long __attribute__((weak)) sched_clock(void)
 /*
  * Some helpers for converting nanosecond timing to jiffy resolution
  */
-#define NS_TO_JIFFIES(TIME)((unsigned long)(TIME) / (10 / HZ))
-#define JIFFIES_TO_NS(TIME)((TIME) * (10 / HZ))
+#define NS_TO_JIFFIES(TIME)((unsigned long)(TIME) / (NSEC_PER_SEC / HZ))
+#define JIFFIES_TO_NS(TIME)((TIME) * (NSEC_PER_SEC / HZ))
 
 #define NICE_0_LOADSCHED_LOAD_SCALE
 #define NICE_0_SHIFT   SCHED_LOAD_SHIFT
@@ -7228,7 +7228,7 @@ static u64 cpu_usage_read(struct cgroup *cgrp, struct 
cftype *cft)
spin_unlock_irqrestore(&cpu_rq(i)->lock, flags);
}
/* Convert from ns to ms */
-   do_div(res, 100);
+   do_div(res, NSEC_PER_MSEC);
 
return res;
 }
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 3b4efbe..6547f9a 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -226,9 +226,9 @@ static struct ctl_table root_table[] = {
 
 #ifdef CONFIG_SCHED_DEBUG
 static unsigned long min_sched_granularity_ns = 10;/* 100 
usecs */
-static unsigned long max_sched_granularity_ns = 10;/* 1 second */
+static unsigned long max_sched_granularity_ns = NSEC_PER_SEC;  /* 1 second */
 static unsigned long min_wakeup_granularity_ns;/* 0 
usecs */
-static unsigned long max_wakeup_granularity_ns = 10;   /* 1 second */
+static unsigned long max_wakeup_granularity_ns = NSEC_PER_SEC; /* 1 second */
 #endif
 
 static struct ctl_table kern_table[] = {

Re: [possibly OT] for_each_netdev() in 2.6.23-gitX / 2.6.24-rc1-gitY breaks Cisco VPN client

2007-10-30 Thread Stephen Hemminger

On Wed, 31 Oct 2007 01:35:47 +0100
"Alessandro Suardi" <[EMAIL PROTECTED]> wrote:

> It's been a while I noticed, but I thought someone would as usual
>  cook up some fix, while I don't even see the issue been reported...
>  if this isn't a Linux kernel/net issue just drop my email, thanks.
> 
> Error message during cisco_vpn.ko build:
> 
> /download/linux/net/vpnclient/interceptor.c:345:23: error: macro
> "for_each_netdev" requires 2 arguments, but only 1 given
> 

RTFM Documentation/stable_api_nonsense.txt


-- 
Stephen Hemminger <[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: Multiple MSI messages support

2007-10-30 Thread Shawn Jin

On Oct 30, 2007 8:00 PM, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Roland Dreier wrote:
> > Multiple interrupt messages are supported by Linux via MSI-X (which
>
> Absolutely, but the poster seemed to be talking about MSI, not MSI-X.

I guess Roland understood my intention. :-P

My interpretation of this statement is that you have to use MSIX if
multiple MSI messages are required on Linux.

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

Re: Linux Security Module Framework (Was: LSM conversion to static interface)

2007-10-30 Thread david


On Wed, 31 Oct 2007, Peter Dolding wrote:


On 10/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

On Wed, 31 Oct 2007, Peter Dolding wrote:


MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are
applied over using Selinux rules.  This is just the way it is stacking LSM's
is Just not healthy you always risk on LSM breaking another.  Part of the
reason why I have suggested a complete redesign of LSM.  To get away from
this problem of stacking.


since the method of stacking hasn't been determined yet, you can't say
this.


I can because that is the current day problem. With many LSM's loaded
they stack completely as a complete mess and with problems.  They
fight with each other.  Lack of define on stacking equals big
problems.   Since you have not created a standard for stacking does
not stop the problem from existing.  Nice lack of planing when LSM
started or maybe its intentional.  When you need stacking its about
time you start moving things into the OS?


the lack of a stacking ability was deliberate (go back and read the 
archives). basicly no LSM was willing to admit that they weren't the 
be-all, end-all of security, so nobody was willing to consider that anyone 
would ever want anything else.


one method of doing the stacking would be for the LSM to not know about 
the stacking, but the kernel takes care of passing all requests through 
each LSM in order (if the LSMs can be staticly compiled the order should 
be able to be changed at compile time)


now, the existing policies for some LSM's may need to change, becouse 
they've been assuming that they only needed to check capabilities for 
UID=0, when they will now need to check them for everyone, but arguably, 
this was a bug masquerading as an optimization in the first place.



There is a way around the problem too without allowing LSM to stack.
Good advantage backward compatible  because your are not playing with
the LSM standard to do it so no LSM modules should need large
alterations.  At worse mirror extensions to handle the new OS feature.
Posix File Capabilities provide the solution.   First done as a LSM
risked conflict.   Moved in as a operating system extension by by
conflict.  Fragments from LSM's should exactly move that way if they
expect to be overlapped by other models.

Lot of stacking problems can be avoided if segments are complete
standard extensions.


which LSM gets to declare the standards?



it would be possible for MultiAdmin to grant additional access, that
SELinux then denies for it's own reasons.

if the SELinux policy is written so that it ignores capabilities, and
instead just looks at uid0 then that policy is broken in a stacked
environment, but it's the polciy that's broken, not the stacking.


That is not how current day always works.  MultiAdmin grants and that
can be the end of the treeing.   Selinux does not get asked if it
refuses it or not.  So no matter what was set in the Selinux policy it
may never get used.   Adding more layers is also bad for performance
to.  Treeing threw modules for rights is a really slow process.  As
like a posix feature extension.   Selinux/Other LSM's is at top of
allocation no flaw no bypass.


only if the stacking mode permits this. if it always requires passing 
through all the layers then this wouldn't be a problem.


Besides which, the MultiAdmin authors would probably be willing to make 
the nessasary changes to their LSM to play nicely with others anyway (but 
good programming practice would dictate that you don't count on it, and 
arrange for the other modules to approve as well)



yes, there will be interactions that don't make sense, but just becouse
something can be used wrong doesn't mean that there aren't other cases
where it can be used properly.


We are talking security here if its not order safe its not good.
MultiAdmin done as a posix feature extension is order safe.
MultiAdmin done as a LSM is not order safe.


as things are currently written, it's not possible to stack, so there is 
no order. change how things are written and you can make them safe.



System Admins are humans too.  Getting orders backwards does happen.
So should be avoided where able.


the sysadmins need to be given enough rope, you don't know everything that 
they are trying to do, and you don't know what other LSMs going to do. so 
how can you possibly decide ahead of time what orders are safe?



This completely avoids the need for adding another layer of stacking
and since built inside current day framework.  Does doing this risk
the end of LSM's as we know it yes it does.  Since it is not being
used as LSM were intended.  LSM is just a addon to standard OS
security what is either a testing ground for new features to secure
the OS that get build into the OS in time or as location for security
modules.

Somethings should be just done in the Standard OS security nothing to
do with LSM.

Little bit hard for some I guess to hear that LSM are not all
important and no

Re: [PATCH 09/33] mm: system wide ALLOC_NO_WATERMARK

2007-10-30 Thread Nick Piggin

On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
> Change ALLOC_NO_WATERMARK page allocation such that the reserves are system
> wide - which they are per setup_per_zone_pages_min(), when we scrape the
> barrel, do it properly.
>

IIRC it's actually not too uncommon to have allocations coming here via
page reclaim. It's not exactly clear that you want to break mempolicies
at this point.


> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> ---
>  mm/page_alloc.c |6 ++
>  1 file changed, 6 insertions(+)
>
> Index: linux-2.6/mm/page_alloc.c
> ===
> --- linux-2.6.orig/mm/page_alloc.c
> +++ linux-2.6/mm/page_alloc.c
> @@ -1638,6 +1638,12 @@ restart:
>  rebalance:
>   if (alloc_flags & ALLOC_NO_WATERMARKS) {
>  nofail_alloc:
> + /*
> +  * break out of mempolicy boundaries
> +  */
> + zonelist = NODE_DATA(numa_node_id())->node_zonelists +
> + gfp_zone(gfp_mask);
> +
>   /* go through the zonelist yet again, ignoring mins */
>   page = get_page_from_freelist(gfp_mask, order, zonelist,
>   ALLOC_NO_WATERMARKS);
>
> --
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 06/33] mm: allow PF_MEMALLOC from softirq context

2007-10-30 Thread Nick Piggin

On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
> Allow PF_MEMALLOC to be set in softirq context. When running softirqs from
> a borrowed context save current->flags, ksoftirqd will have its own
> task_struct.

What's this for? Why would ksoftirqd pick up PF_MEMALLOC? (I guess
that some networking thing must be picking it up in a subsequent patch,
but I'm too lazy to look!)... Again, can you have more of a rationale in
your patch headers, or ref the patch that uses it... thanks

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: tipc_config.h requires linux/string.h, which does not exist in exported headers

2007-10-30 Thread David Miller

From: David Miller <[EMAIL PROTECTED]>
Date: Tue, 30 Oct 2007 21:14:04 -0700 (PDT)

> Unfortunately I have to back it out, it breaks the build.
> 
> In file included from net/tipc/core.h:41,
>  from net/tipc/addr.c:37:
> include/linux/tipc_config.h: In function 'TLV_SET':
> include/linux/tipc_config.h:306: error: implicit declaration of function 
> 'memcpy'
> include/linux/tipc_config.h:306: warning: incompatible implicit declaration 
> of built-in function 'memcpy'
> 
> I truly think adding linux/string.h to unifdef-y along with:
> 
> #ifndef __KERNEL__
> #include 
> #else
>  ...
> #endif
> 
> in linux/string.h is a much cleaner and less error prone solution :-)

Here is what I mean, specifically.  And this is build tested :-)

>From 97ef1bb0c8e371b7988287f38bd107c4aa14d78d Mon Sep 17 00:00:00 2001
From: David S. Miller <[EMAIL PROTECTED]>
Date: Tue, 30 Oct 2007 21:44:00 -0700
Subject: [PATCH] [TIPC]: Fix headercheck wrt. tipc_config.h

It wants string functions like memcpy() for inline
routines, and these define userland interfaces.

The only clean way to deal with this is to simply
put linux/string.h into unifdef-y and have it
include  when not-__KERNEL__.

Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
 include/linux/Kbuild   |1 +
 include/linux/string.h |   12 +++-
 2 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index bd33c22..37bfa19 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -326,6 +326,7 @@ unifdef-y += sonypi.h
 unifdef-y += soundcard.h
 unifdef-y += stat.h
 unifdef-y += stddef.h
+unifdef-y += string.h
 unifdef-y += synclink.h
 unifdef-y += sysctl.h
 unifdef-y += tcp.h
diff --git a/include/linux/string.h b/include/linux/string.h
index 836062b..c5d3fca 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -3,16 +3,14 @@
 
 /* We don't want strings.h stuff being user by user stuff by accident */
 
-#ifdef __KERNEL__
+#ifndef __KERNEL__
+#include 
+#else
 
 #include /* for inline */
 #include/* for size_t */
 #include   /* for NULL */
 
-#ifdef __cplusplus
-extern "C" {
-#endif
-
 extern char *strndup_user(const char __user *, long);
 
 /*
@@ -111,9 +109,5 @@ extern void *kmemdup(const void *src, size_t len, gfp_t 
gfp);
 extern char **argv_split(gfp_t gfp, const char *str, int *argcp);
 extern void argv_free(char **argv);
 
-#ifdef __cplusplus
-}
-#endif
-
 #endif
 #endif /* _LINUX_STRING_H_ */
-- 
1.5.2.5

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 05/33] mm: kmem_estimate_pages()

2007-10-30 Thread Nick Piggin

On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
> Provide a method to get the upper bound on the pages needed to allocate
> a given number of objects from a given kmem_cache.
>

Fair enough, but just to make it a bit easier, can you provide a
little reason of why in this patch (or reference the patch number
where you use it, or put it together with the patch where you use
it, etc.).

Thanks,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 04/33] mm: allow mempool to fall back to memalloc reserves

2007-10-30 Thread Nick Piggin

On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
> Allow the mempool to use the memalloc reserves when all else fails and
> the allocation context would otherwise allow it.

I don't see what this is for. The whole point of when I fixed this
to *not* use the memalloc reserves is because processes that were
otherwise allowed to use those reserves, were. They should not.



> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> ---
>  mm/mempool.c |   12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> Index: linux-2.6/mm/mempool.c
> ===
> --- linux-2.6.orig/mm/mempool.c
> +++ linux-2.6/mm/mempool.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include "internal.h"
>
>  static void add_element(mempool_t *pool, void *element)
>  {
> @@ -204,7 +205,7 @@ void * mempool_alloc(mempool_t *pool, gf
>   void *element;
>   unsigned long flags;
>   wait_queue_t wait;
> - gfp_t gfp_temp;
> + gfp_t gfp_temp, gfp_orig = gfp_mask;
>
>   might_sleep_if(gfp_mask & __GFP_WAIT);
>
> @@ -228,6 +229,15 @@ repeat_alloc:
>   }
>   spin_unlock_irqrestore(&pool->lock, flags);
>
> + /* if we really had right to the emergency reserves try those */
> + if (gfp_to_alloc_flags(gfp_orig) & ALLOC_NO_WATERMARKS) {
> + if (gfp_temp & __GFP_NOMEMALLOC) {
> + gfp_temp &= ~(__GFP_NOMEMALLOC|__GFP_NOWARN);
> + goto repeat_alloc;
> + } else
> + gfp_temp |= __GFP_NOMEMALLOC|__GFP_NOWARN;
> + }
> +
>   /* We must not sleep in the GFP_ATOMIC case */
>   if (!(gfp_mask & __GFP_WAIT))
>   return NULL;
>
> --
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 03/33] mm: slub: add knowledge of reserve pages

2007-10-30 Thread Nick Piggin

On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
> Restrict objects from reserve slabs (ALLOC_NO_WATERMARKS) to allocation
> contexts that are entitled to it.
>
> Care is taken to only touch the SLUB slow path.
>
> This is done to ensure reserve pages don't leak out and get consumed.

I think this is generally a good idea (to prevent slab allocators
from stealing reserve). However I naively think the implementation
is a bit overengineered and thus has a few holes.

Humour me, what was the problem with failing the slab allocation
(actually, not fail but just call into the page allocator to do
correct waiting  / reclaim) in the slowpath if the process fails the
watermark checks?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] af_key: suppress a warning for 64k pages.

2007-10-30 Thread David Miller

From: Stephen Rothwell <[EMAIL PROTECTED]>
Date: Wed, 31 Oct 2007 15:34:22 +1100

> On Tue, 30 Oct 2007 21:08:46 -0700 (PDT) David Miller <[EMAIL PROTECTED]> 
> wrote:
> > I think we should retain the check, but modify it so that GCC knows we
> > understand that it's OK if it is always false.  Perhaps a simple (u32)
> > cast on the left branch of the comparison is sufficient?
> 
> Unfortunately, that does not suppress the warning (gcc is getting too
> smart :-().

It seems if you break the comparison out into a function which
takes a u32, that's enough to get rid of the warning.

I can't figure out a way to make this prettier, can you?

#define PAGE_SIZE   (64 * 1024)

typedef unsigned int u32;
typedef unsigned short u16;

int compare(u32 val)
{
if (val >= PAGE_SIZE)
return -1;
return 0;
}

int foo(u16 val)
{
#if 1
return compare(val);
#else
if (val >= PAGE_SIZE)
return -1;
return 0;
#endif
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.22.7 Machine Check Exception

2007-10-30 Thread Andrew Morton

On Thu, 25 Oct 2007 12:40:58 +0200 Michael Stiller <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> i encountered the following machine check exceptions (and hangs) with
> 2.6.22.7 on an Dual Core-2 Xeon System. It occurs if i try to use the
> PCI-X Intel Gigabit Ethernet card after some minutes:
> 
> CPU 3: Machine Check Exception 0005
> Bank 0: b2401400
> Bank 5: b20012102400
> 
> or
> 
> CPU 1: Machine Check Exception 0005
> Bank 0: b2401400
> Bank 5: b20012102400
> 
> What is the cause? How can this be debugged?
> 

I guess it means your hardware is sick.  Presumably those two
numbers were supposed to be the same.

I assume this is the same machine as in your "2.6.22.7 reboots if PCI-X eth
card is used for capture" report?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 00/33] Swap over NFS -v14

2007-10-30 Thread David Miller

From: Nick Piggin <[EMAIL PROTECTED]>
Date: Wed, 31 Oct 2007 14:26:32 +1100

> Is it really worth all the added complexity of making swap
> over NFS files work, given that you could use a network block
> device instead?

Don't be misled.  Swapping over NFS is just a scarecrow for the
seemingly real impetus behind these changes which is network storage
stuff like iSCSI.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] af_key: suppress a warning for 64k pages.

2007-10-30 Thread Stephen Rothwell

On Tue, 30 Oct 2007 21:08:46 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote:
>
> I'm not so sure ifdef'ing things up all over the place is the way to
> solve this.  It makes the code ultra ugly.

I agree.

> I think we should retain the check, but modify it so that GCC knows we
> understand that it's OK if it is always false.  Perhaps a simple (u32)
> cast on the left branch of the comparison is sufficient?

Unfortunately, that does not suppress the warning (gcc is getting too
smart :-().

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpwQ8N1ii73T.pgp
Description: PGP signature

Re: [PATCH 00/33] Swap over NFS -v14

2007-10-30 Thread Nick Piggin

On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
> Hi,
>
> Another posting of the full swap over NFS series.

Hi,

Is it really worth all the added complexity of making swap
over NFS files work, given that you could use a network block
device instead?

Also, have you ensured that page_file_index, page_file_mapping
and page_offset are only ever used on anonymous pages when the
page is locked? (otherwise PageSwapCache could change)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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]: exit_ivtv_i2c() cannot be __devexit

2007-10-30 Thread David Miller


Please apply, thanks!

[MEDIA] IVTV: exit_ivtv_i2c() cannot be __devexit

It is referenced both from __devinit code (ivtv_probe) and
normal .text (ivtv_process_eeprom), and therefore cannot
be discarded via __devexit.

Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
 drivers/media/video/ivtv/ivtv-i2c.c |2 +-
 drivers/media/video/ivtv/ivtv-i2c.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/ivtv/ivtv-i2c.c 
b/drivers/media/video/ivtv/ivtv-i2c.c
index 285fca6..623eea2 100644
--- a/drivers/media/video/ivtv/ivtv-i2c.c
+++ b/drivers/media/video/ivtv/ivtv-i2c.c
@@ -741,7 +741,7 @@ int __devinit init_ivtv_i2c(struct ivtv *itv)
return i2c_bit_add_bus(&itv->i2c_adap);
 }
 
-void __devexit exit_ivtv_i2c(struct ivtv *itv)
+void exit_ivtv_i2c(struct ivtv *itv)
 {
IVTV_DEBUG_I2C("i2c exit\n");
 
diff --git a/drivers/media/video/ivtv/ivtv-i2c.h 
b/drivers/media/video/ivtv/ivtv-i2c.h
index 677c329..de6a074 100644
--- a/drivers/media/video/ivtv/ivtv-i2c.h
+++ b/drivers/media/video/ivtv/ivtv-i2c.h
@@ -36,6 +36,6 @@ void ivtv_call_i2c_clients(struct ivtv *itv, unsigned int 
cmd, void *arg);
 
 /* init + register i2c algo-bit adapter */
 int __devinit init_ivtv_i2c(struct ivtv *itv);
-void __devexit exit_ivtv_i2c(struct ivtv *itv);
+void exit_ivtv_i2c(struct ivtv *itv);
 
 #endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.24: (ACPI AC adapter) sending {proc,netlink,kobject}_event from -> resume method?

2007-10-30 Thread Andrey Borzenkov

On Wednesday 31 October 2007, Rafael J. Wysocki wrote:
> On Tuesday, 30 October 2007 20:33, Andrey Borzenkov wrote:
> > Is it valid to send events from within ->resume device method?
>
> It is or at least it should be.  The GPEs are supposed to be fully
> functional at this point.
>
> > If not, what is the proper way to notify user space about hardware
> > changes during suspension?
> > Specifically it seems that new sysfs ACPI power supply interface
> > sometimes missing plugged in AC cord during suspend. I suspect that no
> > event is generated for this; I am not sure whether ACPI is required to
> > generate such events at all in this case.
> >
> > I'll need some time to get reproducible case so I do not categorize this
> > yet as regression.
>
> Is the "[2.6.24-rc1 regression] AC adapter state does not change after
> resume" message a follow-up to this one?
>

yes


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

Re: [2.6.24-rc1 regression] AC adapter state does not change after resume

2007-10-30 Thread Andrey Borzenkov

On Wednesday 31 October 2007, Rafael J. Wysocki wrote:
> On Tuesday, 30 October 2007 21:24, Andrey Borzenkov wrote:
> > I suspect new ACPI AC adapter code but have to add some printk's to be
> > sure.
> >
> > To reproduce - plug in AC cord, suspend, unplug, resume - kpowersave and
> > sysfs still show AC adapter online. Or other way round.
>
> Is this a resume from RAM or from disk?
>

RAM

> Does 2.6.23 work correctly?
>

yes


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

Re: 2.6.23 regression: accessing invalid mmap'ed memory from gdb causes unkillable spinning

2007-10-30 Thread Nick Piggin

On Wed, Oct 31, 2007 at 12:45:35AM +, Duane Griffin wrote:
> Accessing a memory mapped region past the last page containing a valid
> file mapping produces a SIGBUS fault (as it should). Running a program
> that does this under gdb, then accessing the invalid memory from gdb,
> causes it to start consuming 100% CPU and become unkillable. Once in
> that state, SysRq-T doesn't show a stack trace for gdb, although it is
> shown as running and stack traces are dumped for other tasks.
> 
> 2.6.22 does not have this bug (gdb just prints '\0' as the contents,
> although arguably that is also a bug, and it should instead report the
> SIGBUS).
> 
> Bisection indicates the problem was introduced by:
> 
> 54cb8821de07f2ffcd28c380ce9b93d5784b40d7
> "mm: merge populate and nopage into fault (fixes nonlinear)"
> 
> The following program demonstrates the issue:
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> int main(int argc, char *argv[])
> {
> int fd;
> struct stat buf;
> 
> if (argc != 2) {
> fprintf(stderr, "usage: %s \n", argv[0]);
> exit(1);
> }
> 
> fd = open(argv[1], O_RDONLY);
> fstat(fd, &buf);
> int count = buf.st_size + sysconf(_SC_PAGE_SIZE);
> char *file = (char *) mmap(NULL, count, PROT_READ, MAP_PRIVATE, fd, 
> 0);
> if (file == MAP_FAILED) {
> fprintf(stderr, "mmap failed: %s\n", strerror(errno));
> } else {
> char ch;
> fprintf(stderr, "using offset %d\n", (count - 1));
> ch = file[count - 1];
> munmap(file, count);
> }
> close(fd);
> return 0;
> }
> 
> To reproduce the bug, run it under gdb, go up a couple of frames to
> the main function, then access invalid memory, for e.g. with: "print
> file[4095]", or whatever offset was reported.


Well that's probably the best bug report I've ever had, thanks Duane!

The issue is a silly thinko -- I didn't pay enough attention to the ptrace
rules in filemap_fault :( partly I think that's because I don't understand
them and am scared of them ;)

The following minimal patch fixes it here, and should probably be applied to
2.6.23 stable as well as 2.6.24. If you could verify it, that would be much
appreciated.

However I actually don't really like how this all works. I don't like that
filemap.c should have to know about ptrace, or exactly what ptrace wants here.
It's a bit hairy to force insert page into pagecache and pte into pagetables
here, given the races.

In access_process_vm, can't we just zero fill in the case of a sigbus? Linus?
That will also avoid changing applicatoin behaviour due to a gdb read...

Thanks,
Nick

--
Duane Griffin noticed a 2.6.23 regression that will cause gdb to hang when
it tries to access the memory of another process beyond i_size.

This is because the solution to the fault vs invalidate race requires that
we recheck i_size after the page lock is taken. However in that case, I
had not accounted for the fact that ptracers are granted an exception to this
rule.

Cc: Duane Griffin <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]
---
Index: linux-2.6/mm/filemap.c
===
--- linux-2.6.orig/mm/filemap.c
+++ linux-2.6/mm/filemap.c
@@ -1374,7 +1374,7 @@ retry_find:
 
/* Must recheck i_size under page lock */
size = (i_size_read(inode) + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
-   if (unlikely(vmf->pgoff >= size)) {
+   if (unlikely(vmf->pgoff >= size) && vma->vm_mm == current->mm) {
unlock_page(page);
page_cache_release(page);
goto outside_data_content;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 07/14] Blackfin SPI driver: Add SPI master controller platform device 1

2007-10-30 Thread Bryan Wu


On Tue, 2007-10-30 at 12:08 -0700, David Brownell wrote:
> On Tuesday 30 October 2007, Bryan Wu wrote:
> > From: Sonic Zhang <[EMAIL PROTECTED]>
> > 
> > Signed-off-by: Sonic Zhang <[EMAIL PROTECTED]>
> > Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
> 
> The patch comments in this series leave a bit to be desired,
> especially patches from Sonic.  (Several are like this one:
> just a $SUBJECT, no description.)  I've improved them in the
> versions I'll be sending on ...
> 
Sorry, that's my fault. 

Sonic's original patch modified this driver file and the Blackfin arch
related files. So I separated the patch to this SPI driver specific code
and Blackfin arch related patch which should be merged in Blackfin git
tree.

But I didn't change the description and subject here.

> It's worth noting that in this case the $SUBJECT doesn't
> relate *at all* to what this patch actually does!  Namely,
> it uses the portmux mechanism to add support for two more
> SPI buses ... it doesn't add a platform device.
> 

Sorry again, it will not happen again.

-Bryan Wu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: tipc_config.h requires linux/string.h, which does not exist in exported headers

2007-10-30 Thread David Miller

From: David Miller <[EMAIL PROTECTED]>
Date: Tue, 30 Oct 2007 15:31:54 -0700 (PDT)

> From: Sam Ravnborg <[EMAIL PROTECTED]>
> Date: Tue, 30 Oct 2007 23:20:25 +0100
> 
> > Something like this..
> > I like it - much better than adding string.h to unidef-y.
> > PS - had not pulled latest -linus - so you must update Kbuild.
> > PPS - tipc.h should be exported too as I understood Stephen.
> 
> tipc.h is already listed in header-y.
> 
> I'll merge your patch, thanks Sam.

Unfortunately I have to back it out, it breaks the build.

In file included from net/tipc/core.h:41,
 from net/tipc/addr.c:37:
include/linux/tipc_config.h: In function 'TLV_SET':
include/linux/tipc_config.h:306: error: implicit declaration of function 
'memcpy'
include/linux/tipc_config.h:306: warning: incompatible implicit declaration of 
built-in function 'memcpy'

I truly think adding linux/string.h to unifdef-y along with:

#ifndef __KERNEL__
#include 
#else
 ...
#endif

in linux/string.h is a much cleaner and less error prone solution :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.24-rc1 regression] AC adapter state does not change after resume

2007-10-30 Thread Andrey Borzenkov

On Wednesday 31 October 2007, Alexey Starikovskiy wrote:
> Andrey Borzenkov wrote:
> > I suspect new ACPI AC adapter code but have to add some printk's to be
> > sure.
> >
> > To reproduce - plug in AC cord, suspend, unplug, resume - kpowersave and
> > sysfs still show AC adapter online. Or other way round.
> >
> > -andrey
>
> Please check if this patch helps.
>

It does not even compile :)

On serious note (after adding forward declaration) - patch half works. It does 
make "online" return true value (which confirms that underlying ACPI works 
correctly) but HAL still does not notice it.

The problem is, with power_supply interface HAL does not use polling, it 
relies on CHANGE event. This event is apparently never generated if AC 
adapter state changes on resume. So the obvious fix is to compare AC state 
before and after suspend in ->resume function and generate synthetic CHANGE 
event if something has changed.

This will also make superfluous polling redundant.

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

Re: [PATCH] af_key: suppress a warning for 64k pages.

2007-10-30 Thread David Miller

From: Stephen Rothwell <[EMAIL PROTECTED]>
Date: Wed, 31 Oct 2007 14:59:54 +1100

> On PowerPC allmodconfig build we get this:
> 
> net/key/af_key.c:400: warning: comparison is always false due to limited 
> range of data type
> 
> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
...
>  
> + /* sadb_x_ctx_len is uint16_t */
> +#if PAGE_SIZE < (1 << 16)
>   if (sec_ctx->sadb_x_ctx_len > PAGE_SIZE)
>   return -EINVAL;
> +#endif
>  
>   len = pfkey_sec_ctx_len(sec_ctx);
>  

I'm not so sure ifdef'ing things up all over the place is the way to
solve this.  It makes the code ultra ugly.

I think we should retain the check, but modify it so that GCC knows we
understand that it's OK if it is always false.  Perhaps a simple (u32)
cast on the left branch of the comparison is sufficient?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] aacraid: don't assign cpu_to_le32(constant) to u8

2007-10-30 Thread Stephen Rothwell

Noticed on PowerPC allmod config build:

drivers/scsi/aacraid/commsup.c:1342: warning: large integer implicitly 
truncated to unsigned type
drivers/scsi/aacraid/commsup.c:1343: warning: large integer implicitly 
truncated to unsigned type
drivers/scsi/aacraid/commsup.c:1344: warning: large integer implicitly 
truncated to unsigned type

Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
 drivers/scsi/aacraid/commsup.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]

diff --git a/drivers/scsi/aacraid/commsup.c b/drivers/scsi/aacraid/commsup.c
index 240a0bb..b9682a8 100644
--- a/drivers/scsi/aacraid/commsup.c
+++ b/drivers/scsi/aacraid/commsup.c
@@ -1339,9 +1339,9 @@ int aac_check_health(struct aac_dev * aac)
aif = (struct aac_aifcmd *)hw_fib->data;
aif->command = cpu_to_le32(AifCmdEventNotify);
aif->seqnum = cpu_to_le32(0x);
-   aif->data[0] = cpu_to_le32(AifEnExpEvent);
-   aif->data[1] = cpu_to_le32(AifExeFirmwarePanic);
-   aif->data[2] = cpu_to_le32(AifHighPriority);
+   aif->data[0] = AifEnExpEvent;
+   aif->data[1] = AifExeFirmwarePanic;
+   aif->data[2] = AifHighPriority;
aif->data[3] = cpu_to_le32(BlinkLED);
 
/*
-- 
1.5.3.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/

[PATCH] af_key: suppress a warning for 64k pages.

2007-10-30 Thread Stephen Rothwell

On PowerPC allmodconfig build we get this:

net/key/af_key.c:400: warning: comparison is always false due to limited range 
of data type

Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
 net/key/af_key.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]

diff --git a/net/key/af_key.c b/net/key/af_key.c
index 7969f8a..7da6c1a 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -397,8 +397,11 @@ static inline int verify_sec_ctx_len(void *p)
struct sadb_x_sec_ctx *sec_ctx = (struct sadb_x_sec_ctx *)p;
int len;
 
+   /* sadb_x_ctx_len is uint16_t */
+#if PAGE_SIZE < (1 << 16)
if (sec_ctx->sadb_x_ctx_len > PAGE_SIZE)
return -EINVAL;
+#endif
 
len = pfkey_sec_ctx_len(sec_ctx);
 
-- 
1.5.3.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: Multiple MSI messages support

2007-10-30 Thread Jeff Garzik


Roland Dreier wrote:

Multiple interrupt messages are supported by Linux via MSI-X (which


Absolutely, but the poster seemed to be talking about MSI, not MSI-X.

Jeff


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

[PATCH] selinux: suppress a warning for 64k pages.

2007-10-30 Thread Stephen Rothwell

On PowerPC allmodconfig build we get this:

security/selinux/xfrm.c:214: warning: comparison is always false due to limited 
range of data type

Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
 security/selinux/xfrm.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]

diff --git a/security/selinux/xfrm.c b/security/selinux/xfrm.c
index 36a191e..602beb0 100644
--- a/security/selinux/xfrm.c
+++ b/security/selinux/xfrm.c
@@ -211,8 +211,11 @@ static int selinux_xfrm_sec_ctx_alloc(struct xfrm_sec_ctx 
**ctxp,
if (uctx->ctx_doi != XFRM_SC_ALG_SELINUX)
return -EINVAL;
 
+   /* ctx_len is __u16 */
+#if PAGE_SIZE < (1 << 16)
if (uctx->ctx_len >= PAGE_SIZE)
return -ENOMEM;
+#endif
 
*ctxp = ctx = kmalloc(sizeof(*ctx) +
  uctx->ctx_len + 1,
-- 
1.5.3.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/

[PATCH] mtrr use type bool

2007-10-30 Thread Paul Jimenez


This is a janitorish patch to 1) remove private TRUE/FALSE #def's in
favor of using the standard enum from linux/stddef.h and 2) switch the
variables holding those values to type 'bool' (from linux/types.h)
since it both seems more appropriate and allows for potentially better
optimization.

As a truly minor aside, I removed a couple of comments documenting
a 'do_safe' parameter that seems to no longer exist.

Signed-off-by: Paul Jimenez <[EMAIL PROTECTED]>


diff --git a/arch/x86/kernel/cpu/mtrr/amd.c b/arch/x86/kernel/cpu/mtrr/amd.c
index 0949cdb..ee2331b 100644
--- a/arch/x86/kernel/cpu/mtrr/amd.c
+++ b/arch/x86/kernel/cpu/mtrr/amd.c
@@ -53,8 +53,6 @@ static void amd_set_mtrr(unsigned int reg, unsigned long base,
  The base address of the region.
  The size of the region. If this is 0 the region is disabled.
  The type of the region.
- If TRUE, do the change safely. If FALSE, safety measures should
-be done externally.
 [RETURNS] Nothing.
 */
 {
diff --git a/arch/x86/kernel/cpu/mtrr/generic.c 
b/arch/x86/kernel/cpu/mtrr/generic.c
index 992f08d..1c331c3 100644
--- a/arch/x86/kernel/cpu/mtrr/generic.c
+++ b/arch/x86/kernel/cpu/mtrr/generic.c
@@ -188,7 +188,7 @@ static inline void k8_enable_fixed_iorrs(void)
  * \param changed pointer which indicates whether the MTRR needed to be changed
  * \param msrwords pointer to the MSR values which the MSR should have
  */
-static void set_fixed_range(int msr, int * changed, unsigned int * msrwords)
+static void set_fixed_range(int msr, bool *changed, unsigned int *msrwords)
 {
unsigned lo, hi;
 
@@ -200,7 +200,7 @@ static void set_fixed_range(int msr, int * changed, 
unsigned int * msrwords)
((msrwords[0] | msrwords[1]) & K8_MTRR_RDMEM_WRMEM_MASK))
k8_enable_fixed_iorrs();
mtrr_wrmsr(msr, msrwords[0], msrwords[1]);
-   *changed = TRUE;
+   *changed = true;
}
 }
 
@@ -260,7 +260,7 @@ static void generic_get_mtrr(unsigned int reg, unsigned 
long *base,
 static int set_fixed_ranges(mtrr_type * frs)
 {
unsigned long long *saved = (unsigned long long *) frs;
-   int changed = FALSE;
+   bool changed = false;
int block=-1, range;
 
while (fixed_range_blocks[++block].ranges)
@@ -273,17 +273,17 @@ static int set_fixed_ranges(mtrr_type * frs)
 
 /*  Set the MSR pair relating to a var range. Returns TRUE if
 changes are made  */
-static int set_mtrr_var_ranges(unsigned int index, struct mtrr_var_range *vr)
+static bool set_mtrr_var_ranges(unsigned int index, struct mtrr_var_range *vr)
 {
unsigned int lo, hi;
-   int changed = FALSE;
+   bool changed = false;
 
rdmsr(MTRRphysBase_MSR(index), lo, hi);
if ((vr->base_lo & 0xf0ffUL) != (lo & 0xf0ffUL)
|| (vr->base_hi & (size_and_mask >> (32 - PAGE_SHIFT))) !=
(hi & (size_and_mask >> (32 - PAGE_SHIFT {
mtrr_wrmsr(MTRRphysBase_MSR(index), vr->base_lo, vr->base_hi);
-   changed = TRUE;
+   changed = true;
}
 
rdmsr(MTRRphysMask_MSR(index), lo, hi);
@@ -292,7 +292,7 @@ static int set_mtrr_var_ranges(unsigned int index, struct 
mtrr_var_range *vr)
|| (vr->mask_hi & (size_and_mask >> (32 - PAGE_SHIFT))) !=
(hi & (size_and_mask >> (32 - PAGE_SHIFT {
mtrr_wrmsr(MTRRphysMask_MSR(index), vr->mask_lo, vr->mask_hi);
-   changed = TRUE;
+   changed = true;
}
return changed;
 }
@@ -417,8 +417,6 @@ static void generic_set_mtrr(unsigned int reg, unsigned 
long base,
  The base address of the region.
  The size of the region. If this is 0 the region is disabled.
  The type of the region.
- If TRUE, do the change safely. If FALSE, safety measures should
-be done externally.
 [RETURNS] Nothing.
 */
 {
diff --git a/arch/x86/kernel/cpu/mtrr/if.c b/arch/x86/kernel/cpu/mtrr/if.c
index c7d8f17..1453568 100644
--- a/arch/x86/kernel/cpu/mtrr/if.c
+++ b/arch/x86/kernel/cpu/mtrr/if.c
@@ -37,7 +37,7 @@ const char *mtrr_attrib_to_str(int x)
 
 static int
 mtrr_file_add(unsigned long base, unsigned long size,
- unsigned int type, char increment, struct file *file, int page)
+ unsigned int type, bool increment, struct file *file, int page)
 {
int reg, max;
unsigned int *fcount = FILE_FCOUNT(file); 
@@ -55,7 +55,7 @@ mtrr_file_add(unsigned long base, unsigned long size,
base >>= PAGE_SHIFT;
size >>= PAGE_SHIFT;
}
-   reg = mtrr_add_page(base, size, type, 1);
+   reg = mtrr_add_page(base, size, type, true);
if (reg >= 0)
++fcount[reg];
return reg;
@@ -141,7 +141,7 @@ mtrr_write(struct file *file, const char __user *buf, 
size_t len, loff_t * ppos)
size >>= PAGE_SHIFT;
err =
mtrr_add_page((unsigned lon

[PATCH] libata: suppress two warnings

2007-10-30 Thread Stephen Rothwell

drivers/ata/libata-core.c:768: warning: 'ata_lpm_enable' defined but not used
drivers/ata/libata-core.c:784: warning: 'ata_lpm_disable' defined but not used

Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
 drivers/ata/libata-core.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 63035d7..7162645 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -735,6 +735,7 @@ enable_pm_out:
return /* rc */;/* hopefully we can use 'rc' eventually */
 }
 
+#ifdef CONFIG_PM
 /**
  * ata_dev_disable_pm - disable SATA interface power management
  * @device - device to enable ipm for
@@ -755,6 +756,7 @@ static void ata_dev_disable_pm(struct ata_device *dev)
if (ap->ops->disable_pm)
ap->ops->disable_pm(ap);
 }
+#endif /* CONFIG_PM */
 
 void ata_lpm_schedule(struct ata_port *ap, enum link_pm policy)
 {
@@ -764,6 +766,7 @@ void ata_lpm_schedule(struct ata_port *ap, enum link_pm 
policy)
ata_port_schedule_eh(ap);
 }
 
+#ifdef CONFIG_PM
 static void ata_lpm_enable(struct ata_host *host)
 {
struct ata_link *link;
@@ -789,6 +792,7 @@ static void ata_lpm_disable(struct ata_host *host)
ata_lpm_schedule(ap, ap->pm_policy);
}
 }
+#endif /* CONFIG_PM */
 
 
 /**
-- 
1.5.3.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/

[PATCH] hiddev: compat_ptr() returns a void *

2007-10-30 Thread Stephen Rothwell

so cast it to unsigned long before passing it to hiddev_ioctl.

This gets rid of:

drivers/hid/usbhid/hiddev.c: In function 'hiddev_compat_ioctl':
drivers/hid/usbhid/hiddev.c:746: warning: passing argument 4 of 'hiddev_ioctl' 
makes integer from pointer without a cast

Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
 drivers/hid/usbhid/hiddev.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]

diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
index 9837adc..5fc4019 100644
--- a/drivers/hid/usbhid/hiddev.c
+++ b/drivers/hid/usbhid/hiddev.c
@@ -743,7 +743,7 @@ inval:
 static long hiddev_compat_ioctl(struct file *file, unsigned int cmd, unsigned 
long arg)
 {
struct inode *inode = file->f_path.dentry->d_inode;
-   return hiddev_ioctl(inode, file, cmd, compat_ptr(arg));
+   return hiddev_ioctl(inode, file, cmd, (unsigned long)compat_ptr(arg));
 }
 #endif
 
-- 
1.5.3.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: pdflush stuck in D state with v2.6.24-rc1-192-gef49c32

2007-10-30 Thread Florin Iucha

On Tue, Oct 30, 2007 at 07:02:42PM -0500, Florin Iucha wrote:
> I have added the patches and started a linux kernel compilation, and
> something really interesting happens.  I run the build with the
> equivalent of "make -j3" and in a separate console I am watching the
> build with 'top'.  The build consumes 98% of both CPUs.  If I stop the
> output in the build console with "Ctrl-S", one core goes to idle,
> while the other is in 50% waiting, then goes to 75% waiting.  When I
> resume the build with "Ctrl-Q", the build starts to use both CPUs at
> 98-99%.  The NFS4 use was minimal, as I did not login with Gnome, but
> just logged on the console.  Also, the CPU that is in 75% waiting
> state changes occasionally.  'Top' shows pdflush in D state, using
> 5-6% of CPU.

I forgot the traces:

   http://iucha.net/2.6.24-rc1/fw.1.gz
   http://iucha.net/2.6.24-rc1/fw.2.gz
   http://iucha.net/2.6.24-rc1/fw.3.gz

florin

-- 
Bruce Schneier expects the Spanish Inquisition.
  http://geekz.co.uk/schneierfacts/fact/163


signature.asc
Description: Digital signature

Re: [PATCH] sysfs: add filter function to groups

2007-10-30 Thread Greg KH

On Tue, Oct 30, 2007 at 01:25:43PM -0500, James Bottomley wrote:
> On Mon, 2007-10-29 at 18:58 +0100, Stefan Richter wrote:
> > James Bottomley wrote:
> > >> >  struct attribute_group {
> > >> >const char  *name;
> > >> > +  int (*filter_show)(struct kobject *, int);
> > 
> > > Actually, it returns a true/false value indicating whether the given
> > > attribute should be displayed.
> > 
> > How about this:
> > 
> > int (*is_visible)(...);
> 
> OK, so is this latest revision acceptable to everyone?
> 
> James
> 
> Index: BUILD-2.6/fs/sysfs/group.c
> ===
> --- BUILD-2.6.orig/fs/sysfs/group.c   2007-10-28 17:27:04.0 -0500
> +++ BUILD-2.6/fs/sysfs/group.c2007-10-30 12:35:47.0 -0500
> @@ -16,25 +16,31 @@
>  #include "sysfs.h"
>  
>  
> -static void remove_files(struct sysfs_dirent *dir_sd,
> +static void remove_files(struct sysfs_dirent *dir_sd, struct kobject *kobj,
>const struct attribute_group *grp)
>  {
>   struct attribute *const* attr;
> + int i;
>  
> - for (attr = grp->attrs; *attr; attr++)
> - sysfs_hash_and_remove(dir_sd, (*attr)->name);
> + for (i = 0, attr = grp->attrs; *attr; i++, attr++)
> + if (grp->is_visible &&
> + grp->is_visible(kobj, *attr, i))
> + sysfs_hash_and_remove(dir_sd, (*attr)->name);

Hm, doesn't this break for the zillions of attribute groups that do not
have the is_visible function set?

> -static int create_files(struct sysfs_dirent *dir_sd,
> +static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj,
>   const struct attribute_group *grp)
>  {
>   struct attribute *const* attr;
> - int error = 0;
> + int error = 0, i;
>  
> - for (attr = grp->attrs; *attr && !error; attr++)
> - error = sysfs_add_file(dir_sd, *attr, SYSFS_KOBJ_ATTR);
> + for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++)
> + if (grp->is_visible &&
> + grp->is_visible(kobj, *attr, i))
> + error |=
> + sysfs_add_file(dir_sd, *attr, SYSFS_KOBJ_ATTR);

Same problem here, if grp->is_visible is not set, sysfs_add_file() would
never be called, right?

Other than the logic problem (I think), I have no issue with this idea
at all.  Care to redo this so it works?

thanks,

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

Re: Linux Security Module Framework (Was: LSM conversion to static interface)

2007-10-30 Thread Casey Schaufler

--- Peter Dolding <[EMAIL PROTECTED]> wrote:

> Lets end the bitrot.  Start having bits go into the main OS security
> features where they should be.

Gawd. Sorry, but we lost that argument in 1986 and the situation
hasn't changed a bit since. Most people just don't want what we're
selling. Do you know why Unix was a success and MULTICS* a failure?
It's because Unix had mode bits and MULTICS had ACLs. Fortunately
for those of us who wear titles like "Security Expert" or "Trust
Technologist" with pride there are enough clinical paranoids in
positions of authority to keep the Trusted System niche from closing
up completely and hence supporting our Rock Star Lifestyles. The
good news is that the situation is no worse than that faced by
the people who are bringing you Infiniband or Itanium, neither of
which will ever be the life of the party either. Sure security is
important, but I learned (in college, and yes they had colleges
way back then) not to drink too much at parties I'd crashed.

LSM isn't all I want it to be either, but it's better than I ever
got in the Proprietary OS world, and that includes when the MLS
systems were bringing in $20million a pop. Trying to force features
that virtually no one wants into any system is a bad idea. If
you haven't read Man of LaMancha I strongly suggest you do so.
Or at least see the play, it's got some catchy songs.

-
* If you don't know what MULTICS was you can buy me a beer and
  I'll tell you the whole story

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] Fix a spurious kfree_skb() call

2007-10-30 Thread David Miller

From: Michal Januszewski <[EMAIL PROTECTED]>
Date: Wed, 31 Oct 2007 00:10:52 +0100

> Remove a spurious call to kfree_skb() in the connector rx_skb handler.
> 
> This fixes a regression introduced by the '[NET]: make netlink user ->
> kernel interface synchronious' patch 
> (cd40b7d3983c708aabe3d3008ec64ffce56d33b0)
> 
> Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>

Applied, thanks!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: dev_ifname32() fails on 32->64bit calls in copy_in_user().

2007-10-30 Thread David Miller

From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Wed, 31 Oct 2007 13:35:24 +1100

> [PATCH] Fix new dev_ifname32 returning -EFAULT
> 
> A stray semicolon slipped in the patch that updated dev_ifname32 to
> not be inline, causing it to always return -EFAULT. This fixes it.
> 
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

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

Re: [PATCH RESEND] SCSI not showing tray status correctly

2007-10-30 Thread James Bottomley

On Sat, 2007-10-27 at 22:58 +, Maarten Bressers wrote:
> > This patch is too simplistic.  ide-cd.c:ide_cdrom_drive_status() looks
> > to be a reasonable implementation.  However, the worry is that
> > GET_EVENT_NOTIFICATION is a MMC command; devices not conforming to MMC
> > won't support it.  In theory, they should just return ILLEGAL_REQUEST,
> > but USB devices have been known to crash when given commands they don't
> > understand.  How widely tested has this been (if it's been in Gentoo
> > since 2004, then it's probably widely tested enough)?
> >
> > James
> >
> This patch hasn't been tested at all, I'm sorry if I gave you that
> impression, it isn't in Gentoo's patches, it's just been brought to our
> attention in the bug I linked too.
> 
> I created another patch, based on your recommendations, and with a lot of
> help from Daniel Drake ([EMAIL PROTECTED]), that's included below. Some
> changes are made to test_unit_ready() to be able to pass the sense data
> to sr_drive_status(). Currently, sr_do_ioctl() swallows this data and
> makes its own interpretations of sense codes, which isn't what we want
> here.
> 
> Is this what you had in mind? Do you think the possible problems with
> USB drives that you mentioned will prevent this patch from going in? 
> The patch has only been compile tested right now, we can do some real
> testing later, for now I'd just like to get your feedback on it.

In general it looks good ... I suppose the only way to test it is to
stick it in and see what happens.  However, there are a few rough edges.

> Maarten
> 
> ---
> 
> --- a/drivers/scsi/sr_ioctl.c 2007-10-26 22:40:41.0 +0200
> +++ b/drivers/scsi/sr_ioctl.c 2007-10-27 23:56:16.0 +0200
> @@ -275,16 +275,21 @@ int sr_do_ioctl(Scsi_CD *cd, struct pack
>  /* -- */
>  /* interface to cdrom.c   */
>  
> -static int test_unit_ready(Scsi_CD *cd)
> +static int test_unit_ready(Scsi_CD *cd, struct request_sense *sense)
>  {
> - struct packet_command cgc;
> + struct scsi_device *SDev = cd->device;
> + unsigned char cmd[CDROM_PACKET_SIZE] = { GPCMD_TEST_UNIT_READY };
> + int result;
>  
> - memset(&cgc, 0, sizeof(struct packet_command));
> - cgc.cmd[0] = GPCMD_TEST_UNIT_READY;
> - cgc.quiet = 1;
> - cgc.data_direction = DMA_NONE;
> - cgc.timeout = IOCTL_TIMEOUT;
> - return sr_do_ioctl(cd, &cgc);
> + if (!scsi_block_when_processing_errors(SDev))
> + return -ENODEV;
> +
> + memset(sense, 0, sizeof(*sense));
> + result = scsi_execute(SDev, cmd, DMA_NONE,
> +   NULL, 0, (char *)sense,
> +   IOCTL_TIMEOUT, IOCTL_RETRIES, 0);
> +
> + return driver_byte(result);

This bit isn't quite right ... this will return true if there's a
collected sense code and false otherwise (so it returns 0 on failure
that doesn't produce any sense information).

>  }
>  
>  int sr_tray_move(struct cdrom_device_info *cdi, int pos)
> @@ -310,14 +315,41 @@ int sr_lock_door(struct cdrom_device_inf
>  
>  int sr_drive_status(struct cdrom_device_info *cdi, int slot)
>  {
> + struct request_sense sense;
> + struct media_event_desc med;
> +
>   if (CDSL_CURRENT != slot) {
>   /* we have no changer support */
>   return -EINVAL;
>   }
> - if (0 == test_unit_ready(cdi->handle))
> + if ((0 == test_unit_ready(cdi->handle, &sense)) || 
> + sense.sense_key == UNIT_ATTENTION)

Unit attention won't necessarily mean the media is OK ... unit attention
can mean the media or tray status has changed.

>   return CDS_DISC_OK;
>  
> - return CDS_TRAY_OPEN;
> + if (!cdrom_get_media_event(cdi, &med)) {
> + if (med.media_present)
> + return CDS_DISC_OK;
> + else if (med.door_open)
> + return CDS_TRAY_OPEN;
> + else
> + return CDS_NO_DISC;
> + }
> +
> + if (sense.sense_key == NOT_READY && sense.asc == 0x04 && sense.ascq == 
> 0x04)

Actually, all asc 0x4 codes are some type of in progress operation,
format doesn't necessarily have to be treated specially.

> + return CDS_DISC_OK;
> +
> + /*
> +  * If not using Mt Fuji extended media tray reports,
> +  * just return TRAY_OPEN since ATAPI doesn't provide
> +  * any other way to detect this...
> +  */
> + if (sense.sense_key == NOT_READY) {
> + if (sense.asc == 0x3a && sense.ascq == 1)
> + return CDS_NO_DISC;
> + else
> + return CDS_TRAY_OPEN;

This is also a bit odd.  asc 0x3a ascq 0x2 definitely means tray open,
but there are a lot of other not ready conditions that don't mean this.

> + }
> + return CDS_DRIVE_NOT_READY;
>  }
>  
>  int sr_disk_status(struct cdrom_device_info *cdi)

James


-
To unsubscri

Re: 2.6.23 performance regression

2007-10-30 Thread Nick Piggin

On Tuesday 30 October 2007 18:54, Lorenzo Allegrucci wrote:
> Hi, sorry if this is a faq but reading
> http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf (slides 17,
> 18)
> looks like 2.6.23 is having a performance regression on MySQL and
> PostgreSQL benchmarks.  Has anyone investigated these?

I think Ingo was looking into them. I'm just in the middle of
building a new setup to investigate some performance issues too,
so I hope to look at this.

Apparently it did go unnoticed during CFS testing, unfortunately.
Although now it has been brought to light, I think 2.6.24 is
supposed to be better (although it now gets worse on other things).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: dev_ifname32() fails on 32->64bit calls in copy_in_user().

2007-10-30 Thread Benjamin Herrenschmidt

Bug is in the new dev_ifname32:

uifr = compat_alloc_user_space(sizeof(struct ifreq));
if (copy_in_user(uifr, compat_ptr(arg), sizeof(struct ifreq32)));
return -EFAULT;

There's a stray ";" after the if statement, that was obviously not
tested :-)

This fixes it here (tested):

[PATCH] Fix new dev_ifname32 returning -EFAULT

A stray semicolon slipped in the patch that updated dev_ifname32 to
not be inline, causing it to always return -EFAULT. This fixes it.

Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---

Index: linux-work/fs/compat_ioctl.c
===
--- linux-work.orig/fs/compat_ioctl.c   2007-10-31 13:30:42.0 +1100
+++ linux-work/fs/compat_ioctl.c2007-10-31 13:30:46.0 +1100
@@ -322,7 +322,7 @@ static int dev_ifname32(unsigned int fd,
int err;
 
uifr = compat_alloc_user_space(sizeof(struct ifreq));
-   if (copy_in_user(uifr, compat_ptr(arg), sizeof(struct ifreq32)));
+   if (copy_in_user(uifr, compat_ptr(arg), sizeof(struct ifreq32)))
return -EFAULT;
 
err = sys_ioctl(fd, SIOCGIFNAME, (unsigned long)uifr);


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] acpi: 'acpi_gbl_system_awake_and_running' is no longer used, only assigned.

2007-10-30 Thread Len Brown

Bob reports that this is used in a pending version of ACPICA,
so we'll leave the code alone.

thanks,
-Len

On Tuesday 30 October 2007 06:54, Richard Knutsson wrote:
> 'acpi_gbl_system_awake_and_running' is no longer used, only assigned.
> 
> Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
> ---
> Diffed against linus-git
> Checked with script/checkpatch.pl
> 
>  drivers/acpi/hardware/hwsleep.c   |5 -
>  drivers/acpi/utilities/utglobal.c |1 -
>  include/acpi/acglobal.h   |1 -
>  3 files changed, 7 deletions(-)
> 
> 
> diff --git a/drivers/acpi/hardware/hwsleep.c b/drivers/acpi/hardware/hwsleep.c
> index 81b2484..e020e50 100644
> --- a/drivers/acpi/hardware/hwsleep.c
> +++ b/drivers/acpi/hardware/hwsleep.c
> @@ -300,8 +300,6 @@ acpi_status asmlinkage acpi_enter_sleep_state(u8 
> sleep_state)
>   return_ACPI_STATUS(status);
>   }
>  
> - acpi_gbl_system_awake_and_running = FALSE;
> -
>   status = acpi_hw_enable_all_wakeup_gpes();
>   if (ACPI_FAILURE(status)) {
>   return_ACPI_STATUS(status);
> @@ -446,7 +444,6 @@ acpi_status asmlinkage acpi_enter_sleep_state_s4bios(void)
>   if (ACPI_FAILURE(status)) {
>   return_ACPI_STATUS(status);
>   }
> - acpi_gbl_system_awake_and_running = FALSE;
>  
>   status = acpi_hw_enable_all_wakeup_gpes();
>   if (ACPI_FAILURE(status)) {
> @@ -587,8 +584,6 @@ acpi_status acpi_leave_sleep_state(u8 sleep_state)
>   }
>   /* TBD: _WAK "sometimes" returns stuff - do we want to look at it? */
>  
> - acpi_gbl_system_awake_and_running = TRUE;
> -
>   /* Enable power button */
>  
>   (void)
> diff --git a/drivers/acpi/utilities/utglobal.c 
> b/drivers/acpi/utilities/utglobal.c
> index 93ea829..f2ba315 100644
> --- a/drivers/acpi/utilities/utglobal.c
> +++ b/drivers/acpi/utilities/utglobal.c
> @@ -709,7 +709,6 @@ void acpi_ut_init_globals(void)
>   /* Hardware oriented */
>  
>   acpi_gbl_events_initialized = FALSE;
> - acpi_gbl_system_awake_and_running = TRUE;
>  
>   /* Namespace */
>  
> diff --git a/include/acpi/acglobal.h b/include/acpi/acglobal.h
> index 347a911..ae0fc0a 100644
> --- a/include/acpi/acglobal.h
> +++ b/include/acpi/acglobal.h
> @@ -236,7 +236,6 @@ ACPI_EXTERN u8 acpi_gbl_step_to_next_call;
>  ACPI_EXTERN u8 acpi_gbl_acpi_hardware_present;
>  ACPI_EXTERN u8 acpi_gbl_global_lock_present;
>  ACPI_EXTERN u8 acpi_gbl_events_initialized;
> -ACPI_EXTERN u8 acpi_gbl_system_awake_and_running;
>  
>  extern u8 acpi_gbl_shutdown;
>  extern u32 acpi_gbl_startup_flags;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 08/10] SLUB: Optional fast path using cmpxchg_local

2007-10-30 Thread Mathieu Desnoyers

* Christoph Lameter ([EMAIL PROTECTED]) wrote:
> Provide an alternate implementation of the SLUB fast paths for alloc
> and free using cmpxchg_local. The cmpxchg_local fast path is selected
> for arches that have CONFIG_FAST_CMPXCHG_LOCAL set. An arch should only
> set CONFIG_FAST_CMPXCHG_LOCAL if the cmpxchg_local is faster than an
> interrupt enable/disable sequence. This is known to be true for both
> x86 platforms so set FAST_CMPXCHG_LOCAL for both arches.
> 
> Not all arches can support fast cmpxchg operations. Typically the
> architecture must have an optimized cmpxchg instruction. The
> cmpxchg fast path makes no sense on platforms whose cmpxchg is
> slower than interrupt enable/disable (like f.e. IA64).
> 
> The advantages of a cmpxchg_local based fast path are:
> 
> 1. Lower cycle count (30%-60% faster)
> 
> 2. There is no need to disable and enable interrupts on the fast path.
>Currently interrupts have to be disabled and enabled on every
>slab operation. This is likely saving a significant percentage
>of interrupt off / on sequences in the kernel.
> 
> 3. The disposal of freed slabs can occur with interrupts enabled.
> 

It would require some testing, but I suspect that powerpc, mips and m32r
are three other architectures that could benefit from this (from the top
of my head)

Mathieu

> The alternate path is realized using #ifdef's. Several attempts to do the
> same with macros and in line functions resulted in a mess (in particular due
> to the strange way that local_interrupt_save() handles its argument and due
> to the need to define macros/functions that sometimes disable interrupts
> and sometimes do something else. The macro based approaches made it also
> difficult to preserve the optimizations for the non cmpxchg paths).
> 
> #ifdef seems to be the way to go here to have a readable source.
> 
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
> 
> ---
>  arch/x86/Kconfig.i386   |4 ++
>  arch/x86/Kconfig.x86_64 |4 ++
>  mm/slub.c   |   71 
> ++--
>  3 files changed, 77 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6/mm/slub.c
> ===
> --- linux-2.6.orig/mm/slub.c  2007-10-27 10:39:07.583665939 -0700
> +++ linux-2.6/mm/slub.c   2007-10-27 10:40:19.710415861 -0700
> @@ -1496,7 +1496,12 @@ static void *__slab_alloc(struct kmem_ca
>  {
>   void **object;
>   struct page *new;
> +#ifdef CONFIG_FAST_CMPXCHG_LOCAL
> + unsigned long flags;
>  
> + local_irq_save(flags);
> + preempt_enable_no_resched();
> +#endif
>   if (!c->page)
>   goto new_slab;
>  
> @@ -1518,6 +1523,10 @@ load_freelist:
>  unlock_out:
>   slab_unlock(c->page);
>  out:
> +#ifdef CONFIG_FAST_CMPXCHG_LOCAL
> + preempt_disable();
> + local_irq_restore(flags);
> +#endif
>   return object;
>  
>  another_slab:
> @@ -1592,9 +1601,26 @@ static void __always_inline *slab_alloc(
>   gfp_t gfpflags, int node, void *addr)
>  {
>   void **object;
> - unsigned long flags;
>   struct kmem_cache_cpu *c;
>  
> +#ifdef CONFIG_FAST_CMPXCHG_LOCAL
> + c = get_cpu_slab(s, get_cpu());
> + do {
> + object = c->freelist;
> + if (unlikely(is_end(object) || !node_match(c, node))) {
> + object = __slab_alloc(s, gfpflags, node, addr, c);
> + if (unlikely(!object)) {
> + put_cpu();
> + goto out;
> + }
> + break;
> + }
> + } while (cmpxchg_local(&c->freelist, object, object[c->offset])
> + != object);
> + put_cpu();
> +#else
> + unsigned long flags;
> +
>   local_irq_save(flags);
>   c = get_cpu_slab(s, smp_processor_id());
>   if (unlikely((is_end(c->freelist)) || !node_match(c, node))) {
> @@ -1609,6 +1635,7 @@ static void __always_inline *slab_alloc(
>   c->freelist = object[c->offset];
>   }
>   local_irq_restore(flags);
> +#endif
>  
>   if (unlikely((gfpflags & __GFP_ZERO)))
>   memset(object, 0, c->objsize);
> @@ -1644,6 +1671,11 @@ static void __slab_free(struct kmem_cach
>   void *prior;
>   void **object = (void *)x;
>  
> +#ifdef CONFIG_FAST_CMPXCHG_LOCAL
> + unsigned long flags;
> +
> + local_irq_save(flags);
> +#endif
>   slab_lock(page);
>  
>   if (unlikely(SlabDebug(page)))
> @@ -1669,6 +1701,9 @@ checks_ok:
>  
>  out_unlock:
>   slab_unlock(page);
> +#ifdef CONFIG_FAST_CMPXCHG_LOCAL
> + local_irq_restore(flags);
> +#endif
>   return;
>  
>  slab_empty:
> @@ -1679,6 +1714,9 @@ slab_empty:
>   remove_partial(s, page);
>  
>   slab_unlock(page);
> +#ifdef CONFIG_FAST_CMPXCHG_LOCAL
> + local_irq_restore(flags);
> +#endif
>   discard_slab(s, page);
>   return;
>

Re: [patch 09/10] SLUB: Do our own locking via slab_lock and slab_unlock.

2007-10-30 Thread Nick Piggin

On Wednesday 31 October 2007 05:32, Christoph Lameter wrote:
> On Tue, 30 Oct 2007, Nick Piggin wrote:
> > Is this actually a speedup on any architecture to roll your own locking
> > rather than using bit spinlock?
>
> It avoids one load from memory when allocating and the release is simply
> writing the page->flags back. Less instructions.

OK, but it probably isn't a measurable speedup, even on microbenchmarks,
right? And many architectures have to have more barriers around cmpxchg
than they do around a test_and_set_bit_lock, so it may even be slower
on some.

> > I am not exactly convinced that smp_wmb() is a good idea to have in your
> > unlock, rather than the normally required smp_mb() that every other open
> > coded lock in the kernel is using today. If you comment every code path
> > where a load leaking out of the critical section would not be a problem,
> > then OK it may be correct, but I still don't think it is worth the
> > maintenance overhead.
>
> I thought you agreed that release semantics only require a write barrier?

Not in general.

> The issue here is that other processors see the updates before the
> updates to page-flags.
>
> A load leaking out of a critical section would require that the result of
> the load is not used to update other information before the slab_unlock
> and that the source of the load is not overwritten in the critical
> section. That does not happen in sluib.

That may be the case, but I don't think there is enough performance
justification to add a hack like this. ia64 for example is going to
do an mf for smp_wmb so I doubt it is a clear win.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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]bluetooth: hci_sysfs connection bus_id add support for diffrent hci device

2007-10-30 Thread Dave Young

For multi hci devices host, connection from/to same destination
bluetooth device, add_conn will failed due to sysfs duplicate name.

sysfs: duplicate filename 'acl0018C5B6B456' can not be created
WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
 [] sysfs_add_one+0xa0/0xe0
 [] sysfs_create_link+0x9b/0x140
 [] create_files+0x31/0x60
 [] bus_add_device+0x5b/0xf0
 [] device_add+0x11c/0x350
 [] add_conn+0x0/0x90 [bluetooth]
 [] add_conn+0xf/0x90 [bluetooth]
 [] run_workqueue+0x5e/0x110
 [] worker_thread+0xac/0x100
 [] autoremove_wake_function+0x0/0x50
 [] autoremove_wake_function+0x0/0x50
 [] worker_thread+0x0/0x100
 [] kthread+0x59/0xa0
 [] kthread+0x0/0xa0
 [] kernel_thread_helper+0x7/0x14
 ===
add_conn: Failed to register connection device

Add prefix hdev->name to bus_id to fix this problem.

Signed-off-by: Dave Young <[EMAIL PROTECTED]> 

---
net/bluetooth/hci_sysfs.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff -upr linux/net/bluetooth/hci_sysfs.c linux.new/net/bluetooth/hci_sysfs.c
--- linux/net/bluetooth/hci_sysfs.c 2007-10-31 10:21:00.0 +0800
+++ linux.new/net/bluetooth/hci_sysfs.c 2007-10-31 10:21:55.0 +0800
@@ -302,7 +302,8 @@ void hci_conn_add_sysfs(struct hci_conn 
conn->dev.release = bt_release;
 
snprintf(conn->dev.bus_id, BUS_ID_SIZE,
-   "%s%2.2X%2.2X%2.2X%2.2X%2.2X%2.2X",
+   "%s%s%2.2X%2.2X%2.2X%2.2X%2.2X%2.2X",
+   hdev->name,
conn->type == ACL_LINK ? "acl" : "sco",
ba->b[5], ba->b[4], ba->b[3],
ba->b[2], ba->b[1], ba->b[0]);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Security Module Framework (Was: LSM conversion to static interface)

2007-10-30 Thread Peter Dolding

On 10/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Wed, 31 Oct 2007, Peter Dolding wrote:
>
> > MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are
> > applied over using Selinux rules.  This is just the way it is stacking LSM's
> > is Just not healthy you always risk on LSM breaking another.  Part of the
> > reason why I have suggested a complete redesign of LSM.  To get away from
> > this problem of stacking.
>
> since the method of stacking hasn't been determined yet, you can't say
> this.

I can because that is the current day problem. With many LSM's loaded
they stack completely as a complete mess and with problems.  They
fight with each other.  Lack of define on stacking equals big
problems.   Since you have not created a standard for stacking does
not stop the problem from existing.  Nice lack of planing when LSM
started or maybe its intentional.  When you need stacking its about
time you start moving things into the OS?

There is a way around the problem too without allowing LSM to stack.
Good advantage backward compatible  because your are not playing with
the LSM standard to do it so no LSM modules should need large
alterations.  At worse mirror extensions to handle the new OS feature.
 Posix File Capabilities provide the solution.   First done as a LSM
risked conflict.   Moved in as a operating system extension by by
conflict.  Fragments from LSM's should exactly move that way if they
expect to be overlapped by other models.

Lot of stacking problems can be avoided if segments are complete
standard extensions.
>
> it would be possible for MultiAdmin to grant additional access, that
> SELinux then denies for it's own reasons.
>
> if the SELinux policy is written so that it ignores capabilities, and
> instead just looks at uid0 then that policy is broken in a stacked
> environment, but it's the polciy that's broken, not the stacking.

That is not how current day always works.  MultiAdmin grants and that
can be the end of the treeing.   Selinux does not get asked if it
refuses it or not.  So no matter what was set in the Selinux policy it
may never get used.   Adding more layers is also bad for performance
to.  Treeing threw modules for rights is a really slow process.  As
like a posix feature extension.   Selinux/Other LSM's is at top of
allocation no flaw no bypass.

> yes, there will be interactions that don't make sense, but just becouse
> something can be used wrong doesn't mean that there aren't other cases
> where it can be used properly.
>
We are talking security here if its not order safe its not good.
MultiAdmin done as a posix feature extension is order safe.
MultiAdmin done as a LSM is not order safe.

System Admins are humans too.  Getting orders backwards does happen.
So should be avoided where able.

This completely avoids the need for adding another layer of stacking
and since built inside current day framework.  Does doing this risk
the end of LSM's as we know it yes it does.  Since it is not being
used as LSM were intended.  LSM is just a addon to standard OS
security what is either a testing ground for new features to secure
the OS that get build into the OS in time or as location for security
modules.

Somethings should be just done in the Standard OS security nothing to
do with LSM.

Little bit hard for some I guess to hear that LSM are not all
important and not all Security features should be done in them.  Some
should be done in the main OS security features.

Biggest current day problem with LSM is they have forgot that LSM is
only a testing ground or a zone for features that people will only
want some of the time.

MultiAdmin is a feature that can enhance means to Audit OS ie who did
what.  Enhance security hand outs and can be really handy with almost
any LSM on the system.  Its description of what it is sounds very much
like every other standard feature.

Lets end the bitrot.  Start having bits go into the main OS security
features where they should be.

Peter Dolding
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [dm-devel] Re: dm: bounce_pfn limit added

2007-10-30 Thread Alasdair G Kergon

On Wed, Oct 31, 2007 at 02:01:33AM +, Alasdair G Kergon wrote:
> What if you swap in alternative dm targets, e.g. if it's linear,
> try multipath (round-robin, one path)?
  
And try using md instead of dm - does that also show the problem?
(md takes a similar stance to dm on this I believe.)

Alasdair
-- 
[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: fix marker warnings

2007-10-30 Thread Mathieu Desnoyers

* Dave Hansen ([EMAIL PROTECTED]) wrote:
> I'm seeing these in the latest git:
> 
> kernel/marker.c: In function `marker_probe_unregister':
> kernel/marker.c:355: warning: `probe_module' might be used uninitialized in 
> this function
> kernel/marker.c: In function `marker_probe_unregister_private_data':
> kernel/marker.c:389: warning: `probe_module' might be used uninitialized in 
> this function
> kernel/marker.c:392: warning: `entry' might be used uninitialized in this 
> function
> 
> It's due to gcc not detecting that the need_update condition is actually
> constant, and will never call marker_update_probes() on an uninitialized
> probe_module.
> 
> However, that need_update bit is all due to dropping the mutex before
> calling marker_update_probes().  As far as I can tell, every call to
> marker_update_probes() has this lock dropping behavior just before
> calling it.  So, let's just hold the locks over the
> marker_update_probes() and document that it needs to have a lock taken
> instead.  
> 
> This removes code overall.  Untested except for a quick compile.
> Consider it just a style suggestion. :)
> 

Ok, just ran it and it seems good. It did not appear as trivial during
development because locking was is a different order until recently.

I wonder what gcc version you are using though, because mine does not
warn about anything. I wonder if it is really necessary to "fix" false
gcc warnings like this. Let's take it as a cleanup.

Acked-by: Mathieu Desnoyers <[EMAIL PROTECTED]>

> marker_probe_unregister_private_data() also has a bit of a goto mess
> that produces similar warnings.  I'll look at it next.
> 
> ---
> 
>  linux-2.6.git-dave/kernel/marker.c |   34 +++---
>  1 file changed, 11 insertions(+), 23 deletions(-)
> 
> diff -puN kernel/marker.c~fix-marker-warnings kernel/marker.c
> --- linux-2.6.git/kernel/marker.c~fix-marker-warnings 2007-10-30 
> 12:54:36.0 -0700
> +++ linux-2.6.git-dave/kernel/marker.c2007-10-30 13:03:39.0 
> -0700
> @@ -288,12 +288,13 @@ void marker_update_probe_range(struct ma
>   * Issues a synchronize_sched() when no reference to the module passed
>   * as parameter is found in the probes so the probe module can be
>   * safely unloaded from now on.
> + *
> + * must hold markers_mutex
>   */
> -static void marker_update_probes(struct module *probe_module)
> +static void __marker_update_probes(struct module *probe_module)
>  {
>   int refcount = 0;
>  
> - mutex_lock(&markers_mutex);
>   /* Core kernel markers */
>   marker_update_probe_range(__start___markers,
>   __stop___markers, probe_module, &refcount);
> @@ -303,7 +304,6 @@ static void marker_update_probes(struct 
>   synchronize_sched();
>   deferred_sync = 0;
>   }
> - mutex_unlock(&markers_mutex);
>  }
>  
>  /**
> @@ -320,7 +320,7 @@ int marker_probe_register(const char *na
>   marker_probe_func *probe, void *private)
>  {
>   struct marker_entry *entry;
> - int ret = 0, need_update = 0;
> + int ret = 0;
>  
>   mutex_lock(&markers_mutex);
>   entry = get_marker(name);
> @@ -335,11 +335,9 @@ int marker_probe_register(const char *na
>   ret = add_marker(name, format, probe, private);
>   if (ret)
>   goto end;
> - need_update = 1;
> + __marker_update_probes(NULL);
>  end:
>   mutex_unlock(&markers_mutex);
> - if (need_update)
> - marker_update_probes(NULL);
>   return ret;
>  }
>  EXPORT_SYMBOL_GPL(marker_probe_register);
> @@ -355,7 +353,6 @@ void *marker_probe_unregister(const char
>   struct module *probe_module;
>   struct marker_entry *entry;
>   void *private;
> - int need_update = 0;
>  
>   mutex_lock(&markers_mutex);
>   entry = get_marker(name);
> @@ -368,11 +365,9 @@ void *marker_probe_unregister(const char
>   probe_module = __module_text_address((unsigned long)entry->probe);
>   private = remove_marker(name);
>   deferred_sync = 1;
> - need_update = 1;
> + __marker_update_probes(probe_module);
>  end:
>   mutex_unlock(&markers_mutex);
> - if (need_update)
> - marker_update_probes(probe_module);
>   return private;
>  }
>  EXPORT_SYMBOL_GPL(marker_probe_unregister);
> @@ -392,7 +387,6 @@ void *marker_probe_unregister_private_da
>   struct marker_entry *entry;
>   int found = 0;
>   unsigned int i;
> - int need_update = 0;
>  
>   mutex_lock(&markers_mutex);
>   for (i = 0; i < MARKER_TABLE_SIZE; i++) {
> @@ -414,11 +408,9 @@ iter_end:
>   probe_module = __module_text_address((unsigned long)entry->probe);
>   private = remove_marker(entry->name);
>   deferred_sync = 1;
> - need_update = 1;
> + __marker_update_probes(probe_module);
>  end:
>   mutex_unlock(&markers_mutex);
> - if (need_update)
> - marker_update_probes(probe_module);
>   return private;
>  }
>

Re: [dm-devel] Re: dm: bounce_pfn limit added

2007-10-30 Thread Alasdair G Kergon

On Tue, Oct 30, 2007 at 11:26:17PM +, Alasdair G Kergon wrote:
> ) DM doesn't need to bounce bio's on its own, but the block layer defaults
> ) to that in blk_queue_make_request(). The lower level drivers should
> ) bounce ios themselves, that is what they need to do if not layered below
> ) dm anyways.

So currently we treat bounce_pfn as a property that does not need to be
propagated through the stack.

But is that the right approach?
- Is there a blk_queue_bounce() missing either from dm or elsewhere?
  (And BTW can the bio_alloc() that lurks within lead to deadlock?)

Firstly, what's going wrong?
- What is the dm table you are using?  (output of 'dmsetup table')
  - Which dm targets and with how many underlying devices?
- Which underlying driver?
- Is this direct I/O to the block device from userspace, or via some
filesystem or what?

Presumably you've shown the problem goes away when the dm device is
removed from the stack.
What if you swap in alternative dm targets, e.g. if it's linear,
try multipath (round-robin, one path)?
 
Alasdair
-- 
[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] sysfs: add filter function to groups

2007-10-30 Thread Kay Sievers

On Oct 31, 2007 1:40 AM, Mark M. Hoffman <[EMAIL PROTECTED]> wrote:
> * James Bottomley <[EMAIL PROTECTED]> [2007-10-30 13:25:43 -0500]:
> > On Mon, 2007-10-29 at 18:58 +0100, Stefan Richter wrote:
> > > James Bottomley wrote:
> > > >> >  struct attribute_group {
> > > >> >const char  *name;
> > > >> > +  int (*filter_show)(struct kobject *, int);
> > >
> > > > Actually, it returns a true/false value indicating whether the given
> > > > attribute should be displayed.
> > >
> > > How about this:
> > >
> > > int (*is_visible)(...);
> >
> > OK, so is this latest revision acceptable to everyone?
>
> I've just been hacking around in this area a bit, for a completely different
> reason: there are literally 1000's of attributes in drivers/hwmon/*.c that
> really want to be const, but which cannot be due to the current API.  I was
> about to propose some patches that move in a different direction...

That isn't related to "dynamic attributes", right?

> IMHO the fundamental problem is struct attribute_group itself.  This structure
> is nothing but a convenience for packaging the arguments to sysfs_create_group
> and sysfs_remove_group.

That "problem" is actually a good thing. If you look at the change
rate of the internal kernel API, it saves us so much trouble. Like in
this case, James can just add a callback without caring about any
(almost :)) of the current users.

> Those functions should take the contents of that
> struct as direct arguments.

I think we should move in the opposite direction. You are right, it
isn't neccessarily pretty, but having encapsulations like this saves
us a lot of trouble while interacting with so many other people and
extending API's all the time. It's a trade, and it's a good one, if
you need to maintain code that has so many callers, and  so many
architectures, you can't even check that you don't break them.

> I haven't finished the patch series to implement
> this, but since I noticed your patch I thought I'd better speak up now.  
> Here's
> the first... the idea is to eventually deprecate sysfs_[create|remove]_group()
> altogether.

Again, I don't think, that we want to get rid of the struct container
housing all the parameters and beeing open for future extensions
without changing all the callers.

> The current declaration of struct attribute_group prevents long lists of
> attributes from being marked const.  Ideally, the second argument to the
> sysfs_create_group() and sysfs_remove_group() functions would be marked 
> "deep"
> const, but C has no such construct.  This patch provides a parallel set of
> functions with the desired decoration.

What do we get out of this constification compared to the current code?

Thanks,
Kay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] local_t Documentation update 2

2007-10-30 Thread Mathieu Desnoyers

local_t Documentation update 2

(this patch seems to have fallen off the grid, but is still providing
useful information. It applies to 2.6.23-mm1.)

Grant Grundler was asking for more detail about correct usage of local atomic
operations and suggested adding the resulting summary to local_ops.txt.

"Please add a bit more detail. If DaveM is correct (he normally is), then
there must be limits on how the local_t can be used in the kernel process
and interrupt contexts. I'd like those rules spelled out very clearly
since it's easy to get wrong and tracking down such a bug is quite painful."

Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Signed-off-by: Grant Grundler <[EMAIL PROTECTED]>
---
 Documentation/local_ops.txt |   23 +++
 1 file changed, 23 insertions(+)

Index: linux-2.6-lttng/Documentation/local_ops.txt
===
--- linux-2.6-lttng.orig/Documentation/local_ops.txt2007-09-04 
11:53:23.0 -0400
+++ linux-2.6-lttng/Documentation/local_ops.txt 2007-09-04 12:19:31.0 
-0400
@@ -68,6 +68,29 @@ typedef struct { atomic_long_t a; } loca
   variable can be read when reading some _other_ cpu's variables.
 
 
+* Rules to follow when using local atomic operations
+
+- Variables touched by local ops must be per cpu variables.
+- _Only_ the CPU owner of these variables must write to them.
+- This CPU can use local ops from any context (process, irq, softirq, nmi, ...)
+  to update its local_t variables.
+- Preemption (or interrupts) must be disabled when using local ops in
+  process context to   make sure the process won't be migrated to a
+  different CPU between getting the per-cpu variable and doing the
+  actual local op.
+- When using local ops in interrupt context, no special care must be
+  taken on a mainline kernel, since they will run on the local CPU with
+  preemption already disabled. I suggest, however, to explicitly
+  disable preemption anyway to make sure it will still work correctly on
+  -rt kernels.
+- Reading the local cpu variable will provide the current copy of the
+  variable.
+- Reads of these variables can be done from any CPU, because updates to
+  "long", aligned, variables are always atomic. Since no memory
+  synchronization is done by the writer CPU, an outdated copy of the
+  variable can be read when reading some _other_ cpu's variables.
+
+
 * How to use local atomic operations
 
 #include 
-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Xen-devel] [patch 30/44] xen: Add support for preemption

2007-10-30 Thread Jeremy Fitzhardinge

tgh wrote:
> Thank for your reply
> and I still have several questions
>   
>> Yes, that's the normal mode of operation. The hypervisor will timeslice
>> multiple vcpus onto a single vcpu.
>>   
>> 
> that is ,the VM could be preempted by xen,and could xen hypervisor also
> be preempted to reschedule other vm or xen kernel thread?and are there
> the counterpart abstractions in xen for kernel thread in linux?
>   

Yes, a vcpu in Xen is the same as a task in the kernel. In the same way
the kernel multiplexes multiple tasks onto your cpu(s), Xen multiplexes
multiple vcpus onto your cpu(s). This isn't directly visible to the
guest kernel, in the same way that user processes can't generally
observe timeslicing.

>> This patch doesn't relate to that; it's whether a Xen Linux guest's
>> kernel can be preempted to reschedule processes while running under Xen.
>>   
>> 
> that is ,the patch makes the guest's kernel, rather than xen, be able to
> be preempted ,is it right?
>   

Yes. Previous to that change, kernel preemption was disabled when
compiling Xen support in.

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

Re: Multiple MSI messages support

2007-10-30 Thread Shawn Jin

On Oct 30, 2007 2:51 PM, Roland Dreier <[EMAIL PROTECTED]> wrote:
>
>  > > I understand that the current PCI subsystem or linux kernel (x86)
>  > > supports only one message when MSI is enabled even for devices having
>  > > multiple MSI messages. But why? Is this a limitation solely due to the
>  > > OS or due to the x86 APIC?
>  > > I know the current linux kernel (2.6.23) changed MSI message data
>  > > format a little bit to support other architectures. But some older
>  > > version (e.g. 2.6.18) defined a specific format for the MSI msg data
>  > > in a way that 8 bits contain the irq number and the other 8 bits have
>  > > the interrupt attributes, which is x86 specific. Why does the msg data
>  > > need to contain the irq number? Here is my hypothetic explanation. The
>  > > device writes the MSI msg data to the specified MSI msg address. And
>  > > APIC uses the irq number in the msg data to generate appropriate
>  > > interrupt, which of course results in an appropriate ISR invoked. A
>  > > device having multiple MSI messages typically appends some information
>  > > of which MSI message to the msg data field. For example, if the system
>  > > (or OS) configures the MSI msg data as 0x5000, a device having 4 MSI
>  > > messages could write 0x5000, 0x5001, 0x5002, 0x5003 to differentiate
>  > > the MSI messages. However this cannot work with the APIC due to the
>  > > way how APIC asserts interrupts as I described above (if my
>  > > understanding is correct).
>  > > Hence my answer to the question is this is due to the x86 APIC. For
>  > > other architectures such as powerpc this is probably not a problem
>  > > since the interrupt controller is different. Am I correct?
>
>  > IMO it's more like there has never been enough need for anybody to
>  > look into it, I bet...
>
> Actually the original poster's explanation is pretty accurate.  MSI
> imposes a restriction on how a device generates multiple messages,
> since there is only one message data register and the rest of the
> messages must be based on that in a simple way.  And the format of
> "Intel-style" APIC MSI messages does not match up with the way the PCI
> spec generates multiple messages.
>
> In fact at least IBM pSeries boxes seem to be able to use MSI to
> generate multiple interrupts from the same device -- BenH can probably
> give details.
>
> Multiple interrupt messages are supported by Linux via MSI-X (which
> allows each message to have completely different data).

Thanks for confirming this. I found that Windows also allocates only
one MSI message for such device, though I know nobody here is
interested in Windows. :-P This also confirms from another perspective
that supporting only one MSI message is actually due to the APIC
limitation.

>  > The way drivers are written, you are typically must touch a few key
>  > hardware registers _anyway_, so the multiple messages in practice are
>  > not much more useful than the simple fact that your MSI irq handler
>  > function was called (with all that indicates and implies).
>
> For high-performance devices this is not really true.  The InfiniBand
> mthca driver can use MSI to get a single interrupt, or MSI-X to get
> different interrupts for different types of events.  MSI-X allows the
> read of the "interrupt cause register" to be avoided, and this ends up
> making a measurable performance difference for the fast path.

I agree. Accessing HW registers across PCIe is not quite desirable
since it takes relatively long time especially for reads. In some
situation, if multiple MSI messages were supported, even a single
interrupt would handle multiple events and avoid reading some HW
status register to determine the type of event since the message data
has such information. Hence the performance should be improved quite a
bit.

-Shawn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: pci-disable-decode-of-io-memory-during-bar-sizing.patch

2007-10-30 Thread Jesse Barnes

On Tuesday, October 30, 2007 4:59 pm Linus Torvalds wrote:
> Also, there are several devices that don't show up in the MMCFG
> things, or just otherwise get it wrong.
>
> So just take a look at arch/x86/pci/mmconfig-shared.c and look for
> "conf1".
>
> Really. Damn, I'm nervous taking any MMCFG patches that has you as an
> author, if you aren't even aware of these kinds of fundamnetal
> issues. You probably read the standards about how things are
> "supposed" to work, and then just believed them?

We have a few bits of code in there to look at the actual MMCONFIG base 
register, which is good since we can sanity check it against the 
firmware.  However, by itself it's not enough since we may end up using 
it even though the BIOS didn't tell us about an overlap that really 
does exist.  Robert recognized this and added checks to make sure the 
values read from the base regs actually matched what the firmware was 
telling us in the ACPI tables (at least iirc, it's been awhile since I 
looked at the patch).

So don't be too nervous. :)

Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 asm-compat.h to x86

2007-10-30 Thread Glauber de Oliveira Costa

On 10/30/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Mathieu Desnoyers wrote:
> > Add asm-compat.h to x86
> >
> > In assembly code and in gcc inline assembly, we need .long to express a "c 
> > long"
> > type on i386 and a .quad to express the same on x86_64. Use macros similar 
> > to
> > powerpc "PPC_LONG" to express those. Name chosen: ASM_LONG. (didn't feel 
> > like
> > X86_LONG was required).
> >
> > This is useful in inline assembly within code shared between 32 and 64
> > bits architectures in x86.
> >
> > More compatible assembly macros could be added in this header later when
> > needed.
> >
> > I had to create this to implement a merged optimized immediate values
> > header for x86.
> >
>
> Seems sound to me, and this header might be a useful place to put other
> things, like macros to emit exceptions, etc...
>
I have already done similar things in the unified pvops patch. But it
was just a few locations, and I didn't fell the need for a common
thing. But it is definitely useful.

-- 
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 asm-compat.h to x86

2007-10-30 Thread Jeremy Fitzhardinge

Mathieu Desnoyers wrote:
> Add asm-compat.h to x86
>
> In assembly code and in gcc inline assembly, we need .long to express a "c 
> long"
> type on i386 and a .quad to express the same on x86_64. Use macros similar to
> powerpc "PPC_LONG" to express those. Name chosen: ASM_LONG. (didn't feel like
> X86_LONG was required).
>
> This is useful in inline assembly within code shared between 32 and 64
> bits architectures in x86.
>
> More compatible assembly macros could be added in this header later when
> needed.
>
> I had to create this to implement a merged optimized immediate values
> header for x86.
>   

Seems sound to me, and this header might be a useful place to put other
things, like macros to emit exceptions, etc...

J
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> CC: Thomas Gleixner <[EMAIL PROTECTED]>
> CC: Ingo Molnar <[EMAIL PROTECTED]>
> CC: "H. Peter Anvin" <[EMAIL PROTECTED]>
> ---
>  include/asm-x86/asm-compat.h |   29 +
>  1 file changed, 29 insertions(+)
>
> Index: linux-2.6-lttng/include/asm-x86/asm-compat.h
> ===
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ linux-2.6-lttng/include/asm-x86/asm-compat.h  2007-10-24 
> 09:41:09.0 -0400
> @@ -0,0 +1,29 @@
> +#ifndef _ASM_X86_ASM_COMPAT_H
> +#define _ASM_X86_ASM_COMPAT_H
> +
> +#include 
> +
> +#ifdef __ASSEMBLY__
> +#  define stringify_in_c(...)__VA_ARGS__
> +#  define ASM_CONST(x)   x
> +#else
> +/* This version of stringify will deal with commas... */
> +#  define __stringify_in_c(...)  #__VA_ARGS__
> +#  define stringify_in_c(...)__stringify_in_c(__VA_ARGS__) " "
> +#  define __ASM_CONST(x) x##UL
> +#  define ASM_CONST(x)   __ASM_CONST(x)
> +#endif
> +
> +#ifdef CONFIG_X86_64
> +
> +/* operations for longs and pointers */
> +#define ASM_LONG stringify_in_c(.quad)
> +
> +#else /* 32-bit */
> +
> +/* operations for longs and pointers */
> +#define ASM_LONG stringify_in_c(.long)
> +
> +#endif
> +
> +#endif /* _ASM_X86_ASM_COMPAT_H */
>
>   

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

1 2 3 4 5 6 7 >

1 - 100 of 628 matches

Mail list logo