* Re: [PATCH] vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)
From: Pedro Garcia @ 2010-07-01 18:47 UTC (permalink / raw)
To: netdev; +Cc: Patrick McHardy, Ben Hutchings, Eric Dumazet, David Miller
In-Reply-To: <20100630.131616.233403329.davem@davemloft.net>
The patch with the modifications suggested by David.
- Without the 8021q module loaded in the kernel, all 802.1p packets
(VLAN 0 but QoS tagging) are silently discarded (as expected, as
the protocol is not loaded).
- Without this patch in 8021q module, these packets are forwarded to
the module, but they are discarded also if VLAN 0 is not configured,
which should not be the default behaviour, as VLAN 0 is not really
a VLANed packet but a 802.1p packet. Defining VLAN 0 makes it almost
impossible to communicate with mixed 802.1p and non 802.1p devices on
the same network due to arp table issues.
- Changed logic to skip vlan specific code in vlan_skb_recv if VLAN
is 0 and we have not defined a VLAN with ID 0, but we accept the
packet with the encapsulated proto and pass it later to netif_rx.
- In the vlan device event handler, added some logic to add VLAN 0
to HW filter in devices that support it (this prevented any traffic
in VLAN 0 to reach the stack in e1000e with HW filter under 2.6.35,
and probably also with other HW filtered cards, so we fix it here).
- In the vlan unregister logic, prevent the elimination of VLAN 0
in devices with HW filter.
- The default behaviour is to ignore the VLAN 0 tagging and accept
the packet as if it was not tagged, but we can still define a
VLAN 0 if desired (so it is backwards compatible).
Signed-off-by: Pedro Garcia <pedro.netdev@dondevamos.com>
--
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 3c1c8c1..a2ad152 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -155,9 +155,10 @@ void unregister_vlan_dev(struct net_device *dev, struct list_head *head)
BUG_ON(!grp);
/* Take it out of our own structures, but be sure to interlock with
- * HW accelerating devices or SW vlan input packet processing.
+ * HW accelerating devices or SW vlan input packet processing if
+ * VLAN is not 0 (leave it there for 802.1p).
*/
- if (real_dev->features & NETIF_F_HW_VLAN_FILTER)
+ if (vlan_id && (real_dev->features & NETIF_F_HW_VLAN_FILTER))
ops->ndo_vlan_rx_kill_vid(real_dev, vlan_id);
grp->nr_vlans--;
@@ -419,6 +420,14 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
if (is_vlan_dev(dev))
__vlan_device_event(dev, event);
+ if ((event == NETDEV_UP) &&
+ (dev->features & NETIF_F_HW_VLAN_FILTER) &&
+ dev->netdev_ops->ndo_vlan_rx_add_vid) {
+ pr_info("8021q: adding VLAN 0 to HW filter on device %s\n",
+ dev->name);
+ dev->netdev_ops->ndo_vlan_rx_add_vid(dev, 0);
+ }
+
grp = __vlan_find_group(dev);
if (!grp)
goto out;
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 50f58f5..0f91f46 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -8,6 +8,9 @@
int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
u16 vlan_tci, int polling)
{
+ struct net_device *vlan_dev;
+ u16 vlan_id;
+
if (netpoll_rx(skb))
return NET_RX_DROP;
@@ -16,9 +19,12 @@ int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
skb->skb_iif = skb->dev->ifindex;
__vlan_hwaccel_put_tag(skb, vlan_tci);
- skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
+ vlan_id = vlan_tci & VLAN_VID_MASK;
+ vlan_dev = vlan_group_get_device(grp, vlan_id);
- if (!skb->dev)
+ if (vlan_dev)
+ skb->dev = vlan_dev;
+ else if (vlan_id)
goto drop;
return (polling ? netif_receive_skb(skb) : netif_rx(skb));
@@ -82,15 +88,20 @@ vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp,
unsigned int vlan_tci, struct sk_buff *skb)
{
struct sk_buff *p;
+ struct net_device *vlan_dev;
+ u16 vlan_id;
if (skb_bond_should_drop(skb, ACCESS_ONCE(skb->dev->master)))
skb->deliver_no_wcard = 1;
skb->skb_iif = skb->dev->ifindex;
__vlan_hwaccel_put_tag(skb, vlan_tci);
- skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
+ vlan_id = vlan_tci & VLAN_VID_MASK;
+ vlan_dev = vlan_group_get_device(grp, vlan_id);
- if (!skb->dev)
+ if (vlan_dev)
+ skb->dev = vlan_dev;
+ else if (vlan_id)
goto drop;
for (p = napi->gro_list; p; p = p->next) {
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 5298426..21f7229 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -142,6 +142,7 @@ int vlan_skb_recv(struct sk_buff *skb, struct net_device *dev,
{
struct vlan_hdr *vhdr;
struct vlan_rx_stats *rx_stats;
+ struct net_device *vlan_dev;
u16 vlan_id;
u16 vlan_tci;
@@ -157,53 +158,69 @@ int vlan_skb_recv(struct sk_buff *skb, struct net_device *dev,
vlan_id = vlan_tci & VLAN_VID_MASK;
rcu_read_lock();
- skb->dev = __find_vlan_dev(dev, vlan_id);
- if (!skb->dev) {
- pr_debug("%s: ERROR: No net_device for VID: %u on dev: %s\n",
- __func__, vlan_id, dev->name);
- goto err_unlock;
- }
-
- rx_stats = per_cpu_ptr(vlan_dev_info(skb->dev)->vlan_rx_stats,
- smp_processor_id());
- rx_stats->rx_packets++;
- rx_stats->rx_bytes += skb->len;
-
- skb_pull_rcsum(skb, VLAN_HLEN);
-
- skb->priority = vlan_get_ingress_priority(skb->dev, vlan_tci);
+ vlan_dev = __find_vlan_dev(dev, vlan_id);
- pr_debug("%s: priority: %u for TCI: %hu\n",
- __func__, skb->priority, vlan_tci);
-
- switch (skb->pkt_type) {
- case PACKET_BROADCAST: /* Yeah, stats collect these together.. */
- /* stats->broadcast ++; // no such counter :-( */
- break;
-
- case PACKET_MULTICAST:
- rx_stats->multicast++;
- break;
+ /* If the VLAN device is defined, we use it.
+ * If not, and the VID is 0, it is a 802.1p packet (not
+ * really a VLAN), so we will just netif_rx it later to the
+ * original interface, but with the skb->proto set to the
+ * wrapped proto: we do nothing here.
+ */
- case PACKET_OTHERHOST:
- /* Our lower layer thinks this is not local, let's make sure.
- * This allows the VLAN to have a different MAC than the
- * underlying device, and still route correctly.
- */
- if (!compare_ether_addr(eth_hdr(skb)->h_dest,
- skb->dev->dev_addr))
- skb->pkt_type = PACKET_HOST;
- break;
- default:
- break;
+ if (!vlan_dev) {
+ if (vlan_id) {
+ pr_debug("%s: ERROR: No net_device for VID: %u on dev: %s\n",
+ __func__, vlan_id, dev->name);
+ goto err_unlock;
+ }
+ rx_stats = NULL;
+ } else {
+ skb->dev = vlan_dev;
+
+ rx_stats = per_cpu_ptr(vlan_dev_info(skb->dev)->vlan_rx_stats,
+ smp_processor_id());
+ rx_stats->rx_packets++;
+ rx_stats->rx_bytes += skb->len;
+
+ skb->priority = vlan_get_ingress_priority(skb->dev, vlan_tci);
+
+ pr_debug("%s: priority: %u for TCI: %hu\n",
+ __func__, skb->priority, vlan_tci);
+
+ switch (skb->pkt_type) {
+ case PACKET_BROADCAST:
+ /* Yeah, stats collect these together.. */
+ /* stats->broadcast ++; // no such counter :-( */
+ break;
+
+ case PACKET_MULTICAST:
+ rx_stats->multicast++;
+ break;
+
+ case PACKET_OTHERHOST:
+ /* Our lower layer thinks this is not local, let's make
+ * sure.
+ * This allows the VLAN to have a different MAC than the
+ * underlying device, and still route correctly.
+ */
+ if (!compare_ether_addr(eth_hdr(skb)->h_dest,
+ skb->dev->dev_addr))
+ skb->pkt_type = PACKET_HOST;
+ break;
+ default:
+ break;
+ }
}
+ skb_pull_rcsum(skb, VLAN_HLEN);
vlan_set_encap_proto(skb, vhdr);
- skb = vlan_check_reorder_header(skb);
- if (!skb) {
- rx_stats->rx_errors++;
- goto err_unlock;
+ if (vlan_dev) {
+ skb = vlan_check_reorder_header(skb);
+ if (!skb) {
+ rx_stats->rx_errors++;
+ goto err_unlock;
+ }
}
netif_rx(skb);
^ permalink raw reply related
* pull request: wireless-next-2.6 2010-07-01
From: John W. Linville @ 2010-07-01 18:15 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
David,
Two weeks since the last request, plenty of new stuff intended for
2.6.36...
Included are the usual bunch of driver updates, including a big
dump from the rt2x00 team. This also includes cfg80211 support
for libertas, a flurry of (mostly trivial) stuff from me, and a
wireless-2.6 pull to resolve some patch dependencies.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit ea812ca1b06113597adcd8e70c0f84a413d97544:
Alexander Duyck (1):
x86: Align skb w/ start of cacheline on newer core 2/Xeon Arch
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Bruno Randolf (1):
ath5k: fix antenna div gc for <= AR5K_SREV_PHY_2413
Daniel Halperin (1):
iwlwifi: update LQ for bcast station on channel change
Felix Fietkau (3):
ath9k: fix retry count for A-MPDU rate control status reports
mac80211: fix the for_each_sta_info macro
ath9k: fix TSF after reset on AR913x
Gertjan van Wingerde (10):
mac80211: Fix compile warning in scan.c.
rt2x00: Fix frame dumping for USB devices.
rt2x00: Move filling of TX URB to rt2x00usb_kick_tx_entry function.
rt2x00: Merge PCI and USB versions of write_tx_data into single function.
rt2x00: Move common txdone handling to rt2x00lib_txdone.
rt2x00: Rename driver write_tx_datadesc callback function.
rt2x00: Split of TXWI writing to write_tx_data callback in rt2800usb.
eeprom_93cx6: Add support for 93c86 EEPROMs.
rt2x00: Correctly detect 93C86 EEPROMs in rt2800pci.
rt2x00: Align rt2800 EEPROM validation to Ralink vendor driver.
Helmut Schaa (6):
rt2x00: Implement tx mpdu aggregation
rt2x00: Fix beacon updates in rt2800pci
rt2x00: Fix beacon updates in rt61pci
rt2x00: Disable link tuning in AP mode
rt2x00: fix beacon reset on rt2800
mac82011: Allow selection of minstrel_ht as default rc algorithm
Ivo van Doorn (7):
rt2x00: Write the BSSID to register when interface is added
rt2x00: Remove unneeded variable
rt2x00: Enable multiBSS in rt2800
rt2x00: Fix IEEE80211_HT_CAP_RX_STBC assignment
rt2x00: Fix antenna initialization
rt2x00: Always set BBP_CSR_CFG_BBP_RW_MODE to 1
rt2x00: Fix compile warning when debug disabled
Jay Sternberg (1):
iwlwifi: display ucode SW Error in hex
Johannes Berg (7):
mac80211_hwsim: fix fake_hw_scan
mac80211: fix sw scan bracketing
iwlagn: use mutex for aggregation
iwlwifi: use sync commands for keys
iwlwifi: return ucode errors from station management
iwlwifi: fix multicast
iwlwifi: read rfkill during resume
John W. Linville (14):
libertas: mark lbs_ret_802_11d_domain_info static
ath9k: declare MODULE_FIRMWARE for ath9k_htc
rtl8180: mark rtl8180_beacon_work static
mac80211: don't shadow mgmt variable in ieee80211_rx_h_action
minstrel_ht: make *idx unsigned in minstrel_downgrade_rate
wireless: mark reg_mutex as static
minstrel_ht: move minstrel_mcs_groups declaration to header file
mac80211: avoid scheduling while atomic in mesh_rx_plink_frame
mac80211: use netif_receive_skb in ieee80211_rx callpath
mac80211: use netif_receive_skb in ieee80211_tx_status callpath
mac80211: remove unnecessary check in ieee80211_dump_survey
mac80211: add basic tracing to drv_get_survey
ath9k: remove unused function ath9k_hw_keyisvalid
ath9k: make ath9k_hw_keysetmac static
Justin P. Mattock (2):
wireless:hostap_main.c warning: variable 'iface' set but not used
wireless:hostap_ap.c Fix warning: variable 'fc' set but not used
Juuso Oikarinen (3):
mac80211: Add interface for driver to temporarily disable dynamic ps
cfg80211/mac80211: Update set_tx_power to use mBm instead of dBm units
nl80211: Add option to adjust transmit power
Kiran Divekar (3):
Libertas: cfg80211 support
Libertas: fix WARN_ON issues in cfg80211 support
Libertas: Added 11d support using cfg80211
Larry Finger (1):
b43: Clarify logged message after fatal DMA error and switch to PIO mode
Luis R. Rodriguez (5):
ath9k_hw: fix ASPM setting for AR9003
ath9k_hw: move LowPower array writes to ar9003_hw_configpcipowersave()
ath9k_hw: add pcieSerDesWrite to disable SERDES ASPM tweaks
ath9k_hw: dynamically choose the SERDES array for low power
ath9k_hw: add an extra delay when reseting AR_RTC_RESET
Magnus Damm (1):
b43: Add SDIO_DEVICE() for EW-CG1102GC
Ondrej Zary (1):
rt2500usb: fallback to SW encryption for TKIP+AES
Reinette Chatre (2):
Merge branch 'wireless-2.6' into wireless-next-2.6
iwlagn: reduce severity of disconnected antennas warning
Sebastian Smolorz (2):
at76c50x-usb: Move function at76_join() several lines up
at76c50x-usb: Extract bssid from authentication frame
Sujith (2):
ath9k_htc: Update supported product list
ath9k_htc: Add LED support for AR7010
Uwe Kleine-König (2):
cfg80211: move cfg80211_exit to .exit.text
wireless: move regulatory_init to .init.text
Vasanthakumar Thiagarajan (4):
ath9k: Fix bug in starting ani
ath9k: Fix bug in paprd
ath9k: Remove unused paprd_txok
ath9k: Wakeup the chip in an appropriate place in ath_paprd_calibrate()
Vivek Natarajan (1):
ath9k: Add a module parameter to disable led blinking.
Wey-Yi Guy (11):
iwlwifi: move agn specific rx related code to iwl-agn-rx.c
iwlwifi: move _agn statistics related structure
iwlwifi: move calibration from iwlcore to iwlagn
iwlwifi: code cleanup to remove un-necessary "goto"
iwlwifi: remove non-exist reference
iwlwifi: set TX_CMD_FLAG_PROT_REQUIRE_MSK in tx_flag
iwlwifi: name change from signal protection flag
iwlwifi: enable DC calibration based on config parameter
iwlwifi: add a mechanism to disable plcp error checking
iwlwifi: turn on RTS/CTS after aggregation become operational
iwlwifi: add disable rf calibration support for 6000g2a and 6000g2b
Documentation/networking/README.ipw2200 | 2 +-
drivers/net/b44.c | 144 +-
drivers/net/wireless/at76c50x-usb.c | 108 +-
drivers/net/wireless/at76c50x-usb.h | 1 +
drivers/net/wireless/ath/ath5k/Makefile | 1 +
drivers/net/wireless/ath/ath5k/ani.c | 20 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 19 +-
drivers/net/wireless/ath/ath5k/attach.c | 2 -
drivers/net/wireless/ath/ath5k/base.c | 373 ++--
drivers/net/wireless/ath/ath5k/caps.c | 7 -
drivers/net/wireless/ath/ath5k/debug.c | 79 +-
drivers/net/wireless/ath/ath5k/debug.h | 9 +-
drivers/net/wireless/ath/ath5k/desc.c | 152 +-
drivers/net/wireless/ath/ath5k/desc.h | 310 ++--
drivers/net/wireless/ath/ath5k/dma.c | 13 -
drivers/net/wireless/ath/ath5k/eeprom.c | 3 +-
drivers/net/wireless/ath/ath5k/gpio.c | 7 -
drivers/net/wireless/ath/ath5k/pcu.c | 24 -
drivers/net/wireless/ath/ath5k/phy.c | 82 +-
drivers/net/wireless/ath/ath5k/qcu.c | 9 -
drivers/net/wireless/ath/ath5k/reset.c | 64 +-
drivers/net/wireless/ath/ath5k/sysfs.c | 116 +
drivers/net/wireless/ath/ath9k/Makefile | 3 +-
drivers/net/wireless/ath/ath9k/ani.c | 743 ++++++-
drivers/net/wireless/ath/ath9k/ani.h | 78 +-
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 372 +++-
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 118 +-
drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 6 +-
drivers/net/wireless/ath/ath9k/ar9002_phy.h | 7 +
.../{ar9003_initvals.h => ar9003_2p0_initvals.h} | 254 ++--
.../{ar9003_initvals.h => ar9003_2p2_initvals.h} | 433 ++--
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 10 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 13 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 4 +-
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 185 ++-
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 13 +
drivers/net/wireless/ath/ath9k/ar9003_mac.h | 5 +
drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 714 ++++++
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 513 ++++-
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 298 ++-
drivers/net/wireless/ath/ath9k/ath9k.h | 89 +-
drivers/net/wireless/ath/ath9k/beacon.c | 3 +-
drivers/net/wireless/ath/ath9k/common.c | 314 +---
drivers/net/wireless/ath/ath9k/common.h | 77 +-
drivers/net/wireless/ath/ath9k/debug.c | 68 +-
drivers/net/wireless/ath/ath9k/debug.h | 2 +
drivers/net/wireless/ath/ath9k/eeprom.c | 29 +
drivers/net/wireless/ath/ath9k/eeprom.h | 5 +-
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 1 +
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 618 +++---
drivers/net/wireless/ath/ath9k/eeprom_def.c | 1 +
drivers/net/wireless/ath/ath9k/gpio.c | 9 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 71 +-
drivers/net/wireless/ath/ath9k/hif_usb.h | 2 +
drivers/net/wireless/ath/ath9k/htc.h | 38 +-
drivers/net/wireless/ath/ath9k/htc_drv_beacon.c | 23 +
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 163 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 493 +++--
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 86 +-
drivers/net/wireless/ath/ath9k/htc_hst.c | 3 +-
drivers/net/wireless/ath/ath9k/hw-ops.h | 16 +
drivers/net/wireless/ath/ath9k/hw.c | 304 ++--
drivers/net/wireless/ath/ath9k/hw.h | 100 +-
drivers/net/wireless/ath/ath9k/init.c | 58 +-
drivers/net/wireless/ath/ath9k/mac.c | 14 +-
drivers/net/wireless/ath/ath9k/mac.h | 13 +-
drivers/net/wireless/ath/ath9k/main.c | 427 ++---
drivers/net/wireless/ath/ath9k/pci.c | 1 +
drivers/net/wireless/ath/ath9k/rc.c | 184 +-
drivers/net/wireless/ath/ath9k/recv.c | 296 +++-
drivers/net/wireless/ath/ath9k/reg.h | 90 +-
drivers/net/wireless/ath/ath9k/virtual.c | 2 +-
drivers/net/wireless/ath/ath9k/wmi.c | 3 -
drivers/net/wireless/ath/ath9k/xmit.c | 161 +-
drivers/net/wireless/b43/dma.c | 69 +-
drivers/net/wireless/b43/main.c | 2 +-
drivers/net/wireless/b43/sdio.c | 1 +
drivers/net/wireless/b43legacy/dma.c | 49 +-
drivers/net/wireless/hostap/hostap_ap.c | 3 +-
drivers/net/wireless/hostap/hostap_main.c | 2 -
drivers/net/wireless/ipw2x00/ipw2100.c | 18 +-
drivers/net/wireless/ipw2x00/ipw2200.c | 7 +-
drivers/net/wireless/iwlwifi/Kconfig | 6 +-
drivers/net/wireless/iwlwifi/Makefile | 4 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 5 +
drivers/net/wireless/iwlwifi/iwl-3945-debugfs.c | 28 +-
drivers/net/wireless/iwlwifi/iwl-3945.c | 208 +--
drivers/net/wireless/iwlwifi/iwl-4965.c | 96 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 67 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 487 +++--
.../iwlwifi/{iwl-calib.c => iwl-agn-calib.c} | 26 +-
drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c | 91 +-
drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c | 32 +-
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 233 +--
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 20 +-
drivers/net/wireless/iwlwifi/iwl-agn-rx.c | 284 +++
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 82 +-
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 123 +
drivers/net/wireless/iwlwifi/iwl-agn.c | 392 +++-
drivers/net/wireless/iwlwifi/iwl-agn.h | 44 +
drivers/net/wireless/iwlwifi/iwl-commands.h | 35 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 288 +--
drivers/net/wireless/iwlwifi/iwl-core.h | 35 +-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 92 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 95 +-
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 3 +
drivers/net/wireless/iwlwifi/iwl-helpers.h | 27 +
drivers/net/wireless/iwlwifi/iwl-rx.c | 242 +--
drivers/net/wireless/iwlwifi/iwl-scan.c | 49 +-
drivers/net/wireless/iwlwifi/iwl-sta.c | 164 +-
drivers/net/wireless/iwlwifi/iwl-sta.h | 32 +-
drivers/net/wireless/iwlwifi/iwl-tx.c | 33 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 138 +-
drivers/net/wireless/iwmc3200wifi/cfg80211.c | 12 +-
drivers/net/wireless/iwmc3200wifi/hal.c | 2 +-
drivers/net/wireless/iwmc3200wifi/rx.c | 4 +-
drivers/net/wireless/libertas/Makefile | 3 -
drivers/net/wireless/libertas/assoc.c | 2264 -------------------
drivers/net/wireless/libertas/assoc.h | 155 --
drivers/net/wireless/libertas/cfg.c | 2038 +++++++++++++++++-
drivers/net/wireless/libertas/cfg.h | 21 +-
drivers/net/wireless/libertas/cmd.c | 124 +-
drivers/net/wireless/libertas/cmdresp.c | 111 +-
drivers/net/wireless/libertas/debugfs.c | 54 +-
drivers/net/wireless/libertas/decl.h | 10 +-
drivers/net/wireless/libertas/dev.h | 68 +-
drivers/net/wireless/libertas/ethtool.c | 29 +-
drivers/net/wireless/libertas/host.h | 28 +-
drivers/net/wireless/libertas/if_sdio.c | 58 +
drivers/net/wireless/libertas/if_usb.c | 12 +-
drivers/net/wireless/libertas/main.c | 305 +--
drivers/net/wireless/libertas/mesh.c | 6 +-
drivers/net/wireless/libertas/mesh.h | 5 -
drivers/net/wireless/libertas/rx.c | 121 +-
drivers/net/wireless/libertas/scan.c | 1354 -----------
drivers/net/wireless/libertas/scan.h | 63 -
drivers/net/wireless/libertas/tx.c | 12 +-
drivers/net/wireless/libertas/wext.c | 2353 --------------------
drivers/net/wireless/libertas/wext.h | 17 -
drivers/net/wireless/libertas_tf/if_usb.c | 5 +-
drivers/net/wireless/mac80211_hwsim.c | 5 +
drivers/net/wireless/mwl8k.c | 12 +-
drivers/net/wireless/orinoco/hermes_dld.c | 2 +-
drivers/net/wireless/orinoco/orinoco_usb.c | 4 +-
drivers/net/wireless/orinoco/wext.c | 4 +-
drivers/net/wireless/p54/eeprom.c | 4 +-
drivers/net/wireless/p54/p54spi.c | 5 +-
drivers/net/wireless/p54/p54usb.c | 6 +-
drivers/net/wireless/prism54/isl_ioctl.c | 11 +-
drivers/net/wireless/rndis_wlan.c | 56 +-
drivers/net/wireless/rt2x00/rt2400pci.c | 16 +-
drivers/net/wireless/rt2x00/rt2500pci.c | 16 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 40 +-
drivers/net/wireless/rt2x00/rt2800.h | 57 +-
drivers/net/wireless/rt2x00/rt2800lib.c | 314 ++-
drivers/net/wireless/rt2x00/rt2800lib.h | 13 +-
drivers/net/wireless/rt2x00/rt2800pci.c | 151 +-
drivers/net/wireless/rt2x00/rt2800pci.h | 19 -
drivers/net/wireless/rt2x00/rt2800usb.c | 119 +-
drivers/net/wireless/rt2x00/rt2800usb.h | 37 -
drivers/net/wireless/rt2x00/rt2x00.h | 44 +-
drivers/net/wireless/rt2x00/rt2x00config.c | 12 +-
drivers/net/wireless/rt2x00/rt2x00debug.c | 1 +
drivers/net/wireless/rt2x00/rt2x00dev.c | 43 +-
drivers/net/wireless/rt2x00/rt2x00dump.h | 7 +-
drivers/net/wireless/rt2x00/rt2x00ht.c | 47 +-
drivers/net/wireless/rt2x00/rt2x00lib.h | 26 +-
drivers/net/wireless/rt2x00/rt2x00link.c | 8 +-
drivers/net/wireless/rt2x00/rt2x00mac.c | 10 +-
drivers/net/wireless/rt2x00/rt2x00pci.c | 33 +-
drivers/net/wireless/rt2x00/rt2x00pci.h | 10 -
drivers/net/wireless/rt2x00/rt2x00queue.c | 86 +-
drivers/net/wireless/rt2x00/rt2x00queue.h | 9 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 68 +-
drivers/net/wireless/rt2x00/rt2x00usb.h | 29 -
drivers/net/wireless/rt2x00/rt61pci.c | 62 +-
drivers/net/wireless/rt2x00/rt73usb.c | 52 +-
drivers/net/wireless/rtl818x/rtl8180_dev.c | 2 +-
drivers/net/wireless/wl12xx/Kconfig | 4 +-
drivers/net/wireless/wl12xx/wl1251_main.c | 4 +-
drivers/net/wireless/wl12xx/wl1251_sdio.c | 40 +-
drivers/net/wireless/wl12xx/wl1271.h | 31 +-
drivers/net/wireless/wl12xx/wl1271_cmd.c | 41 +-
drivers/net/wireless/wl12xx/wl1271_cmd.h | 28 +-
drivers/net/wireless/wl12xx/wl1271_event.c | 10 +-
drivers/net/wireless/wl12xx/wl1271_ini.h | 123 +
drivers/net/wireless/wl12xx/wl1271_main.c | 95 +-
drivers/net/wireless/wl12xx/wl1271_sdio.c | 2 +-
drivers/net/wireless/wl12xx/wl1271_testmode.c | 11 +-
drivers/net/wireless/wl12xx/wl1271_tx.c | 36 +-
drivers/net/wireless/wl12xx/wl1271_tx.h | 1 +
drivers/net/wireless/zd1211rw/zd_mac.c | 5 +-
drivers/net/wireless/zd1211rw/zd_mac.h | 3 +-
drivers/net/wireless/zd1211rw/zd_usb.c | 2 +-
drivers/ssb/driver_chipcommon.c | 25 +
drivers/ssb/driver_chipcommon_pmu.c | 17 +-
drivers/ssb/main.c | 76 +-
drivers/ssb/pci.c | 15 +-
include/linux/eeprom_93cx6.h | 1 +
include/linux/nl80211.h | 24 +-
include/linux/ssb/ssb.h | 159 +--
include/net/cfg80211.h | 137 +-
include/net/mac80211.h | 120 +-
net/mac80211/Kconfig | 8 +
net/mac80211/Makefile | 4 +
net/mac80211/agg-rx.c | 123 +-
net/mac80211/agg-tx.c | 554 +++--
net/mac80211/cfg.c | 100 +-
net/mac80211/debugfs.c | 154 +-
net/mac80211/debugfs_key.c | 2 +-
net/mac80211/debugfs_sta.c | 65 +-
net/mac80211/driver-ops.h | 102 +-
net/mac80211/driver-trace.h | 210 +-
net/mac80211/ht.c | 50 +-
net/mac80211/ibss.c | 109 +-
net/mac80211/ieee80211_i.h | 73 +-
net/mac80211/iface.c | 188 ++-
net/mac80211/key.c | 290 +--
net/mac80211/key.h | 30 +-
net/mac80211/main.c | 116 +-
net/mac80211/mesh.c | 73 +-
net/mac80211/mesh.h | 2 -
net/mac80211/mesh_hwmp.c | 4 +-
net/mac80211/mesh_pathtbl.c | 4 +-
net/mac80211/mesh_plink.c | 42 +-
net/mac80211/mlme.c | 239 +--
net/mac80211/pm.c | 18 +-
net/mac80211/rate.h | 13 +
net/mac80211/rc80211_minstrel_ht.c | 825 +++++++
net/mac80211/rc80211_minstrel_ht.h | 130 ++
net/mac80211/rc80211_minstrel_ht_debugfs.c | 118 +
net/mac80211/rx.c | 193 +-
net/mac80211/scan.c | 6 +-
net/mac80211/sta_info.c | 22 +-
net/mac80211/sta_info.h | 113 +-
net/mac80211/status.c | 6 +-
net/mac80211/tx.c | 93 +-
net/mac80211/util.c | 31 +-
net/mac80211/work.c | 2 +-
net/mac80211/wpa.c | 8 +-
net/wireless/chan.c | 5 +-
net/wireless/core.c | 2 +-
net/wireless/core.h | 1 +
net/wireless/mlme.c | 8 +-
net/wireless/nl80211.c | 89 +-
net/wireless/reg.c | 6 +-
net/wireless/reg.h | 2 +-
net/wireless/wext-compat.c | 10 +-
248 files changed, 14685 insertions(+), 13932 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath5k/sysfs.c
copy drivers/net/wireless/ath/ath9k/{ar9003_initvals.h => ar9003_2p0_initvals.h} (87%)
rename drivers/net/wireless/ath/ath9k/{ar9003_initvals.h => ar9003_2p2_initvals.h} (78%)
create mode 100644 drivers/net/wireless/ath/ath9k/ar9003_paprd.c
rename drivers/net/wireless/iwlwifi/{iwl-calib.c => iwl-agn-calib.c} (98%)
create mode 100644 drivers/net/wireless/iwlwifi/iwl-agn-rx.c
delete mode 100644 drivers/net/wireless/libertas/assoc.c
delete mode 100644 drivers/net/wireless/libertas/assoc.h
delete mode 100644 drivers/net/wireless/libertas/scan.c
delete mode 100644 drivers/net/wireless/libertas/scan.h
delete mode 100644 drivers/net/wireless/libertas/wext.c
delete mode 100644 drivers/net/wireless/libertas/wext.h
create mode 100644 drivers/net/wireless/wl12xx/wl1271_ini.h
create mode 100644 net/mac80211/rc80211_minstrel_ht.c
create mode 100644 net/mac80211/rc80211_minstrel_ht.h
create mode 100644 net/mac80211/rc80211_minstrel_ht_debugfs.c
Omnibus patch available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2010-07-01.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
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] igbvf: avoid name clash between PF and VF
From: Casey Leedom @ 2010-07-01 17:12 UTC (permalink / raw)
To: Stefan Assmann
Cc: e1000-devel, netdev, gregory.v.rose, jeffrey.t.kirsher,
Andy Gospodarek
In-Reply-To: <4C2C378D.4090806@redhat.com>
| From: Stefan Assmann <sassmann@redhat.com>
| Date: Wednesday, June 30, 2010 11:37 pm
|
| You're correct, the problem shouldn't occur with cxgb4vf and therefore
| this change shouldn't be necessary. However we might consider a
| consistent naming scheme for VFs in all drivers. But I don't have a
| strong opinion about this, either way would be fine by me.
Sorry, I hadn't meant to imply any criticism of your naming proposal. I was
just trying to clarify when/where such a scheme might be necessary.
On the naming proposal itself, it strikes me that the most common use of PCI-E
SR-IOV Virtual Functions will be to export them to KVM Virtual Machines via PCI
"Pass Through." So there shouldn't be any naming conflict there, right? Or is
it the same scenario you described before: that the VF NIC device might be found
before the normal "eth0", etc. withing the Virtual Machine?
In any case, I don't really have any feelings one way or the other about
interface naming. As I mentioned before, the cxgb4vf driver will end up with
persistent MAC addresses so all the normal interface management stuff will work
normally (naming, DHCP, etc.)
Casey
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
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
* [GIT PULL net-2.6] vhost-net: more error handling fixes
From: Michael S. Tsirkin @ 2010-07-01 16:41 UTC (permalink / raw)
To: David Miller; +Cc: kvm, virtualization, netdev, linux-kernel, krkumar2
David,
The following tree includes more fixes dealing with
error handling in vhost-net. It is on top of net-2.6.
Please merge it for 2.6.35.
Thanks!
The following changes since commit 38000a94a902e94ca8b5498f7871c6316de8957a:
sky2: enable rx/tx in sky2_phy_reinit() (2010-06-23 14:37:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-net
Michael S. Tsirkin (2):
vhost: break out of polling loop on error
vhost: add unlikely annotations to error path
drivers/vhost/net.c | 12 ++++++-
drivers/vhost/vhost.c | 86 +++++++++++++++++++++++++------------------------
drivers/vhost/vhost.h | 8 ++--
3 files changed, 58 insertions(+), 48 deletions(-)
--
MST
^ permalink raw reply
* Re: RFC: Allow 'ip' to run in daemon mode?
From: Stephen Hemminger @ 2010-07-01 16:35 UTC (permalink / raw)
To: Ben Greear; +Cc: Simon Horman, NetDev
In-Reply-To: <4C2CB739.3020001@candelatech.com>
On Thu, 01 Jul 2010 08:41:45 -0700
Ben Greear <greearb@candelatech.com> wrote:
> On 07/01/2010 12:07 AM, Simon Horman wrote:
> > On Tue, Jun 29, 2010 at 08:34:41AM -0700, Ben Greear wrote:
> >> I'm considering modifying 'ip' to be able to run in daemon
> >> mode so that I can do lots of IP commands without having to
> >> pay the startup cost of iproute.
> >>
> >> The -batch option almost works, but it's hard to programatically
> >> figure out failure codes.
> >>
> >> I'm thinking about making these changes:
> >>
> >> 1) Move all of the error printing code into common methods (basically,
> >> wrap printf). In daemon mode this text can be sent back to the
> >> calling process, and in normal mode, it will be printed to stdout/stderr
> >> as it is currently.
> >>
> >> 2) Remove all or most calls to 'exit' and instead return error codes
> >> to the calling logic.
> >>
> >> 3) Add ability to listen on a unix socket for commands, basically treat
> >> them just like batch commands, one command per packet.
> >>
> >> 4) Return well formatted error code and text response to calling process
> >> over the unix socket, maybe something like:
> >>
> >> RV: [errno or equiv, zero for success]\n
> >> CMD: [ command string this relates to ]\n
> >> [ Optional free form text ]
> >>
> >>
> >> Does something like this have any chance of upstream inclusion?
> >
> > Hi Ben,
> >
> > can't you achieve as much by omitting 3) and using stdio (cleanly)?
> > Or in other words, fix batch mode rather than adding another mode.
> > Or are you worried about backwards-compatibility?
>
> I think the most of the work will be in steps 1 and 2. Adding a listening
> socket and dealing with that is probably 50-100 lines of code.
>
> I'd be happy to attempt steps 1, 2, and possibly 4 for standard iproute2.
> If the unix socket thing still isn't wanted, it would be relatively easy for me
> to carry a patch to enable it in my own code.
>
> I think a lot of folks are scraping the output of 'ip', so backwards compat of
> the error messages is a concern.
Use libnl and write a real service. Maybe even use json
--
^ permalink raw reply
* Re: [PATCH ethtool 2/2] ethtool: Add support for control of RX flow hash indirection
From: Ben Hutchings @ 2010-07-01 16:03 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-net-drivers
In-Reply-To: <1277910792.2082.18.camel@achroite.uk.solarflarecom.com>
On Wed, 2010-06-30 at 16:13 +0100, Ben Hutchings wrote:
> Many NICs use an indirection table to map an RX flow hash value to one
> of an arbitrary number of queues (not necessarily a power of 2). It
> can be useful to remove some queues from this indirection table so
> that they are only used for flows that are specifically filtered
> there. It may also be useful to weight the mapping to account for
> user processes with the same CPU-affinity as the RX interrupts.
[...]
> + printf("RX flow hash indirection table for %s with %llu RX ring(s):\n",
> + devname, ring_count.data);
> + for (i = 0; i < indir->size; i++) {
> + if (i % 8 == 0)
> + printf("%5zu: ", i);
> + printf(" %5u", indir->ring_index[i]);
> + if (i % 8 == 7)
> + fputc('\n', stdout);
> + }
[...]
The "%5zu: " above should be "%5u: ". I can either send another patch
or leave you to fix this up, as you prefer.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: [net-next-2.6 PATCH 1/8] e1000e: cleanup ethtool loopback setup code
From: Ben Hutchings @ 2010-07-01 15:55 UTC (permalink / raw)
To: Allan, Bruce W; +Cc: David Miller, Kirsher, Jeffrey T, netdev@vger.kernel.org
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A9001591F6130@orsmsx509.amr.corp.intel.com>
On Wed, 2010-06-30 at 15:41 -0700, Allan, Bruce W wrote:
> On Friday, June 18, 2010 10:15 PM, David Miller wrote:
> > I've applied this series however:
> >
> > 1) Please address Ben's concerns about turning EEE on by default
> > given that standardization is not complete yet.
> >
> > 2) I hate module parameters, I'd rather you create a new ethtool
> > feature bit and thus allow the setting to be modified at run
> > time. Please create a new ethtool control flag, and remove
> > this module option.
> >
> > Thanks.
>
> Hi Dave,
>
> I've been looking into your request number 2 above (as a reminder, it
> had to do with a patch I submitted that added a module parameter to
> e1000e in order to enable/disable Energy Efficient Ethernet for a
> particular type of adapter).
>
> For this new ethtool feature bit/flag for EEE, would you prefer it be
> set via:
> 1) the generic parameter setting option (e.g. -s ethX [eee on|off]),
> 2) yet another new show/change option pair, or
> 3) a new option that can set this new feature and be expandable to
> future features that are likewise not related to existing ethtool
> options (e.g. -F [eee on|off] [whizbang on|off])?
The ethtool utility is maintained by Jeff Garzik, not David.
> For #2 or #3, it makes sense to use ethtool_op_[g|s]et_flags with new
> ETH_FLAG_<feature> and NETIF_F_<feature> defines, but #1 can be
> implemented that way or by using remaining reserved elements of struct
> ethtool_cmd - if your preference is for #1, would you prefer it be
> implemented with the former or latter?
I don't think this belongs in the netdev features because it's nothing
that the networking stack needs to care about. It could go in the
ethtool flags though currently the ethtool utility assumes those are
only for protocol offload/acceleration features.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: RFC: Allow 'ip' to run in daemon mode?
From: Ben Greear @ 2010-07-01 15:41 UTC (permalink / raw)
To: Simon Horman; +Cc: NetDev, Stephen Hemminger
In-Reply-To: <20100701070753.GA15216@verge.net.au>
On 07/01/2010 12:07 AM, Simon Horman wrote:
> On Tue, Jun 29, 2010 at 08:34:41AM -0700, Ben Greear wrote:
>> I'm considering modifying 'ip' to be able to run in daemon
>> mode so that I can do lots of IP commands without having to
>> pay the startup cost of iproute.
>>
>> The -batch option almost works, but it's hard to programatically
>> figure out failure codes.
>>
>> I'm thinking about making these changes:
>>
>> 1) Move all of the error printing code into common methods (basically,
>> wrap printf). In daemon mode this text can be sent back to the
>> calling process, and in normal mode, it will be printed to stdout/stderr
>> as it is currently.
>>
>> 2) Remove all or most calls to 'exit' and instead return error codes
>> to the calling logic.
>>
>> 3) Add ability to listen on a unix socket for commands, basically treat
>> them just like batch commands, one command per packet.
>>
>> 4) Return well formatted error code and text response to calling process
>> over the unix socket, maybe something like:
>>
>> RV: [errno or equiv, zero for success]\n
>> CMD: [ command string this relates to ]\n
>> [ Optional free form text ]
>>
>>
>> Does something like this have any chance of upstream inclusion?
>
> Hi Ben,
>
> can't you achieve as much by omitting 3) and using stdio (cleanly)?
> Or in other words, fix batch mode rather than adding another mode.
> Or are you worried about backwards-compatibility?
I think the most of the work will be in steps 1 and 2. Adding a listening
socket and dealing with that is probably 50-100 lines of code.
I'd be happy to attempt steps 1, 2, and possibly 4 for standard iproute2.
If the unix socket thing still isn't wanted, it would be relatively easy for me
to carry a patch to enable it in my own code.
I think a lot of folks are scraping the output of 'ip', so backwards compat of
the error messages is a concern.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH repost] sched: export sched_set/getaffinity to modules
From: Peter Zijlstra @ 2010-07-01 14:55 UTC (permalink / raw)
To: Tejun Heo
Cc: Oleg Nesterov, Michael S. Tsirkin, Ingo Molnar, Sridhar Samudrala,
netdev, lkml, kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev,
Jiri Kosina, Thomas Gleixner, Andi Kleen
In-Reply-To: <4C2CABF2.2020801@kernel.org>
On Thu, 2010-07-01 at 16:53 +0200, Tejun Heo wrote:
> Hello,
>
> On 07/01/2010 04:46 PM, Oleg Nesterov wrote:
> >> It might be a good idea to make the function take extra clone flags
> >> but anyways once created cloned task can be treated the same way as
> >> other kthreads, so nothing else needs to be changed.
> >
> > This makes kthread_stop() work. Otherwise the new thread is just
> > the CLONE_VM child of the caller, and the caller is the user-mode
> > task doing ioctl() ?
>
> Hmmm, indeed. It makes the attribute inheritance work but circumvents
> the whole reason there is kthreadd.
I thought the whole reason there was threadd was to avoid the
inheritance? So avoiding the avoiding of inheritance seems like the goal
here, no?
^ permalink raw reply
* Re: [PATCH repost] sched: export sched_set/getaffinity to modules
From: Tejun Heo @ 2010-07-01 14:53 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Michael S. Tsirkin, Peter Zijlstra, Ingo Molnar,
Sridhar Samudrala, netdev, lkml, kvm@vger.kernel.org,
Andrew Morton, Dmitri Vorobiev, Jiri Kosina, Thomas Gleixner,
Andi Kleen
In-Reply-To: <20100701144624.GA11171@redhat.com>
Hello,
On 07/01/2010 04:46 PM, Oleg Nesterov wrote:
>> It might be a good idea to make the function take extra clone flags
>> but anyways once created cloned task can be treated the same way as
>> other kthreads, so nothing else needs to be changed.
>
> This makes kthread_stop() work. Otherwise the new thread is just
> the CLONE_VM child of the caller, and the caller is the user-mode
> task doing ioctl() ?
Hmmm, indeed. It makes the attribute inheritance work but circumvents
the whole reason there is kthreadd.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH repost] sched: export sched_set/getaffinity to modules
From: Oleg Nesterov @ 2010-07-01 14:46 UTC (permalink / raw)
To: Tejun Heo
Cc: Michael S. Tsirkin, Peter Zijlstra, Ingo Molnar,
Sridhar Samudrala, netdev, lkml, kvm@vger.kernel.org,
Andrew Morton, Dmitri Vorobiev, Jiri Kosina, Thomas Gleixner,
Andi Kleen
In-Reply-To: <4C2CA5C5.4040402@kernel.org>
On 07/01, Tejun Heo wrote:
>
> All that's necessary is shortcutting indirection through kthreadd.
> ie. An exported function which looks like the following,
>
> struct kthread_clone_or_whatever(int (*threadfn).....)
> {
> struct kthread_create_info create;
> int pid;
>
> INIT create;
>
> pid = kernel_thread(kthread, &create, CLONE_FS...);
> if (pid < 0)
> return ERROR;
> wait_for_completion(&create.done);
>
> if (!IS_ERR(create.result))
> SET NAME;
> return create.result;
> }
>
> It might be a good idea to make the function take extra clone flags
> but anyways once created cloned task can be treated the same way as
> other kthreads, so nothing else needs to be changed.
This makes kthread_stop() work. Otherwise the new thread is just
the CLONE_VM child of the caller, and the caller is the user-mode
task doing ioctl() ?
Oleg.
^ permalink raw reply
* Re: [PATCH repost] sched: export sched_set/getaffinity to modules
From: Oleg Nesterov @ 2010-07-01 14:33 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Michael S. Tsirkin, Ingo Molnar, Sridhar Samudrala, Tejun Heo,
netdev, lkml, kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev,
Jiri Kosina, Thomas Gleixner, Andi Kleen
In-Reply-To: <1277991024.1917.108.camel@laptop>
On 07/01, Peter Zijlstra wrote:
>
> On Thu, 2010-07-01 at 16:08 +0300, Michael S. Tsirkin wrote:
> > Maybe it makes sense to add kthread_clone (in addition to
> > kthread_create) that would do what you suggest?
> > If yes, any hints on an implementation?
>
> I think that's called kernel_thread() see
> kernel/kthread.c:create_kthread().
Well, strictly speaking kernel_thread() doesn't create the kernel thread.
Unless the caller is the kernel thread. And daemonize() is deprecated.
kernel_thread() just forks the CLONE_VM + flags child.
Oleg.
^ permalink raw reply
* Re: [PATCH repost] sched: export sched_set/getaffinity to modules
From: Tejun Heo @ 2010-07-01 14:27 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Peter Zijlstra, Ingo Molnar, Sridhar Samudrala, Oleg Nesterov,
netdev, lkml, kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev,
Jiri Kosina, Thomas Gleixner, Andi Kleen
In-Reply-To: <20100701133956.GD32223@redhat.com>
Hello,
On 07/01/2010 03:39 PM, Michael S. Tsirkin wrote:
>> I think that's called kernel_thread() see
>> kernel/kthread.c:create_kthread().
>>
>> Doing the whole kthreadd dance and then copying bits and pieces back
>> sounds very fragile, so yeah, something like that should work.
>
> Thanks!
> Sridhar, Tejun, have the time to look into this approach?
All that's necessary is shortcutting indirection through kthreadd.
ie. An exported function which looks like the following,
struct kthread_clone_or_whatever(int (*threadfn).....)
{
struct kthread_create_info create;
int pid;
INIT create;
pid = kernel_thread(kthread, &create, CLONE_FS...);
if (pid < 0)
return ERROR;
wait_for_completion(&create.done);
if (!IS_ERR(create.result))
SET NAME;
return create.result;
}
It might be a good idea to make the function take extra clone flags
but anyways once created cloned task can be treated the same way as
other kthreads, so nothing else needs to be changed.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH repost] sched: export sched_set/getaffinity to modules
From: Peter Zijlstra @ 2010-07-01 13:57 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Ingo Molnar, Sridhar Samudrala, Tejun Heo, Oleg Nesterov, netdev,
lkml, kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev,
Jiri Kosina, Thomas Gleixner, Andi Kleen
In-Reply-To: <20100701133956.GD32223@redhat.com>
On Thu, 2010-07-01 at 16:39 +0300, Michael S. Tsirkin wrote:
>
> The proposed patch kills the thread when the fd is closed,
> so I think this already works without making it part of the process.
>
OK, fd bound resources are fine.
^ permalink raw reply
* [PATCH net-next-2.6] be2net: changes to properly provide phy details
From: Ajit Khaparde @ 2010-07-01 13:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev
be2net driver is currently not showing correct phy details in certain cases.
This patch fixes it.
Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
---
drivers/net/benet/be.h | 1 +
drivers/net/benet/be_cmds.c | 35 +++++++++++++++++++++++++
drivers/net/benet/be_cmds.h | 27 +++++++++++++++++++
drivers/net/benet/be_ethtool.c | 55 +++++++++++++++++++++++++++++----------
4 files changed, 104 insertions(+), 14 deletions(-)
diff --git a/drivers/net/benet/be.h b/drivers/net/benet/be.h
index b46be49..1a0d2d0 100644
--- a/drivers/net/benet/be.h
+++ b/drivers/net/benet/be.h
@@ -282,6 +282,7 @@ struct be_adapter {
int link_speed;
u8 port_type;
u8 transceiver;
+ u8 autoneg;
u8 generation; /* BladeEngine ASIC generation */
u32 flash_status;
struct completion flash_compl;
diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
index 65e3260..344e062 100644
--- a/drivers/net/benet/be_cmds.c
+++ b/drivers/net/benet/be_cmds.c
@@ -1695,3 +1695,38 @@ int be_cmd_get_seeprom_data(struct be_adapter *adapter,
spin_unlock_bh(&adapter->mcc_lock);
return status;
}
+
+int be_cmd_get_phy_info(struct be_adapter *adapter, struct be_dma_mem *cmd)
+{
+ struct be_mcc_wrb *wrb;
+ struct be_cmd_req_get_phy_info *req;
+ struct be_sge *sge;
+ int status;
+
+ spin_lock_bh(&adapter->mcc_lock);
+
+ wrb = wrb_from_mccq(adapter);
+ if (!wrb) {
+ status = -EBUSY;
+ goto err;
+ }
+
+ req = cmd->va;
+ sge = nonembedded_sgl(wrb);
+
+ be_wrb_hdr_prepare(wrb, sizeof(*req), false, 1,
+ OPCODE_COMMON_GET_PHY_DETAILS);
+
+ be_cmd_hdr_prepare(&req->hdr, CMD_SUBSYSTEM_COMMON,
+ OPCODE_COMMON_GET_PHY_DETAILS,
+ sizeof(*req));
+
+ sge->pa_hi = cpu_to_le32(upper_32_bits(cmd->dma));
+ sge->pa_lo = cpu_to_le32(cmd->dma & 0xFFFFFFFF);
+ sge->len = cpu_to_le32(cmd->size);
+
+ status = be_mcc_notify_wait(adapter);
+err:
+ spin_unlock_bh(&adapter->mcc_lock);
+ return status;
+}
diff --git a/drivers/net/benet/be_cmds.h b/drivers/net/benet/be_cmds.h
index 763dc19..912a058 100644
--- a/drivers/net/benet/be_cmds.h
+++ b/drivers/net/benet/be_cmds.h
@@ -144,6 +144,7 @@ struct be_mcc_mailbox {
#define OPCODE_COMMON_ENABLE_DISABLE_BEACON 69
#define OPCODE_COMMON_GET_BEACON_STATE 70
#define OPCODE_COMMON_READ_TRANSRECV_DATA 73
+#define OPCODE_COMMON_GET_PHY_DETAILS 102
#define OPCODE_ETH_ACPI_CONFIG 2
#define OPCODE_ETH_PROMISCUOUS 3
@@ -869,6 +870,30 @@ struct be_cmd_resp_seeprom_read {
u8 seeprom_data[BE_READ_SEEPROM_LEN];
};
+enum {
+ PHY_TYPE_CX4_10GB = 0,
+ PHY_TYPE_XFP_10GB,
+ PHY_TYPE_SFP_1GB,
+ PHY_TYPE_SFP_PLUS_10GB,
+ PHY_TYPE_KR_10GB,
+ PHY_TYPE_KX4_10GB,
+ PHY_TYPE_BASET_10GB,
+ PHY_TYPE_BASET_1GB,
+ PHY_TYPE_DISABLED = 255
+};
+
+struct be_cmd_req_get_phy_info {
+ struct be_cmd_req_hdr hdr;
+ u8 rsvd0[24];
+};
+struct be_cmd_resp_get_phy_info {
+ struct be_cmd_req_hdr hdr;
+ u16 phy_type;
+ u16 interface_type;
+ u32 misc_params;
+ u32 future_use[4];
+};
+
extern int be_pci_fnum_get(struct be_adapter *adapter);
extern int be_cmd_POST(struct be_adapter *adapter);
extern int be_cmd_mac_addr_query(struct be_adapter *adapter, u8 *mac_addr,
@@ -947,4 +972,6 @@ extern int be_cmd_get_seeprom_data(struct be_adapter *adapter,
struct be_dma_mem *nonemb_cmd);
extern int be_cmd_set_loopback(struct be_adapter *adapter, u8 port_num,
u8 loopback_type, u8 enable);
+extern int be_cmd_get_phy_info(struct be_adapter *adapter,
+ struct be_dma_mem *cmd);
diff --git a/drivers/net/benet/be_ethtool.c b/drivers/net/benet/be_ethtool.c
index 200e985..c0ade24 100644
--- a/drivers/net/benet/be_ethtool.c
+++ b/drivers/net/benet/be_ethtool.c
@@ -314,10 +314,13 @@ static int be_get_sset_count(struct net_device *netdev, int stringset)
static int be_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
{
struct be_adapter *adapter = netdev_priv(netdev);
- u8 mac_speed = 0, connector = 0;
+ struct be_dma_mem phy_cmd;
+ struct be_cmd_resp_get_phy_info *resp;
+ u8 mac_speed = 0;
u16 link_speed = 0;
bool link_up = false;
int status;
+ u16 intf_type;
if (adapter->link_speed < 0) {
status = be_cmd_link_status_query(adapter, &link_up,
@@ -337,40 +340,57 @@ static int be_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
}
}
- status = be_cmd_read_port_type(adapter, adapter->port_num,
- &connector);
+ phy_cmd.size = sizeof(struct be_cmd_req_get_phy_info);
+ phy_cmd.va = pci_alloc_consistent(adapter->pdev, phy_cmd.size,
+ &phy_cmd.dma);
+ if (!phy_cmd.va) {
+ dev_err(&adapter->pdev->dev, "Memory alloc failure\n");
+ return -ENOMEM;
+ }
+ status = be_cmd_get_phy_info(adapter, &phy_cmd);
if (!status) {
- switch (connector) {
- case 7:
+ resp = (struct be_cmd_resp_get_phy_info *) phy_cmd.va;
+ intf_type = le16_to_cpu(resp->interface_type);
+
+ switch (intf_type) {
+ case PHY_TYPE_XFP_10GB:
+ case PHY_TYPE_SFP_1GB:
+ case PHY_TYPE_SFP_PLUS_10GB:
ecmd->port = PORT_FIBRE;
- ecmd->transceiver = XCVR_EXTERNAL;
- break;
- case 0:
- ecmd->port = PORT_TP;
- ecmd->transceiver = XCVR_EXTERNAL;
break;
default:
ecmd->port = PORT_TP;
- ecmd->transceiver = XCVR_INTERNAL;
break;
}
- } else {
- ecmd->port = PORT_AUI;
+
+ switch (intf_type) {
+ case PHY_TYPE_KR_10GB:
+ case PHY_TYPE_KX4_10GB:
+ ecmd->autoneg = AUTONEG_ENABLE;
ecmd->transceiver = XCVR_INTERNAL;
+ break;
+ default:
+ ecmd->autoneg = AUTONEG_DISABLE;
+ ecmd->transceiver = XCVR_EXTERNAL;
+ break;
+ }
}
/* Save for future use */
adapter->link_speed = ecmd->speed;
adapter->port_type = ecmd->port;
adapter->transceiver = ecmd->transceiver;
+ adapter->autoneg = ecmd->autoneg;
+ pci_free_consistent(adapter->pdev, phy_cmd.size,
+ phy_cmd.va, phy_cmd.dma);
} else {
ecmd->speed = adapter->link_speed;
ecmd->port = adapter->port_type;
ecmd->transceiver = adapter->transceiver;
+ ecmd->autoneg = adapter->autoneg;
}
ecmd->duplex = DUPLEX_FULL;
- ecmd->autoneg = AUTONEG_DISABLE;
ecmd->phy_address = adapter->port_num;
switch (ecmd->port) {
case PORT_FIBRE:
@@ -384,6 +404,13 @@ static int be_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
break;
}
+ if (ecmd->autoneg) {
+ ecmd->supported |= SUPPORTED_1000baseT_Full;
+ ecmd->supported |= SUPPORTED_Autoneg;
+ ecmd->advertising |= (ADVERTISED_10000baseT_Full |
+ ADVERTISED_1000baseT_Full);
+ }
+
return 0;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH repost] sched: export sched_set/getaffinity to modules
From: Michael S. Tsirkin @ 2010-07-01 13:39 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Sridhar Samudrala, Tejun Heo, Oleg Nesterov, netdev,
lkml, kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev,
Jiri Kosina, Thomas Gleixner, Andi Kleen
In-Reply-To: <1277991024.1917.108.camel@laptop>
On Thu, Jul 01, 2010 at 03:30:24PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-07-01 at 16:08 +0300, Michael S. Tsirkin wrote:
> > On Thu, Jul 01, 2010 at 02:46:35PM +0200, Peter Zijlstra wrote:
> > > On Thu, 2010-07-01 at 14:34 +0200, Peter Zijlstra wrote:
> > > > On Thu, 2010-07-01 at 15:23 +0300, Michael S. Tsirkin wrote:
> > > > >
> > > > > The patch using this is here:
> > > > > http://www.mail-archive.com/kvm@vger.kernel.org/msg35411.html
> > > > >
> > > > > It simply copies the affinity from the parent when thread is created.
> > > >
> > > > Sounds like policy, not something the kernel should do..
> > >
> > > The alternative would be using clone() instead of thread_create() and
> > > inherit everything from the creating task.
> > > Inheriting from kthreadd and then undoing some aspects just sounds
> > > like daft policy that really ought to be in userspace.
> >
> > Yes, that's basically what this patchset is trying to do:
> > create a workqueue inheriting everything from the creating task.
> > Sridhar started with an API to do exactly this:
> > http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-05/msg07478.html
> >
> > Then we switched to raw kthread to avoid stepping on cwq toes.
> > Maybe it makes sense to add kthread_clone (in addition to
> > kthread_create) that would do what you suggest?
> > If yes, any hints on an implementation?
>
> I think that's called kernel_thread() see
> kernel/kthread.c:create_kthread().
>
> Doing the whole kthreadd dance and then copying bits and pieces back
> sounds very fragile, so yeah, something like that should work.
Thanks!
Sridhar, Tejun, have the time to look into this approach?
> The other issue to consider is the thread group status of these things,
> I think it would be best if these threads were still considered part of
> the process that spawned them so that they would die nicely when the
> process gets whacked.
The proposed patch kills the thread when the fd is closed,
so I think this already works without making it part of the process.
> At which point one could wonder if the kthread interface makes any
> sense, why not let userspace fork tasks and let them call into the
> kernel to perform work...
One thing I wanted to avoid is letting userspace know
just how many threads are there. We are using a single one
now, but we used to have threads per-cpu, and we might
switch to a thread per virtqueue in the future.
IMO all this should ideally be transparent to userspace.
--
MST
^ permalink raw reply
* ::::::APPLY FOR A LOAN:::::
From: Private Fund Loan Inc @ 2010-07-01 13:42 UTC (permalink / raw)
To: inq
We offer loan at cheap rate, they say opprtunity does not knock twice.
But with our loan firm, you can get the cheapest loan at a low
percentage rate of 2% yearly from $5,000.00 Min. To $100 000 000.00 Max.
Contact us via email if you are interested with the following details
NAME:
PHONE:
LOAN DURATION:
ADDRESS:
AMOUNT:
Private Fund Loan Inc
+60102950738
^ permalink raw reply
* Re: [PATCH repost] sched: export sched_set/getaffinity to modules
From: Peter Zijlstra @ 2010-07-01 13:30 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Ingo Molnar, Sridhar Samudrala, Tejun Heo, Oleg Nesterov, netdev,
lkml, kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev,
Jiri Kosina, Thomas Gleixner, Andi Kleen
In-Reply-To: <20100701130816.GB32223@redhat.com>
On Thu, 2010-07-01 at 16:08 +0300, Michael S. Tsirkin wrote:
> On Thu, Jul 01, 2010 at 02:46:35PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-07-01 at 14:34 +0200, Peter Zijlstra wrote:
> > > On Thu, 2010-07-01 at 15:23 +0300, Michael S. Tsirkin wrote:
> > > >
> > > > The patch using this is here:
> > > > http://www.mail-archive.com/kvm@vger.kernel.org/msg35411.html
> > > >
> > > > It simply copies the affinity from the parent when thread is created.
> > >
> > > Sounds like policy, not something the kernel should do..
> >
> > The alternative would be using clone() instead of thread_create() and
> > inherit everything from the creating task.
> > Inheriting from kthreadd and then undoing some aspects just sounds
> > like daft policy that really ought to be in userspace.
>
> Yes, that's basically what this patchset is trying to do:
> create a workqueue inheriting everything from the creating task.
> Sridhar started with an API to do exactly this:
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-05/msg07478.html
>
> Then we switched to raw kthread to avoid stepping on cwq toes.
> Maybe it makes sense to add kthread_clone (in addition to
> kthread_create) that would do what you suggest?
> If yes, any hints on an implementation?
I think that's called kernel_thread() see
kernel/kthread.c:create_kthread().
Doing the whole kthreadd dance and then copying bits and pieces back
sounds very fragile, so yeah, something like that should work.
The other issue to consider is the thread group status of these things,
I think it would be best if these threads were still considered part of
the process that spawned them so that they would die nicely when the
process gets whacked.
At which point one could wonder if the kthread interface makes any
sense, why not let userspace fork tasks and let them call into the
kernel to perform work...
^ permalink raw reply
* Re: [PATCH repost] sched: export sched_set/getaffinity to modules
From: Michael S. Tsirkin @ 2010-07-01 13:22 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Sridhar Samudrala, Tejun Heo, Oleg Nesterov, netdev,
lkml, kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev,
Jiri Kosina, Thomas Gleixner, Andi Kleen
In-Reply-To: <1277989646.1917.77.camel@laptop>
On Thu, Jul 01, 2010 at 03:07:26PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-07-01 at 15:50 +0300, Michael S. Tsirkin wrote:
> > On Thu, Jul 01, 2010 at 02:32:43PM +0200, Peter Zijlstra wrote:
> > > On Thu, 2010-07-01 at 14:55 +0300, Michael S. Tsirkin wrote:
> > >
> > > > > - why can't it set the kernel thread's affinity too?
> > > >
> > > > It can. However: the threads are started internally by the driver
> > > > when qemu does an ioctl. What we want to do is give it a sensible
> > > > default affinity. management tool can later tweak it if it wants to.
> > >
> > > So have that ioctl return the tid of that new fancy thread and then set
> > > its affinity, stuff it in cgroup, whatever you fancy.
> > >
> > > > > - what happens if someone changes the tasks' affinity?
> > > >
> > > > We would normally create a cgroup including all internal
> > > > tasks, making it easy to find and change affinity for
> > > > them all if necessary.
> > >
> > > And to stuff them in a cgroup you also need the tid, at which point it
> > > might as well set the affinity from userspace, right?
> >
> > We also put it in a cgroup transparently. I think that it's actually
> > important to do it on thread creation: if we don't, malicious userspace
> > can create large amount of work exceeding the cgroup limits.
> >
> > And the same applies so the affinity, right? If the qemu process
> > is limited to a set of CPUs, isn't it important to make
> > the kernel thread that does work our behalf limited to the same
> > set of CPUs?
>
> I'm not sure we have anything like this, but I wouldn't think so, if a
> driver creates a kthread and manages to inject tons of work its not
> typically limited to whatever limits apply to the task that supplied the
> work.
>
> Take the encryption threads for example, those don't run in the context
> of whoever provides the data to be encrypted (file,net whatever) and
> thus the task responsible could consume heaps more resources than when
> it would have to do the encryption itself.
>
> That's how kthreads work.
Right. And IMHO ideally all such work would run on the appropriate
CPU and be accounted to. It's just that with virt people seem to
run untrusted applications and expect the damage to be contained.
So we came up with a simple approach that seems to do the
just just for us.
--
MST
^ permalink raw reply
* Re: [PATCH repost] sched: export sched_set/getaffinity to modules
From: Michael S. Tsirkin @ 2010-07-01 13:08 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Sridhar Samudrala, Tejun Heo, Oleg Nesterov, netdev,
lkml, kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev,
Jiri Kosina, Thomas Gleixner, Andi Kleen
In-Reply-To: <1277988395.1917.47.camel@laptop>
On Thu, Jul 01, 2010 at 02:46:35PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-07-01 at 14:34 +0200, Peter Zijlstra wrote:
> > On Thu, 2010-07-01 at 15:23 +0300, Michael S. Tsirkin wrote:
> > >
> > > The patch using this is here:
> > > http://www.mail-archive.com/kvm@vger.kernel.org/msg35411.html
> > >
> > > It simply copies the affinity from the parent when thread is created.
> >
> > Sounds like policy, not something the kernel should do..
>
> The alternative would be using clone() instead of thread_create() and
> inherit everything from the creating task.
> Inheriting from kthreadd and then undoing some aspects just sounds
> like daft policy that really ought to be in userspace.
Yes, that's basically what this patchset is trying to do:
create a workqueue inheriting everything from the creating task.
Sridhar started with an API to do exactly this:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-05/msg07478.html
Then we switched to raw kthread to avoid stepping on cwq toes.
Maybe it makes sense to add kthread_clone (in addition to
kthread_create) that would do what you suggest?
If yes, any hints on an implementation?
--
MST
^ permalink raw reply
* Re: [PATCH repost] sched: export sched_set/getaffinity to modules
From: Peter Zijlstra @ 2010-07-01 13:07 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Ingo Molnar, Sridhar Samudrala, Tejun Heo, Oleg Nesterov, netdev,
lkml, kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev,
Jiri Kosina, Thomas Gleixner, Andi Kleen
In-Reply-To: <20100701125038.GA32223@redhat.com>
On Thu, 2010-07-01 at 15:50 +0300, Michael S. Tsirkin wrote:
> On Thu, Jul 01, 2010 at 02:32:43PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-07-01 at 14:55 +0300, Michael S. Tsirkin wrote:
> >
> > > > - why can't it set the kernel thread's affinity too?
> > >
> > > It can. However: the threads are started internally by the driver
> > > when qemu does an ioctl. What we want to do is give it a sensible
> > > default affinity. management tool can later tweak it if it wants to.
> >
> > So have that ioctl return the tid of that new fancy thread and then set
> > its affinity, stuff it in cgroup, whatever you fancy.
> >
> > > > - what happens if someone changes the tasks' affinity?
> > >
> > > We would normally create a cgroup including all internal
> > > tasks, making it easy to find and change affinity for
> > > them all if necessary.
> >
> > And to stuff them in a cgroup you also need the tid, at which point it
> > might as well set the affinity from userspace, right?
>
> We also put it in a cgroup transparently. I think that it's actually
> important to do it on thread creation: if we don't, malicious userspace
> can create large amount of work exceeding the cgroup limits.
>
> And the same applies so the affinity, right? If the qemu process
> is limited to a set of CPUs, isn't it important to make
> the kernel thread that does work our behalf limited to the same
> set of CPUs?
I'm not sure we have anything like this, but I wouldn't think so, if a
driver creates a kthread and manages to inject tons of work its not
typically limited to whatever limits apply to the task that supplied the
work.
Take the encryption threads for example, those don't run in the context
of whoever provides the data to be encrypted (file,net whatever) and
thus the task responsible could consume heaps more resources than when
it would have to do the encryption itself.
That's how kthreads work.
^ permalink raw reply
* [PATCH 2/2] qlge: fix a eeh handler to not add a pending timer
From: leitao @ 2010-07-01 13:00 UTC (permalink / raw)
To: davem; +Cc: netdev, Breno Leitao, Ron Mercer
In-Reply-To: <e687077281d05d3a2da49431b7c0ff0b1076f3e6.1277936929.git.root@sanx1002.austin.ibm.com>
On some ocasions the function qlge_io_resume() tries to add a
pending timer, which causes the system to hit the BUG() on
add_timer() function.
This patch removes the timer during the EEH recovery.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
---
drivers/net/qlge/qlge_main.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/qlge/qlge_main.c b/drivers/net/qlge/qlge_main.c
index 509dadc..d10bcef 100644
--- a/drivers/net/qlge/qlge_main.c
+++ b/drivers/net/qlge/qlge_main.c
@@ -4712,6 +4712,8 @@ static void ql_eeh_close(struct net_device *ndev)
netif_stop_queue(ndev);
}
+ /* Disabling the timer */
+ del_timer_sync(&qdev->timer);
if (test_bit(QL_ADAPTER_UP, &qdev->flags))
cancel_delayed_work_sync(&qdev->asic_reset_work);
cancel_delayed_work_sync(&qdev->mpi_reset_work);
--
1.6.5.2
^ permalink raw reply related
* [PATCH 1/2] qlge: Replacing add_timer() to mod_timer()
From: leitao @ 2010-07-01 13:00 UTC (permalink / raw)
To: davem; +Cc: netdev, Breno Leitao, Ron Mercer
Currently qlge driver calls add_timer() instead of mod_timer().
This patch changes add_timer() to mod_timer(), which seems a better
solution.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
---
drivers/net/qlge/qlge_main.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/qlge/qlge_main.c b/drivers/net/qlge/qlge_main.c
index fa4b24c..509dadc 100644
--- a/drivers/net/qlge/qlge_main.c
+++ b/drivers/net/qlge/qlge_main.c
@@ -4611,8 +4611,7 @@ static void ql_timer(unsigned long data)
return;
}
- qdev->timer.expires = jiffies + (5*HZ);
- add_timer(&qdev->timer);
+ mod_timer(&qdev->timer, jiffies + (5*HZ));
}
static int __devinit qlge_probe(struct pci_dev *pdev,
@@ -4808,8 +4807,7 @@ static void qlge_io_resume(struct pci_dev *pdev)
netif_err(qdev, ifup, qdev->ndev,
"Device was not running prior to EEH.\n");
}
- qdev->timer.expires = jiffies + (5*HZ);
- add_timer(&qdev->timer);
+ mod_timer(&qdev->timer, jiffies + (5*HZ));
netif_device_attach(ndev);
}
@@ -4871,8 +4869,7 @@ static int qlge_resume(struct pci_dev *pdev)
return err;
}
- qdev->timer.expires = jiffies + (5*HZ);
- add_timer(&qdev->timer);
+ mod_timer(&qdev->timer, jiffies + (5*HZ));
netif_device_attach(ndev);
return 0;
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH repost] sched: export sched_set/getaffinity to modules
From: Michael S. Tsirkin @ 2010-07-01 12:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Sridhar Samudrala, Tejun Heo, Oleg Nesterov, netdev,
lkml, kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev,
Jiri Kosina, Thomas Gleixner, Andi Kleen
In-Reply-To: <1277987563.1917.28.camel@laptop>
On Thu, Jul 01, 2010 at 02:32:43PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-07-01 at 14:55 +0300, Michael S. Tsirkin wrote:
>
> > > - why can't it set the kernel thread's affinity too?
> >
> > It can. However: the threads are started internally by the driver
> > when qemu does an ioctl. What we want to do is give it a sensible
> > default affinity. management tool can later tweak it if it wants to.
>
> So have that ioctl return the tid of that new fancy thread and then set
> its affinity, stuff it in cgroup, whatever you fancy.
>
> > > - what happens if someone changes the tasks' affinity?
> >
> > We would normally create a cgroup including all internal
> > tasks, making it easy to find and change affinity for
> > them all if necessary.
>
> And to stuff them in a cgroup you also need the tid, at which point it
> might as well set the affinity from userspace, right?
We also put it in a cgroup transparently. I think that it's actually
important to do it on thread creation: if we don't, malicious userspace
can create large amount of work exceeding the cgroup limits.
And the same applies so the affinity, right? If the qemu process
is limited to a set of CPUs, isn't it important to make
the kernel thread that does work our behalf limited to the same
set of CPUs?
--
MST
^ permalink raw reply
* Re: [PATCH repost] sched: export sched_set/getaffinity to modules
From: Peter Zijlstra @ 2010-07-01 12:46 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Ingo Molnar, Sridhar Samudrala, Tejun Heo, Oleg Nesterov, netdev,
lkml, kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev,
Jiri Kosina, Thomas Gleixner, Andi Kleen
In-Reply-To: <1277987657.1917.32.camel@laptop>
On Thu, 2010-07-01 at 14:34 +0200, Peter Zijlstra wrote:
> On Thu, 2010-07-01 at 15:23 +0300, Michael S. Tsirkin wrote:
> >
> > The patch using this is here:
> > http://www.mail-archive.com/kvm@vger.kernel.org/msg35411.html
> >
> > It simply copies the affinity from the parent when thread is created.
>
> Sounds like policy, not something the kernel should do..
The alternative would be using clone() instead of thread_create() and
inherit everything from the creating task. Inheriting from kthreadd and
then undoing some aspects just sounds like daft policy that really ought
to be in userspace.
^ 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