* Re: [PATCH 06/11] rt2x00: do not use PCI resources before pci_enable_device()
From: Gertjan van Wingerde @ 2010-08-03 16:14 UTC (permalink / raw)
To: Kulikov Vasiliy
Cc: kernel-janitors, Ivo van Doorn, John W. Linville, Helmut Schaa,
Alban Browaeys, linux-wireless, users, netdev, linux-kernel
In-Reply-To: <1280850203-5532-1-git-send-email-segooon@gmail.com>
On Tue, Aug 3, 2010 at 5:43 PM, Kulikov Vasiliy <segooon@gmail.com> wrote:
> IRQ and resource[] may not have correct values until
> after PCI hotplug setup occurs at pci_enable_device() time.
>
> The semantic match that finds this problem is as follows:
>
> // <smpl>
> @@
> identifier x;
> identifier request ~= "pci_request.*|pci_resource.*";
> @@
>
> (
> * x->irq
> |
> * x->resource
> |
> * request(x, ...)
> )
> ...
> *pci_enable_device(x)
> // </smpl>
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Good catch.
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2x00pci.c | 21 ++++++++++-----------
> 1 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00pci.c b/drivers/net/wireless/rt2x00/rt2x00pci.c
> index 19b262e..63c2cc4 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00pci.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00pci.c
> @@ -240,16 +240,16 @@ int rt2x00pci_probe(struct pci_dev *pci_dev, const struct pci_device_id *id)
> struct rt2x00_dev *rt2x00dev;
> int retval;
>
> - retval = pci_request_regions(pci_dev, pci_name(pci_dev));
> + retval = pci_enable_device(pci_dev);
> if (retval) {
> - ERROR_PROBE("PCI request regions failed.\n");
> + ERROR_PROBE("Enable device failed.\n");
> return retval;
> }
>
> - retval = pci_enable_device(pci_dev);
> + retval = pci_request_regions(pci_dev, pci_name(pci_dev));
> if (retval) {
> - ERROR_PROBE("Enable device failed.\n");
> - goto exit_release_regions;
> + ERROR_PROBE("PCI request regions failed.\n");
> + goto exit_disable_device;
> }
>
> pci_set_master(pci_dev);
> @@ -260,14 +260,14 @@ int rt2x00pci_probe(struct pci_dev *pci_dev, const struct pci_device_id *id)
> if (dma_set_mask(&pci_dev->dev, DMA_BIT_MASK(32))) {
> ERROR_PROBE("PCI DMA not supported.\n");
> retval = -EIO;
> - goto exit_disable_device;
> + goto exit_release_regions;
> }
>
> hw = ieee80211_alloc_hw(sizeof(struct rt2x00_dev), ops->hw);
> if (!hw) {
> ERROR_PROBE("Failed to allocate hardware.\n");
> retval = -ENOMEM;
> - goto exit_disable_device;
> + goto exit_release_regions;
> }
>
> pci_set_drvdata(pci_dev, hw);
> @@ -300,13 +300,12 @@ exit_free_reg:
> exit_free_device:
> ieee80211_free_hw(hw);
>
> -exit_disable_device:
> - if (retval != -EBUSY)
> - pci_disable_device(pci_dev);
> -
> exit_release_regions:
> pci_release_regions(pci_dev);
>
> +exit_disable_device:
> + pci_disable_device(pci_dev);
> +
> pci_set_drvdata(pci_dev, NULL);
>
> return retval;
> --
> 1.7.0.4
>
>
^ permalink raw reply
* Re: [PATCH] can-raw: Fix skb_orphan_try handling
From: Patrick Ohly @ 2010-08-03 16:14 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: David Miller, eric.dumazet@gmail.com, netdev@vger.kernel.org,
socketcan-core@lists.berlios.de, matthias.fuchs@esd.eu
In-Reply-To: <4C583447.8010004@hartkopp.net>
On Tue, 2010-08-03 at 18:22 +0300, Oliver Hartkopp wrote:
> >> The flags are tested all together in skb_orphan_try() ...
> >
> > This is why I hate using unions in situations like this... it makes
> > code impossible to audit easily.
> >
> > This damn thing should just be a "u8 flags" and a bunch of bit mask
> > CPP macro defines for the various boolean values.
>
> Yep! I also felt like this.
>
> Maybe Patrick Ohly can give some feedback, if he's ok with that kind of
> change. So far there are only a few places that would need to be changed for
> the flags bitops.
I'm fine with using a simple u8. I'm not sure where I picked up the
union thing, it's not something that I usually do in my own code.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
^ permalink raw reply
* Re: [ANNOUNCE]: Release of iptables-1.4.9
From: Gabor Z. Papp @ 2010-08-03 16:34 UTC (permalink / raw)
To: Patrick McHardy
Cc: Netfilter Development Mailinglist, Linux Netdev List,
'netfilter@vger.kernel.org', netfilter-announce
In-Reply-To: <4C5832F9.50004@trash.net>
* Patrick McHardy <kaber@trash.net>:
| iptables version 1.4.9
make[2]: Entering directory `/home/gzp/src/iptables-1.4.9'
/bin/sh ./libtool --tag=CC --mode=link gcc -D_LARGEFILE_SOURCE=1
-D_LARGE_FILES -D_FILE_OFFSET_BITS=64 -D_REENTRANT -Wall
-Waggregate-return -Wmissing-declarations -Wmissing-prototypes
-Wredundant-decls -Wshadow -Wstrict-prototypes -Winline -pipe
-DXTABLES_LIBDIR=\"/pkg/lib/xtables\" -DXTABLES_INTERNAL -I./include
-I./include -DIPTABLES_MULTI -DALL_INCLUSIVE -g -O2 -rdynamic -o
iptables-multi iptables_multi-iptables-multi.o
iptables_multi-iptables-save.o iptables_multi-iptables-restore.o
iptables_multi-iptables-xml.o iptables_multi-iptables-standalone.o
iptables_multi-iptables.o iptables_multi-xshared.o libiptc/libip4tc.la
extensions/libext4.a libxtables.la -lm
libtool: link: gcc -D_LARGEFILE_SOURCE=1 -D_LARGE_FILES
-D_FILE_OFFSET_BITS=64 -D_REENTRANT -Wall -Waggregate-return
-Wmissing-declarations -Wmissing-prototypes -Wredundant-decls -Wshadow
-Wstrict-prototypes -Winline -pipe
-DXTABLES_LIBDIR=\"/pkg/lib/xtables\" -DXTABLES_INTERNAL -I./include
-I./include -DIPTABLES_MULTI -DALL_INCLUSIVE -g -O2 -rdynamic -o
iptables-multi iptables_multi-iptables-multi.o
iptables_multi-iptables-save.o iptables_multi-iptables-restore.o
iptables_multi-iptables-xml.o iptables_multi-iptables-standalone.o
iptables_multi-iptables.o iptables_multi-xshared.o
libiptc/.libs/libip4tc.a extensions/libext4.a ./.libs/libxtables.a -lm
collect2: ld terminated with signal 11 [Segmentation fault]
extensions/libext4.a(initext4.o): In function `init_extensions':
/home/gzp/src/iptables-1.4.9/extensions/initext4.c:138: undefined reference to `libxt_TEE_init'
make[2]: *** [iptables-multi] Error 1
[kernel]
Linux gzp1 2.6.32.17-gzp1 #1 SMP PREEMPT Tue Aug 3 17:17:10 CEST 2010
i686 GNU/Linux
[glibc]
GNU C Library stable release version 2.11.2, by Roland McGrath et al.
Compiled by GNU CC version 4.4.4.
Compiled on a Linux 2.6.34 system on 2010-06-01.
Native POSIX Threads Library by Ulrich Drepper et al
[gcc]
gcc (GCC) 4.4.4
[binutils]
GNU ld (Linux/GNU Binutils) 2.20.51.0.10.20100707
^ permalink raw reply
* Re: [ANNOUNCE]: Release of iptables-1.4.9
From: Patrick McHardy @ 2010-08-03 17:05 UTC (permalink / raw)
To: Gabor Z. Papp
Cc: Netfilter Development Mailinglist, Linux Netdev List,
'netfilter@vger.kernel.org', netfilter-announce
In-Reply-To: <x6bp9jy7sj@gzp>
Am 03.08.2010 18:34, schrieb Gabor Z. Papp:
> * Patrick McHardy <kaber@trash.net>:
>
> | iptables version 1.4.9
>
> ...
> libiptc/.libs/libip4tc.a extensions/libext4.a ./.libs/libxtables.a -lm
> collect2: ld terminated with signal 11 [Segmentation fault]
> extensions/libext4.a(initext4.o): In function `init_extensions':
> /home/gzp/src/iptables-1.4.9/extensions/initext4.c:138: undefined reference to `libxt_TEE_init'
> make[2]: *** [iptables-multi] Error 1
Did you use a git checkout/patch against 1.4.8 or the tar.bz2?
In case its the former, try running make clean, sh autogen.sh and
sh configure again before the build.
^ permalink raw reply
* Re: [PATCH] can-raw: Fix skb_orphan_try handling
From: Oliver Hartkopp @ 2010-08-03 17:11 UTC (permalink / raw)
To: Patrick Ohly
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, David Miller,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <1280852081.3266.834.camel-/oqbx4SGF9pV+x+AlpbFz62pdiUAq4bhAL8bYrjMMd8@public.gmane.org>
On 03.08.2010 18:14, Patrick Ohly wrote:
> On Tue, 2010-08-03 at 18:22 +0300, Oliver Hartkopp wrote:
>>>> The flags are tested all together in skb_orphan_try() ...
>>>
>>> This is why I hate using unions in situations like this... it makes
>>> code impossible to audit easily.
>>>
>>> This damn thing should just be a "u8 flags" and a bunch of bit mask
>>> CPP macro defines for the various boolean values.
>>
>> Yep! I also felt like this.
>>
>> Maybe Patrick Ohly can give some feedback, if he's ok with that kind of
>> change. So far there are only a few places that would need to be changed for
>> the flags bitops.
>
> I'm fine with using a simple u8. I'm not sure where I picked up the
> union thing, it's not something that I usually do in my own code.
>
:-)
Im currently busy until next week, would you like to provide a patch?
Regards,
Oliver
^ permalink raw reply
* Re: [ANNOUNCE]: Release of iptables-1.4.9
From: Gabor Z. Papp @ 2010-08-03 17:16 UTC (permalink / raw)
To: Patrick McHardy
Cc: Netfilter Development Mailinglist, Linux Netdev List,
'netfilter@vger.kernel.org', netfilter-announce
In-Reply-To: <4C584C63.8010607@trash.net>
* Patrick McHardy <kaber@trash.net>:
| Did you use a git checkout/patch against 1.4.8 or the tar.bz2?
| In case its the former, try running make clean, sh autogen.sh and
| sh configure again before the build.
Used the tarball, but tried git also:
/bin/sh ./libtool --tag=CC --mode=link gcc -D_LARGEFILE_SOURCE=1
-D_LARGE_FILES -D_FILE_OFFSET_BITS=64 -D_REENTRANT -Wall
-Waggregate-return -Wmissing-declarations -Wmissing-prototypes
-Wredundant-decls -Wshadow -Wstrict-prototypes -Winline -pipe
-DXTABLES_LIBDIR=\"/pkg/lib/xtables\" -DXTABLES_INTERNAL -I./include
-I./include -DIPTABLES_MULTI -DALL_INCLUSIVE -g -O2 -rdynamic -o
iptables-multi iptables_multi-iptables-multi.o
iptables_multi-iptables-save.o iptables_multi-iptables-restore.o
iptables_multi-iptables-xml.o iptables_multi-iptables-standalone.o
iptables_multi-iptables.o iptables_multi-xshared.o libiptc/libip4tc.la
extensions/libext4.a libxtables.la -lm
libtool: link: gcc -D_LARGEFILE_SOURCE=1 -D_LARGE_FILES
-D_FILE_OFFSET_BITS=64 -D_REENTRANT -Wall -Waggregate-return
-Wmissing-declarations -Wmissing-prototypes -Wredundant-decls -Wshadow
-Wstrict-prototypes -Winline -pipe
-DXTABLES_LIBDIR=\"/pkg/lib/xtables\" -DXTABLES_INTERNAL -I./include
-I./include -DIPTABLES_MULTI -DALL_INCLUSIVE -g -O2 -rdynamic -o
iptables-multi iptables_multi-iptables-multi.o
iptables_multi-iptables-save.o iptables_multi-iptables-restore.o
iptables_multi-iptables-xml.o iptables_multi-iptables-standalone.o
iptables_multi-iptables.o iptables_multi-xshared.o
libiptc/.libs/libip4tc.a extensions/libext4.a ./.libs/libxtables.a -lm
collect2: ld terminated with signal 11 [Segmentation fault]
extensions/libext4.a(initext4.o): In function `init_extensions':
/home/gzp/src/iptables/extensions/initext4.c:144: undefined reference to `libxt_IDLETIMER_init'
/home/gzp/src/iptables/extensions/initext4.c:145: undefined reference to `libxt_TEE_init'
make[2]: *** [iptables-multi] Error 1
Note the difference, new undefined reference: `libxt_IDLETIMER_init
^ permalink raw reply
* sunrpc: what prevents an xprt from being freed before task_cleanup runs?
From: Jeff Layton @ 2010-08-03 17:24 UTC (permalink / raw)
To: linux-nfs-u79uwXL29TY76Z2rM5mHXA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, bfields-uC3wQj2KruNg9hUCZPvPmw
We got a report recently about a panic in RHEL5 (2.6.18 based kernel).
The problem appears to be that a task_cleanup workqueue job ran and got
passed a pointer to an xprt that had been freed. The bug is here in
case anyone is interested in the details:
https://bugzilla.redhat.com/show_bug.cgi?id=611938
The situation seems to be pretty difficult to reproduce, but I don't
see anything that's intended to ensure that this doesn't occur in RHEL5
or mainline. The task_cleanup workqueue job doesn't hold a reference to
the xprt, and the job isn't canceled when the xprt is torn down.
Bruce had a look and suggested that we may need something like the
patch below (pasted in, so it probably won't apply correctly). I've
tested a backported version of it on RHEL5 and it seems to work fine.
Is it reasonable to cancel task_cleanup when destroying the xprt? Or,
am I missing something that should prevent this situation in mainline
(and perhaps isn't in RHEL5's kernel).
Any help is appreciated...
-----------------------------[snip]---------------------------------
diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
index dcd0132..2a1f664 100644
--- a/net/sunrpc/xprt.c
+++ b/net/sunrpc/xprt.c
@@ -1129,6 +1129,7 @@ static void xprt_destroy(struct kref *kref)
rpc_destroy_wait_queue(&xprt->sending);
rpc_destroy_wait_queue(&xprt->resend);
rpc_destroy_wait_queue(&xprt->backlog);
+ cancel_work_sync(&xprt->task_cleanup);
/*
* Tear down transport state and free the rpc_xprt
*/
-----------------------------[snip]---------------------------------
Thanks,
--
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [ANNOUNCE]: Release of iptables-1.4.9
From: Gabor Z. Papp @ 2010-08-03 17:25 UTC (permalink / raw)
To: Patrick McHardy
Cc: Netfilter Development Mailinglist, Linux Netdev List,
'netfilter@vger.kernel.org', netfilter-announce
In-Reply-To: <x6vd7rwrah@gzp>
* "Gabor Z. Papp" <gzp@papp.hu>:
| Note the difference, new undefined reference: `libxt_IDLETIMER_init
--disable-shared --enable-static configure options cause the problems.
--enable-shared --disable-static compiles fine, but I would like to
link against the static libs.
^ permalink raw reply
* Re: [ANNOUNCE]: Release of iptables-1.4.9
From: Michele Petrazzo - Unipex @ 2010-08-03 17:29 UTC (permalink / raw)
To: Gabor Z. Papp
Cc: Patrick McHardy, Netfilter Development Mailinglist,
Linux Netdev List, 'netfilter@vger.kernel.org',
netfilter-announce
In-Reply-To: <x6vd7rwrah@gzp>
Gabor Z. Papp wrote:
> * Patrick McHardy <kaber@trash.net>:
>
> | Did you use a git checkout/patch against 1.4.8 or the tar.bz2?
> | In case its the former, try running make clean, sh autogen.sh and
> | sh configure again before the build.
>
> Used the tarball, but tried git also:
>
Here git works. Or better, compile but I don't find the "iptables" command.
If I enable static compilation "configure --enable-static", I receive:
extensions/libext4.a(initext4.o): In function `init_extensions':
/home/devel/iptables/extensions/initext4.c:103: undefined reference to
`libxt_IDLETIMER_init'
/home/devel/iptables/extensions/initext4.c:137: undefined reference to
`libxt_TEE_ini
Michele
^ permalink raw reply
* Re: [PATCH] can-raw: Fix skb_orphan_try handling
From: Patrick Ohly @ 2010-08-03 17:33 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: David Miller, eric.dumazet@gmail.com, netdev@vger.kernel.org,
socketcan-core@lists.berlios.de, matthias.fuchs@esd.eu
In-Reply-To: <4C584DB2.8020406@hartkopp.net>
On Tue, 2010-08-03 at 10:11 -0700, Oliver Hartkopp wrote:
> > I'm fine with using a simple u8. I'm not sure where I picked up the
> > union thing, it's not something that I usually do in my own code.
> >
>
> :-)
>
> Im currently busy until next week, would you like to provide a patch?
Sorry, I have to pass. I'm busy elsewhere myself. MeeGo and
SyncEvolution plus real life consume all of my time nowadays.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
^ permalink raw reply
* Re: [PATCH] can-raw: Fix skb_orphan_try handling
From: Oliver Hartkopp @ 2010-08-03 17:50 UTC (permalink / raw)
To: Patrick Ohly
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, David Miller,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <1280856828.3266.839.camel-/oqbx4SGF9pV+x+AlpbFz62pdiUAq4bhAL8bYrjMMd8@public.gmane.org>
On 03.08.2010 19:33, Patrick Ohly wrote:
> On Tue, 2010-08-03 at 10:11 -0700, Oliver Hartkopp wrote:
>>> I'm fine with using a simple u8. I'm not sure where I picked up the
>>> union thing, it's not something that I usually do in my own code.
>>>
>>
>> :-)
>>
>> Im currently busy until next week, would you like to provide a patch?
>
> Sorry, I have to pass. I'm busy elsewhere myself. MeeGo and
> SyncEvolution plus real life consume all of my time nowadays.
Working for MeeGo is a good excuse ;-)
Will pick that task next week.
BR,
Oliver
^ permalink raw reply
* Re: [ANNOUNCE]: Release of iptables-1.4.9
From: Jan Engelhardt @ 2010-08-03 18:04 UTC (permalink / raw)
To: Gabor Z. Papp
Cc: Patrick McHardy, Netfilter Development Mailinglist,
Linux Netdev List, 'netfilter@vger.kernel.org',
netfilter-announce
In-Reply-To: <x6lj8nwqu4@gzp>
On Tuesday 2010-08-03 19:25, Gabor Z. Papp wrote:
>* "Gabor Z. Papp" <gzp@papp.hu>:
>
>| Note the difference, new undefined reference: `libxt_IDLETIMER_init
>
>--disable-shared --enable-static configure options cause the problems.
>
>--enable-shared --disable-static compiles fine, but I would like to
>link against the static libs.
(BTW, with --disable-shared you remove the possibility to use any .so
files whatsoever. You can use --enable-static --enable-shared to get
both "all in one binary" and ".so support".)
The following changes since commit 371cea299f0b2eb100b9fc9fb99089640d2d606f:
xtables: remove unnecessary cast (2010-08-03 19:56:11 +0200)
are available in the git repository at:
git://dev.medozas.de/iptables master
Jan Engelhardt (1):
build: fix static linking
extensions/libxt_IDLETIMER.c | 2 +-
extensions/libxt_TEE.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
[Actually there's also the "remove unnecessary cast" patch that is not
included in this listing, but merging that should be ok.]
parent 371cea299f0b2eb100b9fc9fb99089640d2d606f (v1.4.9-18-g371cea2)
commit 0428e5a6541c3f5eaaf683d8da9ea60c44eac4c7
Author: Jan Engelhardt <jengelh@medozas.de>
Date: Tue Aug 3 19:58:38 2010 +0200
build: fix static linking
Gabor Z. Papp noted this link-time error when configuring with
--enable-static:
extensions/libext4.a(initext4.o): In function "init_extensions":
extensions/initext4.c:144: undefined reference to "libxt_IDLETIMER_init"
extensions/initext4.c:145: undefined reference to "libxt_TEE_init"
Indeed, since the two modules did not use our special macro "_init"
(which expands to libxt_foo_init), initext4.c could not find them by
that name. Correct this.
References: http://marc.info/?l=netfilter&m=128085480927924&w=2
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
extensions/libxt_IDLETIMER.c | 2 +-
extensions/libxt_TEE.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/extensions/libxt_IDLETIMER.c b/extensions/libxt_IDLETIMER.c
index 12573a4..1562e02 100644
--- a/extensions/libxt_IDLETIMER.c
+++ b/extensions/libxt_IDLETIMER.c
@@ -132,7 +132,7 @@ static struct xtables_target idletimer_tg_reg = {
.extra_opts = idletimer_tg_opts,
};
-static __attribute__((constructor)) void idletimer_tg_ldr(void)
+void _init(void)
{
xtables_register_target(&idletimer_tg_reg);
}
diff --git a/extensions/libxt_TEE.c b/extensions/libxt_TEE.c
index f8e7fd1..e4c0607 100644
--- a/extensions/libxt_TEE.c
+++ b/extensions/libxt_TEE.c
@@ -195,7 +195,7 @@ static struct xtables_target tee_tg6_reg = {
.extra_opts = tee_tg_opts,
};
-static __attribute__((constructor)) void tee_tg_ldr(void)
+void _init(void)
{
xtables_register_target(&tee_tg_reg);
xtables_register_target(&tee_tg6_reg);
--
# Created with git-export-patch
^ permalink raw reply related
* Re: [ANNOUNCE]: Release of iptables-1.4.9
From: Gabor Z. Papp @ 2010-08-03 18:09 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Patrick McHardy, Netfilter Development Mailinglist,
Linux Netdev List, 'netfilter@vger.kernel.org',
netfilter-announce
In-Reply-To: <alpine.LSU.2.01.1008032001430.1519@obet.zrqbmnf.qr>
* Jan Engelhardt <jengelh@medozas.de>:
| (BTW, with --disable-shared you remove the possibility to use any .so
| files whatsoever. You can use --enable-static --enable-shared to get
| both "all in one binary" and ".so support".)
And how to force linking the binaries against the static libs?
| The following changes since commit 371cea299f0b2eb100b9fc9fb99089640d2d606f:
| xtables: remove unnecessary cast (2010-08-03 19:56:11 +0200)
| are available in the git repository at:
| git://dev.medozas.de/iptables master
Fixed, compiled fine.
^ permalink raw reply
* [GIT PULL] xen-netfront driver updates for 2.6.36
From: Jeremy Fitzhardinge @ 2010-08-03 18:11 UTC (permalink / raw)
To: David Miller
Cc: Linux Kernel Mailing List, NetDev, Xen-devel@lists.xensource.com,
Xu, Dongxiao
Hi Dave,
Here's a git branch with some updates to the Xen netfront driver, which
add a new "smartpoll" mode to the netfront backend protocol, which is
basically equivalent to interrupt mitigation. They've been in
linux-next for a week or so.
Do you want to take this via the net tree, or are you OK with me
submitting them directly?
Thanks,
J
The following changes since commit 74fca6a42863ffacaf7ba6f1936a9f228950f657:
Linux 2.6.31 (2009-09-09 15:13:59 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git upstream/netfront
Dongxiao Xu (1):
xen/netfront: Use smart polling instead of event notification.
Ian Campbell (2):
xen/rings: make protocol specific usage of shared sring explicit
xen/netfront: make protocol specific usage of shared sring explicit
drivers/net/xen-netfront.c | 114 ++++++++++++++++++++++++++++++++++++++-
include/xen/interface/io/ring.h | 11 ++++-
2 files changed, 122 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: [GIT PULL] xen-netfront driver updates for 2.6.36
From: Jeremy Fitzhardinge @ 2010-08-03 18:12 UTC (permalink / raw)
To: David Miller
Cc: Linux Kernel Mailing List, NetDev, Xen-devel@lists.xensource.com,
Xu, Dongxiao
In-Reply-To: <4C585BC8.5070203@goop.org>
On 08/03/2010 11:11 AM, Jeremy Fitzhardinge wrote:
> Hi Dave,
>
> Here's a git branch with some updates to the Xen netfront driver,
> which add a new "smartpoll" mode to the netfront backend protocol,
> which is basically equivalent to interrupt mitigation. They've been
> in linux-next for a week or so.
Oops, never mind.
They got left out of linux-next, and they have a merge conflict. I'll
sort it out and resubmit.
'Thanks,
J
^ permalink raw reply
* Re: [ANNOUNCE]: Release of iptables-1.4.9
From: Jan Engelhardt @ 2010-08-03 18:34 UTC (permalink / raw)
To: Gabor Z. Papp
Cc: Patrick McHardy, Netfilter Development Mailinglist,
Linux Netdev List, 'netfilter@vger.kernel.org',
netfilter-announce
In-Reply-To: <x6sk2vo9eq@gzp>
On Tuesday 2010-08-03 20:09, Gabor Z. Papp wrote:
>* Jan Engelhardt <jengelh@medozas.de>:
>
>| (BTW, with --disable-shared you remove the possibility to use any .so
>| files whatsoever. You can use --enable-static --enable-shared to get
>| both "all in one binary" and ".so support".)
>
>And how to force linking the binaries against the static libs?
What libs?
^ permalink raw reply
* [GIT PULL] xen-netfront driver updates for 2.6.36
From: Jeremy Fitzhardinge @ 2010-08-03 18:39 UTC (permalink / raw)
To: David Miller
Cc: Linux Kernel Mailing List, NetDev, Xen-devel@lists.xensource.com,
Xu, Dongxiao
Hi Dave,
OK, let's try that again.
Here's a git branch with some updates to the Xen netfront driver, which
add a new "smartpoll" mode to the netfront backend protocol, which is
basically equivalent to interrupt mitigation. This merges cleanly with
current linux-next (it previously just had a small constification conflict).
Do you want to take this via the net tree, or are you OK with me
submitting them directly?
Thanks,
J
The following changes since commit 9fe6206f400646a2322096b56c59891d530e8d51:
Linux 2.6.35 (2010-08-01 15:11:14 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
upstream/netfront
Dongxiao Xu (1):
xen/netfront: Use smart polling instead of event notification.
Ian Campbell (2):
xen/rings: make protocol specific usage of shared sring explicit
xen/netfront: make protocol specific usage of shared sring explicit
drivers/net/xen-netfront.c | 114
++++++++++++++++++++++++++++++++++++++-
include/xen/interface/io/ring.h | 11 ++++-
2 files changed, 122 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: sunrpc: what prevents an xprt from being freed before task_cleanup runs?
From: Trond Myklebust @ 2010-08-03 18:40 UTC (permalink / raw)
To: Jeff Layton
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
bfields-uC3wQj2KruNg9hUCZPvPmw
In-Reply-To: <20100803132453.4fa18444-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
On Tue, 2010-08-03 at 13:24 -0400, Jeff Layton wrote:
> We got a report recently about a panic in RHEL5 (2.6.18 based kernel).
> The problem appears to be that a task_cleanup workqueue job ran and got
> passed a pointer to an xprt that had been freed. The bug is here in
> case anyone is interested in the details:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=611938
>
> The situation seems to be pretty difficult to reproduce, but I don't
> see anything that's intended to ensure that this doesn't occur in RHEL5
> or mainline. The task_cleanup workqueue job doesn't hold a reference to
> the xprt, and the job isn't canceled when the xprt is torn down.
>
> Bruce had a look and suggested that we may need something like the
> patch below (pasted in, so it probably won't apply correctly). I've
> tested a backported version of it on RHEL5 and it seems to work fine.
>
> Is it reasonable to cancel task_cleanup when destroying the xprt? Or,
> am I missing something that should prevent this situation in mainline
> (and perhaps isn't in RHEL5's kernel).
>
> Any help is appreciated...
>
> -----------------------------[snip]---------------------------------
> diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
> index dcd0132..2a1f664 100644
> --- a/net/sunrpc/xprt.c
> +++ b/net/sunrpc/xprt.c
> @@ -1129,6 +1129,7 @@ static void xprt_destroy(struct kref *kref)
> rpc_destroy_wait_queue(&xprt->sending);
> rpc_destroy_wait_queue(&xprt->resend);
> rpc_destroy_wait_queue(&xprt->backlog);
> + cancel_work_sync(&xprt->task_cleanup);
> /*
> * Tear down transport state and free the rpc_xprt
> */
> -----------------------------[snip]---------------------------------
>
> Thanks,
How about doing a wait_on_bit_lock(&xprt->state, XPRT_LOCKED,...)
instead?
Cheers
Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: sunrpc: what prevents an xprt from being freed before task_cleanup runs?
From: Trond Myklebust @ 2010-08-03 18:49 UTC (permalink / raw)
To: Jeff Layton
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
bfields-uC3wQj2KruNg9hUCZPvPmw
In-Reply-To: <1280860815.9771.25.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
On Tue, 2010-08-03 at 14:40 -0400, Trond Myklebust wrote:
> On Tue, 2010-08-03 at 13:24 -0400, Jeff Layton wrote:
> > We got a report recently about a panic in RHEL5 (2.6.18 based kernel).
> > The problem appears to be that a task_cleanup workqueue job ran and got
> > passed a pointer to an xprt that had been freed. The bug is here in
> > case anyone is interested in the details:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=611938
> >
> > The situation seems to be pretty difficult to reproduce, but I don't
> > see anything that's intended to ensure that this doesn't occur in RHEL5
> > or mainline. The task_cleanup workqueue job doesn't hold a reference to
> > the xprt, and the job isn't canceled when the xprt is torn down.
> >
> > Bruce had a look and suggested that we may need something like the
> > patch below (pasted in, so it probably won't apply correctly). I've
> > tested a backported version of it on RHEL5 and it seems to work fine.
> >
> > Is it reasonable to cancel task_cleanup when destroying the xprt? Or,
> > am I missing something that should prevent this situation in mainline
> > (and perhaps isn't in RHEL5's kernel).
> >
> > Any help is appreciated...
> >
> > -----------------------------[snip]---------------------------------
> > diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
> > index dcd0132..2a1f664 100644
> > --- a/net/sunrpc/xprt.c
> > +++ b/net/sunrpc/xprt.c
> > @@ -1129,6 +1129,7 @@ static void xprt_destroy(struct kref *kref)
> > rpc_destroy_wait_queue(&xprt->sending);
> > rpc_destroy_wait_queue(&xprt->resend);
> > rpc_destroy_wait_queue(&xprt->backlog);
> > + cancel_work_sync(&xprt->task_cleanup);
> > /*
> > * Tear down transport state and free the rpc_xprt
> > */
> > -----------------------------[snip]---------------------------------
> >
> > Thanks,
>
> How about doing a wait_on_bit_lock(&xprt->state, XPRT_LOCKED,...)
> instead?
Hmm... On the other hand, since xprt_destroy() may get called from
inside the rpciod_workqueue, the wait_on_bit_lock() may end up
deadlocking.
Nevermind, then. Let's go with the cancel_work_sync().
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: sunrpc: what prevents an xprt from being freed before task_cleanup runs?
From: J. Bruce Fields @ 2010-08-03 18:48 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Jeff Layton, linux-nfs, netdev
In-Reply-To: <1280860815.9771.25.camel@heimdal.trondhjem.org>
On Tue, Aug 03, 2010 at 02:40:15PM -0400, Trond Myklebust wrote:
> On Tue, 2010-08-03 at 13:24 -0400, Jeff Layton wrote:
> > We got a report recently about a panic in RHEL5 (2.6.18 based kernel).
> > The problem appears to be that a task_cleanup workqueue job ran and got
> > passed a pointer to an xprt that had been freed. The bug is here in
> > case anyone is interested in the details:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=611938
> >
> > The situation seems to be pretty difficult to reproduce, but I don't
> > see anything that's intended to ensure that this doesn't occur in RHEL5
> > or mainline. The task_cleanup workqueue job doesn't hold a reference to
> > the xprt, and the job isn't canceled when the xprt is torn down.
> >
> > Bruce had a look and suggested that we may need something like the
> > patch below (pasted in, so it probably won't apply correctly). I've
> > tested a backported version of it on RHEL5 and it seems to work fine.
> >
> > Is it reasonable to cancel task_cleanup when destroying the xprt? Or,
> > am I missing something that should prevent this situation in mainline
> > (and perhaps isn't in RHEL5's kernel).
> >
> > Any help is appreciated...
> >
> > -----------------------------[snip]---------------------------------
> > diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
> > index dcd0132..2a1f664 100644
> > --- a/net/sunrpc/xprt.c
> > +++ b/net/sunrpc/xprt.c
> > @@ -1129,6 +1129,7 @@ static void xprt_destroy(struct kref *kref)
> > rpc_destroy_wait_queue(&xprt->sending);
> > rpc_destroy_wait_queue(&xprt->resend);
> > rpc_destroy_wait_queue(&xprt->backlog);
> > + cancel_work_sync(&xprt->task_cleanup);
> > /*
> > * Tear down transport state and free the rpc_xprt
> > */
> > -----------------------------[snip]---------------------------------
> >
> > Thanks,
>
> How about doing a wait_on_bit_lock(&xprt->state, XPRT_LOCKED,...)
> instead?
I'll believe you, but I don't get it: what guarantees that XPRT_LOCKED
isn't cleared while xprt_autoclose autoclose is still running?
--b.
^ permalink raw reply
* [PATCH] davinci_emac: Fix use after free in davinci_emac_remove
From: Stefan Weil @ 2010-08-03 18:53 UTC (permalink / raw)
To: netdev
Cc: Stefan Weil, David S. Miller, Chaithrika U S, Sriramakrishnan,
Kevin Hilman, linux-kernel
free_netdev finally calls kfree which makes the contents
of ndev and priv (private data contained in ndev) invalid.
So iounmap should be called before free_netdev.
Cc: David S. Miller <davem@davemloft.net>
Cc: Chaithrika U S <chaithrika@ti.com>
Cc: Sriramakrishnan <srk@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
---
drivers/net/davinci_emac.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 8cc8a43..866e6b8 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -2818,8 +2818,8 @@ static int __devexit davinci_emac_remove(struct platform_device *pdev)
release_mem_region(res->start, res->end - res->start + 1);
unregister_netdev(ndev);
- free_netdev(ndev);
iounmap(priv->remap_addr);
+ free_netdev(ndev);
clk_disable(emac_clk);
clk_put(emac_clk);
--
1.5.6.5
^ permalink raw reply related
* Re: sunrpc: what prevents an xprt from being freed before task_cleanup runs?
From: Trond Myklebust @ 2010-08-03 18:56 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Jeff Layton, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100803184856.GA31579-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
On Tue, 2010-08-03 at 14:48 -0400, J. Bruce Fields wrote:
> On Tue, Aug 03, 2010 at 02:40:15PM -0400, Trond Myklebust wrote:
> > On Tue, 2010-08-03 at 13:24 -0400, Jeff Layton wrote:
> > > We got a report recently about a panic in RHEL5 (2.6.18 based kernel).
> > > The problem appears to be that a task_cleanup workqueue job ran and got
> > > passed a pointer to an xprt that had been freed. The bug is here in
> > > case anyone is interested in the details:
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=611938
> > >
> > > The situation seems to be pretty difficult to reproduce, but I don't
> > > see anything that's intended to ensure that this doesn't occur in RHEL5
> > > or mainline. The task_cleanup workqueue job doesn't hold a reference to
> > > the xprt, and the job isn't canceled when the xprt is torn down.
> > >
> > > Bruce had a look and suggested that we may need something like the
> > > patch below (pasted in, so it probably won't apply correctly). I've
> > > tested a backported version of it on RHEL5 and it seems to work fine.
> > >
> > > Is it reasonable to cancel task_cleanup when destroying the xprt? Or,
> > > am I missing something that should prevent this situation in mainline
> > > (and perhaps isn't in RHEL5's kernel).
> > >
> > > Any help is appreciated...
> > >
> > > -----------------------------[snip]---------------------------------
> > > diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
> > > index dcd0132..2a1f664 100644
> > > --- a/net/sunrpc/xprt.c
> > > +++ b/net/sunrpc/xprt.c
> > > @@ -1129,6 +1129,7 @@ static void xprt_destroy(struct kref *kref)
> > > rpc_destroy_wait_queue(&xprt->sending);
> > > rpc_destroy_wait_queue(&xprt->resend);
> > > rpc_destroy_wait_queue(&xprt->backlog);
> > > + cancel_work_sync(&xprt->task_cleanup);
> > > /*
> > > * Tear down transport state and free the rpc_xprt
> > > */
> > > -----------------------------[snip]---------------------------------
> > >
> > > Thanks,
> >
> > How about doing a wait_on_bit_lock(&xprt->state, XPRT_LOCKED,...)
> > instead?
>
> I'll believe you, but I don't get it: what guarantees that XPRT_LOCKED
> isn't cleared while xprt_autoclose autoclose is still running?
Look more closely: the callers that enqueue task_cleanup on the
workqueue all ensure that XPRT_LOCKED is held, and it isn't released
until the call to xprt_release_write() at the very end of
xprt_autoclose().
The rpciod_workqueue deadlocking is an issue, though, so unfortunately,
we won't be able to make use of the above.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: sunrpc: what prevents an xprt from being freed before task_cleanup runs?
From: Jeff Layton @ 2010-08-03 18:59 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-nfs, netdev, bfields
In-Reply-To: <1280860815.9771.25.camel@heimdal.trondhjem.org>
On Tue, 03 Aug 2010 14:40:15 -0400
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> On Tue, 2010-08-03 at 13:24 -0400, Jeff Layton wrote:
> > We got a report recently about a panic in RHEL5 (2.6.18 based kernel).
> > The problem appears to be that a task_cleanup workqueue job ran and got
> > passed a pointer to an xprt that had been freed. The bug is here in
> > case anyone is interested in the details:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=611938
> >
> > The situation seems to be pretty difficult to reproduce, but I don't
> > see anything that's intended to ensure that this doesn't occur in RHEL5
> > or mainline. The task_cleanup workqueue job doesn't hold a reference to
> > the xprt, and the job isn't canceled when the xprt is torn down.
> >
> > Bruce had a look and suggested that we may need something like the
> > patch below (pasted in, so it probably won't apply correctly). I've
> > tested a backported version of it on RHEL5 and it seems to work fine.
> >
> > Is it reasonable to cancel task_cleanup when destroying the xprt? Or,
> > am I missing something that should prevent this situation in mainline
> > (and perhaps isn't in RHEL5's kernel).
> >
> > Any help is appreciated...
> >
> > -----------------------------[snip]---------------------------------
> > diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
> > index dcd0132..2a1f664 100644
> > --- a/net/sunrpc/xprt.c
> > +++ b/net/sunrpc/xprt.c
> > @@ -1129,6 +1129,7 @@ static void xprt_destroy(struct kref *kref)
> > rpc_destroy_wait_queue(&xprt->sending);
> > rpc_destroy_wait_queue(&xprt->resend);
> > rpc_destroy_wait_queue(&xprt->backlog);
> > + cancel_work_sync(&xprt->task_cleanup);
> > /*
> > * Tear down transport state and free the rpc_xprt
> > */
> > -----------------------------[snip]---------------------------------
> >
> > Thanks,
>
> How about doing a wait_on_bit_lock(&xprt->state, XPRT_LOCKED,...)
> instead?
>
I haven't quite grokked what XPRT_LOCKED is supposed to signify. What
would be the advantage of doing that over just killing off the
task_cleanup job? It seems like if we're tearing down the xprt then
waiting for task_cleanup to run is sort of pointless -- xs_destroy will
take care of closing the socket anyway.
Also, if we do go that route, do we need a wake_up_bit call in
xprt_clear_locked?
Thanks,
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply
* Vaše Mail Box kvóty překročí stanovený limit
From: Správce systému @ 2010-08-03 18:52 UTC (permalink / raw)
Vaše poštovní schránka překročila limit úložiště, které je 20GB,
jak nastavit váš správce, máte v současné době běží na
+20.9gigabajt,
Možná nebudete moci odesílat nebo přijímat novou poštu, dokud
re-ověření Vaší schránky.
Chcete-li znovu potvrdili svou poštovní schránku, klikněte prosím na
níže uvedený odkaz:
http://w3t.org/CJ6
Pokud výše uvedený odkaz nefunguje, prosím zkopírujte a vložte níže
uvedený odkaz okně prohlížeče
http://w3t.org/CJ6
Díky
Správce systému
^ permalink raw reply
* Re: softirq warnings when calling dev_kfree_skb_irq - bug in conntrack?
From: Jeremy Fitzhardinge @ 2010-08-03 19:16 UTC (permalink / raw)
To: David Miller
Cc: johannes, netdev, dongxiao.xu, Xen-devel, Ian.Campbell, kaber,
eric.dumazet
In-Reply-To: <20100803.002318.209965574.davem@davemloft.net>
On 08/03/2010 12:23 AM, David Miller wrote:
> From: Johannes Berg<johannes@sipsolutions.net>
> Date: Tue, 03 Aug 2010 09:04:34 +0200
>
>> I had this too:
>> http://article.gmane.org/gmane.linux.network/167590
>>
>> But I'm not convinced it's conntrack, I'd think it's
>>
>> commit 15e83ed78864d0625e87a85f09b297c0919a4797
>> Author: Eric Dumazet<eric.dumazet@gmail.com>
>> Date: Wed May 19 23:16:03 2010 +0000
>>
>> net: remove zap_completion_queue
>>
>> which, from the looks of it, ought to be reverted because it failed to
>> take into account that dev_kfree_skb() can do more things that require
>> non-irq-context than just calling skb->destructor, like for instance the
>> conntrack thing we see here.
> Agreed. I'll revert this and queue that up for 2.6.35-stable
Reverting this change fixes the problem for me.
Thanks,
J
^ 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