* Re: [PATCH 00/09] net: remove trailing spaces in messages
From: David Miller @ 2010-03-24 21:11 UTC (permalink / raw)
To: elendil
Cc: netdev, linux-kernel, per.liden, jon.maloy, allan.stephens,
samuel, benh, linuxppc-dev, e1000-devel
In-Reply-To: <201003241840.18701.elendil@planet.nl>
From: Frans Pop <elendil@planet.nl>
Date: Wed, 24 Mar 2010 18:40:15 +0100
> This is the second patchset to remove trailing spaces in kernel messages.
> Patches in this set cover networking code, excepting wireless which will be
> submitted in a separate set.
>
> Patches have been rebased against current net-next.
>
> Benefits are:
> - general cleanup and consistency
> - minor reduction in kernel size and user's log file size
> - reduced annoyance for people writing logcheck rules
>
> I have run the patches through checkpatch and included some fixes, but in
> most cases the files are so horrible in general that fixing the warnings
> purely for these changes doesn't make sense.
All applied, but I have to make some fixups.
For example, GIT warns about trailing whitespace on any lines that you
touched so I had to fix those up before putting them into the tree.
Thanks.
^ permalink raw reply
* Re: [PATCH 00/07] net: remove trailing spaces in messages
From: David Miller @ 2010-03-24 21:12 UTC (permalink / raw)
To: elendil
Cc: netdev, linux-kernel, linux-wireless, lrodriguez, yi.zhu,
reinette.chatre, ilw, mcgrof, coreythomas, libertas-dev
In-Reply-To: <201003241927.12434.elendil@planet.nl>
From: Frans Pop <elendil@planet.nl>
Date: Wed, 24 Mar 2010 19:27:09 +0100
> This is the third patchset to remove trailing spaces in kernel messages.
> Patches in this set cover wireless code.
>
> Note that the last patch for libertas changes a debugfs header and not
> actually a message.
>
> Patches have been rebased against current net-next.
John, please suck these in :-)
^ permalink raw reply
* Re: [PATCH 4/7 v2] wireless/iwlwifi: remove trailing space in messages
From: Frans Pop @ 2010-03-24 21:19 UTC (permalink / raw)
To: linux-wireless
Cc: netdev, linux-kernel, Zhu Yi, Reinette Chatre,
Intel Linux Wireless
In-Reply-To: <1269456395-15343-4-git-send-email-elendil@planet.nl>
Includes minor improvements in debugging messages in iwl-4965.c,
function iwl4965_is_temp_calib_needed().
Signed-off-by: Frans Pop <elendil@planet.nl>
Cc: Zhu Yi <yi.zhu@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>
Cc: Intel Linux Wireless <ilw@linux.intel.com>
---
Rebased against and updated for iwlwifi-2.6.git/master
as requested by Reinette.
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945-rs.c b/drivers/net/wireless/iwlwifi/iwl-3945-rs.c
index 605aca4..9e411dc 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-3945-rs.c
@@ -341,7 +341,7 @@ void iwl3945_rs_rate_init(struct iwl_priv *priv, struct ieee80211_sta *sta, u8 s
struct ieee80211_supported_band *sband;
int i;
- IWL_DEBUG_INFO(priv, "enter \n");
+ IWL_DEBUG_INFO(priv, "enter\n");
if (sta_id == priv->hw_params.bcast_sta_id)
goto out;
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.c b/drivers/net/wireless/iwlwifi/iwl-3945.c
index 6d5e170..175709e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945.c
+++ b/drivers/net/wireless/iwlwifi/iwl-3945.c
@@ -486,7 +486,7 @@ static void _iwl3945_dbg_report_frame(struct iwl_priv *priv,
* but you can hack it to show more, if you'd like to. */
if (dataframe)
IWL_DEBUG_RX(priv, "%s: mhd=0x%04x, dst=0x%02x, "
- "len=%u, rssi=%d, chnl=%d, rate=%d, \n",
+ "len=%u, rssi=%d, chnl=%d, rate=%d,\n",
title, le16_to_cpu(fc), header->addr1[5],
length, rssi, channel, rate);
else {
@@ -1023,7 +1023,7 @@ static void iwl3945_nic_config(struct iwl_priv *priv)
IWL_DEBUG_INFO(priv, "HW Revision ID = 0x%X\n", rev_id);
if (rev_id & PCI_CFG_REV_ID_BIT_RTP)
- IWL_DEBUG_INFO(priv, "RTP type \n");
+ IWL_DEBUG_INFO(priv, "RTP type\n");
else if (rev_id & PCI_CFG_REV_ID_BIT_BASIC_SKU) {
IWL_DEBUG_INFO(priv, "3945 RADIO-MB type\n");
iwl_set_bit(priv, CSR_HW_IF_CONFIG_REG,
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c
index aea5519..b4978e5 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965.c
+++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
@@ -410,7 +410,7 @@ static void iwl4965_gain_computation(struct iwl_priv *priv,
sizeof(cmd), &cmd);
if (ret)
IWL_DEBUG_CALIB(priv, "fail sending cmd "
- "REPLY_PHY_CALIBRATION_CMD \n");
+ "REPLY_PHY_CALIBRATION_CMD\n");
/* TODO we might want recalculate
* rx_chain in rxon cmd */
@@ -1612,19 +1612,19 @@ static int iwl4965_is_temp_calib_needed(struct iwl_priv *priv)
/* get absolute value */
if (temp_diff < 0) {
- IWL_DEBUG_POWER(priv, "Getting cooler, delta %d, \n", temp_diff);
+ IWL_DEBUG_POWER(priv, "Getting cooler, delta %d\n", temp_diff);
temp_diff = -temp_diff;
} else if (temp_diff == 0)
- IWL_DEBUG_POWER(priv, "Same temp, \n");
+ IWL_DEBUG_POWER(priv, "Temperature unchanged\n");
else
- IWL_DEBUG_POWER(priv, "Getting warmer, delta %d, \n", temp_diff);
+ IWL_DEBUG_POWER(priv, "Getting warmer, delta %d\n", temp_diff);
if (temp_diff < IWL_TEMPERATURE_THRESHOLD) {
- IWL_DEBUG_POWER(priv, "Thermal txpower calib not needed\n");
+ IWL_DEBUG_POWER(priv, " => thermal txpower calib not needed\n");
return 0;
}
- IWL_DEBUG_POWER(priv, "Thermal txpower calib needed\n");
+ IWL_DEBUG_POWER(priv, " => thermal txpower calib needed\n");
return 1;
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
index 623aa71..d13fb8d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
@@ -854,7 +854,7 @@ static void iwlagn_dbg_report_frame(struct iwl_priv *priv,
* but you can hack it to show more, if you'd like to. */
if (dataframe)
IWL_DEBUG_RX(priv, "%s: mhd=0x%04x, dst=0x%02x, "
- "len=%u, rssi=%d, chnl=%d, rate=%u, \n",
+ "len=%u, rssi=%d, chnl=%d, rate=%u,\n",
title, le16_to_cpu(fc), header->addr1[5],
length, rssi, channel, bitrate);
else {
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
index 06b8792..0c3c768 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
@@ -2002,7 +2002,7 @@ static void rs_rate_scale_perform(struct iwl_priv *priv,
/* rates available for this association, and for modulation mode */
rate_mask = rs_get_supported_rates(lq_sta, hdr, tbl->lq_type);
- IWL_DEBUG_RATE(priv, "mask 0x%04X \n", rate_mask);
+ IWL_DEBUG_RATE(priv, "mask 0x%04X\n", rate_mask);
/* mask with station rate restriction */
if (is_legacy(tbl->lq_type)) {
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-tx.c b/drivers/net/wireless/iwlwifi/iwl-agn-tx.c
index c14e2bf..94aab6a 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-tx.c
@@ -723,9 +723,9 @@ int iwlagn_tx_skb(struct iwl_priv *priv, struct sk_buff *skb)
tx_cmd->dram_lsb_ptr = cpu_to_le32(scratch_phys);
tx_cmd->dram_msb_ptr = iwl_get_dma_hi_addr(scratch_phys);
- IWL_DEBUG_TX(priv, "sequence nr = 0X%x \n",
+ IWL_DEBUG_TX(priv, "sequence nr = 0X%x\n",
le16_to_cpu(out_cmd->hdr.sequence));
- IWL_DEBUG_TX(priv, "tx_flags = 0X%x \n", le32_to_cpu(tx_cmd->tx_flags));
+ IWL_DEBUG_TX(priv, "tx_flags = 0X%x\n", le32_to_cpu(tx_cmd->tx_flags));
iwl_print_hex_dump(priv, IWL_DL_TX, (u8 *)tx_cmd, sizeof(*tx_cmd));
iwl_print_hex_dump(priv, IWL_DL_TX, (u8 *)tx_cmd->hdr, hdr_len);
@@ -1308,7 +1308,7 @@ void iwlagn_rx_reply_compressed_ba(struct iwl_priv *priv,
(unsigned long long)le64_to_cpu(ba_resp->bitmap),
ba_resp->scd_flow,
ba_resp->scd_ssn);
- IWL_DEBUG_TX_REPLY(priv, "DAT start_idx = %d, bitmap = 0x%llx \n",
+ IWL_DEBUG_TX_REPLY(priv, "DAT start_idx = %d, bitmap = 0x%llx\n",
agg->start_idx,
(unsigned long long)agg->bitmap);
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index 6aec77f..1629b4d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -181,7 +181,7 @@ int iwl_commit_rxon(struct iwl_priv *priv)
IWL_ERR(priv, "Error setting new RXON (%d)\n", ret);
return ret;
}
- IWL_DEBUG_INFO(priv, "Return from !new_assoc RXON. \n");
+ IWL_DEBUG_INFO(priv, "Return from !new_assoc RXON.\n");
memcpy(active_rxon, &priv->staging_rxon, sizeof(*active_rxon));
iwl_clear_ucode_stations(priv, false);
iwl_restore_stations(priv);
@@ -2310,7 +2310,7 @@ static int iwl_prepare_card_hw(struct iwl_priv *priv)
{
int ret = 0;
- IWL_DEBUG_INFO(priv, "iwl_prepare_card_hw enter \n");
+ IWL_DEBUG_INFO(priv, "iwl_prepare_card_hw enter\n");
ret = iwl_set_hw_ready(priv);
if (priv->hw_ready)
@@ -3084,7 +3084,7 @@ static int iwlagn_mac_sta_add(struct ieee80211_hw *hw,
iwl_restore_wepkeys(priv);
/* Initialize rate scaling */
- IWL_DEBUG_INFO(priv, "Initializing rate scaling for station %pM \n",
+ IWL_DEBUG_INFO(priv, "Initializing rate scaling for station %pM\n",
sta->addr);
iwl_rs_rate_init(priv, sta, sta_id);
diff --git a/drivers/net/wireless/iwlwifi/iwl-calib.c b/drivers/net/wireless/iwlwifi/iwl-calib.c
index 845831a..dbb50a8 100644
--- a/drivers/net/wireless/iwlwifi/iwl-calib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-calib.c
@@ -592,7 +592,7 @@ void iwl_sensitivity_calibration(struct iwl_priv *priv,
IWL_DEBUG_CALIB(priv, "rx_enable_time = %u usecs\n", rx_enable_time);
if (!rx_enable_time) {
- IWL_DEBUG_CALIB(priv, "<< RX Enable Time == 0! \n");
+ IWL_DEBUG_CALIB(priv, "<< RX Enable Time == 0!\n");
return;
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 1b4408a..3c8ec6e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -348,7 +348,7 @@ void iwl_reset_qos(struct iwl_priv *priv)
priv->qos_data.def_qos_parm.ac[i].reserved1 = 0;
}
}
- IWL_DEBUG_QOS(priv, "set QoS to default \n");
+ IWL_DEBUG_QOS(priv, "set QoS to default\n");
spin_unlock_irqrestore(&priv->lock, flags);
}
@@ -1914,7 +1914,7 @@ static void iwl_ht_conf(struct iwl_priv *priv,
struct iwl_ht_config *ht_conf = &priv->current_ht_config;
struct ieee80211_sta *sta;
- IWL_DEBUG_MAC80211(priv, "enter: \n");
+ IWL_DEBUG_MAC80211(priv, "enter:\n");
if (!ht_conf->is_ht)
return;
@@ -2475,7 +2475,7 @@ int iwl_alloc_txq_mem(struct iwl_priv *priv)
sizeof(struct iwl_tx_queue) * priv->cfg->num_of_queues,
GFP_KERNEL);
if (!priv->txq) {
- IWL_ERR(priv, "Not enough memory for txq \n");
+ IWL_ERR(priv, "Not enough memory for txq\n");
return -ENOMEM;
}
return 0;
diff --git a/drivers/net/wireless/iwlwifi/iwl-hcmd.c b/drivers/net/wireless/iwlwifi/iwl-hcmd.c
index 73681c4..51f89e7 100644
--- a/drivers/net/wireless/iwlwifi/iwl-hcmd.c
+++ b/drivers/net/wireless/iwlwifi/iwl-hcmd.c
@@ -169,7 +169,7 @@ int iwl_send_cmd_sync(struct iwl_priv *priv, struct iwl_host_cmd *cmd)
mutex_lock(&priv->sync_cmd_mutex);
set_bit(STATUS_HCMD_ACTIVE, &priv->status);
- IWL_DEBUG_INFO(priv, "Setting HCMD_ACTIVE for command %s \n",
+ IWL_DEBUG_INFO(priv, "Setting HCMD_ACTIVE for command %s\n",
get_cmd_string(cmd->id));
cmd_idx = iwl_enqueue_hcmd(priv, cmd);
@@ -191,7 +191,7 @@ int iwl_send_cmd_sync(struct iwl_priv *priv, struct iwl_host_cmd *cmd)
jiffies_to_msecs(HOST_COMPLETE_TIMEOUT));
clear_bit(STATUS_HCMD_ACTIVE, &priv->status);
- IWL_DEBUG_INFO(priv, "Clearing HCMD_ACTIVE for command %s \n",
+ IWL_DEBUG_INFO(priv, "Clearing HCMD_ACTIVE for command %s\n",
get_cmd_string(cmd->id));
ret = -ETIMEDOUT;
goto cancel;
diff --git a/drivers/net/wireless/iwlwifi/iwl-io.h b/drivers/net/wireless/iwlwifi/iwl-io.h
index c719baf..4f54a5f 100644
--- a/drivers/net/wireless/iwlwifi/iwl-io.h
+++ b/drivers/net/wireless/iwlwifi/iwl-io.h
@@ -297,7 +297,7 @@ static inline u32 __iwl_read_direct32(const char *f, u32 l,
struct iwl_priv *priv, u32 reg)
{
u32 value = _iwl_read_direct32(priv, reg);
- IWL_DEBUG_IO(priv, "read_direct32(0x%4X) = 0x%08x - %s %d \n", reg, value,
+ IWL_DEBUG_IO(priv, "read_direct32(0x%4X) = 0x%08x - %s %d\n", reg, value,
f, l);
return value;
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-power.c b/drivers/net/wireless/iwlwifi/iwl-power.c
index e0581a7..2655dbd 100644
--- a/drivers/net/wireless/iwlwifi/iwl-power.c
+++ b/drivers/net/wireless/iwlwifi/iwl-power.c
@@ -874,7 +874,7 @@ void iwl_tt_initialize(struct iwl_priv *priv)
int size = sizeof(struct iwl_tt_trans) * (IWL_TI_STATE_MAX - 1);
struct iwl_tt_trans *transaction;
- IWL_DEBUG_POWER(priv, "Initialize Thermal Throttling \n");
+ IWL_DEBUG_POWER(priv, "Initialize Thermal Throttling\n");
memset(tt, 0, sizeof(struct iwl_tt_mgmt));
diff --git a/drivers/net/wireless/iwlwifi/iwl-scan.c b/drivers/net/wireless/iwlwifi/iwl-scan.c
index 79ce8e5..d817c9c 100644
--- a/drivers/net/wireless/iwlwifi/iwl-scan.c
+++ b/drivers/net/wireless/iwlwifi/iwl-scan.c
@@ -453,7 +453,7 @@ static int iwl_get_channels_for_scan(struct iwl_priv *priv,
added++;
}
- IWL_DEBUG_SCAN(priv, "total channels to scan %d \n", added);
+ IWL_DEBUG_SCAN(priv, "total channels to scan %d\n", added);
return added;
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-sta.c b/drivers/net/wireless/iwlwifi/iwl-sta.c
index 531d0e4..b38a055 100644
--- a/drivers/net/wireless/iwlwifi/iwl-sta.c
+++ b/drivers/net/wireless/iwlwifi/iwl-sta.c
@@ -71,7 +71,7 @@ u8 iwl_find_station(struct iwl_priv *priv, const u8 *addr)
(!(priv->stations[ret].used & IWL_STA_UCODE_ACTIVE) ||
((priv->stations[ret].used & IWL_STA_UCODE_ACTIVE) &&
(priv->stations[ret].used & IWL_STA_UCODE_INPROGRESS)))) {
- IWL_ERR(priv, "Requested station info for sta %d before ready. \n",
+ IWL_ERR(priv, "Requested station info for sta %d before ready.\n",
ret);
ret = IWL_INVALID_STATION;
}
@@ -143,7 +143,7 @@ static void iwl_process_add_sta_resp(struct iwl_priv *priv,
sta_id);
break;
case ADD_STA_MODIFY_NON_EXIST_STA:
- IWL_ERR(priv, "Attempting to modify non-existing station %d \n",
+ IWL_ERR(priv, "Attempting to modify non-existing station %d\n",
sta_id);
break;
default:
@@ -574,7 +574,7 @@ static int iwl_remove_station(struct iwl_priv *priv, struct ieee80211_sta *sta)
if (!iwl_is_ready(priv)) {
IWL_DEBUG_INFO(priv,
- "Unable to remove station %pM, device not ready. \n",
+ "Unable to remove station %pM, device not ready.\n",
sta->addr);
/*
* It is typical for stations to be removed when we are
@@ -671,7 +671,7 @@ void iwl_clear_ucode_stations(struct iwl_priv *priv, bool force)
} else {
for (i = 0; i < priv->hw_params.max_stations; i++) {
if (priv->stations[i].used & IWL_STA_UCODE_ACTIVE) {
- IWL_DEBUG_INFO(priv, "Clearing ucode active for station %d \n", i);
+ IWL_DEBUG_INFO(priv, "Clearing ucode active for station %d\n", i);
priv->stations[i].used &= ~IWL_STA_UCODE_ACTIVE;
cleared = true;
}
@@ -1108,7 +1108,7 @@ int iwl_remove_dynamic_key(struct iwl_priv *priv,
priv->stations[sta_id].sta.mode = STA_CONTROL_MODIFY_MSK;
if (iwl_is_rfkill(priv)) {
- IWL_DEBUG_WEP(priv, "Not sending REPLY_ADD_STA command because RFKILL enabled. \n");
+ IWL_DEBUG_WEP(priv, "Not sending REPLY_ADD_STA command because RFKILL enabled.\n");
spin_unlock_irqrestore(&priv->sta_lock, flags);
return 0;
}
@@ -1210,7 +1210,7 @@ int iwl_send_lq_cmd(struct iwl_priv *priv,
return ret;
if (init) {
- IWL_DEBUG_INFO(priv, "init LQ command complete, clearing sta addition status for sta %d \n",
+ IWL_DEBUG_INFO(priv, "init LQ command complete, clearing sta addition status for sta %d\n",
lq->sta_id);
spin_lock_irqsave(&priv->sta_lock, flags_spin);
priv->stations[lq->sta_id].used &= ~IWL_STA_UCODE_INPROGRESS;
diff --git a/drivers/net/wireless/iwlwifi/iwl-tx.c b/drivers/net/wireless/iwlwifi/iwl-tx.c
index 0ea881a..4f8f448 100644
--- a/drivers/net/wireless/iwlwifi/iwl-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c
@@ -640,7 +640,7 @@ void iwl_tx_cmd_complete(struct iwl_priv *priv, struct iwl_rx_mem_buffer *rxb)
if (!(meta->flags & CMD_ASYNC)) {
clear_bit(STATUS_HCMD_ACTIVE, &priv->status);
- IWL_DEBUG_INFO(priv, "Clearing HCMD_ACTIVE for command %s \n",
+ IWL_DEBUG_INFO(priv, "Clearing HCMD_ACTIVE for command %s\n",
get_cmd_string(cmd->hdr.cmd));
wake_up_interruptible(&priv->wait_command_queue);
}
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 76a6de9..c619f2a 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -597,9 +597,9 @@ static int iwl3945_tx_skb(struct iwl_priv *priv, struct sk_buff *skb)
txq->need_update = 0;
}
- IWL_DEBUG_TX(priv, "sequence nr = 0X%x \n",
+ IWL_DEBUG_TX(priv, "sequence nr = 0X%x\n",
le16_to_cpu(out_cmd->hdr.sequence));
- IWL_DEBUG_TX(priv, "tx_flags = 0X%x \n", le32_to_cpu(tx_cmd->tx_flags));
+ IWL_DEBUG_TX(priv, "tx_flags = 0X%x\n", le32_to_cpu(tx_cmd->tx_flags));
iwl_print_hex_dump(priv, IWL_DL_TX, tx_cmd, sizeof(*tx_cmd));
iwl_print_hex_dump(priv, IWL_DL_TX, (u8 *)tx_cmd->hdr,
ieee80211_hdrlen(fc));
@@ -1937,7 +1937,7 @@ static int iwl3945_get_channels_for_scan(struct iwl_priv *priv,
added++;
}
- IWL_DEBUG_SCAN(priv, "total channels to scan %d \n", added);
+ IWL_DEBUG_SCAN(priv, "total channels to scan %d\n", added);
return added;
}
@@ -3403,7 +3403,7 @@ static int iwl3945_mac_sta_add(struct ieee80211_hw *hw,
}
/* Initialize rate scaling */
- IWL_DEBUG_INFO(priv, "Initializing rate scaling for station %pM \n",
+ IWL_DEBUG_INFO(priv, "Initializing rate scaling for station %pM\n",
sta->addr);
iwl3945_rs_rate_init(priv, sta, sta_id);
^ permalink raw reply related
* Re: Seeing new kernel unaligned access messages in linux-next on ia64
From: Jan Engelhardt @ 2010-03-24 21:26 UTC (permalink / raw)
To: David Miller; +Cc: tony.luck, netdev
In-Reply-To: <20100324.102759.107122703.davem@davemloft.net>
Hi,
Tony Luck observes that the original IFLA_STATS64 submission causes
unaligned accesses. This is because nla_data() returns a pointer to a
memory region that is only aligned to 32 bits.
Using a temporary and memcpying it off would normally fix this,
as in the patch below. During testing however, I still get
unaligned messages even with the patch - and I would not know
what causes this. In fact, adding a printks magically fixes
it. (Bug in gcc-4.4-sparc compiler?)
memcpy(v, &a, sizeof(a));
+ printk(KERN_INFO "v=%p a=%p\n", v, &a);
origin git://dev.medozas.de/linux net
mode cherry-pick
parent 1c01fe14a87332cc88266fbd6e598319322eb96f (v2.6.34-rc1-1069-g1c01fe1)
commit 5480c9bb1b418bb09748340257dea1e57efeb18f
Author: Jan Engelhardt <jengelh@medozas.de>
Date: Wed Mar 24 19:52:43 2010 +0100
net: fix unaligned access in IFLA_STATS64
Tony Luck observes that the original IFLA_STATS64 submission causes
unaligned accesses. This is because nla_data() returns a pointer to a
memory region that is only aligned to 32 bits. Do some memcpying to
workaround this.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
net/core/rtnetlink.c | 53 +++++++++++++++++++++--------------------
1 files changed, 27 insertions(+), 26 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index e1121f0..473d4b1 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -602,36 +602,39 @@ static void copy_rtnl_link_stats(struct rtnl_link_stats *a,
a->tx_compressed = b->tx_compressed;
}
-static void copy_rtnl_link_stats64(struct rtnl_link_stats64 *a,
+static void copy_rtnl_link_stats64(struct rtnl_link_stats64 *v,
const struct net_device_stats *b)
{
- a->rx_packets = b->rx_packets;
- a->tx_packets = b->tx_packets;
- a->rx_bytes = b->rx_bytes;
- a->tx_bytes = b->tx_bytes;
- a->rx_errors = b->rx_errors;
- a->tx_errors = b->tx_errors;
- a->rx_dropped = b->rx_dropped;
- a->tx_dropped = b->tx_dropped;
-
- a->multicast = b->multicast;
- a->collisions = b->collisions;
-
- a->rx_length_errors = b->rx_length_errors;
- a->rx_over_errors = b->rx_over_errors;
- a->rx_crc_errors = b->rx_crc_errors;
- a->rx_frame_errors = b->rx_frame_errors;
- a->rx_fifo_errors = b->rx_fifo_errors;
- a->rx_missed_errors = b->rx_missed_errors;
-
- a->tx_aborted_errors = b->tx_aborted_errors;
- a->tx_carrier_errors = b->tx_carrier_errors;
- a->tx_fifo_errors = b->tx_fifo_errors;
- a->tx_heartbeat_errors = b->tx_heartbeat_errors;
- a->tx_window_errors = b->tx_window_errors;
-
- a->rx_compressed = b->rx_compressed;
- a->tx_compressed = b->tx_compressed;
+ struct rtnl_link_stats64 a;
+
+ a.rx_packets = b->rx_packets;
+ a.tx_packets = b->tx_packets;
+ a.rx_bytes = b->rx_bytes;
+ a.tx_bytes = b->tx_bytes;
+ a.rx_errors = b->rx_errors;
+ a.tx_errors = b->tx_errors;
+ a.rx_dropped = b->rx_dropped;
+ a.tx_dropped = b->tx_dropped;
+
+ a.multicast = b->multicast;
+ a.collisions = b->collisions;
+
+ a.rx_length_errors = b->rx_length_errors;
+ a.rx_over_errors = b->rx_over_errors;
+ a.rx_crc_errors = b->rx_crc_errors;
+ a.rx_frame_errors = b->rx_frame_errors;
+ a.rx_fifo_errors = b->rx_fifo_errors;
+ a.rx_missed_errors = b->rx_missed_errors;
+
+ a.tx_aborted_errors = b->tx_aborted_errors;
+ a.tx_carrier_errors = b->tx_carrier_errors;
+ a.tx_fifo_errors = b->tx_fifo_errors;
+ a.tx_heartbeat_errors = b->tx_heartbeat_errors;
+ a.tx_window_errors = b->tx_window_errors;
+
+ a.rx_compressed = b->rx_compressed;
+ a.tx_compressed = b->tx_compressed;
+ memcpy(v, &a, sizeof(a));
}
static inline int rtnl_vfinfo_size(const struct net_device *dev)
@@ -734,8 +737,6 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
sizeof(struct rtnl_link_stats64));
if (attr == NULL)
goto nla_put_failure;
-
- stats = dev_get_stats(dev);
copy_rtnl_link_stats64(nla_data(attr), stats);
if (dev->netdev_ops->ndo_get_vf_config && dev->dev.parent) {
--
# Created with git-export-patch
^ permalink raw reply related
* Re: [PATCH 00/09] net: remove trailing spaces in messages
From: Frans Pop @ 2010-03-24 21:30 UTC (permalink / raw)
To: David Miller
Cc: jon.maloy, samuel, e1000-devel, per.liden, netdev, linux-kernel,
linuxppc-dev, allan.stephens, benh
In-Reply-To: <20100324.141158.43422101.davem@davemloft.net>
On Wednesday 24 March 2010, David Miller wrote:
> All applied, but I have to make some fixups.
>
> For example, GIT warns about trailing whitespace on any lines that you
> touched so I had to fix those up before putting them into the tree.
I did wonder about fixing that or not. But as the surrounding code also has
tons of trailing whitespace, I chose to leave things consistently messy.
I'll remove at least trailing whitespace next time.
Thanks David.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
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 4/7 v2] wireless/iwlwifi: remove trailing space in messages
From: reinette chatre @ 2010-03-24 21:38 UTC (permalink / raw)
To: Frans Pop, John W. Linville
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Zhu, Yi,
Intel Linux Wireless
In-Reply-To: <201003242220.00328.elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
On Wed, 2010-03-24 at 14:19 -0700, Frans Pop wrote:
> Includes minor improvements in debugging messages in iwl-4965.c,
> function iwl4965_is_temp_calib_needed().
>
> Signed-off-by: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
> Cc: Zhu Yi <yi.zhu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Cc: Reinette Chatre <reinette.chatre-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Cc: Intel Linux Wireless <ilw-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> ---
>
> Rebased against and updated for iwlwifi-2.6.git/master
> as requested by Reinette.
>
John, I'll take this patch and submit it as part of our regular process.
Reinette
--
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: mmotm 2010-03-23 - IPv6 warnings...
From: Andrew Morton @ 2010-03-24 22:42 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: netdev, linux-kernel
In-Reply-To: <12096.1269481001@localhost>
On Wed, 24 Mar 2010 21:36:41 -0400 Valdis.Kletnieks@vt.edu wrote:
> On Tue, 23 Mar 2010 15:34:59 PDT, akpm@linux-foundation.org said:
> > The mm-of-the-moment snapshot 2010-03-23-15-34 has been uploaded to
> >
> > http://userweb.kernel.org/~akpm/mmotm/
>
> Seen in my dmesg. It may be relevant that I'm at home, and my IPv6
> prefix arrives via a PPP VPN connection. This happened about 20-25 seconds
> after I launched pppd.
Yes, thanks, I get the same - it doesn't seem to break anything. It
also happens some time after boot has completed, presumably when I do
something, but I haven't looked into what "something" is. It's
certainly not as complex as a PPP VPN connection.
The net guys are crunching on it.
^ permalink raw reply
* [net-2.6 PATCH 1/2] ixgbe: Priority tag FIP frames
From: Jeff Kirsher @ 2010-03-24 22:45 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Robert Love, Chris Leech, Jeff Kirsher
From: Robert Love <robert.w.love@intel.com>
Currently FIP (FCoE Initialization Protocol) frames
are going untagged. This causes various problems
with FCFs (switches) that have negotiated a priority
over dcbx. This patch tags FIP frames with the same
priority as the FCoE frames.
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: Chris Leech <christopher.leech@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 26 +++++++++++++++++---------
1 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index a9147e5..997d997 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -5628,7 +5628,8 @@ static u16 ixgbe_select_queue(struct net_device *dev, struct sk_buff *skb)
#ifdef IXGBE_FCOE
if ((adapter->flags & IXGBE_FLAG_FCOE_ENABLED) &&
- (skb->protocol == htons(ETH_P_FCOE))) {
+ ((skb->protocol == htons(ETH_P_FCOE)) ||
+ (skb->protocol == htons(ETH_P_FIP)))) {
txq &= (adapter->ring_feature[RING_F_FCOE].indices - 1);
txq += adapter->ring_feature[RING_F_FCOE].mask;
return txq;
@@ -5675,18 +5676,25 @@ static netdev_tx_t ixgbe_xmit_frame(struct sk_buff *skb,
tx_ring = adapter->tx_ring[skb->queue_mapping];
- if ((adapter->flags & IXGBE_FLAG_FCOE_ENABLED) &&
- (skb->protocol == htons(ETH_P_FCOE))) {
- tx_flags |= IXGBE_TX_FLAGS_FCOE;
#ifdef IXGBE_FCOE
+ if (adapter->flags & IXGBE_FLAG_FCOE_ENABLED) {
#ifdef CONFIG_IXGBE_DCB
- tx_flags &= ~(IXGBE_TX_FLAGS_VLAN_PRIO_MASK
- << IXGBE_TX_FLAGS_VLAN_SHIFT);
- tx_flags |= ((adapter->fcoe.up << 13)
- << IXGBE_TX_FLAGS_VLAN_SHIFT);
-#endif
+ /* for FCoE with DCB, we force the priority to what
+ * was specified by the switch */
+ if ((skb->protocol == htons(ETH_P_FCOE)) ||
+ (skb->protocol == htons(ETH_P_FIP))) {
+ tx_flags &= ~(IXGBE_TX_FLAGS_VLAN_PRIO_MASK
+ << IXGBE_TX_FLAGS_VLAN_SHIFT);
+ tx_flags |= ((adapter->fcoe.up << 13)
+ << IXGBE_TX_FLAGS_VLAN_SHIFT);
+ }
#endif
+ /* flag for FCoE offloads */
+ if (skb->protocol == htons(ETH_P_FCOE))
+ tx_flags |= IXGBE_TX_FLAGS_FCOE;
}
+#endif
+
/* four things can cause us to need a context descriptor */
if (skb_is_gso(skb) ||
(skb->ip_summed == CHECKSUM_PARTIAL) ||
^ permalink raw reply related
* [net-2.6 PATCH 2/2] ixgbe: filter FIP frames into the FCoE offload queues
From: Jeff Kirsher @ 2010-03-24 22:45 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Chris Leech, Jeff Kirsher
In-Reply-To: <20100324224500.6653.28216.stgit@localhost.localdomain>
From: Chris Leech <christopher.leech@intel.com>
During FCF solicitation, the switch is supposed to pad the
solicited advertisement out to the endpoints specified
maximum FCoE frame size. That means that we need to receive
FIP frames that are larger than the standard MTU. To make
sure the receive queue is configured correctly, we should be
filtering FIP traffic into the FCoE queues.
Signed-off-by: Chris Leech <christopher.leech@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_fcoe.c | 15 +++++++++++++++
drivers/net/ixgbe/ixgbe_type.h | 1 +
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_fcoe.c b/drivers/net/ixgbe/ixgbe_fcoe.c
index e1978da..9276d59 100644
--- a/drivers/net/ixgbe/ixgbe_fcoe.c
+++ b/drivers/net/ixgbe/ixgbe_fcoe.c
@@ -522,6 +522,9 @@ void ixgbe_configure_fcoe(struct ixgbe_adapter *adapter)
/* Enable L2 eth type filter for FCoE */
IXGBE_WRITE_REG(hw, IXGBE_ETQF(IXGBE_ETQF_FILTER_FCOE),
(ETH_P_FCOE | IXGBE_ETQF_FCOE | IXGBE_ETQF_FILTER_EN));
+ /* Enable L2 eth type filter for FIP */
+ IXGBE_WRITE_REG(hw, IXGBE_ETQF(IXGBE_ETQF_FILTER_FIP),
+ (ETH_P_FIP | IXGBE_ETQF_FILTER_EN));
if (adapter->ring_feature[RING_F_FCOE].indices) {
/* Use multiple rx queues for FCoE by redirection table */
for (i = 0; i < IXGBE_FCRETA_SIZE; i++) {
@@ -532,6 +535,12 @@ void ixgbe_configure_fcoe(struct ixgbe_adapter *adapter)
}
IXGBE_WRITE_REG(hw, IXGBE_FCRECTL, IXGBE_FCRECTL_ENA);
IXGBE_WRITE_REG(hw, IXGBE_ETQS(IXGBE_ETQF_FILTER_FCOE), 0);
+ fcoe_i = f->mask;
+ fcoe_i &= IXGBE_FCRETA_ENTRY_MASK;
+ fcoe_q = adapter->rx_ring[fcoe_i]->reg_idx;
+ IXGBE_WRITE_REG(hw, IXGBE_ETQS(IXGBE_ETQF_FILTER_FIP),
+ IXGBE_ETQS_QUEUE_EN |
+ (fcoe_q << IXGBE_ETQS_RX_QUEUE_SHIFT));
} else {
/* Use single rx queue for FCoE */
fcoe_i = f->mask;
@@ -541,6 +550,12 @@ void ixgbe_configure_fcoe(struct ixgbe_adapter *adapter)
IXGBE_ETQS_QUEUE_EN |
(fcoe_q << IXGBE_ETQS_RX_QUEUE_SHIFT));
}
+ /* send FIP frames to the first FCoE queue */
+ fcoe_i = f->mask;
+ fcoe_q = adapter->rx_ring[fcoe_i]->reg_idx;
+ IXGBE_WRITE_REG(hw, IXGBE_ETQS(IXGBE_ETQF_FILTER_FIP),
+ IXGBE_ETQS_QUEUE_EN |
+ (fcoe_q << IXGBE_ETQS_RX_QUEUE_SHIFT));
IXGBE_WRITE_REG(hw, IXGBE_FCRXCTRL,
IXGBE_FCRXCTRL_FCOELLI |
diff --git a/drivers/net/ixgbe/ixgbe_type.h b/drivers/net/ixgbe/ixgbe_type.h
index c574d0a..aed4ed6 100644
--- a/drivers/net/ixgbe/ixgbe_type.h
+++ b/drivers/net/ixgbe/ixgbe_type.h
@@ -1298,6 +1298,7 @@
#define IXGBE_ETQF_FILTER_BCN 1
#define IXGBE_ETQF_FILTER_FCOE 2
#define IXGBE_ETQF_FILTER_1588 3
+#define IXGBE_ETQF_FILTER_FIP 4
/* VLAN Control Bit Masks */
#define IXGBE_VLNCTRL_VET 0x0000FFFF /* bits 0-15 */
#define IXGBE_VLNCTRL_CFI 0x10000000 /* bit 28 */
^ permalink raw reply related
* Re: Seeing new kernel unaligned access messages in linux-next on ia64
From: Andreas Schwab @ 2010-03-24 22:47 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: David Miller, tony.luck, netdev
In-Reply-To: <alpine.LSU.2.01.1003242059230.4028@obet.zrqbmnf.qr>
Jan Engelhardt <jengelh@medozas.de> writes:
> Using a temporary and memcpying it off would normally fix this,
> as in the patch below. During testing however, I still get
> unaligned messages even with the patch - and I would not know
> what causes this.
The memcpy will not fix the alignment issue because the copy operation
is fully equivalent to a direct assignment, and the compiler can still
take advantage of the known alignment of the types. You have to
explicitly tell the compiler about the reduced alignment guarantee.
> In fact, adding a printks magically fixes it. (Bug in gcc-4.4-sparc
> compiler?)
>
> memcpy(v, &a, sizeof(a));
> + printk(KERN_INFO "v=%p a=%p\n", v, &a);
Presumably the extended lifetime of the variables caused the compiler to
use a different expansion for memcpy which is less dependent on
alignment.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH] e1000e: do not modify tx_queue_len on link speed change
From: Jeff Kirsher @ 2010-03-24 22:55 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Franco Fichtner, Emil Tantilov, Jeff Kirsher
From: Emil Tantilov <emil.s.tantilov@intel.com>
Previously the driver tweaked txqueuelen to avoid false Tx hang reports seen at half duplex.
This had the effect of overriding user set values on link change/reset. Testing shows that
adjusting only the timeout factor is sufficient to prevent Tx hang reports at half duplex.
This patch removes all instances of tx_queue_len in the driver.
Originally reported and patched by Franco Fichtner
CC: Franco Fichtner <franco@lastsummer.de>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/e1000.h | 1 -
drivers/net/e1000e/netdev.c | 11 +----------
2 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h
index c2ec095..118bdf4 100644
--- a/drivers/net/e1000e/e1000.h
+++ b/drivers/net/e1000e/e1000.h
@@ -279,7 +279,6 @@ struct e1000_adapter {
struct napi_struct napi;
- unsigned long tx_queue_len;
unsigned int restart_queue;
u32 txd_cmd;
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 88d54d3..e1cceb6 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -2289,8 +2289,6 @@ static void e1000_configure_tx(struct e1000_adapter *adapter)
ew32(TCTL, tctl);
e1000e_config_collision_dist(hw);
-
- adapter->tx_queue_len = adapter->netdev->tx_queue_len;
}
/**
@@ -2877,7 +2875,6 @@ void e1000e_down(struct e1000_adapter *adapter)
del_timer_sync(&adapter->watchdog_timer);
del_timer_sync(&adapter->phy_info_timer);
- netdev->tx_queue_len = adapter->tx_queue_len;
netif_carrier_off(netdev);
adapter->link_speed = 0;
adapter->link_duplex = 0;
@@ -3588,21 +3585,15 @@ static void e1000_watchdog_task(struct work_struct *work)
"link gets many collisions.\n");
}
- /*
- * tweak tx_queue_len according to speed/duplex
- * and adjust the timeout factor
- */
- netdev->tx_queue_len = adapter->tx_queue_len;
+ /* adjust timeout factor according to speed/duplex */
adapter->tx_timeout_factor = 1;
switch (adapter->link_speed) {
case SPEED_10:
txb2b = 0;
- netdev->tx_queue_len = 10;
adapter->tx_timeout_factor = 16;
break;
case SPEED_100:
txb2b = 0;
- netdev->tx_queue_len = 100;
adapter->tx_timeout_factor = 10;
break;
}
^ permalink raw reply related
* [PATCH] e1000e: Use pr_<level> and netdev_<level>
From: Jeff Kirsher @ 2010-03-24 22:55 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Joe Perches, Bruce Allan, Jeff Kirsher
From: Bruce Allan <bruce.w.allan@intel.com>
As an alternative to a quite large patch previously submitted by Joe
Perches to make use of kernel logging API, this patch is much less
intrusive.
Convert e_<level> to netdev_<level>
Use #define pr_fmt
Convert a few printks to pr_<level>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/e1000.h | 19 +++++--------------
drivers/net/e1000e/netdev.c | 9 +++++----
2 files changed, 10 insertions(+), 18 deletions(-)
diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h
index 118bdf4..23ab67c 100644
--- a/drivers/net/e1000e/e1000.h
+++ b/drivers/net/e1000e/e1000.h
@@ -42,25 +42,16 @@
struct e1000_info;
-#define e_printk(level, adapter, format, arg...) \
- printk(level "%s: %s: " format, pci_name(adapter->pdev), \
- adapter->netdev->name, ## arg)
-
-#ifdef DEBUG
#define e_dbg(format, arg...) \
- e_printk(KERN_DEBUG , hw->adapter, format, ## arg)
-#else
-#define e_dbg(format, arg...) do { (void)(hw); } while (0)
-#endif
-
+ netdev_dbg(hw->adapter->netdev, format, ## arg)
#define e_err(format, arg...) \
- e_printk(KERN_ERR, adapter, format, ## arg)
+ netdev_err(adapter->netdev, format, ## arg)
#define e_info(format, arg...) \
- e_printk(KERN_INFO, adapter, format, ## arg)
+ netdev_info(adapter->netdev, format, ## arg)
#define e_warn(format, arg...) \
- e_printk(KERN_WARNING, adapter, format, ## arg)
+ netdev_warn(adapter->netdev, format, ## arg)
#define e_notice(format, arg...) \
- e_printk(KERN_NOTICE, adapter, format, ## arg)
+ netdev_notice(adapter->netdev, format, ## arg)
/* Interrupt modes, as used by the IntMode parameter */
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index e1cceb6..ad4546e 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -26,6 +26,8 @@
*******************************************************************************/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/module.h>
#include <linux/types.h>
#include <linux/init.h>
@@ -5394,10 +5396,9 @@ static struct pci_driver e1000_driver = {
static int __init e1000_init_module(void)
{
int ret;
- printk(KERN_INFO "%s: Intel(R) PRO/1000 Network Driver - %s\n",
- e1000e_driver_name, e1000e_driver_version);
- printk(KERN_INFO "%s: Copyright (c) 1999 - 2009 Intel Corporation.\n",
- e1000e_driver_name);
+ pr_info("Intel(R) PRO/1000 Network Driver - %s\n",
+ e1000e_driver_version);
+ pr_info("Copyright (c) 1999 - 2009 Intel Corporation.\n");
ret = pci_register_driver(&e1000_driver);
return ret;
^ permalink raw reply related
* Re: Seeing new kernel unaligned access messages in linux-next on ia64
From: Jan Engelhardt @ 2010-03-24 23:17 UTC (permalink / raw)
To: Andreas Schwab; +Cc: David Miller, tony.luck, netdev
In-Reply-To: <m2vdcl5ocj.fsf@igel.home>
On Wednesday 2010-03-24 23:47, Andreas Schwab wrote:
>Jan Engelhardt writes:
>
>> Using a temporary and memcpying it off would normally fix this,
>> as in the patch below. During testing however, I still get
>> unaligned messages even with the patch - and I would not know
>> what causes this.
>
>The memcpy will not fix the alignment issue because the copy operation
>is fully equivalent to a direct assignment, and the compiler can still
>take advantage of the known alignment of the types. You have to
>explicitly tell the compiler about the reduced alignment guarantee.
You're right, I remember seeing that sort of optimization before. So I
have changed the function's signature to read
-static void copy_rtnl_link_stats64(struct rtnl_link_stats64 *v,
- const struct net_device_stats *b)
+static void copy_rtnl_link_stats64(void *v, const struct net_device_stats *b)
{
...
memcpy(v, &a, sizeof(a));
}
No more unaligned messages - but is this an acceptable solution?
thanks,
Jan
^ permalink raw reply
* RE: Seeing new kernel unaligned access messages in linux-next on ia64
From: Luck, Tony @ 2010-03-24 23:19 UTC (permalink / raw)
To: Jan Engelhardt, Andreas Schwab; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <alpine.LSU.2.01.1003250014400.16715@obet.zrqbmnf.qr>
> No more unaligned messages - but is this an acceptable solution?
There are a bunch of macros in include/linux/unaligned/*.h to
handle this sort of thing.
-Tony
^ permalink raw reply
* Re: behavior of recvmmsg() on blocking sockets
From: Brandon Black @ 2010-03-24 23:35 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <g76h4xrt5j1pw2kk3tUYAxe124vaj_firegpg@mail.gmail.com>
On Wed, Mar 24, 2010 at 1:34 PM, <drepper@gmail.com> wrote:
> On Wed, Mar 24, 2010 at 11:28, Brandon Black <blblack@gmail.com> wrote:
>>
>> I still think having a "block until at least one packet arrives" mode
>> for recvmmsg() makes sense though.
>
> I agree. This is the mode I've seen people asking for. They want the call
> to return as quickly as possible if there is data and then with as many
> messages as possible. A MSG_WAITFORONE flag would do the trick nicely.
This patch might be woefully inadequate, as I'm not intimately
familiar with the rest of the Linux socket code, and I'm not sure what
the impact is of (a) adding that new flag, which is the first beyond
the 16-bit space, and (b) having that extra undefined flag present
during the underlying recvmsg() calls, but this patch Works For Me for
my isolated case. Thoughts? (hoping gmail doesn't mangle this)
[blblack@xpc kernels]$ diff -u linux-2.6.33-orig/net/socket.c
linux-2.6.33/net/socket.c
--- linux-2.6.33-orig/net/socket.c 2010-02-24 12:52:17.000000000 -0600
+++ linux-2.6.33/net/socket.c 2010-03-24 18:10:37.156234986 -0500
@@ -2133,7 +2133,10 @@
if (err)
break;
- ++datagrams;
+
+ /* MSG_WAITFORONE turns on MSG_DONTWAIT after one packet */
+ if (!datagrams++ && flags & MSG_WAITFORONE)
+ flags |= MSG_DONTWAIT;
if (timeout) {
ktime_get_ts(timeout);
[blblack@xpc kernels]$ diff -u
linux-2.6.33-orig/include/linux/socket.h
linux-2.6.33/include/linux/socket.h
--- linux-2.6.33-orig/include/linux/socket.h 2010-02-24 12:52:17.000000000 -0600
+++ linux-2.6.33/include/linux/socket.h 2010-03-24 17:35:14.009266280 -0500
@@ -255,6 +255,7 @@
#define MSG_ERRQUEUE 0x2000 /* Fetch message from error queue */
#define MSG_NOSIGNAL 0x4000 /* Do not generate SIGPIPE */
#define MSG_MORE 0x8000 /* Sender will send more */
+#define MSG_WAITFORONE 0x10000 /* recvmmsg(): block until 1+ packets avail */
#define MSG_EOF MSG_FIN
^ permalink raw reply
* Re: [PATCH] e1000e: Use pr_<level> and netdev_<level>
From: Joe Perches @ 2010-03-24 23:43 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, Bruce Allan
In-Reply-To: <20100324225529.7104.17189.stgit@localhost.localdomain>
On Wed, 2010-03-24 at 15:55 -0700, Jeff Kirsher wrote:
> From: Bruce Allan <bruce.w.allan@intel.com>
> As an alternative to a quite large patch previously submitted by Joe
> Perches to make use of kernel logging API, this patch is much less
> intrusive.
[]
> diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h
> index 118bdf4..23ab67c 100644
> --- a/drivers/net/e1000e/e1000.h
> +++ b/drivers/net/e1000e/e1000.h
> @@ -42,25 +42,16 @@
>
> struct e1000_info;
>
> -#define e_printk(level, adapter, format, arg...) \
> - printk(level "%s: %s: " format, pci_name(adapter->pdev), \
> - adapter->netdev->name, ## arg)
> -
> -#ifdef DEBUG
> #define e_dbg(format, arg...) \
> - e_printk(KERN_DEBUG , hw->adapter, format, ## arg)
> -#else
> -#define e_dbg(format, arg...) do { (void)(hw); } while (0)
> -#endif
> -
> + netdev_dbg(hw->adapter->netdev, format, ## arg)
> #define e_err(format, arg...) \
> - e_printk(KERN_ERR, adapter, format, ## arg)
> + netdev_err(adapter->netdev, format, ## arg)
> #define e_info(format, arg...) \
> - e_printk(KERN_INFO, adapter, format, ## arg)
> + netdev_info(adapter->netdev, format, ## arg)
> #define e_warn(format, arg...) \
> - e_printk(KERN_WARNING, adapter, format, ## arg)
> + netdev_warn(adapter->netdev, format, ## arg)
> #define e_notice(format, arg...) \
> - e_printk(KERN_NOTICE, adapter, format, ## arg)
> + netdev_notice(adapter->netdev, format, ## arg)
Macros that use global variables are undesirable.
I think there's value in using standard mechanisms.
cheers, Joe
^ permalink raw reply
* RE: [PATCH] e1000e: Use pr_<level> and netdev_<level>
From: Allan, Bruce W @ 2010-03-24 23:54 UTC (permalink / raw)
To: Joe Perches, Kirsher, Jeffrey T
Cc: davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <1269474180.1541.11.camel@Joe-Laptop.home>
On Wednesday, March 24, 2010 4:43 PM, Joe Perches wrote:
> On Wed, 2010-03-24 at 15:55 -0700, Jeff Kirsher wrote:
>> From: Bruce Allan <bruce.w.allan@intel.com>
>> As an alternative to a quite large patch previously submitted by Joe
>> Perches to make use of kernel logging API, this patch is much less
>> intrusive.
> []
>> diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h
>> index 118bdf4..23ab67c 100644 --- a/drivers/net/e1000e/e1000.h
>> +++ b/drivers/net/e1000e/e1000.h
>> @@ -42,25 +42,16 @@
>>
>> struct e1000_info;
>>
>> -#define e_printk(level, adapter, format, arg...) \
>> - printk(level "%s: %s: " format, pci_name(adapter->pdev), \
>> - adapter->netdev->name, ## arg)
>> -
>> -#ifdef DEBUG
>> #define e_dbg(format, arg...) \
>> - e_printk(KERN_DEBUG , hw->adapter, format, ## arg)
>> -#else
>> -#define e_dbg(format, arg...) do { (void)(hw); } while (0)
>> -#endif
>> -
>> + netdev_dbg(hw->adapter->netdev, format, ## arg)
>> #define e_err(format, arg...) \
>> - e_printk(KERN_ERR, adapter, format, ## arg)
>> + netdev_err(adapter->netdev, format, ## arg)
>> #define e_info(format, arg...) \
>> - e_printk(KERN_INFO, adapter, format, ## arg)
>> + netdev_info(adapter->netdev, format, ## arg)
>> #define e_warn(format, arg...) \
>> - e_printk(KERN_WARNING, adapter, format, ## arg)
>> + netdev_warn(adapter->netdev, format, ## arg)
>> #define e_notice(format, arg...) \
>> - e_printk(KERN_NOTICE, adapter, format, ## arg)
>> + netdev_notice(adapter->netdev, format, ## arg)
>
> Macros that use global variables are undesirable.
>
> I think there's value in using standard mechanisms.
>
> cheers, Joe
No global variable is used - both adapter and hw are either a local variable or a passed in parameter for all functions that use these macros.
^ permalink raw reply
* RE: [PATCH] e1000e: Use pr_<level> and netdev_<level>
From: Joe Perches @ 2010-03-25 0:04 UTC (permalink / raw)
To: Allan, Bruce W
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A9061B3334E@orsmsx509.amr.corp.intel.com>
On Wed, 2010-03-24 at 16:54 -0700, Allan, Bruce W wrote:
> On Wednesday, March 24, 2010 4:43 PM, Joe Perches wrote:
> > On Wed, 2010-03-24 at 15:55 -0700, Jeff Kirsher wrote:
> >> From: Bruce Allan <bruce.w.allan@intel.com>
> >> As an alternative to a quite large patch previously submitted by Joe
> >> Perches to make use of kernel logging API, this patch is much less
> >> intrusive.
> > []
> >> diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h
> >> index 118bdf4..23ab67c 100644 --- a/drivers/net/e1000e/e1000.h
> >> +++ b/drivers/net/e1000e/e1000.h
> >> @@ -42,25 +42,16 @@
> >>
> >> struct e1000_info;
> >>
> >> -#define e_printk(level, adapter, format, arg...) \
> >> - printk(level "%s: %s: " format, pci_name(adapter->pdev), \
> >> - adapter->netdev->name, ## arg)
> >> -
> >> -#ifdef DEBUG
> >> #define e_dbg(format, arg...) \
> >> - e_printk(KERN_DEBUG , hw->adapter, format, ## arg)
> >> -#else
> >> -#define e_dbg(format, arg...) do { (void)(hw); } while (0)
> >> -#endif
> >> -
> >> + netdev_dbg(hw->adapter->netdev, format, ## arg)
> >> #define e_err(format, arg...) \
> >> - e_printk(KERN_ERR, adapter, format, ## arg)
> >> + netdev_err(adapter->netdev, format, ## arg)
> >> #define e_info(format, arg...) \
> >> - e_printk(KERN_INFO, adapter, format, ## arg)
> >> + netdev_info(adapter->netdev, format, ## arg)
> >> #define e_warn(format, arg...) \
> >> - e_printk(KERN_WARNING, adapter, format, ## arg)
> >> + netdev_warn(adapter->netdev, format, ## arg)
> >> #define e_notice(format, arg...) \
> >> - e_printk(KERN_NOTICE, adapter, format, ## arg)
> >> + netdev_notice(adapter->netdev, format, ## arg)
> >
> > Macros that use global variables are undesirable.
> > I think there's value in using standard mechanisms.
> >
> No global variable is used - both adapter and hw are either a local
> variable or a passed in parameter for all functions that use these macros.
hw and adapter are locally scoped in each function here,
but are not local to the macro. That can make conversions
of macros to functions difficult.
It's your code, not mine.
Proving the conversion correct is pretty trivial.
Do what's best.
cheers, Joe
^ permalink raw reply
* Re: why not use the tcp_set_state() in inet_csk_listen_start()?
From: 杨硕 @ 2010-03-25 0:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1269421323.3213.16.camel@edumazet-laptop>
But if we use "STATE_TRACE", maybe the state will be incomplete.
> Because its not necessary ?
>
> tcp_set_state() takes care of particular state transitions.
>
> In case of inet_csk_listen_start(), old state is TCP_CLOSE, so there is
> nothing special to do in tcp_set_state().
>
^ permalink raw reply
* mmotm 2010-03-23 - IPv6 warnings...
From: Valdis.Kletnieks @ 2010-03-25 1:36 UTC (permalink / raw)
To: akpm; +Cc: netdev, linux-kernel
In-Reply-To: <201003232301.o2NN1bms031050@imap1.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 5066 bytes --]
On Tue, 23 Mar 2010 15:34:59 PDT, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2010-03-23-15-34 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
Seen in my dmesg. It may be relevant that I'm at home, and my IPv6
prefix arrives via a PPP VPN connection. This happened about 20-25 seconds
after I launched pppd.
[ 175.269411] ------------[ cut here ]------------
[ 175.269433] WARNING: at net/ipv6/addrconf.c:544 inet6_ifa_finish_destroy+0x40/0xbb()
[ 175.269441] Hardware name: Latitude E6500
[ 175.269447] Modules linked in: ppp_async sunrpc usb_storage [last unloaded: scsi_wait_scan]
[ 175.269473] Pid: 7, comm: ksoftirqd/1 Tainted: G W 2.6.34-rc2-mmotm0323 #1
[ 175.269480] Call Trace:
[ 175.269488] <IRQ> [<ffffffff8103728a>] warn_slowpath_common+0x80/0x98
[ 175.269517] [<ffffffff810372b7>] warn_slowpath_null+0x15/0x17
[ 175.269530] [<ffffffff814f2093>] inet6_ifa_finish_destroy+0x40/0xbb
[ 175.269542] [<ffffffff814f2122>] in6_ifa_put+0x14/0x16
[ 175.269555] [<ffffffff814f4893>] addrconf_prefix_rcv+0x583/0x786
[ 175.269568] [<ffffffff814f70b3>] ? rt6_get_dflt_router+0xab/0xbb
[ 175.269581] [<ffffffff814fd98c>] ndisc_rcv+0x90f/0xdb4
[ 175.269595] [<ffffffff810852a7>] ? __rcu_read_unlock+0x30c/0x341
[ 175.269609] [<ffffffff81502f6d>] ? debug_lockdep_rcu_enabled+0x33/0x39
[ 175.269622] [<ffffffff815040ae>] icmpv6_rcv+0x59b/0x659
[ 175.269634] [<ffffffff81504c9e>] ? ipv6_chk_mcast_addr+0xaf/0x13d
[ 175.269648] [<ffffffff81063e21>] ? trace_hardirqs_on_caller+0x16/0x13c
[ 175.269661] [<ffffffff8103d5b3>] ? _local_bh_enable_ip+0x15c/0x16e
[ 175.269674] [<ffffffff8103d5ce>] ? local_bh_enable_ip+0x9/0xb
[ 175.269689] [<ffffffff81598c44>] ? _raw_read_unlock_bh+0x39/0x3e
[ 175.269702] [<ffffffff81504d13>] ? ipv6_chk_mcast_addr+0x124/0x13d
[ 175.269714] [<ffffffff814eee7d>] ? ip6_input_finish+0x0/0x343
[ 175.269726] [<ffffffff814ef066>] ip6_input_finish+0x1e9/0x343
[ 175.269737] [<ffffffff814eee7d>] ? ip6_input_finish+0x0/0x343
[ 175.269748] [<ffffffff814ef20c>] NF_HOOK.clone.1+0x4c/0x53
[ 175.269759] [<ffffffff814ef6d6>] ip6_input+0x1c/0x1e
[ 175.269769] [<ffffffff814ef7df>] ip6_mc_input+0x107/0x11c
[ 175.269780] [<ffffffff814eee17>] ? ip6_rcv_finish+0x0/0x26
[ 175.269791] [<ffffffff814eee39>] ip6_rcv_finish+0x22/0x26
[ 175.269802] [<ffffffff814ef20c>] NF_HOOK.clone.1+0x4c/0x53
[ 175.269812] [<ffffffff814ef666>] ipv6_rcv+0x453/0x4a7
[ 175.269827] [<ffffffff8146527e>] __netif_receive_skb+0x2da/0x307
[ 175.269839] [<ffffffff81465348>] process_backlog+0x9d/0xd6
[ 175.269851] [<ffffffff81465631>] net_rx_action+0xf2/0x356
[ 175.269863] [<ffffffff8103dc41>] __do_softirq+0x14a/0x282
[ 175.269876] [<ffffffff8100360c>] call_softirq+0x1c/0x34
[ 175.269882] <EOI> [<ffffffff81004b58>] ? do_softirq+0x44/0xf0
[ 175.269901] [<ffffffff8103d7dd>] run_ksoftirqd+0xbc/0x1fb
[ 175.269912] [<ffffffff8103d721>] ? run_ksoftirqd+0x0/0x1fb
[ 175.269925] [<ffffffff81052c6b>] kthread+0x7a/0x82
[ 175.269937] [<ffffffff81003514>] kernel_thread_helper+0x4/0x10
[ 175.269949] [<ffffffff81599900>] ? restore_args+0x0/0x30
[ 175.269961] [<ffffffff81052bf1>] ? kthread+0x0/0x82
[ 175.269971] [<ffffffff81003510>] ? kernel_thread_helper+0x0/0x10
[ 175.269979] ---[ end trace a7919e7f17c0a727 ]---
[ 175.269986] Freeing alive inet6 address ffff880107e1a400
[ 176.472172] ------------[ cut here ]------------
[ 176.472192] WARNING: at net/ipv6/addrconf.c:544 inet6_ifa_finish_destroy+0x40/0xbb()
[ 176.472200] Hardware name: Latitude E6500
[ 176.472206] Modules linked in: ppp_async sunrpc usb_storage [last unloaded: scsi_wait_scan]
[ 176.472232] Pid: 4008, comm: fetchmail Tainted: G W 2.6.34-rc2-mmotm0323 #1
[ 176.472239] Call Trace:
[ 176.472256] [<ffffffff8103728a>] warn_slowpath_common+0x80/0x98
[ 176.472269] [<ffffffff810372b7>] warn_slowpath_null+0x15/0x17
[ 176.472280] [<ffffffff814f2093>] inet6_ifa_finish_destroy+0x40/0xbb
[ 176.472291] [<ffffffff814f2122>] in6_ifa_put+0x14/0x16
[ 176.472303] [<ffffffff814f2a7b>] ipv6_dev_get_saddr+0x2b3/0x2c7
[ 176.472316] [<ffffffff814f8f32>] ? fib6_rule_lookup+0x18/0x1a
[ 176.472328] [<ffffffff814ebb04>] ip6_dst_lookup_tail+0x90/0xc5
[ 176.472339] [<ffffffff814ebc37>] ip6_dst_lookup+0x10/0x12
[ 176.472352] [<ffffffff8150f712>] ip6_datagram_connect+0x334/0x4f6
[ 176.472365] [<ffffffff8103d5b3>] ? _local_bh_enable_ip+0x15c/0x16e
[ 176.472378] [<ffffffff81457d82>] ? release_sock+0xff/0x108
[ 176.472390] [<ffffffff814c0042>] inet_dgram_connect+0x56/0x5d
[ 176.472402] [<ffffffff81455907>] sys_connect+0x75/0x98
[ 176.472415] [<ffffffff810e24b4>] ? path_put+0x1d/0x22
[ 176.472429] [<ffffffff81063e21>] ? trace_hardirqs_on_caller+0x16/0x13c
[ 176.472442] [<ffffffff8107d442>] ? audit_syscall_entry+0xcb/0x19c
[ 176.472455] [<ffffffff810026eb>] system_call_fastpath+0x16/0x1b
[ 176.472464] ---[ end trace a7919e7f17c0a728 ]---
[ 176.472472] Freeing alive inet6 address ffff880107e1a400
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: Shan Wei @ 2010-03-25 2:22 UTC (permalink / raw)
To: YOSHIFUJI Hideaki
Cc: Patrick McHardy, YOSHIFUJI Hideaki, David Miller, Alexey Dobriyan,
Yasuyuki KOZAKAI, netdev@vger.kernel.org, netfilter-devel
In-Reply-To: <4BA90F72.6010404@linux-ipv6.org>
yoshifuji-san:
YOSHIFUJI Hideaki wrote, at 03/24/2010 02:58 AM:
>> In this case without conntrack, IPv6 would send an ICMPv6 message,
>> so in my opinion the transparent thing to do would be to still send
>> them. Of course only if reassembly is done on an end host.
>
> Well, no. conntrack should just forward even uncompleted fragments
> to next process (e.g. core ipv6 code), and then the core would send
> ICMP error back. ICMP should be sent by the core ipv6 code according
> to decision of itself, not according to netfilter.
It's bad to forward uncompleted fragments to IPv4/IPv6 stack.
One the one hand, helper modules of conntrack analyze application data
in packets. They need to parse overall segment or datagram. If packets are
fragmented, conntrack needs to reassemble them.
On the other hand, if uncompleted fragments are forwarded to IPv4/IPv6 stack,
they will be reassemble twice, and the result is also failure.
So, conntrack will drop uncompleted fragments after reassemble timeout.
> Would you please explain more about what you mean by consistency
> between IPv4 and IPv6 conntrack?
>
> I do think it is rather different, anyway (because original packets
> is to be preserved in IPv6, but not in IPv4).
Yes, the defragment implement of IPv6 conntrack is absolutely different from that of IPv4 conntrack.
But, the handle after reassemble timeout should be consistent.
For IPv4 conntrack, an end host with conntrack enabled must send ICMP fragment reassembly timeout
message to source host. Details see commit e9017b
(Title: IP: Send an ICMP "Fragment Reassembly Timeout" message when enabling connection track).
--
Best Regards
-----
Shan Wei
>
> --yoshfuji
>
^ permalink raw reply
* Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: Shan Wei @ 2010-03-25 2:28 UTC (permalink / raw)
To: Patrick McHardy
Cc: YOSHIFUJI Hideaki, David Miller, Alexey Dobriyan,
Yasuyuki KOZAKAI, netdev@vger.kernel.org, netfilter-devel,
yoshfuji@linux-ipv6.org >> YOSHIFUJI Hideaki
In-Reply-To: <4BA8D8AF.1040307@trash.net>
Patrick McHardy wrote, at 03/23/2010 11:05 PM:
> Shan Wei wrote:
>>> On the other hand, I'd even say we should NOT send
>>> icmp here (at least by default) because standard routers
>>> never send such packet.
>>>
>> Yes，for routers, the patch-set does not send icmp message to
>> source host. It only does on destination host with IPv6 connection
>> track enable.
>>
>
> The nf-next tree is open again, now would be a good time to resubmit
> these patches.
> Thanks!
If no body opposes them, i will resubmit these patches with v3.
--
Best Regards
-----
Shan Wei
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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
* bug 15606: register_netdevice: Kobject changed too ealier
From: Richard Zhao @ 2010-03-25 2:44 UTC (permalink / raw)
To: netdev
Hi,
Could someone take bug 15606?
https://bugzilla.kernel.org/show_bug.cgi?id=15606
Thanks
Richard
^ permalink raw reply
* Re: [iproute2] tc pedit modify ethhdr ?
From: Xiaofei Wu @ 2010-03-25 2:59 UTC (permalink / raw)
To: hadi; +Cc: linux netdev
In-Reply-To: <1269438652.4089.22.camel@bigi>
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
I made a test like your example.
The terminal prints:
parse_cmd argc 20 set offset -14 length 2
pack_key16: Final val 90000000 mask 0000ffff
parse_cmd done argc 18 munge offset -16 length 2
what's the meaning of the above 3 lines; It modify the value of -16,-15,-14,-13 , or just modify -14,-13 ?
If it modified -16,-15 , would it cause any problems?
Thanks.
--
Wu
----- Original Message ----
> but the size of ethhdr is 14 bytes, 14 is not multiple of 4 .
> How to use 'tc ... pedit ...' modify a packet's h_dest and h_source
> of ethhdr ?
> Use ' ... pedit munge offset -14 u16 set 0x0090 munge offset -12 u32 set 0x9600030a ... ' or
> use ' ... pedit munge offset -16 u32 ... munge offset -12 ... ' ?
>
0 is at ip header.
dst MAC starts at -14
src MAC at -8
ethertype at -2
Example:
tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 \
match ip src 192.168.1.10/32 flowid 1:2 \
action pedit munge offset -14 u16 set 0x0000 \
munge offset -12 u32 set 0x00010100 \
munge offset -8 u32 set 0x0aaf0100 \
munge offset -4 u32 set 0x0008ec06 pipe \
action mirred egress redirect dev eth1
[-- Attachment #2: test.png --]
[-- Type: application/octet-stream, Size: 61263 bytes --]
^ permalink raw reply
* Re: [iproute2] tc pedit modify ethhdr ?
From: jamal @ 2010-03-25 3:21 UTC (permalink / raw)
To: Xiaofei Wu; +Cc: linux netdev
In-Reply-To: <326421.66567.qm@web111606.mail.gq1.yahoo.com>
I put some effort in responding to you. Please put some
effort in testing it.
cheers,
jamal
On Wed, 2010-03-24 at 19:59 -0700, Xiaofei Wu wrote:
>
>
> I made a test like your example.
> The terminal prints:
> parse_cmd argc 20 set offset -14 length 2
> pack_key16: Final val 90000000 mask 0000ffff
> parse_cmd done argc 18 munge offset -16 length 2
>
> what's the meaning of the above 3 lines; It modify the value of -16,-15,-14,-13 , or just modify -14,-13 ?
> If it modified -16,-15 , would it cause any problems?
>
> Thanks.
>
>
> --
> Wu
>
>
>
> ----- Original Message ----
> > but the size of ethhdr is 14 bytes, 14 is not multiple of 4 .
> > How to use 'tc ... pedit ...' modify a packet's h_dest and h_source
> > of ethhdr ?
> > Use ' ... pedit munge offset -14 u16 set 0x0090 munge offset -12 u32 set 0x9600030a ... ' or
> > use ' ... pedit munge offset -16 u32 ... munge offset -12 ... ' ?
> >
>
> 0 is at ip header.
> dst MAC starts at -14
> src MAC at -8
> ethertype at -2
>
> Example:
> tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 \
> match ip src 192.168.1.10/32 flowid 1:2 \
> action pedit munge offset -14 u16 set 0x0000 \
> munge offset -12 u32 set 0x00010100 \
> munge offset -8 u32 set 0x0aaf0100 \
> munge offset -4 u32 set 0x0008ec06 pipe \
> action mirred egress redirect dev eth1
>
>
>
^ 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