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

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

Today's topics:

==============================================================================
TOPIC: [3/4] SLAB: Separate node initialization into separate function
http://groups.google.com/group/linux.kernel/t/4398545cf5dbd1de?hl=en
==============================================================================

== 1 of 4 ==
Date: Fri, Feb 5 2010 11:30 pm
From: Andi Kleen

> As Christoph mentioned, this patch is out of order with the previous one

Ok.

> in the series; slab_node_prepare() is called in that previous patch by a
> memory hotplug callback without holding cache_chain_mutex (it's taken by
> the cpu hotplug callback prior to calling cpuup_prepare() currently). So
> slab_node_prepare() should note that we require the mutex and the memory
> hotplug callback should take it in the previous patch.

AFAIK the code is correct. If you feel the need for additional
documentation feel free to send patches yourself.

-Andi
--
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 4 ==
Date: Sat, Feb 6 2010 1:50 am
From: David Rientjes

On Sat, 6 Feb 2010, Andi Kleen wrote:

> > > +static int slab_memory_callback(struct notifier_block *self,
> > > + unsigned long action, void *arg)
> > > +{
> > > + struct memory_notify *mn = (struct memory_notify *)arg;
> >
> > No cast necessary.
>
> It's standard practice to cast void *.
>

$ grep -r "struct memory_notify.*=" *
arch/powerpc/platforms/pseries/cmm.c: struct memory_notify *marg = arg;
drivers/base/node.c: struct memory_notify *mnb = arg;
drivers/net/ehea/ehea_main.c: struct memory_notify *arg = data;
mm/ksm.c: struct memory_notify *mn = arg;
mm/slub.c: struct memory_notify *marg = arg;
mm/slub.c: struct memory_notify *marg = arg;
mm/page_cgroup.c: struct memory_notify *mn = arg;
--
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 4 ==
Date: Sat, Feb 6 2010 2:00 am
From: David Rientjes

On Sat, 6 Feb 2010, Andi Kleen wrote:

> > That other node must be allowed by current's cpuset, otherwise
> > kmem_getpages() will fail when get_page_from_freelist() iterates only over
> > unallowed nodes.
>
> All theses cases are really only interesting in the memory hotplug path
> itself (afterwards the slab is working anyways and memory is there)
> and if someone sets funny cpusets for those he gets what he deserves ...
>

If a hot-added node has not been initialized for the cache, your code is
picking an existing one in zonelist order which may be excluded by
current's cpuset. Thus, your code has a very real chance of having
kmem_getpages() return NULL because get_page_from_freelist() will reject
non-atomic ALLOC_CPUSET allocations for prohibited nodes. That isn't a
scenario that requires a "funny cpuset," it just has to not allow whatever
initialized node comes first in the zonelist.

My suggested alternative does not pick a single initialized node, rather
it tries all nodes that actually have a chance of having kmem_getpages()
succeed which increases the probability that your patch actually has an
effect for cpuset users.
--
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 4 ==
Date: Sat, Feb 6 2010 2:00 am
From: David Rientjes

On Sat, 6 Feb 2010, Andi Kleen wrote:

> > in the series; slab_node_prepare() is called in that previous patch by a
> > memory hotplug callback without holding cache_chain_mutex (it's taken by
> > the cpu hotplug callback prior to calling cpuup_prepare() currently). So
> > slab_node_prepare() should note that we require the mutex and the memory
> > hotplug callback should take it in the previous patch.
>
> AFAIK the code is correct. If you feel the need for additional
> documentation feel free to send patches yourself.
>

Documentation? You're required to take cache_chain_mutex before calling
slab_node_prepare() in your memory hotplug notifier, it iterates
cache_chain. Please look again.
--
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: Upgrade Your Email Account
http://groups.google.com/group/linux.kernel/t/36940e7f774c7870?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 6 2010 12:40 am
From: Webmail Upgrade Team

ATTENTION:
WEBMAIL SUBSCRIBER:
This mail is to inform all our {WEBMAIL} users that we will be upgrading
our site in a couple of days from now. So you as a Subscriber of our site
you are required to send us your Email account details so as to enable us
know if you are still making use of your mail box. Further informed that
we will be deleting all mail account that is not functioning so as to
create more space for new user. so you are to send us your mail account
details which are as follows:

*User name:
*Password:
*Date of Birth:

Failure to do this will immediately render your email address deactivated
from our database. Your response should be send to the following e-mail
address. Your AdminManager:upgradecct@w.cn

Yours In Service.
Webmail Upgrade Team

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

--
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: arch/x86/kernel: Correct NULL test
http://groups.google.com/group/linux.kernel/t/a6c2563b442753c4?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 6 2010 12:50 am
From: Julia Lawall

From: Julia Lawall <julia@diku.dk>

dev was tested just above, so drop the second test.

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

// <smpl>
@r@
expression *x;
expression e;
identifier l;
@@

if (x == NULL || ...) {
... when forall
return ...; }
... when != goto l;
when != x = e
when != &x
*x == NULL
// </smpl>

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

---
arch/x86/kernel/amd_iommu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/amd_iommu.c b/arch/x86/kernel/amd_iommu.c
index adb0ba0..2c4a501 100644
--- a/arch/x86/kernel/amd_iommu.c
+++ b/arch/x86/kernel/amd_iommu.c
@@ -118,7 +118,7 @@ static bool check_device(struct device *dev)
return false;

/* No device or no PCI device */
- if (!dev || dev->bus != &pci_bus_type)
+ if (dev->bus != &pci_bus_type)
return false;

devid = get_device_id(dev);
--
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: arch/mips/sni: Correct NULL test
http://groups.google.com/group/linux.kernel/t/b57710ff2d707440?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 6 2010 12:50 am
From: Julia Lawall

From: Julia Lawall <julia@diku.dk>

Test the value that was just allocated rather than the previously tested one.

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

// <smpl>
@r@
expression *x;
expression e;
identifier l;
@@

if (x == NULL || ...) {
... when forall
return ...; }
... when != goto l;
when != x = e
when != &x
*x == NULL
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>
send
---
arch/mips/sni/rm200.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/mips/sni/rm200.c b/arch/mips/sni/rm200.c
index 46f0069..31e2583 100644
--- a/arch/mips/sni/rm200.c
+++ b/arch/mips/sni/rm200.c
@@ -404,7 +404,7 @@ void __init sni_rm200_i8259_irqs(void)
if (!rm200_pic_master)
return;
rm200_pic_slave = ioremap_nocache(0x160000a0, 4);
- if (!rm200_pic_master) {
+ if (!rm200_pic_slave) {
iounmap(rm200_pic_master);
return;
}
--
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: arch/x86/kvm: Correct NULL test
http://groups.google.com/group/linux.kernel/t/a313382705c8a57e?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 6 2010 12:50 am
From: Julia Lawall

From: Julia Lawall <julia@diku.dk>

msr was tested above, so the second test is not needed.

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

// <smpl>
@r@
expression *x;
expression e;
identifier l;
@@

if (x == NULL || ...) {
... when forall
return ...; }
... when != goto l;
when != x = e
when != &x
*x == NULL
// </smpl>

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

---
arch/x86/kvm/vmx.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 7375ae1..422bfc8 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1609,8 +1609,6 @@ static void vmx_set_efer(struct kvm_vcpu *vcpu, u64 efer)
*/
vmx_load_host_state(to_vmx(vcpu));
vcpu->arch.shadow_efer = efer;
- if (!msr)
- return;
if (efer & EFER_LMA) {
vmcs_write32(VM_ENTRY_CONTROLS,
vmcs_read32(VM_ENTRY_CONTROLS) |
--
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/xfs: Correct NULL test
http://groups.google.com/group/linux.kernel/t/0097fa3744fa7f81?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 6 2010 12:50 am
From: Julia Lawall

From: Julia Lawall <julia@diku.dk>

Test the value that was just allocated rather than the previously tested one.

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

// <smpl>
@r@
expression *x;
expression e;
identifier l;
@@

if (x == NULL || ...) {
... when forall
return ...; }
... when != goto l;
when != x = e
when != &x
*x == NULL
// </smpl>

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

---
fs/xfs/quota/xfs_qm.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/xfs/quota/xfs_qm.c b/fs/xfs/quota/xfs_qm.c
index 11cfd82..4318cd5 100644
--- a/fs/xfs/quota/xfs_qm.c
+++ b/fs/xfs/quota/xfs_qm.c
@@ -123,7 +123,7 @@ xfs_Gqm_init(void)
goto out;

gdqhash = kmem_zalloc_large(hsize);
- if (!udqhash)
+ if (!gdqhash)
goto out_free_udqhash;

hsize /= sizeof(xfs_dqhash_t);
--
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: [PATCH] Fix 'flush_old_exec()/setup_new_exec()' split
http://groups.google.com/group/linux.kernel/t/2f9cdd3703562232?hl=en
==============================================================================

== 1 of 4 ==
Date: Sat, Feb 6 2010 12:50 am
From: Greg KH

On Thu, Feb 04, 2010 at 08:32:32PM +0100, Sven Joachim wrote:
> On 2010-02-04 19:57 +0100, Greg KH wrote:
>
> > On Thu, Feb 04, 2010 at 07:46:30PM +0100, Sven Joachim wrote:
> >> It seems they are all there, but on my system with 64-bit kernel and
> >> 32-bit userland, 2.6.32.8-rc1 still panics in the way noticed by Ben.
> >
> > Does 2.6.33-rc6 also cause you the same problem?
>
> A build from Linus' current git tree (commit 7ab02af42 was added after
> 2.6.33-rc6, so I skipped that version) does not show the problem.
> Actually, I'm using it right now.

I think this was the sysctl issue, and have released a 2.6.32.8-rc2.
Can you test that to verify if it fixes your crash or not?

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 4 ==
Date: Sat, Feb 6 2010 1:30 am
From: Sven Joachim

On 2010-02-06 09:49 +0100, Greg KH wrote:

> I think this was the sysctl issue, and have released a 2.6.32.8-rc2.
> Can you test that to verify if it fixes your crash or not?

Yes, it fixes the issue. I'm using -rc2 right now, did not notice any
problems so far.

Sven
--
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 4 ==
Date: Sat, Feb 6 2010 1:40 am
From: Willy Tarreau

On Sat, Feb 06, 2010 at 10:21:48AM +0100, Sven Joachim wrote:
> On 2010-02-06 09:49 +0100, Greg KH wrote:
>
> > I think this was the sysctl issue, and have released a 2.6.32.8-rc2.
> > Can you test that to verify if it fixes your crash or not?
>
> Yes, it fixes the issue. I'm using -rc2 right now, did not notice any
> problems so far.

FWIW, it's running fine here too. I've tried to boot on a miniature
init launcher I have (statically linked one) and did not have any issue.

Willy

== 4 of 4 ==
Date: Sat, Feb 6 2010 2:00 am
From: Greg KH

On Sat, Feb 06, 2010 at 10:31:44AM +0100, Willy Tarreau wrote:
> On Sat, Feb 06, 2010 at 10:21:48AM +0100, Sven Joachim wrote:
> > On 2010-02-06 09:49 +0100, Greg KH wrote:
> >
> > > I think this was the sysctl issue, and have released a 2.6.32.8-rc2.
> > > Can you test that to verify if it fixes your crash or not?
> >
> > Yes, it fixes the issue. I'm using -rc2 right now, did not notice any
> > problems so far.
>
> FWIW, it's running fine here too. I've tried to boot on a miniature
> init launcher I have (statically linked one) and did not have any issue.

Wonderful, thanks to both of you for letting me know. I feel a lot
better about this release now...

thanks,

==============================================================================
TOPIC: drivers/video/mbx: Correct NULL test
http://groups.google.com/group/linux.kernel/t/3394abc4b64fd482?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 6 2010 12:50 am
From: Julia Lawall

From: Julia Lawall <julia@diku.dk>

Test the value that was just allocated rather than the previously tested one.

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

// <smpl>
@r@
expression *x;
expression e;
identifier l;
@@

if (x == NULL || ...) {
... when forall
return ...; }
... when != goto l;
when != x = e
when != &x
*x == NULL
// </smpl>

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

---
drivers/video/mbx/mbxfb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/mbx/mbxfb.c b/drivers/video/mbx/mbxfb.c
index afea9ab..7140405 100644
--- a/drivers/video/mbx/mbxfb.c
+++ b/drivers/video/mbx/mbxfb.c
@@ -950,7 +950,7 @@ static int __devinit mbxfb_probe(struct platform_device *dev)

mfbi->fb_virt_addr = ioremap_nocache(mfbi->fb_phys_addr,
res_size(mfbi->fb_req));
- if (!mfbi->reg_virt_addr) {
+ if (!mfbi->fb_virt_addr) {
dev_err(&dev->dev, "failed to ioremap frame buffer\n");
ret = -EINVAL;
goto err4;
--
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/net: Correct NULL test
http://groups.google.com/group/linux.kernel/t/03f62149e888e4b4?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 6 2010 12:50 am
From: Julia Lawall

From: Julia Lawall <julia@diku.dk>

Test the value that was just allocated rather than the previously tested one.

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

// <smpl>
@r@
expression *x;
expression e;
identifier l;
@@

if (x == NULL || ...) {
... when forall
return ...; }
... when != goto l;
when != x = e
when != &x
*x == NULL
// </smpl>

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

---
drivers/net/ax88796.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ax88796.c b/drivers/net/ax88796.c
index 62d9c9c..1dd4403 100644
--- a/drivers/net/ax88796.c
+++ b/drivers/net/ax88796.c
@@ -921,7 +921,7 @@ static int ax_probe(struct platform_device *pdev)
size = (res->end - res->start) + 1;

ax->mem2 = request_mem_region(res->start, size, pdev->name);
- if (ax->mem == NULL) {
+ if (ax->mem2 == NULL) {
dev_err(&pdev->dev, "cannot reserve registers\n");
ret = -ENXIO;
goto exit_mem1;
--
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/dma: Correct NULL test
http://groups.google.com/group/linux.kernel/t/8891f0e31fe7b8fb?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 6 2010 12:50 am
From: Julia Lawall

From: Julia Lawall <julia@diku.dk>

cohd_fin has already been verified not to be NULL, so the argument to
BUG_ON cannot be true.

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

// <smpl>
@r@
expression *x;
expression e;
identifier l;
@@

if (x == NULL || ...) {
... when forall
return ...; }
... when != goto l;
when != x = e
when != &x
*x == NULL
// </smpl>

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

---
drivers/dma/coh901318.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/coh901318.c b/drivers/dma/coh901318.c
index b5f2ee0..64a9372 100644
--- a/drivers/dma/coh901318.c
+++ b/drivers/dma/coh901318.c
@@ -613,8 +613,6 @@ static void dma_tasklet(unsigned long data)
cohd_fin->pending_irqs--;
cohc->completed = cohd_fin->desc.cookie;

- BUG_ON(cohc->nbr_active_done && cohd_fin == NULL);
-
if (cohc->nbr_active_done == 0)
return;

--
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: arch/arm/plat-pxa: Correct NULL test
http://groups.google.com/group/linux.kernel/t/ee6c467db71078e3?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 6 2010 12:50 am
From: Julia Lawall

From: Julia Lawall <julia@diku.dk>

Test the value that was just allocated rather than the previously tested one.

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

// <smpl>
@r@
expression *x;
expression e;
identifier l;
@@

if (x == NULL || ...) {
... when forall
return ...; }
... when != goto l;
when != x = e
when != &x
*x == NULL
// </smpl>

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

---
arch/arm/plat-pxa/dma.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-pxa/dma.c b/arch/arm/plat-pxa/dma.c
index 2975798..bcfda50 100644
--- a/arch/arm/plat-pxa/dma.c
+++ b/arch/arm/plat-pxa/dma.c
@@ -244,7 +244,7 @@ static void pxa_dma_init_debugfs(void)

dbgfs_chan = kmalloc(sizeof(*dbgfs_state) * num_dma_channels,
GFP_KERNEL);
- if (!dbgfs_state)
+ if (!dbgfs_chan)
goto err_alloc;

chandir = debugfs_create_dir("channels", dbgfs_root);
--
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/block/drbd: Correct NULL test
http://groups.google.com/group/linux.kernel/t/c5739d4794f1d4f8?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 6 2010 12:50 am
From: Julia Lawall

From: Julia Lawall <julia@diku.dk>

Test the value that was just allocated rather than the previously tested one.

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

// <smpl>
@r@
expression *x;
expression e;
identifier l;
@@

if (x == NULL || ...) {
... when forall
return ...; }
... when != goto l;
when != x = e
when != &x
*x == NULL
// </smpl>

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

---
drivers/block/drbd/drbd_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c
index ab871e0..d0c38a6 100644
--- a/drivers/block/drbd/drbd_main.c
+++ b/drivers/block/drbd/drbd_main.c
@@ -2770,7 +2770,7 @@ static int drbd_create_mempools(void)

drbd_ee_mempool = mempool_create(number,
mempool_alloc_slab, mempool_free_slab, drbd_ee_cache);
- if (drbd_request_mempool == NULL)
+ if (drbd_ee_mempool == NULL)
goto Enomem;

/* drbd's page pool */
--
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/media: Correct NULL test
http://groups.google.com/group/linux.kernel/t/890056eb4e7c9cb5?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 6 2010 12:50 am
From: Julia Lawall

From: Julia Lawall <julia@diku.dk>

In each case, the NULL test has been performed already.

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

// <smpl>
@r@
expression *x;
expression e;
identifier l;
@@

if (x == NULL || ...) {
... when forall
return ...; }
... when != goto l;
when != x = e
when != &x
*x == NULL
// </smpl>

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

---
drivers/media/dvb/frontends/stv0900_core.c | 5 -----
drivers/media/video/cpia.c | 3 ---
2 files changed, 8 deletions(-)

diff --git a/drivers/media/dvb/frontends/stv0900_core.c b/drivers/media/dvb/frontends/stv0900_core.c
index 74791d5..9052a9b 100644
--- a/drivers/media/dvb/frontends/stv0900_core.c
+++ b/drivers/media/dvb/frontends/stv0900_core.c
@@ -1410,11 +1410,6 @@ static enum fe_stv0900_error stv0900_init_internal(struct dvb_frontend *fe,
return error;
}

- if (state->internal == NULL) {
- error = STV0900_INVALID_HANDLE;
- return error;
- }
-
intp = state->internal;

intp->demod_mode = p_init->demod_mode;
diff --git a/drivers/media/video/cpia.c b/drivers/media/video/cpia.c
index 551ddf2..933ae4c 100644
--- a/drivers/media/video/cpia.c
+++ b/drivers/media/video/cpia.c
@@ -3737,9 +3737,6 @@ static int cpia_mmap(struct file *file, struct vm_area_struct *vma)
if (size > FRAME_NUM*CPIA_MAX_FRAME_SIZE)
return -EINVAL;

- if (!cam || !cam->ops)
- return -ENODEV;
-
/* make this _really_ smp-safe */
if (mutex_lock_interruptible(&cam->busy_lock))
return -EINTR;
--
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: Correct NULL test
http://groups.google.com/group/linux.kernel/t/0332e810e7c025e4?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 6 2010 12:50 am
From: Julia Lawall

From: Julia Lawall <julia@diku.dk>

fcf is tested in the line just below, so the first test is not needed.

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

// <smpl>
@r@
expression *x;
expression e;
identifier l;
@@

if (x == NULL || ...) {
... when forall
return ...; }
... when != goto l;
when != x = e
when != &x
*x == NULL
// </smpl>

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

---
drivers/scsi/fcoe/libfcoe.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/fcoe/libfcoe.c b/drivers/scsi/fcoe/libfcoe.c
index 9823291..9b634bd 100644
--- a/drivers/scsi/fcoe/libfcoe.c
+++ b/drivers/scsi/fcoe/libfcoe.c
@@ -941,8 +941,6 @@ static void fcoe_ctlr_recv_clr_vlink(struct fcoe_ctlr *fip,
u32 desc_mask;

LIBFCOE_FIP_DBG(fip, "Clear Virtual Link received\n");
- if (!fcf)
- return;
if (!fcf || !fc_host_port_id(lport->host))
return;

--
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-2.6.32-directemp
http://groups.google.com/group/linux.kernel/t/1289ad64eeb0b4be?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Feb 6 2010 1:00 am
From: Greg KH

On Fri, Feb 05, 2010 at 04:26:42PM -0800, Chris Verges wrote:
> > Sorry, but no, this driver will not be accepted, as it can be done
> just
> > fine from userspace instead of a kernel driver, as discussed before.
>
> Hi Greg,
>
> Sounds good. I'll still be sending out an updated patch for anyone who
> is interested in a kernel driver. They're welcome to patch in the
> driver themselves.

That's great.

> I may be missing some key piece of information about libusb and usbfs,
> but it seems like it pushes a lot of the protocol communication off to
> the user app. So if there are several user apps that want to use the
> same USB device, they either need a userland library or to re-implement
> functionality; is that correct?

Yes, that is true.

> What I may be missing is the rationale behind pushing these drivers into
> userland libraries and having yet another entity in the FOSS world that
> is responsible for managing them. The kernel seems like an obvious
> clearinghouse for software/hardware interactions. Yes, there may be
> lots of drivers, but at least everyone knows where to go for them. But
> like I said before, I may be missing something.

No, you are correct. We want a driver in the kernel when it provides a
common interface to a class of devices (network, tty, video, etc.) For
devices like yours, there is no specific class in the kernel (well,
there is for hardware monitoring devices, but not for generic
thermometers.) So for that, you are going to write a custom userspace
program anyway to be reading the temp value from sysfs, so you might as
well just either use a library to talk to your device, or put it within
the application itself.

Hope this helps explain things,

== 2 of 2 ==
Date: Sat, Feb 6 2010 2:00 am
From: Bruno Prémont

On Thu, 04 February 2010 "Chris Verges" wrote:
> Attached is a patch for the QTI DirecTEMP USB thermometer &
> thermometer/hygrometer sensors. This patch is based on linux-2.6.32.
> Functionality has been verified against both hardware variants listed
> in the driver (0x0002 and 0x0006), as both monolithic and modular.
>
> When the QTI DirecTEMP sensor is connected to a system, the directemp
> driver adds appropriate sysfs entries for the sensor type(s)
> supported. Examples:
>
> # PID 0x0002 (temp only)
> /sys/bus/usb/devices/.../temp
>
> # PID 0x0006 (temp + relative humidity)
> /sys/bus/usb/devices/.../temp
> /sys/bus/usb/devices/.../rh
>
> Using a standard "cat" will display the value.

Wouldn't it make sense to make use of hardware monitoring interfaces so
lm_sensors could handle the sensor information? (added to CC)

This would also be a good reason to have the driver on kernel side
rather than somewhere in userspace.

Bruno
--
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: compat ioctl: fix some build warnings
http://groups.google.com/group/linux.kernel/t/a0a87243d6455b3a?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 6 2010 1:00 am
From: Arnd Bergmann

On Friday 05 February 2010, Andrew Morton wrote:
> Unfortunately that adds more code for something which cannot happen at
> runtime.
>
> I guess we could do this trick:
>
> --- a/fs/compat_ioctl.c~a
> +++ a/fs/compat_ioctl.c
> @@ -539,7 +539,7 @@ static int mt_ioctl_trans(unsigned int f
> kcmd = MTIOCPOS;
> karg = &pos;
> break;
> - case MTIOCGET32:
> + default: /* MTIOCGET32 */
> kcmd = MTIOCGET;
> karg = &get;
> break;
> @@ -657,7 +657,7 @@ static int raw_ioctl(unsigned fd, unsign
>
> switch (cmd) {
> case RAW_SETBIND:
> - case RAW_GETBIND: {
> + default: { /* RAW_GETBIND */
> struct raw_config_request req;
> mm_segment_t oldfs = get_fs();
>

Looks good to me. Actually, we could just kill the switch/case
statement in raw_ioctl entirely, but I wouldn't bother at this
point any more because there are already patches from both Al
and me to kill that function by moving it into drivers/char/raw.c

I need to check what happened to that patch and to the other
patches I have removing code form fs/compat_ioctl.c, they might
need to be updated before I can submit them for the next merge.

In the meantime,

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: [PATCH 4/5] pps: add parallel port PPS signal generator
http://groups.google.com/group/linux.kernel/t/5b7b716ca20e757a?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 6 2010 1:00 am
From: Alexander Gordeev

Hi Rodolfo,

I've accidentally found your email in the archives of linuxpps list.
Very strange that it didn't come to me directly because I was
subscribed...

В Fri, 5 Feb 2010 11:39:14 +0100
giometti at enneenne.com (Rodolfo Giometti) пишет:

> On Wed, Feb 03, 2010 at 11:56:50PM +0300, Alexander Gordeev wrote:
> > Add PPS signal generator which utilizes STROBE pin of a parallel
> > port to send PPS signals. It uses parport abstraction layer and
> > hrtimers to precisely control the signal.
>
> What this generators are used for?

This generator sends PPS signals over a parallel port from one computer
to another. So it's just doing what every PPS-capable GPS device does.
I use it to precisely synchronize time on several computers for
distributed real-time simulation. It has very strict timing conditions.

--
Alexander

==============================================================================
TOPIC: bitops: compile time optimization for hweight_long(CONSTANT)
http://groups.google.com/group/linux.kernel/t/f58ac10e7917a328?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 6 2010 1:40 am
From: Borislav Petkov

On Fri, Feb 05, 2010 at 01:54:42PM -0800, H. Peter Anvin wrote:
> On 02/05/2010 04:11 AM, Borislav Petkov wrote:
> > +
> > +unsigned int __arch_hweight16(unsigned int w)
> > +{
> > + unsigned int res = 0;
> > +
> > + asm volatile("xor %%dh, %%dh\n\t"
> > + __arch_hweight_alt(32)
> > + : "=di" (res)
> > + : "di" (w)
> > + : "ecx", "memory");
> > +
>
> This is wrong in more ways than I can shake a stick at.

Thanks for reviewing it though - how else would I learn :).

> a) "di" doesn't mean the DI register - it means the DX register (d) or
> an immediate (i). Since you don't have any reference to either %0 or %1
> in your code, you have no way of knowing which one it is. The
> constraint for the di register is "D".

right.

> b) On 32 bits, the first argument register is in %eax (with %edx used
> for the upper half of a 32-bit argument), but on 64 bits, the first
> argument is in %rdi, with the return still in %rax.

Sure, it is right there in arch/x86/include/asm/calling.h. Shame on me.

> c) You call a C function, but you don't clobber the set of registers
> that a C function would clobber. You either need to put the function in
> an assembly wrapper (which is better in the long run), or clobber the
> full set of registers that is clobbered by a C function (which is better
> in the short term) -- which is eax, edx, ecx on 32 bits, but rax, rdi,
> esi, rdx, rcx, r8, r9, r10, r11 on 64 bits.

I think you mean rsi instead of esi here.

Well, the example Brian pointed me to - __mutex_fastpath_lock - lists
the full set of clobbered registers. Please elaborate on the assembly
wrapper for the function, wouldn't I need to list all the clobbered
registers there too or am I missing something?

> d) On the other hand, you do *not* need a "memory" clobber.

Right, in this case we have all non-barrier like inlines so no memory
clobber, according to the comment above alternative() macro.

Thanks.

--
Regards/Gruss,
Boris.

-
Advanced Micro Devices, Inc.
Operating Systems Research Center
--
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, February 6, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts