* Re: linux-next: manual merge of the sound tree with the pxa tree
From: Ian Molton @ 2009-01-23 3:08 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Takashi Iwai, linux-next, Eric Miao, Mark Brown
In-Reply-To: <20090123140130.eba111dd.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi Takashi,
>
> Today's linux-next merge of the sound tree got a conflict in
> sound/soc/pxa/e800_wm9712.c between commit
> f638d6ae54b5dc1bbffaa1dd94cb288d989670af ("[ARM] pxa: remove unnecessary
> #include of pxa-regs.h and hardware.h") from the pxa tree and commit 0465c7aa6fbab89de820442aed449ceb8d9145a6 ("ASoC: machine driver for
> Toshiba e800") from the sound tree.
>
> Just overlapping context changes. I fixed it up (see below) and can
> carry the fix as necessary.
Looks good. If it needs acking, then
Acked-by: Ian Molton <ian@mnementh.co.uk>
-Ian
^ permalink raw reply
* linux-next: manual merge of the kmemcheck tree with the x86 tree
From: Stephen Rothwell @ 2009-01-23 4:44 UTC (permalink / raw)
To: Vegard Nossum, Pekka Enberg, Ingo Molnar; +Cc: linux-next, Nick Piggin
Hi all,
Today's linux-next merge of the kmemcheck tree got a conflict in
arch/x86/mm/fault.c between commit do_page_fault ("x86: optimise x86's
do_page_fault (C entry point for the page fault path)") from the x86 tree
and commit 787ecfaa503dc63ff1831ddc74b15dad49bace1d ("x86: add hooks for
kmemcheck") from the kmemcheck tree.
I fixed it up (see below) but it is worth a check. I can carry the fix
as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc arch/x86/mm/fault.c
index d3eee74,c73afbb..0000000
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@@ -806,7 -602,16 +807,14 @@@ void __kprobes do_page_fault(struct pt_
/* get the address */
address = read_cr2();
- si_code = SEGV_MAPERR;
-
+ /*
+ * Detect and handle instructions that would cause a page fault for
+ * both a tracked kernel page and a userspace page.
+ */
+ if(kmemcheck_active(regs))
+ kmemcheck_hide(regs);
+
- if (notify_page_fault(regs))
+ if (unlikely(notify_page_fault(regs)))
return;
if (unlikely(kmmio_fault(regs, address)))
return;
@@@ -829,12 -634,16 +837,16 @@@
#else
if (unlikely(address >= TASK_SIZE64)) {
#endif
- if (!(error_code & (PF_RSVD|PF_USER|PF_PROT)) &&
- vmalloc_fault(address) >= 0)
- return;
+ if (!(error_code & (PF_RSVD | PF_USER | PF_PROT))) {
+ if (vmalloc_fault(address) >= 0)
+ return;
+
+ if (kmemcheck_fault(regs, address, error_code))
+ return;
+ }
/* Can handle a stale RO->RW TLB */
- if (spurious_fault(address, error_code))
+ if (spurious_fault(error_code, address))
return;
/*
^ permalink raw reply
* linux-next: manual merge of the sparseirq tree with the cpus4096 tree
From: Stephen Rothwell @ 2009-01-23 5:09 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-next, Mike Travis, Yinghai Lu
Hi Ingo,
Today's linux-next merge of the sparseirq tree got a conflict in
kernel/irq/handle.c between commit
7f7ace0cda64c99599c23785f8979a072e118058 ("cpumask: update irq_desc to
use cpumask_var_t") from the cpus4096 tree and commit
d7e51e66899f95dabc89b4d4c6674a6e50fa37fc ("sparseirq: make some func to
be used with genirq") from the sparseirq tree.
I fixed it up (see below) and can carry the fix as necessary. I am not
sure if this needs something better.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc kernel/irq/handle.c
index 375d68c,48299a8..0000000
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@@ -236,8 -225,9 +237,10 @@@ int __init early_irq_init(void
for (i = 0; i < count; i++) {
desc[i].irq = i;
+ desc[i].kstat_irqs = kstat_irqs_all[i];
+ init_alloc_desc_masks(&desc[i], 0, true);
}
+
return arch_early_irq_init();
}
^ permalink raw reply
* linux-next: manual merge of the iommu tree with the kmemcheck tree
From: Stephen Rothwell @ 2009-01-23 5:39 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-next, FUJITA Tomonori, Vegard Nossum
Hi Ingo,
Today's linux-next merge of the iommu tree got a conflict in
arch/x86/include/asm/dma-mapping.h between commit
19dd5283c3b1f3f8abab705c23658403910dfe23 ("kmemcheck: add DMA hooks")
from the kmemcheck tree and commit
d7dff84053524186b139342ac66a4160ce6bb517 ("x86: remove map_single and
unmap_single in struct dma_mapping_ops") from the iommu tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc arch/x86/include/asm/dma-mapping.h
index e93265c,5a34780..0000000
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@@ -6,8 -6,8 +6,9 @@@
* documentation.
*/
+#include <linux/kmemcheck.h>
#include <linux/scatterlist.h>
+ #include <linux/dma-attrs.h>
#include <asm/io.h>
#include <asm/swiotlb.h>
#include <asm-generic/dma-coherent.h>
@@@ -91,13 -53,14 +54,15 @@@ extern void *dma_generic_alloc_coherent
static inline dma_addr_t
dma_map_single(struct device *hwdev, void *ptr, size_t size,
- int direction)
+ enum dma_data_direction dir)
{
- struct dma_mapping_ops *ops = get_dma_ops(hwdev);
+ struct dma_map_ops *ops = get_dma_ops(hwdev);
- BUG_ON(!valid_dma_direction(direction));
+ BUG_ON(!valid_dma_direction(dir));
+ kmemcheck_mark_initialized(ptr, size);
- return ops->map_single(hwdev, virt_to_phys(ptr), size, direction);
+ return ops->map_page(hwdev, virt_to_page(ptr),
+ (unsigned long)ptr & ~PAGE_MASK, size,
+ dir, NULL);
}
static inline void
^ permalink raw reply
* linux-next: proc tree build failure
From: Stephen Rothwell @ 2009-01-23 6:15 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: linux-next, Cyrill Gorcunov, David S. Miller, Eric W. Biederman
Hi Alexey,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
drivers/net/pppoe.c: In function 'pppoe_seq_open':
drivers/net/pppoe.c:1102: error: implicit declaration of function 'PDE_NET'
drivers/net/pppol2tp.c: In function 'pppol2tp_proc_open':
drivers/net/pppol2tp.c:2579: error: implicit declaration of function 'PDE_NET'
Caused by commits a6bcf1c1d38e0672db35e0d9f2504ac04ddf3ed5 ("net: pppoe -
introduce net-namespace functionality") and
4e9fb8016a351b5b9da7fea32bcfdbc9d836e421 ("net: pppol2tp - introduce
net-namespace functionality") from the net tree interacting with commit
0e6a2bfcbae4ee3cf770a6a5da203b4a336ff8ff ("proc 5/6: simplify network
namespace lookup") from the proc tree.
I added the following fix to the merge and can carry it as necessary.
I expect that there is a better fix for this, though. These are the only
references to PDE_NET outside fs/proc.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
index 798b8cf..3aabf92 100644
--- a/drivers/net/pppoe.c
+++ b/drivers/net/pppoe.c
@@ -1099,7 +1099,7 @@ static int pppoe_seq_open(struct inode *inode, struct file *file)
return err;
m = file->private_data;
- net = maybe_get_net(PDE_NET(PDE(inode)));
+ net = maybe_get_net(inode->i_sb->s_fs_info);
BUG_ON(!net);
m->private = net;
diff --git a/drivers/net/pppol2tp.c b/drivers/net/pppol2tp.c
index 056e22a..d21470f 100644
--- a/drivers/net/pppol2tp.c
+++ b/drivers/net/pppol2tp.c
@@ -2576,7 +2576,7 @@ static int pppol2tp_proc_open(struct inode *inode, struct file *file)
goto out;
pd = m->private;
- net = maybe_get_net(PDE_NET(PDE(inode)));
+ net = maybe_get_net(inode->i_sb->s_fs_info);
BUG_ON(!net);
pd->seq_net = net;
return 0;
^ permalink raw reply related
* Re: linux-next: proc tree build failure
From: Cyrill Gorcunov @ 2009-01-23 7:09 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Alexey Dobriyan, linux-next, David S. Miller, Eric W. Biederman
In-Reply-To: <20090123171515.a0af4f8b.sfr@canb.auug.org.au>
[Stephen Rothwell - Fri, Jan 23, 2009 at 05:15:15PM +1100]
| Hi Alexey,
|
| Today's linux-next build (powerpc ppc64_defconfig) failed like this:
|
| drivers/net/pppoe.c: In function 'pppoe_seq_open':
| drivers/net/pppoe.c:1102: error: implicit declaration of function 'PDE_NET'
| drivers/net/pppol2tp.c: In function 'pppol2tp_proc_open':
| drivers/net/pppol2tp.c:2579: error: implicit declaration of function 'PDE_NET'
|
| Caused by commits a6bcf1c1d38e0672db35e0d9f2504ac04ddf3ed5 ("net: pppoe -
| introduce net-namespace functionality") and
| 4e9fb8016a351b5b9da7fea32bcfdbc9d836e421 ("net: pppol2tp - introduce
| net-namespace functionality") from the net tree interacting with commit
| 0e6a2bfcbae4ee3cf770a6a5da203b4a336ff8ff ("proc 5/6: simplify network
| namespace lookup") from the proc tree.
|
| I added the following fix to the merge and can carry it as necessary.
|
| I expect that there is a better fix for this, though. These are the only
| references to PDE_NET outside fs/proc.
| --
| Cheers,
| Stephen Rothwell sfr@canb.auug.org.au
| http://www.canb.auug.org.au/~sfr/
|
| diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
| index 798b8cf..3aabf92 100644
| --- a/drivers/net/pppoe.c
| +++ b/drivers/net/pppoe.c
| @@ -1099,7 +1099,7 @@ static int pppoe_seq_open(struct inode *inode, struct file *file)
| return err;
|
| m = file->private_data;
| - net = maybe_get_net(PDE_NET(PDE(inode)));
| + net = maybe_get_net(inode->i_sb->s_fs_info);
| BUG_ON(!net);
| m->private = net;
|
| diff --git a/drivers/net/pppol2tp.c b/drivers/net/pppol2tp.c
| index 056e22a..d21470f 100644
| --- a/drivers/net/pppol2tp.c
| +++ b/drivers/net/pppol2tp.c
| @@ -2576,7 +2576,7 @@ static int pppol2tp_proc_open(struct inode *inode, struct file *file)
| goto out;
|
| pd = m->private;
| - net = maybe_get_net(PDE_NET(PDE(inode)));
| + net = maybe_get_net(inode->i_sb->s_fs_info);
| BUG_ON(!net);
| pd->seq_net = net;
| return 0;
|
Hi Stephen,
thanks for catching this. Until I miss something --
s_fs_info for /proc is struct pid_namespace* right?
So maybe_get_net will convert it to net*, which is
not right I guess. On the other hand -- and PDE, and
PDE_NET is defined in proc_fs.h regardless if CONIG_PROC_FS
is turned on/off. Confused...
(to be fair -- this maybe_get_net(PDE_NET(PDE(inode))) is
taken from proc_net.c:get_proc_net, but to eliminate #ifdef
I reimplemented it, which is not good too -- maybe I've been
to put get_proc_net into some header, Eric?)
- Cyrill -
^ permalink raw reply
* linux-next: net tree build failure
From: Stephen Rothwell @ 2009-01-23 7:28 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-next, Stephen Hemminger
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
Hi Dave,
Today's linux-next build (powerpc allyesconfig) failed like this:
drivers/net/arcnet/com20020-pci.o:(.bss+0x10): multiple definition of `com20020_netdev_ops'
drivers/net/arcnet/com20020.o:(.data.rel.ro+0x0): first defined here
The immediate cause is commit a1799af4d7deefccdaa9d222a886fa1373dbb49a
("com20020: convert to net_devic_ops") which I have reverted for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: Tree for January 23
From: Stephen Rothwell @ 2009-01-23 7:48 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 7685 bytes --]
Hi all,
News: I will be on leave next week, so there will probably be no
linux-next release until Feb 2.
Changes since 20090122:
Undropped trees:
quota
ide
Dropped trees (temporarily):
cpu_alloc (build problem)
audit (difficult conflicts)
I merged the mfd tree immediately after Linus' tree instead of applying
the build fix patch it has.
The driver-core.current tree lost its build failure.
The tip-core tree gained a conflict against the x86 tree.
The cpus4096 tree lost its conflict.
The quota tree lost its build failure.
The ide tree lost its build failure.
The net tree gained a build failure for which I reverted a commit.
The sound tree gained a conflict against the pxa tree.
The kmemcheck tree lost a conflict, but gained another against the x86 tree.
The sparseirq tree gained a conflict against the cpus4096 tree.
The iommu tree gained a conflict against the kmemcheck tree.
The proc tree gained a build failure due to interaction with the net tree.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig,
ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES) and
i386, sparc and sparc64 defconfig.
Below is a summary of the state of the merge.
We are up to 132 trees (counting Linus' and 18 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging mfd/for-next
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging dwmw2/master
Merging arm/devel
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
CONFLICT (delete/modify): arch/m68knommu/include/asm/Kbuild deleted in m68knommu/for-next and modified in HEAD. Version HEAD of arch/m68knommu/include/asm/Kbuild left in tree.
$ git rm -f arch/m68knommu/include/asm/Kbuild
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging pxa/for-next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
Merging xtensa/master
Merging quilt/driver-core
Merging quilt/usb
Merging tip-core/auto-core-next
CONFLICT (content): Merge conflict in arch/x86/kernel/setup_percpu.c
Merging cpus4096/auto-cpus4096-next
Merging ftrace/auto-ftrace-next
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
Merging pci/linux-next
Merging quilt/device-mapper
Merging hid/for-next
Merging quilt/i2c
CONFLICT (content): Merge conflict in arch/arm/configs/magician_defconfig
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging quota/for_next
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
Merging infiniband/for-next
Merging acpi/test
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging ocfs2/linux-next
Merging ext4/next
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging mtd/master
Merging wireless/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
CONFLICT (content): Merge conflict in sound/soc/pxa/e800_wm9712.c
Merging cpufreq/next
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
Merging v9fs/for-next
Merging quilt/rr
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging bkl-removal/bkl-removal
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
CONFLICT (content): Merge conflict in mm/slob.c
Merging uclinux/for-next
Merging md/for-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in arch/x86/mm/fault.c
Merging generic-ipi/auto-generic-ipi-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging quilt/ttydev
Merging agp/agp-next
Merging oprofile/auto-oprofile-next
Merging fastboot/auto-fastboot-next
Merging sparseirq/auto-sparseirq-next
CONFLICT (content): Merge conflict in kernel/irq/handle.c
Merging iommu/auto-iommu-next
CONFLICT (content): Merge conflict in arch/x86/include/asm/dma-mapping.h
Merging uwb/for-upstream
Merging watchdog/master
Merging proc/proc
CONFLICT (content): Merge conflict in security/selinux/hooks.c
Applying: proc: fixup for pppoe changes
Merging bdev/master
Merging dwmw2-iommu/master
CONFLICT (content): Merge conflict in drivers/pci/intel-iommu.c
CONFLICT (content): Merge conflict in include/linux/dma_remapping.h
Merging cputime/cputime
Merging osd/linux-next
Merging fatfs/master
Merging fuse/for-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging squashfs/master
Merging omap/for-next
Merging kmemleak/kmemleak
CONFLICT (content): Merge conflict in include/linux/slab.h
CONFLICT (content): Merge conflict in init/main.c
CONFLICT (content): Merge conflict in mm/slab.c
CONFLICT (content): Merge conflict in mm/slob.c
CONFLICT (content): Merge conflict in mm/slub.c
CONFLICT (content): Merge conflict in mm/vmalloc.c
Merging quilt/staging
Merging scsi-post-merge/master
Created commit 0e7a536: Revert "com20020: convert to net_devic_ops"
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: net tree build failure
From: David Miller @ 2009-01-23 7:56 UTC (permalink / raw)
To: sfr; +Cc: linux-next, shemminger
In-Reply-To: <20090123182847.718fdb85.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 23 Jan 2009 18:28:47 +1100
> drivers/net/arcnet/com20020-pci.o:(.bss+0x10): multiple definition of `com20020_netdev_ops'
> drivers/net/arcnet/com20020.o:(.data.rel.ro+0x0): first defined here
>
> The immediate cause is commit a1799af4d7deefccdaa9d222a886fa1373dbb49a
> ("com20020: convert to net_devic_ops") which I have reverted for today.
Does this patch fix it? I can't see any other way to end up
with a multiple definition like that.
diff --git a/include/linux/com20020.h b/include/linux/com20020.h
index 350afa7..5dcfb94 100644
--- a/include/linux/com20020.h
+++ b/include/linux/com20020.h
@@ -29,7 +29,7 @@
int com20020_check(struct net_device *dev);
int com20020_found(struct net_device *dev, int shared);
-const struct net_device_ops com20020_netdev_ops;
+extern const struct net_device_ops com20020_netdev_ops;
/* The number of low I/O ports used by the card. */
#define ARCNET_TOTAL_SIZE 8
^ permalink raw reply related
* Re: linux-next: net tree build failure
From: Stephen Rothwell @ 2009-01-23 8:01 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, shemminger
In-Reply-To: <20090122.235612.256786187.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 442 bytes --]
Hi Dave,
On Thu, 22 Jan 2009 23:56:12 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> Does this patch fix it? I can't see any other way to end up
> with a multiple definition like that.
It confused me as well (one of the defintions is in the bss and one in
ro-data). I will give your patch a try later tonight.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: net tree build failure
From: David Miller @ 2009-01-23 8:13 UTC (permalink / raw)
To: sfr; +Cc: linux-next, shemminger
In-Reply-To: <20090123190103.1420c62f.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 23 Jan 2009 19:01:03 +1100
> On Thu, 22 Jan 2009 23:56:12 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> >
> > Does this patch fix it? I can't see any other way to end up
> > with a multiple definition like that.
>
> It confused me as well (one of the defintions is in the bss and one in
> ro-data). I will give your patch a try later tonight.
Ok, if one was in the BSS then very likely my patch will fix
things.
Look forward to your test results :)
^ permalink raw reply
* Rebooting at boot: linux-next: Tree for January 22
From: Nico -telmich- Schottelius @ 2009-01-23 9:54 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML
In-Reply-To: <20090122180543.1ab0baa6.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 653 bytes --]
Hello!
Stephen Rothwell [Thu, Jan 22, 2009 at 06:05:43PM +1100]:
> Hi all,
>
> Changes since 20090121:
This kernel instantly reboots after being booted on the x200.
With 20090121 it booted, but suspend is still broken.
I'm back on 2.6.28-rc9-wl-denkbrett-24896-gf4f5c96, which almost
always suspends and wakes up: After some days of suspend/wakeup
this kernel also freezes.
I suspect there's more than one bug in the suspend code.
Sincerly,
Nico
--
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/
PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: net tree build failure
From: Stephen Rothwell @ 2009-01-23 10:21 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, shemminger
In-Reply-To: <20090123.001337.179440063.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]
Hi Dave,
On Fri, 23 Jan 2009 00:13:37 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> Ok, if one was in the BSS then very likely my patch will fix
> things.
>
> Look forward to your test results :)
>
I did some builds just using Debian Sid's native x86 gcc and binutils:
$ gcc --version
gcc (Debian 4.3.2-4) 4.3.3 20090119 (prerelease)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ as --version
GNU assembler (GNU Binutils for Debian) 2.18.0.20080103
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `i486-linux-gnu'.
Without your patch:
$ objdump -t com20020*.o | grep _ops
0000000000000000 g O .bss 00000000000000a8 com20020_netdev_ops
0000000000000000 g O .rodata 00000000000000a8 com20020_netdev_ops
So it is not powerpc specific. (The powerpc toolchain (gcc 4.3.2m
binutils 2.19) was built by me from gnu sources, so it is not Debian
specific either.)
With your patch:
$ objdump -t com20020*.o | grep _ops
0000000000000000 *UND* 0000000000000000 com20020_netdev_ops
0000000000000000 g O .rodata 00000000000000a8 com20020_netdev_ops
So, this could be a compiler bug?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: net tree build failure
From: Stephen Rothwell @ 2009-01-23 10:39 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, shemminger
In-Reply-To: <20090123212128.16cd5698.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 351 bytes --]
Hi again,
On Fri, 23 Jan 2009 21:21:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> So, this could be a compiler bug?
We pass -fno-common to gcc which seems to cause the (non-extern) const
variable to end up in the bss.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: net tree build failure
From: Stephen Rothwell @ 2009-01-23 10:50 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, shemminger
In-Reply-To: <20090123213927.61beb5b3.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]
On Fri, 23 Jan 2009 21:39:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi again,
>
> On Fri, 23 Jan 2009 21:21:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > So, this could be a compiler bug?
>
> We pass -fno-common to gcc which seems to cause the (non-extern) const
> variable to end up in the bss.
-fno-common
In C, allocate even uninitialized global variables in the data
section of the object file, rather than generating them as common
blocks. This has the effect that if the same variable is declared
(without "extern") in two different compilations, you will get an
error when you link them. The only reason this might be useful is
if you wish to verify that the program will work on other systems
which always work this way.
I don't know why we use this, but it seems to basically make using
"extern" on variables in header files compulsory. But it seems to be
moving the variable from *COM* to .bss rather than to .{ro}data as I would
expect from the description above.
Oh, well, easy to work around.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the sound tree with the pxa tree
From: Mark Brown @ 2009-01-23 11:31 UTC (permalink / raw)
To: Ian Molton; +Cc: Stephen Rothwell, Takashi Iwai, linux-next, Eric Miao
In-Reply-To: <49793496.2010908@mnementh.co.uk>
On Fri, Jan 23, 2009 at 03:08:06AM +0000, Ian Molton wrote:
> Stephen Rothwell wrote:
>> Just overlapping context changes. I fixed it up (see below) and can
>> carry the fix as necessary.
> Looks good. If it needs acking, then
> Acked-by: Ian Molton <ian@mnementh.co.uk>
Stephen's fix didn't apply directly to the ASoC tree so I've applied the
slightly different fix below which merges cleanly with the PXA commit
for me:
>From c91cf25ebfbf3a5b336cbaa46646d37dd3d33127 Mon Sep 17 00:00:00 2001
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date: Fri, 23 Jan 2009 11:23:32 +0000
Subject: [PATCH] ASoC: Fix merge with PXA tree
Fix a merge issue caused by context overlap.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
sound/soc/pxa/e800_wm9712.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/sound/soc/pxa/e800_wm9712.c b/sound/soc/pxa/e800_wm9712.c
index 78a1770..bc019cd 100644
--- a/sound/soc/pxa/e800_wm9712.c
+++ b/sound/soc/pxa/e800_wm9712.c
@@ -18,13 +18,10 @@
#include <sound/soc.h>
#include <sound/soc-dapm.h>
-#include <mach/pxa-regs.h>
-#include <mach/hardware.h>
+#include <asm/mach-types.h>
#include <mach/audio.h>
#include <mach/eseries-gpio.h>
-#include <asm/mach-types.h>
-
#include "../codecs/wm9712.h"
#include "pxa2xx-pcm.h"
#include "pxa2xx-ac97.h"
--
1.5.6.5
^ permalink raw reply related
* Re: linux-next: manual merge of the kmemcheck tree with the x86 tree
From: Pekka Enberg @ 2009-01-23 14:21 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Vegard Nossum, Ingo Molnar, linux-next, Nick Piggin
In-Reply-To: <20090123154409.e3d1cd1d.sfr@canb.auug.org.au>
Hi Stephen,
On Fri, 2009-01-23 at 15:44 +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the kmemcheck tree got a conflict in
> arch/x86/mm/fault.c between commit do_page_fault ("x86: optimise x86's
> do_page_fault (C entry point for the page fault path)") from the x86 tree
> and commit 787ecfaa503dc63ff1831ddc74b15dad49bace1d ("x86: add hooks for
> kmemcheck") from the kmemcheck tree.
>
> I fixed it up (see below) but it is worth a check. I can carry the fix
> as necessary.
Looks good to me. Vegard?
Pekka
^ permalink raw reply
* Re: linux-next: manual merge of the kmemcheck tree with the x86 tree
From: Ingo Molnar @ 2009-01-23 15:53 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Stephen Rothwell, Vegard Nossum, linux-next, Nick Piggin
In-Reply-To: <1232720514.6094.61.camel@penberg-laptop>
* Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> Hi Stephen,
>
> On Fri, 2009-01-23 at 15:44 +1100, Stephen Rothwell wrote:
> > Today's linux-next merge of the kmemcheck tree got a conflict in
> > arch/x86/mm/fault.c between commit do_page_fault ("x86: optimise x86's
> > do_page_fault (C entry point for the page fault path)") from the x86 tree
> > and commit 787ecfaa503dc63ff1831ddc74b15dad49bace1d ("x86: add hooks for
> > kmemcheck") from the kmemcheck tree.
> >
> > I fixed it up (see below) but it is worth a check. I can carry the fix
> > as necessary.
>
> Looks good to me. Vegard?
it's resolved in tip/master already.
Stephen, could you please only report conflict resolutions that you do if
they differ from the one done in tip/master? Or use tip/auto-latest that
has all these conflict resolutions integrated into a single package.
A lot of internal conflicts between -tip originated trees get reported
again and again as genuine conflicts - needlessly in 99% of the cases as
i've already done the conflict resolution myself days (sometimes weeks)
ahead of the linux-next resolution, and tested the end result in
tip/master.
Ingo
^ permalink raw reply
* Re: linux-next: proc tree build failure
From: Alexey Dobriyan @ 2009-01-23 18:48 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: Stephen Rothwell, linux-next, David S. Miller, Eric W. Biederman
In-Reply-To: <20090123070955.GA8491@localhost>
On Fri, Jan 23, 2009 at 10:09:55AM +0300, Cyrill Gorcunov wrote:
> [Stephen Rothwell - Fri, Jan 23, 2009 at 05:15:15PM +1100]
> | Hi Alexey,
> |
> | Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> |
> | drivers/net/pppoe.c: In function 'pppoe_seq_open':
> | drivers/net/pppoe.c:1102: error: implicit declaration of function 'PDE_NET'
> | drivers/net/pppol2tp.c: In function 'pppol2tp_proc_open':
> | drivers/net/pppol2tp.c:2579: error: implicit declaration of function 'PDE_NET'
> |
> | Caused by commits a6bcf1c1d38e0672db35e0d9f2504ac04ddf3ed5 ("net: pppoe -
> | introduce net-namespace functionality") and
> | 4e9fb8016a351b5b9da7fea32bcfdbc9d836e421 ("net: pppol2tp - introduce
> | net-namespace functionality") from the net tree interacting with commit
> | 0e6a2bfcbae4ee3cf770a6a5da203b4a336ff8ff ("proc 5/6: simplify network
> | namespace lookup") from the proc tree.
> |
> | I added the following fix to the merge and can carry it as necessary.
> |
> | I expect that there is a better fix for this, though. These are the only
> | references to PDE_NET outside fs/proc.
> | --
> | Cheers,
> | Stephen Rothwell sfr@canb.auug.org.au
> | http://www.canb.auug.org.au/~sfr/
> |
> | diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
> | index 798b8cf..3aabf92 100644
> | --- a/drivers/net/pppoe.c
> | +++ b/drivers/net/pppoe.c
> | @@ -1099,7 +1099,7 @@ static int pppoe_seq_open(struct inode *inode, struct file *file)
> | return err;
> |
> | m = file->private_data;
> | - net = maybe_get_net(PDE_NET(PDE(inode)));
> | + net = maybe_get_net(inode->i_sb->s_fs_info);
> | BUG_ON(!net);
> | m->private = net;
> |
> | diff --git a/drivers/net/pppol2tp.c b/drivers/net/pppol2tp.c
> | index 056e22a..d21470f 100644
> | --- a/drivers/net/pppol2tp.c
> | +++ b/drivers/net/pppol2tp.c
> | @@ -2576,7 +2576,7 @@ static int pppol2tp_proc_open(struct inode *inode, struct file *file)
> | goto out;
> |
> | pd = m->private;
> | - net = maybe_get_net(PDE_NET(PDE(inode)));
> | + net = maybe_get_net(inode->i_sb->s_fs_info);
> | BUG_ON(!net);
> | pd->seq_net = net;
> | return 0;
> |
>
> Hi Stephen,
>
> thanks for catching this. Until I miss something --
> s_fs_info for /proc is struct pid_namespace* right?
> So maybe_get_net will convert it to net*, which is
> not right I guess. On the other hand -- and PDE, and
> PDE_NET is defined in proc_fs.h regardless if CONIG_PROC_FS
> is turned on/off. Confused...
>
> (to be fair -- this maybe_get_net(PDE_NET(PDE(inode))) is
> taken from proc_net.c:get_proc_net, but to eliminate #ifdef
> I reimplemented it, which is not good too -- maybe I've been
> to put get_proc_net into some header, Eric?)
PDE_NET here is bogus. you should use seq_open_net/seq_release_net.
See how other code does this, plenty of examples.
^ permalink raw reply
* Re: linux-next: proc tree build failure
From: Cyrill Gorcunov @ 2009-01-23 19:26 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: Stephen Rothwell, linux-next, David S. Miller, Eric W. Biederman
In-Reply-To: <20090123184147.GA3340@x200.localdomain>
[Alexey Dobriyan - Fri, Jan 23, 2009 at 09:48:37PM +0300]
...
| > Hi Stephen,
| >
| > thanks for catching this. Until I miss something --
| > s_fs_info for /proc is struct pid_namespace* right?
| > So maybe_get_net will convert it to net*, which is
| > not right I guess. On the other hand -- and PDE, and
| > PDE_NET is defined in proc_fs.h regardless if CONIG_PROC_FS
| > is turned on/off. Confused...
| >
| > (to be fair -- this maybe_get_net(PDE_NET(PDE(inode))) is
| > taken from proc_net.c:get_proc_net, but to eliminate #ifdef
| > I reimplemented it, which is not good too -- maybe I've been
| > to put get_proc_net into some header, Eric?)
|
| PDE_NET here is bogus. you should use seq_open_net/seq_release_net.
| See how other code does this, plenty of examples.
|
The question is not in examples, I saw that code.
There is some problem with seq_open_net/seq_release_net --
I don't need additional private data for sequential files,
all I need is just a pointer (ie -- seq_file.private) which
is already allocated for seq_file structure itself. So
Alexey, why should I use seq_open_net then and ask for
additional memory which I don't need? (side note:
actually get_net/put_net is really needed here indeed).
- Cyrill -
^ permalink raw reply
* Re: linux-next: proc tree build failure
From: Cyrill Gorcunov @ 2009-01-23 19:41 UTC (permalink / raw)
To: Alexey Dobriyan, Stephen Rothwell, linux-next, David S. Miller,
Eric W. Biederman
In-Reply-To: <20090123192607.GF8491@localhost>
[Cyrill Gorcunov - Fri, Jan 23, 2009 at 10:26:07PM +0300]
| [Alexey Dobriyan - Fri, Jan 23, 2009 at 09:48:37PM +0300]
| ...
| | > Hi Stephen,
| | >
| | > thanks for catching this. Until I miss something --
| | > s_fs_info for /proc is struct pid_namespace* right?
| | > So maybe_get_net will convert it to net*, which is
| | > not right I guess. On the other hand -- and PDE, and
| | > PDE_NET is defined in proc_fs.h regardless if CONIG_PROC_FS
| | > is turned on/off. Confused...
| | >
| | > (to be fair -- this maybe_get_net(PDE_NET(PDE(inode))) is
| | > taken from proc_net.c:get_proc_net, but to eliminate #ifdef
| | > I reimplemented it, which is not good too -- maybe I've been
| | > to put get_proc_net into some header, Eric?)
| |
| | PDE_NET here is bogus. you should use seq_open_net/seq_release_net.
| | See how other code does this, plenty of examples.
| |
|
| The question is not in examples, I saw that code.
| There is some problem with seq_open_net/seq_release_net --
| I don't need additional private data for sequential files,
| all I need is just a pointer (ie -- seq_file.private) which
| is already allocated for seq_file structure itself. So
| Alexey, why should I use seq_open_net then and ask for
| additional memory which I don't need? (side note:
| actually get_net/put_net is really needed here indeed).
|
| - Cyrill -
On the other hand - Alexey could we 'teach' seq_open_net/seq_release_net
to handle 0 private size? So then I could be able to set
seq_file.private to NULL
and call seq_release_net without problems?
- Cyrill -
^ permalink raw reply
* Re: linux-next: proc tree build failure
From: Cyrill Gorcunov @ 2009-01-23 20:26 UTC (permalink / raw)
To: Alexey Dobriyan, Stephen Rothwell, linux-next, David S. Miller,
Eric W. Biederman
In-Reply-To: <20090123194109.GG8491@localhost>
[Cyrill Gorcunov - Fri, Jan 23, 2009 at 10:41:09PM +0300]
| [Cyrill Gorcunov - Fri, Jan 23, 2009 at 10:26:07PM +0300]
| | [Alexey Dobriyan - Fri, Jan 23, 2009 at 09:48:37PM +0300]
| | ...
| | | > Hi Stephen,
| | | >
| | | > thanks for catching this. Until I miss something --
| | | > s_fs_info for /proc is struct pid_namespace* right?
| | | > So maybe_get_net will convert it to net*, which is
| | | > not right I guess. On the other hand -- and PDE, and
| | | > PDE_NET is defined in proc_fs.h regardless if CONIG_PROC_FS
| | | > is turned on/off. Confused...
| | | >
| | | > (to be fair -- this maybe_get_net(PDE_NET(PDE(inode))) is
| | | > taken from proc_net.c:get_proc_net, but to eliminate #ifdef
| | | > I reimplemented it, which is not good too -- maybe I've been
| | | > to put get_proc_net into some header, Eric?)
| | |
| | | PDE_NET here is bogus. you should use seq_open_net/seq_release_net.
| | | See how other code does this, plenty of examples.
| | |
| |
| | The question is not in examples, I saw that code.
| | There is some problem with seq_open_net/seq_release_net --
| | I don't need additional private data for sequential files,
| | all I need is just a pointer (ie -- seq_file.private) which
| | is already allocated for seq_file structure itself. So
| | Alexey, why should I use seq_open_net then and ask for
| | additional memory which I don't need? (side note:
| | actually get_net/put_net is really needed here indeed).
| |
| | - Cyrill -
|
| On the other hand - Alexey could we 'teach' seq_open_net/seq_release_net
| to handle 0 private size? So then I could be able to set
| seq_file.private to NULL
| and call seq_release_net without problems?
|
| - Cyrill -
But if the only right way to play with this is to use seq_open/release_net
then I will change the PPPoX code. Alexey?
- Cyrill -
^ permalink raw reply
* Re: linux-next: Tree for January 23 (kvm)
From: Randy Dunlap @ 2009-01-23 20:34 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, avi
In-Reply-To: <20090123184826.f2c91472.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi all,
>
> News: I will be on leave next week, so there will probably be no
> linux-next release until Feb 2.
>
> Changes since 20090122:
kvm changes cause this build error on i386:
when kvm is built as module:
ERROR: "__moddi3" [arch/x86/kvm/kvm.ko] undefined!
or when kvm is built into the kernel image:
lapic.c:(.text+0x19276): undefined reference to `__moddi3'
I guess it's this line:
ns = ktime_to_ns(remaining) % apic->timer.period;
--
~Randy
^ permalink raw reply
* [PATCH] kmemtrace: fix printk format warnings
From: Randy Dunlap @ 2009-01-23 21:03 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, Eduard - Gabriel Munteanu
In-Reply-To: <20090123184826.f2c91472.sfr@canb.auug.org.au>
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix kmemtrace printk warnings:
kernel/trace/kmemtrace.c:142: warning: format '%4ld' expects type 'long int', but argument 3 has type 'size_t'
kernel/trace/kmemtrace.c:147: warning: format '%4ld' expects type 'long int', but argument 3 has type 'size_t'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
cc: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
---
kernel/trace/kmemtrace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20090123.orig/kernel/trace/kmemtrace.c
+++ linux-next-20090123/kernel/trace/kmemtrace.c
@@ -139,12 +139,12 @@ kmemtrace_print_alloc_compress(struct tr
return TRACE_TYPE_PARTIAL_LINE;
/* Requested */
- ret = trace_seq_printf(s, "%4ld ", entry->bytes_req);
+ ret = trace_seq_printf(s, "%4zd ", entry->bytes_req);
if (!ret)
return TRACE_TYPE_PARTIAL_LINE;
/* Allocated */
- ret = trace_seq_printf(s, "%4ld ", entry->bytes_alloc);
+ ret = trace_seq_printf(s, "%4zd ", entry->bytes_alloc);
if (!ret)
return TRACE_TYPE_PARTIAL_LINE;
^ permalink raw reply
* Re: linux-next: Tree for January 23 (drivers/watchdog/cpwd.c:411: error: 'inode' undeclared (first use in this function))
From: Alexey Dobriyan @ 2009-01-23 21:21 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, wim
In-Reply-To: <20090123184826.f2c91472.sfr@canb.auug.org.au>
On sparc:
drivers/watchdog/cpwd.c: In function 'cpwd_ioctl':
drivers/watchdog/cpwd.c:411: error: 'inode' undeclared (first use in this function)
drivers/watchdog/cpwd.c:411: error: (Each undeclared identifier is reported only once
drivers/watchdog/cpwd.c:411: error: for each function it appears in.)
drivers/watchdog/cpwd.c: In function 'cpwd_compat_ioctl':
drivers/watchdog/cpwd.c:483: warning: passing argument 1 of 'cpwd_ioctl' from incompatible pointer type
drivers/watchdog/cpwd.c:483: warning: passing argument 2 of 'cpwd_ioctl' makes integer from pointer without a cast
drivers/watchdog/cpwd.c:483: error: too many arguments to function 'cpwd_ioctl'
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
drivers/watchdog/cpwd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/watchdog/cpwd.c
+++ b/drivers/watchdog/cpwd.c
@@ -402,6 +402,7 @@ static int cpwd_release(struct inode *inode, struct file *file)
static long cpwd_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
+ struct inode *inode = file->f_path.dentry->d_inode;
static struct watchdog_info info = {
.options = WDIOF_SETTIMEOUT,
.firmware_version = 1,
@@ -480,7 +481,7 @@ static long cpwd_compat_ioctl(struct file *file, unsigned int cmd,
case WIOCSTOP:
case WIOCGSTAT:
lock_kernel();
- rval = cpwd_ioctl(file->f_path.dentry->d_inode, file, cmd, arg);
+ rval = cpwd_ioctl(file, cmd, arg);
unlock_kernel();
break;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox