* [PATCH 36/37] drivers/net/wireless/orinoco: Use kmemdup
From: Julia Lawall @ 2010-05-15 21:24 UTC (permalink / raw)
To: Pavel Roskin, David Gibson, John W. Linville, linux-wireless,
orinoco-users, orinoco-devel, netdev, linux-kernel,
kernel-janitors
From: Julia Lawall <julia@diku.dk>
Use kmemdup when some other buffer is immediately copied into the
allocated region.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
statement S;
@@
- to = \(kmalloc\|kzalloc\)(size,flag);
+ to = kmemdup(from,size,flag);
if (to==NULL || ...) S
- memcpy(to, from, size);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/wireless/orinoco/wext.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff -u -p a/drivers/net/wireless/orinoco/wext.c b/drivers/net/wireless/orinoco/wext.c
--- a/drivers/net/wireless/orinoco/wext.c
+++ b/drivers/net/wireless/orinoco/wext.c
@@ -993,11 +993,9 @@ static int orinoco_ioctl_set_genie(struc
return -EINVAL;
if (wrqu->data.length) {
- buf = kmalloc(wrqu->data.length, GFP_KERNEL);
+ buf = kmemdup(extra, wrqu->data.length, GFP_KERNEL);
if (buf == NULL)
return -ENOMEM;
-
- memcpy(buf, extra, wrqu->data.length);
} else
buf = NULL;
^ permalink raw reply
* [PATCH 32/37] drivers/net/wireless/p54: Use kmemdup
From: Julia Lawall @ 2010-05-15 21:22 UTC (permalink / raw)
To: Michael Wu, John W. Linville, linux-wireless, netdev,
linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Use kmemdup when some other buffer is immediately copied into the
allocated region.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
statement S;
@@
- to = \(kmalloc\|kzalloc\)(size,flag);
+ to = kmemdup(from,size,flag);
if (to==NULL || ...) S
- memcpy(to, from, size);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/wireless/p54/eeprom.c | 4 ++--
drivers/net/wireless/p54/p54usb.c | 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
diff -u -p a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -433,10 +433,9 @@ static int p54u_firmware_reset_3887(stru
u8 *buf;
int ret;
- buf = kmalloc(4, GFP_KERNEL);
+ buf = kmemdup(p54u_romboot_3887, 4, GFP_KERNEL);
if (!buf)
return -ENOMEM;
- memcpy(buf, p54u_romboot_3887, 4);
ret = p54u_bulk_msg(priv, P54U_PIPE_DATA,
buf, 4);
kfree(buf);
diff -u -p a/drivers/net/wireless/p54/eeprom.c b/drivers/net/wireless/p54/eeprom.c
--- a/drivers/net/wireless/p54/eeprom.c
+++ b/drivers/net/wireless/p54/eeprom.c
@@ -599,13 +599,13 @@ int p54_parse_eeprom(struct ieee80211_hw
}
break;
case PDR_PRISM_ZIF_TX_IQ_CALIBRATION:
- priv->iq_autocal = kmalloc(data_len, GFP_KERNEL);
+ priv->iq_autocal = kmemdup(entry->data, data_len,
+ GFP_KERNEL);
if (!priv->iq_autocal) {
err = -ENOMEM;
goto err;
}
- memcpy(priv->iq_autocal, entry->data, data_len);
priv->iq_autocal_len = data_len / sizeof(struct pda_iq_autocal_entry);
break;
case PDR_DEFAULT_COUNTRY:
^ permalink raw reply
* [PATCH 26/37] drivers/net/wireless/ipw2x00: Use kmemdup
From: Julia Lawall @ 2010-05-15 21:21 UTC (permalink / raw)
To: Zhu Yi, Reinette Chatre, Intel Linux Wireless, John W. Linville,
linux-wireless, netdev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Use kmemdup when some other buffer is immediately copied into the
allocated region.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
statement S;
@@
- to = \(kmalloc\|kzalloc\)(size,flag);
+ to = kmemdup(from,size,flag);
if (to==NULL || ...) S
- memcpy(to, from, size);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/wireless/ipw2x00/ipw2200.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -u -p a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -6626,13 +6626,12 @@ static int ipw_wx_set_genie(struct net_d
return -EINVAL;
if (wrqu->data.length) {
- buf = kmalloc(wrqu->data.length, GFP_KERNEL);
+ buf = kmemdup(extra, wrqu->data.length, GFP_KERNEL);
if (buf == NULL) {
err = -ENOMEM;
goto out;
}
- memcpy(buf, extra, wrqu->data.length);
kfree(ieee->wpa_ie);
ieee->wpa_ie = buf;
ieee->wpa_ie_len = wrqu->data.length;
^ permalink raw reply
* [PATCH 24/37] drivers/net/wireless/b43: Use kmemdup
From: Julia Lawall @ 2010-05-15 21:20 UTC (permalink / raw)
To: Stefano Brivio, John W. Linville, linux-wireless, netdev,
linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Use kmemdup when some other buffer is immediately copied into the
allocated region.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
statement S;
@@
- to = \(kmalloc\|kzalloc\)(size,flag);
+ to = kmemdup(from,size,flag);
if (to==NULL || ...) S
- memcpy(to, from, size);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/wireless/b43/dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -u -p a/drivers/net/wireless/b43/dma.c b/drivers/net/wireless/b43/dma.c
--- a/drivers/net/wireless/b43/dma.c
+++ b/drivers/net/wireless/b43/dma.c
@@ -1221,14 +1221,14 @@ static int dma_tx_fragment(struct b43_dm
meta->dmaaddr = map_descbuffer(ring, skb->data, skb->len, 1);
/* create a bounce buffer in zone_dma on mapping failure. */
if (b43_dma_mapping_error(ring, meta->dmaaddr, skb->len, 1)) {
- priv_info->bouncebuffer = kmalloc(skb->len, GFP_ATOMIC | GFP_DMA);
+ priv_info->bouncebuffer = kmemdup(skb->data, skb->len,
+ GFP_ATOMIC | GFP_DMA);
if (!priv_info->bouncebuffer) {
ring->current_slot = old_top_slot;
ring->used_slots = old_used_slots;
err = -ENOMEM;
goto out_unmap_hdr;
}
- memcpy(priv_info->bouncebuffer, skb->data, skb->len);
meta->dmaaddr = map_descbuffer(ring, priv_info->bouncebuffer, skb->len, 1);
if (b43_dma_mapping_error(ring, meta->dmaaddr, skb->len, 1)) {
^ permalink raw reply
* [PATCH 14/37] drivers/net/wireless/ath/ath9k: Use kmemdup
From: Julia Lawall @ 2010-05-15 21:17 UTC (permalink / raw)
To: Luis R. Rodriguez, Jouni Malinen, Sujith Manoharan,
Vasanthakumar Thiagarajan, Senthil Balasubramanian,
John W. Linville, linux-wireless, ath9k-devel, netdev,
linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Use kmemdup when some other buffer is immediately copied into the
allocated region.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
statement S;
@@
- to = \(kmalloc\|kzalloc\)(size,flag);
+ to = kmemdup(from,size,flag);
if (to==NULL || ...) S
- memcpy(to, from, size);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff -u -p a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -901,12 +901,10 @@ static void ath9k_hif_usb_reboot(struct
void *buf;
int ret;
- buf = kmalloc(4, GFP_KERNEL);
+ buf = kmemdup(&reboot_cmd, 4, GFP_KERNEL);
if (!buf)
return;
- memcpy(buf, &reboot_cmd, 4);
-
ret = usb_bulk_msg(udev, usb_sndbulkpipe(udev, USB_REG_OUT_PIPE),
buf, 4, NULL, HZ);
if (ret)
^ permalink raw reply
* [PATCH 13/37] drivers/net/wireless/iwmc3200wifi: Use kmemdup
From: Julia Lawall @ 2010-05-15 21:16 UTC (permalink / raw)
To: Samuel Ortiz, Zhu Yi, Intel Linux Wireless, John W. Linville,
linux-wireless, netdev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Use kmemdup when some other buffer is immediately copied into the
allocated region.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
statement S;
@@
- to = \(kmalloc\|kzalloc\)(size,flag);
+ to = kmemdup(from,size,flag);
if (to==NULL || ...) S
- memcpy(to, from, size);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/wireless/iwmc3200wifi/rx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -u -p a/drivers/net/wireless/iwmc3200wifi/rx.c b/drivers/net/wireless/iwmc3200wifi/rx.c
--- a/drivers/net/wireless/iwmc3200wifi/rx.c
+++ b/drivers/net/wireless/iwmc3200wifi/rx.c
@@ -321,14 +321,14 @@ iwm_rx_ticket_node_alloc(struct iwm_priv
return ERR_PTR(-ENOMEM);
}
- ticket_node->ticket = kzalloc(sizeof(struct iwm_rx_ticket), GFP_KERNEL);
+ ticket_node->ticket = kmemdup(ticket, sizeof(struct iwm_rx_ticket),
+ GFP_KERNEL);
if (!ticket_node->ticket) {
IWM_ERR(iwm, "Couldn't allocate RX ticket\n");
kfree(ticket_node);
return ERR_PTR(-ENOMEM);
}
- memcpy(ticket_node->ticket, ticket, sizeof(struct iwm_rx_ticket));
INIT_LIST_HEAD(&ticket_node->node);
return ticket_node;
^ permalink raw reply
* [PATCH 12/37] drivers/net/wireless/wl12xx: Use kmemdup
From: Julia Lawall @ 2010-05-15 21:16 UTC (permalink / raw)
To: Luciano Coelho, John W. Linville, linux-wireless, netdev,
linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Use kmemdup when some other buffer is immediately copied into the
allocated region.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
statement S;
@@
- to = \(kmalloc\|kzalloc\)(size,flag);
+ to = kmemdup(from,size,flag);
if (to==NULL || ...) S
- memcpy(to, from, size);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/wireless/wl12xx/wl1271_main.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff -u -p a/drivers/net/wireless/wl12xx/wl1271_main.c b/drivers/net/wireless/wl12xx/wl1271_main.c
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
@@ -573,7 +573,7 @@ static int wl1271_fetch_nvs(struct wl127
goto out;
}
- wl->nvs = kmalloc(sizeof(struct wl1271_nvs_file), GFP_KERNEL);
+ wl->nvs = kmemdup(fw->data, sizeof(struct wl1271_nvs_file), GFP_KERNEL);
if (!wl->nvs) {
wl1271_error("could not allocate memory for the nvs file");
@@ -581,8 +581,6 @@ static int wl1271_fetch_nvs(struct wl127
goto out;
}
- memcpy(wl->nvs, fw->data, sizeof(struct wl1271_nvs_file));
-
out:
release_firmware(fw);
@@ -2350,15 +2348,13 @@ struct ieee80211_hw *wl1271_alloc_hw(voi
goto err_hw_alloc;
}
- plat_dev = kmalloc(sizeof(wl1271_device), GFP_KERNEL);
+ plat_dev = kmemdup(&wl1271_device, sizeof(wl1271_device), GFP_KERNEL);
if (!plat_dev) {
wl1271_error("could not allocate platform_device");
ret = -ENOMEM;
goto err_plat_alloc;
}
- memcpy(plat_dev, &wl1271_device, sizeof(wl1271_device));
-
wl = hw->priv;
memset(wl, 0, sizeof(*wl));
^ permalink raw reply
* [PATCH 10/37] drivers/net/wireless/libertas_tf: Use kmemdup
From: Julia Lawall @ 2010-05-15 21:16 UTC (permalink / raw)
To: John W. Linville, linux-wireless, netdev, linux-kernel,
kernel-janitors
From: Julia Lawall <julia@diku.dk>
Use kmemdup when some other buffer is immediately copied into the
allocated region.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
statement S;
@@
- to = \(kmalloc\|kzalloc\)(size,flag);
+ to = kmemdup(from,size,flag);
if (to==NULL || ...) S
- memcpy(to, from, size);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/wireless/libertas_tf/if_usb.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff -u -p a/drivers/net/wireless/libertas_tf/if_usb.c b/drivers/net/wireless/libertas_tf/if_usb.c
--- a/drivers/net/wireless/libertas_tf/if_usb.c
+++ b/drivers/net/wireless/libertas_tf/if_usb.c
@@ -538,7 +538,8 @@ static void if_usb_receive_fwload(struct
return;
}
- syncfwheader = kmalloc(sizeof(struct fwsyncheader), GFP_ATOMIC);
+ syncfwheader = kmemdup(skb->data, sizeof(struct fwsyncheader),
+ GFP_ATOMIC);
if (!syncfwheader) {
lbtf_deb_usbd(&cardp->udev->dev, "Failure to allocate syncfwheader\n");
kfree_skb(skb);
@@ -546,8 +547,6 @@ static void if_usb_receive_fwload(struct
return;
}
- memcpy(syncfwheader, skb->data, sizeof(struct fwsyncheader));
-
if (!syncfwheader->cmd) {
lbtf_deb_usb2(&cardp->udev->dev, "FW received Blk with correct CRC\n");
lbtf_deb_usb2(&cardp->udev->dev, "FW received Blk seqnum = %d\n",
^ permalink raw reply
* [PATCH 7/37] drivers/net/wireless/wl12xx: Use kmemdup
From: Julia Lawall @ 2010-05-15 21:15 UTC (permalink / raw)
To: Kalle Valo, John W. Linville, linux-wireless, netdev,
linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Use kmemdup when some other buffer is immediately copied into the
allocated region.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
statement S;
@@
- to = \(kmalloc\|kzalloc\)(size,flag);
+ to = kmemdup(from,size,flag);
if (to==NULL || ...) S
- memcpy(to, from, size);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/wireless/wl12xx/wl1251_main.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff -u -p a/drivers/net/wireless/wl12xx/wl1251_main.c b/drivers/net/wireless/wl12xx/wl1251_main.c
--- a/drivers/net/wireless/wl12xx/wl1251_main.c
+++ b/drivers/net/wireless/wl12xx/wl1251_main.c
@@ -124,7 +124,7 @@ static int wl1251_fetch_nvs(struct wl125
}
wl->nvs_len = fw->size;
- wl->nvs = kmalloc(wl->nvs_len, GFP_KERNEL);
+ wl->nvs = kmemdup(fw->data, wl->nvs_len, GFP_KERNEL);
if (!wl->nvs) {
wl1251_error("could not allocate memory for the nvs file");
@@ -132,8 +132,6 @@ static int wl1251_fetch_nvs(struct wl125
goto out;
}
- memcpy(wl->nvs, fw->data, wl->nvs_len);
-
ret = 0;
out:
^ permalink raw reply
* [PATCH 1/37] drivers/net/wireless/libertas: Use kmemdup
From: Julia Lawall @ 2010-05-15 21:12 UTC (permalink / raw)
To: Dan Williams, John W. Linville, libertas-dev, linux-wireless,
netdev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Use kmemdup when some other buffer is immediately copied into the
allocated region.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
statement S;
@@
- to = \(kmalloc\|kzalloc\)(size,flag);
+ to = kmemdup(from,size,flag);
if (to==NULL || ...) S
- memcpy(to, from, size);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/wireless/libertas/if_usb.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff -u -p a/drivers/net/wireless/libertas/if_usb.c b/drivers/net/wireless/libertas/if_usb.c
--- a/drivers/net/wireless/libertas/if_usb.c
+++ b/drivers/net/wireless/libertas/if_usb.c
@@ -618,16 +618,14 @@ static void if_usb_receive_fwload(struct
return;
}
- syncfwheader = kmalloc(sizeof(struct fwsyncheader), GFP_ATOMIC);
+ syncfwheader = kmemdup(skb->data + IPFIELD_ALIGN_OFFSET,
+ sizeof(struct fwsyncheader), GFP_ATOMIC);
if (!syncfwheader) {
lbs_deb_usbd(&cardp->udev->dev, "Failure to allocate syncfwheader\n");
kfree_skb(skb);
return;
}
- memcpy(syncfwheader, skb->data + IPFIELD_ALIGN_OFFSET,
- sizeof(struct fwsyncheader));
-
if (!syncfwheader->cmd) {
lbs_deb_usb2(&cardp->udev->dev, "FW received Blk with correct CRC\n");
lbs_deb_usb2(&cardp->udev->dev, "FW received Blk seqnum = %d\n",
^ permalink raw reply
* [PATCH] cfg80211: fix crash in cfg80211_set_freq()
From: Felix Fietkau @ 2010-05-15 13:46 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, johannes
Since wdev can be NULL, check it before dereferencing it
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
net/wireless/chan.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index d92d088..b01a6f6 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -50,7 +50,7 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
struct ieee80211_channel *chan;
int result;
- if (wdev->iftype == NL80211_IFTYPE_MONITOR)
+ if (wdev && wdev->iftype == NL80211_IFTYPE_MONITOR)
wdev = NULL;
if (wdev) {
--
1.6.4.2
^ permalink raw reply related
* [patch -next 2/2 v2] ath9k/debug: fixup the return codes
From: Dan Carpenter @ 2010-05-15 13:36 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Jouni Malinen, Sujith Manoharan, Vasanthakumar Thiagarajan,
Senthil Balasubramanian, John W. Linville, Felix Fietkau,
Jeff Hansen, linux-wireless, ath9k-devel
In-Reply-To: <20100514132539.GH5695@bicker>
Changed -EINVAL to -EFAULT if copy_to_user() failed.
Changed 0 to -ENOMEM if allocations failed.
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
V2: No change. Just updated to apply on top of V2 of the earlier patch
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index fad1c85..3ff6a52 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -56,7 +56,7 @@ static ssize_t write_file_debug(struct file *file, const char __user *user_buf,
len = min(count, sizeof(buf) - 1);
if (copy_from_user(buf, user_buf, len))
- return -EINVAL;
+ return -EFAULT;
buf[len] = '\0';
if (strict_strtoul(buf, 0, &mask))
@@ -100,7 +100,7 @@ static ssize_t write_file_tx_chainmask(struct file *file, const char __user *use
len = min(count, sizeof(buf) - 1);
if (copy_from_user(buf, user_buf, len))
- return -EINVAL;
+ return -EFAULT;
buf[len] = '\0';
if (strict_strtoul(buf, 0, &mask))
@@ -142,7 +142,7 @@ static ssize_t write_file_rx_chainmask(struct file *file, const char __user *use
len = min(count, sizeof(buf) - 1);
if (copy_from_user(buf, user_buf, len))
- return -EINVAL;
+ return -EFAULT;
buf[len] = '\0';
if (strict_strtoul(buf, 0, &mask))
@@ -175,7 +175,7 @@ static ssize_t read_file_dma(struct file *file, char __user *user_buf,
buf = kmalloc(DMA_BUF_LEN, GFP_KERNEL);
if (!buf)
- return 0;
+ return -ENOMEM;
ath9k_ps_wakeup(sc);
@@ -407,7 +407,7 @@ static ssize_t read_file_rcstat(struct file *file, char __user *user_buf,
max = 80 + sc->cur_rate_table->rate_cnt * 1024 + 1;
buf = kmalloc(max, GFP_KERNEL);
if (buf == NULL)
- return 0;
+ return -ENOMEM;
len += sprintf(buf, "%6s %6s %6s "
"%10s %10s %10s %10s\n",
@@ -644,7 +644,7 @@ static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
buf = kzalloc(size, GFP_KERNEL);
if (buf == NULL)
- return 0;
+ return -ENOMEM;
len += sprintf(buf, "%30s %10s%10s%10s\n\n", "BE", "BK", "VI", "VO");
@@ -718,7 +718,7 @@ static ssize_t read_file_recv(struct file *file, char __user *user_buf,
buf = kzalloc(size, GFP_KERNEL);
if (buf == NULL)
- return 0;
+ return -ENOMEM;
len += snprintf(buf + len, size - len,
"%18s : %10u\n", "CRC ERR",
@@ -838,7 +838,7 @@ static ssize_t write_file_regidx(struct file *file, const char __user *user_buf,
len = min(count, sizeof(buf) - 1);
if (copy_from_user(buf, user_buf, len))
- return -EINVAL;
+ return -EFAULT;
buf[len] = '\0';
if (strict_strtoul(buf, 0, ®idx))
@@ -880,7 +880,7 @@ static ssize_t write_file_regval(struct file *file, const char __user *user_buf,
len = min(count, sizeof(buf) - 1);
if (copy_from_user(buf, user_buf, len))
- return -EINVAL;
+ return -EFAULT;
buf[len] = '\0';
if (strict_strtoul(buf, 0, ®val))
^ permalink raw reply related
* [patch -next 1/2 v2] ath9k/debug: improve the snprintf() handling
From: Dan Carpenter @ 2010-05-15 13:34 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Jouni Malinen, Sujith Manoharan, Vasanthakumar Thiagarajan,
Senthil Balasubramanian, John W. Linville, Felix Fietkau,
Jeff Hansen, linux-wireless, ath9k-devel
In-Reply-To: <20100514132437.GG5695@bicker>
The snprintf() function returns the number of bytes that *would* have
been written (not counting the NULL terminator). We want to pass NULL
terminated strings to the user so we need to add one to the snprintf
return value. And if the return value is larger than the size of the
buffer we need to set it to the smaller value.
In this patch if there were one liners where string clearly fits into
the buffer, then I changed snprintf to sprintf(). It's confusing to use
the return value of snprintf() as a limitter without verifying that it's
smaller than size. This is what initially caught my attention here.
If we use the return value of sprintf() instead, future code auditors will
assume we've verified that it fits already.
Also I did find some places where it made sense to use the return value
after we've verified that it is smaller than the buffer size.
Finally the read_file_rcstat() function added an explicit NULL terminator
before calling snprintf(). That's unnecessary because snprintf() will
add the null terminator automatically.
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
V2: Include NULL terminator in the buffer which gets copied to the user.
Btw. I don't actually this hardware so I can't test this code. Sorry. :/
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 2ca9bba..fad1c85 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -41,8 +41,8 @@ static ssize_t read_file_debug(struct file *file, char __user *user_buf,
char buf[32];
unsigned int len;
- len = snprintf(buf, sizeof(buf), "0x%08x\n", common->debug_mask);
- return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+ len = sprintf(buf, "0x%08x\n", common->debug_mask);
+ return simple_read_from_buffer(user_buf, count, ppos, buf, len + 1);
}
static ssize_t write_file_debug(struct file *file, const char __user *user_buf,
@@ -85,8 +85,8 @@ static ssize_t read_file_tx_chainmask(struct file *file, char __user *user_buf,
char buf[32];
unsigned int len;
- len = snprintf(buf, sizeof(buf), "0x%08x\n", common->tx_chainmask);
- return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+ len = sprintf(buf, "0x%08x\n", common->tx_chainmask);
+ return simple_read_from_buffer(user_buf, count, ppos, buf, len + 1);
}
static ssize_t write_file_tx_chainmask(struct file *file, const char __user *user_buf,
@@ -127,8 +127,8 @@ static ssize_t read_file_rx_chainmask(struct file *file, char __user *user_buf,
char buf[32];
unsigned int len;
- len = snprintf(buf, sizeof(buf), "0x%08x\n", common->rx_chainmask);
- return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+ len = sprintf(buf, "0x%08x\n", common->rx_chainmask);
+ return simple_read_from_buffer(user_buf, count, ppos, buf, len + 1);
}
static ssize_t write_file_rx_chainmask(struct file *file, const char __user *user_buf,
@@ -247,6 +247,10 @@ static ssize_t read_file_dma(struct file *file, char __user *user_buf,
ath9k_ps_restore(sc);
+ len++;
+ if (len > DMA_BUF_LEN)
+ len = DMA_BUF_LEN;
+
retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
kfree(buf);
return retval;
@@ -357,6 +361,10 @@ static ssize_t read_file_interrupt(struct file *file, char __user *user_buf,
len += snprintf(buf + len, sizeof(buf) - len,
"%8s: %10u\n", "TOTAL", sc->debug.stats.istats.total);
+ len++;
+ if (len > sizeof(buf))
+ len = sizeof(buf);
+
return simple_read_from_buffer(user_buf, count, ppos, buf, len);
}
@@ -396,11 +404,10 @@ static ssize_t read_file_rcstat(struct file *file, char __user *user_buf,
if (sc->cur_rate_table == NULL)
return 0;
- max = 80 + sc->cur_rate_table->rate_cnt * 1024;
- buf = kmalloc(max + 1, GFP_KERNEL);
+ max = 80 + sc->cur_rate_table->rate_cnt * 1024 + 1;
+ buf = kmalloc(max, GFP_KERNEL);
if (buf == NULL)
return 0;
- buf[max] = 0;
len += sprintf(buf, "%6s %6s %6s "
"%10s %10s %10s %10s\n",
@@ -442,6 +449,10 @@ static ssize_t read_file_rcstat(struct file *file, char __user *user_buf,
stats->per);
}
+ len++;
+ if (len > max)
+ len = max;
+
retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
kfree(buf);
return retval;
@@ -504,6 +515,10 @@ static ssize_t read_file_wiphy(struct file *file, char __user *user_buf,
len += snprintf(buf + len, sizeof(buf) - len,
"addrmask: %pM\n", addr);
+ len++;
+ if (len > sizeof(buf))
+ len = sizeof(buf);
+
return simple_read_from_buffer(user_buf, count, ppos, buf, len);
}
@@ -647,6 +662,10 @@ static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
PR("DATA Underrun: ", data_underrun);
PR("DELIM Underrun: ", delim_underrun);
+ len++;
+ if (len > size)
+ len = size;
+
retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
kfree(buf);
@@ -750,6 +769,10 @@ static ssize_t read_file_recv(struct file *file, char __user *user_buf,
PHY_ERR("HT-LENGTH", ATH9K_PHYERR_HT_LENGTH_ILLEGAL);
PHY_ERR("HT-RATE", ATH9K_PHYERR_HT_RATE_ILLEGAL);
+ len++;
+ if (len > size)
+ len = size;
+
retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
kfree(buf);
@@ -801,8 +824,8 @@ static ssize_t read_file_regidx(struct file *file, char __user *user_buf,
char buf[32];
unsigned int len;
- len = snprintf(buf, sizeof(buf), "0x%08x\n", sc->debug.regidx);
- return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+ len = sprintf(buf, "0x%08x\n", sc->debug.regidx);
+ return simple_read_from_buffer(user_buf, count, ppos, buf, len + 1);
}
static ssize_t write_file_regidx(struct file *file, const char __user *user_buf,
@@ -842,8 +865,8 @@ static ssize_t read_file_regval(struct file *file, char __user *user_buf,
u32 regval;
regval = REG_READ_D(ah, sc->debug.regidx);
- len = snprintf(buf, sizeof(buf), "0x%08x\n", regval);
- return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+ len = sprintf(buf, "0x%08x\n", regval);
+ return simple_read_from_buffer(user_buf, count, ppos, buf, len + 1);
}
static ssize_t write_file_regval(struct file *file, const char __user *user_buf,
^ permalink raw reply related
* Re: [PATCH 1/2] wireless: rtl818x: rtl8180: add ids
From: Hin-Tak Leung @ 2010-05-15 11:21 UTC (permalink / raw)
To: Xose Vazquez Perez; +Cc: linux-wireless, linville, herton, Larry.Finger
In-Reply-To: <4BEE7AB0.2090206@gmail.com>
--- On Sat, 15/5/10, Xose Vazquez Perez <xose.vazquez@gmail.com> wrote:
> Sorry, but no realtek devices here.
I am sorry, if you do not own any of the devices for which you just copied a bunch of IDs from the windows driver, that means your patch is untested. What is your purpose of copying IDs from the windows driver?
There is no code sharing between the windows driver and the linux driver, and there are at least 5 variants of the device - so what the windows driver supports really bears no relationship with what the linux driver supports.
I don't think it is a good idea to blindly copy IDs from the windows driver without testing.
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: fix dma sync in rx path
From: Felix Fietkau @ 2010-05-15 10:44 UTC (permalink / raw)
To: Ming Lei; +Cc: lrodriguez, linux-wireless, linville
In-Reply-To: <20100515182540.6f4e140c@tom-lei>
On 2010-05-15 12:25 PM, Ming Lei wrote:
> From edd368e7436e7a80c5a43e7ad40cff1f3fa20806 Mon Sep 17 00:00:00 2001
> From: Ming Lei <tom.leiming@gmail.com>
> Date: Fri, 14 May 2010 17:35:51 +0800
> Subject: [PATCH 2/2] ath9k: fix dma sync in rx path(v2)
>
> If buffer is to be accessed by cpu after dma is over, but
> between dma mapping and dma unmapping, we should use
> dma_sync_single_for_cpu to sync the buffer between cpu with
> device. And dma_sync_single_for_device is used to let
> device gain the buffer again.
>
> v2: Felix pointed out dma_sync_single_for_device is needed to return
> buffer to device if an unsuccessful status bit check is found.
>
> Signed-off-by: Ming Lei <tom.leiming@gmail.com>
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Thanks, I will test that later and let you know if it works.
- Felix
^ permalink raw reply
* Re: [PATCH 1/2] wireless: rtl818x: rtl8180: add ids
From: Xose Vazquez Perez @ 2010-05-15 10:42 UTC (permalink / raw)
To: htl10; +Cc: linux-wireless, linville, herton, Larry.Finger
In-Reply-To: <263268.62614.qm@web23103.mail.ird.yahoo.com>
On 05/15/2010 01:49 AM, Hin-Tak Leung wrote:
> --- On Sat, 15/5/10, Xose Vazquez Perez <xose.vazquez@gmail.com> wrote:
>> taken from windows inf file
>>
>> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
>
> Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
>
> You added 3 device ids - do you own one of them by any chance? We like to know who has what hardware sometimes - just in case they are slightly different.
Sorry, but no realtek devices here.
--
If less is more than more, most is more than less.
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: fix dma sync in rx path
From: Ming Lei @ 2010-05-15 10:25 UTC (permalink / raw)
To: Ming Lei; +Cc: Felix Fietkau, lrodriguez, linux-wireless, linville
In-Reply-To: <AANLkTikFtb1j7x9-d-SpV8AAODQAxNAobIZePCQNLbip@mail.gmail.com>
>From edd368e7436e7a80c5a43e7ad40cff1f3fa20806 Mon Sep 17 00:00:00 2001
From: Ming Lei <tom.leiming@gmail.com>
Date: Fri, 14 May 2010 17:35:51 +0800
Subject: [PATCH 2/2] ath9k: fix dma sync in rx path(v2)
If buffer is to be accessed by cpu after dma is over, but
between dma mapping and dma unmapping, we should use
dma_sync_single_for_cpu to sync the buffer between cpu with
device. And dma_sync_single_for_device is used to let
device gain the buffer again.
v2: Felix pointed out dma_sync_single_for_device is needed to return
buffer to device if an unsuccessful status bit check is found.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/recv.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index a3fe6e1..f4453f0 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -694,12 +694,16 @@ static bool ath_edma_get_buffers(struct ath_softc *sc,
bf = SKB_CB_ATHBUF(skb);
BUG_ON(!bf);
- dma_sync_single_for_device(sc->dev, bf->bf_buf_addr,
+ dma_sync_single_for_cpu(sc->dev, bf->bf_buf_addr,
common->rx_bufsize, DMA_FROM_DEVICE);
ret = ath9k_hw_process_rxdesc_edma(ah, NULL, skb->data);
- if (ret == -EINPROGRESS)
+ if (ret == -EINPROGRESS) {
+ /*let device gain the buffer again*/
+ dma_sync_single_for_device(sc->dev, bf->bf_buf_addr,
+ common->rx_bufsize, DMA_FROM_DEVICE);
return false;
+ }
__skb_unlink(skb, &rx_edma->rx_fifo);
if (ret == -EINVAL) {
@@ -808,7 +812,7 @@ static struct ath_buf *ath_get_next_rx_buf(struct ath_softc *sc,
* 1. accessing the frame
* 2. requeueing the same buffer to h/w
*/
- dma_sync_single_for_device(sc->dev, bf->bf_buf_addr,
+ dma_sync_single_for_cpu(sc->dev, bf->bf_buf_addr,
common->rx_bufsize,
DMA_FROM_DEVICE);
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH 2/2] ath9k: fix dma sync in rx path
From: Ming Lei @ 2010-05-15 9:52 UTC (permalink / raw)
To: Felix Fietkau; +Cc: lrodriguez, linux-wireless, linville
In-Reply-To: <4BEE689A.9060102@openwrt.org>
2010/5/15 Felix Fietkau <nbd@openwrt.org>:
> The second part of your patch might be OK then (I'm not really sure).
> But the first part is definitely wrong, since with EDMA Rx, the
> descriptor data is part of the buffer, so the cache needs to be
> invalidated for every access until the status bit shows that it has been
> completed.
> This could probably be fixed by running dma_sync_single_for_device after
> an unsuccessful status bit check and also after the descriptor part has
Yes, dma_sync_single_for_device is needed to return buffer to device
if an unsuccessful status bit check is found.
> been zero'd out before passing the buffer on to the hw.
The patch does not touch this dma_sync_single_for_device.
--
Lei Ming
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: fix dma sync in rx path
From: Felix Fietkau @ 2010-05-15 9:25 UTC (permalink / raw)
To: Ming Lei; +Cc: lrodriguez, linux-wireless, linville
In-Reply-To: <AANLkTikV8cAc4Njpa1cXq1BHRExkwbaKwjlyyH52rgqO@mail.gmail.com>
On 2010-05-15 3:31 AM, Ming Lei wrote:
> 2010/5/15 Felix Fietkau <nbd@openwrt.org>:
>> On 2010-05-14 5:27 PM, Ming Lei wrote:
>>> 2010/5/14 Felix Fietkau <nbd@openwrt.org>:
>>>> On 2010-05-14 3:16 PM, tom.leiming@gmail.com wrote:
>>>>> From: Ming Lei <tom.leiming@gmail.com>
>>>>>
>>>>> If buffer is to be accessed by cpu after dma transfer is over, but
>>>>> between dma mapping and dma unmapping, we should use
>>>>> dma_sync_single_for_cpu to sync the buffer between cpu with
>>>>> device. And dma_sync_single_for_device is used to let
>>>>> device gain the buffer again.
>>>> I think this patch is wrong. On most MIPS devices,
>>>> dma_sync_single_for_cpu is a no-op. In fact, with this patch, the rx
>>>> path fails very quickly.
>>>
>>> Sorry for my bad email client.
>>>
>>> On most MIPS devices, dma_sync_single_for_cpu does same things
>>> almost with dma_unmap_single(plat_unmap_dma_mem is no-op). If
>>> dma_unmap_single is enough, dma_sync_single_for_cpu is certainly
>>> enough,
>>> isn't it?
>> Because I did some testing with these functions while writing the code,
>> I already know that dma_sync_single_for_cpu is not enough in this case.
>
> In theory, dma_sync_single_for_cpu is enough in this case, as explained
> in the commit log.
>
> On MIPS, cache invalidation is done in dma mapping for DMA_FROM_DEVICE
> direction, so it is correct that dma_sync_single_for_cpu or dma unmapping
> is only a no-op since access from CPU will trigger a refetch of the buffer
> from memory into cache.
>
> Also dma_sync_single_for_device still does cache invalidation for
> DMA_FROM_DEVICE direction, if it has to be done in this case to avoid rx
> failure, I guess there is some code which does touch the dma buffer
> after dma mapping but before dma_sync_single_for_device(should be
> dma_sync_single_for_cpu), maybe before dma transfer is over.
> If so, it should be a bug since it violates the dma api constraint, maybe
> we should have a careful review to check the dma api rule.
The second part of your patch might be OK then (I'm not really sure).
But the first part is definitely wrong, since with EDMA Rx, the
descriptor data is part of the buffer, so the cache needs to be
invalidated for every access until the status bit shows that it has been
completed.
This could probably be fixed by running dma_sync_single_for_device after
an unsuccessful status bit check and also after the descriptor part has
been zero'd out before passing the buffer on to the hw.
- Felix
^ permalink raw reply
* Re: Strange ACK Behaviour with ath9k
From: Roberto Riggio @ 2010-05-15 9:24 UTC (permalink / raw)
To: Björn Smedman; +Cc: linux-wireless
In-Reply-To: <AANLkTimnzAJd9Y02m8OBVLHphL5pbFw56M2LfB1L5oKz@mail.gmail.com>
Hi,
at both ends of the communications I get the hwaddr from the iwconfig
command and I pass the output to my software. In fact the other host
acks the frame carrying the echo request message and generates the
corresponding echo reply whose frame is actually acked by the recipient
the point is that they keep resending the frames until the max data retries
is reached.
On 05/14/2010 01:15 AM, Björn Smedman wrote:
> Hi Roberto,
>
> When I've seen this it has been caused by a mismatch between the
> addresses in the injected frame and that configured in the hardware.
> The transmitting radio doesn't understand it is the intended recipient
> of the ack and continues retrying.
>
> /Björn
>
> On Thu, May 13, 2010 at 6:04 PM, Roberto Riggio
> <roberto.riggio@create-net.org> wrote:
>
>> Hi,
>>
>> I'm having a very strange behaviour between two sr71a (ath9k) cards
>> operating in monitor mode. I'm using the following patch to specify
>> the transmission rate frame by frame:
>>
>> http://thread.gmane.org/gmane.linux.kernel.wireless.general/47441
>>
>>
>> However if I try to send some traffic between the two nodes with both
>> interfaces operating in monitor mode I can see from a third machine
>> using wireshark that albeit the frame is sent and the corresponding
>> ack generated, the originator seems to ignore the ACK and keepts
>> retransmitting the frame. This is happening on both ends of the
>> communication (i'm ping one node from the other).
>>
>> As a matter of fact i thought that ACK are handled directly by the
>> firmware. Any hints?
>>
>> R.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* [PATCH V2] ssb: Handle alternate SSPROM location
From: Larry Finger @ 2010-05-15 3:08 UTC (permalink / raw)
To: John W Linville, Michael Buesch; +Cc: b43-dev, linux-wireless
In kernel Bugzilla #15825 (2 users), in a wireless mailing list thread
(http://lists.infradead.org/pipermail/b43-dev/2010-May/000124.html), and on a
netbook owned by John Linville
(http://marc.info/?l=linux-wireless&m=127230751408818&w=4), there are reports
of ssb failing to detect an SPROM at the normal location. After studying the
MMIO trace dump for the Broadcom wl driver, it was determined that the affected
boxes had a relocated SPROM.
This patch fixes all systems that have reported this problem.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@kernel.org>
---
John,
This patch and the one by Gabor entitled "[PATCH] ssb: Implement
fast powerup delay calculation" are needed to fix these systems. As there is the
possibility that this patch will break some 14e4:4315 devices, it should stew in
testing for a while. I am confident enough in it to add the Cc for stable.
V2 - remove initialization per Michaels's comment. Sorry it has taken so long - I'm
traveling.
Larry
---
Index: wireless-testing/drivers/ssb/pci.c
===================================================================
--- wireless-testing.orig/drivers/ssb/pci.c
+++ wireless-testing/drivers/ssb/pci.c
@@ -631,8 +631,17 @@ static int ssb_pci_sprom_get(struct ssb_
return -ENODEV;
}
- bus->sprom_offset = (bus->chipco.dev->id.revision < 31) ?
- SSB_SPROM_BASE1 : SSB_SPROM_BASE31;
+ /* get SPROM offset: SSB_SPROM_BASE1 except for chipcommon rev >= 31
+ * or chip ID is 0x4312 and chipcommon status & 3 == 2
+ */
+ if (bus->chipco.dev->id.revision >= 31)
+ bus->sprom_offset = SSB_SPROM_BASE31;
+ else if (bus->chip_id == 0x4312 && (bus->chipco.status & 0x03) == 2)
+ bus->sprom_offset = SSB_SPROM_BASE31;
+ else
+ bus->sprom_offset = SSB_SPROM_BASE1;
+
+ ssb_dprintk(KERN_INFO PFX "SPROM offset is 0x%x\n", bus->sprom_offset);
buf = kcalloc(SSB_SPROMSIZE_WORDS_R123, sizeof(u16), GFP_KERNEL);
if (!buf)
Index: wireless-testing/drivers/ssb/driver_chipcommon.c
===================================================================
--- wireless-testing.orig/drivers/ssb/driver_chipcommon.c
+++ wireless-testing/drivers/ssb/driver_chipcommon.c
@@ -256,11 +256,12 @@ void ssb_chipcommon_init(struct ssb_chip
return; /* We don't have a ChipCommon */
if (cc->dev->id.revision >= 11)
cc->status = chipco_read32(cc, SSB_CHIPCO_CHIPSTAT);
+ ssb_dprintk(KERN_INFO PFX "chipcommon status is 0x%x\n", cc->status);
ssb_pmu_init(cc);
chipco_powercontrol_init(cc);
ssb_chipco_set_clockmode(cc, SSB_CLKMODE_FAST);
delay = calc_fast_powerup_delay(cc);
- ssb_printk(KERN_INFO PFX "fast_pwrup_delay is %d\n", delay);
+ ssb_dprintk(KERN_INFO PFX "fast_pwrup_delay is %d\n", delay);
cc->fast_pwrup_delay = delay;
ssb_write16(cc->dev, SSB_MMIO_POWERUP_DELAY, delay);
}
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: fix dma sync in rx path
From: Ming Lei @ 2010-05-15 1:31 UTC (permalink / raw)
To: Felix Fietkau; +Cc: lrodriguez, linux-wireless, linville
In-Reply-To: <4BED7809.3090204@openwrt.org>
2010/5/15 Felix Fietkau <nbd@openwrt.org>:
> On 2010-05-14 5:27 PM, Ming Lei wrote:
>> 2010/5/14 Felix Fietkau <nbd@openwrt.org>:
>>> On 2010-05-14 3:16 PM, tom.leiming@gmail.com wrote:
>>>> From: Ming Lei <tom.leiming@gmail.com>
>>>>
>>>> If buffer is to be accessed by cpu after dma transfer is over, but
>>>> between dma mapping and dma unmapping, we should use
>>>> dma_sync_single_for_cpu to sync the buffer between cpu with
>>>> device. And dma_sync_single_for_device is used to let
>>>> device gain the buffer again.
>>> I think this patch is wrong. On most MIPS devices,
>>> dma_sync_single_for_cpu is a no-op. In fact, with this patch, the rx
>>> path fails very quickly.
>>
>> Sorry for my bad email client.
>>
>> On most MIPS devices, dma_sync_single_for_cpu does same things
>> almost with dma_unmap_single(plat_unmap_dma_mem is no-op). If
>> dma_unmap_single is enough, dma_sync_single_for_cpu is certainly
>> enough,
>> isn't it?
> Because I did some testing with these functions while writing the code,
> I already know that dma_sync_single_for_cpu is not enough in this case.
In theory, dma_sync_single_for_cpu is enough in this case, as explained
in the commit log.
On MIPS, cache invalidation is done in dma mapping for DMA_FROM_DEVICE
direction, so it is correct that dma_sync_single_for_cpu or dma unmapping
is only a no-op since access from CPU will trigger a refetch of the buffer
from memory into cache.
Also dma_sync_single_for_device still does cache invalidation for
DMA_FROM_DEVICE direction, if it has to be done in this case to avoid rx
failure, I guess there is some code which does touch the dma buffer
after dma mapping but before dma_sync_single_for_device(should be
dma_sync_single_for_cpu), maybe before dma transfer is over.
If so, it should be a bug since it violates the dma api constraint, maybe
we should have a careful review to check the dma api rule.
>
> Maybe we need to place the dma_sync_single_for_device call elsewhere and
> then move the dma_sync_single_for_cpu call there afterwads, but simply
> replacing this instance as is done in your patch *will* cause regressions.
>
> - Felix
>
--
Lei Ming
^ permalink raw reply
* Re: ath9k: BUG kmalloc-8192: Poison overwritten
From: Justin P. Mattock @ 2010-05-15 1:26 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, Bruno Randolf, linux-wireless@vger.kernel.org,
Linux Kernel Mailing List, Miles Lane
In-Reply-To: <20100515005201.GH28198@tux>
Justin P. Mattock
On May 14, 2010, at 5:52 PM, "Luis R. Rodriguez"
<lrodriguez@atheros.com> wrote:
> On Fri, May 14, 2010 at 03:32:48PM -0700, Justin P. Mattock wrote:
>> ATH9K: cachelsz 256 rxbufsize 3904
>
> OK I see nothing odd with these values, and I do not see how
> these values can make ath_rxbuf_alloc() barf. I'd like to
> reproduce this myself at least once, I left iperf running over
> night with no rants from SLAB. I should note this should be
> reproducible with RX only if it is ath_rxbuf_alloc() to blame
> but without a concrete reproducible instructions it is hard
> to guess what to do and if this can only come up during RX.
>
> Can you describe a little more when you have seen this? What
> were you doing exactly, for how long? When was the last time
> you saw this, what were you doing then?
>
> Luis
This is hard to reproduce(reason for looking a kmemchek).
As for what I remember, walked into the las Vegas convention cntr
(Hilton),
Found the Internet hub, scanned for networks, wicd said it was
connected, opened firefox to see the prices, ended up seeing a blank
page(at this point didn't look at dmesg(could have already happened)),
then switched to another network(did this a few times),
Eventually opened firefox(saw the prices, said fuc*k this), then
started to read up on i8042.c(cause Linus was pull requesting and I
wanted to find out what was going on in that area), then
Checked dmesg, and voilà there the bug is.
After this rebooted, was hoping this was reproducable for a bisect,
but realized it's not the reproducable..
Justin P. Mattock
^ permalink raw reply
* Re: ath9k: BUG kmalloc-8192: Poison overwritten
From: Luis R. Rodriguez @ 2010-05-15 0:52 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Luis Rodriguez, Bruno Randolf, linux-wireless@vger.kernel.org,
Linux Kernel Mailing List, Miles Lane
In-Reply-To: <B796B1C7-D7CC-457A-9C86-7C70EA9451CF@gmail.com>
On Fri, May 14, 2010 at 03:32:48PM -0700, Justin P. Mattock wrote:
> ATH9K: cachelsz 256 rxbufsize 3904
OK I see nothing odd with these values, and I do not see how
these values can make ath_rxbuf_alloc() barf. I'd like to
reproduce this myself at least once, I left iperf running over
night with no rants from SLAB. I should note this should be
reproducible with RX only if it is ath_rxbuf_alloc() to blame
but without a concrete reproducible instructions it is hard
to guess what to do and if this can only come up during RX.
Can you describe a little more when you have seen this? What
were you doing exactly, for how long? When was the last time
you saw this, what were you doing then?
Luis
^ permalink raw reply
* Re: [PATCH] ath5k: consistently use rx_bufsize for RX DMA
From: Luis R. Rodriguez @ 2010-05-15 0:34 UTC (permalink / raw)
To: Bruno Randolf
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, bob@bobcopeland.com,
ath5k-devel@lists.ath5k.org
In-Reply-To: <201005150705.22887.br1@einfach.org>
On Fri, May 14, 2010 at 03:05:22PM -0700, Bruno Randolf wrote:
> On Saturday 15 May 2010 01:04:34 Luis R. Rodriguez wrote:
> > On Fri, May 14, 2010 at 12:50 AM, Bruno Randolf <br1@einfach.org> wrote:
> > > We should use the same buffer size we set up for DMA also in the hardware
> > > descriptor. Previously we used common->rx_bufsize for setting up the DMA
> > > mapping, but skb_tailroom(skb) for the size we tell to the hardware in
> > > the descriptor itself. The problem is that skb_tailroom(skb) can give us
> > > a larger value than the size we set up for DMA before: In my case
> > > rx_bufsize is 2528, and we allocated an skb of 2559 bytes length,
> > > including padding for cache alignment, but sbk_tailroom() was 2592. Just
> > > consistently use rx_bufsize for all RX DMA memory sizes.
> > >
> > > Also check the return value of setup function.
> > >
> > > Signed-off-by: Bruno Randolf <br1@einfach.org>
> >
> > Cc: stable?
>
> might be useful. i just would like some review before that.
FWIW
Reviewed-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> > Is that other bug reproducible, can the user test this to cure it?
>
> not sure. seems like he can with running kismet for a few hours (i'm doing the
> same over the weekend). i doubt that this is "the" bug though...
Oh I'm not assuming it is, but it still looks like a valid stable bug fix to me.
Luis
^ 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