twitter: linux.kernel - 23 new messages in 13 topics

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

Today's topics:

* AlacrityVM guest drivers for 2.6.33 - 5 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/265f7bf4a9a1d92d?hl=en
* Ceph distributed file system client for 2.6.33 - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/da03a2a565e29bf7?hl=en
* nommu: implement vmap/vunmap with kmalloc - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d1f32572d97bd664?hl=en
* x86: do_debug && PTRACE_SINGLESTEP broken by 08d68323d1f0c34452e614263b212ca
556dae47f - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/253956bb28f9a94f?hl=en
* Driver core: export platform_device_register_data as a GPL symbol - 3
messages, 3 authors
http://groups.google.com/group/linux.kernel/t/af315ef92d8fba1e?hl=en
* 2.6.33-rc1: LZMA kernel fails to decompress - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ae7e95c77b222ba5?hl=en
* Fix BUILD_BUG_ON in fs/compat_ioctl.c to build with gcc 4.5 snapshot - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/c2edbc4556dba135?hl=en
* 2.6.33-rc1+ bisected (?) s2ram regression - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/d9bf4392ddf21b2f?hl=en
* fs/compat_ioctl.c: fix build error when !BLOCK - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b46853b9810837a2?hl=en
* 3c507.c: remove unused NULL pointer check - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c0bc6a27904ff335?hl=en
* x86: fix size for ex trampoline with 32bit - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7a95a362ae722346?hl=en
* xfs and block fixes for virtually indexed arches - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f6cf95c5b7d8e318?hl=en
* 2.6.33-rc1 build failure: copy_from_user() buffer size is not provably
correct - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e0b57a2b296b8356?hl=en

==============================================================================
TOPIC: AlacrityVM guest drivers for 2.6.33
http://groups.google.com/group/linux.kernel/t/265f7bf4a9a1d92d?hl=en
==============================================================================

== 1 of 5 ==
Date: Mon, Dec 21 2009 8:40 am
From: Anthony Liguori

On 12/21/2009 10:04 AM, Gregory Haskins wrote:
> No, B and C definitely are, but A is lacking. And the performance
> suffers as a result in my testing (vhost-net still throws a ton of exits
> as its limited by virtio-pci and only adds about 1Gb/s to virtio-u, far
> behind venet even with things like zero-copy turned off).
>

How does virtio-pci limit vhost-net? The only time exits should occur
are when the guest notifies the host that something has been placed on
the ring. Since vhost-net has no tx mitigation scheme right now, the
result may be that it's taking an io exit on every single packet but
this is orthogonal to virtio-pci.

Since virtio-pci supports MSI-X, there should be no IO exits on
host->guest notification other than EOI in the virtual APIC. This is a
light weight exit today and will likely disappear entirely with newer
hardware.

Regards,

Anthony Liguori
--
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 5 ==
Date: Mon, Dec 21 2009 8:50 am
From: Gregory Haskins

On 12/21/09 11:37 AM, Anthony Liguori wrote:
> On 12/21/2009 10:04 AM, Gregory Haskins wrote:
>> No, B and C definitely are, but A is lacking. And the performance
>> suffers as a result in my testing (vhost-net still throws a ton of exits
>> as its limited by virtio-pci and only adds about 1Gb/s to virtio-u, far
>> behind venet even with things like zero-copy turned off).
>>
>
> How does virtio-pci limit vhost-net? The only time exits should occur
> are when the guest notifies the host that something has been placed on
> the ring. Since vhost-net has no tx mitigation scheme right now, the
> result may be that it's taking an io exit on every single packet but
> this is orthogonal to virtio-pci.
>
> Since virtio-pci supports MSI-X, there should be no IO exits on
> host->guest notification other than EOI in the virtual APIC.

The very best you can hope to achieve is 1:1 EOI per signal (though
today virtio-pci is even worse than that). As I indicated above, I can
eliminate more than 50% of even the EOIs in trivial examples, and even
more as we scale up the number of devices or the IO load (or both).

> This is a
> light weight exit today and will likely disappear entirely with newer
> hardware.

By that argument, this is all moot. New hardware will likely obsolete
the need for venet or virtio-net anyway. The goal of my work is to
provide an easy to use framework for maximizing the IO transport _in
lieu_ of hardware acceleration. Software will always be leading here,
so we don't want to get into a pattern of waiting for new hardware to
cover poor software engineering. Its simply not necessary in most
cases. A little smart software design and a framework that allows it to
be easily exploited/reused is the best step forward, IMO.

Kind Regards,
-Greg

== 3 of 5 ==
Date: Mon, Dec 21 2009 8:50 am
From: Avi Kivity

On 12/21/2009 06:37 PM, Anthony Liguori wrote:
> Since virtio-pci supports MSI-X, there should be no IO exits on
> host->guest notification other than EOI in the virtual APIC. This is
> a light weight exit today and will likely disappear entirely with
> newer hardware.

I'm working on disappearing EOI exits on older hardware as well. Same
idea as the old TPR patching, without most of the magic.

--
error compiling committee.c: too many arguments to function

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

== 4 of 5 ==
Date: Mon, Dec 21 2009 9:00 am
From: Gregory Haskins

On 12/21/09 11:40 AM, Avi Kivity wrote:
> On 12/21/2009 06:37 PM, Anthony Liguori wrote:
>> Since virtio-pci supports MSI-X, there should be no IO exits on
>> host->guest notification other than EOI in the virtual APIC. This is
>> a light weight exit today and will likely disappear entirely with
>> newer hardware.
>
> I'm working on disappearing EOI exits on older hardware as well. Same
> idea as the old TPR patching, without most of the magic.
>

While I applaud any engineering effort that results in more optimal
execution, if you are talking about what we have discussed in the past
its not quite in the same league as my proposal.

You are talking about the ability to optimize the final EOI if there are
no pending interrupts remaining, right? The problem with this approach
is it addresses the wrong side of the curve: That is, it optimizes the
code as its about to go io-idle. You still have to take an extra exit
for each injection during the heat of battle, which is when you actually
need it most.

To that front, what I have done is re-used the lockless shared-memory
concept for even "interrupt injection". Lockless shared-memory rings
have the property that both producer and consumer can simultaneously
manipulate the ring. So what we do in alacrityvm is deliver shm-signals
(shm-signal == "interrupt" in vbus) over a ring so that the host can
inject a signal to a running vcpu and a vcpu can complete an
ack/re-inject cycle directly from vcpu context. Therefore, we only need
a physical IDT injection when the vcpu is io-idle transitioning to
io-busy, and remain completely in parallel guest/host context until we
go idle again.

That said, your suggestion would play nicely with the above mentioned
scheme, so I look forward to seeing it in the tree. Feel free to send
me patches for testing.

Kind Regards,
-Greg

== 5 of 5 ==
Date: Mon, Dec 21 2009 9:10 am
From: Avi Kivity

On 12/21/2009 06:56 PM, Gregory Haskins wrote:
>> I'm working on disappearing EOI exits on older hardware as well. Same
>> idea as the old TPR patching, without most of the magic.
>>
>>
> While I applaud any engineering effort that results in more optimal
> execution, if you are talking about what we have discussed in the past
> its not quite in the same league as my proposal.
>

I don't doubt this for a minute.

> You are talking about the ability to optimize the final EOI if there are
> no pending interrupts remaining, right? The problem with this approach
> is it addresses the wrong side of the curve: That is, it optimizes the
> code as its about to go io-idle. You still have to take an extra exit
> for each injection during the heat of battle, which is when you actually
> need it most.
>

No, it's completely orthogonal. An interrupt is injected, the handler
disables further interrupts and EOIs, then schedules the rest of the
handling code. So long as there as packets in the ring interrupts won't
be enabled and hence there won't be any reinjections.

Different interrupt sources still need different interrupts, but as all
of your tests have been single-interface, this can't be the reason for
your performance.

--
error compiling committee.c: too many arguments to function

==============================================================================
TOPIC: Ceph distributed file system client for 2.6.33
http://groups.google.com/group/linux.kernel/t/da03a2a565e29bf7?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Dec 21 2009 8:50 am
From: Sage Weil

On Sat, 19 Dec 2009, Andi Kleen wrote:

> Jim Garlick <garlick@llnl.gov> writes:
> >
> > Ceph is new and experimental so you're not going to see production shops
>
> One issue with ceph is that I'm not sure it has any users at all.
> The mailing list seems to be pretty much dead?
> On a philosophical area I agree that network file systems are
> definitely an area that could need some more improvements.

The list is slow. The developers all work in the same office, so most of
the technical discussion ends up face to face (we're working on moving
more of it to the list). I also tend to send users actively testing it to
the irc channel.

That said, there aren't many active users. I see lots of interested
people lurking on the list and 'waiting for stability,' but I think the
prospect of testing an unstable cluster fs is much more daunting than a
local one.

If you want stability, then it's probably too early to merge. If you want
active users, that essentially hinges on stability too. But if it's
interest in/demand for an alternative distributed fs, then the sooner it's
merged the better.

From my point of view merging now will be a bit rockier with coordinating
releases, bug fixes, and dealing with any unforseen client side changes,
but I think it'll be worth it. OTOH, another release cycle will bring
greater stability and better first impressions.

sage
--
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: Mon, Dec 21 2009 8:50 am
From: Sage Weil

On Sat, 19 Dec 2009, Valdis.Kletnieks@vt.edu wrote:

> On Fri, 18 Dec 2009 12:54:02 PST, Sage Weil said:
> > I would still like to see ceph merged for 2.6.33. It's certainly not
> > production ready, but it would be greatly beneficial to be in mainline for
> > the same reasons other file systems like btrfs and exofs were merged
> > early.
>
> Is the on-the-wire protocol believed to be correct, complete, and stable? How
> about any userspace APIs and on-disk formats? In other words..
>
> > > The git tree includes the full patchset posted in October and incremental
> > > changes since then. I've tried to cram in all the anticipated protocol
> > > changes, but the file system is still strictly EXPERIMENTAL and is marked
>
> Anything left dangling on the changes?

The wire protocol is close. There is a corner cases with MDS failure
recovery that need attention, but it can be resolved in a backward
compatible way. I think a compat/incompat flags mechanism during the
initial handshake might be appropriate to make changes easier going
forward. I don't anticipate any other changes there.

There are some as-yet unresolved interface and performance issues with the
way the storage nodes interact with btrfs that have on disk format
implications. I hope to resolve those shortly. Those of course do not
impact the client code.

sage

==============================================================================
TOPIC: nommu: implement vmap/vunmap with kmalloc
http://groups.google.com/group/linux.kernel/t/d1f32572d97bd664?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Dec 21 2009 8:50 am
From: Mike Frysinger

git-svn-id: svn://localhost/svn/linux-kernel/trunk@7693 526b6c2d-f592-4532-a319-5dd88ccb003d
---
mm/nommu.c | 18 +++++++++++++++---
1 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/mm/nommu.c b/mm/nommu.c
index 8687973..d28ab94 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -360,14 +360,26 @@ EXPORT_SYMBOL(vmalloc_32_user);

void *vmap(struct page **pages, unsigned int count, unsigned long flags, pgprot_t prot)
{
- BUG();
- return NULL;
+ unsigned int i;
+ void *new_map, *page_data;
+
+ new_map = kmalloc(count << PAGE_SHIFT, GFP_KERNEL);
+ if (!new_map)
+ return NULL;
+
+ for (i = 0; i < count; ++i) {
+ page_data = kmap(pages[i]);
+ memcpy(new_map + (i << PAGE_SHIFT), page_data, PAGE_SIZE);
+ kunmap(page_data);
+ }
+
+ return new_map;
}
EXPORT_SYMBOL(vmap);

void vunmap(const void *addr)
{
- BUG();
+ kfree(addr);
}
EXPORT_SYMBOL(vunmap);

--
1.6.5.4

==============================================================================
TOPIC: x86: do_debug && PTRACE_SINGLESTEP broken by 08d68323d1f0c34452e614263b
212ca556dae47f
http://groups.google.com/group/linux.kernel/t/253956bb28f9a94f?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Dec 21 2009 8:50 am
From: Jan Kiszka

Oleg Nesterov wrote:
> On 12/21, Jan Kiszka wrote:
>> Oleg Nesterov wrote:
>>> Hmm. Now I see how wrong I was when I said this code is "obviously wrong" ;)
>
> Yes, it is easy to blame the code you don't understand.
>
> My apologies to all.
>
>>> I'll add the debugging printk's and report the output. Sorry for delay,
>>> can't do this today.
>> Can't reproduce, runs fine here with with 2.6.33-rc1 as both host&guest
>> and qemu-kvm latest git. Host uses kvm-intel.
>
> Everything runs fine under 2.6.32 as a _host_ kernel. Previously I did
> the testing under 2.6.26.5-45.fc9.

Makes sense: that kernel (most probably) predates any debug register
virtualization in kvm.

>
> Sorry for noise, thanks all for your help.

Never mind.

Jan

==============================================================================
TOPIC: Driver core: export platform_device_register_data as a GPL symbol
http://groups.google.com/group/linux.kernel/t/af315ef92d8fba1e?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Dec 21 2009 8:50 am
From: Greg KH

On Mon, Dec 21, 2009 at 11:41:08AM -0500, Mike Frysinger wrote:
> From: Michael Hennerich <michael.hennerich@analog.com>
>
> This allows MFD's to register/bind drivers for their sub devices while
> still being compiled as a module.

Is this a problem that we need to get resolved in .33, or older kernels,
or just for .34?

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/

== 2 of 3 ==
Date: Mon, Dec 21 2009 8:50 am
From: Mike Frysinger

From: Michael Hennerich <michael.hennerich@analog.com>

This allows MFD's to register/bind drivers for their sub devices while
still being compiled as a module.

Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
drivers/base/platform.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 9d2ee25..58efaf2 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -441,6 +441,7 @@ error:
platform_device_put(pdev);
return ERR_PTR(retval);
}
+EXPORT_SYMBOL_GPL(platform_device_register_data);

static int platform_drv_probe(struct device *_dev)
{
--
1.6.5.4

== 3 of 3 ==
Date: Mon, Dec 21 2009 9:10 am
From: Mike Frysinger

On Mon, Dec 21, 2009 at 11:46, Greg KH wrote:
> On Mon, Dec 21, 2009 at 11:41:08AM -0500, Mike Frysinger wrote:
>> This allows MFD's to register/bind drivers for their sub devices while
>> still being compiled as a module.
>
> Is this a problem that we need to get resolved in .33, or older kernels,
> or just for .34?

the functionality is in place now, so it could be used in .33. but it
isnt that big of a deal to simply say the mfd core cant be built as a
module right now.

so, it'd be nice for .33, but if it's too much hassle, .34 is OK.
-mike
--
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: 2.6.33-rc1: LZMA kernel fails to decompress
http://groups.google.com/group/linux.kernel/t/ae7e95c77b222ba5?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Dec 21 2009 8:50 am
From: Tvrtko Ursulin

Hi,

When run under VMware, LZMA compressed 2.6.33-rc1 instantly reboots in the
decompression stage. At least I suppose so, because switching to GZIP makes
it work.

Kernel was configured via make oldconfig from a working 2.6.32-rc6. Only other
difference is that kprobes are disabled in 33-rc1 and enabled in 32-rc6.

CPU on the server is Xeon 5110 if it helps.

I can post the .config if needed, in fact since I will be away after today, I
will do it right now. But as a reply to this to ensure at least this post is
not eaten by vger filters.

Tvrtko
--
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: Mon, Dec 21 2009 8:50 am
From: Tvrtko Ursulin

.config for working 2.6.33-rc1, if I change compression to LZMA it does not
boot.

Tvrtko

==============================================================================
TOPIC: Fix BUILD_BUG_ON in fs/compat_ioctl.c to build with gcc 4.5 snapshot
http://groups.google.com/group/linux.kernel/t/c2edbc4556dba135?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Dec 21 2009 8:50 am
From: Arnd Bergmann

On Sunday 20 December 2009, Andi Kleen wrote:
> ===================================================================
> --- linux-2.6.33-rc1-ak.orig/fs/compat_ioctl.c
> +++ linux-2.6.33-rc1-ak/fs/compat_ioctl.c
> @@ -1649,8 +1649,10 @@ static int compat_ioctl_check_table(unsi
> {
> int i;
> const int max = ARRAY_SIZE(ioctl_pointer) - 1;
> + extern void __ioctl_pointer_too_large(void);
>
> - BUILD_BUG_ON(max >= (1 << 16));
> + if (max >= (1 << 16))
> + __ioctl_pointer_too_large();
>
> /* guess initial offset into table, assuming a
> normalized distribution */

Acked-by: Arnd Bergmann <arnd@arndb.de>
--
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: 2.6.33-rc1+ bisected (?) s2ram regression
http://groups.google.com/group/linux.kernel/t/d9bf4392ddf21b2f?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Dec 21 2009 8:50 am
From: "Carlos R. Mafra"

After 2.6.33-rc1 suspend to RAM (echo mem > /sys/power/state) stopped working
on my Vaio. Plain 2.6.33-rc1 is fine.

The symptom is that it seems to never finish suspending, and the last
messages on the console stay there forever and the laptop stays dead
(no leds blinking, can't hear the fan, no nothing). I have to press
the power button to use it again.

I bisected it down to e2912009fb7b7157 ("sched: Ensure set_task_cpu() is
never called on blocked tasks"), but it does not revert cleanly for me
to double check it.

[ I tried to "solve" the merge conflict and the kernel compiled, but
s2ram did not work after that. So I am not sure if my bisection culprit
makes sense. ]

This is the bisect log:

# good: [55639353a0035052d9ea6cfe4dde0ac7fcbb2c9f] Linux 2.6.33-rc1
git bisect good 55639353a0035052d9ea6cfe4dde0ac7fcbb2c9f
# bad: [dd59f6c76b265ed2ff18b497d6105a9511b1feb1] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha-2.6
git bisect bad dd59f6c76b265ed2ff18b497d6105a9511b1feb1
# bad: [aac3d39693529ca538e37ebdb6ed5d6432a697c7] Merge branch 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git bisect bad aac3d39693529ca538e37ebdb6ed5d6432a697c7
# bad: [077614ee1e93245a3b9a4e1213659405dbeb0ba6] sched: Fix broken assertion
git bisect bad 077614ee1e93245a3b9a4e1213659405dbeb0ba6
# bad: [e2912009fb7b715728311b0d8fe327a1432b3f79] sched: Ensure set_task_cpu() is never called on blocked tasks
git bisect bad e2912009fb7b715728311b0d8fe327a1432b3f79
# good: [b9f8fcd55bbdb037e5332dbdb7b494f0b70861ac] sched: Fix cpu_clock() in NMIs, on !CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
git bisect good b9f8fcd55bbdb037e5332dbdb7b494f0b70861ac
# good: [9ee349ad6d326df3633d43f54202427295999c47] sched: Fix set_cpu_active() in cpu_down()
git bisect good 9ee349ad6d326df3633d43f54202427295999c47
# good: [e4f4288842ee12747e10c354d72be7d424c0b627] sched: Select_task_rq_fair() must honour SD_LOAD_BALANCE
git bisect good e4f4288842ee12747e10c354d72be7d424c0b627
# good: [06b83b5fbea273672822b6ee93e16781046553ec] sched: Use TASK_WAKING for fork wakups
git bisect good 06b83b5fbea273672822b6ee93e16781046553ec

If there is anything else I can do, let me know.
--
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: Mon, Dec 21 2009 9:00 am
From: Peter Zijlstra

On Mon, 2009-12-21 at 17:46 +0100, Carlos R. Mafra wrote:
> After 2.6.33-rc1 suspend to RAM (echo mem > /sys/power/state) stopped working
> on my Vaio. Plain 2.6.33-rc1 is fine.

http://lkml.org/lkml/2009/12/20/88

== 3 of 3 ==
Date: Mon, Dec 21 2009 9:30 am
From: "Carlos R. Mafra"

On Mo 21.Dez'09 at 17:56:20 +0100, Peter Zijlstra wrote:
> On Mon, 2009-12-21 at 17:46 +0100, Carlos R. Mafra wrote:
> > After 2.6.33-rc1 suspend to RAM (echo mem > /sys/power/state) stopped working
> > on my Vaio. Plain 2.6.33-rc1 is fine.
>
> http://lkml.org/lkml/2009/12/20/88

I tested it now, and the patch fixes the problem.
Thanks Peter!
--
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: fs/compat_ioctl.c: fix build error when !BLOCK
http://groups.google.com/group/linux.kernel/t/b46853b9810837a2?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Dec 21 2009 9:00 am
From: Arnd Bergmann

No driver uses SG_SET_TRANSFORM any more in Linux, since the ide-scsi
driver was removed in 2.6.29. The compat-ioctl cleanup series moved
the handling for this around, which broke building without CONFIG_BLOCK.

Just remove the code handling it for compat mode.
---

On Sunday 20 December 2009, Alexander Beregalov wrote:
> 2009/12/21 Al Viro <viro@zeniv.linux.org.uk>:
> > On Mon, Dec 21, 2009 at 12:21:32AM +0300, Alexander Beregalov wrote:
> >> Fix this build error when CONFIG_BLOCK is not set.
> >> fs/compat_ioctl.c:1604: error: 'SG_SET_TRANSFORM' undeclared
> >
> > Do you want that through VFS tree? I'm going to send a bunch of assorted
> > fixes tomorrow morning, so I can pass that one at the same time...
>
> Yes, please.

Sorry for being slow on this, I already had the fix prepared when Randy
found it last week but had not gotten around to submitting it.

Al, the patch that Alexander has sent is obviously correct as well,
so if you have already prepared the series just keep that one, otherwise
please replace it with this one.

--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -1600,8 +1600,6 @@ static long do_ioctl_trans(int fd, unsigned int cmd,
case KDSKBMETA:
case KDSKBLED:
case KDSETLED:
- /* SG stuff */
- case SG_SET_TRANSFORM:
/* AUTOFS */
case AUTOFS_IOC_READY:
case AUTOFS_IOC_FAIL:
--
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: 3c507.c: remove unused NULL pointer check
http://groups.google.com/group/linux.kernel/t/c0bc6a27904ff335?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Dec 21 2009 9:00 am
From: Oliver Hartkopp

Alexander Strakh wrote:
> In driver drivers/net/3c507.c in function Iirqreturn_t el16_interrupt:
> 1. If in line 555 dev = NULL then we goto line 556
> 2. In line 556 we have null dereference because pr_err called with dev->name
> in third parameter.
> 555 if (dev == NULL) {
> 556 pr_err("%s: net_interrupt(): irq %d for unknown device.
> \n",
> 557 dev->name, irq);
> 558 return IRQ_NONE;
> 559 }
>
> Found by Linux Device Drivers Verification (Svace detector)
>
> Remove unused NULL pointer check.

You are obviously doing more than that ...

>
> Signed-off-by: Alexander Strakh <strakh@ispras.ru>
>
> ---
> diff --git a/./0000/drivers/net/3c507.c b/./moder/drivers/net/3c507.c
> index fbc2311..3bfb3dd 100644
> --- a/./0000/drivers/net/3c507.c
> +++ b/./moder/drivers/net/3c507.c
> @@ -552,12 +552,6 @@ static irqreturn_t el16_interrupt(int irq, void *dev_id)
> ushort ack_cmd = 0;
> void __iomem *shmem;
>
> - if (dev == NULL) {
> - pr_err("%s: net_interrupt(): irq %d for unknown device.\n",
> - dev->name, irq);

You are changing real funcionality here!

If you want to fix it, fix the pr_err() but do not remove the "return
IRQ_NONE" entirely.

This looks like an introduction of a bug.

Regards,
Oliver

> - return IRQ_NONE;
> - }
> -

==============================================================================
TOPIC: x86: fix size for ex trampoline with 32bit
http://groups.google.com/group/linux.kernel/t/7a95a362ae722346?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Dec 21 2009 9:20 am
From: "H. Peter Anvin"

On 12/20/2009 11:27 PM, Yinghai Lu wrote:
>
>
> fix for error that is introduced by
> | x86: Use find_e820() instead of hard coded trampoline address
>
> it should end with PAGE_SIZE + PAGE_SIZE
>

2*PAGE_SIZE?

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

==============================================================================
TOPIC: xfs and block fixes for virtually indexed arches
http://groups.google.com/group/linux.kernel/t/f6cf95c5b7d8e318?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Dec 21 2009 9:20 am
From: James Bottomley

On Sat, 2009-12-19 at 18:33 +0000, Ralf Baechle wrote:
> On Thu, Dec 17, 2009 at 09:42:15AM -0800, Linus Torvalds wrote:
>
> >
> > I also think that the changes to bio_map_kernel() and bio_map_kern_endio()
> > are not just "fundamentally ugly", I think they are made worse by the fact
> > that it's not even done "right". You both flush the virtual caches before
> > the IO and invalidate after - when the real pattern should be that you
> > flush it before a write, and invalidate it after a read.
> >
> > And I really think that would be all much more properly done at the
> > _caller_ level, not by the BIO layer.
> >
> > You must have some locking and allocation etc logic at the caller anyway,
> > why doesn't _that_ level just do the flushing or invalidation?
>
> And then there are certain types of caches that need invalidation before
> _and_ after a DMA transaction as a workaround for a processor being
> grossly abused in a system that it should not be used in. Basically the
> issue is that falsly speculated stores may dirty caches.

Um, so that's just so wrong it doesn't even seem possible. It would
mean that a speculation could make a line dirty while DMA was in
progress to the underlying memory. There's always going to be a window
between the DMA completion and the software invalidation where the dirty
line could be flushed, thus corrupting the DMA transfer.

Hopefully steps have been taken to see that whoever thought this was a
good idea isn't still contributing to the gene pool?

James

==============================================================================
TOPIC: 2.6.33-rc1 build failure: copy_from_user() buffer size is not provably
correct
http://groups.google.com/group/linux.kernel/t/e0b57a2b296b8356?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Dec 21 2009 9:30 am
From: "H. Peter Anvin"

On 12/21/2009 03:09 AM, Ritesh Raj Sarraf wrote:
>
> I have verified the build tree and am building from -rc1 only. The fix you've
> mentioned above is also part of it.
>
> debian-build:/tmp/all-yes-config/2.6.33-rc1# cat Makefile |grep EXTRAVERSION
> EXTRAVERSION = -rc1
>
> Must be a newer bug then.
>

No, it's the same one, but different gcc. Sigh.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Monday, December 21, 2009

linux.kernel - 23 new messages in 13 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts