twitter: linux.kernel - 25 new messages in 20 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* linux-next: vfs tree build warning - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f298e042af218de3?hl=en
* [v2] vmstat: add anon_scan_ratio field to zoneinfo - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/c89061c47f128629?hl=en
* [RFC][PATCH] PM: Force GFP_NOIO during suspend/resume (was: Re: Memory
allocations in .suspend became very unreliable) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ea47ae157ce53ab8?hl=en
* clockevents: fix clockevent_devices list corruption after cpu hotplug - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/e4ca30da40649a04?hl=en
* vfs: introduce FMODE_NEG_OFFSET for allowing negative f_pos - 3 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/73ada7b3722506e3?hl=en
* linux-next: Tree for January 14 (drm header files) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5497977e7292e95c?hl=en
* arch/sh: Fix build failure caused by missing semicolon / missing include - 2
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/fce67b9492569094?hl=en
* linux-next: manual merge of the acpi tree with Linus' tree - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/4d4b5fa29e087171?hl=en
* rt2870sta: constify RTUSBMultiWrite(), RTUSBFirmwareWrite() - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/b61d0c7f0b05acb9?hl=en
* workqueue: implement work_busy() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/675a7a7f351dadda?hl=en
* sched_clock.c change to -stable? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2470b21ebc380bcf?hl=en
* fio mmap randread 64k more than 40% regression with 2.6.33-rc1 - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/76a44da5bee9106a?hl=en
* S2io: two branches the same in wait_for_cmd_complete() - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/9773c5fd3b4ced83?hl=en
* Fix wrong offset for vma merge in mbind - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0212c4e6ca612b7f?hl=en
* add MAP_UNLOCKED mmap flag - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ad07c0cc16e721ec?hl=en
* linux-next: manual merge of the arm tree with the arm-current tree - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/9140c5d9349ba840?hl=en
* drivers/net: Eliminate useless code - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/fec3c4db27721f05?hl=en
* vfs: Fix vmtruncate() regression - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d06889ba23497311?hl=en
* linux-next: origin tree build warning - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8b3cd5b75d7e266b?hl=en
* linux-next: manual merge of the rr tree with Linus' tree - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/adde684db4651655?hl=en

==============================================================================
TOPIC: linux-next: vfs tree build warning
http://groups.google.com/group/linux.kernel/t/f298e042af218de3?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 6:20 pm
From: Stephen Rothwell

Hi Al,

Today's linux-next build (x86_64_allmodconfig) produced this warning:

fs/logfs/inode.c:399: warning: initialization from incompatible pointer type

Introduced by commit bc39e28236344af617473df80abb7de43176511e ("pass
writeback_control to ->write_inode") from the vfs tree interacting with
commit 5db53f3e80dee2d9dff5e534f9e9fe1db17c9936 ("[LogFS] add new flash
file system") from the logfs tree.

This will need a fixup patch (see below) which I can carry in the
linux-next tree. There may, of course, be a better fix (which I can
carry if someone sends it to me).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 18 Jan 2010 12:14:59 +1100
Subject: [PATCH] logfs: fixup for write_inode API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
fs/logfs/inode.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/fs/logfs/inode.c b/fs/logfs/inode.c
index 6d08b37..36308af 100644
--- a/fs/logfs/inode.c
+++ b/fs/logfs/inode.c
@@ -8,6 +8,7 @@
#include "logfs.h"
#include <linux/writeback.h>
#include <linux/backing-dev.h>
+#include <linux/writeback.h>

/*
* How soon to reuse old inode numbers? LogFS doesn't store deleted inodes
@@ -282,7 +283,7 @@ struct inode *logfs_read_meta_inode(struct super_block *sb, u64 ino)
return inode;
}

-static int logfs_write_inode(struct inode *inode, int do_sync)
+static int logfs_write_inode(struct inode *inode, struct writeback_control *wbc)
{
int ret;
long flags = WF_LOCK;
--
1.6.6

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

==============================================================================
TOPIC: [v2] vmstat: add anon_scan_ratio field to zoneinfo
http://groups.google.com/group/linux.kernel/t/c89061c47f128629?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Jan 17 2010 6:30 pm
From: Minchan Kim

On Mon, Jan 18, 2010 at 11:16 AM, Rik van Riel <riel@redhat.com> wrote:
> On 01/17/2010 09:10 PM, Minchan Kim wrote:
>
>> Absoultely right. I missed that. Thanks.
>> get_scan_ratio used lru_lock to get reclaim_stat->recent_xxxx.
>> But, it doesn't used lru_lock to get ap/fp.
>>
>> Is it intentional? I think you or Rik know it. :)
>> I think if we want to get exact value, we have to use lru_lock until
>> getting ap/fp.
>> If it isn't, we don't need lru_lock when we get the
>> reclaim_stat->recent_xxxx.
>>
>> What do you think about it?
>
> This is definately not intentional.
>
> Getting race conditions in this code could throw off the
> statistics by a factor 2. I do not know how serious that
> would be for the VM or whether (and how quickly) it would
> self correct.

Okay. How about making patch to get exact ap/fp?
Although it were not serious or fast recoverable, I think it would be better
to protect lru_lock for consistency if lru_lock isn't big contention lock.

>
> --
> All rights reversed.
>

--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Sun, Jan 17 2010 6:30 pm
From: KOSAKI Motohiro

> On 01/17/2010 09:10 PM, Minchan Kim wrote:
>
> > Absoultely right. I missed that. Thanks.
> > get_scan_ratio used lru_lock to get reclaim_stat->recent_xxxx.
> > But, it doesn't used lru_lock to get ap/fp.
> >
> > Is it intentional? I think you or Rik know it. :)
> > I think if we want to get exact value, we have to use lru_lock until
> > getting ap/fp.
> > If it isn't, we don't need lru_lock when we get the reclaim_stat->recent_xxxx.
> >
> > What do you think about it?
>
> This is definately not intentional.

Really?
So, I'll post next patch.

Thanks.

> Getting race conditions in this code could throw off the
> statistics by a factor 2. I do not know how serious that
> would be for the VM or whether (and how quickly) it would
> self correct.
>
> --
> All rights reversed.

==============================================================================
TOPIC: [RFC][PATCH] PM: Force GFP_NOIO during suspend/resume (was: Re: Memory
allocations in .suspend became very unreliable)
http://groups.google.com/group/linux.kernel/t/ea47ae157ce53ab8?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 6:30 pm
From: KOSAKI Motohiro

> Index: linux-2.6/mm/page_alloc.c
> ===================================================================
> --- linux-2.6.orig/mm/page_alloc.c
> +++ linux-2.6/mm/page_alloc.c
> @@ -1963,10 +1963,13 @@ __alloc_pages_nodemask(gfp_t gfp_mask, u
> page = get_page_from_freelist(gfp_mask|__GFP_HARDWALL, nodemask, order,
> zonelist, high_zoneidx, ALLOC_WMARK_LOW|ALLOC_CPUSET,
> preferred_zone, migratetype);
> - if (unlikely(!page))
> + if (unlikely(!page)) {
> + mm_lock_suspend(gfp_mask);
> page = __alloc_pages_slowpath(gfp_mask, order,
> zonelist, high_zoneidx, nodemask,
> preferred_zone, migratetype);
> + mm_unlock_suspend(gfp_mask);
> + }
>
> trace_mm_page_alloc(page, order, gfp_mask, migratetype);
> return page;

I think we don't need read side lock at all. generally, no lock might makes race.
But in this case, changing gfp_allowed_mask and nvidia suspend method should be
serialized higher level. Why the above two code need to run concurrently?

==============================================================================
TOPIC: clockevents: fix clockevent_devices list corruption after cpu hotplug
http://groups.google.com/group/linux.kernel/t/e4ca30da40649a04?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 6:40 pm
From: Xiaotian Feng

On 01/17/2010 05:28 PM, Ozan Çağlayan wrote:
> Thomas Gleixner wrote:
>
>>
>> I'm not happy about that churn. Why don't we simply scan the
>> clockevent_devices list for leftovers of the dead CPU ?
>>
>> Untested patch below solves the same problem.
>
>
> Hi, I have 3 bug reports about a clockevent failure while halting the system (2.6.31.11 kernel).
> It exactly pinpoints to the line 262 which got changed with this patch merged to 2.6.31.10 (and also 2.6.32.3):
>
> [4406.986777] kernel BUG at kernel/time/clockevents.c:262!
> [4406.986777] invalid opcode: 0000 [#1] SMP
> [4406.986777] last sysfs file: /sysfs/module/ip_tables/initstate

I think this one is duplicated of
http://bugzilla.kernel.org/show_bug.cgi?id=15037
Thomas is working on the fix. I've sent a workaround patch on
http://patchwork.kernel.org/patch/71537/

>
>
> All 3 systems have Pentium 4 processors with different clock speeds.
>
> Here's a screenshot of the full stacktrace:
> http://bugs.pardus.org.tr/attachment.cgi?id=4820
>
> and the relevant bugzilla report:
> http://bugzilla.kernel.org/show_bug.cgi?id=15073
>
> Thanks,
> Ozan Caglayan
> Pardus Linux -- http://www.pardus.org.tr/eng
>

==============================================================================
TOPIC: vfs: introduce FMODE_NEG_OFFSET for allowing negative f_pos
http://groups.google.com/group/linux.kernel/t/73ada7b3722506e3?hl=en
==============================================================================

== 1 of 3 ==
Date: Sun, Jan 17 2010 6:40 pm
From: KAMEZAWA Hiroyuki

On Mon, 18 Jan 2010 11:13:04 +0900
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> wrote:

> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> writes:
>
> > On Mon, 18 Jan 2010 10:38:27 +0900
> > OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> wrote:
> >
> >> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> writes:
> >>
> >> >> So, lseek() returns (uses) it?
> >> >
> >> > lseek can return negative value, as far as I know.
> >>
> >> Umm..., how do you know the difference of -EOVERFLOW and fpos == -75?
> >>
> >
> > Ah, sorry. I read wrong.
> >
> > For /dev/mem, it uses its own lseek function which allows negative f_pos
> > value. Other usual file system doesn't allow negative f_pos.
> >
> > It's ok not to return -EOVEFLOW for /dev/mem because there is no file end.
>
> No, no. I think it has the problem.
>
> E.g. /dev/mem returns -75 as fpos, so, lseek(2) returns -75 to
> userland. Then the userland (e.g. glibc) convert it as
> error. I.e. finally, errno == -75, and lseek(3) returns -1, right?
>
Maybe possible.

Hmm. Then, /dev/mem's llseek need some fix not to return pos < -PAGESIZE.
Wu-san, could you add additional bug fix to lseek()'s f_pos handling in
/dev/mem ?

Thanks,
-Kame

== 2 of 3 ==
Date: Sun, Jan 17 2010 7:20 pm
From: "Wu, Fengguang"

Hi,

[replying from webmail, sorry for top-posting]

memory_lseek() calls force_successful_syscall_return() to force success on negative vals.
However that is a no-op for x86.

My experiment shows that lseek() does return negative pos. However,
manual says that "a value of (off_t) -1 is returned" on error. So it's OK
as long as your program is written as "err == -1" instead of "err < 0".

code:
err = lseek64(fd, addr, SEEK_SET);
if (err == -1)
perror("seek " FILENAME);

output:
# kmem-rw 0xffffffffa0094000
addr=0xffffffffa0094000 val=0x441f0fe5894855

strace:
open("/dev/kmem", O_RDWR) = 3
lseek(3, 18446744072099545088, SEEK_SET) = 18446744072099545088
read(3, "UH\211\345\17\37D\0"..., 8) = 8

Thanks,
Fengguang
________________________________________
From: KAMEZAWA Hiroyuki [kamezawa.hiroyu@jp.fujitsu.com]
Sent: Monday, January 18, 2010 10:30 AM
To: OGAWA Hirofumi
Cc: Wu, Fengguang; Andrew Morton; Al Viro; Heiko Carstens; Christoph Hellwig; LKML; Eric Paris; Nick Piggin; Andi Kleen; David Howells; Jonathan Corbet; linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 6/6] vfs: introduce FMODE_NEG_OFFSET for allowing negative f_pos

On Mon, 18 Jan 2010 11:13:04 +0900
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> wrote:

Hmm. Then, /dev/mem's llseek need some fix not to return pos < -PAGESIZE.
Wu-san, could you add additional bug fix to lseek()'s f_pos handling in
/dev/mem ?

Thanks,
-Kame

== 3 of 3 ==
Date: Sun, Jan 17 2010 7:30 pm
From: KAMEZAWA Hiroyuki

On Mon, 18 Jan 2010 11:15:38 +0800
"Wu, Fengguang" <fengguang.wu@intel.com> wrote:

> Hi,
>
> [replying from webmail, sorry for top-posting]
>
> memory_lseek() calls force_successful_syscall_return() to force success on negative vals.
> However that is a no-op for x86.
>
> My experiment shows that lseek() does return negative pos. However,
> manual says that "a value of (off_t) -1 is returned" on error. So it's OK
> as long as your program is written as "err == -1" instead of "err < 0".
>
On error, the kernel returns -EOVERFLOW (via %eax) and libc hides
it by
errno = EOVERFLOW
ret = -1

The problem discussed here is the kernel's return value. So, the kernel's
lseek should check that, I think.

Anyway, this lseek problem is not related to this patch itself and has
existed for very long time. Fixing it later by another patch is not very
bad, I think.
(I'm sorry I myself is not ready for writing a patch...)

Thaks,
-Kame

==============================================================================
TOPIC: linux-next: Tree for January 14 (drm header files)
http://groups.google.com/group/linux.kernel/t/5497977e7292e95c?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 6:50 pm
From: Stephen Rothwell

[Just cc'd Dave]

On Sun, 17 Jan 2010 15:17:18 -0800 Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
> Is anything being done about these?
> or does anything need to be done?
>
>
> usr/include/drm/drm_mode.h:84: found __[us]{8,16,32,64} type without #include <linux/types.h>
> usr/include/drm/i915_drm.h:119: found __[us]{8,16,32,64} type without #include <linux/types.h>
> usr/include/drm/mga_drm.h:260: found __[us]{8,16,32,64} type without #include <linux/types.h>
> usr/include/drm/radeon_drm.h:758: found __[us]{8,16,32,64} type without #include <linux/types.h>
> usr/include/drm/via_drm.h:117: found __[us]{8,16,32,64} type without #include <linux/types.h>
>
>
> Thanks,
> ---
> ~Randy

--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

==============================================================================
TOPIC: arch/sh: Fix build failure caused by missing semicolon / missing
include
http://groups.google.com/group/linux.kernel/t/fce67b9492569094?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Jan 17 2010 7:00 pm
From: Peter Huewe

From: Peter Huewe <peterhuewe@gmx.de>
Date: Mon, 18 Jan 2010 03:48:31 +0100

This patch fixes a build failure[1][2] for all sh configs, by fixing a
missing semicolon and a missing include file.

Build failure was introduced by the patch
sh: fixed PMB mode refactoring [3]
of Wed, 13 Jan 2010 09:31:48 +0000 (18:31 +0900)

References:
[1] http://kisskb.ellerman.id.au/kisskb/buildresult/2019836/
[2] http://kisskb.ellerman.id.au/kisskb/compiler/16/
[3] http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=a0ab36689a36e583b6e736f1c99ac8c9aebdad59

Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
---
Patch against linux-next tree of 20100114
KernelVersion: next-20100114

arch/sh/include/asm/mmu.h | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/sh/include/asm/mmu.h b/arch/sh/include/asm/mmu.h
index 4b0882b..c5313e2 100644
--- a/arch/sh/include/asm/mmu.h
+++ b/arch/sh/include/asm/mmu.h
@@ -1,5 +1,6 @@
#ifndef __MMU_H
#define __MMU_H
+#include <linux/errno.h>

/*
* Privileged Space Mapping Buffer (PMB) definitions
@@ -75,7 +76,7 @@ int pmb_init(void);
static inline long pmb_remap(unsigned long virt, unsigned long phys,
unsigned long size, unsigned long flags)
{
- return -EINVAL
+ return -EINVAL;
}

static inline void pmb_unmap(unsigned long addr)
--
1.6.4.4

== 2 of 2 ==
Date: Sun, Jan 17 2010 8:10 pm
From: Paul Mundt

On Mon, Jan 18, 2010 at 03:57:31AM +0100, Peter Huewe wrote:
> From: Peter Huewe <peterhuewe@gmx.de>
> Date: Mon, 18 Jan 2010 03:48:31 +0100
>
> This patch fixes a build failure[1][2] for all sh configs, by fixing a
> missing semicolon and a missing include file.
>
> Build failure was introduced by the patch
> sh: fixed PMB mode refactoring [3]
> of Wed, 13 Jan 2010 09:31:48 +0000 (18:31 +0900)
>
This was already caught and corrected, thanks anyways.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: linux-next: manual merge of the acpi tree with Linus' tree
http://groups.google.com/group/linux.kernel/t/4d4b5fa29e087171?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 7:00 pm
From: Stephen Rothwell

Hi Len,

Today's linux-next merge of the acpi tree got a conflict in
drivers/gpu/drm/i915/intel_lvds.c between commit
40f33a92100f4d9b6e85ad642100cfe42d7ff57d ("drm/i915: Add HP
nx9020/SamsungSX20S to ACPI LID quirk list") from Linus' tree and commit
25fbdd0b66c193607ed058662e06d29345766c17 ("drm/i915: Add HP
nx9020/Samsung SX20S to ACPI LID quirk list") from the acpi tree.

Clearly two (slightly different) versions of the same change. I used the
version from the drm tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

==============================================================================
TOPIC: rt2870sta: constify RTUSBMultiWrite(), RTUSBFirmwareWrite()
http://groups.google.com/group/linux.kernel/t/b61d0c7f0b05acb9?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 7:00 pm
From: Ben Hutchings

These functions do not modify the data they are passed.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/staging/rt2860/rtmp.h | 6 +++---
drivers/staging/rt2870/common/rtusb_io.c | 10 +++++-----
2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/rt2860/rtmp.h b/drivers/staging/rt2860/rtmp.h
index c50abf4..6c6503d 100644
--- a/drivers/staging/rt2860/rtmp.h
+++ b/drivers/staging/rt2860/rtmp.h
@@ -4043,10 +4043,10 @@ int RTUSBMultiRead(struct rt_rtmp_adapter *pAd,
u16 Offset, u8 *pData, u16 length);

int RTUSBMultiWrite(struct rt_rtmp_adapter *pAd,
- u16 Offset, u8 *pData, u16 length);
+ u16 Offset, const u8 *pData, u16 length);

int RTUSBMultiWrite_OneByte(struct rt_rtmp_adapter *pAd,
- u16 Offset, u8 *pData);
+ u16 Offset, const u8 *pData);

int RTUSBReadBBPRegister(struct rt_rtmp_adapter *pAd,
u8 Id, u8 *pValue);
@@ -4112,7 +4112,7 @@ int RTUSBSingleWrite(struct rt_rtmp_adapter *pAd,
u16 Offset, u16 Value);

int RTUSBFirmwareWrite(struct rt_rtmp_adapter *pAd,
- u8 *pFwImage, unsigned long FwLen);
+ const u8 *pFwImage, unsigned long FwLen);

int RTUSBVenderReset(struct rt_rtmp_adapter *pAd);

diff --git a/drivers/staging/rt2870/common/rtusb_io.c b/drivers/staging/rt2870/common/rtusb_io.c
index 34443f2..cf0d2f5 100644
--- a/drivers/staging/rt2870/common/rtusb_io.c
+++ b/drivers/staging/rt2870/common/rtusb_io.c
@@ -84,7 +84,7 @@ static int RTUSBFirmwareRun(struct rt_rtmp_adapter *pAd)
========================================================================
*/
int RTUSBFirmwareWrite(struct rt_rtmp_adapter *pAd,
- u8 *pFwImage, unsigned long FwLen)
+ const u8 *pFwImage, unsigned long FwLen)
{
u32 MacReg;
int Status;
@@ -167,7 +167,7 @@ int RTUSBMultiRead(struct rt_rtmp_adapter *pAd,
========================================================================
*/
int RTUSBMultiWrite_OneByte(struct rt_rtmp_adapter *pAd,
- u16 Offset, u8 *pData)
+ u16 Offset, const u8 *pData)
{
int Status;

@@ -175,18 +175,18 @@ int RTUSBMultiWrite_OneByte(struct rt_rtmp_adapter *pAd,
Status = RTUSB_VendorRequest(pAd,
USBD_TRANSFER_DIRECTION_OUT,
DEVICE_VENDOR_REQUEST_OUT,
- 0x6, 0, Offset, pData, 1);
+ 0x6, 0, Offset, (u8 *)pData, 1);

return Status;
}

int RTUSBMultiWrite(struct rt_rtmp_adapter *pAd,
- u16 Offset, u8 *pData, u16 length)
+ u16 Offset, const u8 *pData, u16 length)
{
int Status;

u16 index = 0, Value;
- u8 *pSrc = pData;
+ const u8 *pSrc = pData;
u16 resude = 0;

resude = length % 2;
--
1.6.6

==============================================================================
TOPIC: workqueue: implement work_busy()
http://groups.google.com/group/linux.kernel/t/675a7a7f351dadda?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 7:00 pm
From: Andy Walls

On Mon, 2010-01-18 at 09:57 +0900, Tejun Heo wrote:
> Implement work_busy() which tests whether a work is either pending or
> running. The test isn't synchronized against workqueue operation and
> the result is only good as advisory hints or for debugging.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>

Hi Tejun,

>From a driver writer's perspective, this function not useful since it is
unreliable (false positives only?) and I have no way of

"ensuring the workqueue @work was last queued on stays valid until this
function returns."

I don't quite know how to check and enfore a workqueue's continuing
validity across the function call. (Maybe you could clarify?)

As a driver writer, I'd do one of two things to reliably know when a
work is "not busy":

1. mark work objects which I submitted with an atomic_t or bit flags:

struct foo_work {
struct work_struct work;
atomic_t dispatched;
struct foo_instance *foo;
};

struct foo_instance {
...
struct foo_work work_object[5];
...
};

The irq_handler finds a work_object[] that is not dispatched, marks it
dispatched, and schedules the work. The work handler will clear the
dispatched field when it is done with the work object. A busy work
object will have dispatched set, a non-busy work will not, and
dispatched can be checked atomically.

This still can suffer from false positives for "busy", but it functions
as long as the work_object[] exists vs. the workqueue validity criterion
(which isn't clear to me). The driver has direct control of when the
work_object[] array will be valid.

Or
2. Just schedule the work object and check the return value to see if
the submission suceeded. If it did, the work was "not pending". This
method can't check for "running" of course.

Is there some specific use case where this function is very useful
despite being unreliable? I just think it's asking for abuse by someone
who would think "mostly reliable" is good enough, when it actually may
not be.

Regards,
Andy

> ---
> include/linux/workqueue.h | 2 +-
> kernel/workqueue.c | 31 +++++++++++++++++++++++++++++++
> 2 files changed, 32 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
> index 265207d..4f8705f 100644
> --- a/include/linux/workqueue.h
> +++ b/include/linux/workqueue.h
> @@ -293,8 +293,8 @@ extern int keventd_up(void);
> extern void init_workqueues(void);
> int execute_in_process_context(work_func_t fn, struct execute_work *);
>
> +extern bool work_busy(struct work_struct *work);
> extern int flush_work(struct work_struct *work);
> -
> extern int cancel_work_sync(struct work_struct *work);
>
> /*
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 233278c..882d4d8 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -1960,6 +1960,37 @@ out_unlock:
> EXPORT_SYMBOL_GPL(flush_workqueue);
>
> /**
> + * work_busy - test whether a work is currently pending or running
> + * @work: the work to be tested
> + *
> + * Test whether @work is currently pending or running. There is no
> + * synchronization around this function and the test result is
> + * unreliable and only useful as advisory hints or for debugging. The
> + * caller is responsible for ensuring the workqueue @work was last
> + * queued on stays valid until this function returns.
> + *
> + * RETURNS:
> + * %true if @work is currently running, %false otherwise.
> + */
> +bool work_busy(struct work_struct *work)
> +{
> + struct cpu_workqueue_struct *cwq = get_wq_data(work);
> + struct global_cwq *gcwq;
> + unsigned long flags;
> + bool ret;
> +
> + if (!cwq)
> + return false;
> + gcwq = cwq->gcwq;
> +
> + spin_lock_irqsave(&gcwq->lock, flags);
> + ret = work_pending(work) || find_worker_executing_work(gcwq, work);
> + spin_unlock_irqrestore(&gcwq->lock, flags);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(work_busy);
> +
> +/**
> * flush_work - block until a work_struct's callback has terminated
> * @work: the work which is to be flushed
> *

==============================================================================
TOPIC: sched_clock.c change to -stable?
http://groups.google.com/group/linux.kernel/t/2470b21ebc380bcf?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 7:10 pm
From: David Miller

From: Ingo Molnar <mingo@elte.hu>
Date: Sat, 16 Jan 2010 12:36:47 +0100

>> Therefore, do you mind if I send this commit to -stable?
>>
>> Thanks.
>
> Sure!
>
> I've attached the commit for the -stable team's convenience.

Great, I'll submit it also as part of my sparc -stable submission
to make sure they really get it :-)

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

==============================================================================
TOPIC: fio mmap randread 64k more than 40% regression with 2.6.33-rc1
http://groups.google.com/group/linux.kernel/t/76a44da5bee9106a?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 7:10 pm
From: "Zhang, Yanmin"

On Sat, 2010-01-16 at 17:27 +0100, Corrado Zoccolo wrote:
> Hi Yanmin
> On Mon, Jan 4, 2010 at 7:28 PM, Corrado Zoccolo <czoccolo@gmail.com> wrote:
> > Hi Yanmin,
> >> When low_latency=1, we get the biggest number with kernel 2.6.32.
> >> Comparing with low_latency=0's result, the prior one is about 4% better.
> > Ok, so 2.6.33 + corrado (with low_latency =0) is comparable with
> > fastest 2.6.32, so we can consider the first part of the problem
> > solved.
> >
> I think we can return now to your full script with queue merging.
> I'm wondering if (in arm_slice_timer):
> - if (cfqq->dispatched)
> + if (cfqq->dispatched || (cfqq->new_cfqq && rq_in_driver(cfqd)))
> return;
> gives the same improvement you were experiencing just reverting to rq_in_driver.
I did a quick testing against 2.6.33-rc1. With the new method, fio mmap randread 46k
has about 20% improvement. With just checking rq_in_driver(cfqd), it has
about 33% improvement.

>
> We saw that cfqq->dispatched worked fine when there was no queue
> merging happening, so it must be something concerning merging,
> probably dispatched is not accurate when we set up for a merging, but
> the merging was not yet done.

==============================================================================
TOPIC: S2io: two branches the same in wait_for_cmd_complete()
http://groups.google.com/group/linux.kernel/t/9773c5fd3b4ced83?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Jan 17 2010 7:20 pm
From: David Miller

From: Roel Kluin <roel.kluin@gmail.com>
Date: Sun, 17 Jan 2010 16:10:04 +0100

> Regardless of the bit_state, the branches execute the same code.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> drivers/net/s2io.c | 13 +++----------
> 1 files changed, 3 insertions(+), 10 deletions(-)
>
> Maybe something else was intended?
> this was introduced in commit 9fc93a41a1ad11

If you know the guilty commit, at least do the author(s) of commit
and/or the driver maintainer(s) the courtesy of CC:'ing them on
patches like this.

I've fixed this up here in my reply.

> diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
> index cc42186..0e353d6 100644
> --- a/drivers/net/s2io.c
> +++ b/drivers/net/s2io.c
> @@ -3415,16 +3415,9 @@ static int wait_for_cmd_complete(void __iomem *addr, u64 busy_bit,
>
> do {
> val64 = readq(addr);
> - if (bit_state == S2IO_BIT_RESET) {
> - if (!(val64 & busy_bit)) {
> - ret = SUCCESS;
> - break;
> - }
> - } else {
> - if (!(val64 & busy_bit)) {
> - ret = SUCCESS;
> - break;
> - }
> + if (!(val64 & busy_bit)) {
> + ret = SUCCESS;
> + break;
> }
>
> if (in_interrupt())
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Sun, Jan 17 2010 8:00 pm
From: Joe Perches

On Sun, 2010-01-17 at 19:13 -0800, David Miller wrote:
> From: Roel Kluin <roel.kluin@gmail.com>
> Date: Sun, 17 Jan 2010 16:10:04 +0100
> > Regardless of the bit_state, the branches execute the same code.
> > Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> > ---
> > drivers/net/s2io.c | 13 +++----------
> > 1 files changed, 3 insertions(+), 10 deletions(-)
> > Maybe something else was intended?
> > this was introduced in commit 9fc93a41a1ad11
> If you know the guilty commit, at least do the author(s) of commit
> and/or the driver maintainer(s) the courtesy of CC:'ing them on
> patches like this.

One way to do that is to use:
$ ./scripts/get_maintainer.pl --git-blame <patch>

==============================================================================
TOPIC: Fix wrong offset for vma merge in mbind
http://groups.google.com/group/linux.kernel/t/0212c4e6ca612b7f?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 7:20 pm
From: KOSAKI Motohiro

> mm-fix-mbind-vma-merge-problem.patch added vma_merge in mbind
> to merge mergeable vmas.
> But it passed wrong offset of vm_file.
>
> This patch fixes it.
>
> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Cc: Christoph Lameter <cl@linux-foundation.org>
> Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>

Nice catch!
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>

> ---
> mm/mempolicy.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index 9751f3f..7e529d0 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -570,6 +570,7 @@ static int mbind_range(struct mm_struct *mm, unsigned long start,
> struct vm_area_struct *prev;
> struct vm_area_struct *vma;
> int err = 0;
> + pgoff_t pgoff;
> unsigned long vmstart;
> unsigned long vmend;
>
> @@ -582,9 +583,9 @@ static int mbind_range(struct mm_struct *mm, unsigned long start,
> vmstart = max(start, vma->vm_start);
> vmend = min(end, vma->vm_end);
>
> + pgoff = vma->vm_pgoff + ((start - vma->vm_start) >> PAGE_SHIFT);
> prev = vma_merge(mm, prev, vmstart, vmend, vma->vm_flags,
> - vma->anon_vma, vma->vm_file, vma->vm_pgoff,
> - new_pol);
> + vma->anon_vma, vma->vm_file, pgoff, new_pol);
> if (prev) {
> vma = prev;
> next = vma->vm_next;
> --
> 1.6.3.3
>
>
>
> --
> Kind regards,
> Minchan Kim
>

==============================================================================
TOPIC: add MAP_UNLOCKED mmap flag
http://groups.google.com/group/linux.kernel/t/ad07c0cc16e721ec?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 7:30 pm
From: KOSAKI Motohiro

> On Thu, Jan 14, 2010 at 3:17 AM, KOSAKI Motohiro
> <kosaki.motohiro@jp.fujitsu.com> wrote:
> >> > Hmm..
> >> > Your answer didn't match I wanted.
> >> Then I don't get what you want.
> >
> > I want to know the benefit of the patch for patch reviewing.
> >
>
> The benefit of the patch is that it makes it possible for an
> application which has previously called mlockall(MCL_FUTURE) to
> selectively exempt new memory mappings from memory locking, on a
> per-mmap-call basis. As was pointed out earlier, there is currently no
> thread-safe way for an application to do this. The earlier proposed
> workaround of toggling MCL_FUTURE around calls to mmap is racy in a
> multi-threaded context. Other threads may manipulate the address space
> during the window where MCL_FUTURE is off, subverting the programmers
> intended memory locking semantics.
>
> The ability to exempt specific memory mappings from memory locking is
> necessary when the region to be mapped is larger than physical memory.
> In such cases a call to mmap the region cannot succeed, unless
> MAP_UNLOCKED is available.
>
>
> >
> >> > few additional questions.
> >> >
> >> > - Why don't you change your application? It seems natural way than kernel change.
> >> There is no way to change my application and achieve what I've described
> >> in a multithreaded app.
> >
> > Then, we don't recommend to use mlockall(). I don't hope to hear your conclusion,
> > it is not objectivization. I hope to hear why you reached such conclusion.
> >
>
> I agree that mlockall is a big hammer and should be avoided in most
> cases, but there are situations where it is exactly what is needed. In
> Gleb's instance, it sounds like he is doing some finicky performance
> measurement and major page faults skew his results. In my case, I have
> a realtime process where the measured latency impact of major page
> faults is unacceptable. In both of these cases, mlockall is a
> reasonable approach to eliminating major faults.
>
> However, Gleb and I have independently found ourselves unable to use
> mlockall because we also need to create a very large memory mapping
> (for which we don't care about major faults). The proposed
> MAP_UNLOCKED flag would allow us to override MCL_FUTURE for that one
> mapping.
>
> >
> >> > - Why do you want your virtual machine have mlockall? AFAIK, current majority
> >> > virtual machine doesn't.
> >> It is absolutely irrelevant for that patch, but just because you ask I
> >> want to measure the cost of swapping out of a guest memory.
> >
> > No. if you stop to use mlockall, the issue is vanished.
> >
>
> And other issues arise. Gleb described a situation where the use of
> mlockall is justified, identified an issue which prevents its use, and
> provided a patch which resolves that issue. Why are you focusing on
> the validity of using mlockall?
>
> >
> >> > - If this feature added, average distro user can get any benefit?
> >> >
> >> ?! Is this some kind of new measure? There are plenty of much more
> >> invasive features that don't bring benefits to an average distro user.
> >> This feature can bring benefit to embedded/RT developers.
> >
> > I mean who get benifit?
> >
> >
> >> > I mean, many application developrs want to add their specific feature
> >> > into kernel. but if we allow it unlimitedly, major syscall become
> >> > the trushbox of pretty toy feature soon.
> >> >
> >> And if application developer wants to extend kernel in a way that it
> >> will be possible to do something that was not possible before why is
> >> this a bad thing? I would agree with you if for my problem was userspace
> >> solution, but there is none. The mmap interface is asymmetric in regards
> >> to mlock currently. There is MAP_LOCKED, but no MAP_UNLOCKED. Why
> >> MAP_LOCKED is useful then?
> >
> > Why? Because this is formal LKML reviewing process. I'm reviewing your
> > patch for YOU.
> >
> > If there is no objective reason, I don't want to continue reviewing.
> >
>
> There is an objective reason: the current interaction between
> mlockall(MCL_FUTURE) and mmap has a deficiency. In 'normal' mode,
> without MCL_FUTURE in force, the default is that new memory mappings
> are not locked, but mmap provides MAP_LOCKED specifically to override
> that default. However, with MCL_FUTURE toggled to on, there is no
> analogous way to tell mmap to override the default. The proposed
> MAP_UNLOCKED flag would resolve this deficiency.

Very thank you, Andrew!

Your explanation help me lots rather than original patch description. OK, At least
MAP_UNLOCED have two users (you and gleb) and your explanation seems
makes sense.

So, if gleb resend this patch with rewrited description, I might take my reviewed-by tag to it, probagly.

Thanks.

==============================================================================
TOPIC: linux-next: manual merge of the arm tree with the arm-current tree
http://groups.google.com/group/linux.kernel/t/9140c5d9349ba840?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 7:40 pm
From: Stephen Rothwell

Hi Ben,

On Mon, 18 Jan 2010 01:33:07 +0000 Ben Dooks <ben-linux@fluff.org> wrote:
>
> Is that from the merge of next-samsung or from two parts of the ARM
> trees?

I merged the arm-current tree
(ssh://master.kernel.org/home/rmk/linux-2.6-arm.git#master) into
linux-next and then later the arm tree
(ssh://master.kernel.org/home/rmk/linux-2.6-arm.git#devel) and the second
merge produced this conflict. However, Russell has merged the samsung
tree (git://git.fluff.org/bjdooks/linux.git#next-samsung) into the arm
tree, already.

--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

==============================================================================
TOPIC: drivers/net: Eliminate useless code
http://groups.google.com/group/linux.kernel/t/fec3c4db27721f05?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 7:40 pm
From: David Miller

From: Julia Lawall <julia@diku.dk>
Date: Sat, 16 Jan 2010 16:57:56 +0100 (CET)

> The variable qdev is initialized twice to the same (side effect-free)
> expression. Drop one initialization.
>
> A simplified version of the semantic match that finds this problem is:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @forall@
> idexpression *x;
> identifier f!=ERR_PTR;
> @@
>
> x = f(...)
> ... when != x
> (
> x = f(...,<+...x...+>,...)
> |
> * x = f(...)
> )
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>

Something in your patch creation process is corrupting these
patches.

> diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
> index f922294..4ef0afb 100644
> --- a/drivers/net/qla3xxx.c
> +++ b/drivers/net/qla3xxx.c
> @@ -4087,9 +4087,8 @@ static void __devexit ql3xxx_remove(struct pci_dev *pdev)
> struct ql3_adapter *qdev = netdev_priv(ndev);
>
> unregister_netdev(ndev);
> - qdev = netdev_priv(ndev);
>
> ql_disable_interrupts(qdev);
>
> --

That hunk header states that after the line is removed there should
be 8 lines present in the hunk, but the patch only shows 7 such
lines.

I suspect something is eating the final line of your patches.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: vfs: Fix vmtruncate() regression
http://groups.google.com/group/linux.kernel/t/d06889ba23497311?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 8:00 pm
From: Nick Piggin

On Fri, Jan 15, 2010 at 09:26:02AM +0900, OGAWA Hirofumi wrote:
> Andrew Morton <akpm@linux-foundation.org> writes:
>
> > On Wed, 13 Jan 2010 21:14:09 +0900
> > OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> wrote:
> >
> >>
> >> If __block_prepare_write() was failed in block_write_begin(), the
> >> allocated blocks can be outside of ->i_size.
> >>
> >> But new truncate_pagecache() in vmtuncate() does nothing if new < old.
> >> It means the above usage is not working anymore.
> >>
> >> So, this patch fixes it by removing "new < old" check. It would need
> >> more cleanup/change. But, now -rc and truncate working is in progress,
> >> so, this tried to fix it minimum change.
> >>
> >> Acked-by: Nick Piggin <npiggin@suse.de>
> >> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> >> ---
> >>
> >> mm/truncate.c | 28 +++++++++++++---------------
> >> 1 file changed, 13 insertions(+), 15 deletions(-)
> >>
> >> diff -puN mm/truncate.c~truncate_pagecache-fix mm/truncate.c
> >> --- linux-2.6/mm/truncate.c~truncate_pagecache-fix 2010-01-12 05:43:06.000000000 +0900
> >> +++ linux-2.6-hirofumi/mm/truncate.c 2010-01-12 05:43:06.000000000 +0900
> >> @@ -522,22 +522,20 @@ EXPORT_SYMBOL_GPL(invalidate_inode_pages
> >> */
> >> void truncate_pagecache(struct inode *inode, loff_t old, loff_t new)
> >> {
> >> - if (new < old) {
> >> - struct address_space *mapping = inode->i_mapping;
> >> + struct address_space *mapping = inode->i_mapping;
> >>
> >> - /*
> >> - * unmap_mapping_range is called twice, first simply for
> >> - * efficiency so that truncate_inode_pages does fewer
> >> - * single-page unmaps. However after this first call, and
> >> - * before truncate_inode_pages finishes, it is possible for
> >> - * private pages to be COWed, which remain after
> >> - * truncate_inode_pages finishes, hence the second
> >> - * unmap_mapping_range call must be made for correctness.
> >> - */
> >> - unmap_mapping_range(mapping, new + PAGE_SIZE - 1, 0, 1);
> >> - truncate_inode_pages(mapping, new);
> >> - unmap_mapping_range(mapping, new + PAGE_SIZE - 1, 0, 1);
> >> - }
> >> + /*
> >> + * unmap_mapping_range is called twice, first simply for
> >> + * efficiency so that truncate_inode_pages does fewer
> >> + * single-page unmaps. However after this first call, and
> >> + * before truncate_inode_pages finishes, it is possible for
> >> + * private pages to be COWed, which remain after
> >> + * truncate_inode_pages finishes, hence the second
> >> + * unmap_mapping_range call must be made for correctness.
> >> + */
> >> + unmap_mapping_range(mapping, new + PAGE_SIZE - 1, 0, 1);
> >> + truncate_inode_pages(mapping, new);
> >> + unmap_mapping_range(mapping, new + PAGE_SIZE - 1, 0, 1);
> >> }
> >> EXPORT_SYMBOL(truncate_pagecache);
> >
> > The fix was applied to 2.6.33-rcX
> > (cedabed49b39b4319bccc059a63344b6232b619c), appears to be needed in
> > 2.6.32.x but no cc:stable's are present?
>
> Ah, yes. I forgot to add "Cc: stable". Please apply this to 2.6.32.x.

Thanks guys, it's quite important so please apply to stable 2.6.32 and
consider it as a high priority to release.

==============================================================================
TOPIC: linux-next: origin tree build warning
http://groups.google.com/group/linux.kernel/t/8b3cd5b75d7e266b?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 8:10 pm
From: Stephen Rothwell

Hi all,

Today's linux-next build (x86_64_allmodconfig) produced these warnings:

drivers/base/memory.c:319: warning: initialization from incompatible pointer type
drivers/base/memory.c:353: warning: initialization from incompatible pointer type
drivers/base/memory.c:408: warning: initialization from incompatible pointer type
drivers/base/memory.c:409: warning: initialization from incompatible pointer type

Introduced by commit 8ff410daa009c4b44be445ded5b0cec00abc0426 ("sysdev:
fix prototype for memory_sysdev_class show/store functions").

The third parameter to SYSDEV_CLASS_ATTR should be a "ssize_t (*)(struct
sysdev_class *, char *)", but this commit changes them to "ssize_t (*)
(struct sysdev_class *, struct sysdev_class_attribute *, char *buf)". Or
maybe the definition of "struct sysdev_class_attribute" is wrong?

It actually looks like commit c29af9636 ("sysdev: Pass attribute in
sysdev_class attributes show/store") referred to in the changelog for the
above commit has not yet been applied to Linus' tree?

--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

==============================================================================
TOPIC: linux-next: manual merge of the rr tree with Linus' tree
http://groups.google.com/group/linux.kernel/t/adde684db4651655?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 8:10 pm
From: Stephen Rothwell

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
include/linux/kernel.h between commit
cc8ef6eb21e964b1c5eb97b2d0e8ac9893e1bf86 ("kernel.h: add
BUILD_BUG_ON_NOT_POWER_OF_2()") from Linus' tree and commit
eb586ef779665b558aeafa9b948c0b005c5caadf
("misc:move-BUILD_BUG-et-al-inside-__KERNEL__") from the rr tree.

I fixed it up (see below) and can carry the fix for a while.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au

diff --cc include/linux/kernel.h
index 328bca6,57ffaa0..0000000
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@@ -702,13 -702,59 +702,63 @@@ static inline void ftrace_dump(void) {
struct sysinfo;
extern int do_sysinfo(struct sysinfo *info);

-

twitter

Sunday, January 17, 2010

linux.kernel - 25 new messages in 20 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts