* [PATCH] drivers/net: Remove CONFIG_WIZNET_TX_FLOW option
From: Mike Sinkovsky @ 2012-04-12 6:14 UTC (permalink / raw)
To: netdev, linux-kernel; +Cc: Mike Sinkovsky
This option was there for debugging race conditions,
just remove it, and assume TX_FLOW is always enabled.
Signed-off-by: Mike Sinkovsky <msink@permonline.ru>
---
This replaces patch from Paul Gortmaker:
"[PATCH 3/5] drivers/net: remove IS_ENABLED usage from wiznet drivers
The use of IS_ENABLED in C code (vs just in CPP #if directives)
causes us to carry the burden of a huge autoconf.h file. It is
also misleading in that a casual inspection of the code would
leave one thinking that the if statements were evaluated at
runtime, when TX_FLOW is a Kconfig bool and hence evaluated
at configure time as an either/or."
Just remove this option instead.
drivers/net/ethernet/wiznet/Kconfig | 8 --------
drivers/net/ethernet/wiznet/w5100.c | 5 ++---
drivers/net/ethernet/wiznet/w5300.c | 9 +++------
3 files changed, 5 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/wiznet/Kconfig b/drivers/net/ethernet/wiznet/Kconfig
index c8291bf..cb18043 100644
--- a/drivers/net/ethernet/wiznet/Kconfig
+++ b/drivers/net/ethernet/wiznet/Kconfig
@@ -70,12 +70,4 @@ config WIZNET_BUS_ANY
Performance may decrease compared to explicitly selected bus mode.
endchoice
-config WIZNET_TX_FLOW
- bool "Use transmit flow control"
- depends on WIZNET_W5100 || WIZNET_W5300
- default y
- help
- This enables transmit flow control for WIZnet chips.
- If unsure, say Y.
-
endif # NET_VENDOR_WIZNET
diff --git a/drivers/net/ethernet/wiznet/w5100.c b/drivers/net/ethernet/wiznet/w5100.c
index 157d2f0..22e2c5c 100644
--- a/drivers/net/ethernet/wiznet/w5100.c
+++ b/drivers/net/ethernet/wiznet/w5100.c
@@ -441,8 +441,7 @@ static int w5100_start_tx(struct sk_buff *skb, struct net_device *ndev)
struct w5100_priv *priv = netdev_priv(ndev);
u16 offset;
- if (IS_ENABLED(CONFIG_WIZNET_TX_FLOW))
- netif_stop_queue(ndev);
+ netif_stop_queue(ndev);
offset = w5100_read16(priv, W5100_S0_TX_WR);
w5100_writebuf(priv, offset, skb->data, skb->len);
@@ -517,7 +516,7 @@ static irqreturn_t w5100_interrupt(int irq, void *ndev_instance)
w5100_write(priv, W5100_S0_IR, ir);
mmiowb();
- if (IS_ENABLED(CONFIG_WIZNET_TX_FLOW) && (ir & S0_IR_SENDOK)) {
+ if (ir & S0_IR_SENDOK) {
netif_dbg(priv, tx_done, ndev, "tx done\n");
netif_wake_queue(ndev);
}
diff --git a/drivers/net/ethernet/wiznet/w5300.c b/drivers/net/ethernet/wiznet/w5300.c
index 86d07bb..63cb9dd 100644
--- a/drivers/net/ethernet/wiznet/w5300.c
+++ b/drivers/net/ethernet/wiznet/w5300.c
@@ -273,9 +273,7 @@ static void w5300_hw_start(struct w5300_priv *priv)
S0_MR_MACRAW : S0_MR_MACRAW_MF);
mmiowb();
w5300_command(priv, S0_CR_OPEN);
- w5300_write(priv, W5300_S0_IMR, IS_ENABLED(CONFIG_WIZNET_TX_FLOW) ?
- S0_IR_RECV | S0_IR_SENDOK :
- S0_IR_RECV);
+ w5300_write(priv, W5300_S0_IMR, S0_IR_RECV | S0_IR_SENDOK);
w5300_write(priv, W5300_IMR, IR_S0);
mmiowb();
}
@@ -371,8 +369,7 @@ static int w5300_start_tx(struct sk_buff *skb, struct net_device *ndev)
{
struct w5300_priv *priv = netdev_priv(ndev);
- if (IS_ENABLED(CONFIG_WIZNET_TX_FLOW))
- netif_stop_queue(ndev);
+ netif_stop_queue(ndev);
w5300_write_frame(priv, skb->data, skb->len);
mmiowb();
@@ -439,7 +436,7 @@ static irqreturn_t w5300_interrupt(int irq, void *ndev_instance)
w5300_write(priv, W5300_S0_IR, ir);
mmiowb();
- if (IS_ENABLED(CONFIG_WIZNET_TX_FLOW) && (ir & S0_IR_SENDOK)) {
+ if (ir & S0_IR_SENDOK) {
netif_dbg(priv, tx_done, ndev, "tx done\n");
netif_wake_queue(ndev);
}
--
1.6.3.3
^ permalink raw reply related
* Regression due to "ath9k: fix going to full-sleep on PS idle"
From: Sujith Manoharan @ 2012-04-12 5:07 UTC (permalink / raw)
To: Linus Torvalds
Cc: ath9k-devel@lists.ath9k.org, KH, linux-wireless Mailing List,
linux-kernel, John W. Linville, Greg, Heinz Diehl,
Network Development, akpm, David Miller, alan
In-Reply-To: <CA+55aFxWD1bE0oiR4GpLP19MCm2CzwuApuYhcE_NF7bC+tFYjg@mail.gmail.com>
Linus Torvalds wrote:
> You guys need to fix the subject line (like this), and make sure that
> the right people are cc'd. This is not a "stable" issue - stable
> cannot revert stuff that hasn't been reverted upstream.
>
> So instead of stable and Greg, it should be netdev and Davem.
>
> David/John: multiple people are complaining about that commit. It
> really should be reverted, or a fix found. It's broken.
>
> I can do the revert, but it would be better coming from the networking people.
John has already reverted the commit:
http://git.kernel.org/?p=linux/kernel/git/linville/wireless.git;a=commit;h=011afa1ed8c408d694957d2474d89dc81a60b70c
Sujith
^ permalink raw reply
* Re: suspicious RCU usage warnings in 3.3.0
From: Paul E. McKenney @ 2012-04-12 4:54 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, mroos, linux-kernel, netdev
In-Reply-To: <20120411.210843.716144028821174908.davem@davemloft.net>
On Wed, Apr 11, 2012 at 09:08:43PM -0400, David Miller wrote:
> From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Date: Wed, 11 Apr 2012 17:45:07 -0700
>
> > If I am confused about the simple function call, and if control is really
> > passing via an interrupt or exception, then rcu_irq_enter() should be
> > called on entry to the interrupt or exception and rcu_irq_exit() should
> > be called on exit.
>
> Hmm, it seems the convention changed such that platforms aren't
> supposed to invoke do_softirq() from their trap return trap any more.
> It's handled completely by irq_exit().
>
> When did that start happening? :-)
Heh! It appears that git doesn't go back far enough for me to find the
answer to that question. ;-)
> Anyways I bet that's the problem, sparc64 invokes do_softirq() in it's
> trap return path if softirqs are pending, and that doesn't do any
> of the RCU frobbing you mention.
The following untested patch that probably does not even build is offered
up for your amusement. I don't know enough about SPARC's needs for
alignment, handling of branch-delay slots, and so on for this to have
any chance of working, but hey! ;-)
Thanx, Paul
------------------------------------------------------------------------
sparc64: Eliminate obsolete __handle_softirq() function
The invocation of softirq is now handled by irq_exit(), so there is no
need for sparc64 to invoke it on the trap-return path. In fact, doing so
is a bug because if the trap occurred in the idle loop, this invocation
can result in lockdep-RCU failures. The problem is that RCU ignores idle
CPUs, and the sparc64 trap-return path to the softirq handlers fails to
tell RCU that the CPU must be considered non-idle while those handlers
are executing. This means that RCU is ignoring any RCU read-side critical
sections in those handlers, which in turn means that RCU-protected data
can be yanked out from under those read-side critical sections.
The shiny new lockdep-RCU ability to detect RCU read-side critical sections
that RCU is ignoring located this problem.
The fix is straightforward: Make sparc64 stop manually invoking the
softirq handlers.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
rtrap_64.S | 7 -------
1 file changed, 7 deletions(-)
diff --git a/arch/sparc/kernel/rtrap_64.S b/arch/sparc/kernel/rtrap_64.S
index 77f1b95..9171fc2 100644
--- a/arch/sparc/kernel/rtrap_64.S
+++ b/arch/sparc/kernel/rtrap_64.S
@@ -20,11 +20,6 @@
.text
.align 32
-__handle_softirq:
- call do_softirq
- nop
- ba,a,pt %xcc, __handle_softirq_continue
- nop
__handle_preemption:
call schedule
wrpr %g0, RTRAP_PSTATE, %pstate
@@ -89,9 +84,7 @@ rtrap:
cmp %l1, 0
/* mm/ultra.S:xcall_report_regs KNOWS about this load. */
- bne,pn %icc, __handle_softirq
ldx [%sp + PTREGS_OFF + PT_V9_TSTATE], %l1
-__handle_softirq_continue:
rtrap_xcall:
sethi %hi(0xf << 20), %l4
and %l1, %l4, %l4
^ permalink raw reply related
* Regression due to "ath9k: fix going to full-sleep on PS idle"
From: Linus Torvalds @ 2012-04-12 4:22 UTC (permalink / raw)
To: Heinz Diehl
Cc: linux-kernel, Greg KH, akpm, alan, linux-wireless Mailing List,
Sujith Manoharan, ath9k-devel@lists.ath9k.org, John W. Linville,
David Miller, Network Development
On Wed, Apr 11, 2012 at 9:16 PM, Heinz Diehl <htd@fancy-poultry.org> wrote:
> On 12.04.2012, Sergio Correia wrote:
>
>> is there any chance for this one to be included in this review cycle?
>>
>> http://www.spinics.net/lists/linux-wireless/msg87999.html
>
> Thanks for pointing this out! This patch fixes my network problems
> which forced me to go back to a previous kernel.
You guys need to fix the subject line (like this), and make sure that
the right people are cc'd. This is not a "stable" issue - stable
cannot revert stuff that hasn't been reverted upstream.
So instead of stable and Greg, it should be netdev and Davem.
David/John: multiple people are complaining about that commit. It
really should be reverted, or a fix found. It's broken.
I can do the revert, but it would be better coming from the networking people.
Linus
^ permalink raw reply
* Re: [PATCH 06/10] mac80211: Add sta_state to ethtool stats.
From: Johannes Berg @ 2012-04-12 3:49 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, netdev
In-Reply-To: <1334166738-28243-7-git-send-email-greearb@candelatech.com>
On Wed, 2012-04-11 at 10:52 -0700, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> Helps to know how the station is doing in it's association
> attempt.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> :100644 100644 bbaf564... a63834d... M net/mac80211/cfg.c
> net/mac80211/cfg.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index bbaf564..a63834d 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -118,7 +118,7 @@ static const char ieee80211_gstrings_sta_stats[][ETH_GSTRING_LEN] = {
> "rx_duplicates", "rx_fragments", "rx_dropped",
> "tx_packets", "tx_bytes", "tx_fragments",
> "tx_filtered", "tx_retry_failed", "tx_retries",
> - "beacon_loss", "txrate", "rxrate", "signal",
> + "beacon_loss", "sta_state", "txrate", "rxrate", "signal",
> "channel", "noise", "ch_time", "ch_time_busy",
> "ch_time_ext_busy", "ch_time_rx", "ch_time_tx"
> };
> @@ -534,10 +534,12 @@ static void ieee80211_get_et_stats(struct wiphy *wiphy,
> data[i++] += sta->beacon_loss_count;
>
> if (!do_once) {
> - i += 3;
> + i += 4;
> goto after_once;
> }
>
> + data[i++] = sta->sta_state;
> +
Gee, I wish it was easier to tell if you were adding it to the right
spot in the list ... any way that could be made easier?
johannes
^ permalink raw reply
* Re: [PATCH 05/10] mac80211: Add more ethtools stats: survey, rates, etc
From: Johannes Berg @ 2012-04-12 3:46 UTC (permalink / raw)
To: greearb-my8/4N5VtI7c+919tysfdA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1334166738-28243-6-git-send-email-greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
On Wed, 2012-04-11 at 10:52 -0700, greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org wrote:
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -19,6 +19,7 @@
> #include "cfg.h"
> #include "rate.h"
> #include "mesh.h"
> +#include "../wireless/core.h"
NACK. Don't do that.
johannes
--
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
* Re: [PATCH 08/10] mac80211: Support on-channel scan option.
From: Johannes Berg @ 2012-04-12 3:45 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, netdev
In-Reply-To: <1334166738-28243-9-git-send-email-greearb@candelatech.com>
On Wed, 2012-04-11 at 10:52 -0700, greearb@candelatech.com wrote:
> static int __ieee80211_start_scan(struct ieee80211_sub_if_data *sdata,
> struct cfg80211_scan_request *req)
> @@ -438,10 +461,43 @@ static int __ieee80211_start_scan(struct ieee80211_sub_if_data *sdata,
> local->scan_req = req;
> local->scan_sdata = sdata;
>
> - if (local->ops->hw_scan)
> + if (local->ops->hw_scan) {
> __set_bit(SCAN_HW_SCANNING, &local->scanning);
> - else
> - __set_bit(SCAN_SW_SCANNING, &local->scanning);
> + } else {
> + /* If we are scanning only on the current channel, then
> + * we do not need to stop normal activities
> + */
> + if ((req->n_channels == 1) &&
> + (req->channels[0]->center_freq ==
> + local->hw.conf.channel->center_freq)) {
how about "else if {", then the indentation isn't so deep and you can
have much nicer code in the entire block :)
> + unsigned long next_delay;
please add a blank line after variable declarations.
> + }
> + else {
please read the coding style documentation
> @@ -672,6 +704,12 @@ void ieee80211_scan_work(struct work_struct *work)
>
> sdata = local->scan_sdata;
>
> + /* When scanning on-channel, the first-callback means completeed. */
typo "completed"
> + if (test_bit(SCAN_ONCHANNEL_SCANNING, &local->scanning)) {
> + aborted = test_and_clear_bit(SCAN_ABORTED, &local->scanning);
> + goto out_complete;
> + }
how does the onchannel bit get cleared?
Shouldn't you be calling pre/post scan hooks?
I'm a bit divided over this. On the one hand, it seems like a mildly
useful optimisation, on the other though it adds a bunch of complexity
for multi-channel we've been thinking about... Not that we want to
support multi-channel with SW scan anyway, but still.
johannes
^ permalink raw reply
* Re: [PATCH 00/10] Wireless patches for wireless-testing
From: Johannes Berg @ 2012-04-12 3:39 UTC (permalink / raw)
To: greearb-my8/4N5VtI7c+919tysfdA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1334166738-28243-1-git-send-email-greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
On Wed, 2012-04-11 at 10:52 -0700, greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org wrote:
> From: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
>
> Support Ethtool stats for Wireless, including in-depth
> stats for ath9k, and add some additional ath9k stats
> to debugfs. Support scanning on-channel.
Please don't mix two completely different things in a single series of
patches. I almost skipped this completely since I already saw the
ethtool stuff and don't care about ath9k stats, but clearly I need to
look at the scan thing ...
johannes
--
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
* linux-next: build failure after merge of the wireless-next tree
From: Stephen Rothwell @ 2012-04-12 2:24 UTC (permalink / raw)
To: John W. Linville
Cc: linux-next, linux-kernel, Thomas Pedersen, David Miller, netdev
[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]
Hi John,
After merging the wireless-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
net/wireless/nl80211.c: In function 'nl80211_ch_switch_notify':
net/wireless/nl80211.c:8060:2: error: implicit declaration of function 'NLA_PUT_U32' [-Werror=implicit-function-declaration]
Caused by commit 5314526b1743 ("cfg80211: add channel switch notify
event") interacting with commit 9360ffd18597 ("wireless: Stop using
NLA_PUT*()") from the net-next tree.
I added the following merge fix patch.
John, you may like to cherry-pick that commit from Dave's tree (or back
merge that part of Dave's tree or get Dave to merge you tree and start
further work on top of the merge).
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 12 Apr 2012 12:21:01 +1000
Subject: [PATCH] cfg80211: NLA_PUT_U32 api change merge fix
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
net/wireless/nl80211.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index f727a1f..f7d2ebb 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -8057,9 +8057,12 @@ void nl80211_ch_switch_notify(struct cfg80211_registered_device *rdev,
return;
}
- NLA_PUT_U32(msg, NL80211_ATTR_IFINDEX, netdev->ifindex);
- NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_FREQ, freq);
- NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_CHANNEL_TYPE, type);
+ if (nla_put_u32(msg, NL80211_ATTR_IFINDEX, netdev->ifindex))
+ goto nla_put_failure;
+ if (nla_put_u32(msg, NL80211_ATTR_WIPHY_FREQ, freq))
+ goto nla_put_failure;
+ if (nla_put_u32(msg, NL80211_ATTR_WIPHY_CHANNEL_TYPE, type))
+ goto nla_put_failure;
genlmsg_end(msg, hdr);
--
1.7.10.rc3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: suspicious RCU usage warnings in 3.3.0
From: Paul E. McKenney @ 2012-04-12 1:53 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, mroos, linux-kernel, netdev
In-Reply-To: <20120411.210319.370705937753558953.davem@davemloft.net>
On Wed, Apr 11, 2012 at 09:03:19PM -0400, David Miller wrote:
> From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Date: Wed, 11 Apr 2012 17:45:07 -0700
>
> > On Wed, Apr 11, 2012 at 08:18:54PM -0400, David Miller wrote:
> >> From: Stephen Hemminger <shemminger@vyatta.com>
> >> Date: Wed, 11 Apr 2012 17:10:04 -0700
> >>
> >> > On Wed, 11 Apr 2012 16:08:37 -0700
> >> > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >> >
> >> >> Hmmm... What CPU family is this running on? From the look of the
> >> >> stack, it is sneaking out of idle into softirq without telling RCU.
> >> >> This would cause RCU to complain bitterly about being invoked from
> >> >> the idle loop -- and RCU ignores CPUs in the idle loop.
> >> >>
> >> >> Thanx, Paul
> >> >
> >> > Sun4... Ping David.
> >>
> >> So is there anything specific I need to do in the sparc64
> >> idle loop?
> >
> > Hmmm... I must confess that I don't immediately see how control
> > is passing from cpu_idle() in arch/sparc/kernel/process_64.c to
> > __handle_softirq().
> >
> > But it looks like a simple function call in the call trace:
>
> It's coming from the trap return code path at the end of hardware
> interrupt processing, on the IRQ stack.
Ah! I should have guessed something like that was happening given
that __handle_softirq() is written in assembly.
Thanx, Paul
^ permalink raw reply
* Re: suspicious RCU usage warnings in 3.3.0
From: David Miller @ 2012-04-12 1:08 UTC (permalink / raw)
To: paulmck; +Cc: shemminger, mroos, linux-kernel, netdev
In-Reply-To: <20120412004507.GF2473@linux.vnet.ibm.com>
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date: Wed, 11 Apr 2012 17:45:07 -0700
> If I am confused about the simple function call, and if control is really
> passing via an interrupt or exception, then rcu_irq_enter() should be
> called on entry to the interrupt or exception and rcu_irq_exit() should
> be called on exit.
Hmm, it seems the convention changed such that platforms aren't
supposed to invoke do_softirq() from their trap return trap any more.
It's handled completely by irq_exit().
When did that start happening? :-)
Anyways I bet that's the problem, sparc64 invokes do_softirq() in it's
trap return path if softirqs are pending, and that doesn't do any
of the RCU frobbing you mention.
^ permalink raw reply
* Re: suspicious RCU usage warnings in 3.3.0
From: David Miller @ 2012-04-12 1:03 UTC (permalink / raw)
To: paulmck; +Cc: shemminger, mroos, linux-kernel, netdev
In-Reply-To: <20120412004507.GF2473@linux.vnet.ibm.com>
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date: Wed, 11 Apr 2012 17:45:07 -0700
> On Wed, Apr 11, 2012 at 08:18:54PM -0400, David Miller wrote:
>> From: Stephen Hemminger <shemminger@vyatta.com>
>> Date: Wed, 11 Apr 2012 17:10:04 -0700
>>
>> > On Wed, 11 Apr 2012 16:08:37 -0700
>> > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>> >
>> >> Hmmm... What CPU family is this running on? From the look of the
>> >> stack, it is sneaking out of idle into softirq without telling RCU.
>> >> This would cause RCU to complain bitterly about being invoked from
>> >> the idle loop -- and RCU ignores CPUs in the idle loop.
>> >>
>> >> Thanx, Paul
>> >
>> > Sun4... Ping David.
>>
>> So is there anything specific I need to do in the sparc64
>> idle loop?
>
> Hmmm... I must confess that I don't immediately see how control
> is passing from cpu_idle() in arch/sparc/kernel/process_64.c to
> __handle_softirq().
>
> But it looks like a simple function call in the call trace:
It's coming from the trap return code path at the end of hardware
interrupt processing, on the IRQ stack.
^ permalink raw reply
* Re: [PATCH v17 01/15] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
From: Andrew Lutomirski @ 2012-04-12 0:50 UTC (permalink / raw)
To: mtk.manpages
Cc: Jonathan Corbet, Andrew Morton, Will Drewry, linux-kernel,
linux-security-module, linux-arch, linux-doc, kernel-hardening,
netdev, x86, arnd, davem, hpa, mingo, oleg, peterz, rdunlap,
mcgrathr, tglx, eparis, serge.hallyn, djm, scarybeasts, indan,
pmoore, eric.dumazet, markus, coreyb, keescook, jmorris,
Andy Lutomirski, linux-man
In-Reply-To: <CAKgNAkhhnC1+vdh7vTYKkngzxHccDwHH_aKF5wCNhga33BGhyQ@mail.gmail.com>
On Wed, Apr 11, 2012 at 12:31 PM, Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
> On Sat, Apr 7, 2012 at 8:28 AM, Jonathan Corbet <corbet@lwn.net> wrote:
>> On Fri, 6 Apr 2012 13:01:17 -0700
>> Andrew Lutomirski <luto@mit.edu> wrote:
>>
>>> This has been bugging me for awhile. Is there any interest in moving
>>> the manpages into the kernel source tree? Then there could be a
>>> general requirement that new APIs get documented when they're written.
>>
>> Man page (or other documentation) requirements for patch acceptance are a
>> regular kernel summit feature. People seem to think it's a good idea, but
>> actual enforcement of such requirements always seems to be lacking. Lots
>> of people have kind of given up trying. I don't really see that adding
>> the man pages to the tree would help, but I could be wrong...
>
> I largely consider this (moving man pages to kernel.org) a technical
> solution to what is fundamentally a social problem (developers
> reluctant to write documentation), and doubt that the technical
> solution would make much difference. I'd love to be proved wrong, but
> the experiment would require significant start-up effort. (My
> collected thoughts on this can be found here:
> http://www.kernel.org/doc/man-pages/todo.html#migrate_to_kernel_source.
> Note the alternative idea of patch tags mentioned at the end of that
> text.)
>
> Unless, or until there's a paid maintainer, I don't expect things to
> get significantly better than what they currently are. The quite
> significant improvements in man-pages since 2004, when I became
> maintainer were in small part due to the fact that I was for a short
> period paid to do the work, but in much larger part due to a huge
> private effort over those years which over the last couple of years is
> no longer unsustainable for me (man-pages is in competition with
> requirements for my attention from family, working life, and
> (seriously!) seismic events),
Hrm. Maybe someone could convince Andrew and Linus not to pull new
syscalls or major ABI features unless the patchset includes full docs.
Anyway, I'll write up a detailed description of PR_SET_NO_NEW_PRIVS,
stick it in the changelog, and cc linux-doc.
--Andy
^ permalink raw reply
* RE:
From: Felicia @ 2012-04-12 0:45 UTC (permalink / raw)
Do you need a fast approved loan with low
interest rate? Are you tired of looking for a
loan? Just reply and we are here to help.
^ permalink raw reply
* Re: suspicious RCU usage warnings in 3.3.0
From: Paul E. McKenney @ 2012-04-12 0:45 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, mroos, linux-kernel, netdev
In-Reply-To: <20120411.201854.1070083308359208025.davem@davemloft.net>
On Wed, Apr 11, 2012 at 08:18:54PM -0400, David Miller wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Wed, 11 Apr 2012 17:10:04 -0700
>
> > On Wed, 11 Apr 2012 16:08:37 -0700
> > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> >> Hmmm... What CPU family is this running on? From the look of the
> >> stack, it is sneaking out of idle into softirq without telling RCU.
> >> This would cause RCU to complain bitterly about being invoked from
> >> the idle loop -- and RCU ignores CPUs in the idle loop.
> >>
> >> Thanx, Paul
> >
> > Sun4... Ping David.
>
> So is there anything specific I need to do in the sparc64
> idle loop?
Hmmm... I must confess that I don't immediately see how control
is passing from cpu_idle() in arch/sparc/kernel/process_64.c to
__handle_softirq().
But it looks like a simple function call in the call trace:
[36457.471471] Call Trace:
[36457.503600] [0000000000489834] lockdep_rcu_suspicious+0xd4/0x100
[36457.583727] [00000000006755a8] __netif_receive_skb+0x368/0xa80
[36457.661536] [0000000000675e6c] netif_receive_skb+0x4c/0x60
[36457.734787] [000000000063fd74] tulip_poll+0x3b4/0x6a0
[36457.802327] [00000000006794d8] net_rx_action+0x118/0x1e0
[36457.873299] [00000000004560fc] __do_softirq+0x9c/0x140
[36457.941984] [000000000042b1c4] do_softirq+0x84/0xc0
[36458.007229] [0000000000404a40] __handle_softirq+0x0/0x10
[36458.078199] [000000000042b688] cpu_idle+0x48/0x100
[36458.142314] [0000000000722db8] rest_init+0x160/0x188
[36458.208711] [00000000008c87b0] start_kernel+0x32c/0x33c
[36458.278530] [0000000000722c50] tlb_fixup_done+0x88/0x90
[36458.348346] [0000000000000000] (null)
If it really is a simple function call, the trick is to wrap a RCU_NONIDLE()
around the call point, for example, fancifully:
RCU_NONIDLE(__handle_softirq());
This places an rcu_idle_enter() before the argument and an
rcu_idle_enter() after it. So it might be sufficient to adjust the
positions of the rcu_idle_enter() and rcu_idle_exit() calls in sparc64's
cpu_idle() function, for example, into the sparc64_yield() function
(if that is what is needed -- I can't see how sparc64_yield() calls
__handle_softirq(), either).
If I am confused about the simple function call, and if control is really
passing via an interrupt or exception, then rcu_irq_enter() should be
called on entry to the interrupt or exception and rcu_irq_exit() should
be called on exit.
Otherwise, RCU will happily ignore any RCU read-side critical sections
that are in what it believes to the the idle loop.
Thanx, Paul
^ permalink raw reply
* Re: suspicious RCU usage warnings in 3.3.0
From: David Miller @ 2012-04-12 0:18 UTC (permalink / raw)
To: shemminger; +Cc: paulmck, mroos, linux-kernel, netdev
In-Reply-To: <20120411171004.016ddd95@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 11 Apr 2012 17:10:04 -0700
> On Wed, 11 Apr 2012 16:08:37 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
>> Hmmm... What CPU family is this running on? From the look of the
>> stack, it is sneaking out of idle into softirq without telling RCU.
>> This would cause RCU to complain bitterly about being invoked from
>> the idle loop -- and RCU ignores CPUs in the idle loop.
>>
>> Thanx, Paul
>
> Sun4... Ping David.
So is there anything specific I need to do in the sparc64
idle loop?
^ permalink raw reply
* Re: [PATCH v17 01/15] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
From: Michael Kerrisk (man-pages) @ 2012-04-12 0:15 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Andrew Lutomirski, Andrew Morton, Will Drewry, linux-kernel,
linux-security-module, linux-arch, linux-doc, kernel-hardening,
netdev, x86, arnd, davem, hpa, mingo, oleg, peterz, rdunlap,
mcgrathr, tglx, eparis, serge.hallyn, djm, scarybeasts, indan,
pmoore, eric.dumazet, markus, coreyb, keescook, jmorris,
Andy Lutomirski, linux-man
In-Reply-To: <CAKgNAkhhnC1+vdh7vTYKkngzxHccDwHH_aKF5wCNhga33BGhyQ@mail.gmail.com>
> no longer unsustainable for me (man-pages is in competition with
^no longer unsustainable^no longer sustainable
^ permalink raw reply
* Re: [PATCH 5/9] ipvs: use adaptive pause in master thread
From: Pablo Neira Ayuso @ 2012-04-12 0:13 UTC (permalink / raw)
To: Julian Anastasov
Cc: Simon Horman, lvs-devel, netdev, netfilter-devel, Wensong Zhang
In-Reply-To: <alpine.LFD.2.00.1204112221250.2000@ja.ssi.bg>
Hi Julian,
On Wed, Apr 11, 2012 at 11:02:39PM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Tue, 10 Apr 2012, Pablo Neira Ayuso wrote:
>
> > You can still use kthread_should_stop inside a wrapper function
> > that calls kthread_stop and up() the semaphore.
> >
> > sync_stop:
> > kthread_stop(k)
> > up(s)
> >
> > kthread_routine:
> > while(1) {
> > down(s)
> > if (kthread_should_stop(k))
> > break;
> >
> > get sync msg
> > send sync msg
> > }
> >
> > BTW, each up() does not necessarily mean one wakeup event. up() will
> > delivery only one wakeup event for one process that has been already
> > awaken.
>
> OK, now I added up(). It will be called when
> 32 messages are queued after last sent by thread.
Why 32?
If you do up() once per message, you will still get an arbitrary
number of messages in the queue until the scheduler selects your
thread to enter the running state.
In other works, if you do up() once per 32 messages, your thread will
get N+32 messages in its queue by the time the scheduler makes it
enter the running state. Being N that amount of arbitrary messages.
This seems to me like more chances to overrun the socket buffer under
high stress.
> > > I'm still thinking if sndbuf value should be exported,
> > > currently users have to modify the global default/max value.
> >
> > I think it's a good idea.
>
> Done, used same value both for rcvbuf and sndbuf.
>
> > > But in below version I'm trying to handle the sndbuf overflow
> > > by blocking for write_space event. By this way we should work
> > > with any sndbuf configuration.
> >
> > You seem to be defering the overrun problem by using a longer
> > intermediate queue than the socket buffer. Then, that queue can be
> > tuned by the user via sysctl. It may happen under heavy stress that
> > your intermediate queue gets full again, then you'll have to drop
> > packets at some point.
>
> Yes, both values are for same thing, the problem is
> that queue size is in messages while socket buffer is in bytes.
> And as sndbuf config is optional, I'm not trying to derive
> sync_qlen_max from sndbuf. May be we can do it after
> socket is created but it will cause problem for systems
> that do not configure sync_sock_size, they before now used
> unlimited queue and may be default socket size, so using
> some small default sndbuf as sync_qlen_max can cause message
> drops. They will use reduced limits. So, now we provide
> some large sync_qlen_max as default configuration
> which probably exceeds the default socket buffer.
>
> Still, I think the down/up idea is not better.
> We are adding two new vars: master_stopped and
> master_sem.
Well, this is not exactly the idea I had in mind.
> The problem is that kthread_stop() is a blocking
> function. It waits thread to terminate. It can not wakeup
> thread blocked in down(), so we add master_stopped flag
> that will unblock the down() loop while kthread_stop() will also
> unblock thread if waiting for write_space. I.e. up()+kthread_stop()
> is racy without additional flag while kthread_stop()+up()
> is not possible to work.
I don't see the up+kthread_stop() race you mention.
> I'm appending untested version with up+down but I think
> we should use wake_up_process and schedule_timeout instead,
> as in previous version.
OK.
I still think that using an intermediate queue is *not* the way
to achieve reliability and congestion control, sorry.
But, you seem to persist on the idea and I don't want to block your
developments, I just wanted to show my point and provide some ideas.
After all, you maintain that part of the code.
Please, tell me what patch you want me to apply and I'll take it.
^ permalink raw reply
* Re: suspicious RCU usage warnings in 3.3.0
From: Stephen Hemminger @ 2012-04-12 0:10 UTC (permalink / raw)
To: paulmck; +Cc: Meelis Roos, David Miller, linux-kernel, netdev
In-Reply-To: <20120411230837.GC2473@linux.vnet.ibm.com>
On Wed, 11 Apr 2012 16:08:37 -0700
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> Hmmm... What CPU family is this running on? From the look of the
> stack, it is sneaking out of idle into softirq without telling RCU.
> This would cause RCU to complain bitterly about being invoked from
> the idle loop -- and RCU ignores CPUs in the idle loop.
>
> Thanx, Paul
Sun4... Ping David.
^ permalink raw reply
* Re: [PATCH] netfilter: ipvs: Verify that IP_VS protocol has been registered
From: Pablo Neira Ayuso @ 2012-04-11 23:46 UTC (permalink / raw)
To: Sasha Levin
Cc: wensong, horms, ja, kaber, davem, davej, netdev, lvs-devel,
netfilter-devel, linux-kernel
In-Reply-To: <20120411232243.GB7038@1984>
On Thu, Apr 12, 2012 at 01:22:43AM +0200, Pablo Neira Ayuso wrote:
> On Thu, Apr 05, 2012 at 07:24:33PM -0400, Sasha Levin wrote:
> > The registration of a protocol might fail, there were no checks
> > and all registrations were assumed to be correct. This lead to
> > NULL ptr dereferences when apps tried registering.
> >
> > For example:
> >
> > [ 1293.226051] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
> > [ 1293.227038] IP: [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> > [ 1293.227038] PGD 391de067 PUD 6c20b067 PMD 0
> > [ 1293.227038] Oops: 0000 [#1] PREEMPT SMP
> > [ 1293.227038] CPU 1
> > [ 1293.227038] Pid: 19609, comm: trinity Tainted: G W 3.4.0-rc1-next-20120405-sasha-dirty #57
> > [ 1293.227038] RIP: 0010:[<ffffffff822aacb0>] [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> > [ 1293.227038] RSP: 0018:ffff880038c1dd18 EFLAGS: 00010286
> > [ 1293.227038] RAX: ffffffffffffffc0 RBX: 0000000000001500 RCX: 0000000000010000
> > [ 1293.227038] RDX: 0000000000000000 RSI: ffff88003a2d5888 RDI: 0000000000000282
> > [ 1293.227038] RBP: ffff880038c1dd48 R08: 0000000000000000 R09: 0000000000000000
> > [ 1293.227038] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003a2d5668
> > [ 1293.227038] R13: ffff88003a2d5988 R14: ffff8800696a8ff8 R15: 0000000000000000
> > [ 1293.227038] FS: 00007f01930d9700(0000) GS:ffff88007ce00000(0000) knlGS:0000000000000000
> > [ 1293.227038] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [ 1293.227038] CR2: 0000000000000018 CR3: 0000000065dfc000 CR4: 00000000000406e0
> > [ 1293.227038] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [ 1293.227038] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > [ 1293.227038] Process trinity (pid: 19609, threadinfo ffff880038c1c000, task ffff88002dc73000)
> > [ 1293.227038] Stack:
> > [ 1293.227038] ffff880038c1dd48 00000000fffffff4 ffff8800696aada0 ffff8800694f5580
> > [ 1293.227038] ffffffff8369f1e0 0000000000001500 ffff880038c1dd98 ffffffff822a716b
> > [ 1293.227038] 0000000000000000 ffff8800696a8ff8 0000000000000015 ffff8800694f5580
> > [ 1293.227038] Call Trace:
> > [ 1293.227038] [<ffffffff822a716b>] ip_vs_app_inc_new+0xdb/0x180
> > [ 1293.227038] [<ffffffff822a7258>] register_ip_vs_app_inc+0x48/0x70
> > [ 1293.227038] [<ffffffff822b2fea>] __ip_vs_ftp_init+0xba/0x140
> > [ 1293.227038] [<ffffffff821c9060>] ops_init+0x80/0x90
> > [ 1293.227038] [<ffffffff821c90cb>] setup_net+0x5b/0xe0
> > [ 1293.227038] [<ffffffff821c9416>] copy_net_ns+0x76/0x100
> > [ 1293.227038] [<ffffffff810dc92b>] create_new_namespaces+0xfb/0x190
> > [ 1293.227038] [<ffffffff810dca21>] unshare_nsproxy_namespaces+0x61/0x80
> > [ 1293.227038] [<ffffffff810afd1f>] sys_unshare+0xff/0x290
> > [ 1293.227038] [<ffffffff8187622e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> > [ 1293.227038] [<ffffffff82665539>] system_call_fastpath+0x16/0x1b
> > [ 1293.227038] Code: 89 c7 e8 34 91 3b 00 89 de 66 c1 ee 04 31 de 83 e6 0f 48 83 c6 22 48 c1 e6 04 4a 8b 14 26 49 8d 34 34 48 8d 42 c0 48 39 d6 74 13 <66> 39 58 58 74 22 48 8b 48 40 48 8d 41 c0 48 39 ce 75 ed 49 8d
> > [ 1293.227038] RIP [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> > [ 1293.227038] RSP <ffff880038c1dd18>
> > [ 1293.227038] CR2: 0000000000000018
> > [ 1293.379284] ---[ end trace 364ab40c7011a009 ]---
> > [ 1293.381182] Kernel panic - not syncing: Fatal exception in interrupt
> >
> > Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> > ---
> > net/netfilter/ipvs/ip_vs_proto.c | 21 ++++++++++++++++-----
> > 1 files changed, 16 insertions(+), 5 deletions(-)
> >
> > diff --git a/net/netfilter/ipvs/ip_vs_proto.c b/net/netfilter/ipvs/ip_vs_proto.c
> > index f843a88..43893ba 100644
> > --- a/net/netfilter/ipvs/ip_vs_proto.c
> > +++ b/net/netfilter/ipvs/ip_vs_proto.c
> > @@ -316,20 +316,31 @@ ip_vs_tcpudp_debug_packet(int af, struct ip_vs_protocol *pp,
> > */
> > int __net_init ip_vs_protocol_net_init(struct net *net)
> > {
> > + int ret;
> > #ifdef CONFIG_IP_VS_PROTO_TCP
> > - register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
> > + ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
> > + if (ret < 0)
> > + return ret;
> > #endif
> > #ifdef CONFIG_IP_VS_PROTO_UDP
> > - register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
> > + ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
> > + if (ret < 0)
> > + return ret;
>
> If you return here, I think you'll leave things in inconsistent state,
> ie. the tcp protocol is registered. You have to unregister it before
> leaving.
>
> ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
^^^
sorry, I meant to say udp here.
> if (ret < 0)
> goto err_tcp;
^^^
and here.
> ...
> err_tcp:
> unregister_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
^ permalink raw reply
* Re: [RFC PATCH 1/2] net: ethtool: Add capability to retrieve plug-in module EEPROM
From: Ben Hutchings @ 2012-04-11 23:42 UTC (permalink / raw)
To: Stuart Hodgson
Cc: netdev, bruce.w.allan, mirq-linux, decot, amit.salecha,
alexander.h.duyck, davem, linux-kernel
In-Reply-To: <1334168217.2552.5.camel@bwh-desktop.uk.solarflarecom.com>
On Wed, 2012-04-11 at 19:16 +0100, Ben Hutchings wrote:
> On Wed, 2012-04-11 at 17:50 +0100, Stuart Hodgson wrote:
> > On 02/04/12 18:52, Ben Hutchings wrote:
> [...]
> > >> --- a/net/core/ethtool.c
> > >> +++ b/net/core/ethtool.c
> [...]
> > >> + if (eeprom.offset + eeprom.len> modinfo.eeprom_len)
> > >> + return -EINVAL;
> > >> +
> > >> + data = kmalloc(PAGE_SIZE, GFP_USER);
> > >> + if (!data)
> > >> + return -ENOMEM;
> > >
> > > What if some device has a larger EEPROM? Surely this length should be
> > > eeprom.len.
> > >
> >
> > Do you mean what if the eeprom length in te device is larger than
> > PAGE_SIZE?
>
> Yes.
>
> > If so then it should really use modinfo.eeprom_len since
> > this the size of the data. eeprom.len could be arbitary.
>
> No, eeprom.len is the size of the data and we've already validated it at
> this point.
Maybe we should start by refactoring ethtool_get_eeprom() so we can
reuse most of its code in ethtool_get_module_eeprom(), rather than
having to worry about what the maximum size of a module EEPROM might be
and whether we need a loop:
Subject: ethtool: Split ethtool_get_eeprom() to allow for additional EEPROM accessors
We want to support reading module (SFP+, XFP, ...) EEPROMs as well as
NIC EEPROMs. They will need a different command number and driver
operation, but the structure and arguments will be the same and so we
can share most of the code here.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
net/core/ethtool.c | 24 +++++++++++++++++-------
1 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index beacdd9..ca7698f 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -751,18 +751,17 @@ static int ethtool_get_link(struct net_device *dev, char __user *useraddr)
return 0;
}
-static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
+static int ethtool_get_any_eeprom(struct net_device *dev, void __user *useraddr,
+ int (*getter)(struct net_device *,
+ struct ethtool_eeprom *, u8 *),
+ u32 total_len)
{
struct ethtool_eeprom eeprom;
- const struct ethtool_ops *ops = dev->ethtool_ops;
void __user *userbuf = useraddr + sizeof(eeprom);
u32 bytes_remaining;
u8 *data;
int ret = 0;
- if (!ops->get_eeprom || !ops->get_eeprom_len)
- return -EOPNOTSUPP;
-
if (copy_from_user(&eeprom, useraddr, sizeof(eeprom)))
return -EFAULT;
@@ -771,7 +770,7 @@ static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
return -EINVAL;
/* Check for exceeding total eeprom len */
- if (eeprom.offset + eeprom.len > ops->get_eeprom_len(dev))
+ if (eeprom.offset + eeprom.len > total_len)
return -EINVAL;
data = kmalloc(PAGE_SIZE, GFP_USER);
@@ -782,7 +781,7 @@ static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
while (bytes_remaining > 0) {
eeprom.len = min(bytes_remaining, (u32)PAGE_SIZE);
- ret = ops->get_eeprom(dev, &eeprom, data);
+ ret = getter(dev, &eeprom, data);
if (ret)
break;
if (copy_to_user(userbuf, data, eeprom.len)) {
@@ -803,6 +802,17 @@ static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
return ret;
}
+static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
+{
+ const struct ethtool_ops *ops = dev->ethtool_ops;
+
+ if (!ops->get_eeprom || !ops->get_eeprom_len)
+ return -EOPNOTSUPP;
+
+ return ethtool_get_any_eeprom(dev, useraddr, ops->get_eeprom,
+ ops->get_eeprom_len(dev));
+}
+
static int ethtool_set_eeprom(struct net_device *dev, void __user *useraddr)
{
struct ethtool_eeprom eeprom;
--
1.7.7.6
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: [PATCH] netfilter: ipvs: Verify that IP_VS protocol has been registered
From: Pablo Neira Ayuso @ 2012-04-11 23:22 UTC (permalink / raw)
To: Sasha Levin
Cc: wensong, horms, ja, kaber, davem, davej, netdev, lvs-devel,
netfilter-devel, linux-kernel
In-Reply-To: <1333668273-8873-1-git-send-email-levinsasha928@gmail.com>
On Thu, Apr 05, 2012 at 07:24:33PM -0400, Sasha Levin wrote:
> The registration of a protocol might fail, there were no checks
> and all registrations were assumed to be correct. This lead to
> NULL ptr dereferences when apps tried registering.
>
> For example:
>
> [ 1293.226051] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
> [ 1293.227038] IP: [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> [ 1293.227038] PGD 391de067 PUD 6c20b067 PMD 0
> [ 1293.227038] Oops: 0000 [#1] PREEMPT SMP
> [ 1293.227038] CPU 1
> [ 1293.227038] Pid: 19609, comm: trinity Tainted: G W 3.4.0-rc1-next-20120405-sasha-dirty #57
> [ 1293.227038] RIP: 0010:[<ffffffff822aacb0>] [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> [ 1293.227038] RSP: 0018:ffff880038c1dd18 EFLAGS: 00010286
> [ 1293.227038] RAX: ffffffffffffffc0 RBX: 0000000000001500 RCX: 0000000000010000
> [ 1293.227038] RDX: 0000000000000000 RSI: ffff88003a2d5888 RDI: 0000000000000282
> [ 1293.227038] RBP: ffff880038c1dd48 R08: 0000000000000000 R09: 0000000000000000
> [ 1293.227038] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003a2d5668
> [ 1293.227038] R13: ffff88003a2d5988 R14: ffff8800696a8ff8 R15: 0000000000000000
> [ 1293.227038] FS: 00007f01930d9700(0000) GS:ffff88007ce00000(0000) knlGS:0000000000000000
> [ 1293.227038] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 1293.227038] CR2: 0000000000000018 CR3: 0000000065dfc000 CR4: 00000000000406e0
> [ 1293.227038] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 1293.227038] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 1293.227038] Process trinity (pid: 19609, threadinfo ffff880038c1c000, task ffff88002dc73000)
> [ 1293.227038] Stack:
> [ 1293.227038] ffff880038c1dd48 00000000fffffff4 ffff8800696aada0 ffff8800694f5580
> [ 1293.227038] ffffffff8369f1e0 0000000000001500 ffff880038c1dd98 ffffffff822a716b
> [ 1293.227038] 0000000000000000 ffff8800696a8ff8 0000000000000015 ffff8800694f5580
> [ 1293.227038] Call Trace:
> [ 1293.227038] [<ffffffff822a716b>] ip_vs_app_inc_new+0xdb/0x180
> [ 1293.227038] [<ffffffff822a7258>] register_ip_vs_app_inc+0x48/0x70
> [ 1293.227038] [<ffffffff822b2fea>] __ip_vs_ftp_init+0xba/0x140
> [ 1293.227038] [<ffffffff821c9060>] ops_init+0x80/0x90
> [ 1293.227038] [<ffffffff821c90cb>] setup_net+0x5b/0xe0
> [ 1293.227038] [<ffffffff821c9416>] copy_net_ns+0x76/0x100
> [ 1293.227038] [<ffffffff810dc92b>] create_new_namespaces+0xfb/0x190
> [ 1293.227038] [<ffffffff810dca21>] unshare_nsproxy_namespaces+0x61/0x80
> [ 1293.227038] [<ffffffff810afd1f>] sys_unshare+0xff/0x290
> [ 1293.227038] [<ffffffff8187622e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [ 1293.227038] [<ffffffff82665539>] system_call_fastpath+0x16/0x1b
> [ 1293.227038] Code: 89 c7 e8 34 91 3b 00 89 de 66 c1 ee 04 31 de 83 e6 0f 48 83 c6 22 48 c1 e6 04 4a 8b 14 26 49 8d 34 34 48 8d 42 c0 48 39 d6 74 13 <66> 39 58 58 74 22 48 8b 48 40 48 8d 41 c0 48 39 ce 75 ed 49 8d
> [ 1293.227038] RIP [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> [ 1293.227038] RSP <ffff880038c1dd18>
> [ 1293.227038] CR2: 0000000000000018
> [ 1293.379284] ---[ end trace 364ab40c7011a009 ]---
> [ 1293.381182] Kernel panic - not syncing: Fatal exception in interrupt
>
> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> ---
> net/netfilter/ipvs/ip_vs_proto.c | 21 ++++++++++++++++-----
> 1 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_proto.c b/net/netfilter/ipvs/ip_vs_proto.c
> index f843a88..43893ba 100644
> --- a/net/netfilter/ipvs/ip_vs_proto.c
> +++ b/net/netfilter/ipvs/ip_vs_proto.c
> @@ -316,20 +316,31 @@ ip_vs_tcpudp_debug_packet(int af, struct ip_vs_protocol *pp,
> */
> int __net_init ip_vs_protocol_net_init(struct net *net)
> {
> + int ret;
> #ifdef CONFIG_IP_VS_PROTO_TCP
> - register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
> + ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
> + if (ret < 0)
> + return ret;
> #endif
> #ifdef CONFIG_IP_VS_PROTO_UDP
> - register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
> + ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
> + if (ret < 0)
> + return ret;
If you return here, I think you'll leave things in inconsistent state,
ie. the tcp protocol is registered. You have to unregister it before
leaving.
ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
if (ret < 0)
goto err_tcp;
...
err_tcp:
unregister_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
^ permalink raw reply
* Re: [PATCH 1/1] netfilter: xt_recent: Add optional mask option for xt_recent
From: Pablo Neira Ayuso @ 2012-04-11 23:14 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: Patrick McHardy, David S. Miller, netfilter-devel, netfilter,
coreteam, linux-kernel, netdev
In-Reply-To: <1331033084-23803-1-git-send-email-denys@visp.net.lb>
Hi Denys,
On Tue, Mar 06, 2012 at 01:24:44PM +0200, Denys Fedoryshchenko wrote:
> Use case for this feature:
> 1)In some occasions if you need to allow,block,match specific subnet.
> 2)I can use recent as a trigger when netfilter rule matches, with mask 0.0.0.0
>
> Example:
>
> If you ping 8.8.8.8, after that you can't ping 2.2.2.10
Could you provide an useful example for this new feature?
I also think you can make this with hashlimit, that allows you to
set the network mask.
^ permalink raw reply
* Re: suspicious RCU usage warnings in 3.3.0
From: Paul E. McKenney @ 2012-04-11 23:08 UTC (permalink / raw)
To: Meelis Roos; +Cc: David Miller, linux-kernel, netdev
In-Reply-To: <alpine.SOC.1.00.1204111807420.26884@math.ut.ee>
On Wed, Apr 11, 2012 at 06:08:53PM +0300, Meelis Roos wrote:
> > > Is this the same RCU problem that was fixed after 3.3 (fix a potential
> > > rcu_read_lock() imbalance in rt6_fill_node())? My problem does not seem
> > > to be ipv6-only, most traces are from IPv6 but some for ip.
> >
> > It's hard to say because the ipv6 RCU problem causes the warning to
> > trigger somewhere away from the ipv6 code that had the RCU locking
> > bug.
>
> Tested todays 3.4.0-rc2-00016-ga9e1e53 on the same with flood ping and
> still got RCU warning:
Hmmm... What CPU family is this running on? From the look of the
stack, it is sneaking out of idle into softirq without telling RCU.
This would cause RCU to complain bitterly about being invoked from
the idle loop -- and RCU ignores CPUs in the idle loop.
Thanx, Paul
> [36456.693191]
> [36456.712658] ===============================
> [36456.767614] [ INFO: suspicious RCU usage. ]
> [36456.822588] 3.4.0-rc2-00016-ga9e1e53 #36 Not tainted
> [36456.887835] -------------------------------
> [36456.942804] include/linux/netpoll.h:70 suspicious rcu_dereference_check() usage!
> [36457.040083]
> [36457.040089] other info that might help us debug this:
> [36457.040098]
> [36457.145306]
> [36457.145312] RCU used illegally from idle CPU!
> [36457.145320] rcu_scheduler_active = 1, debug_locks = 0
> [36457.288293] RCU used illegally from extended quiescent state!
> [36457.363834] no locks held by swapper/0.
> [36457.414221]
> [36457.414227] stack backtrace:
> [36457.471471] Call Trace:
> [36457.503600] [0000000000489834] lockdep_rcu_suspicious+0xd4/0x100
> [36457.583727] [00000000006755a8] __netif_receive_skb+0x368/0xa80
> [36457.661536] [0000000000675e6c] netif_receive_skb+0x4c/0x60
> [36457.734787] [000000000063fd74] tulip_poll+0x3b4/0x6a0
> [36457.802327] [00000000006794d8] net_rx_action+0x118/0x1e0
> [36457.873299] [00000000004560fc] __do_softirq+0x9c/0x140
> [36457.941984] [000000000042b1c4] do_softirq+0x84/0xc0
> [36458.007229] [0000000000404a40] __handle_softirq+0x0/0x10
> [36458.078199] [000000000042b688] cpu_idle+0x48/0x100
> [36458.142314] [0000000000722db8] rest_init+0x160/0x188
> [36458.208711] [00000000008c87b0] start_kernel+0x32c/0x33c
> [36458.278530] [0000000000722c50] tlb_fixup_done+0x88/0x90
> [36458.348346] [0000000000000000] (null)
>
>
> --
> Meelis Roos (mroos@linux.ee)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: via-rhine: Problem with lost link after a while
From: Francois Romieu @ 2012-04-11 22:21 UTC (permalink / raw)
To: Svenning Sørensen
Cc: Bjarke Istrup Pedersen, linux-kernel, netdev, Andreas Mohr
In-Reply-To: <4F8553BF.6030303@secomea.com>
Svenning Sørensen <sss@secomea.com> :
[...]
> Regarding the "Tx descriptor busy" test: no, I didn't see it
> trigger, I just put it there just in case because I suspected there
> could be a race due to the lock-free tx path.
> But I'm glad if you're confident that it can't happen :)
Almost :o)
Without the patch it may happen in mainline. Once the napi Tx completion
function checks if queueing is stopped before enabling it, it should not
happen though. The patch should fix the race where queuing is not enabled
as well.
That being said, I would welcome a pony^W^W some testing on a multi-core
system with lots of Tx and enough irq from a different (non via-rhine)
source to starve the softirq processing.
--
Ueimor
^ 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