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

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

Today's topics:

==============================================================================
TOPIC: btrfs: handle kmalloc() failure
http://groups.google.com/group/linux.kernel/t/82ebdfc4e7c4afe8?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 4:30 am
From: Dan Carpenter

Return -ENOMEM if kmalloc() fails.

Signed-off-by: Dan Carpenter <error27@gmail.com>

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 15f661d..be9b5df 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1212,6 +1212,9 @@ static noinline int btrfs_ioctl_ino_lookup(struct file *file,
return -EPERM;

args = kmalloc(sizeof(*args), GFP_KERNEL);
+ if (!args)
+ return -ENOMEM;
+
if (copy_from_user(args, argp, sizeof(*args))) {
kfree(args);
return -EFAULT;
--
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: afs: potential null dereference
http://groups.google.com/group/linux.kernel/t/7ee577ef4e1bc972?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 4:30 am
From: Dan Carpenter

It seems clear from the surrounding code that xpermits is allowed to be
NULL here.

Signed-off-by: Dan Carpenter <error27@gmail.com>

diff --git a/fs/afs/security.c b/fs/afs/security.c
index 3ef5043..bb4ed14 100644
--- a/fs/afs/security.c
+++ b/fs/afs/security.c
@@ -189,8 +189,9 @@ void afs_cache_permit(struct afs_vnode *vnode, struct key *key, long acl_order)
if (!permits)
goto out_unlock;

- memcpy(permits->permits, xpermits->permits,
- count * sizeof(struct afs_permit));
+ if (xpermits)
+ memcpy(permits->permits, xpermits->permits,
+ count * sizeof(struct afs_permit));

_debug("key %x access %x",
key_serial(key), vnode->status.caller_access);
--
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: MTD: Fix Orion NAND driver compilation with ARM OABI
http://groups.google.com/group/linux.kernel/t/177b8a65dffdfa8d?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Mar 20 2010 4:30 am
From: Paulius Zaleckas

On Sat, Mar 20, 2010 at 11:41 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Sat, 2010-03-20 at 10:55 +0200, Paulius Zaleckas wrote:
>> We must tell GCC to use even register for variable passed
>> to ldrd instruction. Without this patch GCC 4.2.1 puts this
>> variable to r2/r3 on EABI and r3/r4 on OABI, so force it to
>> r2/r3. This does not change anything when EABI and OABI
>> compilation works OK.
>>
>> Without this patch and with OABI I get:
>> /tmp/ccMkwOCs.s:63: Error: first destination register must be even -- `ldrd r3,[ip]'
>> make[5]: *** [drivers/mtd/nand/orion_nand.o] Error 1
>
> ...
>> - uint64_t x;
>> + /*
>> + * force x variable to r2/r3 registers since ldrd instruction
>> + * requires first register to be even.
>> + */
>> + register uint64_t x asm ("r2");
>> +
>> asm volatile ("ldrd\t%0, [%1]" : "=&r" (x) : "r" (io_base));
>
> Hm, isn't there an asm constraint which will force it into an
> appropriate register pair?

Not that I know of...

> Failing that, "=&2,4,6,8" ought to work.

No, fails with error: matching constraint not valid in output operand

> (Um, and why the earlyclobber? Why can't io_base be passed in in one of
> the same registers?)
>
> We should try to avoid making our constraints more restrictive than they
> need to be.
>
> --
> David Woodhouse Open Source Technology Centre
> David.Woodhouse@intel.com Intel Corporation
--
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: Sat, Mar 20 2010 5:00 am
From: David Woodhouse

On Sat, 2010-03-20 at 13:20 +0200, Paulius Zaleckas wrote:
> On Sat, Mar 20, 2010 at 11:41 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> > On Sat, 2010-03-20 at 10:55 +0200, Paulius Zaleckas wrote:
> >> - uint64_t x;
> >> + /*
> >> + * force x variable to r2/r3 registers since ldrd instruction
> >> + * requires first register to be even.
> >> + */
> >> + register uint64_t x asm ("r2");
> >> +
> >> asm volatile ("ldrd\t%0, [%1]" : "=&r" (x) : "r" (io_base));
> >
> > Hm, isn't there an asm constraint which will force it into an
> > appropriate register pair?
>
> Not that I know of...
>
> > Failing that, "=&r2,r4,r6,r8" ought to work.
>
> No, fails with error: matching constraint not valid in output operand

Hm, crap -- GCC on ARM doesn't let you give specific registers, so that
trick doesn't work.

Strictly speaking, I think your version is wrong -- although you force
the variable 'x' to be stored in r2/r3, you don't actually force GCC to
use r2/r3 as the output registers for the asm statement -- it could
happily use other registers, then move their contents into r2/r3
afterwards.

Obviously it _won't_ do that most of the time, but it _could_. GCC PR
#15089 was filed for the fact that sometimes it does, but I think Nico
was missing the point -- GCC is _allowed_ to do that, and if it makes
you sad then you should be asking for better assembly constraints which
would allow you to tell it not to.

See the __asmeq() macro in <asm/system.h> for a dirty hack which will
check which registers are used and abort at compile time, although your
compilation is going to fail anyway so I'm not sure it makes much of a
difference in this particular case.

The real fix here is to add an asm constraint to GCC which allows you to
specify "any even GPR" (or whatever's most suitable for the ldrd
instruction). Being able to give specific registers, like you can on
other architectures, would be useful too.

Please file a PR, then resubmit your patch with a comment explaining
that the code is known to be broken because GCC doesn't allow you to do
any better, and containing a reference to your PR. If people copy your
code, I want them to at least know that they're propagating a bug.

--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation

--
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: btrfs: dereferencing freed memory
http://groups.google.com/group/linux.kernel/t/08b9033150b085ee?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 4:30 am
From: Dan Carpenter

The original code dereferenced range on the next line.

Signed-off-by: Dan Carpenter <error27@gmail.com>

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index be9b5df..d7ab56c 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1378,6 +1378,7 @@ static int btrfs_ioctl_defrag(struct file *file, void __user *argp)
sizeof(*range))) {
ret = -EFAULT;
kfree(range);
+ goto out;
}
/* compression requires us to start the IO */
if ((range->flags & BTRFS_DEFRAG_RANGE_COMPRESS)) {
--
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: btrfs cleanup: remove more dead code
http://groups.google.com/group/linux.kernel/t/1296d061a1540645?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 4:40 am
From: Dan Carpenter

rb_node cannot be an ERR_PTR() here so I removed the misleading check.
Also I removed some more dead code at the bottom.

It looks like the code from lookup_extent_mapping() may have been
copy and pasted into search_extent_mapping()?

Signed-off-by: Dan Carpenter <error27@gmail.com>
---
This doesn't change anything. Could you put it into linux-next?

diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
index 94668b1..010f299 100644
--- a/fs/btrfs/extent_map.c
+++ b/fs/btrfs/extent_map.c
@@ -380,16 +380,7 @@ struct extent_map *search_extent_mapping(struct extent_map_tree *tree,
em = NULL;
goto out;
}
- if (IS_ERR(rb_node)) {
- em = ERR_PTR(PTR_ERR(rb_node));
- goto out;
- }
em = rb_entry(rb_node, struct extent_map, rb_node);
- goto found;
-
- em = NULL;
- goto out;
-
found:
atomic_inc(&em->refs);
out:
--
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: btrfs cleanup: unneeded null check
http://groups.google.com/group/linux.kernel/t/864cf14f5c0f4e0b?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 4:40 am
From: Dan Carpenter

old_inode cannot be null here so I removed the check.
This fixes a smatch warning:
fs/btrfs/inode.c +5545 btrfs_rename(88) warn: variable dereferenced
before check 'old_inode'

Signed-off-by: Dan Carpenter <error27@gmail.com>
---
linux-next material

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 02bb099..647ce41 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -5541,10 +5541,8 @@ static int btrfs_rename(struct inode *old_dir, struct dentry *old_dentry,
* make sure the inode gets flushed if it is replacing
* something.
*/
- if (new_inode && new_inode->i_size &&
- old_inode && S_ISREG(old_inode->i_mode)) {
+ if (new_inode && new_inode->i_size && S_ISREG(old_inode->i_mode))
btrfs_add_ordered_operation(trans, root, old_inode);
- }

old_dir->i_ctime = old_dir->i_mtime = ctime;
new_dir->i_ctime = new_dir->i_mtime = ctime;
--
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: locking problems: Btrfs: be more selective in the defrag ioctl
http://groups.google.com/group/linux.kernel/t/59bea90a2c360876?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 4:40 am
From: Dan Carpenter

Hi Chris,

There is a locking problem in
940100a4a7b78 "Btrfs: be more selective in the defrag ioctl"

There are two places where we break out of the while loop under the
lock.

fs/btrfs/ioctl.c +708 btrfs_defrag_file(159) error: double lock 'mutex:&inode->i_mutex'
600 mutex_lock(&inode->i_mutex);
601 if (range->flags & BTRFS_DEFRAG_RANGE_COMPRESS)
602 BTRFS_I(inode)->force_compress = 1;
603
604 ret = btrfs_check_data_free_space(root, inode, PAGE_CACHE_SIZE);
605 if (ret) {
606 ret = -ENOSPC;
607 break;

Here.

608 }
609
610 ret = btrfs_reserve_metadata_for_delalloc(root, inode, 1);
611 if (ret) {
612 btrfs_free_reserved_data_space(root, inode,
613 PAGE_CACHE_SIZE);
614 ret = -ENOSPC;
615 break;

And here.

616 }

Maybe we should have "goto err_reservations;" instead of break? I
don't know the code well enough to say.

regards,
dan carpenter
--
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: Loan Offer
http://groups.google.com/group/linux.kernel/t/f6f532a6333727d2?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 5:00 am
From: come

We are currently offering loan, ranges from $10,000USD
to (infinity. Terms and conditions apply)
Apply now.

==============================================================================
TOPIC: musb: potential use after free
http://groups.google.com/group/linux.kernel/t/f91b41ea646a3fe3?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 5:30 am
From: Dan Carpenter

We assign "urb->hcpriv = qh;" a few lines down. I'm pretty sure we
want it "urb->hcpriv" to be NULL not a freed value.

Signed-off-by: Dan Carpenter <error27@gmail.com>
---
Found with a static checker. I don't have the hardware to test this.

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index dec896e..877d20b 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2042,6 +2042,7 @@ static int musb_urb_enqueue(
* odd, rare, error prone, but legal.
*/
kfree(qh);
+ qh = NULL;
ret = 0;
} else
ret = musb_schedule(musb, qh,
--
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: ceph: handle kmalloc() failure
http://groups.google.com/group/linux.kernel/t/c64ea23e62cbce50?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 5:40 am
From: Dan Carpenter

Return ERR_PTR(-ENOMEM) if kmalloc() fails. We handle allocation
failures the same way later in the function.

Signed-off-by: Dan Carpenter <error27@gmail.com>

diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
index a260010..655b005 100644
--- a/fs/ceph/mds_client.c
+++ b/fs/ceph/mds_client.c
@@ -328,6 +328,8 @@ static struct ceph_mds_session *register_session(struct ceph_mds_client *mdsc,
struct ceph_mds_session *s;

s = kzalloc(sizeof(*s), GFP_NOFS);
+ if (!s)
+ return ERR_PTR(-ENOMEM);
s->s_mdsc = mdsc;
s->s_mds = mds;
s->s_state = CEPH_MDS_SESSION_NEW;
--
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: (none)
http://groups.google.com/group/linux.kernel/t/28bffe75ee7a790a?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 5:40 am
From: "Tobacco Office"

Send your Names,Sex,Country,Tell,occupation
--
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: bug report: ceph: && vs ||
http://groups.google.com/group/linux.kernel/t/ed06e902bc40abe9?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 5:50 am
From: Dan Carpenter

1772 /* correct session? */
1773 if (!req->r_session && req->r_session != session) {

Is this supposed to || here? We know "session" is non-NULL at
the point because we already dereferenced it. If "req->r_session"
is null then the second condition is always true.

Also we dereference "req->r_session" later on without checking.

1774 pr_err("mdsc_handle_reply got %llu on session mds%d"
1775 " not mds%d\n", tid, session->s_mds,
1776 req->r_session ? req->r_session->s_mds : -1);
1777 mutex_unlock(&mdsc->mutex);
1778 goto out;
1779 }
1780

==============================================================================
TOPIC: [RESEND] x86: add HPET-quirk for nVidia MCP61 LPC Bridge (10de:03e0)
http://groups.google.com/group/linux.kernel/t/2e139f286d40ff74?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 6:00 am
From: Frank Schaefer

Clemens Ladisch schrieb:
> Frank Schaefer wrote:
>
>> Any comments on this patch ?
>>
> Gmail ate your tabs; see Documentation/email-clients.txt.
>
Thanks for your reply Clemens.
It wasn't Gmails fault, I made a pasting mistake...sorry.
> Cosmetic changes to not belong in the stable tree; see
> Documentation/stable_kernel_rules.txt.
>
Alright, no Cc stable.
>> Wrong list ?
>>
>
> arch/x86 stuff should go to <x86@kernel.org>.
>
>
> Regards,
> Clemens
>
The get-maintainer-script told me to send it to this list. Shouldn't it
be updated then ?
Also: this list seems to be mentioned nowhere, at least not at

http://www.linux.org/docs/lists.html
http://vger.kernel.org/vger-lists.html

Regards,
Frank
--
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: execve for script don't return ENOEXEC, bug ?
http://groups.google.com/group/linux.kernel/t/53d156cf36c58e4f?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 6:00 am
From: Valery Reznic

--- On Sat, 3/20/10, David Newall <davidn@davidnewall.com> wrote:

> From: David Newall <davidn@davidnewall.com>
> Subject: Re: execve for script don't return ENOEXEC, bug ?
> To: "Valery Reznic" <valery_reznic@yahoo.com>
> Cc: linux-kernel@vger.kernel.org
> Date: Saturday, March 20, 2010, 11:41 AM
> Valery Reznic wrote:
> > [valery@localhost ~]$ cat a.sh #!/bin/sh
> > echo "It's a.sh"
> > [valery@localhost ~]$ cat b.sh #! ./a.sh
> > echo "It's b.sh"
> > [valery@localhost ~]$ [valery@localhost ~]$ strace -f
> -e execve setarch i386 ./b.sh execve("/usr/bin/setarch",
> ["setarch", "i386", "./b.sh"], [/* 40 vars */]) = 0
> > execve("./b.sh", ["./b.sh"], [/* 40 vars */]) = 0
> > It's a.sh
> >
>
> That is the correct output for a script which is being
> interpreted by a.sh, when a.sh prints "It's a.sh" using
> /bin/sh as its interpreter. Remember, you didn't ask
> /bin/sh to interpret b.sh, you asked a.sh to do it, and a.sh
> is a simple echo statement, not an interpreter. There
> is no error here.

execve's man page state that script's interprtert should not be
interpreter itself:
------------------------------------------------------
Interpreter scripts
An interpreter script is a text file that has execute permission
enabled and whose first line is of the form:

#! interpreter [optional-arg]

The interpreter must be a valid pathname for an executable which is not
itself a script.
------------------------------------------------------

I.e, execve should return ENOEXEC. And it did it at least in Fedora 8 and earlier.

To me it looks like execve and it's man page disagree. Do you know is it new intended behaviour of execve and just man page wasn't update or it's a bug in execve ?

Valery.
>

==============================================================================
TOPIC: scsi: fix lockdep warning
http://groups.google.com/group/linux.kernel/t/11d9a53a0f67b845?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 6:10 am
From: Greg KH

On Sat, Mar 20, 2010 at 12:17:38AM -0700, Yinghai Lu wrote:
>
> with qlogic and emulex card etc.

Is this still needed with 2.6.34-rc2?

And as was pointed out, this does not look correct as you are doing it
on static attributes.

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: intel-agp.c: Fix crash when accessing nonexistent GTT entries in i915
http://groups.google.com/group/linux.kernel/t/bcbed4037b6559cf?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 6:10 am
From: Miguel Ojeda

On Fri, Mar 19, 2010 at 9:27 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Thu, 11 Mar 2010 16:54:26 +0100
> Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>
>> Attached dmesg, lspci -vv, config and xorg.
>>
>> When the X server crashes, the kernel does not report anything
>
> This seems to have gone all quiet?

It seems so, I was about to ping Zhenyu.

>
> As this was a 2.6.32->2.6.32.4 regression, I assume that it's also a
> 2.6.32->2.6.33 regression?

Yep. All kernels I tested since 2.6.32.4 crash, including 2.6.32.10,
2.6.33 and 2.6.34-rc1. See my original message for more details about
the crash.

>
--
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: Yet another (third) dt3155 driver PCI/video4linux compliant
http://groups.google.com/group/linux.kernel/t/c727762dff291a2e?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 6:10 am
From: Greg KH

On Sat, Mar 20, 2010 at 11:18:36AM +0200, Marin Mitov wrote:
> Hi Scott, Greg, all,
>
> Here you will find a link to the source code for a dt3155 driver
> rewritten to be PCI/video4linux compliant.
>
> http://lfb.issp.bas.bg/~mitov/linux/dt3155v4l/
>
> It works with xawtv (if the window is bigger than the acquired image).
> See
>
> http://lfb.issp.bas.bg/~mitov/linux/dt3155v4l/00README
>
> for more details.
>
> Any critics/comments will be appreciated.

Can you send it in patch form? I can't really do anything with it like
this, sorry.

==============================================================================
TOPIC: virtio-balloon: allow hypervisor refuse locking some pages
http://groups.google.com/group/linux.kernel/t/8961c225809279ff?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Mar 20 2010 6:10 am
From: Avi Kivity

On 03/19/2010 10:46 PM, Dmitry Torokhov wrote:
> Some hypervisors may refuse our request to lock pages in certain
> circumstances. For example, VMware may decide that the target balloon
> size decreased since it was last communicated to the guest and thus
> current page should not be locked.
>
>
> static struct virtio_driver virtio_balloon_driver = {
> diff --git a/include/linux/virtio_balloon.h b/include/linux/virtio_balloon.h
> index a50ecd1..4baad1c 100644
> --- a/include/linux/virtio_balloon.h
> +++ b/include/linux/virtio_balloon.h
> @@ -6,12 +6,16 @@
> #include<linux/virtio_config.h>
>
> /* The feature bitmap for virtio balloon */
> -#define VIRTIO_BALLOON_F_MUST_TELL_HOST 0 /* Tell before reclaiming pages */
> -#define VIRTIO_BALLOON_F_STATS_VQ 1 /* Memory Stats virtqueue */
> +#define VIRTIO_BALLOON_F_MUST_TELL_HOST 0 /* Tell before reclaiming pages */
> +#define VIRTIO_BALLOON_F_STATS_VQ 1 /* Memory Stats virtqueue */
> +#define VIRTIO_BALLOON_F_HOST_MAY_REFUSE 2 /* Host may refuse some pages */
>
> /* Size of a PFN in the balloon interface. */
> #define VIRTIO_BALLOON_PFN_SHIFT 12
>
> +#define VIRTIO_BALLOON_PFN_OK 0
> +#define VIRTIO_BALLOON_PFN_FAIL 1
> +
> struct virtio_balloon_config
> {
> /* Number of pages host wants Guest to give up. */
>

Please update the virtio pci spec (can't find the URL - Rusty?) to
reflect the protocol change.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

== 2 of 2 ==
Date: Sat, Mar 20 2010 6:20 am
From: Avi Kivity

On 03/19/2010 10:47 PM, Dmitry Torokhov wrote:
> This is a virtio-based transport between VMware's hypervisor
> and virtio_ballon driver that allows host control guest memory
> ballooning.
>
>

This is a little wierd since it's specific to the balloon driver. The
virtio design is to make transport and device orthogonal so we could
mix'n'match any driver with any transport, but this will only work with
the balloon driver. It's also 640 lines while the original balloon
driver is ~300. Some of that is because you're emulating a queue that
doesn't really exist, IIUC.

So while I'd love to see other hypervisors adopt virtio, I think in this
case it makes more sense to have your own balloon driver.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

==============================================================================
TOPIC: ceph: cleanup: remove dead code
http://groups.google.com/group/linux.kernel/t/f5d5d9776aa5fcc8?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 6:10 am
From: Dan Carpenter

"xattr" is never NULL here. We took care of that in the previous
if statement block.

Signed-off-by: Dan Carpenter <error27@gmail.com>

diff --git a/fs/ceph/xattr.c b/fs/ceph/xattr.c
index 37d6ce6..65b0e9b 100644
--- a/fs/ceph/xattr.c
+++ b/fs/ceph/xattr.c
@@ -185,12 +185,6 @@ static int __set_xattr(struct ceph_inode_info *ci,
ci->i_xattrs.names_size -= xattr->name_len;
ci->i_xattrs.vals_size -= xattr->val_len;
}
- if (!xattr) {
- pr_err("__set_xattr ENOMEM on %p %llx.%llx xattr %s=%s\n",
- &ci->vfs_inode, ceph_vinop(&ci->vfs_inode), name,
- xattr->val);
- return -ENOMEM;
- }
ci->i_xattrs.names_size += name_len;
ci->i_xattrs.vals_size += val_len;
if (val)
--
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: trace: find the correct ftrace event
http://groups.google.com/group/linux.kernel/t/28b816b62ae45fcd?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Mar 20 2010 6:30 am
From: Dan Carpenter

The original code doesn't work because "call" is never NULL there.

Signed-off-by: Dan Carpenter <error27@gmail.com>
---
My code should work, but it seems like there should but it seems like
there should be a more elegant way to do this?

diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c
index 4615f62..6070c70 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -1388,16 +1388,19 @@ int ftrace_profile_set_filter(struct perf_event *event, int event_id,
struct event_filter *filter;
struct filter_parse_state *ps;
struct ftrace_event_call *call = NULL;
+ int found = 0;

mutex_lock(&event_mutex);

list_for_each_entry(call, &ftrace_events, list) {
- if (call->id == event_id)
+ if (call->id == event_id) {
+ found = 1;
break;
+ }
}

err = -EINVAL;
- if (!call)
+ if (!found)
goto out_unlock;

err = -EEXIST;
--
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: Sat, Mar 20 2010 6:40 am
From: Steven Rostedt

On Sat, 2010-03-20 at 16:19 +0300, Dan Carpenter wrote:
> The original code doesn't work because "call" is never NULL there.

A one line change would have done the same ;-)

> Signed-off-by: Dan Carpenter <error27@gmail.com>
> ---
> My code should work, but it seems like there should but it seems like
> there should be a more elegant way to do this?
>
> diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c
> index 4615f62..6070c70 100644
> --- a/kernel/trace/trace_events_filter.c
> +++ b/kernel/trace/trace_events_filter.c
> @@ -1388,16 +1388,19 @@ int ftrace_profile_set_filter(struct perf_event *event, int event_id,
> struct event_filter *filter;
> struct filter_parse_state *ps;
> struct ftrace_event_call *call = NULL;
> + int found = 0;
>
> mutex_lock(&event_mutex);
>
> list_for_each_entry(call, &ftrace_events, list) {
> - if (call->id == event_id)
> + if (call->id == event_id) {
> + found = 1;
> break;
> + }
> }
>
> err = -EINVAL;
> - if (!call)

if (call == &ftrace_events)

-- Steve

> + if (!found)
> goto out_unlock;
>
> err = -EEXIST;

==============================================================================
TOPIC: Business proposal.
http://groups.google.com/group/linux.kernel/t/f53d952698e3fb20?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 6:40 am
From: "YING CHEN."

Business proposal.
I have a business proposal for you that will be beneficial to the both of
us. This proposal has to do with funds transfer. Kindly let me hear from
you to enable me provide you with details on what I propose. Thank you.
Please send your Response to the EMAIL:ying1cheng55@yahoo.cn
Regard.
YING CHEN.

==============================================================================
TOPIC: checkpatch: Add check for too short Kconfig descriptions
http://groups.google.com/group/linux.kernel/t/3f69d694f5d3b65d?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 6:40 am
From: Tilman Schmidt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 2010-03-20 03:32 schrieb Andi Kleen:
> I've seen various new Kconfigs with rather unhelpful one liner
> descriptions. Add a Kconfig warning for a minimum length of the
> Kconfig help section.

I don't think helpfulness can be enforced via line count.
A one-liner can be quite sufficient (eg. CRYPTO_MD4).
OTOH more lines can still leave important questions unanswered (eg.
CRYPTO_SALSA20_586 whose help text is identical to that of
CRYPTO_SALSA20, leaving you wondering when to choose one over the other).

Jm2c
Tilman

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkukzjIACgkQQ3+did9BuFvE1wCff7n2x/bAbiZrJkTnQrEUi7eI
oVsAoJO6l5JMBddFfQOwQDetun1tCtEx
=qkDo
-----END PGP SIGNATURE-----
--
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/

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

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

Saturday, March 20, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts