twitter: linux.kernel - 26 new messages in 16 topics

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

Today's topics:

* Re-enabling non-GPL driver access to disk partition information - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/cdc0617079a6d776?hl=en
* exit: PR_SET_ANCHOR for marking processes as reapers for child processes - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/85def94b1ef0fefe?hl=en
* inodes: Support generic defragmentation - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b72566b846445e03?hl=en
* Staging: hv: fix various coding style issues in RingBuffer.c - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/835318a4006a8a0b?hl=en
* alpha: PTR_ERR overwrites -EINVAL in syscall osf_mount - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/16fdd0b211d48292?hl=en
* kconfig: Look in both /bin and /sbin for lsmod in streamline_config.pl - 5
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/813d37d80464f6e5?hl=en
* slub: ARCH_SLAB_MINALIGN defaults to 8 on x86_32. is this too big? - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/90562c9ef16cf2a0?hl=en
* bitops: compile time optimization for hweight_long(CONSTANT) - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/f58ac10e7917a328?hl=en
* [RFC] 512K readahead size with thrashing safe readahead - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/96ba73a9249e5c25?hl=en
* [linux-next] kconfig: Updates to localmodconfig - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b24eea2db7e3d8f1?hl=en
* dvb: return -ENOMEM if kzalloc failed in dvb_usb_device_init() - 2 messages,
2 authors
http://groups.google.com/group/linux.kernel/t/0d3d1e42dcaac9b8?hl=en
* Improving OOM killer - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/389db2dcf6479d30?hl=en
* kernel-shark: fix unitialized handle compile warnings - 3 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/2ae6ffbd06a5c48a?hl=en
* mxc: Core support for i.MX5 series of processors from Freescale - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/281ca1a532ca6d76?hl=en
* obsolete config in kernel source (IP_ROUTE_PERVASIVE) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d12dd2ed499dffa4?hl=en
* ARM: Change the mandatory barriers implementation - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1873254b2b8984f3?hl=en

==============================================================================
TOPIC: Re-enabling non-GPL driver access to disk partition information
http://groups.google.com/group/linux.kernel/t/cdc0617079a6d776?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 7:30 am
From: David Newall

Greg KH wrote:
> On Sat, Jan 30, 2010 at 02:32:20PM +1030, David Newall wrote:
>
>> Greg KH wrote:
>>
>>> On Fri, Jan 29, 2010 at 09:15:09AM -0500, Derek Atkins wrote:
>>>
>>>
>>>> -EXPORT_SYMBOL_GPL(put_device);
>>>> +EXPORT_SYMBOL(put_device);
>>>>
>>>>
>>> No, sorry, [...] I can not, and will not, make this change.
>>>
>>>
>> Derek,
>>
>> Consider writing a GPL wrapper module.
>>
>
> Ah, the old "GPL condom" try. Sorry, but this has been tried many times
> in the past, and have been shut down every time. See the Samba history
> of this for lots of details as to why this does not work.

Samba vs The Money merely shows that The Money failed to put up a
sufficient defence. Good result for FOSS, but I recommend against you
betting your home on it.

Anyway, I was thinking of something a little more substantial that what
you perhaps read into my suggestion. There's usually a substantial gap
between the pure needs of a driver and the facilities offered by an
operating system. In the case in question, for example, the need is to
count the number of partitions, and the facility offered is get_device,
or something. A tiny GPL module that calls get_device and returns a
count sounds eminently defensible.

In addition--and please keep in mind that I'm unfamiliar with the
internals of the kernel--it seems to me there's an obvious similarity
with USL vs BSD, alleging copyright for verbatim copying of macro
constants, amongst other things. A lesson that learned then was that you
can't prevent someone from using provided facilities necessary for use
of the operating system. I don't know what put_device does, but I know
what it sounds like; it sounds like it's something that you have to use,
and so one can use it, even in proprietary code. I imagine this idea
will irritate those who put in the hard yards, but FOSS has to play by
the same rules as the monied end of town. You might want to think about
this carefully, because if it's taken all the way through court and the
GPL-only claim rejected, there may well be a run-on effect on all of the
symbols marked GPL-only. Those who want to thwart proprietary kernel
modules may find it prudent to generously give up this symbol rather
than risking the lot.
--
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: exit: PR_SET_ANCHOR for marking processes as reapers for child
processes
http://groups.google.com/group/linux.kernel/t/85def94b1ef0fefe?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 7:30 am
From: Américo Wang

On Tue, Feb 02, 2010 at 01:04:57PM +0100, Lennart Poettering wrote:
>
>This patch adds a simple flag for each process that marks it as an
>"anchor" process for all its children and grandchildren. If a child of
>such an anchor dies all its children will not be reparented to init, but
>instead to this anchor, escaping this anchor process is not possible. A
>task with this flag set hence acts is little "sub-init".
>

This will break the applictions which using 'getppid() == 1' to check
if its real parent is dead or not...

--
Live like a child, think like the god.

--
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: inodes: Support generic defragmentation
http://groups.google.com/group/linux.kernel/t/b72566b846445e03?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 7:40 am
From: Christoph Lameter

On Mon, 1 Feb 2010, Dave Chinner wrote:

> > The standard case is the classic updatedb. Lots of dentries/inodes cached
> > with no or little corresponding data cache.
>
> I don't believe that updatedb has anything to do with causing
> internal inode/dentry slab fragmentation. In all my testing I rarely
> see use-once filesystem traversals cause internal slab
> fragmentation. This appears to be a result of use-once filesystem
> traversal resulting in slab pages full of objects that have the same
> locality of access. Hence each new slab page that traversal
> allocates will contain objects that will be adjacent in the LRU.
> Hence LRU-based reclaim is very likely to free all the objects on
> each page in the same pass and as such no fragmentation will occur.

updatedb causes lots of partially allocated slab pages. While updatedb
runs other filesystem activities occur. And updatedb does not work in
straightforward linear fashion. dentries are cached and slowly expired etc
etc. Updatedb may not cause the fragmentation on a level that you observed
with some of the filesystem loads on large systems.

> All the cases of inode/dentry slab fragmentation I have seen are a
> result of access patterns that result in slab pages containing
> objects with different temporal localities. It's when the access
> pattern is sufficiently distributed throughout the working set we
> get the "need to free 95% of the objects in the entire cache to free
> a single page" type of reclaim behaviour.

There are also other factors at play like the different NUMA node,
concurrent processes. A strict optimized HPC workload may be able to
eliminate other factors but that is not the case for typical workloads.
Access patterns are typically somewhat distribyted.

> AFAICT, the defrag patches as they stand don't really address the
> fundamental problem of differing temporal locality inside a slab
> page. It makes the assumption that "partial page == defrag
> candidate" but there isn't any further consideration of when any of
> the remaing objects were last accessed. I think that this really
> does need to be taken into account, especially considering that the
> allocator tries to fill partial pages with new objects before
> allocating new pages and so the page under reclaim might contain
> very recently allocated objects.

Reclaim is only run if there is memory pressure. This means that lots of
reclaimable entities exist and therefore we can assume that many of these
have had a somewhat long lifetime. The allocator tries to fill partial
pages with new objects and then retires those pages to the full slab list.
Those are not subject to reclaim efforts covered here. A page under
reclaim is likely to contain many recently freed objects.

The remaining objects may have a long lifetime and a high usage pattern
but it is worth to relocate them into other slabs if they prevent reclaim
of the page. Relocation occurs in this patchset by reclaim and then the
next use likely causes the reallocation in a partially allocated slab.
This means that objects with a high usage count will tend to be aggregated
in full slabs that are no longer subject to targeted reclaim.

We could improve the situation by allowing the moving of objects (which
would avoid the reclaim and realloc) but that is complex and so needs to
be deferred to a second stage (same approach we went through with page
migration).

> Someone in a previous discussion on this patch set (Nick? Hugh,
> maybe? I can't find the reference right now) mentioned something
> like this about the design of the force-reclaim operations. IIRC the
> suggestion was that it may be better to track LRU-ness by per-slab
> page rather than per-object so that reclaim can target the slab
> pages that - on aggregate - had the oldest objects in it. I think
> this has merit - prevention of internal fragmentation seems like a
> better approach to me than to try to cure it after it is already
> present....

LRUness exists in terms of the list of partial slab pages. Frequently
allocated slabs are in the front of the queue and less used slabs are in
the rear. Defrag/reclaim occurs from the rear.

--
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: Staging: hv: fix various coding style issues in RingBuffer.c
http://groups.google.com/group/linux.kernel/t/835318a4006a8a0b?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 3 2010 7:40 am
From: CB

>From a545464b8c98ca1f2b35b6b701842bca16a6cccf Mon Sep 17 00:00:00 2001
From: C. Bartlett <c-bartlett@hotmail.co.uk>
Date: Wed, 3 Feb 2010 15:08:17 +0000
Subject: [PATCH] Staging: hv: fix various coding style issues in RingBuffer.c
This is a patch to the RingBuffer.c file that corrects various coding style warnings and errors found by checkpatch.pl
Signed-off-by: Craig Bartlett <c-bartlett@hotmail.co.uk>

---
drivers/staging/hv/RingBuffer.c | 153 ++++++++++++++++++++++-----------------
1 files changed, 86 insertions(+), 67 deletions(-)

diff --git a/drivers/staging/hv/RingBuffer.c b/drivers/staging/hv/RingBuffer.c
index f69ae33..80b8a2c 100644
--- a/drivers/staging/hv/RingBuffer.c
+++ b/drivers/staging/hv/RingBuffer.c
@@ -48,7 +48,7 @@ Description:
static inline void
GetRingBufferAvailBytes(RING_BUFFER_INFO *rbi, u32 *read, u32 *write)
{
- u32 read_loc,write_loc;
+ u32 read_loc, write_loc;

/* Capture the read/write indices before they changed */
read_loc = rbi->RingBuffer->ReadIndex;
@@ -68,7 +68,7 @@ Description:

--*/
static inline u32
-GetNextWriteLocation(RING_BUFFER_INFO* RingInfo)
+GetNextWriteLocation(RING_BUFFER_INFO *RingInfo)
{
u32 next = RingInfo->RingBuffer->WriteIndex;

@@ -87,7 +87,7 @@ Description:

--*/
static inline void
-SetNextWriteLocation(RING_BUFFER_INFO* RingInfo, u32 NextWriteLocation)
+SetNextWriteLocation(RING_BUFFER_INFO *RingInfo, u32 NextWriteLocation)
{
RingInfo->RingBuffer->WriteIndex = NextWriteLocation;
}
@@ -102,7 +102,7 @@ Description:

--*/
static inline u32
-GetNextReadLocation(RING_BUFFER_INFO* RingInfo)
+GetNextReadLocation(RING_BUFFER_INFO *RingInfo)
{
u32 next = RingInfo->RingBuffer->ReadIndex;

@@ -122,7 +122,7 @@ Description:

--*/
static inline u32
-GetNextReadLocationWithOffset(RING_BUFFER_INFO* RingInfo, u32 Offset)
+GetNextReadLocationWithOffset(RING_BUFFER_INFO *RingInfo, u32 Offset)
{
u32 next = RingInfo->RingBuffer->ReadIndex;

@@ -143,7 +143,7 @@ Description:

--*/
static inline void
-SetNextReadLocation(RING_BUFFER_INFO* RingInfo, u32 NextReadLocation)
+SetNextReadLocation(RING_BUFFER_INFO *RingInfo, u32 NextReadLocation)
{
RingInfo->RingBuffer->ReadIndex = NextReadLocation;
}
@@ -159,7 +159,7 @@ Description:

--*/
static inline void *
-GetRingBuffer(RING_BUFFER_INFO* RingInfo)
+GetRingBuffer(RING_BUFFER_INFO *RingInfo)
{
return (void *)RingInfo->RingBuffer->Buffer;
}
@@ -175,7 +175,7 @@ Description:

--*/
static inline u32
-GetRingBufferSize(RING_BUFFER_INFO* RingInfo)
+GetRingBufferSize(RING_BUFFER_INFO *RingInfo)
{
return RingInfo->RingDataSize;
}
@@ -190,9 +190,10 @@ Description:

--*/
static inline u64
-GetRingBufferIndices(RING_BUFFER_INFO* RingInfo)
+GetRingBufferIndices(RING_BUFFER_INFO *RingInfo)
{
- return ((u64)RingInfo->RingBuffer->WriteIndex << 32) || RingInfo->RingBuffer->ReadIndex;
+ return ((u64)RingInfo->RingBuffer->WriteIndex << 32)
+ || RingInfo->RingBuffer->ReadIndex;
}

@@ -210,9 +211,14 @@ void DumpRingInfo(RING_BUFFER_INFO *RingInfo, char *Prefix)
u32 bytesAvailToWrite;
u32 bytesAvailToRead;

- GetRingBufferAvailBytes(RingInfo, &bytesAvailToRead, &bytesAvailToWrite);
+ GetRingBufferAvailBytes(RingInfo,
+ &bytesAvailToRead,
+ &bytesAvailToWrite);

- DPRINT(VMBUS, DEBUG_RING_LVL, "%s <<ringinfo %p buffer %p avail write %u avail read %u read idx %u write idx %u>>",
+ DPRINT(VMBUS,
+ DEBUG_RING_LVL,
+ "%s <<ringinfo %p buffer %p avail write %u "
+ "avail read %u read idx %u write idx %u>>",
Prefix,
RingInfo,
RingInfo->RingBuffer->Buffer,
@@ -229,13 +235,13 @@ static u32
CopyToRingBuffer(
RING_BUFFER_INFO *RingInfo,
u32 StartWriteOffset,
- void * Src,
+ void *Src,
u32 SrcLen);

static u32
CopyFromRingBuffer(
RING_BUFFER_INFO *RingInfo,
- void * Dest,
+ void *Dest,
u32 DestLen,
u32 StartReadOffset);

@@ -256,15 +262,15 @@ void RingBufferGetDebugInfo(RING_BUFFER_INFO *RingInfo,
u32 bytesAvailToWrite;
u32 bytesAvailToRead;

- if (RingInfo->RingBuffer)
- {
- GetRingBufferAvailBytes(RingInfo, &bytesAvailToRead, &bytesAvailToWrite);
+ if (RingInfo->RingBuffer) {
+ GetRingBufferAvailBytes(RingInfo,
+ &bytesAvailToRead,
+ &bytesAvailToWrite);

DebugInfo->BytesAvailToRead = bytesAvailToRead;
DebugInfo->BytesAvailToWrite = bytesAvailToWrite;
DebugInfo->CurrentReadIndex = RingInfo->RingBuffer->ReadIndex;
DebugInfo->CurrentWriteIndex = RingInfo->RingBuffer->WriteIndex;
-
DebugInfo->CurrentInterruptMask = RingInfo->RingBuffer->InterruptMask;
}
}
@@ -299,7 +305,7 @@ int RingBufferInit(RING_BUFFER_INFO *RingInfo, void *Buffer, u32 BufferLen)

memset(RingInfo, 0, sizeof(RING_BUFFER_INFO));

- RingInfo->RingBuffer = (RING_BUFFER*)Buffer;
+ RingInfo->RingBuffer = (RING_BUFFER *)Buffer;
RingInfo->RingBuffer->ReadIndex = RingInfo->RingBuffer->WriteIndex = 0;

RingInfo->RingSize = BufferLen;
@@ -319,7 +325,7 @@ Description:
Cleanup the ring buffer

--*/
-void RingBufferCleanup(RING_BUFFER_INFO* RingInfo)
+void RingBufferCleanup(RING_BUFFER_INFO *RingInfo)
{
}

@@ -335,14 +341,14 @@ Description:
int RingBufferWrite(RING_BUFFER_INFO *OutRingInfo,
struct scatterlist *sglist, u32 sgcount)
{
- int i=0;
+ int i = 0;
u32 byteAvailToWrite;
u32 byteAvailToRead;
- u32 totalBytesToWrite=0;
+ u32 totalBytesToWrite = 0;

struct scatterlist *sg;
volatile u32 nextWriteLocation;
- u64 prevIndices=0;
+ u64 prevIndices = 0;
unsigned long flags;

DPRINT_ENTER(VMBUS);
@@ -356,17 +362,23 @@ int RingBufferWrite(RING_BUFFER_INFO *OutRingInfo,

spin_lock_irqsave(&OutRingInfo->ring_lock, flags);

- GetRingBufferAvailBytes(OutRingInfo, &byteAvailToRead, &byteAvailToWrite);
+ GetRingBufferAvailBytes(OutRingInfo,
+ &byteAvailToRead,
+ &byteAvailToWrite);

DPRINT_DBG(VMBUS, "Writing %u bytes...", totalBytesToWrite);

/* DumpRingInfo(OutRingInfo, "BEFORE "); */

- /* If there is only room for the packet, assume it is full. Otherwise, the next time around, we think the ring buffer */
+ /* If there is only room for the packet, assume it is full. */
+ /* Otherwise, the next time around, we think the ring buffer */
/* is empty since the read index == write index */
- if (byteAvailToWrite <= totalBytesToWrite)
- {
- DPRINT_DBG(VMBUS, "No more space left on outbound ring buffer (needed %u, avail %u)", totalBytesToWrite, byteAvailToWrite);
+ if (byteAvailToWrite <= totalBytesToWrite) {
+ DPRINT_DBG(VMBUS,
+ "No more space left on outbound ring buffer "
+ "(needed %u, avail %u)",
+ totalBytesToWrite,
+ byteAvailToWrite);

spin_unlock_irqrestore(&OutRingInfo->ring_lock, flags);

@@ -423,17 +435,22 @@ int RingBufferPeek(RING_BUFFER_INFO *InRingInfo, void *Buffer, u32 BufferLen)
{
u32 bytesAvailToWrite;
u32 bytesAvailToRead;
- u32 nextReadLocation=0;
+ u32 nextReadLocation = 0;
unsigned long flags;

spin_lock_irqsave(&InRingInfo->ring_lock, flags);

- GetRingBufferAvailBytes(InRingInfo, &bytesAvailToRead, &bytesAvailToWrite);
+ GetRingBufferAvailBytes(InRingInfo,
+ &bytesAvailToRead,
+ &bytesAvailToWrite);

/* Make sure there is something to read */
- if (bytesAvailToRead < BufferLen )
- {
- /* DPRINT_DBG(VMBUS, "got callback but not enough to read <avail to read %d read size %d>!!", bytesAvailToRead, BufferLen); */
+ if (bytesAvailToRead < BufferLen) {
+ /* DPRINT_DBG(VMBUS,
+ "got callback but not enough to read "
+ "<avail to read %d read size %d>!!",
+ bytesAvailToRead,
+ BufferLen); */

spin_unlock_irqrestore(&InRingInfo->ring_lock, flags);

@@ -444,9 +461,9 @@ int RingBufferPeek(RING_BUFFER_INFO *InRingInfo, void *Buffer, u32 BufferLen)
nextReadLocation = GetNextReadLocation(InRingInfo);

nextReadLocation = CopyFromRingBuffer(InRingInfo,
- Buffer,
- BufferLen,
- nextReadLocation);
+ Buffer,
+ BufferLen,
+ nextReadLocation);

spin_unlock_irqrestore(&InRingInfo->ring_lock, flags);

@@ -468,24 +485,29 @@ int RingBufferRead(RING_BUFFER_INFO *InRingInfo, void *Buffer,
{
u32 bytesAvailToWrite;
u32 bytesAvailToRead;
- u32 nextReadLocation=0;
- u64 prevIndices=0;
+ u32 nextReadLocation = 0;
+ u64 prevIndices = 0;
unsigned long flags;

ASSERT(BufferLen > 0);

spin_lock_irqsave(&InRingInfo->ring_lock, flags);

- GetRingBufferAvailBytes(InRingInfo, &bytesAvailToRead, &bytesAvailToWrite);
+ GetRingBufferAvailBytes(InRingInfo,
+ &bytesAvailToRead,
+ &bytesAvailToWrite);

DPRINT_DBG(VMBUS, "Reading %u bytes...", BufferLen);

/* DumpRingInfo(InRingInfo, "BEFORE "); */

/* Make sure there is something to read */
- if (bytesAvailToRead < BufferLen )
- {
- DPRINT_DBG(VMBUS, "got callback but not enough to read <avail to read %d read size %d>!!", bytesAvailToRead, BufferLen);
+ if (bytesAvailToRead < BufferLen) {
+ DPRINT_DBG(VMBUS,
+ "got callback but not enough to read "
+ "<avail to read %d read size %d>!!",
+ bytesAvailToRead,
+ BufferLen);

spin_unlock_irqrestore(&InRingInfo->ring_lock, flags);

@@ -495,17 +517,18 @@ int RingBufferRead(RING_BUFFER_INFO *InRingInfo, void *Buffer,
nextReadLocation = GetNextReadLocationWithOffset(InRingInfo, Offset);

nextReadLocation = CopyFromRingBuffer(InRingInfo,
- Buffer,
- BufferLen,
- nextReadLocation);
+ Buffer,
+ BufferLen,
+ nextReadLocation);

nextReadLocation = CopyFromRingBuffer(InRingInfo,
- &prevIndices,
- sizeof(u64),
- nextReadLocation);
+ &prevIndices,
+ sizeof(u64),
+ nextReadLocation);

/* Make sure all reads are done before we update the read index since */
- /* the writer may start writing to the read area once the read index is updated */
+ /* the writer may start writing to the read area once the read index */
+ /*is updated */
mb();

/* Update the read index */
@@ -533,25 +556,22 @@ static u32
CopyToRingBuffer(
RING_BUFFER_INFO *RingInfo,
u32 StartWriteOffset,
- void * Src,
+ void *Src,
u32 SrcLen)
{
- void * ringBuffer=GetRingBuffer(RingInfo);
- u32 ringBufferSize=GetRingBufferSize(RingInfo);
+ void *ringBuffer = GetRingBuffer(RingInfo);
+ u32 ringBufferSize = GetRingBufferSize(RingInfo);
u32 fragLen;

- if (SrcLen > ringBufferSize - StartWriteOffset) /* wrap-around detected! */
- {
+ /* wrap-around detected! */
+ if (SrcLen > ringBufferSize - StartWriteOffset) {
DPRINT_DBG(VMBUS, "wrap-around detected!");

fragLen = ringBufferSize - StartWriteOffset;
memcpy(ringBuffer + StartWriteOffset, Src, fragLen);
memcpy(ringBuffer, Src + fragLen, SrcLen - fragLen);
- }
- else
- {
+ } else
memcpy(ringBuffer + StartWriteOffset, Src, SrcLen);
- }

StartWriteOffset += SrcLen;
StartWriteOffset %= ringBufferSize;
@@ -573,28 +593,27 @@ Description:
static u32
CopyFromRingBuffer(
RING_BUFFER_INFO *RingInfo,
- void * Dest,
+ void *Dest,
u32 DestLen,
u32 StartReadOffset)
{
- void * ringBuffer=GetRingBuffer(RingInfo);
- u32 ringBufferSize=GetRingBufferSize(RingInfo);
+ void *ringBuffer = GetRingBuffer(RingInfo);
+ u32 ringBufferSize = GetRingBufferSize(RingInfo);

u32 fragLen;

- if (DestLen > ringBufferSize - StartReadOffset) /* wrap-around detected at the src */
- {
+ /* wrap-around detected at the src */
+ if (DestLen > ringBufferSize - StartReadOffset) {
DPRINT_DBG(VMBUS, "src wrap-around detected!");

fragLen = ringBufferSize - StartReadOffset;

memcpy(Dest, ringBuffer + StartReadOffset, fragLen);
memcpy(Dest + fragLen, ringBuffer, DestLen - fragLen);
- }
- else
- {
+ } else
+
memcpy(Dest, ringBuffer + StartReadOffset, DestLen);
- }
+

StartReadOffset += DestLen;
StartReadOffset %= ringBufferSize;
--
1.6.3.3

== 2 of 2 ==
Date: Wed, Feb 3 2010 8:00 am
From: Greg KH

On Wed, Feb 03, 2010 at 03:34:27PM +0000, CB wrote:
> >From a545464b8c98ca1f2b35b6b701842bca16a6cccf Mon Sep 17 00:00:00 2001
> From: C. Bartlett <c-bartlett@hotmail.co.uk>
> Date: Wed, 3 Feb 2010 15:08:17 +0000
> Subject: [PATCH] Staging: hv: fix various coding style issues in RingBuffer.c
> This is a patch to the RingBuffer.c file that corrects various coding style warnings and errors found by checkpatch.pl
> Signed-off-by: Craig Bartlett <c-bartlett@hotmail.co.uk>

I'd really like to not take this patch, because this code should just be
replaced entirely with the in-kernel ringbuffer data structure instead
(as explained in the drivers/staging/hv/TODO file).

So could you work on that instead? That way we can just delete this
file entirely, which would be best.

thanks,

greg k-h
--
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: alpha: PTR_ERR overwrites -EINVAL in syscall osf_mount
http://groups.google.com/group/linux.kernel/t/16fdd0b211d48292?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 3 2010 7:50 am
From: Roel Kluin

The initial -EINVAL value is overwritten by `retval = PTR_ERR(name)'.
If this isn't an error pointer and typenr is not 1, 6 or 9, then
this retval, a pointer cast to a long, is returned.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Was this intended? Not sure whether this can occur, found by code
analysis.

diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index 62619f2..53c213f 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -361,7 +361,7 @@ osf_procfs_mount(char *dirname, struct procfs_args __user *args, int flags)
SYSCALL_DEFINE4(osf_mount, unsigned long, typenr, char __user *, path,
int, flag, void __user *, data)
{
- int retval = -EINVAL;
+ int retval;
char *name;

name = getname(path);
@@ -379,6 +379,7 @@ SYSCALL_DEFINE4(osf_mount, unsigned long, typenr, char __user *, path,
retval = osf_procfs_mount(name, data, flag);
break;
default:
+ retval = -EINVAL;
printk("osf_mount(%ld, %x)\n", typenr, flag);
}
putname(name);
--
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: Wed, Feb 3 2010 8:00 am
From: Matt Turner

On Wed, Feb 3, 2010 at 10:49 AM, Roel Kluin <roel.kluin@gmail.com> wrote:
> The initial -EINVAL value is overwritten by `retval = PTR_ERR(name)'.
> If this isn't an error pointer and typenr is not 1, 6 or 9, then
> this retval, a pointer cast to a long, is returned.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> Was this intended? Not sure whether this can occur, found by code
> analysis.
>
> diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
> index 62619f2..53c213f 100644
> --- a/arch/alpha/kernel/osf_sys.c
> +++ b/arch/alpha/kernel/osf_sys.c
> @@ -361,7 +361,7 @@ osf_procfs_mount(char *dirname, struct procfs_args __user *args, int flags)
> SYSCALL_DEFINE4(osf_mount, unsigned long, typenr, char __user *, path,
> int, flag, void __user *, data)
> {
> - int retval = -EINVAL;
> + int retval;
> char *name;
>
> name = getname(path);
> @@ -379,6 +379,7 @@ SYSCALL_DEFINE4(osf_mount, unsigned long, typenr, char __user *, path,
> retval = osf_procfs_mount(name, data, flag);
> break;
> default:
> + retval = -EINVAL;
> printk("osf_mount(%ld, %x)\n", typenr, flag);
> }
> putname(name);
>

Looks like a bug to me as well. Can anyone else confirm?

Matt Turner
--
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: kconfig: Look in both /bin and /sbin for lsmod in streamline_config.pl
http://groups.google.com/group/linux.kernel/t/813d37d80464f6e5?hl=en
==============================================================================

== 1 of 5 ==
Date: Wed, Feb 3 2010 7:50 am
From: Steven Rostedt

From: Steven Rostedt <srostedt@redhat.com>

Distributions now have lsmod in /bin instead of /sbin. But to handle
both cases, we look for it in /sbin /bin /usr/bin and /usr/sbin.
If lsmod is not found in any of those paths, it defaults to use
just lsmod and hopes that it lies in the path of the user.

Tested-by: Xavier Chantry <shiningxc@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
scripts/kconfig/streamline_config.pl | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/scripts/kconfig/streamline_config.pl b/scripts/kconfig/streamline_config.pl
index 9e66fa8..d7f7db7 100644
--- a/scripts/kconfig/streamline_config.pl
+++ b/scripts/kconfig/streamline_config.pl
@@ -264,7 +264,20 @@ foreach my $makefile (@makefiles) {
my %modules;

# see what modules are loaded on this system
-open(LIN,"/sbin/lsmod|") || die "Cant lsmod";
+my $lsmod;
+
+foreach $dir ( ("/sbin", "/bin", "/usr/sbin", "/usr/bin") ) {
+ if ( -x "$dir/lsmod" ) {
+ $lsmod = "$dir/lsmod";
+ last;
+ }
+}
+if (!defined($lsmod)) {
+ # try just the path
+ $lsmod = "lsmod";
+}
+
+open(LIN,"$lsmod|") || die "Can not call lsmod with $lsmod";
while (<LIN>) {
next if (/^Module/); # Skip the first line.
if (/^(\S+)/) {
--
1.6.5

== 2 of 5 ==
Date: Wed, Feb 3 2010 7:50 am
From: Steven Rostedt

From: Steven Rostedt <srostedt@redhat.com>

Doing the following:

make LSMOD=file localmodconfig

Will make the streamline-config code use the given file instead of
lsmod. If the file is an executable, it will execute it, otherwise
it will read it as text.

make LSMOD=/my/local/path/lsmod localmodconfig

The above will execute the lsmod in /my/local/path instead of the
lsmods that may be located elsewhere.

make LSMOD=embedded_board_lsmod localmodconfig

The above will read the "embedded_board_lsmod" as a text file. This
is useful if you are doing a cross compile and need to run the
config against modules that exist on an embedded device.

Note, if the LSMOD= file does is not a path, it will add the
path to the object directory. That is, the above example will look
for "embedded_board_lsmod" in the directory that the binary will
be built in (the O=dir directory).

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

On branch config/linus
---
scripts/kconfig/Makefile | 13 +++++++++-
scripts/kconfig/streamline_config.pl | 38 ++++++++++++++++++++++++---------
2 files changed, 38 insertions(+), 13 deletions(-)

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 006c96f..85b9065 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -30,9 +30,18 @@ silentoldconfig: $(obj)/conf
$(Q)mkdir -p include/generated
$< -s $(Kconfig)

+# if no path is given, then use src directory to find file
+ifdef LSMOD
+LSMOD_F = $(shell if [ `basename $(LSMOD)` == $(LSMOD) ]; then \
+ echo $(objtree)/$(LSMOD); \
+ else \
+ echo $(LSMOD); \
+ fi)
+endif
+
localmodconfig: $(obj)/streamline_config.pl $(obj)/conf
$(Q)mkdir -p include/generated
- $(Q)perl $< $(srctree) $(Kconfig) > .tmp.config
+ $(Q)perl $< $(srctree) $(Kconfig) $(LSMOD_F) > .tmp.config
$(Q)if [ -f .config ]; then \
cmp -s .tmp.config .config || \
(mv -f .config .config.old.1; \
@@ -47,7 +56,7 @@ localmodconfig: $(obj)/streamline_config.pl $(obj)/conf

localyesconfig: $(obj)/streamline_config.pl $(obj)/conf
$(Q)mkdir -p include/generated
- $(Q)perl $< $(srctree) $(Kconfig) > .tmp.config
+ $(Q)perl $< $(srctree) $(Kconfig) $(LSMOD_F) > .tmp.config
$(Q)sed -i s/=m/=y/ .tmp.config
$(Q)if [ -f .config ]; then \
cmp -s .tmp.config .config || \
diff --git a/scripts/kconfig/streamline_config.pl b/scripts/kconfig/streamline_config.pl
index d7f7db7..afbd54a 100644
--- a/scripts/kconfig/streamline_config.pl
+++ b/scripts/kconfig/streamline_config.pl
@@ -113,6 +113,7 @@ find_config;
# Get the build source and top level Kconfig file (passed in)
my $ksource = $ARGV[0];
my $kconfig = $ARGV[1];
+my $lsmod_file = $ARGV[2];

my @makefiles = `find $ksource -name Makefile`;
my %depends;
@@ -263,21 +264,36 @@ foreach my $makefile (@makefiles) {

my %modules;

-# see what modules are loaded on this system
-my $lsmod;
-
-foreach $dir ( ("/sbin", "/bin", "/usr/sbin", "/usr/bin") ) {
- if ( -x "$dir/lsmod" ) {
- $lsmod = "$dir/lsmod";
- last;
+if (defined($lsmod_file)) {
+ if ( ! -f $lsmod_file) {
+ die "$lsmod_file not found";
+ }
+ if ( -x $lsmod_file) {
+ # the file is executable, run it
+ open(LIN, "$lsmod_file|");
+ } else {
+ # Just read the contents
+ open(LIN, "$lsmod_file");
}
+} else {
+
+ # see what modules are loaded on this system
+ my $lsmod;
+
+ foreach $dir ( ("/sbin", "/bin", "/usr/sbin", "/usr/bin") ) {
+ if ( -x "$dir/lsmod" ) {
+ $lsmod = "$dir/lsmod";
+ last;
+ }
}
-if (!defined($lsmod)) {
- # try just the path
- $lsmod = "lsmod";
+ if (!defined($lsmod)) {
+ # try just the path
+ $lsmod = "lsmod";
+ }
+
+ open(LIN,"$lsmod|") || die "Can not call lsmod with $lsmod";
}

-open(LIN,"$lsmod|") || die "Can not call lsmod with $lsmod";
while (<LIN>) {
next if (/^Module/); # Skip the first line.
if (/^(\S+)/) {
--
1.6.5

== 3 of 5 ==
Date: Wed, Feb 3 2010 7:50 am
From: Steven Rostedt

From: Steven Rostedt <srostedt@redhat.com>

The streamline_config.pl misses the if conditions for checking
dependencies. For Kconfigs with the following construct:

if MEDIA_SUPPORT

config VIDEO_DEV

[...]

If VIDEO_DEV was enabled, the script will miss the fact that MEDIA_SUPPORT
is also needed.

This patch changes streamline_config.pl to include if conditions into
the dependencies of configs.

Reported-by: Anton Blanchard <anton@sambo.org>
Tested-by: Anton Blanchard <anton@sambo.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
scripts/kconfig/streamline_config.pl | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/scripts/kconfig/streamline_config.pl b/scripts/kconfig/streamline_config.pl
index 0d80082..9e66fa8 100644
--- a/scripts/kconfig/streamline_config.pl
+++ b/scripts/kconfig/streamline_config.pl
@@ -121,6 +121,8 @@ my %prompts;
my %objects;
my $var;
my $cont = 0;
+my $iflevel = 0;
+my @ifdeps;

# prevent recursion
my %read_kconfigs;
@@ -146,6 +148,15 @@ sub read_kconfig {
$state = "NEW";
$config = $1;

+ for (my $i = 0; $i < $iflevel; $i++) {
+ if ($i) {
+ $depends{$config} .= " " . $ifdeps[$i];
+ } else {
+ $depends{$config} = $ifdeps[$i];
+ }
+ $state = "DEP";
+ }
+
# collect the depends for the config
} elsif ($state eq "NEW" && /^\s*depends\s+on\s+(.*)$/) {
$state = "DEP";
@@ -166,6 +177,21 @@ sub read_kconfig {
# note if the config has a prompt
$prompt{$config} = 1;

+ # Check for if statements
+ } elsif (/^if\s+(.*\S)\s*$/) {
+ my $deps = $1;
+ # remove beginning and ending non text
+ $deps =~ s/^[^a-zA-Z0-9_]*//;
+ $deps =~ s/[^a-zA-Z0-9_]*$//;
+
+ my @deps = split /[^a-zA-Z0-9_]+/, $deps;
+
+ $ifdeps[$iflevel++] = join ':', @deps;
+
+ } elsif (/^endif/) {
+
+ $iflevel-- if ($iflevel);
+
# stop on "help"
} elsif (/^\s*help\s*$/) {
$state = "NONE";
--
1.6.5

== 4 of 5 ==
Date: Wed, Feb 3 2010 8:00 am
From: Steven Rostedt

From: Steven Rostedt <srostedt@redhat.com>

If someone downloads a brand new kernel and runs localmodconfig or
localyesconfig, the ending result will report:

*** Error during update of the kernel configuration.

This is because localmodconfig and localyesconfig must create the
include/generated directory to place the autoconf.h file.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
scripts/kconfig/Makefile | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 999e8a7..006c96f 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -31,6 +31,7 @@ silentoldconfig: $(obj)/conf
$< -s $(Kconfig)

localmodconfig: $(obj)/streamline_config.pl $(obj)/conf
+ $(Q)mkdir -p include/generated
$(Q)perl $< $(srctree) $(Kconfig) > .tmp.config
$(Q)if [ -f .config ]; then \
cmp -s .tmp.config .config || \
@@ -45,6 +46,7 @@ localmodconfig: $(obj)/streamline_config.pl $(obj)/conf
$(Q)rm -f .tmp.config

localyesconfig: $(obj)/streamline_config.pl $(obj)/conf
+ $(Q)mkdir -p include/generated
$(Q)perl $< $(srctree) $(Kconfig) > .tmp.config
$(Q)sed -i s/=m/=y/ .tmp.config
$(Q)if [ -f .config ]; then \
--
1.6.5

== 5 of 5 ==
Date: Wed, Feb 3 2010 8:10 am
From: Michal Marek

On Wed, Feb 03, 2010 at 10:46:09AM -0500, Steven Rostedt wrote:
> +# if no path is given, then use src directory to find file
> +ifdef LSMOD
> +LSMOD_F = $(shell if [ `basename $(LSMOD)` == $(LSMOD) ]; then \
> + echo $(objtree)/$(LSMOD); \
> + else \
> + echo $(LSMOD); \
> + fi)
> +endif

You can do this within make like:

ifdef LSMOD
LSMOD_F := $(LSMOD)
ifeq ($(findstring /,$(LSMOD)),)
LSMOD_F := $(objtree)/$(LSMOD)
endif
endif

Michal
--
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: slub: ARCH_SLAB_MINALIGN defaults to 8 on x86_32. is this too big?
http://groups.google.com/group/linux.kernel/t/90562c9ef16cf2a0?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 7:50 am
From: Christoph Lameter

On Wed, 3 Feb 2010, Richard Kennedy wrote:

> slub.c sets the default value of ARCH_SLAB_MINALIGN to sizeof(unsigned
> long long) if the architecture didn't already override it.
>
> And as x86_32 doesn't set a value this means that slab objects get
> aligned to 8 bytes, potentially wasting 4 bytes per object. Slub forces
> objects to be aligned to sizeof(void *) anyway, but I don't see that
> there is any need for it to be 8 on 32bits.

Note that 64 bit entities may exist even under 32 bit (llong) that need
to be aligned properly.

struct buffer_head contains a sector_t which is 64 bit so you should align
to an 8 byte boundary.

> I'm working on a patch to pack more buffer_heads into each kmem_cache
> slab page.
> On 32 bits the structure size is 52 bytes and with the alignment applied
> I end up with a slab of 73 x 56 byte objects. However, if the minimum
> alignment was sizeof(void *) then I'd get 78 x 52 byte objects. So there
> is quite a memory saving to be had in changing this.

SLUB is not restricted to order 0 pages and can use order 1 or 2 pages as
long as this reduces the memory footprint (byte wastage in a slab page is
reduced) and as long as the kernel has contiguous memory available. It
will use order 0 when memory is fragmented.

> Can I define a ARCH_SLAB_MINALIGN in x86_64 to sizeof(void *) ?
> or would it be ok to change the default in slub.c to sizeof(void *) ?
>
> Or am I missing something ?

I'd say leave it alone.
--
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: bitops: compile time optimization for hweight_long(CONSTANT)
http://groups.google.com/group/linux.kernel/t/f58ac10e7917a328?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 3 2010 7:50 am
From: Andrew Morton

On Wed, 03 Feb 2010 16:15:57 +0100 Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-02-03 at 07:08 -0800, Andrew Morton wrote:
> > On Wed, 3 Feb 2010 21:39:51 +0800 Wu Fengguang <fengguang.wu@intel.com> wrote:
> >
> > > Is there an official lowest GCC version that Linux supports?
> >
> > Documentation/Changes says gcc-3.2.
>
> Anyway, its not like that macro I used isn't straight forward. Not much
> a builtin can do better.
>
> The only benefit the builtin has is possibly use machine popcnt
> instructions but we already deal with that in the kernel.

We didn't deal with it on every architecture, which is something which
the compiler extension takes care of.

In fact I can't find anywhere where we dealt with it on x86.
--
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: Wed, Feb 3 2010 7:50 am
From: Peter Zijlstra

On Wed, 2010-02-03 at 07:42 -0800, Andrew Morton wrote:
> On Wed, 03 Feb 2010 16:15:57 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
>
> > On Wed, 2010-02-03 at 07:08 -0800, Andrew Morton wrote:
> > > On Wed, 3 Feb 2010 21:39:51 +0800 Wu Fengguang <fengguang.wu@intel.com> wrote:
> > >
> > > > Is there an official lowest GCC version that Linux supports?
> > >
> > > Documentation/Changes says gcc-3.2.
> >
> > Anyway, its not like that macro I used isn't straight forward. Not much
> > a builtin can do better.
> >
> > The only benefit the builtin has is possibly use machine popcnt
> > instructions but we already deal with that in the kernel.
>
> We didn't deal with it on every architecture, which is something which
> the compiler extension takes care of.
>
> In fact I can't find anywhere where we dealt with it on x86.

>From what I know the popcnt ins on x86 is relatively new, hpa was going
to look at supporting it using alternatives.

==============================================================================
TOPIC: [RFC] 512K readahead size with thrashing safe readahead
http://groups.google.com/group/linux.kernel/t/96ba73a9249e5c25?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 8:00 am
From: Vivek Goyal

On Wed, Feb 03, 2010 at 10:24:54AM -0500, Vivek Goyal wrote:
> On Wed, Feb 03, 2010 at 02:27:56PM +0800, Wu Fengguang wrote:
> > Vivek,
> >
> > On Wed, Feb 03, 2010 at 06:38:03AM +0800, Vivek Goyal wrote:
> > > On Tue, Feb 02, 2010 at 11:28:35PM +0800, Wu Fengguang wrote:
> > > > Andrew,
> > > >
> > > > This is to lift default readahead size to 512KB, which I believe yields
> > > > more I/O throughput without noticeably increasing I/O latency for today's HDD.
> > > >
> > >
> > > Hi Fengguang,
> > >
> > > I was doing a quick test with the patches. I was using fio to run some
> > > sequential reader threads. I have got one access to one Lun from an HP
> > > EVA. In my case it looks like with the patches throughput has come down.
> >
> > Thank you for the quick testing!
> >
> > This patchset does 3 things:
> >
> > 1) 512K readahead size
> > 2) new readahead algorithms
> > 3) new readahead tracing/stats interfaces
> >
> > (1) will impact performance, while (2) _might_ impact performance in
> > case of bugs.
> >
> > Would you kindly retest the patchset with readahead size manually set
> > to 128KB? That would help identify the root cause of the performance
> > drop:
> >
> > DEV=sda
> > echo 128 > /sys/block/$DEV/queue/read_ahead_kb
> >
>
> I have got two paths to the HP EVA and got multipath device setup(dm-3). I
> noticed with vanilla kernel read_ahead_kb=128 after boot but with your patches
> applied it is set to 4. So looks like something went wrong with device
> size/capacity detection hence wrong defaults. Manually setting
> read_ahead_kb=512, got me better performance as compare to vanilla kernel.
>

I put a printk in add_disk and noticed that for multipath device get_capacity() is returning 0 and that's why ra_pages is being set to 1.

Thanks
Vivek
--
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] kconfig: Updates to localmodconfig
http://groups.google.com/group/linux.kernel/t/b24eea2db7e3d8f1?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 8:00 am
From: Steven Rostedt

I'm posting the following patches for review. I've added these
to go into linux-next. They can be found in the git repo shown
below:

git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-kconfig.git
for-linus-2

Steven Rostedt (4):
kconfig: Create include/generated for localmodconfig
kconfig: Check for if conditions in Kconfig for localmodconfig
kconfig: Look in both /bin and /sbin for lsmod in streamline_config.pl
kconfig: Add LSMOD=file to override the lsmod for localmodconfig

----
scripts/kconfig/Makefile | 15 +++++++-
scripts/kconfig/streamline_config.pl | 59 ++++++++++++++++++++++++++++++++-
2 files changed, 70 insertions(+), 4 deletions(-)
--
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: dvb: return -ENOMEM if kzalloc failed in dvb_usb_device_init()
http://groups.google.com/group/linux.kernel/t/0d3d1e42dcaac9b8?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 3 2010 8:10 am
From: roel kluin

On Tue, Feb 2, 2010 at 3:29 PM, Oliver Neukum <oliver@neukum.org> wrote:
> Am Dienstag, 2. Februar 2010 15:29:46 schrieb Roel Kluin:
>> If in a cold state and the download succeeded ret is zero, but we
>> should return -ENOMEM.
>>
>> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
>> ---
>> Or shouldn't we?
>
> We should and we do if cold==0.
> The bug is caused by this:
>
> if (cold) {
> info("found a '%s' in cold state, will try to load a firmware",desc->name);
> ret = dvb_usb_download_firmware(udev,props);
> if (!props->no_reconnect || ret != 0)
> return ret;
> }
>
> which overwrites ret

Is that an ack or do you want me to add an int (e.g. rc) that
handles the dvb_usb_download_firmware() return value?

Roel
--
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: Wed, Feb 3 2010 8:20 am
From: Oliver Neukum

Am Mittwoch, 3. Februar 2010 17:02:49 schrieb roel kluin:
> > The bug is caused by this:
> >
> > if (cold) {
> > info("found a '%s' in cold state, will try to load a firmware",desc->name);
> > ret = dvb_usb_download_firmware(udev,props);
> > if (!props->no_reconnect || ret != 0)
> > return ret;
> > }
> >
> > which overwrites ret
>
> Is that an ack or do you want me to add an int (e.g. rc) that
> handles the dvb_usb_download_firmware() return value?

This is an ack with an additional comment that this function is in need of
a cleanup due to unnecessary subtlety.

Regards
Oliver
--
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: Improving OOM killer
http://groups.google.com/group/linux.kernel/t/389db2dcf6479d30?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 8:10 am
From: Minchan Kim

On Thu, 2010-02-04 at 00:00 +0900, Minchan Kim wrote:
> On Wed, 2010-02-03 at 17:55 +0530, Balbir Singh wrote:
> > * Lubos Lunak <l.lunak@suse.cz> [2010-02-03 13:10:27]:
> >> > I don't understand how this matters. Overcommit is memory for which address
> > > space has been allocated but not actual memory, right? Then that's exactly
> > > what I'm claiming is wrong and am trying to reverse. Currently OOM killer
> > > takes this into account because it uses VmSize, but IMO it shouldn't - if a
> > > process does malloc(400M) but then it uses only a tiny fraction of that, in
> > > the case of memory shortage killing that process does not solve anything in
> > > practice.
> >
> > We have a way of tracking commmitted address space, which is more
> > sensible than just allocating memory and is used for tracking
> > overcommit. I was suggesting that, that might be a better approach.
>
> Yes. It does make sense. At least total_vm doesn't care about
> MAP_NORESERVE case. But unfortunately, it's a per CPU not per Process.

Sorry for confusing. It was opposite. I slept :)
The commited as doesn't care about MAP_NORESERVE case.
But it definitely charges memory. so I think total_vm is better than
committed as if we really have to use vmsize heuristic continuously.

But I am not sure that i understand your point about overcommit policy.

--
Kind regards,
Minchan Kim

==============================================================================
TOPIC: kernel-shark: fix unitialized handle compile warnings
http://groups.google.com/group/linux.kernel/t/2ae6ffbd06a5c48a?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Feb 3 2010 8:10 am
From: John Kacur

On Mon, Feb 1, 2010 at 5:50 PM, Darren Hart <dvhltc@us.ibm.com> wrote:
> Signed-off-by: Darren Hart <dvhltc@us.ibm.com>
> ---
> kernel-shark.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel-shark.c b/kernel-shark.c
> index 9dedf48..222381c 100644
> --- a/kernel-shark.c
> +++ b/kernel-shark.c
> @@ -596,10 +596,10 @@ void kernel_shark(int argc, char **argv)
> if (ret >= 0)
> input_file = default_input_file;
> }
> - if (handle)
> - handle = tracecmd_open(input_file);
> + handle = tracecmd_open(input_file);
>
> - info->handle = handle;
> + if (handle)
> + info->handle = handle;
>
> /* --- Main window --- */
>
> --

This looks correct, but I'm wondering if it is safe to continue if the
call to tracecmd_open fails?
--
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 3 ==
Date: Wed, Feb 3 2010 8:10 am
From: John Kacur

On Mon, Feb 1, 2010 at 5:50 PM, Darren Hart <dvhltc@us.ibm.com> wrote:
> Signed-off-by: Darren Hart <dvhltc@us.ibm.com>
> ---
> trace-read.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/trace-read.c b/trace-read.c
> index a04c85b..5befaba 100644
> --- a/trace-read.c
> +++ b/trace-read.c
> @@ -216,7 +216,7 @@ static void read_rest(void)
> r = read(input_fd, buf, BUFSIZ);
> if (r > 0) {
> buf[r] = 0;
> - printf(buf);
> + printf("%s", buf);
> }
> } while (r > 0);
> }
> --
> 1.6.3.3
>

Oh! Obviously correct, thanks Darren.
--
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/

== 3 of 3 ==
Date: Wed, Feb 3 2010 8:20 am
From: Steven Rostedt

On Wed, 2010-02-03 at 11:17 -0500, Steven Rostedt wrote:
> andle)
> > > - handle = tracecmd_open(input_file);
> > > + handle = tracecmd_open(input_file);
> > >
> > > - info->handle = handle;
> > > + if (handle)
> > > + info->handle = handle;
> > >
> > > /* --- Main window --- */
> > >
> > > --
> >
> > This looks correct, but I'm wondering if it is safe to continue if the
> > call to tracecmd_open fails?
>
> Actually this patch is wrong. The real code should be:
>
> - if (handle)
> + if (input_file)

Looking at the context, this isn't enough. We should have had:

if (input_file)
info->handle = tracecmd_open(input_file);
else
info->handle = NULL;

-- Steve

==============================================================================
TOPIC: mxc: Core support for i.MX5 series of processors from Freescale
http://groups.google.com/group/linux.kernel/t/281ca1a532ca6d76?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 8:10 am
From: Rabin Vincent

On Tue, Feb 02, 2010 at 09:16:27PM -0800, Amit Kucheria wrote:
> diff --git a/arch/arm/mach-mx5/clock.c b/arch/arm/mach-mx5/clock.c
[...]
> +static struct clk_lookup lookups[] __initdata = {
> + _REGISTER_CLOCK("imx-uart.0", NULL, uart1_clk)
> + _REGISTER_CLOCK("imx-uart.1", NULL, uart2_clk)
> + _REGISTER_CLOCK("imx-uart.2", NULL, uart3_clk)
> + _REGISTER_CLOCK(NULL, "gpt", gpt_clk)
> + _REGISTER_CLOCK("fec.0", NULL, fec_clk)
> +};

This shouldn't be __initdata. clk_get() uses this, and modules may use
clk_get().

Rabin
--
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: obsolete config in kernel source (IP_ROUTE_PERVASIVE)
http://groups.google.com/group/linux.kernel/t/d12dd2ed499dffa4?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 8:10 am
From: Christoph Egger

Hi all!

As part of the VAMOS[0] research project at the University of
Erlangen we're checking referential integrity between kernel KConfig
options and in-code Conditional blocks.

According to my search CONFIG_IP_ROUTE_PERVASIVE is not
defined in any 2.4-2.6 kernel (not #define d and not in
KConfig). However some tiny piece of code still checks it. If this is
really a leftover (as I expect) it might be a good idea to actually
remove that unreachable bit of code.

Please keep me informed of this patch getting confirmed /
merged so we can keep track of it.

Regards

Christoph Egger

[0] http://vamos1.informatik.uni-erlangen.de/

==============================================================================
TOPIC: ARM: Change the mandatory barriers implementation
http://groups.google.com/group/linux.kernel/t/1873254b2b8984f3?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 8:20 am
From: Catalin Marinas

(I cc'ed LKML as well just in case I got the wrong semantics of the
mandatory barriers)

The mandatory barriers (mb, rmb, wmb) are used even on uniprocessor
systems for things like ordering Normal Non-cacheable memory accesses
with DMA transfer (via Device memory writes). The current implementation
uses dmb() for mb() and friends but this is not sufficient. The DMB only
ensures the ordering of accesses with regards to a single observer
accessing the same memory. If a DMA transfer is started by a write to
Device memory, the data to be transfered may not reach the main memory
(even if mapped as Normal Non-cacheable) before the device receives the
notification to begin the transfer. The only barrier that would help in
this situation is DSB which would completely drain the write buffers.

The patch also adds support for platform-defined barriers that can be
defined in mach/barriers.h. This is required by at least two platforms -
MSM and RealView (possible OMAP as well). On RealView with an outer
cache (PL310 for example) stores to Normal Non-cacheable memory are
buffered by the outer cache but the DSB doesn't go as far as this. A
separate L2x0 sync command is required (a store to Strongly Ordered
memory would do as well, similar to the MSM requirements and maybe
faster).

Note that the SMP barriers are not affected as they only deal with
ordering in Normal memory. There is however a situation with the use of
IPIs. A DMB is not enough to ensure that a write to Normal memory is
strictly ordered with respect to the IPI generation (and interrupt
handling). A solution is for the users of smp_call_function() to use a
mandatory barrier.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Daniel Walker <dwalker@codeaurora.org>
Cc: Larry Bassel <lbassel@quicinc.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/include/asm/system.h | 18 ++++++++----------
arch/arm/mm/Kconfig | 6 ++++++
2 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 058e7e9..477861d 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -138,14 +138,12 @@ extern unsigned int user_debug;
#define dmb() __asm__ __volatile__ ("" : : : "memory")

twitter

Wednesday, February 3, 2010

linux.kernel - 26 new messages in 16 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts