* Re: [PATCH net-next 6/6] tg3: Make the RSS indir tbl admin configurable
From: Ben Hutchings @ 2011-12-14 21:50 UTC (permalink / raw)
To: Matt Carlson; +Cc: davem, netdev, Michael Chan
In-Reply-To: <1323897002-17295-7-git-send-email-mcarlson@broadcom.com>
On Wed, 2011-12-14 at 13:10 -0800, Matt Carlson wrote:
> This patch adds the ethtool callbacks necessary to change the rss
> indirection table from userspace. When setting the indirection table
> through set_rxfh_indir, an indirection table size of zero is
> interpreted to mean that the admin wants to relinquish control of the
> table to the driver.
I'm not convinced that this is a particularly useful option, but I won't
object. But please document this as an optional driver behaviour in
<linux/ethtool.h>, and add support for this in the ethtool command (e.g.
a 'reset' or 'default' keyword).
> Should the number of interrupts change (e.g.
> across a close / open call, or through a reset), any indirection table
> values that exceed the number of RSS queues or interrupt vectors will
> be automatically scaled back to values within range.
>
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> Reviewed-by: Benjamin Li <benli@broadcom.com>
> ---
> drivers/net/ethernet/broadcom/tg3.c | 128 ++++++++++++++++++++++++++++++++++-
> drivers/net/ethernet/broadcom/tg3.h | 1 +
> 2 files changed, 128 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
> index 8bf11ca..f684be9 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -8229,9 +8229,18 @@ void tg3_rss_init_indir_tbl(struct tg3 *tp)
>
> if (tp->irq_cnt <= 2)
> memset(&tp->rss_ind_tbl[0], 0, sizeof(tp->rss_ind_tbl));
> - else
> + else if (tg3_flag(tp, USER_INDIR_TBL)) {
> + /* Validate table against current IRQ count */
> + for (i = 0; i < TG3_RSS_INDIR_TBL_SIZE; i++) {
> + if (tp->rss_ind_tbl[i] >= tp->irq_cnt - 1) {
> + /* Cap the vector index */
> + tp->rss_ind_tbl[i] = tp->irq_cnt - 2;
A modulo operation might make more sense. But I don't suppose this
failure is going to happen often enough for it to be important.
> + }
> + }
> + } else {
> for (i = 0; i < TG3_RSS_INDIR_TBL_SIZE; i++)
> tp->rss_ind_tbl[i] = i % (tp->irq_cnt - 1);
> + }
> }
>
> void tg3_rss_write_indir_tbl(struct tg3 *tp)
> @@ -10719,6 +10728,120 @@ static int tg3_get_sset_count(struct net_device *dev, int sset)
> }
> }
>
> +static int tg3_get_rxnfc(struct net_device *dev, struct ethtool_rxnfc *info,
> + u32 *rules __always_unused)
> +{
> + struct tg3 *tp = netdev_priv(dev);
> +
> + if (!tg3_flag(tp, SUPPORT_MSIX))
> + return -EINVAL;
Should be -EOPNOTSUPP.
> + if (!netif_running(tp->dev))
> + return -EAGAIN;
Why? You do handle !netif_running() below...
> + switch (info->cmd) {
> + case ETHTOOL_GRXRINGS:
> + if (netif_running(tp->dev))
> + info->data = tp->irq_cnt;
> + else {
> + info->data = num_online_cpus();
> + if (info->data > TG3_IRQ_MAX_VECS_RSS)
> + info->data = TG3_IRQ_MAX_VECS_RSS;
> + }
> +
> + /* The first interrupt vector only
> + * handles link interrupts.
> + */
> + info->data -= 1;
> + return 0;
> +
> + default:
> + return -EOPNOTSUPP;
> + }
> +}
> +
> +static int tg3_get_rxfh_indir(struct net_device *dev,
> + struct ethtool_rxfh_indir *indir)
> +{
> + struct tg3 *tp = netdev_priv(dev);
> + int i;
> +
> + if (!tg3_flag(tp, SUPPORT_MSIX))
> + return -EINVAL;
-EOPNOTSUPP
> + if (!indir->size) {
> + indir->size = TG3_RSS_INDIR_TBL_SIZE;
> + return 0;
> + }
> +
> + if (indir->size != TG3_RSS_INDIR_TBL_SIZE)
> + return -EINVAL;
This is enough to make the ethtool command work, but you're really
supposed to copy min(indir->size, TG3_RSS_INDIR_TBL_SIZE) entries.
> + for (i = 0; i < TG3_RSS_INDIR_TBL_SIZE; i++)
> + indir->ring_index[i] = tp->rss_ind_tbl[i];
> +
> + return 0;
> +}
> +
> +static int tg3_set_rxfh_indir(struct net_device *dev,
> + const struct ethtool_rxfh_indir *indir)
> +{
[...]
This function looks fine.
Ben.
--
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
* Re: [PATCH 1/2] e100: power down PHY if WOL is not enabled
From: Jiang Wang @ 2011-12-14 21:59 UTC (permalink / raw)
To: Ben Hutchings
Cc: Francis St. Amant, Panchamukhi, Carolyn, miles.ito@intel.com,
e1000-devel@lists.sourceforge.net, Bruce Allan, Jesse Brandeburg,
linux-kernel@vger.kernel.org, John Ronciak, Prasanna,
netdev@vger.kernel.org, Chaitanya Lala, Peter
In-Reply-To: <1323894636.2753.2.camel@bwh-desktop>
Hi Ben,
Do you mean the WOL is enabled but PHY is powered off somehow? That scenario should never happen. If WOL is enabled, there is no code to power off PHY.
Regards,
Jiang
-------------------------------------
Jiang Wang
Member of Technical Staff
Riverbed Technology
Tel: (408) 522-5109
Email: Jiang.Wang@riverbed.com
www.riverbed.com
-----Original Message-----
From: Ben Hutchings [mailto:bhutchings@solarflare.com]
Sent: Wednesday, December 14, 2011 12:31 PM
To: Jiang Wang
Cc: Jeff Kirsher; Jesse Brandeburg; Bruce Allan; Carolyn Wyborny; Don Skidmore; Greg Rose; Peter P Waskiewicz Jr; Alex Duyck; John Ronciak; e1000-devel@lists.sourceforge.net; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Prasanna Panchamukhi; Chaitanya Lala; Francis St. Amant; miles.ito@intel.com
Subject: Re: [PATCH 1/2] e100: power down PHY if WOL is not enabled
On Tue, 2011-12-13 at 18:49 -0800, Jiang Wang wrote:
> Since the interface will not be used after being put down and WOL is
> disabled, just power it off.
> When bring up the interface, power on the PHY.
Don't you need to cover the case where WOL is enabled while the interface is down?
Ben.
> Signed-off-by: Jiang Wang <Jiang.Wang@riverbed.com>
> ---
> drivers/net/ethernet/intel/e100.c | 17 +++++++++++++++++
> 1 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e100.c
> b/drivers/net/ethernet/intel/e100.c
> index 5a2fdf7..9824e0a 100644
> --- a/drivers/net/ethernet/intel/e100.c
> +++ b/drivers/net/ethernet/intel/e100.c
> @@ -1449,6 +1449,14 @@ static int e100_phy_init(struct nic *nic)
> netif_printk(nic, hw, KERN_DEBUG, nic->netdev,
> "phy_addr = %d\n", nic->mii.phy_id);
>
> + /* Make sure power to the PHY is enabled */
> + if (!(nic->flags & wol_magic)) {
> + uint16_t phy_data;
> + phy_data = mdio_read(nic->netdev, nic->mii.phy_id, MII_BMCR);
> + phy_data &= ~BMCR_PDOWN;
> + mdio_write(nic->netdev, nic->mii.phy_id, MII_BMCR, phy_data);
> + }
> +
> /* Get phy ID */
> id_lo = mdio_read(netdev, nic->mii.phy_id, MII_PHYSID1);
> id_hi = mdio_read(netdev, nic->mii.phy_id, MII_PHYSID2); @@ -2261,6
> +2269,15 @@ static void e100_down(struct nic *nic)
> napi_disable(&nic->napi);
> netif_stop_queue(nic->netdev);
> e100_hw_reset(nic);
> +
> + /* If wake on LAN is not enabled, power down the PHY */
> + if (!(nic->flags & wol_magic)) {
> + uint16_t phy_data;
> + phy_data = mdio_read(nic->netdev, nic->mii.phy_id, MII_BMCR);
> + phy_data |= BMCR_PDOWN;
> + mdio_write(nic->netdev, nic->mii.phy_id, MII_BMCR, phy_data);
> + }
> +
> free_irq(nic->pdev->irq, nic->netdev);
> del_timer_sync(&nic->watchdog);
> netif_carrier_off(nic->netdev);
--
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.
------------------------------------------------------------------------------
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH 1/2] e100: power down PHY if WOL is not enabled
From: Ben Hutchings @ 2011-12-14 22:07 UTC (permalink / raw)
To: Jiang Wang
Cc: Francis St. Amant, Panchamukhi, Carolyn, miles.ito@intel.com,
e1000-devel@lists.sourceforge.net, Bruce Allan, Jesse Brandeburg,
linux-kernel@vger.kernel.org, John Ronciak, Prasanna,
netdev@vger.kernel.org, Chaitanya Lala, Peter
In-Reply-To: <CEE05A0D7856E14880AD5560634EBEA82AA78720@365EXCH-MBX-P5.nbttech.com>
On Wed, 2011-12-14 at 21:59 +0000, Jiang Wang wrote:
> Hi Ben,
>
> Do you mean the WOL is enabled but PHY is powered off somehow? That
> scenario should never happen. If WOL is enabled, there is no code to
> power off PHY.
[...]
Initial conditions: interface up, WOL off, PHY on.
1. Bring interface down. PHY is turned off.
2. Turn WOL on. PHY is still off, but needs to be on.
Ben.
--
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.
------------------------------------------------------------------------------
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* RE: [PATCH 1/2] e100: power down PHY if WOL is not enabled
From: Jiang Wang @ 2011-12-14 22:16 UTC (permalink / raw)
To: Ben Hutchings
Cc: Jeff Kirsher, Jesse Brandeburg, Bruce Allan, Carolyn Wyborny,
Don Skidmore, Greg Rose, Peter P Waskiewicz Jr, Alex Duyck,
John Ronciak, e1000-devel@lists.sourceforge.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Prasanna Panchamukhi, Chaitanya Lala, Francis St. Amant,
miles.ito@intel.com
In-Reply-To: <1323900468.2753.22.camel@bwh-desktop>
I see. I will add one more check for that. Thanks.
-------------------------------------
Jiang Wang
Member of Technical Staff
Riverbed Technology
Tel: (408) 522-5109
Email: Jiang.Wang@riverbed.com
www.riverbed.com
-----Original Message-----
From: Ben Hutchings [mailto:bhutchings@solarflare.com]
Sent: Wednesday, December 14, 2011 2:08 PM
To: Jiang Wang
Cc: Jeff Kirsher; Jesse Brandeburg; Bruce Allan; Carolyn Wyborny; Don Skidmore; Greg Rose; Peter P Waskiewicz Jr; Alex Duyck; John Ronciak; e1000-devel@lists.sourceforge.net; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Prasanna Panchamukhi; Chaitanya Lala; Francis St. Amant; miles.ito@intel.com
Subject: RE: [PATCH 1/2] e100: power down PHY if WOL is not enabled
On Wed, 2011-12-14 at 21:59 +0000, Jiang Wang wrote:
> Hi Ben,
>
> Do you mean the WOL is enabled but PHY is powered off somehow? That
> scenario should never happen. If WOL is enabled, there is no code to
> power off PHY.
[...]
Initial conditions: interface up, WOL off, PHY on.
1. Bring interface down. PHY is turned off.
2. Turn WOL on. PHY is still off, but needs to be on.
Ben.
--
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
* Re: [PATCH net-next] inet: remove rcu protection on tw_net
From: Eric Dumazet @ 2011-12-14 22:28 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: David Miller, netdev
In-Reply-To: <m1d3bqaowg.fsf@fess.ebiederm.org>
Le mercredi 14 décembre 2011 à 12:17 -0800, Eric W. Biederman a écrit :
> Eric Dumazet <eric.dumazet@gmail.com> writes:
>
> > commit b099ce2602d806 (net: Batch inet_twsk_purge) added rcu protection
> > on tw_net for no obvious reason.
>
> From that commit I see:
>
> sk_nulls_for_each_rcu(sk, node, &head->twchain) {
> tw = inet_twsk(sk);
> - if (!net_eq(twsk_net(tw), net) ||
> - tw->tw_family != family)
> + if ((tw->tw_family != family) ||
> + atomic_read(&twsk_net(tw)->count))
>
> That atomic_read is a new dereference of twsk_net in an only rcu
> protected section. That seems like an obvious reason to me.
>
Absolutely not.
As I said twsk_net() cannot change in a tw lifetime.
(If it could, this code would be bogus anyway, you should use :
net = twsk_net(tw);
if (tw->tw_family != family || !net || atomic_read(&net->count))
...
> > struct net are refcounted anyway since timewait sockets escape from rcu
> > protected sections. tw_net stay valid for the whole timwait lifetime.
>
> What? twsk_net_set does not bump the struct net ref count.
>
The commit I mentioned did not change anything in this respect.
> There is that stupid hold_net/release_net over designed debugging
> thinko that makes it look like we have a refcount. We should probably
> just kill that thing. But a time wait socket unlike a normal socket
> does not keep a network namespace alive. Which is why we have to purge
> pending timewait sockets when a network namespace exits.
>
Since you do a cleanup _before_ removing "struct net", you have absolute
guarantee tw_net is stable, you dont need rcu_dereference() (and implied
smb_rmb()) at all.
Why pay the price twice, once in the super heavy inet_twsk_purge()
function, once in every twsk_net() calls ?
[ By the way, rcu_dereference_raw() dubious use is another sign we dont
really know what RCU invariant is respected when calling twsk_net(tw) ]
> > This also removes a lot of sparse errors.
>
> What is sparse saying that we are doing wrong?
>
CONFIG_SPARSE_RCU_POINTER=y
make C=2 net/ipv4/inet_timewait_sock.o
CHECK net/ipv4/inet_timewait_sock.c
include/net/inet_timewait_sock.h:222:16: error: incompatible types in
comparison expression (different address spaces)
[ repeat NN times ]
comparison expression (different address spaces)
include/net/inet_timewait_sock.h:222:16: error: incompatible types in
comparison expression (different address spaces)
include/net/inet_timewait_sock.h:222:16: error: incompatible types in
comparison expression (different address spaces)
include/net/inet_timewait_sock.h:222:16: error: incompatible types in
comparison expression (different address spaces)
include/net/inet_timewait_sock.h:222:16: error: too many errors
> There may be constraints that are strong enough that we can get away
> this but I am at least a little dubious.
>
Thanks for reviewing and comments !
^ permalink raw reply
* Re: TCP fast retransmit
From: Eric Dumazet @ 2011-12-14 22:31 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: Esztermann, Ansgar, netdev@vger.kernel.org
In-Reply-To: <CAK6E8=dcG3mw8r4FXt62G-0uoRNa9tcyQL3DS62MYe8F=9R6Nw@mail.gmail.com>
Le mercredi 14 décembre 2011 à 11:00 -0800, Yuchung Cheng a écrit :
> >
> I use tcptrace to check the time sequence and I am puzzled:
> I see a lot of OOO packets too but how can this happen at a sender-side trace?
> unless the trace is taken close to but not exactly at the sender.
> I expect on seeing in-sequence packets but a lots of SACKs plus some
> spurious retransmists.
I understood the trace was a receiver-side one (a linux machine if I am
not mistaken, while the sender is AIX powered)
(Looking at timings of ACKS, coming a few us after corresponding data
packet arrival)
^ permalink raw reply
* Re: [PATCH net-next 2/2] igb: offer a PTP Hardware Clock instead of the timecompare method
From: Jesse Brandeburg @ 2011-12-14 22:33 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev@vger.kernel.org, e1000-devel@lists.sourceforge.net,
Keller, Jacob E, Kirsher, Jeffrey T, Ronciak, John, John Stultz,
Thomas Gleixner, Wyborny, Carolyn
In-Reply-To: <388385c50909f63bff239894c60dbb00abc65c93.1323744725.git.richardcochran@gmail.com>
On Mon, 2011-12-12 at 19:00 -0800, Richard Cochran wrote:
> This commit removes the legacy timecompare code from the igb driver and
> offers a tunable PHC instead.
>
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Richard, first, thanks for this work, I have some feedback and request
you make a V2.
> - /*
> - * The timestamp latches on lowest register read. For the 82580
> - * the lowest register is SYSTIMR instead of SYSTIML. However we never
> - * adjusted TIMINCA so SYSTIMR will just read as all 0s so ignore it.
> - */
Please keep this comment in your new igb_82580_systim_read, it explains
a bit of *why* we are doing something. There were a lot of explanatory
comments that you removed, please audit the "-" lines of your patch and
add back the comments that are appropriate in your new code.
> - if (hw->mac.type >= e1000_82580) {
> - stamp = rd32(E1000_SYSTIMR) >> 8;
> - shift = IGB_82580_TSYNC_SHIFT;
> - }
> -
> - stamp |= (u64)rd32(E1000_SYSTIML) << shift;
> - stamp |= (u64)rd32(E1000_SYSTIMH) << (shift + 32);
> - return stamp;
> -}
> -
> /**
> * igb_get_hw_dev - return device
> * used by hardware layer to print debugging information
> @@ -2080,7 +2052,7 @@ static int __devinit igb_probe(struct pci_dev *pdev,
>
> #endif
> /* do hw tstamp init after resetting */
> - igb_init_hw_timer(adapter);
> + igb_ptp_init(adapter);
>
> dev_info(&pdev->dev, "Intel(R) Gigabit Ethernet Network Connection\n");
> /* print bus type/speed/width info */
> @@ -2150,6 +2122,8 @@ static void __devexit igb_remove(struct pci_dev *pdev)
> struct igb_adapter *adapter = netdev_priv(netdev);
> struct e1000_hw *hw = &adapter->hw;
>
> + igb_ptp_remove(adapter);
> +
> /*
> * The watchdog timer may be rescheduled, so explicitly
> * disable watchdog from being rescheduled.
> @@ -2269,112 +2243,6 @@ out:
> }
>
> /**
> - * igb_init_hw_timer - Initialize hardware timer used with IEEE 1588 timestamp
> - * @adapter: board private structure to initialize
> - *
> - * igb_init_hw_timer initializes the function pointer and values for the hw
> - * timer found in hardware.
> - **/
> -static void igb_init_hw_timer(struct igb_adapter *adapter)
> -{
> - struct e1000_hw *hw = &adapter->hw;
> -
> - switch (hw->mac.type) {
> - case e1000_i350:
> - case e1000_82580:
> - memset(&adapter->cycles, 0, sizeof(adapter->cycles));
> - adapter->cycles.read = igb_read_clock;
> - adapter->cycles.mask = CLOCKSOURCE_MASK(64);
> - adapter->cycles.mult = 1;
> - /*
> - * The 82580 timesync updates the system timer every 8ns by 8ns
> - * and the value cannot be shifted. Instead we need to shift
> - * the registers to generate a 64bit timer value. As a result
> - * SYSTIMR/L/H, TXSTMPL/H, RXSTMPL/H all have to be shifted by
> - * 24 in order to generate a larger value for synchronization.
> - */
> - adapter->cycles.shift = IGB_82580_TSYNC_SHIFT;
> - /* disable system timer temporarily by setting bit 31 */
> - wr32(E1000_TSAUXC, 0x80000000);
> - wrfl();
> -
> - /* Set registers so that rollover occurs soon to test this. */
> - wr32(E1000_SYSTIMR, 0x00000000);
> - wr32(E1000_SYSTIML, 0x80000000);
> - wr32(E1000_SYSTIMH, 0x000000FF);
> - wrfl();
> -
> - /* enable system timer by clearing bit 31 */
> - wr32(E1000_TSAUXC, 0x0);
> - wrfl();
> -
> - timecounter_init(&adapter->clock,
> - &adapter->cycles,
> - ktime_to_ns(ktime_get_real()));
> - /*
> - * Synchronize our NIC clock against system wall clock. NIC
> - * time stamp reading requires ~3us per sample, each sample
> - * was pretty stable even under load => only require 10
> - * samples for each offset comparison.
> - */
> - memset(&adapter->compare, 0, sizeof(adapter->compare));
> - adapter->compare.source = &adapter->clock;
> - adapter->compare.target = ktime_get_real;
> - adapter->compare.num_samples = 10;
> - timecompare_update(&adapter->compare, 0);
> - break;
> - case e1000_82576:
> - /*
> - * Initialize hardware timer: we keep it running just in case
> - * that some program needs it later on.
> - */
> - memset(&adapter->cycles, 0, sizeof(adapter->cycles));
> - adapter->cycles.read = igb_read_clock;
> - adapter->cycles.mask = CLOCKSOURCE_MASK(64);
> - adapter->cycles.mult = 1;
> - /**
> - * Scale the NIC clock cycle by a large factor so that
> - * relatively small clock corrections can be added or
> - * subtracted at each clock tick. The drawbacks of a large
> - * factor are a) that the clock register overflows more quickly
> - * (not such a big deal) and b) that the increment per tick has
> - * to fit into 24 bits. As a result we need to use a shift of
> - * 19 so we can fit a value of 16 into the TIMINCA register.
> - */
> - adapter->cycles.shift = IGB_82576_TSYNC_SHIFT;
> - wr32(E1000_TIMINCA,
> - (1 << E1000_TIMINCA_16NS_SHIFT) |
> - (16 << IGB_82576_TSYNC_SHIFT));
> -
> - /* Set registers so that rollover occurs soon to test this. */
> - wr32(E1000_SYSTIML, 0x00000000);
> - wr32(E1000_SYSTIMH, 0xFF800000);
> - wrfl();
> -
> - timecounter_init(&adapter->clock,
> - &adapter->cycles,
> - ktime_to_ns(ktime_get_real()));
> - /*
> - * Synchronize our NIC clock against system wall clock. NIC
> - * time stamp reading requires ~3us per sample, each sample
> - * was pretty stable even under load => only require 10
> - * samples for each offset comparison.
> - */
> - memset(&adapter->compare, 0, sizeof(adapter->compare));
> - adapter->compare.source = &adapter->clock;
> - adapter->compare.target = ktime_get_real;
> - adapter->compare.num_samples = 10;
> - timecompare_update(&adapter->compare, 0);
> - break;
> - case e1000_82575:
> - /* 82575 does not support timesync */
> - default:
> - break;
> - }
> -
> -}
> -
> -/**
> * igb_sw_init - Initialize general software structures (struct igb_adapter)
> * @adapter: board private structure to initialize
> *
> @@ -5628,35 +5496,6 @@ static int igb_poll(struct napi_struct *napi, int budget)
> }
>
> /**
> - * igb_systim_to_hwtstamp - convert system time value to hw timestamp
> - * @adapter: board private structure
> - * @shhwtstamps: timestamp structure to update
> - * @regval: unsigned 64bit system time value.
> - *
> - * We need to convert the system time value stored in the RX/TXSTMP registers
> - * into a hwtstamp which can be used by the upper level timestamping functions
> - */
> -static void igb_systim_to_hwtstamp(struct igb_adapter *adapter,
> - struct skb_shared_hwtstamps *shhwtstamps,
> - u64 regval)
> -{
> - u64 ns;
> -
> - /*
> - * The 82580 starts with 1ns at bit 0 in RX/TXSTMPL, shift this up to
> - * 24 to match clock shift we setup earlier.
> - */
> - if (adapter->hw.mac.type >= e1000_82580)
> - regval <<= IGB_82580_TSYNC_SHIFT;
> -
> - ns = timecounter_cyc2time(&adapter->clock, regval);
> - timecompare_update(&adapter->compare, ns);
> - memset(shhwtstamps, 0, sizeof(struct skb_shared_hwtstamps));
> - shhwtstamps->hwtstamp = ns_to_ktime(ns);
> - shhwtstamps->syststamp = timecompare_transform(&adapter->compare, ns);
> -}
> -
> -/**
> * igb_tx_hwtstamp - utility function which checks for TX time stamp
> * @q_vector: pointer to q_vector containing needed info
> * @buffer: pointer to igb_tx_buffer structure
> diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c b/drivers/net/ethernet/intel/igb/igb_ptp.c
> index 7a9f6bc..7a62980 100644
> --- a/drivers/net/ethernet/intel/igb/igb_ptp.c
> +++ b/drivers/net/ethernet/intel/igb/igb_ptp.c
> @@ -406,3 +406,45 @@ void igb_ptp_remove(struct igb_adapter *adapter)
> adapter->netdev->name);
> }
> }
> +
> +/**
> + * igb_systim_to_hwtstamp - convert system time value to hw timestamp
> + * @adapter: board private structure
> + * @shhwtstamps: timestamp structure to update
cut and paste typo? should match the arguments below.
> + * @systim: unsigned 64bit system time value.
> + *
> + * We need to convert the system time value stored in the RX/TXSTMP registers
> + * into a hwtstamp which can be used by the upper level timestamping functions
> + */
> +void igb_systim_to_hwtstamp(struct igb_adapter *adapter,
> + struct skb_shared_hwtstamps *hwtstamps,
> + u64 systim)
> +{
> + u64 ns;
> + unsigned long flags;
> + unsigned int shift;
> + int msb_set;
> +
> + switch (adapter->hw.mac.type) {
> + case e1000_i350:
> + case e1000_82580:
> + shift = OFL_SHIFT_82580;
> + msb_set = (systim >> 32) & SYSTIMH_MSB_82580;
> + break;
> + case e1000_82576:
> + shift = OFL_SHIFT_82576;
> + msb_set = (systim >> 32) & SYSTIMH_MSB_82576;
> + break;
> + default:
> + return;
> + }
> +
> + spin_lock_irqsave(&adapter->tmreg_lock, flags);
based on the discussion on the list with eric dumazet it should have a
comment here why the spinlock is needed and about how it is expected to
impact performance.
> +
> + ns = igb_overflow_get(adapter, systim, msb_set, shift);
> +
> + spin_unlock_irqrestore(&adapter->tmreg_lock, flags);
> +
> + memset(hwtstamps, 0, sizeof(*hwtstamps));
> + hwtstamps->hwtstamp = ns_to_ktime(ns);
> +}
^ permalink raw reply
* Re: [PATCH RFC] virtio_net: fix refill related races
From: Tejun Heo @ 2011-12-14 23:54 UTC (permalink / raw)
To: Rusty Russell
Cc: Amit Shah, netdev, virtualization, linux-kernel,
Michael S. Tsirkin
In-Reply-To: <87iplltd0g.fsf@rustcorp.com.au>
Hello, Rusty.
On Tue, Dec 13, 2011 at 01:05:11PM +1030, Rusty Russell wrote:
> Both places where we call:
>
> cancel_delayed_work_sync(&vi->refill);
>
> Do not actually guarantee that vi->refill isn't running, because it
> can requeue itself. A 'bool no_more_refill' field seems like the
> simplest fix for this, but I don't think it's sufficient.
>
> Tejun, is this correct? What's the correct way to synchronously stop a
> delayed_work which can "schedule_delayed_work(&vi->refill, HZ/2);" on
> itself?
cancel_delayed_work_sync() itself should be good enough. It first
steals the pending state and then waits for it to finish if in-flight.
Queueing itself afterwards becomes noop.
Thanks.
--
tejun
^ permalink raw reply
* Fwd: Weird linux kernel behavior - ARP - V2.6.16
From: Linus Torvalds @ 2011-12-14 23:57 UTC (permalink / raw)
To: David Miller, Network Development
In-Reply-To: <CAGeZV=TeKwzhpxsEV_rNa0=R-RYZfy6qi0iLoZ5Y4tSA8Ti5qA@mail.gmail.com>
Sent to some wrong people. Is anybody interested in this particular
misconfiguration? Is it intentional/wanted, or just a "don't do that
then"?
Linus
---------- Forwarded message ----------
From: Isaac Theogaraj <isaactheogaraj@gmail.com>
Date: Wed, Dec 14, 2011 at 1:59 AM
Subject: Weird linux kernel behavior - ARP - V2.6.16
To: torvalds@osdl.org
Cc: mtosatti@redhat.com, alan@lxorguk.ukuu.org.uk, tao@acc.umu.se
Dear Kernel experts,
I just encountered a kernel behavior wherein if the default gateway is
set as an interface IP itself,
kernel starts ARPing for every internet address.
Would like to what is the intention behind this behavior?
Of course this is an inadvertent configuration(wrong config. too), but
when kernel ARPs for
all internet addresses, that bloats up network tables in the
routing/bridging devices.
Logically speaking, if I say "My default gateway is me", then it's
like saying that I have all routes
and ARP resolutions. If I don't have a connected network for a
destination, I drop it.
Can you please let me know, why is the behavior set as "ARPing for
every internet address" when
"Default gateway is me"?
thanks in advance,
Isaac.
^ permalink raw reply
* Re: Fwd: Weird linux kernel behavior - ARP - V2.6.16
From: Rick Jones @ 2011-12-15 0:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Miller, Network Development
In-Reply-To: <CA+55aFzZHMd=pCUum3dr+Lz+i1KJfooqNT2fi8Fumq3c8BexkA@mail.gmail.com>
On 12/14/2011 03:57 PM, Linus Torvalds wrote:
> Sent to some wrong people. Is anybody interested in this particular
> misconfiguration? Is it intentional/wanted, or just a "don't do that
> then"?
Configuring one's own IP address as the gateway is how one can use/rely
on "Proxy ARP" whereby the router(s) on your subnet act as proxies for
destinations beyond them by responding to the ARP requests one's system
sends for them. http://en.wikipedia.org/wiki/Proxy_ARP Goes back a
very long way to days before the current ubiquity of network auto
configuration for things like default gateways. (As implied by the
rather low RFC numbers and date on the Stevens book referenced by the
wikipedia entry). The aging of the ARP cache entries enabled a form of
protocol free (relative to the end system) gateway failover - assuming
the gateways/routers on the subnet were able to decide among themselves
who would respond for what, when one of them failed, the aging of the
ARP cache entry and subsequent validation by the end systems would
pick-up the non-failed router's/gateway's MAC address. Happiness and
Joy ensues.
So, it would be normal for such a system to try to ARP for any IP
address it was trying to reach.
It would not be normal for such a system to spontaneously decide to try
to ARP for IPs it was not trying to reach.
Which of those two situations was taking place wasn't entirely clear
from the forwarded message.
rick jones
>
> Linus
>
>
> ---------- Forwarded message ----------
> From: Isaac Theogaraj<isaactheogaraj@gmail.com>
> Date: Wed, Dec 14, 2011 at 1:59 AM
> Subject: Weird linux kernel behavior - ARP - V2.6.16
> To: torvalds@osdl.org
> Cc: mtosatti@redhat.com, alan@lxorguk.ukuu.org.uk, tao@acc.umu.se
>
>
> Dear Kernel experts,
> I just encountered a kernel behavior wherein if the default gateway
> is set as an interface IP itself, kernel starts ARPing for every
> internet address.
> Would like to what is the intention behind this behavior?
>
> Of course this is an inadvertent configuration(wrong config. too),
> but when kernel ARPs for all internet addresses, that bloats up
> network tables in the routing/bridging devices.
>
> Logically speaking, if I say "My default gateway is me", then it's
> like saying that I have all routes and ARP resolutions. If I don't
> have a connected network for a destination, I drop it.
>
> Can you please let me know, why is the behavior set as "ARPing for
> every internet address" when "Default gateway is me"?
> thanks in advance,
> Isaac.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: do not pass vlan pkts to real dev pkt handler also
From: Vasu Dev @ 2011-12-14 23:55 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jiri Pirko, Vasu Dev, netdev, devel, eric.dumazet
In-Reply-To: <4EE8FE86.90009@gmail.com>
On Wed, 2011-12-14 at 20:52 +0100, Nicolas de Pesloüan wrote:
> If a protocol handler is registered on a particular device (instead of
> NULL), then the handler will
> receive whatever is received on this device. This is true for bridge,
> for bonding and probably for
> all other "stackable" devices. I don't see any reason to handle it in
> a different way for vlan.
>
Yeah okay to have orig_dev pkt handler see its all vlan frames though we
didn't have that way until recent change but seems reasonable to have
this way now. So I'll fix fcoe by allowing frames matching to its own
device and that will exclude vlan frames on its orig_dev pkt handler.
However now each stacked vlan tag iteration would result in passing up
frame to its orig_dev pkt handler but don't know if that affects other
and anyway fcoe would be okay with that as well.
Thanks
Vasu
^ permalink raw reply
* RE: [PATCH] libcxgbi: do not print a message when memory allocation fails
From: Karen Xie @ 2011-12-15 0:52 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo, linux-scsi
Cc: netdev, michaelc, davem, JBottomley, linux-kernel
In-Reply-To: <1323877583-6844-1-git-send-email-cascardo@linux.vnet.ibm.com>
The patch looks fine to me.
Thanks,
Karen
-----Original Message-----
From: Thadeu Lima de Souza Cascardo [mailto:cascardo@linux.vnet.ibm.com]
Sent: Wednesday, December 14, 2011 7:46 AM
To: linux-scsi@vger.kernel.org
Cc: netdev@vger.kernel.org; Karen Xie; michaelc@cs.wisc.edu;
davem@davemloft.net; JBottomley@parallels.com;
linux-kernel@vger.kernel.org; Thadeu Lima de Souza Cascardo
Subject: [PATCH] libcxgbi: do not print a message when memory allocation
fails
In alloc_pdu, libcxgbi tries to allocate a skb with GFP_ATOMIC, which
may potentially fail. When it happens, the current code prints a warning
message.
When the system is under IO stress, this failure may happen lots of
times and it usually scares users.
Instead of printing the warning message, the code now increases the
tx_dropped statistics for the ethernet interface wich is doing the iscsi
task.
Signed-off-by: Thadeu Lima de Souza Cascardo
<cascardo@linux.vnet.ibm.com>
---
drivers/scsi/cxgbi/libcxgbi.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/cxgbi/libcxgbi.c
b/drivers/scsi/cxgbi/libcxgbi.c
index c10f74a..3422bc2 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -1862,8 +1862,9 @@ int cxgbi_conn_alloc_pdu(struct iscsi_task *task,
u8 opcode)
tdata->skb = alloc_skb(cdev->skb_tx_rsvd + headroom,
GFP_ATOMIC);
if (!tdata->skb) {
- pr_warn("alloc skb %u+%u, opcode 0x%x failed.\n",
- cdev->skb_tx_rsvd, headroom, opcode);
+ struct cxgbi_sock *csk = cconn->cep->csk;
+ struct net_device *ndev = cdev->ports[csk->port_id];
+ ndev->stats.tx_dropped++;
return -ENOMEM;
}
--
1.7.4.4
^ permalink raw reply related
* Re: twice past the taps, thence out to net?
From: Benjamin Poirier @ 2011-12-15 0:58 UTC (permalink / raw)
To: Rick Jones; +Cc: tcpdump-workers, netdev
In-Reply-To: <4EE8F884.1010304@hp.com>
On 11/12/14 11:27, Rick Jones wrote:
>
> Where in the Linux stack does the tap used by libpcap 1.1.1 reside?
>
On transmission it's before tso/gso, via dev_queue_xmit_nit(). Taps are
registered in the ptype_all list.
-Benjamin
^ permalink raw reply
* winner
From: Microsoft @ 2011-12-14 13:45 UTC (permalink / raw)
You have won 500.000 GBP
send your phone number
and address
^ permalink raw reply
* Re: [net-next RFC PATCH 0/5] Series short description
From: Ben Hutchings @ 2011-12-15 1:36 UTC (permalink / raw)
To: Rusty Russell; +Cc: krkumar2, kvm, mst, netdev, virtualization, levinsasha928
In-Reply-To: <87r50efgza.fsf@rustcorp.com.au>
On Fri, 2011-12-09 at 16:01 +1030, Rusty Russell wrote:
> On Wed, 7 Dec 2011 17:02:04 +0000, Ben Hutchings <bhutchings@solarflare.com> wrote:
> > Solarflare controllers (sfc driver) have 8192 perfect filters for
> > TCP/IPv4 and UDP/IPv4 which can be used for flow steering. (The filters
> > are organised as a hash table, but matched based on 5-tuples.) I
> > implemented the 'accelerated RFS' interface in this driver.
> >
> > I believe the Intel 82599 controllers (ixgbe driver) have both
> > hash-based and perfect filter modes and the driver can be configured to
> > use one or the other. The driver has its own independent mechanism for
> > steering RX and TX flows which predates RFS; I don't know whether it
> > uses hash-based or perfect filters.
>
> Thanks for this summary (and Jason, too). I've fallen a long way behind
> NIC state-of-the-art.
>
> > Most multi-queue controllers could support a kind of hash-based
> > filtering for TCP/IP by adjusting the RSS indirection table. However,
> > this table is usually quite small (64-256 entries). This means that
> > hash collisions will be quite common and this can result in reordering.
> > The same applies to the small table Jason has proposed for virtio-net.
>
> But this happens on real hardware today. Better that real hardware is
> nice, but is it overkill?
What do you mean, it happens on real hardware today? So far as I know,
the only cases where we have dynamic adjustment of flow steering are in
ixgbe (big table of hash filters, I think) and sfc (perfect filters).
I don't think that anyone's currently doing flow steering with the RSS
indirection table. (At least, not on Linux. I think that Microsoft was
intending to do so on Windows, but I don't know whether they ever did.)
> And can't you reorder even with perfect matching, since prior packets
> will be on the old queue and more recent ones on the new queue? Does it
> discard or requeue old ones? Or am I missing a trick?
Yes, that is possible. RFS is careful to avoid such reordering by only
changing the steering of a flow when none of its packets can be in a
software receive queue. It is not generally possible to do the same for
hardware receive queues. However, when the first condition is met it is
likely that there won't be a whole lot of packets for that flow in the
hardware receive queue either. (But if there are, then I think as a
side-effect of commit 09994d1 RFS will repeatedly ask the driver to
steer the flow. Which isn't ideal.)
Ben.
--
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
* Re: Latency guarantees in HFSC rt service curves
From: Michal Soltys @ 2011-12-15 1:48 UTC (permalink / raw)
To: John A. Sullivan III; +Cc: netdev
In-Reply-To: <1323839798.8451.172.camel@denise.theartistscloset.com>
On 11-12-14 06:16, John A. Sullivan III wrote:
> I think I understand the technology (although I confess I did not take
> the time to fully digest how the curves are updated) but I'm grappling
> more with the practical application and I may be making a false
> assumption here.
Hmm, imho you can't really skip that part - or part about "why split RT
into eligible/deadline" to see the mechanics behind RT curves.
>
> Once again, with my practical, "how do I use this" hat on, my
> instinctive thought is that I would ensure that the sum of the rt m2
> curves do not exceed ul, well, not ul literally as rt disregards ul
> but, more accurately, circuit capacity so that my circuit is not
> oversubscribed and my guarantees are sustainable.
> But, since m1 on a concave curve is a momentary "super charge", I
> don't need to worry about oversubscribing since the rate is not
> sustained.
It's just a slope, from which you derive the time(s) used in deciding
"what to send next":
> Thus, if all the traffic were to be backlogged at m1 rates, we would
> overrun the circuit.
Curves don't really change that in any way.
If you did the above for m1 (or m2) for RT curves, the eligiblity would
lose the point (leafs would always be eligible), and the whole thing
would kind-of degenerate into more complex version of LS. There's a
reason why BSDs won't even let you define RT curves that sum at any
point to more than 80% (aside keeping LS useful, perhaps also related to
thier timer resolution [years ago]). Unless they changed it in recent
versions - I didn't really have any modern BSD under my hands for a
while.
> and the sum of their m1 curves > circuit capacity because, operating
> under my false assumption, this is only for that temporary boost. If
> all five classes receive their first packet at the identical moment,
> we will fail to meet the guarantees.
I'd say more aggressive eliglibility and earlier deadline - than any
boost. Which will briefly (if enough leafs are backlogged) turn whole
carefully designed RT mechanics into dimensionless LS-like thingy. So -
while that is possible - why do it ? Setup RT that fits the achievable
speed, and leave the excess bandwidth to LS.
Whole RT design - with eligible/deadline split - is to allow convex
curves to send "earlier", pushing the deadlines to the "right" - which
in turn allows newly backlogged class to have brief priority. But it all
remains under interface limit and over-time fulfills guarantees (even if
locally they are violated).
> I realize I am babbling in my own context so let me state in another
> way in case I'm not being clear. My concern was that, if the four
> classes are continuously backlogged and the fifth class with a concave
> rt service curve constantly goes idle and then immediately receives a
> packet, it will always be transmitting at the m1 rate and thus exceed
> the capacity of the circuit (since the sum of the five m2 curves =
> capacity and the m1 of the fifth class is greater than the m2 of the
> fifth class).
Actually it won't. See what I wrote about the eligible/deadline above.
The 4 classes (suppose they are under convex RT) will be eligible
earlier than they would normally be (and send more). When the 5th class
becomes active with its steeper m1, it literally "has a green light" to
send whenever it's eligible, as the deadlines of the 4 classes are
further to the right. If all classes remain backlogged from now on, it
all evens out properly. If the 5th goes idle, other classes will
"buffer up" again (from a lack of better term).
> So now I'll put my practical hat back on where practice will violate
> theory but with no practical deleterious effect except in the most
> extreme cases. I propose that, from a practical, system administrator
> perspective, it is feasible and probably ideal to define rt service
> curves so that the sum of all m2 curves<= circuit
Going above would really make LS pointless, and turn RT into LS-like
thing (see above).
> curves should be specified to meet latency requirements REGARDLESS OF
> EXCEEDING CIRCUIT CAPACITY.
Again (see above) - that will not get you anywhere. m1 or m2 (look at
the curve as a whole, not just its parts) - it just makes RT lose its
properties and actual meaning behind numbers. Briefly, but still.
I can think of scenarios where such setups would work fine (aside if it
would be really needed), but let's leave that for different occasion :)
>>
>> If anything briefly stops being backlogged, it will get bonus on next
>> backlog period
> I am assuming this assumes a concave curve and has to do with the
> recalculation of the curve and that this would not be true if m1=m2?
yes
ps.
Going through other mails will take me far more time I think.
^ permalink raw reply
* Re: twice past the taps, thence out to net?
From: Vijay Subramanian @ 2011-12-15 2:12 UTC (permalink / raw)
To: Rick Jones; +Cc: tcpdump-workers, netdev
In-Reply-To: <4EE8F884.1010304@hp.com>
On 14 December 2011 11:27, Rick Jones <rick.jones2@hp.com> wrote:
> While looking at "something else" with tcpdump/tcptrace, tcptrace emitted
> lots of notices about hardware duplicated packets being detected (same TCP
> sequence number and IP datagram ID). Sure enough, if I go into the tcpdump
> trace (taken on the sender) I can find instances of what it was talking
> about, separated in time by rather less than I would expect to be the RTO,
> and often as not with few if any intervening arriving ACKs to trigger
> anything like fast retransmit. And besides, those would have a different IP
> datagram ID no?
>
> I did manage to reproduce the issue with plain netperf tcp_stream tests. I
> had one sending system with 30 concurrent netperf tcp_stream tests to 30
> other receiving systems. There are "hardware duplicates" in the sending
> trace, but no duplicate segments (that I can find thus far) in the two
> receiver side traces I took. Of course that doesn't mean "conclusively"
> there were two actual sends but it suggests there werent.
>
> While I work through the "obtain permission" path to post the packet traces
> (don't ask...) I thought I would ask if anyone else has seen something
> similar.
>
> In this case, all the systems are running a 2.6.38-8 Ubuntu kernel (the same
> sorts of issues which delay my just putting the traces up on netperf.org
> preclude a later kernel, and I've no other test systems :( ), with Intel
> 82576 interfaces being driven by:
>
> $ sudo ethtool -i eth0
> driver: igb
> version: 2.1.0-k2
> firmware-version: 1.8-2
> bus-info: 0000:05:00.0
>
> All the systems were connected to the same switch.
>
Rick,
This may be of help.
http://www.tcptrace.org/faq_ans.html#FAQ%2021
Regards,
Vijay Subramanian
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the wireless tree
From: Stephen Rothwell @ 2011-12-15 2:53 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Johannes Berg, John W. Linville
[-- Attachment #1: Type: text/plain, Size: 460 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/wireless/iwlwifi/iwl-agn.c between commit 81670a491849
("iwlwifi: tx_sync only on PAN context") from the wireless tree and
commits from the net-next tree.
I used the version of this file from the wireless-next tree (where this
conflict has been resolved).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the wireless tree
From: Stephen Rothwell @ 2011-12-15 3:16 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Johannes Berg, John W. Linville
In-Reply-To: <20111215135330.94caf28045fd307801fa5ef9@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 741 bytes --]
Hi all,
On Thu, 15 Dec 2011 13:53:30 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/wireless/iwlwifi/iwl-agn.c between commit 81670a491849
> ("iwlwifi: tx_sync only on PAN context") from the wireless tree and
> commits from the net-next tree.
>
> I used the version of this file from the wireless-next tree (where this
> conflict has been resolved).
Unfortunately, it was the wrong resolution for the net-next tree due to
other changes in this file :-(
So instead, I just used the version of this file from the net-next tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 14/15] module_param: make bool parameters really bool (net & drivers/net)
From: Rusty Russell @ 2011-12-15 3:21 UTC (permalink / raw)
To: lkml - Kernel Mailing List; +Cc: Pawel Moll, David S. Miller, netdev
module_param(bool) used to counter-intuitively take an int. In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.
It's time to remove the int/unsigned int option. For this version
it'll simply give a warning, but it'll break next kernel version.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
drivers/net/caif/caif_serial.c | 6 +++---
drivers/net/caif/caif_spi.c | 2 +-
drivers/net/can/vcan.c | 2 +-
drivers/net/ethernet/amd/amd8111e.h | 4 ++--
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 2 +-
drivers/net/ethernet/dlink/de600.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/fw.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/main.c | 2 +-
drivers/net/ethernet/via/via-rhine.c | 3 ++-
drivers/net/irda/donauboe.c | 2 +-
drivers/net/irda/smsc-ircc2.c | 2 +-
drivers/net/usb/pegasus.c | 4 ++--
drivers/net/usb/smsc75xx.c | 2 +-
drivers/net/usb/smsc95xx.c | 2 +-
drivers/net/virtio_net.c | 2 +-
drivers/net/wan/sbni.c | 2 +-
drivers/net/wan/sealevel.c | 2 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
drivers/net/wireless/ath/ath5k/base.c | 6 +++---
drivers/net/wireless/ath/carl9170/main.c | 2 +-
drivers/net/wireless/iwmc3200wifi/main.c | 4 ++--
drivers/net/wireless/mwl8k.c | 2 +-
drivers/net/wireless/orinoco/main.c | 2 +-
drivers/net/wireless/p54/main.c | 2 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 2 +-
drivers/net/wireless/rt2x00/rt2800pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 2 +-
drivers/net/wireless/rt2x00/rt61pci.c | 2 +-
drivers/net/wireless/rt2x00/rt73usb.c | 2 +-
drivers/net/wireless/rtlwifi/wifi.h | 2 +-
include/net/bluetooth/l2cap.h | 2 +-
include/net/sctp/structs.h | 2 +-
net/bluetooth/bnep/core.c | 4 ++--
net/bluetooth/hci_event.c | 2 +-
net/bluetooth/hci_sock.c | 2 +-
net/bluetooth/l2cap_core.c | 2 +-
net/bluetooth/rfcomm/core.c | 4 ++--
net/bluetooth/sco.c | 2 +-
net/dccp/ccids/ccid2.c | 4 ++--
net/dccp/ccids/ccid3.c | 2 +-
net/dccp/ccids/lib/tfrc.c | 2 +-
net/dccp/ccids/lib/tfrc.h | 2 +-
net/dccp/dccp.h | 2 +-
net/dccp/proto.c | 2 +-
net/ipv4/netfilter/ipt_ULOG.c | 2 +-
net/ipv4/netfilter/iptable_filter.c | 2 +-
net/ipv6/netfilter/ip6table_filter.c | 2 +-
net/irda/irlan/irlan_common.c | 2 +-
net/netfilter/nf_conntrack_acct.c | 2 +-
net/netfilter/nf_conntrack_ftp.c | 2 +-
net/netfilter/nf_conntrack_h323_main.c | 2 +-
net/netfilter/nf_conntrack_timestamp.c | 2 +-
52 files changed, 63 insertions(+), 62 deletions(-)
diff --git a/drivers/net/caif/caif_serial.c b/drivers/net/caif/caif_serial.c
--- a/drivers/net/caif/caif_serial.c
+++ b/drivers/net/caif/caif_serial.c
@@ -38,15 +38,15 @@ MODULE_ALIAS_LDISC(N_CAIF);
/*This list is protected by the rtnl lock. */
static LIST_HEAD(ser_list);
-static int ser_loop;
+static bool ser_loop;
module_param(ser_loop, bool, S_IRUGO);
MODULE_PARM_DESC(ser_loop, "Run in simulated loopback mode.");
-static int ser_use_stx = 1;
+static bool ser_use_stx = 1;
module_param(ser_use_stx, bool, S_IRUGO);
MODULE_PARM_DESC(ser_use_stx, "STX enabled or not.");
-static int ser_use_fcs = 1;
+static bool ser_use_fcs = 1;
module_param(ser_use_fcs, bool, S_IRUGO);
MODULE_PARM_DESC(ser_use_fcs, "FCS enabled or not.");
diff --git a/drivers/net/caif/caif_spi.c b/drivers/net/caif/caif_spi.c
--- a/drivers/net/caif/caif_spi.c
+++ b/drivers/net/caif/caif_spi.c
@@ -35,7 +35,7 @@ MODULE_DESCRIPTION("CAIF SPI driver");
/* Returns the number of padding bytes for alignment. */
#define PAD_POW2(x, pow) ((((x)&((pow)-1))==0) ? 0 : (((pow)-((x)&((pow)-1)))))
-static int spi_loop;
+static bool spi_loop;
module_param(spi_loop, bool, S_IRUGO);
MODULE_PARM_DESC(spi_loop, "SPI running in loopback mode.");
diff --git a/drivers/net/can/vcan.c b/drivers/net/can/vcan.c
--- a/drivers/net/can/vcan.c
+++ b/drivers/net/can/vcan.c
@@ -63,7 +63,7 @@ MODULE_AUTHOR("Urs Thuermann <urs.thuerm
* See Documentation/networking/can.txt for details.
*/
-static int echo; /* echo testing. Default: 0 (Off) */
+static bool echo; /* echo testing. Default: 0 (Off) */
module_param(echo, bool, S_IRUGO);
MODULE_PARM_DESC(echo, "Echo sent frames (for testing). Default: 0 (Off)");
diff --git a/drivers/net/ethernet/amd/amd8111e.h b/drivers/net/ethernet/amd/amd8111e.h
--- a/drivers/net/ethernet/amd/amd8111e.h
+++ b/drivers/net/ethernet/amd/amd8111e.h
@@ -808,8 +808,8 @@ typedef enum {
static int card_idx;
static int speed_duplex[MAX_UNITS] = { 0, };
-static int coalesce[MAX_UNITS] = {1,1,1,1,1,1,1,1};
-static int dynamic_ipg[MAX_UNITS] = {0,0,0,0,0,0,0,0};
+static bool coalesce[MAX_UNITS] = {1,1,1,1,1,1,1,1};
+static bool dynamic_ipg[MAX_UNITS] = {0,0,0,0,0,0,0,0};
static unsigned int chip_version;
#endif /* _AMD8111E_H */
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -243,7 +243,7 @@ module_param_array(intr_cnt, uint, NULL,
MODULE_PARM_DESC(intr_cnt,
"thresholds 1..3 for queue interrupt packet counters");
-static int vf_acls;
+static bool vf_acls;
#ifdef CONFIG_PCI_IOV
module_param(vf_acls, bool, 0644);
diff --git a/drivers/net/ethernet/dlink/de600.c b/drivers/net/ethernet/dlink/de600.c
--- a/drivers/net/ethernet/dlink/de600.c
+++ b/drivers/net/ethernet/dlink/de600.c
@@ -59,7 +59,7 @@ static const char version[] = "de600.c:
#include "de600.h"
-static unsigned int check_lost = 1;
+static bool check_lost = 1;
module_param(check_lost, bool, 0);
MODULE_PARM_DESC(check_lost, "If set then check for unplugged de600");
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c b/drivers/net/ethernet/mellanox/mlx4/fw.c
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -48,7 +48,7 @@ enum {
extern void __buggy_use_of_MLX4_GET(void);
extern void __buggy_use_of_MLX4_PUT(void);
-static int enable_qos;
+static bool enable_qos;
module_param(enable_qos, bool, 0444);
MODULE_PARM_DESC(enable_qos, "Enable Quality of Service support in the HCA (default: off)");
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -99,7 +99,7 @@ MODULE_PARM_DESC(log_num_vlan, "Log2 max
/* Log2 max number of VLANs per ETH port (0-7) */
#define MLX4_LOG_NUM_VLANS 7
-static int use_prio;
+static bool use_prio;
module_param_named(use_prio, use_prio, bool, 0444);
MODULE_PARM_DESC(use_prio, "Enable steering by VLAN priority on ETH ports "
"(0/1, default 0)");
diff --git a/drivers/net/ethernet/via/via-rhine.c b/drivers/net/ethernet/via/via-rhine.c
--- a/drivers/net/ethernet/via/via-rhine.c
+++ b/drivers/net/ethernet/via/via-rhine.c
@@ -35,6 +35,7 @@
#define DRV_VERSION "1.5.0"
#define DRV_RELDATE "2010-10-09"
+#include <linux/types.h>
/* A few user-configurable values.
These may be modified when a driver module is loaded. */
@@ -55,7 +56,7 @@ static int rx_copybreak;
/* Work-around for broken BIOSes: they are unable to get the chip back out of
power state D3 so PXE booting fails. bootparam(7): via-rhine.avoid_D3=1 */
-static int avoid_D3;
+static bool avoid_D3;
/*
* In case you are looking for 'options[]' or 'full_duplex[]', they
diff --git a/drivers/net/irda/donauboe.c b/drivers/net/irda/donauboe.c
--- a/drivers/net/irda/donauboe.c
+++ b/drivers/net/irda/donauboe.c
@@ -197,7 +197,7 @@ static char *driver_name = DRIVER_NAME;
static int max_baud = 4000000;
#ifdef USE_PROBE
-static int do_probe = 0;
+static bool do_probe = 0;
#endif
diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
--- a/drivers/net/irda/smsc-ircc2.c
+++ b/drivers/net/irda/smsc-ircc2.c
@@ -79,7 +79,7 @@ MODULE_AUTHOR("Daniele Peri <peri@csai.u
MODULE_DESCRIPTION("SMC IrCC SIR/FIR controller driver");
MODULE_LICENSE("GPL");
-static int smsc_nopnp = 1;
+static bool smsc_nopnp = 1;
module_param_named(nopnp, smsc_nopnp, bool, 0);
MODULE_PARM_DESC(nopnp, "Do not use PNP to detect controller settings, defaults to true");
diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
--- a/drivers/net/usb/pegasus.c
+++ b/drivers/net/usb/pegasus.c
@@ -55,8 +55,8 @@ static const char driver_name[] = "pegas
#define BMSR_MEDIA (BMSR_10HALF | BMSR_10FULL | BMSR_100HALF | \
BMSR_100FULL | BMSR_ANEGCAPABLE)
-static int loopback;
-static int mii_mode;
+static bool loopback;
+static bool mii_mode;
static char *devid;
static struct usb_eth_dev usb_dev_id[] = {
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -76,7 +76,7 @@ struct usb_context {
struct usbnet *dev;
};
-static int turbo_mode = true;
+static bool turbo_mode = true;
module_param(turbo_mode, bool, 0644);
MODULE_PARM_DESC(turbo_mode, "Enable multiple frames per Rx transaction");
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -59,7 +59,7 @@ struct usb_context {
struct usbnet *dev;
};
-static int turbo_mode = true;
+static bool turbo_mode = true;
module_param(turbo_mode, bool, 0644);
MODULE_PARM_DESC(turbo_mode, "Enable multiple frames per Rx transaction");
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -30,7 +30,7 @@
static int napi_weight = 128;
module_param(napi_weight, int, 0444);
-static int csum = 1, gso = 1;
+static bool csum = 1, gso = 1;
module_param(csum, bool, 0444);
module_param(gso, bool, 0444);
diff --git a/drivers/net/wan/sbni.c b/drivers/net/wan/sbni.c
--- a/drivers/net/wan/sbni.c
+++ b/drivers/net/wan/sbni.c
@@ -155,7 +155,7 @@ static int emancipate( struct net_devic
static const char version[] =
"Granch SBNI12 driver ver 5.0.1 Jun 22 2001 Denis I.Timofeev.\n";
-static int skip_pci_probe __initdata = 0;
+static bool skip_pci_probe __initdata = 0;
static int scandone __initdata = 0;
static int num __initdata = 0;
diff --git a/drivers/net/wan/sealevel.c b/drivers/net/wan/sealevel.c
--- a/drivers/net/wan/sealevel.c
+++ b/drivers/net/wan/sealevel.c
@@ -362,7 +362,7 @@ static int io=0x238;
static int txdma=1;
static int rxdma=3;
static int irq=5;
-static int slow=0;
+static bool slow=0;
module_param(io, int, 0);
MODULE_PARM_DESC(io, "The I/O base of the Sealevel card");
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -747,7 +747,7 @@ struct ath5k_athchan_2ghz {
*/
#define AR5K_KEYCACHE_SIZE 8
-extern int ath5k_modparam_nohwcrypt;
+extern bool ath5k_modparam_nohwcrypt;
/***********************\
HW RELATED DEFINITIONS
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -68,15 +68,15 @@
#define CREATE_TRACE_POINTS
#include "trace.h"
-int ath5k_modparam_nohwcrypt;
+bool ath5k_modparam_nohwcrypt;
module_param_named(nohwcrypt, ath5k_modparam_nohwcrypt, bool, S_IRUGO);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
-static int modparam_all_channels;
+static bool modparam_all_channels;
module_param_named(all_channels, modparam_all_channels, bool, S_IRUGO);
MODULE_PARM_DESC(all_channels, "Expose all channels the device can use.");
-static int modparam_fastchanswitch;
+static bool modparam_fastchanswitch;
module_param_named(fastchanswitch, modparam_fastchanswitch, bool, S_IRUGO);
MODULE_PARM_DESC(fastchanswitch, "Enable fast channel switching for AR2413/AR5413 radios.");
diff --git a/drivers/net/wireless/ath/carl9170/main.c b/drivers/net/wireless/ath/carl9170/main.c
--- a/drivers/net/wireless/ath/carl9170/main.c
+++ b/drivers/net/wireless/ath/carl9170/main.c
@@ -48,7 +48,7 @@
#include "carl9170.h"
#include "cmd.h"
-static int modparam_nohwcrypt;
+static bool modparam_nohwcrypt;
module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware crypto offload.");
diff --git a/drivers/net/wireless/iwmc3200wifi/main.c b/drivers/net/wireless/iwmc3200wifi/main.c
--- a/drivers/net/wireless/iwmc3200wifi/main.c
+++ b/drivers/net/wireless/iwmc3200wifi/main.c
@@ -91,11 +91,11 @@ static struct iwm_conf def_iwm_conf = {
.mac_addr = {0x00, 0x02, 0xb3, 0x01, 0x02, 0x03},
};
-static int modparam_reset;
+static bool modparam_reset;
module_param_named(reset, modparam_reset, bool, 0644);
MODULE_PARM_DESC(reset, "reset on firmware errors (default 0 [not reset])");
-static int modparam_wimax_enable = 1;
+static bool modparam_wimax_enable = 1;
module_param_named(wimax_enable, modparam_wimax_enable, bool, 0644);
MODULE_PARM_DESC(wimax_enable, "Enable wimax core (default 1 [wimax enabled])");
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -31,7 +31,7 @@
#define MWL8K_VERSION "0.12"
/* Module parameters */
-static unsigned ap_mode_default;
+static bool ap_mode_default;
module_param(ap_mode_default, bool, 0);
MODULE_PARM_DESC(ap_mode_default,
"Set to 1 to make ap mode the default instead of sta mode");
diff --git a/drivers/net/wireless/orinoco/main.c b/drivers/net/wireless/orinoco/main.c
--- a/drivers/net/wireless/orinoco/main.c
+++ b/drivers/net/wireless/orinoco/main.c
@@ -121,7 +121,7 @@ module_param(orinoco_debug, int, 0644);
MODULE_PARM_DESC(orinoco_debug, "Debug level");
#endif
-static int suppress_linkstatus; /* = 0 */
+static bool suppress_linkstatus; /* = 0 */
module_param(suppress_linkstatus, bool, 0644);
MODULE_PARM_DESC(suppress_linkstatus, "Don't log link status changes");
diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
--- a/drivers/net/wireless/p54/main.c
+++ b/drivers/net/wireless/p54/main.c
@@ -27,7 +27,7 @@
#include "p54.h"
#include "lmac.h"
-static int modparam_nohwcrypt;
+static bool modparam_nohwcrypt;
module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
MODULE_AUTHOR("Michael Wu <flamingice@sourmilk.net>");
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -39,7 +39,7 @@
/*
* Allow hardware encryption to be disabled.
*/
-static int modparam_nohwcrypt;
+static bool modparam_nohwcrypt;
module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -50,7 +50,7 @@
/*
* Allow hardware encryption to be disabled.
*/
-static int modparam_nohwcrypt = 0;
+static bool modparam_nohwcrypt = 0;
module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -45,7 +45,7 @@
/*
* Allow hardware encryption to be disabled.
*/
-static int modparam_nohwcrypt;
+static bool modparam_nohwcrypt;
module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -41,7 +41,7 @@
/*
* Allow hardware encryption to be disabled.
*/
-static int modparam_nohwcrypt = 0;
+static bool modparam_nohwcrypt = 0;
module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -40,7 +40,7 @@
/*
* Allow hardware encryption to be disabled.
*/
-static int modparam_nohwcrypt;
+static bool modparam_nohwcrypt;
module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
diff --git a/drivers/net/wireless/rtlwifi/wifi.h b/drivers/net/wireless/rtlwifi/wifi.h
--- a/drivers/net/wireless/rtlwifi/wifi.h
+++ b/drivers/net/wireless/rtlwifi/wifi.h
@@ -1485,7 +1485,7 @@ struct rtl_intf_ops {
struct rtl_mod_params {
/* default: 0 = using hardware encryption */
- int sw_crypto;
+ bool sw_crypto;
/* default: 0 = DBG_EMERG (0)*/
int debug;
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -492,7 +492,7 @@ static inline int l2cap_tx_window_full(s
#define __is_sframe(ctrl) ((ctrl) & L2CAP_CTRL_FRAME_TYPE)
#define __is_sar_start(ctrl) (((ctrl) & L2CAP_CTRL_SAR) == L2CAP_SDU_START)
-extern int disable_ertm;
+extern bool disable_ertm;
int l2cap_init_sockets(void);
void l2cap_cleanup_sockets(void);
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -235,7 +235,7 @@ extern struct sctp_globals {
/* Flag to indicate whether computing and verifying checksum
* is disabled. */
- int checksum_disable;
+ bool checksum_disable;
/* Threshold for rwnd update SACKS. Receive buffer shifted this many
* bits is an indicator of when to send and window update SACK.
diff --git a/net/bluetooth/bnep/core.c b/net/bluetooth/bnep/core.c
--- a/net/bluetooth/bnep/core.c
+++ b/net/bluetooth/bnep/core.c
@@ -56,8 +56,8 @@
#define VERSION "1.3"
-static int compress_src = 1;
-static int compress_dst = 1;
+static bool compress_src = 1;
+static bool compress_dst = 1;
static LIST_HEAD(bnep_session_list);
static DECLARE_RWSEM(bnep_session_sem);
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -45,7 +45,7 @@
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
-static int enable_le;
+static bool enable_le;
/* Handle HCI Event packets */
diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -49,7 +49,7 @@
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
-static int enable_mgmt;
+static bool enable_mgmt;
/* ----- HCI socket interface ----- */
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -56,7 +56,7 @@
#include <net/bluetooth/l2cap.h>
#include <net/bluetooth/smp.h>
-int disable_ertm;
+bool disable_ertm;
static u32 l2cap_feat_mask = L2CAP_FEAT_FIXED_CHAN;
static u8 l2cap_fixed_chan[8] = { 0x02, };
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -51,8 +51,8 @@
#define VERSION "1.11"
-static int disable_cfc;
-static int l2cap_ertm;
+static bool disable_cfc;
+static bool l2cap_ertm;
static int channel_mtu = -1;
static unsigned int l2cap_mtu = RFCOMM_MAX_L2CAP_MTU;
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -51,7 +51,7 @@
#include <net/bluetooth/hci_core.h>
#include <net/bluetooth/sco.h>
-static int disable_esco;
+static bool disable_esco;
static const struct proto_ops sco_sock_ops;
diff --git a/net/dccp/ccids/ccid2.c b/net/dccp/ccids/ccid2.c
--- a/net/dccp/ccids/ccid2.c
+++ b/net/dccp/ccids/ccid2.c
@@ -29,7 +29,7 @@
#ifdef CONFIG_IP_DCCP_CCID2_DEBUG
-static int ccid2_debug;
+static bool ccid2_debug;
#define ccid2_pr_debug(format, a...) DCCP_PR_DEBUG(ccid2_debug, format, ##a)
#else
#define ccid2_pr_debug(format, a...)
@@ -174,7 +174,7 @@ out:
/*
* Congestion window validation (RFC 2861).
*/
-static int ccid2_do_cwv = 1;
+static bool ccid2_do_cwv = 1;
module_param(ccid2_do_cwv, bool, 0644);
MODULE_PARM_DESC(ccid2_do_cwv, "Perform RFC2861 Congestion Window Validation");
diff --git a/net/dccp/ccids/ccid3.c b/net/dccp/ccids/ccid3.c
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -38,7 +38,7 @@
#include <asm/unaligned.h>
#ifdef CONFIG_IP_DCCP_CCID3_DEBUG
-static int ccid3_debug;
+static bool ccid3_debug;
#define ccid3_pr_debug(format, a...) DCCP_PR_DEBUG(ccid3_debug, format, ##a)
#else
#define ccid3_pr_debug(format, a...)
diff --git a/net/dccp/ccids/lib/tfrc.c b/net/dccp/ccids/lib/tfrc.c
--- a/net/dccp/ccids/lib/tfrc.c
+++ b/net/dccp/ccids/lib/tfrc.c
@@ -8,7 +8,7 @@
#include "tfrc.h"
#ifdef CONFIG_IP_DCCP_TFRC_DEBUG
-int tfrc_debug;
+bool tfrc_debug;
module_param(tfrc_debug, bool, 0644);
MODULE_PARM_DESC(tfrc_debug, "Enable TFRC debug messages");
#endif
diff --git a/net/dccp/ccids/lib/tfrc.h b/net/dccp/ccids/lib/tfrc.h
--- a/net/dccp/ccids/lib/tfrc.h
+++ b/net/dccp/ccids/lib/tfrc.h
@@ -21,7 +21,7 @@
#include "packet_history.h"
#ifdef CONFIG_IP_DCCP_TFRC_DEBUG
-extern int tfrc_debug;
+extern bool tfrc_debug;
#define tfrc_pr_debug(format, a...) DCCP_PR_DEBUG(tfrc_debug, format, ##a)
#else
#define tfrc_pr_debug(format, a...)
diff --git a/net/dccp/dccp.h b/net/dccp/dccp.h
--- a/net/dccp/dccp.h
+++ b/net/dccp/dccp.h
@@ -39,7 +39,7 @@
"%s: " fmt, __func__, ##a)
#ifdef CONFIG_IP_DCCP_DEBUG
-extern int dccp_debug;
+extern bool dccp_debug;
#define dccp_pr_debug(format, a...) DCCP_PR_DEBUG(dccp_debug, format, ##a)
#define dccp_pr_debug_cat(format, a...) DCCP_PRINTK(dccp_debug, format, ##a)
#define dccp_debug(fmt, a...) dccp_pr_debug_cat(KERN_DEBUG fmt, ##a)
diff --git a/net/dccp/proto.c b/net/dccp/proto.c
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -1099,7 +1099,7 @@ module_param(thash_entries, int, 0444);
MODULE_PARM_DESC(thash_entries, "Number of ehash buckets");
#ifdef CONFIG_IP_DCCP_DEBUG
-int dccp_debug;
+bool dccp_debug;
module_param(dccp_debug, bool, 0644);
MODULE_PARM_DESC(dccp_debug, "Enable debug messages");
diff --git a/net/ipv4/netfilter/ipt_ULOG.c b/net/ipv4/netfilter/ipt_ULOG.c
--- a/net/ipv4/netfilter/ipt_ULOG.c
+++ b/net/ipv4/netfilter/ipt_ULOG.c
@@ -65,7 +65,7 @@ static unsigned int flushtimeout = 10;
module_param(flushtimeout, uint, 0600);
MODULE_PARM_DESC(flushtimeout, "buffer flush timeout (hundredths of a second)");
-static int nflog = 1;
+static bool nflog = 1;
module_param(nflog, bool, 0400);
MODULE_PARM_DESC(nflog, "register as internal netfilter logging module");
diff --git a/net/ipv4/netfilter/iptable_filter.c b/net/ipv4/netfilter/iptable_filter.c
--- a/net/ipv4/netfilter/iptable_filter.c
+++ b/net/ipv4/netfilter/iptable_filter.c
@@ -52,7 +52,7 @@ iptable_filter_hook(unsigned int hook, s
static struct nf_hook_ops *filter_ops __read_mostly;
/* Default to forward because I got too much mail already. */
-static int forward = NF_ACCEPT;
+static bool forward = NF_ACCEPT;
module_param(forward, bool, 0000);
static int __net_init iptable_filter_net_init(struct net *net)
diff --git a/net/ipv6/netfilter/ip6table_filter.c b/net/ipv6/netfilter/ip6table_filter.c
--- a/net/ipv6/netfilter/ip6table_filter.c
+++ b/net/ipv6/netfilter/ip6table_filter.c
@@ -44,7 +44,7 @@ ip6table_filter_hook(unsigned int hook,
static struct nf_hook_ops *filter_ops __read_mostly;
/* Default to forward because I got too much mail already. */
-static int forward = NF_ACCEPT;
+static bool forward = NF_ACCEPT;
module_param(forward, bool, 0000);
static int __net_init ip6table_filter_net_init(struct net *net)
diff --git a/net/irda/irlan/irlan_common.c b/net/irda/irlan/irlan_common.c
--- a/net/irda/irlan/irlan_common.c
+++ b/net/irda/irlan/irlan_common.c
@@ -67,7 +67,7 @@ static void *ckey;
static void *skey;
/* Module parameters */
-static int eth; /* Use "eth" or "irlan" name for devices */
+static bool eth; /* Use "eth" or "irlan" name for devices */
static int access = ACCESS_PEER; /* PEER, DIRECT or HOSTED */
#ifdef CONFIG_PROC_FS
diff --git a/net/netfilter/nf_conntrack_acct.c b/net/netfilter/nf_conntrack_acct.c
--- a/net/netfilter/nf_conntrack_acct.c
+++ b/net/netfilter/nf_conntrack_acct.c
@@ -18,7 +18,7 @@
#include <net/netfilter/nf_conntrack_extend.h>
#include <net/netfilter/nf_conntrack_acct.h>
-static int nf_ct_acct __read_mostly;
+static bool nf_ct_acct __read_mostly;
module_param_named(acct, nf_ct_acct, bool, 0644);
MODULE_PARM_DESC(acct, "Enable connection tracking flow accounting.");
diff --git a/net/netfilter/nf_conntrack_ftp.c b/net/netfilter/nf_conntrack_ftp.c
--- a/net/netfilter/nf_conntrack_ftp.c
+++ b/net/netfilter/nf_conntrack_ftp.c
@@ -42,7 +42,7 @@ static u_int16_t ports[MAX_PORTS];
static unsigned int ports_c;
module_param_array(ports, ushort, &ports_c, 0400);
-static int loose;
+static bool loose;
module_param(loose, bool, 0600);
unsigned int (*nf_nat_ftp_hook)(struct sk_buff *skb,
diff --git a/net/netfilter/nf_conntrack_h323_main.c b/net/netfilter/nf_conntrack_h323_main.c
--- a/net/netfilter/nf_conntrack_h323_main.c
+++ b/net/netfilter/nf_conntrack_h323_main.c
@@ -42,7 +42,7 @@ static int gkrouted_only __read_mostly =
module_param(gkrouted_only, int, 0600);
MODULE_PARM_DESC(gkrouted_only, "only accept calls from gatekeeper");
-static int callforward_filter __read_mostly = 1;
+static bool callforward_filter __read_mostly = 1;
module_param(callforward_filter, bool, 0600);
MODULE_PARM_DESC(callforward_filter, "only create call forwarding expectations "
"if both endpoints are on different sides "
diff --git a/net/netfilter/nf_conntrack_timestamp.c b/net/netfilter/nf_conntrack_timestamp.c
--- a/net/netfilter/nf_conntrack_timestamp.c
+++ b/net/netfilter/nf_conntrack_timestamp.c
@@ -15,7 +15,7 @@
#include <net/netfilter/nf_conntrack_extend.h>
#include <net/netfilter/nf_conntrack_timestamp.h>
-static int nf_ct_tstamp __read_mostly;
+static bool nf_ct_tstamp __read_mostly;
module_param_named(tstamp, nf_ct_tstamp, bool, 0644);
MODULE_PARM_DESC(tstamp, "Enable connection tracking flow timestamping.");
^ permalink raw reply
* Re: [PATCH 14/15] module_param: make bool parameters really bool (net & drivers/net)
From: Joe Perches @ 2011-12-15 3:45 UTC (permalink / raw)
To: Rusty Russell
Cc: lkml - Kernel Mailing List, Pawel Moll, David S. Miller, netdev
In-Reply-To: <877h1ysenl.fsf@rustcorp.com.au>
On Thu, 2011-12-15 at 13:51 +1030, Rusty Russell wrote:
> module_param(bool) used to counter-intuitively take an int. In
> fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
> trick.
[]
> diff --git a/drivers/net/caif/caif_serial.c b/drivers/net/caif/caif_serial.c
[]
> @@ -38,15 +38,15 @@ MODULE_ALIAS_LDISC(N_CAIF);
[]
> -static int ser_use_stx = 1;
> +static bool ser_use_stx = 1;
Could you respin these please using bool foo = true/false instead?
^ permalink raw reply
* Re: [PATCH v9 0/9] Request for inclusion: per-cgroup tcp memory pressure controls
From: KAMEZAWA Hiroyuki @ 2011-12-15 5:40 UTC (permalink / raw)
To: Glauber Costa
Cc: davem, linux-kernel, paul, lizf, ebiederm, gthelen, netdev,
linux-mm, kirill, avagin, devel, eric.dumazet, cgroups
In-Reply-To: <1323676029-5890-1-git-send-email-glommer@parallels.com>
On Mon, 12 Dec 2011 11:47:00 +0400
Glauber Costa <glommer@parallels.com> wrote:
> Hi,
>
> This series fixes all the few comments raised in the last round,
> and seem to have acquired consensus from the memcg side.
>
> Dave, do you think it is acceptable now from the networking PoV?
> In case positive, would you prefer merging this trough your tree,
> or acking this so a cgroup maintainer can do it?
>
I met this bug at _1st_ run. Please enable _all_ debug options!.
>From this log, your mem_cgroup_sockets_init() is totally buggy because
tcp init routine will call percpu_alloc() under read_lock.
please fix. I'll turn off the config for today's linux-next.
Regards,
-Kame
==
Dec 15 14:47:15 bluextal kernel: [ 228.386054] BUG: sleeping function called from invalid context at k
ernel/mutex.c:271
Dec 15 14:47:15 bluextal kernel: [ 228.386286] in_atomic(): 1, irqs_disabled(): 0, pid: 2692, name: cg
create
Dec 15 14:47:15 bluextal kernel: [ 228.386438] 4 locks held by cgcreate/2692:
Dec 15 14:47:15 bluextal kernel: [ 228.386580] #0: (&sb->s_type->i_mutex_key#15/1){+.+.+.}, at: [<ff
ffffff8118717e>] kern_path_create+0x8e/0x150
Dec 15 14:47:15 bluextal kernel: [ 228.387238] #1: (cgroup_mutex){+.+.+.}, at: [<ffffffff810c2907>]
cgroup_mkdir+0x77/0x3f0
Dec 15 14:47:15 bluextal kernel: [ 228.387755] #2: (&sb->s_type->i_mutex_key#15/2){+.+.+.}, at: [<ff
ffffff810be168>] cgroup_create_file+0xc8/0xf0
Dec 15 14:47:15 bluextal kernel: [ 228.388401] #3: (proto_list_lock){++++.+}, at: [<ffffffff814e7fe4
>] mem_cgroup_sockets_init+0x24/0xf0
Dec 15 14:47:15 bluextal kernel: [ 228.388922] Pid: 2692, comm: cgcreate Not tainted 3.2.0-rc5-next-20
111214+ #34
Dec 15 14:47:15 bluextal kernel: [ 228.389154] Call Trace:
Dec 15 14:47:15 bluextal kernel: [ 228.389296] [<ffffffff81080f07>] __might_sleep+0x107/0x140
Dec 15 14:47:15 bluextal kernel: [ 228.389446] [<ffffffff815ce15f>] mutex_lock_nested+0x2f/0x50
Dec 15 14:47:15 bluextal kernel: [ 228.389597] [<ffffffff811354fd>] pcpu_alloc+0x4d/0xa20
Dec 15 14:47:15 bluextal kernel: [ 228.389745] [<ffffffff810a5759>] ? debug_check_no_locks_freed+0xa9/0x180
Dec 15 14:47:15 bluextal kernel: [ 228.389897] [<ffffffff810a5615>] ? trace_hardirqs_on_caller+0x105/0x190
Dec 15 14:47:15 bluextal kernel: [ 228.390057] [<ffffffff810a56ad>] ? trace_hardirqs_on+0xd/0x10
Dec 15 14:47:15 bluextal kernel: [ 228.390206] [<ffffffff810a3600>] ? lockdep_init_map+0x50/0x140
Dec 15 14:47:15 bluextal kernel: [ 228.390356] [<ffffffff81135f00>] __alloc_percpu+0x10/0x20
Dec 15 14:47:15 bluextal kernel: [ 228.390506] [<ffffffff812fda18>] __percpu_counter_init+0x58/0xc0
Dec 15 14:47:15 bluextal kernel: [ 228.390658] [<ffffffff8158fb26>] tcp_init_cgroup+0xd6/0x140
Dec 15 14:47:15 bluextal kernel: [ 228.390808] [<ffffffff814e8014>] mem_cgroup_sockets_init+0x54/0xf0
Dec 15 14:47:15 bluextal kernel: [ 228.390961] [<ffffffff8116b47b>] mem_cgroup_populate+0xab/0xc0
Dec 15 14:47:15 bluextal kernel: [ 228.391120] [<ffffffff810c053a>] cgroup_populate_dir+0x7a/0x110
Dec 15 14:47:15 bluextal kernel: [ 228.391271] [<ffffffff810c2b16>] cgroup_mkdir+0x286/0x3f0
Dec 15 14:47:15 bluextal kernel: [ 228.391420] [<ffffffff811836b4>] vfs_mkdir+0xa4/0xe0
Dec 15 14:47:15 bluextal kernel: [ 228.391566] [<ffffffff8118747d>] sys_mkdirat+0xcd/0xe0
Dec 15 14:47:15 bluextal kernel: [ 228.391714] [<ffffffff811874a8>] sys_mkdir+0x18/0x20
Dec 15 14:47:15 bluextal kernel: [ 228.391862] [<ffffffff815d86cf>] tracesys+0xdd/0xe2
==
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v9 0/9] Request for inclusion: per-cgroup tcp memory pressure controls
From: David Miller @ 2011-12-15 5:48 UTC (permalink / raw)
To: kamezawa.hiroyu
Cc: glommer, linux-kernel, paul, lizf, ebiederm, gthelen, netdev,
linux-mm, kirill, avagin, devel, eric.dumazet, cgroups
In-Reply-To: <20111215144019.03706ff7.kamezawa.hiroyu@jp.fujitsu.com>
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Date: Thu, 15 Dec 2011 14:40:19 +0900
> I met this bug at _1st_ run. Please enable _all_ debug options!.
Plus the CONFIG_NET=n and other build failures.
This patch series was seriously rushed, and very poorly handled.
Yet I kept getting so much pressure to review, comment upon, and
ultimately apply these patches. Never, ever, do this to me ever
again.
If I don't feel your patches are high priority enough or ready enough
for me to review, then TOO BAD. Don't ask people to pressure me or
get my attention. Instead, ask others for help and do testing before
wasting MY time and crapping up MY tree.
I should have noticed a red flag when I have James Bottomly asking me
to look at these patches, I should have pushed back. Instead, I
relented, and now I'm very seriously regretting it.
All the regressions in the net-next tree over the past several days
have been due to this patch set, and this patch set alone.
This code wasn't ready and needed, at a minimum, several more weeks of
work before being put in.
Instead, we're going to bandaid patch it up after the fact, rather
than just letting these changes mature naturally during the review
process.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 1/1] r8169.c correct MSIEnable register offset
From: David Miller @ 2011-12-15 6:43 UTC (permalink / raw)
To: romieu; +Cc: cantona, hayeswang, linux-kernel, nic_swsd, netdev
In-Reply-To: <20111214213713.GA2907@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Wed, 14 Dec 2011 22:37:13 +0100
> Su Kang Yin <cantona@cantona.no-ip.org> :
>> correct MSIEnable (bit 5) register to Config1 (offset 0x52) instead of
>> Config2 (offset 0x53)
>
> I wonder where the inspiration for the MSIEnable bit came from.
> It looks like something was confused with the Message Control word
> in PCI space.
>
> Imho you can simply remove it altogether.
Someone should find out what the real situation is with this.
Maybe it mirrors the PCI config space setting and is read-only, maybe
not. But it should be determined for sure before changing this. :-)
^ permalink raw reply
* Re: [PATCH v9 0/9] Request for inclusion: per-cgroup tcp memory pressure controls
From: Glauber Costa @ 2011-12-15 6:48 UTC (permalink / raw)
To: David Miller
Cc: kamezawa.hiroyu, linux-kernel, paul, lizf, ebiederm, gthelen,
netdev, linux-mm, kirill, avagin, devel, eric.dumazet, cgroups
In-Reply-To: <20111215.004836.402973956281143052.davem@davemloft.net>
On 12/15/2011 09:48 AM, David Miller wrote:
> From: KAMEZAWA Hiroyuki<kamezawa.hiroyu@jp.fujitsu.com>
> Date: Thu, 15 Dec 2011 14:40:19 +0900
>
>> I met this bug at _1st_ run. Please enable _all_ debug options!.
>
> Plus the CONFIG_NET=n and other build failures.
>
> This patch series was seriously rushed, and very poorly handled.
>
> Yet I kept getting so much pressure to review, comment upon, and
> ultimately apply these patches. Never, ever, do this to me ever
> again.
>
> If I don't feel your patches are high priority enough or ready enough
> for me to review, then TOO BAD. Don't ask people to pressure me or
> get my attention. Instead, ask others for help and do testing before
> wasting MY time and crapping up MY tree.
>
> I should have noticed a red flag when I have James Bottomly asking me
> to look at these patches, I should have pushed back. Instead, I
> relented, and now I'm very seriously regretting it.
>
> All the regressions in the net-next tree over the past several days
> have been due to this patch set, and this patch set alone.
>
> This code wasn't ready and needed, at a minimum, several more weeks of
> work before being put in.
>
> Instead, we're going to bandaid patch it up after the fact, rather
> than just letting these changes mature naturally during the review
> process.
Hi Dave,
You are right about all points. I will admit to it, face it, and
apologize it.
I guess the best I can do right now is fix whatever you guys point me to
and not repeat it in the future.
Thanks
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ 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