* Re: [patch] netns: let net_generic take pointer-to-const args
From: Eric Dumazet @ 2010-11-21 8:29 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: David S. Miller, netdev
In-Reply-To: <alpine.LNX.2.01.1011210506110.9636@obet.zrqbmnf.qr>
Le dimanche 21 novembre 2010 à 05:07 +0100, Jan Engelhardt a écrit :
> parent 2801f1c311f8388ea80d78555747d449b46ea90d (v2.6.37-rc1-225-g2801f1c)
> commit 381a4560f0062f5c1919f8199772d7af7281349e
> Author: Jan Engelhardt <jengelh@medozas.de>
> Date: Sun Nov 21 04:35:16 2010 +0100
>
> netns: let net_generic take pointer-to-const args
>
> This commit is same in nature as v2.6.37-rc1-755-g3654654; the network
> namespace itself is not modified when calling net_generic, so the
> parameter can be const.
>
> Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
> ---
> include/net/netns/generic.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/net/netns/generic.h b/include/net/netns/generic.h
> index 81a31c0..3419bf5 100644
> --- a/include/net/netns/generic.h
> +++ b/include/net/netns/generic.h
> @@ -30,7 +30,7 @@ struct net_generic {
> void *ptr[0];
> };
>
> -static inline void *net_generic(struct net *net, int id)
> +static inline void *net_generic(const struct net *net, int id)
> {
> struct net_generic *ng;
> void *ptr;
While you are at it you could also use
const struct net_generic *ng;
Just curious, if we could use __pure attribute as well.
^ permalink raw reply
* Re: [PATCH 60/62] rt2x00: Use static const
From: Gertjan van Wingerde @ 2010-11-21 8:58 UTC (permalink / raw)
To: Joe Perches
Cc: Ivo van Doorn, John W. Linville,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <d8bfaded20da2265673391a81536d63b0e81dc7f.1290305776.git.joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
On 11/21/10 03:39, Joe Perches wrote:
> Using static const generally increases object text and decreases data size.
> It also generally decreases overall object size.
>
> text data bss dec hex filename
> 40197 56 8336 48589 bdcd drivers/net/wireless/rt2x00/rt2800lib.o.new
> 40205 56 8336 48597 bdd5 drivers/net/wireless/rt2x00/rt2800lib.o.old
>
> Signed-off-by: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
For rt2x00 this is just a tiny optimization, but for what it's worth:
Acked-by: Gertjan van Wingerde <gwingerde-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/net/wireless/rt2x00/rt2800lib.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index ce8df66..7563161 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -2166,7 +2166,7 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
> SHARED_KEY_MODE_ENTRY(i), 0);
>
> for (i = 0; i < 256; i++) {
> - u32 wcid[2] = { 0xffffffff, 0x00ffffff };
> + static const u32 wcid[2] = { 0xffffffff, 0x00ffffff };
> rt2800_register_multiwrite(rt2x00dev, MAC_WCID_ENTRY(i),
> wcid, sizeof(wcid));
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* [net-2.6 PATCH] e1000: fix screaming IRQ
From: Jeff Kirsher @ 2010-11-21 10:48 UTC (permalink / raw)
To: davem
Cc: netdev, gospo, bphilips, Anupam Chanda, stable kernel,
Jesse Brandeburg, Jeff Kirsher
From: Anupam Chanda <anupamc@vmware.com>
VMWare reports that the e1000 driver has a bug when bringing down the
interface, such that interrupts are not disabled in the hardware but the
driver stops reporting that it consumed the interrupt.
The fix is to set the driver's "down" flag later in the routine,
after all the timers and such have exited, preventing the interrupt
handler from being called and exiting early without handling the
interrupt.
CC: Anupam Chanda <anupamc@vmware.com>
CC: stable kernel <stable@kernel.org>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000/e1000_main.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 4686c39..4d62f7b 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -31,7 +31,7 @@
char e1000_driver_name[] = "e1000";
static char e1000_driver_string[] = "Intel(R) PRO/1000 Network Driver";
-#define DRV_VERSION "7.3.21-k6-NAPI"
+#define DRV_VERSION "7.3.21-k8-NAPI"
const char e1000_driver_version[] = DRV_VERSION;
static const char e1000_copyright[] = "Copyright (c) 1999-2006 Intel Corporation.";
@@ -485,9 +485,6 @@ void e1000_down(struct e1000_adapter *adapter)
struct net_device *netdev = adapter->netdev;
u32 rctl, tctl;
- /* signal that we're down so the interrupt handler does not
- * reschedule our watchdog timer */
- set_bit(__E1000_DOWN, &adapter->flags);
/* disable receives in the hardware */
rctl = er32(RCTL);
@@ -508,6 +505,13 @@ void e1000_down(struct e1000_adapter *adapter)
e1000_irq_disable(adapter);
+ /*
+ * Setting DOWN must be after irq_disable to prevent
+ * a screaming interrupt. Setting DOWN also prevents
+ * timers and tasks from rescheduling.
+ */
+ set_bit(__E1000_DOWN, &adapter->flags);
+
del_timer_sync(&adapter->tx_fifo_stall_timer);
del_timer_sync(&adapter->watchdog_timer);
del_timer_sync(&adapter->phy_info_timer);
^ permalink raw reply related
* [net-next-2.6 PATCH] ixgbe: update version number for ixgbe
From: Jeff Kirsher @ 2010-11-21 11:07 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Don Skidmore, Jeff Kirsher
From: Don Skidmore <donald.c.skidmore@intel.com>
This will reflect addition of new X540 hardware
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 5409af3..0254195 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -52,7 +52,7 @@ char ixgbe_driver_name[] = "ixgbe";
static const char ixgbe_driver_string[] =
"Intel(R) 10 Gigabit PCI Express Network Driver";
-#define DRV_VERSION "2.0.84-k2"
+#define DRV_VERSION "3.0.12-k2"
const char ixgbe_driver_version[] = DRV_VERSION;
static char ixgbe_copyright[] = "Copyright (c) 1999-2010 Intel Corporation.";
^ permalink raw reply related
* Re: [PATCH] via-rhine: hardware VLAN support
From: Roger Luethi @ 2010-11-21 13:17 UTC (permalink / raw)
To: Jesse Gross; +Cc: netdev, David S. Miller
In-Reply-To: <AANLkTim40QH2AWz8YtW_y3=WjEU0_Rom9-CPFj-O5MCt@mail.gmail.com>
On Mon, 08 Nov 2010 12:53:57 -0800, Jesse Gross wrote:
> On Mon, Nov 8, 2010 at 8:21 AM, Roger Luethi <rl@hellgate.ch> wrote:
> > On Fri, 05 Nov 2010 11:31:56 -0700, Jesse Gross wrote:
> > Can you point me to a driver that has been switched to use the new methods
> > already? Is there some other form of documentation?
>
> bnx2 is an example of a driver that has been converted. The commit
> that actually made the change was
> 7d0fd2117e3d0550d7987b3aff2bfbc0244cf7c6, which should highlight the
> differences. A key point is that drivers should no longer reference
> vlan groups at all.
bnx2 does not support hardware VLAN filters, but ixgbe does (converted by
commit f62bbb5e62c6e4a91fb222d22bc46e8d4d7e59ef). ixgbe keeps a list of
configured VLANs in a device private data structure (active_vlans). Is that
the model to follow?
^ permalink raw reply
* Re: [PATCH 46/62] usb: Use static const
From: Sergei Shtylyov @ 2010-11-21 14:06 UTC (permalink / raw)
To: Joe Perches
Cc: Jan Dumon, Greg Kroah-Hartman, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <ed2a5bd07f07601ba12ce3c8fcbce2dd954c35aa.1290305776.git.joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
Hello.
On 21-11-2010 5:38, Joe Perches wrote:
> Using static const generally increases object text and decreases data size.
> It also generally decreases overall object size.
> text data bss dec hex filename
> 36120 312 9000 45432 b178 drivers/net/usb/hso.o.old
> 36043 312 9008 45363 b133 drivers/net/usb/hso.o.new
> Consolidate duplicated code into new fix_crc_bug function
> and declare data in that function static const.
> Signed-off-by: Joe Perches<joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
[...]
> diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
> index be8cc2a..c77d0ea 100644
> --- a/drivers/net/usb/hso.c
> +++ b/drivers/net/usb/hso.c
> @@ -1001,6 +1001,18 @@ static void packetizeRx(struct hso_net *odev, unsigned char *ip_pkt,
> }
> }
>
> +static void fix_crc_bug(struct urb *urb, __le16 max_packet_size)
> +{
> + static const u8 crc_check[4] = { 0xDE, 0xAD, 0xBE, 0xEF };
> + u32 rest = urb->actual_length % le16_to_cpu(max_packet_size);
> +
> + if (((rest == 5) || (rest == 6)) &&
> + !memcmp(((u8 *)urb->transfer_buffer) + urb->actual_length - 4,
Parens around '(u8 *)urb->transfer_buffer' not needed. Could get rid of
them, while at it...
> + crc_check, 4)) {
> + urb->actual_length -= 4;
> + }
> +}
> +
> /* Moving data from usb to kernel (in interrupt state) */
> static void read_bulk_callback(struct urb *urb)
> {
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* prize!@msn
From: customers_care_msn @ 2010-11-21 15:34 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: YOU HAVE WON A PRIZE-1 (Recovered).docx --]
[-- Type: application/octet-stream, Size: 159614 bytes --]
^ permalink raw reply
* [PROBLEM] WARNING: at kernel/exit.c:910 do_exit
From: Pekka Enberg @ 2010-11-21 15:35 UTC (permalink / raw)
To: oleg, Linus Torvalds, LKML, Peter Zijlstra, Andrew Morton
Hi all,
The following warning triggered on me while I was browsing the web:
http://twitpic.com/38vxxg
[ Click on the "Rotate photo" button for landscape version. ]
It's
WARN_ON(atomic_read(&tsk->fs_excl));
in do_exit(). There was a prior oops in __pipe_free_info() called in
sys_recvmsg() paths that unfortunately scrolled away. Does it ring a
bell to anyone? This is latest Linus' master from few hours ago. I've
been running 2.6.37-rc1 until today without any problems.
I'll let you know if it triggers again.
Pekka
^ permalink raw reply
* [PATCH net-next-2.6] pktgen: allow faster module unload
From: Eric Dumazet @ 2010-11-21 17:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Unloading pktgen module needs ~6 seconds on a 64 cpus machine, to stop
64 kthreads.
Add a pktgen_exiting variable to let kernel threads die faster, so that
kthread_stop() doesnt have to wait too long for them. This variable is
not tested in fast path.
Note : Before exiting from pktgen_thread_worker(), we must make sure
kthread_stop() is waiting for this thread to be stopped, like its done
in kernel/softirq.c
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/pktgen.c | 17 ++++++++++++-----
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 52fc1e0..f6f3d5d 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -395,6 +395,8 @@ struct pktgen_hdr {
__be32 tv_usec;
};
+bool pktgen_exiting __read_mostly;
+
struct pktgen_thread {
spinlock_t if_lock; /* for list of devices */
struct list_head if_list; /* All device here */
@@ -3451,11 +3453,6 @@ static void pktgen_rem_thread(struct pktgen_thread *t)
remove_proc_entry(t->tsk->comm, pg_proc_dir);
- mutex_lock(&pktgen_thread_lock);
-
- list_del(&t->th_list);
-
- mutex_unlock(&pktgen_thread_lock);
}
static void pktgen_resched(struct pktgen_dev *pkt_dev)
@@ -3602,6 +3599,8 @@ static int pktgen_thread_worker(void *arg)
pkt_dev = next_to_run(t);
if (unlikely(!pkt_dev && t->control == 0)) {
+ if (pktgen_exiting)
+ break;
wait_event_interruptible_timeout(t->queue,
t->control != 0,
HZ/10);
@@ -3654,6 +3653,13 @@ static int pktgen_thread_worker(void *arg)
pr_debug("%s removing thread\n", t->tsk->comm);
pktgen_rem_thread(t);
+ /* Wait for kthread_stop() or risk corruption */
+ while (!kthread_should_stop()) {
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule();
+ }
+ __set_current_state(TASK_RUNNING);
+
return 0;
}
@@ -3928,6 +3934,7 @@ static void __exit pg_cleanup(void)
struct list_head *q, *n;
/* Stop all interfaces & threads */
+ pktgen_exiting = true;
list_for_each_safe(q, n, &pktgen_threads) {
t = list_entry(q, struct pktgen_thread, th_list);
^ permalink raw reply related
* Bad initialisers in pch_gbe_param.c:pch_gbe_check_options ?
From: Dr. David Alan Gilbert @ 2010-11-21 17:17 UTC (permalink / raw)
To: masa-korg; +Cc: netdev, davem
Hi,
The 'sparse' checker pointed me at the following code in pch_gbe_param.c
that does look wrong:
drivers/net/pch_gbe/pch_gbe_param.c:437:26: warning: Initializer entry defined twice
drivers/net/pch_gbe/pch_gbe_param.c:438:26: also defined here
static const struct pch_gbe_option opt = {
.type = range_option,
.name = "Transmit Descriptors",
.err = "using default of "
__MODULE_STRING(PCH_GBE_DEFAULT_TXD),
.def = PCH_GBE_DEFAULT_TXD,
******* .arg = { .r = { .min = PCH_GBE_MIN_TXD } },
******* .arg = { .r = { .max = PCH_GBE_MAX_TXD } }
};
The structure has a union called arg inside of which are two structs (l and r)
and r has two members, min and max. This initialiser is initialising the whole
of .arg twice; I wrote a little test stand alone program and indeed
when doing it this way 'min' ended up as zero.
I suggest what you really want is:
static const struct pch_gbe_option opt = {
.type = range_option,
.name = "Transmit Descriptors",
.err = "using default of "
__MODULE_STRING(PCH_GBE_DEFAULT_TXD),
.def = PCH_GBE_DEFAULT_TXD,
.arg = { .r = { .min = PCH_GBE_MIN_TXD,
.max = PCH_GBE_MAX_TXD } }
};
(There's also an equivalent pair a few lines below)
drivers/net/pch_gbe/pch_gbe_param.c:453:26: warning: Initializer entry defined twice
drivers/net/pch_gbe/pch_gbe_param.c:454:26: also defined here
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ gro.gilbert @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
^ permalink raw reply
* Re: [PROBLEM] WARNING: at kernel/exit.c:910 do_exit
From: Linus Torvalds @ 2010-11-21 17:42 UTC (permalink / raw)
To: Pekka Enberg; +Cc: oleg, LKML, Peter Zijlstra, Andrew Morton, Linux Netdev List
In-Reply-To: <AANLkTi=ej5guZ2R72=fqe5mciwjVeY5LkDL3Qx1W0GvA@mail.gmail.com>
On Sun, Nov 21, 2010 at 7:35 AM, Pekka Enberg <penberg@kernel.org> wrote:
>
> The following warning triggered on me while I was browsing the web:
>
> http://twitpic.com/38vxxg
>
> [ Click on the "Rotate photo" button for landscape version. ]
>
> It's
>
> WARN_ON(atomic_read(&tsk->fs_excl));
>
> in do_exit(). There was a prior oops in __pipe_free_info() called in
> sys_recvmsg() paths that unfortunately scrolled away.
That WARN_ON() is almost certainly due to the previous oops.
The previous oops may have scrolled away, but you can see the
call-chain, since it's part of the later oops. Except the photo is
hard to read ;)
In fact, you can see that there has been _two_ oopses before that. The
"free_pipe_info()" oops comes from the "do_exit()" path of the _first_
oops.
So the original oops seems to be around here:
(*probably* oopsed in __scm_destroy)
(the fd_install on the stack is likely from scm_detach_fds calling
it before calling __scm_destroy - just a stale pointer remaining on
the stack)
scm_detach_fds
unix_stream_recvmsg
sock_recvmsg
__sys_recvmsg
sys_recvmsg
which means that this is almost certainly in networking. Then, when
that oops caused us to die, do_exit() tried to clean up the state, and
_that_ caused us to oops again (now in free_pipe_info). That second
oops is the partial one you see. And then the _third_ oops is the one
you actually caught.
The free_pipe_info() oops in turn must be because we passed in an
invalid "inode" pointer. It's almost certainly the "inode->i_pipe"
dereference, so inode was NULL or something. I don't see why that
would happen, but with a previous oops it's not necessarily clear that
there _is_ a reason.
And who knows? It may be that the networking oops was due to some
other earlier problem that isn't part of this particular callchain and
that has long since scrolled away. I don't see any unix domain changes
since -rc1.
Linus
^ permalink raw reply
* Re: [net-2.6 PATCH] e1000: fix screaming IRQ
From: David Miller @ 2010-11-21 17:54 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, bphilips, anupamc, stable, jesse.brandeburg
In-Reply-To: <20101121104747.17414.88773.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sun, 21 Nov 2010 02:48:28 -0800
> From: Anupam Chanda <anupamc@vmware.com>
>
> VMWare reports that the e1000 driver has a bug when bringing down the
> interface, such that interrupts are not disabled in the hardware but the
> driver stops reporting that it consumed the interrupt.
>
> The fix is to set the driver's "down" flag later in the routine,
> after all the timers and such have exited, preventing the interrupt
> handler from being called and exiting early without handling the
> interrupt.
>
> CC: Anupam Chanda <anupamc@vmware.com>
> CC: stable kernel <stable@kernel.org>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ixgbe: update version number for ixgbe
From: David Miller @ 2010-11-21 17:55 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, donald.c.skidmore
In-Reply-To: <20101121110607.17542.84908.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sun, 21 Nov 2010 03:07:02 -0800
> From: Don Skidmore <donald.c.skidmore@intel.com>
>
> This will reflect addition of new X540 hardware
>
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] pktgen: allow faster module unload
From: David Miller @ 2010-11-21 17:56 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1290359251.2756.134.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 21 Nov 2010 18:07:31 +0100
> @@ -395,6 +395,8 @@ struct pktgen_hdr {
> __be32 tv_usec;
> };
>
> +bool pktgen_exiting __read_mostly;
> +
> struct pktgen_thread {
> spinlock_t if_lock; /* for list of devices */
> struct list_head if_list; /* All device here */
Maybe this should be static?
^ permalink raw reply
* Re: [PATCH] bonding: change list contact to netdev@vger.kernel.org
From: David Miller @ 2010-11-21 17:58 UTC (permalink / raw)
To: horms; +Cc: netdev, fubar
In-Reply-To: <20101120214841.GA20259@verge.net.au>
From: Simon Horman <horms@verge.net.au>
Date: Sun, 21 Nov 2010 06:48:41 +0900
> bonding-devel@lists.sourceforge.net seems only receive spam
> and discussion seems to already occur on netdev@vger.kernel.org.
>
> Signed-off-by: Simon Horman <horms@verge.net.au>
Agreed, applied, thanks Simon.
^ permalink raw reply
* Re: [PATCH net-next-2.6] packet: use vzalloc()
From: David Miller @ 2010-11-21 18:02 UTC (permalink / raw)
To: nhorman; +Cc: eric.dumazet, netdev
In-Reply-To: <20101121004348.GA29311@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Sat, 20 Nov 2010 19:43:48 -0500
> On Sat, Nov 20, 2010 at 06:31:54PM +0100, Eric Dumazet wrote:
>> alloc_one_pg_vec_page() is supposed to return zeroed memory, so use
>> vzalloc() instead of vmalloc()
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> Cc: Neil Horman <nhorman@tuxdriver.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
>
> Thanks Eric!
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-2.6] net: allow GFP_HIGHMEM in __vmalloc()
From: David Miller @ 2010-11-21 18:04 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1290275195.2756.94.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 20 Nov 2010 18:46:35 +0100
> We forgot to use __GFP_HIGHMEM in several __vmalloc() calls.
>
> In ceph, add the missing flag.
>
> In fib_trie.c, xfrm_hash.c and request_sock.c, using vzalloc() is
> cleaner and allows using HIGHMEM pages as well.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [patch] netns: let net_generic take pointer-to-const args
From: David Miller @ 2010-11-21 18:05 UTC (permalink / raw)
To: jengelh; +Cc: netdev
In-Reply-To: <alpine.LNX.2.01.1011210506110.9636@obet.zrqbmnf.qr>
From: Jan Engelhardt <jengelh@medozas.de>
Date: Sun, 21 Nov 2010 05:07:21 +0100 (CET)
> netns: let net_generic take pointer-to-const args
>
> This commit is same in nature as v2.6.37-rc1-755-g3654654; the network
> namespace itself is not modified when calling net_generic, so the
> parameter can be const.
>
> Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Applied.
^ permalink raw reply
* Re: [patch] netns: let net_generic take pointer-to-const args
From: David Miller @ 2010-11-21 18:05 UTC (permalink / raw)
To: eric.dumazet; +Cc: jengelh, netdev
In-Reply-To: <1290328165.2756.102.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 21 Nov 2010 09:29:25 +0100
> While you are at it you could also use
>
> const struct net_generic *ng;
>
> Just curious, if we could use __pure attribute as well.
Sounds like a good idea for a follow-on patch.
^ permalink raw reply
* Re: [PATCH net-2.6] atl1c: Fix hardware type check for enabling OTP CLK
From: David Miller @ 2010-11-21 18:07 UTC (permalink / raw)
To: ben; +Cc: lrodriguez, Jie.Yang, linux-team, netdev
In-Reply-To: <1290228936.3818.135.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sat, 20 Nov 2010 04:55:36 +0000
> Commit 496c185c9495629ef1c65387cb2594578393cfe0 "atl1c: Add support
> for Atheros AR8152 and AR8152" added the condition:
>
> if (hw->nic_type == athr_l1c || hw->nic_type == athr_l2c_b)
>
> for enabling OTP CLK, and the condition:
>
> if (hw->nic_type == athr_l1c || hw->nic_type == athr_l2c)
>
> for disabling OTP CLK. Since the two previously defined hardware
> types are athr_l1c and athr_l2c, the latter condition appears to be
> the correct one. Change the former to match.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> This is compile-tested only. It looks like the current code may fail to
> read non-volatile settings on the L2C hardware since the EEPROM will not
> be clocked. Please check this.
This was brought up before, perhaps 4 or 5 months ago, and the maintainers
for this driver just fooled around and never brought this issue to a
meaningful resolution.
So I'm just going to apply your patch instead of waiting another half
year for something to happen.
Thanks Ben.
^ permalink raw reply
* [PATCH net-next-2.6 v2] pktgen: allow faster module unload
From: Eric Dumazet @ 2010-11-21 18:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20101121.095636.71126038.davem@davemloft.net>
Le dimanche 21 novembre 2010 à 09:56 -0800, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Sun, 21 Nov 2010 18:07:31 +0100
>
> > @@ -395,6 +395,8 @@ struct pktgen_hdr {
> > __be32 tv_usec;
> > };
> >
> > +bool pktgen_exiting __read_mostly;
> > +
> > struct pktgen_thread {
> > spinlock_t if_lock; /* for list of devices */
> > struct list_head if_list; /* All device here */
>
> Maybe this should be static?
Indeed, thanks !
[PATCH net-next-2.6 v2] pktgen: allow faster module unload
Unloading pktgen module needs ~6 seconds on a 64 cpus machine, to stop
64 kthreads.
Add a pktgen_exiting variable to let kernel threads die faster, so that
kthread_stop() doesnt have to wait too long for them. This variable is
not tested in fast path.
Note : Before exiting from pktgen_thread_worker(), we must make sure
kthread_stop() is waiting for this thread to be stopped, like its done
in kernel/softirq.c
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/pktgen.c | 17 ++++++++++++-----
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 52fc1e0..f6f3d5d 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -395,6 +395,8 @@ struct pktgen_hdr {
__be32 tv_usec;
};
+static bool pktgen_exiting __read_mostly;
+
struct pktgen_thread {
spinlock_t if_lock; /* for list of devices */
struct list_head if_list; /* All device here */
@@ -3451,11 +3453,6 @@ static void pktgen_rem_thread(struct pktgen_thread *t)
remove_proc_entry(t->tsk->comm, pg_proc_dir);
- mutex_lock(&pktgen_thread_lock);
-
- list_del(&t->th_list);
-
- mutex_unlock(&pktgen_thread_lock);
}
static void pktgen_resched(struct pktgen_dev *pkt_dev)
@@ -3602,6 +3599,8 @@ static int pktgen_thread_worker(void *arg)
pkt_dev = next_to_run(t);
if (unlikely(!pkt_dev && t->control == 0)) {
+ if (pktgen_exiting)
+ break;
wait_event_interruptible_timeout(t->queue,
t->control != 0,
HZ/10);
@@ -3654,6 +3653,13 @@ static int pktgen_thread_worker(void *arg)
pr_debug("%s removing thread\n", t->tsk->comm);
pktgen_rem_thread(t);
+ /* Wait for kthread_stop */
+ while (!kthread_should_stop()) {
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule();
+ }
+ __set_current_state(TASK_RUNNING);
+
return 0;
}
@@ -3928,6 +3934,7 @@ static void __exit pg_cleanup(void)
struct list_head *q, *n;
/* Stop all interfaces & threads */
+ pktgen_exiting = true;
list_for_each_safe(q, n, &pktgen_threads) {
t = list_entry(q, struct pktgen_thread, th_list);
^ permalink raw reply related
* Re: [PROBLEM] WARNING: at kernel/exit.c:910 do_exit
From: Oleg Nesterov @ 2010-11-21 18:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Pekka Enberg, LKML, Peter Zijlstra, Andrew Morton,
Linux Netdev List
In-Reply-To: <AANLkTikRJ3QBRJ_VsoMG4Q+HMs=a9C8XkJ31dtdKrfpO@mail.gmail.com>
On 11/21, Linus Torvalds wrote:
>
> On Sun, Nov 21, 2010 at 7:35 AM, Pekka Enberg <penberg@kernel.org> wrote:
> >
> > WARN_ON(atomic_read(&tsk->fs_excl));
> >
> > in do_exit(). There was a prior oops in __pipe_free_info() called in
> > sys_recvmsg() paths that unfortunately scrolled away.
>
> That WARN_ON() is almost certainly due to the previous oops.
>
> The previous oops may have scrolled away, but you can see the
> call-chain, since it's part of the later oops. Except the photo is
> hard to read ;)
>
> In fact, you can see that there has been _two_ oopses before that. The
> "free_pipe_info()" oops comes from the "do_exit()" path of the _first_
> oops.
>
> So the original oops seems to be around here:
>
> (*probably* oopsed in __scm_destroy)
> (the fd_install on the stack is likely from scm_detach_fds calling
> it before calling __scm_destroy - just a stale pointer remaining on
> the stack)
> scm_detach_fds
> unix_stream_recvmsg
> sock_recvmsg
> __sys_recvmsg
> sys_recvmsg
Yes, but still I am puzzled a bit. Where ->fs_excl != 0 comes from?
Not that I really understand what it means, but nothing in this path
can do lock_super(), I think. This means it was already nonzero or
the bug caused the memory corruption.
Btw, why it is atomic_t ?
> And who knows? It may be that the networking oops was due to some
> other earlier problem that isn't part of this particular callchain and
> that has long since scrolled away.
Agreed, probably this is false alarm. The oopsing task can trigger
a lot of "wrong" warnings.
Oleg.
^ permalink raw reply
* Re: [PROBLEM] WARNING: at kernel/exit.c:910 do_exit
From: Linus Torvalds @ 2010-11-21 19:11 UTC (permalink / raw)
To: Oleg Nesterov, Jens Axboe
Cc: Pekka Enberg, LKML, Peter Zijlstra, Andrew Morton,
Linux Netdev List
In-Reply-To: <20101121185116.GA2280@redhat.com>
On Sun, Nov 21, 2010 at 10:51 AM, Oleg Nesterov <oleg@redhat.com> wrote:
>
> Yes, but still I am puzzled a bit. Where ->fs_excl != 0 comes from?
> Not that I really understand what it means, but nothing in this path
> can do lock_super(), I think. This means it was already nonzero or
> the bug caused the memory corruption.
I would guess that by the time you do three recursive oopses, you've
probably used up all the kernel stack and you've stomped on the
thread_info itself. At that point, thread->tsk might be totally
random. So it's possible that "current->fs_excl" is nonzero simply
because "current" is a random pointer at this point.
Or it might be memory corruption, and the same thing that caused the
original oops.
I dunno.
I do wonder if we should just flag a thread as "busy oopsing" before
we call "do_exit(), so that _if_ we do a recursive oops we
(a) don't print it out (except just a one-liner to say "recursively
oopsed in %pS" or something)
(b) don't try to clean up with do_exit (because that's likely just
going to oops again or run out of stack etc)
That might have left us with a more visible original oops. Maybe the
register contents at that point could have given us any ideas (ie
things like the slab poisoning memory patterns or whatever).
> Btw, why it is atomic_t ?
That whole thing is insane. Afaik, there is one single user (apart
from the WARN_ON), and that's some stupid block scheduler crap for IO
priority boosting.
The block layer people have been way too eager to add random ugly
crud. And no, I don't see why the atomic_t would make any sense. It's
thread-local.
Linus
^ permalink raw reply
* Re: [PROBLEM] WARNING: at kernel/exit.c:910 do_exit
From: Oleg Nesterov @ 2010-11-21 19:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jens Axboe, Pekka Enberg, LKML, Peter Zijlstra, Andrew Morton,
Linux Netdev List
In-Reply-To: <AANLkTi=fdtLhdV8OOXLAJPPtdPvMWyo8e3ARbk8gagvc@mail.gmail.com>
On 11/21, Linus Torvalds wrote:
>
> I do wonder if we should just flag a thread as "busy oopsing" before
> we call "do_exit(), so that _if_ we do a recursive oops we
>
> (a) don't print it out (except just a one-liner to say "recursively
> oopsed in %pS" or something)
> (b) don't try to clean up with do_exit (because that's likely just
> going to oops again or run out of stack etc)
>
> That might have left us with a more visible original oops. Maybe the
> register contents at that point could have given us any ideas (ie
> things like the slab poisoning memory patterns or whatever).
+inf ;)
I thought about this many times. To me, the major offender is
__schedule_bug(). It is quite useful by itself, but every bug with
spinlock held triggers it.
Oleg.
^ permalink raw reply
* [PATCH] ipv6: fix inet6_dev refcnt with IPV6_PRIVACY enabled
From: Sergey Senozhatsky @ 2010-11-21 19:58 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Pekka Savola (ipv6), Hideaki YOSHIFUJI
When IPV6_PRIVACY is enabled, in ipv6_add_dev we have second extra
in6_dev_hold while preparing to call ipv6_regen_rndid, and only
one in6_dev_put call in addrconf_ifdown for inet6_dev devices with
active regen_timer.
That leaves inet6_dev with refcnt equals to 1 and blocks device unregistration:
"unregister_netdevice: waiting for usb0 to become free. Usage count = 1"
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
---
net/ipv6/addrconf.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2fc35b3..541f773 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -425,7 +425,6 @@ static struct inet6_dev * ipv6_add_dev(struct net_device *dev)
dev->name);
ndev->cnf.use_tempaddr = -1;
} else {
- in6_dev_hold(ndev);
ipv6_regen_rndid((unsigned long) ndev);
}
#endif
^ permalink raw reply related
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