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

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

Today's topics:

==============================================================================
TOPIC: Regression in 2.6.32.2: segfault on halt
http://groups.google.com/group/linux.kernel/t/8278ad993c4dc07e?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 20 2009 7:30 am
From: Holger Hoffstätte

(sorry for the dupes)

Mike Galbraith wrote:
> On Sun, 2009-12-20 at 14:27 +0100, Holger Hoffstätte wrote:
>
>> Took me some time (still learning git - I usually use hg) but I just
>> managed to fix it by reverting not the bisected revision (won't compile
>> any longer), but the follow-up "cleanup & fix":
>>
>> >From 35c1ee3e78766d5666f418af638def9c67e63ecb Mon Sep 17 00:00:00 2001
>> From: Mike Galbraith <efault@gmx.de>
>> Date: Tue, 10 Nov 2009 03:50:02 +0100
>> Subject: [PATCH] sched: Fix and clean up rate-limit newidle code
>>
>> commit eae0c9dfb534cb3449888b9601228efa6480fdb5 upstream.
>>
>> Commit 1b9508f, "Rate-limit newidle" has been confirmed to fix
>> the netperf UDP loopback regression reported by Alex Shi.
>>
>> This is a cleanup and a fix:
>>
>> - moved to a more out of the way spot
>>
>> - fix to ensure that balancing doesn't try to balance
>> runqueues which haven't gone online yet, which can
>> mess up CPU enumeration during boot.
>>
>> Reported-by: Alex Shi <alex.shi@intel.com>
>> Reported-by: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
>> Signed-off-by: Mike Galbraith <efault@gmx.de>
>> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
>> LKML-Reference: <1257821402.5648.17.camel@marge.simson.net>
>> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>>
>> aka:
>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=commit;h=35c1ee3e78766d5666f418af638def9c67e63ecb
>>
>> Reverting this from a clean 32.2 tree results in a kernel with newidle
>> fix, but still working halt/reboot. The only difference between this and
>> the bisected one is the additional change in cpumask handling.
>>
>> That was more fun than expected :)
>
> Egad. Reverting the cpumask bit alone cures the problem?

Yup. I manually changed both cpumask_copy(..) lines back to
cpumask_setall(..) in a clean .32.2 tree and can halt the resulting kernel
without problems.

Holger
--
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: sched: restore sanity
http://groups.google.com/group/linux.kernel/t/9e4813505e83e962?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Dec 20 2009 7:40 am
From: San Mehat

On Sun, Dec 20, 2009 at 7:19 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Sun, 2009-12-20 at 07:05 -0800, San Mehat wrote:
>> >> Probably, but the rest is just as annoying, pr_* is crap.
>
>> Oh? Out of curiosity whats wrong with it?
>
> That's what should be asked of printk().
>
> And as long as we're not going to depricate printk() -- any attempt
> thereof will meet with fierce resistance from yours truly -- its all a
> futile exercise at best, and breaking scripts habits and patches at
> worst.
>
> I might be strange, but if I want to print something in C I write
> print[fk]() and be done with it, there's no reason what so ever to
> introduce fancy wankery for this.
>
> We try to stick to ANSI-C as much as possible, we've got
> kalloc,kfree,strcmp,strnlen and all the other 'regular' C bits,
> deviating from that serves no purpose but seed confusion.
>

Fair enough, thanks for the clarification.

-san

> If driver folks feel the need for dumb-ass wrappers because they can't
> write printk() then maybe, otoh if they can't do that, then wtf are they
> doing writing drivers anyway.
>
> But I feel this has no place in the core kernel at all, esp when its
> getting in the way of things without offering a single benefit.
>
>
>
>

--
----------
San Mehat
Staff Software Engineer
Google Inc.
o: 650-253-7422
c: 408-382-1249
san@google.com
--
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, Dec 20 2009 9:30 am
From: Joe Perches

On Sun, 2009-12-20 at 16:19 +0100, Peter Zijlstra wrote:
> On Sun, 2009-12-20 at 07:05 -0800, San Mehat wrote:
> > >> Probably, but the rest is just as annoying, pr_* is crap.
> > Oh? Out of curiosity whats wrong with it?
> That's what should be asked of printk().

pr_<level> offers some things printk cannot:

o standardization, eliminates frequent missing KERN_ levels
and missing/typo/misspelled module prefixes
o visually shorter, fewer chars used, less 80 char wrapping
o finer grained ability to eliminate unnecessary messages
for embedded systems
o standardized mechanism to prefix messages with module/function
o eventual code reduction via use of a singleton instead of
duplicated module/function names
o eventual dynamic_debug styled control of prefix by
module/function

There are quite of number of arbitrarily named module wrapper
macros and functions that build on printk.

Standardizing them around a fewer number of prefixes would
ease grepping for logging.

A standardized logging function to filter messages by
bitmask or level could also be useful.

> We try to stick to ANSI-C as much as possible, we've got
> kalloc,kfree,strcmp,strnlen and all the other 'regular' C bits,
> deviating from that serves no purpose but seed confusion.

There is a lot of kernel code that isn't 'regular' C.

Nothing in pr_<level> is not ANSI-C, it just builds on printk.

> But I feel this has no place in the core kernel at all, esp when its
> getting in the way of things without offering a single benefit.

What are the negatives of using pr_<level>?

--
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: x264 benchmarks BFS vs CFS
http://groups.google.com/group/linux.kernel/t/e881f7b9eb96d3eb?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 20 2009 8:00 am
From: Mike Galbraith

On Sun, 2009-12-20 at 16:13 +0100, Mike Galbraith wrote:
> On Sun, 2009-12-20 at 13:10 +0100, Kasper Sandberg wrote:
>
> > and as for CFS, it SHOULD exhibit fair behavior anyway, isnt it called
> > "completely FAIR scheduler" ? or is that just the marketing name?
>
> Clue: CFS _did_ distribute CPU evenly. Ponder that for a moment.

All done?

Do you think THAT may be why I thought Con might be interested?!?

-Mike

==============================================================================
TOPIC: epoll'ing tcp sockets for reading
http://groups.google.com/group/linux.kernel/t/3da31ddf7d194c87?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Dec 20 2009 8:00 am
From: Davide Libenzi

On Sun, 20 Dec 2009, Nikolai ZHUBR wrote:

> Sunday, December 20, 2009, 1:56:22 AM, Davide Libenzi wrote:
> [trim]
> > The kernel cannot make decisions based on something whose knowledge is
> > userspace bound.
> I didn't mean that. I just meant it would be usefull to let the caller
> of epoll know also the size of data related to specific EPOLLIN event in
> some "atomic" manner immediately, because the kernel probably knows this
> size already.
> The same thing can approximately be "emulated" by requesting FIOREAD for
> all EPOLLIN-ready sockets just after epoll returns, before any other work.
> It just would look not very elegant IMHO.

No such a thing of "atomic matter", since by the time you read the event,
more data might have come. It's just flawed, you see that?

> > What you define as "abstract/imprecise/overcomplicated" are simply
> > decisions that you, as implementor of the upper layer protocol, have to
> > take in order to implement your userspace code.
> > And I, personally, see nothing even close to be defined complicated in
> > such code.
> > Whenever you're asking for an abstraction/API to implement a kind
> > of software which exist in large quantities on a system, you've got to ask
> > yourself how relevant such abstraction is at the end, if all the existing
> > software have done w/out it.
> Ok, maybe that's what I should have asked at the first place. What would
> you recommend as a reference implementation showing clean, efficient,
> fail-safe usage of epoll with sockets?
> Actually I've been googling for about 2 weeks to find some, but the results
> are rather scarce and dubious.

My reference was not epoll in particular, but more in general all the
network/server software that have been written using select/poll and the
current POSIX APIs, w/out the need of knowing how much data there was on
the link.

- Davide

== 2 of 2 ==
Date: Sun, Dec 20 2009 8:20 am
From: Willy Tarreau

Hi Davide,

On Sun, Dec 20, 2009 at 07:54:09AM -0800, Davide Libenzi wrote:
> On Sun, 20 Dec 2009, Nikolai ZHUBR wrote:
>
> > Sunday, December 20, 2009, 1:56:22 AM, Davide Libenzi wrote:
> > [trim]
> > > The kernel cannot make decisions based on something whose knowledge is
> > > userspace bound.
> > I didn't mean that. I just meant it would be usefull to let the caller
> > of epoll know also the size of data related to specific EPOLLIN event in
> > some "atomic" manner immediately, because the kernel probably knows this
> > size already.
> > The same thing can approximately be "emulated" by requesting FIOREAD for
> > all EPOLLIN-ready sockets just after epoll returns, before any other work.
> > It just would look not very elegant IMHO.
>
> No such a thing of "atomic matter", since by the time you read the event,
> more data might have come. It's just flawed, you see that?

I think that what Nikolai meant was the ability to wake up as soon as
there are *at least* XXX bytes ready. But while I can understand why
it would in theory save some code, in practice he would still have to
properly handle corner cases, which would defeat the original purpose
of his modification :

- if he waits for larger data than the socket buffer can handle, he
will never wake up ;

- if my memory serves me right, the copy_and_cksum() code only knows
whether a segment is correct during its transfer to userland, which
means that epoll() could very well wake up with XXX apparent bytes
ready, but the read would fail before XXX due to an invalid checksum
on an intermediate segment. So the code would still have to take
care of that situation anyway.

The last point implies the complete implementation of the code he wants
to avoid anyway, and the first one implies it will be hard to know when
this would work and when this would not. This means that while at first
glance this behaviour could be useful, it would in practice be useless.

Regards,
Willy

==============================================================================
TOPIC: Regression in 2.6.32.2: radeon KMS hangs system
http://groups.google.com/group/linux.kernel/t/21921fba13c0c32a?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 20 2009 8:30 am
From: Johannes Hirte

With 2.6.32.2 the system hangs completely with black screen when modprobing
radeon with modeset=1. I was able to connect via ssh, but after entering the
password nothing happend. I didn't got a prompt. Only SysRq worked. I've
tracked it down to the following patch:

From 500b758725314ab1b5316eb0caa5b0fa26740e6b Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexdeucher@gmail.com>
Date: Wed, 2 Dec 2009 11:46:52 -0500
Subject: drm/radeon/kms: handle vblanks properly with dpms on

From: Alex Deucher <alexdeucher@gmail.com>

commit 500b758725314ab1b5316eb0caa5b0fa26740e6b upstream.

avivo chips

Copied from pre-avivo code.

Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
drivers/gpu/drm/radeon/atombios_crtc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -241,6 +241,7 @@ void atombios_crtc_dpms(struct drm_crtc
{
struct drm_device *dev = crtc->dev;
struct radeon_device *rdev = dev->dev_private;
+ struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);

switch (mode) {
case DRM_MODE_DPMS_ON:
@@ -248,20 +249,19 @@ void atombios_crtc_dpms(struct drm_crtc
if (ASIC_IS_DCE3(rdev))
atombios_enable_crtc_memreq(crtc, 1);
atombios_blank_crtc(crtc, 0);
+ drm_vblank_post_modeset(dev, radeon_crtc->crtc_id);
+ radeon_crtc_load_lut(crtc);
break;
case DRM_MODE_DPMS_STANDBY:
case DRM_MODE_DPMS_SUSPEND:
case DRM_MODE_DPMS_OFF:
+ drm_vblank_pre_modeset(dev, radeon_crtc->crtc_id);
atombios_blank_crtc(crtc, 1);
if (ASIC_IS_DCE3(rdev))
atombios_enable_crtc_memreq(crtc, 0);
atombios_enable_crtc(crtc, 0);
break;
}
-
- if (mode != DRM_MODE_DPMS_OFF) {
- radeon_crtc_load_lut(crtc);
- }
}

static void

After reverting this patch, modesetting works again. It's a Radeon HD3650 AGP
(RV635) on a Tyan Tiger K8W S2875ANRF (AMD 8151 AGP tunnel). Display is an
Acer X223W connected on DVI.

regards,
Johannes
--
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: Innolux Display Module #AT080TN42 Support
http://groups.google.com/group/linux.kernel/t/7501aa5afca32273?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 20 2009 8:40 am
From: Himanshu Chauhan

Hi All,

I was looking under drivers/video but couldn't find any file dealing with Innolux Display Module
#AT080TN42. Is it supported by Linux? I found this patch related to the module for 2.6.27 but I
don't think it was integrated.

Thanks in advance

Best Regards
Himanshu
--
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: sched: Fix hotplug
http://groups.google.com/group/linux.kernel/t/d76cce5479bdabc4?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 20 2009 8:40 am
From: Peter Zijlstra

The hot-unplug kstopmachine usage does a wakeup after deactivating the
cpu, hence we cannot use cpu_active() here but must rely on the good
olde online.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
kernel/sched.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
index 720df10..0ac4fa5 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -2348,7 +2348,7 @@ int select_task_rq(struct task_struct *p, int sd_flags, int wake_flags)
* not worry about this generic constraint ]
*/
if (unlikely(!cpumask_test_cpu(cpu, &p->cpus_allowed) ||
- !cpu_active(cpu)))
+ !cpu_online(cpu)))
cpu = select_fallback_rq(task_cpu(p), p);

return cpu;

==============================================================================
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: Sun, Dec 20 2009 9:00 am
From: Andi Kleen

Fix BUILD_BUG_ON in fs/compat_ioctl.c to build with gcc 4.5 snapshot

The BUILD_BUG_ON in compat_ioctl_check_table() fails
with a recent gcc mainline snapshot (gcc version 4.5.0 20091219)
(GCC)), even though it works with older compilers.

const int max = ARRAY_SIZE(ioctl_pointer) - 1;
BUILD_BUG_ON(max >= (1 << 16));

I replaced the BUILD_BUG_ON with a old style extern reference and
that works.

That shows that the actual expression is evaluated ok and something must be
wrong with the BUILD_BUG_ON macro itself. Maybe Rusty's rework
will fix that (I haven't tried but it's probably worth investigating)

I filed a bug on the compiler too
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42439

According to Joseph Myers the problem is that even when declared
with const "max" is not a constant expression in the C standard sense,
so the code is indeed incorrect.

Anyways with this workaround a relatively standard defconfig like
configuration and a 64bit allyes configuration builds again with gcc 4.5

Cc: jbeulich@novell.com
Cc: rusty@rustcorp.com.au
Cc: rguenther@suse.de

Signed-off-by: Andi Kleen <ak@linux.intel.com>

---
fs/compat_ioctl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

Index: linux-2.6.33-rc1-ak/fs/compat_ioctl.c
===================================================================
--- 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 */
--
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: drivers/scsi: Eliminate double free
http://groups.google.com/group/linux.kernel/t/eec64477200f3520?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 20 2009 9:10 am
From: Julia Lawall

From: Julia Lawall <julia@diku.dk>

The few lines below the kfree of hdr_buf may go to the label err_free which
will also free hdr_buf. The most straightforward solution seems to be to
just move the kfree of hdr_buf after these gotos.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@r@
identifier E;
expression E1;
iterator I;
statement S;
@@

*kfree(E);
... when != E = E1
when != I(E,...) S
when != &E
*kfree(E);
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>

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

diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
index 55b034b..3c8a024 100644
--- a/drivers/scsi/ses.c
+++ b/drivers/scsi/ses.c
@@ -591,8 +591,6 @@ static int ses_intf_add(struct device *cdev,
ses_dev->page10_len = len;
buf = NULL;
}
- kfree(hdr_buf);
-
scomp = kzalloc(sizeof(struct ses_component) * components, GFP_KERNEL);
if (!scomp)
goto err_free;
@@ -604,6 +602,8 @@ static int ses_intf_add(struct device *cdev,
goto err_free;
}

+ kfree(hdr_buf);
+
edev->scratch = ses_dev;
for (i = 0; i < components; i++)
edev->component[i].scratch = scomp + i;
--
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/ext4: Eliminate double free
http://groups.google.com/group/linux.kernel/t/09108346a71b9590?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 20 2009 9:10 am
From: Julia Lawall

From: Julia Lawall <julia@diku.dk>

b_entry_name and buffer are initially NULL, are initialized within a loop
to the result of calling kmalloc, and are freed at the bottom of this loop.
The loop contains gotos to cleanup, which also frees b_entry_name and
buffer. Some of these gotos are before the reinitializations of
b_entry_name and buffer. To maintain the invariant that b_entry_name and
buffer are NULL at the top of the loop, and thus acceptable arguments to
kfree, these variables are now set to NULL after the kfrees.

This seems to be the simplest solution. A more complicated solution
would be to introduce more labels in the error handling code at the end of
the function.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@r@
identifier E;
expression E1;
iterator I;
statement S;
@@

*kfree(E);
... when != E = E1
when != I(E,...) S
when != &E
*kfree(E);
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>

---
fs/ext4/xattr.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 83218be..f3a2f7e 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1332,6 +1332,8 @@ retry:
goto cleanup;
kfree(b_entry_name);
kfree(buffer);
+ b_entry_name = NULL;
+ buffer = NULL;
brelse(is->iloc.bh);
kfree(is);
kfree(bs);
--
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: vhost: prevent modification of an active ring
http://groups.google.com/group/linux.kernel/t/d473dfaadff5e527?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 20 2009 9:20 am
From: "Michael S. Tsirkin"

We don't support changing ring size or log base while ring is running.
If user violates these rules, he might get his memory silently
corrupted. It's better to be explicit, and fail such modification
attempts with an error.
To make these "vq running" checks in ioctl context robust, this patch
also moves all vq flushes to under device mutex.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/vhost/net.c | 6 +++---
drivers/vhost/vhost.c | 29 ++++++++++++++++++++++++-----
2 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index d6db10c..1b509a0 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -509,12 +509,10 @@ static long vhost_net_set_backend(struct vhost_net *n, unsigned index, int fd)
vhost_net_enable_vq(n, vq);
mutex_unlock(&vq->mutex);
done:
- mutex_unlock(&n->dev.mutex);
if (oldsock) {
vhost_net_flush_vq(n, index);
fput(oldsock->file);
}
- return r;
err:
mutex_unlock(&n->dev.mutex);
return r;
@@ -554,8 +552,8 @@ static void vhost_net_set_features(struct vhost_net *n, u64 features)
n->vqs[i].hdr_size = hdr_size;
mutex_unlock(&n->vqs[i].mutex);
}
- mutex_unlock(&n->dev.mutex);
vhost_net_flush(n);
+ mutex_unlock(&n->dev.mutex);
}

static long vhost_net_ioctl(struct file *f, unsigned int ioctl,
@@ -587,8 +585,10 @@ static long vhost_net_ioctl(struct file *f, unsigned int ioctl,
case VHOST_RESET_OWNER:
return vhost_net_reset_owner(n);
default:
+ mutex_lock(&n->dev.mutex);
r = vhost_dev_ioctl(&n->dev, ioctl, arg);
vhost_net_flush(n);
+ mutex_unlock(&n->dev.mutex);
return r;
}
}
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index e7b4dea..29f1675 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -288,6 +288,12 @@ static long vhost_set_vring(struct vhost_dev *d, int ioctl, void __user *argp)

switch (ioctl) {
case VHOST_SET_VRING_NUM:
+ /* Resizing ring with an active backend?
+ * You don't want to do that. */
+ if (vq->private_data) {
+ r = -EBUSY;
+ break;
+ }
r = copy_from_user(&s, argp, sizeof s);
if (r < 0)
break;
@@ -298,6 +304,12 @@ static long vhost_set_vring(struct vhost_dev *d, int ioctl, void __user *argp)
vq->num = s.num;
break;
case VHOST_SET_VRING_BASE:
+ /* Moving base with an active backend?
+ * You don't want to do that. */
+ if (vq->private_data) {
+ r = -EBUSY;
+ break;
+ }
r = copy_from_user(&s, argp, sizeof s);
if (r < 0)
break;
@@ -413,6 +425,7 @@ static long vhost_set_vring(struct vhost_dev *d, int ioctl, void __user *argp)
return r;
}

+/* Caller must have device mutex */
long vhost_dev_ioctl(struct vhost_dev *d, unsigned int ioctl, unsigned long arg)
{
void __user *argp = (void __user *)arg;
@@ -422,7 +435,6 @@ long vhost_dev_ioctl(struct vhost_dev *d, unsigned int ioctl, unsigned long arg)
long r;
int i, fd;

- mutex_lock(&d->mutex);
/* If you are not the owner, you can become one */
if (ioctl == VHOST_SET_OWNER) {
r = vhost_dev_set_owner(d);
@@ -447,9 +459,17 @@ long vhost_dev_ioctl(struct vhost_dev *d, unsigned int ioctl, unsigned long arg)
break;
}
for (i = 0; i < d->nvqs; ++i) {
- mutex_lock(&d->vqs[i].mutex);
- d->vqs[i].log_base = (void __user *)(unsigned long)p;
- mutex_unlock(&d->vqs[i].mutex);
+ struct vhost_virtqueue *vq;
+ vq = d->vqs + i;
+ mutex_lock(&vq->mutex);
+ /* Moving log base with an active backend?
+ * You don't want to do that. */
+ if (vq->private_data && (vq->log_used ||
+ vhost_has_feature(d, VHOST_F_LOG_ALL)))
+ r = -EBUSY;
+ else
+ vq->log_base = (void __user *)(unsigned long)p;
+ mutex_unlock(&vq->mutex);
}
break;
case VHOST_SET_LOG_FD:
@@ -483,7 +503,6 @@ long vhost_dev_ioctl(struct vhost_dev *d, unsigned int ioctl, unsigned long arg)
break;
}
done:
- mutex_unlock(&d->mutex);
return r;
}

--
1.6.6.rc1.43.gf55cc

==============================================================================
TOPIC: viafb: remove dead code
http://groups.google.com/group/linux.kernel/t/7c17f386b6b25db1?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Dec 20 2009 9:20 am
From: Florian Tobias Schandinat

viafb: remove dead code

Remove a completly unused function.

Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/via_utility.c | 12 ------------
drivers/video/via/via_utility.h | 1 -
2 files changed, 0 insertions(+), 13 deletions(-)

diff --git a/drivers/video/via/via_utility.c b/drivers/video/via/via_utility.c
index d53c3d5..aefdeee 100644
--- a/drivers/video/via/via_utility.c
+++ b/drivers/video/via/via_utility.c
@@ -239,15 +239,3 @@ void viafb_get_gamma_support_state(int bpp, unsigned int *support_state)
else
*support_state = CRT_Device | DVI_Device | LCD_Device;
}
-
-int viafb_input_parameter_converter(int parameter_value)
-{
- int result;
-
- if (parameter_value >= 1 && parameter_value <= 9)
- result = 1 << (parameter_value - 1);
- else
- result = 1;
-
- return result;
-}
diff --git a/drivers/video/via/via_utility.h b/drivers/video/via/via_utility.h
index 2fd4552..1670ba8 100644
--- a/drivers/video/via/via_utility.h
+++ b/drivers/video/via/via_utility.h
@@ -30,6 +30,5 @@ bool viafb_lcd_get_support_expand_state(u32 xres, u32 yres);
void viafb_set_gamma_table(int bpp, unsigned int *gamma_table);
void viafb_get_gamma_table(unsigned int *gamma_table);
void viafb_get_gamma_support_state(int bpp, unsigned int *support_state);
-int viafb_input_parameter_converter(int parameter_value);

twitter

Sunday, December 20, 2009

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

0 Comments:

Post a Comment

About Me

Previous Posts