* [PATCH RESENT] staging: r8188eu: Move writeN buffer off stack
From: Larry Finger @ 2013-10-18 21:39 UTC (permalink / raw)
To: gregkh; +Cc: netdev, Larry Finger, devel
The driver places a 254-byte buffer on the stack when writing long output.
To reduce stack usage, a buffer of the required length is acquired using
kmemdup().
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/staging/rtl8188eu/hal/usb_ops_linux.c | 58 +++++++++++++++++++--------
1 file changed, 42 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/usb_ops_linux.c
b/drivers/staging/rtl8188eu/hal/usb_ops_linux.c
index 787763e..7ba52a1 100644
--- a/drivers/staging/rtl8188eu/hal/usb_ops_linux.c
+++ b/drivers/staging/rtl8188eu/hal/usb_ops_linux.c
@@ -267,28 +267,54 @@ static int usb_write32(struct intf_hdl *pintfhdl, u32
addr, u32 val)
static int usb_writeN(struct intf_hdl *pintfhdl, u32 addr, u32 length, u8 *pdata)
{
- u8 request;
- u8 requesttype;
- u16 wvalue;
- u16 index;
- u16 len;
- u8 buf[VENDOR_CMD_MAX_DATA_LEN] = {0};
+ struct adapter *adapt = pintfhdl->padapter;
+ struct dvobj_priv *dvobjpriv = adapter_to_dvobj(adapt);
+ struct usb_device *udev = dvobjpriv->pusbdev;
+ u8 request = REALTEK_USB_VENQT_CMD_REQ;
+ u8 reqtype = REALTEK_USB_VENQT_WRITE;
+ u16 value = (u16)(addr & 0x0000ffff);
+ u16 index = REALTEK_USB_VENQT_CMD_IDX;
+ int pipe = usb_sndctrlpipe(udev, 0); /* write_out */
+ u8 *buffer;
int ret;
+ int vendorreq_times = 0;
- _func_enter_;
-
- request = 0x05;
- requesttype = 0x00;/* write_out */
- index = 0;/* n/a */
+ buffer = kmemdup(pdata, length, GFP_ATOMIC);
+ if (!buffer)
+ return -ENOMEM;
+ while (++vendorreq_times <= MAX_USBCTRL_VENDORREQ_TIMES) {
+ pipe = usb_sndctrlpipe(udev, 0);/* write_out */
- wvalue = (u16)(addr&0x0000ffff);
- len = length;
- memcpy(buf, pdata, len);
+ ret = rtw_usb_control_msg(udev, pipe, request, reqtype,
+ value, index, buffer, length,
+ RTW_USB_CONTROL_MSG_TIMEOUT);
- ret = usbctrl_vendorreq(pintfhdl, request, wvalue, index, buf, len,
requesttype);
+ if (ret == length) { /* Success this control transfer. */
+ rtw_reset_continual_urb_error(dvobjpriv);
+ } else { /* error cases */
+ DBG_88E("reg 0x%x, usb %u write fail, status:%d value=0x%x,
vendorreq_times:%d\n",
+ value, length, ret, *(u32 *)pdata, vendorreq_times);
- _func_exit_;
+ if (ret < 0) {
+ if (ret == (-ESHUTDOWN) || ret == -ENODEV) {
+ adapt->bSurpriseRemoved = true;
+ } else {
+ struct hal_data_8188e *haldata = GET_HAL_DATA(adapt);
+ haldata->srestpriv.Wifi_Error_Status = USB_VEN_REQ_CMD_FAIL;
+ }
+ }
+ if (rtw_inc_and_chk_continual_urb_error(dvobjpriv)) {
+ adapt->bSurpriseRemoved = true;
+ break;
+ }
+ }
+ /* firmware download is checksumed, don't retry */
+ if ((value >= FW_8188E_START_ADDRESS &&
+ value <= FW_8188E_END_ADDRESS) || ret == length)
+ break;
+ }
+ kfree(buffer);
return ret;
}
-- 1.8.4
^ permalink raw reply related
* [PATCH net-next] ipv6: gso: remove redundant locking
From: Eric Dumazet @ 2013-10-18 21:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
ipv6_gso_send_check() and ipv6_gso_segment() are called by
skb_mac_gso_segment() under rcu lock, no need to use
rcu_read_lock() / rcu_read_unlock()
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv6/ip6_offload.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index d82de72..b405fba 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -66,7 +66,6 @@ static int ipv6_gso_send_check(struct sk_buff *skb)
__skb_pull(skb, sizeof(*ipv6h));
err = -EPROTONOSUPPORT;
- rcu_read_lock();
ops = rcu_dereference(inet6_offloads[
ipv6_gso_pull_exthdrs(skb, ipv6h->nexthdr)]);
@@ -74,7 +73,6 @@ static int ipv6_gso_send_check(struct sk_buff *skb)
skb_reset_transport_header(skb);
err = ops->callbacks.gso_send_check(skb);
}
- rcu_read_unlock();
out:
return err;
@@ -113,13 +111,12 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
segs = ERR_PTR(-EPROTONOSUPPORT);
proto = ipv6_gso_pull_exthdrs(skb, ipv6h->nexthdr);
- rcu_read_lock();
+
ops = rcu_dereference(inet6_offloads[proto]);
if (likely(ops && ops->callbacks.gso_segment)) {
skb_reset_transport_header(skb);
segs = ops->callbacks.gso_segment(skb, features);
}
- rcu_read_unlock();
if (IS_ERR(segs))
goto out;
^ permalink raw reply related
* Re: [PATCH 1/9 RESENT] staging: r8188eu: Set device type to wlan
From: Sergei Shtylyov @ 2013-10-18 21:58 UTC (permalink / raw)
To: Larry Finger, gregkh; +Cc: netdev, devel
In-Reply-To: <5261A904.9030908@lwfinger.net>
Hello.
On 10/19/2013 01:32 AM, Larry Finger wrote:
> The latest version of NetworkManager does not recognize the device as wireless
> without this change.
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> drivers/staging/rtl8188eu/os_dep/os_intfs.c | 5 +++++
> 1 file changed, 5 insertions(+)
> diff --git a/drivers/staging/rtl8188eu/os_dep/os_intfs.c
> b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
> index da9f0d5..17659bb 100644
> --- a/drivers/staging/rtl8188eu/os_dep/os_intfs.c
> +++ b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
> @@ -707,6 +707,10 @@ int rtw_init_netdev_name(struct net_device *pnetdev,
> const char *ifname)
> return 0;
> }
> +static const struct device_type wlan_type = {
Hm, a space got added before +, so the patch was somehow broken.
> + .name = "wlan",
> +};
> +
> struct net_device *rtw_init_netdev(struct adapter *old_padapter)
> {
> struct adapter *padapter;
> @@ -722,6 +726,7 @@ struct net_device *rtw_init_netdev(struct adapter
> *old_padapter)
> if (!pnetdev)
> return NULL;
> + pnetdev->dev.type = &wlan_type;
Here too.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/9 RESENT] staging: r8188eu: Fix Sparse warnings in rtw_wlan_util
From: Ben Hutchings @ 2013-10-18 22:05 UTC (permalink / raw)
To: Larry Finger; +Cc: gregkh, netdev, devel
In-Reply-To: <5261A928.3020007@lwfinger.net>
On Fri, 2013-10-18 at 16:33 -0500, Larry Finger wrote:
> Sparse shows the following warning:
>
> CHECK drivers/staging/rtl8188eu/core/rtw_wlan_util.c
> drivers/staging/rtl8188eu/core/rtw_wlan_util.c:1635:25: warning: cast to
> restricted __le16
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
> b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
> index 153ec61..30ba18c 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
> @@ -1632,7 +1632,7 @@ void process_addba_req(struct adapter *padapter, u8
> *paddba_req, u8 *addr)
> psta = rtw_get_stainfo(pstapriv, addr);
> if (psta) {
> - param = le16_to_cpu(preq->BA_para_set);
> + param = preq->BA_para_set;
preq is pointing to a header which has fixed byte order on the wire, so
this field presumably really is little-endian and the struct definition
should be changed.
Comapre the various headers in drivers/staging/rtl8188eu/include/wifi.h
with struct ieee80211_mgmt in include/linux/ieee80211.h.
Ben.
> tid = (param>>2)&0x0f;
> preorder_ctrl = &psta->recvreorder_ctrl[tid];
> preorder_ctrl->indicate_seq = 0xffff;
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 3/9 RESENT] staging: r8188eu: Fix sparse warnings in ioctl_linux.c
From: Ben Hutchings @ 2013-10-18 22:08 UTC (permalink / raw)
To: Larry Finger; +Cc: gregkh, netdev, devel
In-Reply-To: <5261A967.9000909@lwfinger.net>
On Fri, 2013-10-18 at 16:34 -0500, Larry Finger wrote:
> Sparse checking results in the following warnings:
>
> CHECK drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
> drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:3932:17: warning: cast removes
> address space of expression
> drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:3933:31: warning: incorrect type
> in argument 1 (different address spaces)
[...]
> - DBG_88E("[%s] extra = %s\n", __func__, (char *)wrqu->data.pointer);
> - if (!memcmp(wrqu->data.pointer, "status", 6)) {
> + DBG_88E("[%s] extra = %s\n", __func__, (__force char *)wrqu->data.pointer);
> + if (!memcmp((__force const char *)wrqu->data.pointer, "status", 6)) {
[...]
This is hiding the problem, not fixing it.
This private interface needs to be removed anyway.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH 1/1] drivers: net: wireless: rtlwifi: Fix wrong assignment
From: Felipe Pena @ 2013-10-18 22:15 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, John W. Linville
Cc: linux-wireless, netdev, linux-kernel, Felipe Pena
There is a typo in the struct member name on assignment when checking
rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40, the check uses pwrgroup_ht40
for bound limit and uses pwrgroup_ht20 when assigning instead.
Signed-off-by: Felipe Pena <felipensp@gmail.com>
---
drivers/net/wireless/rtlwifi/rtl8192se/rf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
index 5061f1d..92d38ab 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
@@ -265,7 +265,7 @@ static void _rtl92s_get_txpower_writeval_byregulatory(struct ieee80211_hw *hw,
rtlefuse->pwrgroup_ht40
[RF90_PATH_A][chnl - 1]) {
pwrdiff_limit[i] =
- rtlefuse->pwrgroup_ht20
+ rtlefuse->pwrgroup_ht40
[RF90_PATH_A][chnl - 1];
}
} else {
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 1/1] drivers: net: wireless: rtlwifi: Fix wrong assignment
From: Larry Finger @ 2013-10-18 22:27 UTC (permalink / raw)
To: Felipe Pena, Chaoming Li, John W. Linville
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1382134538-3719-1-git-send-email-felipensp@gmail.com>
On 10/18/2013 05:15 PM, Felipe Pena wrote:
> There is a typo in the struct member name on assignment when checking
> rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40, the check uses pwrgroup_ht40
> for bound limit and uses pwrgroup_ht20 when assigning instead.
>
> Signed-off-by: Felipe Pena <felipensp@gmail.com>
> ---
> drivers/net/wireless/rtlwifi/rtl8192se/rf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
> index 5061f1d..92d38ab 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
> @@ -265,7 +265,7 @@ static void _rtl92s_get_txpower_writeval_byregulatory(struct ieee80211_hw *hw,
> rtlefuse->pwrgroup_ht40
> [RF90_PATH_A][chnl - 1]) {
> pwrdiff_limit[i] =
> - rtlefuse->pwrgroup_ht20
> + rtlefuse->pwrgroup_ht40
> [RF90_PATH_A][chnl - 1];
> }
> } else {
Good catch. There is only one problem - by convention we skip
drivers/net/wireless in the subject. That would probably be OK, but you are
missing the rtl8192se part, which needs to be there. I suggest that you use the
subject "rtlwifi: rtl8192de: Fix wrong assignment".
Larry
^ permalink raw reply
* Re: [PATCH 1/1] drivers: net: wireless: rtlwifi: Fix wrong assignment
From: Felipe Pena @ 2013-10-18 22:43 UTC (permalink / raw)
To: Larry Finger
Cc: Chaoming Li, John W. Linville, linux-wireless, netdev,
linux-kernel
In-Reply-To: <5261B5D6.2020002@lwfinger.net>
On Fri, Oct 18, 2013 at 7:27 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 10/18/2013 05:15 PM, Felipe Pena wrote:
>>
>> There is a typo in the struct member name on assignment when checking
>> rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40, the check uses
>> pwrgroup_ht40
>> for bound limit and uses pwrgroup_ht20 when assigning instead.
>>
>> Signed-off-by: Felipe Pena <felipensp@gmail.com>
>> ---
>> drivers/net/wireless/rtlwifi/rtl8192se/rf.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
>> b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
>> index 5061f1d..92d38ab 100644
>> --- a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
>> +++ b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
>> @@ -265,7 +265,7 @@ static void
>> _rtl92s_get_txpower_writeval_byregulatory(struct ieee80211_hw *hw,
>> rtlefuse->pwrgroup_ht40
>> [RF90_PATH_A][chnl - 1]) {
>> pwrdiff_limit[i] =
>> - rtlefuse->pwrgroup_ht20
>> + rtlefuse->pwrgroup_ht40
>> [RF90_PATH_A][chnl - 1];
>> }
>> } else {
>
>
> Good catch. There is only one problem - by convention we skip
> drivers/net/wireless in the subject. That would probably be OK, but you are
> missing the rtl8192se part, which needs to be there. I suggest that you use
> the subject "rtlwifi: rtl8192de: Fix wrong assignment".
>
> Larry
>
>
Thanks for the reply. I'll re-send it with the suggested subject.
--
Regards,
Felipe Pena
^ permalink raw reply
* Re: [PATCH nf-next] netfilter: xtables: lightweight process control group matching
From: Eric W. Biederman @ 2013-10-18 23:21 UTC (permalink / raw)
To: Daniel Borkmann
Cc: pablo-Cap9r6Oaw4JrovVCs/uTlw,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Tejun Heo,
cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1380910855-12325-1-git-send-email-dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Daniel Borkmann <dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> Implementation of PID-based matching would not be appropriate
> as they frequently change, and child tracking would make that
> even more complex and ugly. Cgroups would be a perfect candidate
> for accomplishing that as they associate a set of tasks with a
> set of parameters for one or more subsystems, in our case the
> netfilter subsystem, which, of course, can be combined with other
> cgroup subsystems into something more complex.
I am coming to this late. But two concrete suggestions.
1) process groups and sessions don't change as frequently as pids.
2) It is possible to put a set of processes in their own network
namespace and pipe just the packets you want those processes to
use into that network namespace. Using an ingress queueing filter
makes that process very efficient even if you have to filter by port.
So I don't think you need cgroups to solve this problem at all.
Eric
^ permalink raw reply
* [PATCH] wireless: rt2800lib: Fix typo on checking
From: Felipe Pena @ 2013-10-19 0:20 UTC (permalink / raw)
To: Ivo van Doorn, Gertjan van Wingerde, Helmut Schaa,
John W. Linville
Cc: linux-wireless, users, netdev, linux-kernel, Felipe Pena
On rt2800_config_channel_rf53xx function the member default_power1 is checked
for bound limit, but default_power2 is used instead.
Signed-off-by: Felipe Pena <felipensp@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 88ce656..1c2ce93 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2650,7 +2650,7 @@ static void rt2800_config_channel_rf53xx(struct rt2x00_dev *rt2x00dev,
if (rt2x00_rt(rt2x00dev, RT5392)) {
rt2800_rfcsr_read(rt2x00dev, 50, &rfcsr);
- if (info->default_power1 > POWER_BOUND)
+ if (info->default_power2 > POWER_BOUND)
rt2x00_set_field8(&rfcsr, RFCSR50_TX, POWER_BOUND);
else
rt2x00_set_field8(&rfcsr, RFCSR50_TX,
--
1.7.10.4
^ permalink raw reply related
* [PATCH] rtlwifi: rtl8192se: Fix wrong assignment
From: Felipe Pena @ 2013-10-19 0:52 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, John W. Linville
Cc: linux-wireless, netdev, linux-kernel, Felipe Pena
There is a typo in the struct member name on assignment when checking
rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40, the check uses pwrgroup_ht40
for bound limit and uses pwrgroup_ht20 when assigning instead.
Signed-off-by: Felipe Pena <felipensp@gmail.com>
---
drivers/net/wireless/rtlwifi/rtl8192se/rf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
index 5061f1d..92d38ab 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
@@ -265,7 +265,7 @@ static void _rtl92s_get_txpower_writeval_byregulatory(struct ieee80211_hw *hw,
rtlefuse->pwrgroup_ht40
[RF90_PATH_A][chnl - 1]) {
pwrdiff_limit[i] =
- rtlefuse->pwrgroup_ht20
+ rtlefuse->pwrgroup_ht40
[RF90_PATH_A][chnl - 1];
}
} else {
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] rtlwifi: rtl8192se: Fix wrong assignment
From: Joe Perches @ 2013-10-19 1:05 UTC (permalink / raw)
To: Felipe Pena
Cc: Larry Finger, Chaoming Li, John W. Linville, linux-wireless,
netdev, linux-kernel
In-Reply-To: <1382143960-4594-1-git-send-email-felipensp@gmail.com>
On Fri, 2013-10-18 at 21:52 -0300, Felipe Pena wrote:
> There is a typo in the struct member name on assignment when checking
> rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40, the check uses pwrgroup_ht40
> for bound limit and uses pwrgroup_ht20 when assigning instead.
>
> Signed-off-by: Felipe Pena <felipensp@gmail.com>
> ---
> drivers/net/wireless/rtlwifi/rtl8192se/rf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
> index 5061f1d..92d38ab 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
> @@ -265,7 +265,7 @@ static void _rtl92s_get_txpower_writeval_byregulatory(struct ieee80211_hw *hw,
> rtlefuse->pwrgroup_ht40
> [RF90_PATH_A][chnl - 1]) {
> pwrdiff_limit[i] =
> - rtlefuse->pwrgroup_ht20
> + rtlefuse->pwrgroup_ht40
> [RF90_PATH_A][chnl - 1];
> }
Using min could help minimize typos
pwrdiff_limit[i] = min(pwrdiff_limit[i],
rtlefuse->pwrgroup_ht40[RF90_PATH_A][chnl - 1]);
^ permalink raw reply
* Re: [PATCH] rtlwifi: rtl8192se: Fix wrong assignment
From: Larry Finger @ 2013-10-19 1:33 UTC (permalink / raw)
To: Joe Perches, Felipe Pena
Cc: Chaoming Li, John W. Linville, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1382144748.2041.16.camel@joe-AO722>
On 10/18/2013 08:05 PM, Joe Perches wrote:
> On Fri, 2013-10-18 at 21:52 -0300, Felipe Pena wrote:
>> There is a typo in the struct member name on assignment when checking
>> rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40, the check uses pwrgroup_ht40
>> for bound limit and uses pwrgroup_ht20 when assigning instead.
>>
>> Signed-off-by: Felipe Pena <felipensp@gmail.com>
>> ---
>> drivers/net/wireless/rtlwifi/rtl8192se/rf.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
>> index 5061f1d..92d38ab 100644
>> --- a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
>> +++ b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
>> @@ -265,7 +265,7 @@ static void _rtl92s_get_txpower_writeval_byregulatory(struct ieee80211_hw *hw,
>> rtlefuse->pwrgroup_ht40
>> [RF90_PATH_A][chnl - 1]) {
>> pwrdiff_limit[i] =
>> - rtlefuse->pwrgroup_ht20
>> + rtlefuse->pwrgroup_ht40
>> [RF90_PATH_A][chnl - 1];
>> }
>
> Using min could help minimize typos
>
> pwrdiff_limit[i] = min(pwrdiff_limit[i],
> rtlefuse->pwrgroup_ht40[RF90_PATH_A][chnl - 1]);
In the initial driver, that would have been true; however, at this point, I
prefer the patch as submitted. There is less churning of the source.
Larry
^ permalink raw reply
* Re: [PATCH] rtlwifi: rtl8192se: Fix wrong assignment
From: Larry Finger @ 2013-10-19 1:35 UTC (permalink / raw)
To: Felipe Pena, Chaoming Li, John W. Linville
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1382143960-4594-1-git-send-email-felipensp@gmail.com>
On 10/18/2013 07:52 PM, Felipe Pena wrote:
> There is a typo in the struct member name on assignment when checking
> rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40, the check uses pwrgroup_ht40
> for bound limit and uses pwrgroup_ht20 when assigning instead.
>
> Signed-off-by: Felipe Pena <felipensp@gmail.com>
> ---
> drivers/net/wireless/rtlwifi/rtl8192se/rf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
> index 5061f1d..92d38ab 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
> @@ -265,7 +265,7 @@ static void _rtl92s_get_txpower_writeval_byregulatory(struct ieee80211_hw *hw,
> rtlefuse->pwrgroup_ht40
> [RF90_PATH_A][chnl - 1]) {
> pwrdiff_limit[i] =
> - rtlefuse->pwrgroup_ht20
> + rtlefuse->pwrgroup_ht40
> [RF90_PATH_A][chnl - 1];
> }
> } else {
> --
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
John: I forgot to mention this earlier, but when you add your s-o-b, please add
a Cc for Stable [3.0 +].
Thanks,
Larry
^ permalink raw reply
* Re: [PATCH 3/9 RESENT] staging: r8188eu: Fix sparse warnings in ioctl_linux.c
From: Larry Finger @ 2013-10-19 1:45 UTC (permalink / raw)
To: Ben Hutchings; +Cc: gregkh, netdev, devel
In-Reply-To: <1382134111.3381.25.camel@bwh-desktop.uk.level5networks.com>
On 10/18/2013 05:08 PM, Ben Hutchings wrote:
> On Fri, 2013-10-18 at 16:34 -0500, Larry Finger wrote:
>> Sparse checking results in the following warnings:
>>
>> CHECK drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
>> drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:3932:17: warning: cast removes
>> address space of expression
>> drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:3933:31: warning: incorrect type
>> in argument 1 (different address spaces)
> [...]
>> - DBG_88E("[%s] extra = %s\n", __func__, (char *)wrqu->data.pointer);
>> - if (!memcmp(wrqu->data.pointer, "status", 6)) {
>> + DBG_88E("[%s] extra = %s\n", __func__, (__force char *)wrqu->data.pointer);
>> + if (!memcmp((__force const char *)wrqu->data.pointer, "status", 6)) {
> [...]
>
> This is hiding the problem, not fixing it.
>
> This private interface needs to be removed anyway.
I agree, but that is not likely to happen soon. I will just leave this set of
Sparse warnings alone.
Larry
^ permalink raw reply
* Re: [PATCH] packet: Deliver VLAN TPID to userspace
From: Atzm Watanabe @ 2013-10-19 6:19 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20131018105655.2cdc628e@nehalam.linuxnetplumber.net>
At Fri, 18 Oct 2013 10:56:55 -0700,
Stephen Hemminger wrote:
>
> On Sat, 19 Oct 2013 02:08:11 +0900
> Atzm Watanabe <atzm@stratosphere.co.jp> wrote:
>
> > diff --git a/include/uapi/linux/if_packet.h b/include/uapi/linux/if_packet.h
> > index dbf0666..6e36e0a 100644
> > --- a/include/uapi/linux/if_packet.h
> > +++ b/include/uapi/linux/if_packet.h
> > @@ -83,7 +83,7 @@ struct tpacket_auxdata {
> > __u16 tp_mac;
> > __u16 tp_net;
> > __u16 tp_vlan_tci;
> > - __u16 tp_padding;
> > + __u16 tp_vlan_tpid;
> > };
> >
> > /* Rx ring - header status */
> > @@ -132,12 +132,13 @@ struct tpacket2_hdr {
> > __u32 tp_sec;
> > __u32 tp_nsec;
> > __u16 tp_vlan_tci;
> > - __u16 tp_padding;
> > + __u16 tp_vlan_tpid;
> > };
> >
> > struct tpacket_hdr_variant1 {
> > __u32 tp_rxhash;
> > __u32 tp_vlan_tci;
> > + __u32 tp_vlan_tpid;
> > };
>
> The last change will break ABI to userspace applications.
> You can reuse padding elements; but you can't increase (or shrink)
> an existing structure.
Thank you for pointing.
But I have two questions:
- The patch that increases existing structures was posted and
accepted in the past (e.g 393e52e33c6c26ec7db290dab803bac1bed962d4
"packet: deliver VLAN TCI to userspace").
What is the difference between them and my patch?
- I tested using tools/testing/selftests/net/psock_tpacket.c built
before applying my patch, and all test cases were passed.
Also I tested by the code that was listed in
Documentation/networking/packet_mmap.txt "AF_PACKET TPACKET_V3
example". It seems that problem was not caused.
What situation causes the problem that you assumed?
Thank you.
^ permalink raw reply
* Re: [patch net REPOST 2/3] ip6_output: do skb ufo init for peeked non ufo skb as well
From: Jiri Pirko @ 2013-10-19 6:23 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: netdev, davem, eric.dumazet, hannes, jdmason, yoshfuji, kuznet,
jmorris, kaber, herbert
In-Reply-To: <5261819B.8020801@cogentembedded.com>
Fri, Oct 18, 2013 at 08:44:43PM CEST, sergei.shtylyov@cogentembedded.com wrote:
>Hello.
>
>On 10/18/2013 09:13 PM, Jiri Pirko wrote:
>
>>Now, if user application does:
>>sendto len<mtu flag MSG_MORE
>>sendto len>mtu flag 0
>>The skb is not treated as fragmented one because it is not initialized
>>that way. So move the initialization to fix this.
>
>>introduced by:
>>commit e89e9cf539a28df7d0eb1d0a545368e9920b34ac "[IPv4/IPv6]: UFO Scatter-gather approach"
>
>>Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>>---
>> net/ipv6/ip6_output.c | 26 ++++++++++++++------------
>> 1 file changed, 14 insertions(+), 12 deletions(-)
>
>>diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
>>index a54c45c..c6cfa2f 100644
>>--- a/net/ipv6/ip6_output.c
>>+++ b/net/ipv6/ip6_output.c
>[...]
>>@@ -1036,20 +1035,23 @@ static inline int ip6_ufo_append_data(struct sock *sk,
>> skb->transport_header = skb->network_header + fragheaderlen;
>>
>> skb->protocol = htons(ETH_P_IPV6);
>>- skb->ip_summed = CHECKSUM_PARTIAL;
>> skb->csum = 0;
>>
>>- /* Specify the length of each IPv6 datagram fragment.
>>- * It has to be a multiple of 8.
>>- */
>>- skb_shinfo(skb)->gso_size = (mtu - fragheaderlen -
>>- sizeof(struct frag_hdr)) & ~7;
>>- skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
>>- ipv6_select_ident(&fhdr, rt);
>>- skb_shinfo(skb)->ip6_frag_id = fhdr.identification;
>> __skb_queue_tail(&sk->sk_write_queue, skb);
>>- }
>>+ } else if (skb_is_gso(skb))
>>+ goto append;
>
> According to Documentation/CodingStyle, there should be {} in both
>arms of *if* statement if there's {} in one of them.
Yep, you are right. I wonder why scripts/checkpatch.pl do not warn about
this. I will send v2. Thanks
>
>WBR, Sergei
>
^ permalink raw reply
* Re: [PATCH nf-next] netfilter: xtables: lightweight process control group matching
From: Daniel Borkmann @ 2013-10-19 7:16 UTC (permalink / raw)
To: Eric W. Biederman
Cc: pablo-Cap9r6Oaw4JrovVCs/uTlw,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Tejun Heo,
cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87li1qp3l8.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
On 10/19/2013 01:21 AM, Eric W. Biederman wrote:
> I am coming to this late. But two concrete suggestions.
>
> 1) process groups and sessions don't change as frequently as pids.
>
> 2) It is possible to put a set of processes in their own network
> namespace and pipe just the packets you want those processes to
> use into that network namespace. Using an ingress queueing filter
> makes that process very efficient even if you have to filter by port.
Actually in our case we're filtering outgoing traffic, based on which
local socket that originated from; so you wouldn't need all of that
construct. Also, you wouldn't even need to have an a-prio knowledge of
the application internals regarding their use of particular use of ports
or protocols. I don't think that such a setup will have the same
efficiency, ease of use, and power to distinguish the application the
traffic came from in such a lightweight, protocol independent and easy way.
^ permalink raw reply
* See the attached file
From: Microsoft Promotion @ 2013-10-19 7:37 UTC (permalink / raw)
In-Reply-To: <1382030230.54824.YahooMailNeo@web5702.biz.mail.ne1.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 21 bytes --]
See the attached file
[-- Attachment #2: MICROSOFT_AWARD_PROMOTION_2013.doc --]
[-- Type: application/msword, Size: 124416 bytes --]
^ permalink raw reply
* Re: [PATCH] wireless: rt2800lib: Fix typo on checking
From: Gertjan van Wingerde @ 2013-10-19 8:31 UTC (permalink / raw)
To: Felipe Pena, John W. Linville
Cc: Ivo van Doorn, Helmut Schaa, linux-wireless, users, netdev,
linux-kernel
In-Reply-To: <1382142042-4463-1-git-send-email-felipensp@gmail.com>
On 10/19/13 02:20, Felipe Pena wrote:
> On rt2800_config_channel_rf53xx function the member default_power1 is checked
> for bound limit, but default_power2 is used instead.
>
> Signed-off-by: Felipe Pena <felipensp@gmail.com>
Good catch.
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800lib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index 88ce656..1c2ce93 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -2650,7 +2650,7 @@ static void rt2800_config_channel_rf53xx(struct rt2x00_dev *rt2x00dev,
>
> if (rt2x00_rt(rt2x00dev, RT5392)) {
> rt2800_rfcsr_read(rt2x00dev, 50, &rfcsr);
> - if (info->default_power1 > POWER_BOUND)
> + if (info->default_power2 > POWER_BOUND)
> rt2x00_set_field8(&rfcsr, RFCSR50_TX, POWER_BOUND);
> else
> rt2x00_set_field8(&rfcsr, RFCSR50_TX,
> --
> 1.7.10.4
>
--
---
Gertjan
^ permalink raw reply
* Re: IPv6 path discovery oddities - flushing the routing cache resolves
From: Hannes Frederic Sowa @ 2013-10-19 8:42 UTC (permalink / raw)
To: Valentijn Sessink; +Cc: netdev, sgunderson
In-Reply-To: <5260D8DE.30303@blub.net>
On Fri, Oct 18, 2013 at 08:44:46AM +0200, Valentijn Sessink wrote:
> On 18-10-13 05:04, Hannes Frederic Sowa wrote:
> > Thanks, I needed this to verify I am on the right track replicating this.
> > 2001:1af8:ff03:3:219:66ff:fe26:6dd is the other end of the connection, I
> > guess?
>
> Yes, the working connection (first example) is from
> 2001:1af8:ff03:3:219:66ff:fe26:6dd. The non-working connection should
> have an MTU of 1280 on the 2001:7b8:1529:: subnet connections (those are
> tunneled, with the tunnel restricting the MTU).
I got access to a nice test box yesterday where I could brute force the
problem in parallel (it was a PITA). This is what I found:
This first patch solves the problem of a complete lockdown of all sockets
towards one ipv6 destination. This can happen if we recheck the ipv6 fib
(expiration is ok) and we get back a rt6_info where we apply the new metrics
information on. After the check the dst entry expires and we do a relookup.
We try to insert the same routing information into the fib which results only
in a call to rt6_clean_expires. Because we don't reset the dst.expires value a
later update of mtu information won't update the expiration time because of
the strange semantics in rt6_update_expires. This patch should fix this.
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 6738f34..3932633 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -164,6 +164,7 @@ static inline struct inet6_dev *ip6_dst_idev(struct dst_entry *dst)
static inline void rt6_clean_expires(struct rt6_info *rt)
{
+ rt->dst.expires = 0;
rt->rt6i_flags &= ~RTF_EXPIRES;
}
The second patch resolves the problem that the socket keeps hanging on
outdated mtu information which gets invalidated just after processing. We
need to relookup the destination entry in case the socket expires. This
helps a socket to free the cached dst before applying the mtu information
to an already expired dst which will be reinserted (see above, it will
only call rt6_clean_expires on the dst_entry). This is normally not a
problem, but in the process of the creation of the cloned dst_entry we
end up copying the metric information from the non-DST_CACHEd route to
the dst_entry (ip6_rt_copy/dst_copy_metrics). Because the information are
held in inetpeer storage and the key for the expired dst and the new dst
have the same key we overwrite the metrics store which currently is in
use by two rt6_infos. So we just invalidate the newly installed metrics
information and will use the interface mtu just after the PACKET_TOO_BIG
notification, which leads to hangs of the connection. A flush of the
cached routing entries causes relookups, so this a workaround.
This patch should fix this:
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c3130ff..7629022 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1064,10 +1064,13 @@ static struct dst_entry *ip6_dst_check(struct dst_entry *dst, u32 cookie)
if (rt->rt6i_genid != rt_genid_ipv6(dev_net(rt->dst.dev)))
return NULL;
- if (rt->rt6i_node && (rt->rt6i_node->fn_sernum == cookie))
- return dst;
+ if (!rt->rt6i_node && (rt->rt6i_node->fn_sernum != cookie))
+ return NULL;
- return NULL;
+ if (rt6_check_expired(rt))
+ return NULL;
+
+ return dst;
}
static struct dst_entry *ip6_negative_advice(struct dst_entry *dst)
I had the patches in test for a few hours on some VMs where I could normally
reproduce this issue within 5 minutes. They are for testing only and I don't
know if they resolve all issues. I also have to check why rt6_update_expires
has such strange expiration update logic.
Steinar and Valentijn could you give them a test drive?
Greetings,
Hannes
^ permalink raw reply related
* Re: IPv6 path discovery oddities - flushing the routing cache resolves
From: Hannes Frederic Sowa @ 2013-10-19 8:53 UTC (permalink / raw)
To: Valentijn Sessink, netdev, sgunderson
In-Reply-To: <20131019084225.GA31333@order.stressinduktion.org>
On Sat, Oct 19, 2013 at 10:42:25AM +0200, Hannes Frederic Sowa wrote:
> This patch should fix this:
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index c3130ff..7629022 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1064,10 +1064,13 @@ static struct dst_entry *ip6_dst_check(struct dst_entry *dst, u32 cookie)
> if (rt->rt6i_genid != rt_genid_ipv6(dev_net(rt->dst.dev)))
> return NULL;
>
> - if (rt->rt6i_node && (rt->rt6i_node->fn_sernum == cookie))
> - return dst;
> + if (!rt->rt6i_node && (rt->rt6i_node->fn_sernum != cookie))
> + return NULL;
I just rewrote this patch to have a clean diff. I missed to rewrite the '&&'
to '||'.
Correct patch is:
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c3130ff..17b3cc1 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1064,10 +1064,13 @@ static struct dst_entry *ip6_dst_check(struct dst_entry *dst, u32 cookie)
if (rt->rt6i_genid != rt_genid_ipv6(dev_net(rt->dst.dev)))
return NULL;
- if (rt->rt6i_node && (rt->rt6i_node->fn_sernum == cookie))
- return dst;
+ if (!rt->rt6i_node || (rt->rt6i_node->fn_sernum != cookie))
+ return NULL;
- return NULL;
+ if (rt6_check_expired(rt))
+ return NULL;
+
+ return dst;
}
static struct dst_entry *ip6_negative_advice(struct dst_entry *dst)
^ permalink raw reply related
* Re: IPv6 path discovery oddities - flushing the routing cache resolves
From: Steinar H. Gunderson @ 2013-10-19 10:12 UTC (permalink / raw)
To: Valentijn Sessink, netdev
In-Reply-To: <20131019084225.GA31333@order.stressinduktion.org>
On Sat, Oct 19, 2013 at 10:42:25AM +0200, Hannes Frederic Sowa wrote:
> I got access to a nice test box yesterday where I could brute force the
> problem in parallel (it was a PITA). This is what I found:
Thanks so much for looking into this! It's great that to hear that it's not
just me being weird =) I'll try rebooting the machine in question into a
kernel with these patches later today; given how intermittent it is, it can
of course only show if the patches are not fully working (or, over time,
make it likely that they are).
/* Steinar */
--
Homepage: http://www.sesse.net/
^ permalink raw reply
* [patch net v2 0/3] UFO fixes
From: Jiri Pirko @ 2013-10-19 10:29 UTC (permalink / raw)
To: netdev
Cc: davem, eric.dumazet, hannes, jdmason, yoshfuji, kuznet, jmorris,
kaber, herbert
Couple of patches fixing UFO functionality in different situations.
v1->v2:
- minor if{}else{} coding style adjustment suggested by Sergei Shtylyov
Jiri Pirko (3):
udp6: respect IPV6_DONTFRAG sockopt in case there are pending frames
ip6_output: do skb ufo init for peeked non ufo skb as well
ip_output: do skb ufo init for peeked non ufo skb as well
net/ipv4/ip_output.c | 13 +++++++++----
net/ipv6/ip6_output.c | 25 ++++++++++++++-----------
net/ipv6/udp.c | 5 ++---
3 files changed, 25 insertions(+), 18 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [patch net v2 2/3] ip6_output: do skb ufo init for peeked non ufo skb as well
From: Jiri Pirko @ 2013-10-19 10:29 UTC (permalink / raw)
To: netdev
Cc: davem, eric.dumazet, hannes, jdmason, yoshfuji, kuznet, jmorris,
kaber, herbert
In-Reply-To: <1382178557-14737-1-git-send-email-jiri@resnulli.us>
Now, if user application does:
sendto len<mtu flag MSG_MORE
sendto len>mtu flag 0
The skb is not treated as fragmented one because it is not initialized
that way. So move the initialization to fix this.
introduced by:
commit e89e9cf539a28df7d0eb1d0a545368e9920b34ac "[IPv4/IPv6]: UFO Scatter-gather approach"
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
net/ipv6/ip6_output.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index a54c45c..975624b 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1008,6 +1008,7 @@ static inline int ip6_ufo_append_data(struct sock *sk,
{
struct sk_buff *skb;
+ struct frag_hdr fhdr;
int err;
/* There is support for UDP large send offload by network
@@ -1015,8 +1016,6 @@ static inline int ip6_ufo_append_data(struct sock *sk,
* udp datagram
*/
if ((skb = skb_peek_tail(&sk->sk_write_queue)) == NULL) {
- struct frag_hdr fhdr;
-
skb = sock_alloc_send_skb(sk,
hh_len + fragheaderlen + transhdrlen + 20,
(flags & MSG_DONTWAIT), &err);
@@ -1036,20 +1035,24 @@ static inline int ip6_ufo_append_data(struct sock *sk,
skb->transport_header = skb->network_header + fragheaderlen;
skb->protocol = htons(ETH_P_IPV6);
- skb->ip_summed = CHECKSUM_PARTIAL;
skb->csum = 0;
- /* Specify the length of each IPv6 datagram fragment.
- * It has to be a multiple of 8.
- */
- skb_shinfo(skb)->gso_size = (mtu - fragheaderlen -
- sizeof(struct frag_hdr)) & ~7;
- skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
- ipv6_select_ident(&fhdr, rt);
- skb_shinfo(skb)->ip6_frag_id = fhdr.identification;
__skb_queue_tail(&sk->sk_write_queue, skb);
+ } else if (skb_is_gso(skb)) {
+ goto append;
}
+ skb->ip_summed = CHECKSUM_PARTIAL;
+ /* Specify the length of each IPv6 datagram fragment.
+ * It has to be a multiple of 8.
+ */
+ skb_shinfo(skb)->gso_size = (mtu - fragheaderlen -
+ sizeof(struct frag_hdr)) & ~7;
+ skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
+ ipv6_select_ident(&fhdr, rt);
+ skb_shinfo(skb)->ip6_frag_id = fhdr.identification;
+
+append:
return skb_append_datato_frags(sk, skb, getfrag, from,
(length - transhdrlen));
}
--
1.8.3.1
^ permalink raw reply related
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