* [gcv v4 07/38] net: Replace __get_cpu_var uses
From: Christoph Lameter @ 2013-09-03 19:12 UTC (permalink / raw)
To: Tejun Heo
Cc: akpm, David S. Miller, netdev, linux-arch, Steven Rostedt,
linux-kernel, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20130903190014.794420260@linux.com>
__get_cpu_var() is used for multiple purposes in the kernel source. One of them is
address calculation via the form &__get_cpu_var(x). This calculates the address for
the instance of the percpu variable of the current processor based on an offset.
Other use cases are for storing and retrieving data from the current processors percpu area.
__get_cpu_var() can be used as an lvalue when writing data or on the right side of an assignment.
__get_cpu_var() is defined as :
#define __get_cpu_var(var) (*this_cpu_ptr(&(var)))
__get_cpu_var() always only does an address determination. However, store and retrieve operations
could use a segment prefix (or global register on other platforms) to avoid the address calculation.
this_cpu_write() and this_cpu_read() can directly take an offset into a percpu area and use
optimized assembly code to read and write per cpu variables.
This patch converts __get_cpu_var into either an explicit address calculation using this_cpu_ptr()
or into a use of this_cpu operations that use the offset. Thereby address calculations are avoided
and less registers are used when code is generated.
At the end of the patch set all uses of __get_cpu_var have been removed so the macro is removed too.
The patch set includes passes over all arches as well. Once these operations are used throughout then
specialized macros can be defined in non -x86 arches as well in order to optimize per cpu access by
f.e. using a global register that may be set to the per cpu base.
Transformations done to __get_cpu_var()
1. Determine the address of the percpu instance of the current processor.
DEFINE_PER_CPU(int, y);
int *x = &__get_cpu_var(y);
Converts to
int *x = this_cpu_ptr(&y);
2. Same as #1 but this time an array structure is involved.
DEFINE_PER_CPU(int, y[20]);
int *x = __get_cpu_var(y);
Converts to
int *x = this_cpu_ptr(y);
3. Retrieve the content of the current processors instance of a per cpu variable.
DEFINE_PER_CPU(int, y);
int x = __get_cpu_var(y)
Converts to
int x = __this_cpu_read(y);
4. Retrieve the content of a percpu struct
DEFINE_PER_CPU(struct mystruct, y);
struct mystruct x = __get_cpu_var(y);
Converts to
memcpy(&x, this_cpu_ptr(&y), sizeof(x));
5. Assignment to a per cpu variable
DEFINE_PER_CPU(int, y)
__get_cpu_var(y) = x;
Converts to
this_cpu_write(y, x);
6. Increment/Decrement etc of a per cpu variable
DEFINE_PER_CPU(int, y);
__get_cpu_var(y)++
Converts to
this_cpu_inc(y)
Signed-off-by: Christoph Lameter <cl@linux.com>
Index: linux/net/core/dev.c
===================================================================
--- linux.orig/net/core/dev.c 2013-08-26 14:16:59.000000000 -0500
+++ linux/net/core/dev.c 2013-08-26 14:18:37.214005168 -0500
@@ -2129,7 +2129,7 @@ static inline void __netif_reschedule(st
unsigned long flags;
local_irq_save(flags);
- sd = &__get_cpu_var(softnet_data);
+ sd = this_cpu_ptr(&softnet_data);
q->next_sched = NULL;
*sd->output_queue_tailp = q;
sd->output_queue_tailp = &q->next_sched;
@@ -2151,7 +2151,7 @@ void dev_kfree_skb_irq(struct sk_buff *s
unsigned long flags;
local_irq_save(flags);
- sd = &__get_cpu_var(softnet_data);
+ sd = this_cpu_ptr(&softnet_data);
skb->next = sd->completion_queue;
sd->completion_queue = skb;
raise_softirq_irqoff(NET_TX_SOFTIRQ);
@@ -3111,7 +3111,7 @@ static void rps_trigger_softirq(void *da
static int rps_ipi_queued(struct softnet_data *sd)
{
#ifdef CONFIG_RPS
- struct softnet_data *mysd = &__get_cpu_var(softnet_data);
+ struct softnet_data *mysd = this_cpu_ptr(&softnet_data);
if (sd != mysd) {
sd->rps_ipi_next = mysd->rps_ipi_list;
@@ -3138,7 +3138,7 @@ static bool skb_flow_limit(struct sk_buf
if (qlen < (netdev_max_backlog >> 1))
return false;
- sd = &__get_cpu_var(softnet_data);
+ sd = this_cpu_ptr(&softnet_data);
rcu_read_lock();
fl = rcu_dereference(sd->flow_limit);
@@ -3280,7 +3280,7 @@ EXPORT_SYMBOL(netif_rx_ni);
static void net_tx_action(struct softirq_action *h)
{
- struct softnet_data *sd = &__get_cpu_var(softnet_data);
+ struct softnet_data *sd = this_cpu_ptr(&softnet_data);
if (sd->completion_queue) {
struct sk_buff *clist;
@@ -3700,7 +3700,7 @@ EXPORT_SYMBOL(netif_receive_skb);
static void flush_backlog(void *arg)
{
struct net_device *dev = arg;
- struct softnet_data *sd = &__get_cpu_var(softnet_data);
+ struct softnet_data *sd = this_cpu_ptr(&softnet_data);
struct sk_buff *skb, *tmp;
rps_lock(sd);
@@ -4146,7 +4146,7 @@ void __napi_schedule(struct napi_struct
unsigned long flags;
local_irq_save(flags);
- ____napi_schedule(&__get_cpu_var(softnet_data), n);
+ ____napi_schedule(this_cpu_ptr(&softnet_data), n);
local_irq_restore(flags);
}
EXPORT_SYMBOL(__napi_schedule);
@@ -4274,7 +4274,7 @@ EXPORT_SYMBOL(netif_napi_del);
static void net_rx_action(struct softirq_action *h)
{
- struct softnet_data *sd = &__get_cpu_var(softnet_data);
+ struct softnet_data *sd = this_cpu_ptr(&softnet_data);
unsigned long time_limit = jiffies + 2;
int budget = netdev_budget;
void *have;
Index: linux/net/core/drop_monitor.c
===================================================================
--- linux.orig/net/core/drop_monitor.c 2013-08-26 14:16:59.000000000 -0500
+++ linux/net/core/drop_monitor.c 2013-08-26 14:18:37.218005126 -0500
@@ -142,7 +142,7 @@ static void trace_drop_common(struct sk_
unsigned long flags;
local_irq_save(flags);
- data = &__get_cpu_var(dm_cpu_data);
+ data = this_cpu_ptr(&dm_cpu_data);
spin_lock(&data->lock);
dskb = data->skb;
Index: linux/net/core/skbuff.c
===================================================================
--- linux.orig/net/core/skbuff.c 2013-08-26 14:16:59.000000000 -0500
+++ linux/net/core/skbuff.c 2013-08-26 14:18:37.218005126 -0500
@@ -371,7 +371,7 @@ static void *__netdev_alloc_frag(unsigne
unsigned long flags;
local_irq_save(flags);
- nc = &__get_cpu_var(netdev_alloc_cache);
+ nc = this_cpu_ptr(&netdev_alloc_cache);
if (unlikely(!nc->frag.page)) {
refill:
for (order = NETDEV_FRAG_PAGE_MAX_ORDER; ;) {
Index: linux/net/ipv4/syncookies.c
===================================================================
--- linux.orig/net/ipv4/syncookies.c 2013-08-26 14:16:59.000000000 -0500
+++ linux/net/ipv4/syncookies.c 2013-08-26 14:18:37.210005210 -0500
@@ -44,7 +44,7 @@ static DEFINE_PER_CPU(__u32 [16 + 5 + SH
static u32 cookie_hash(__be32 saddr, __be32 daddr, __be16 sport, __be16 dport,
u32 count, int c)
{
- __u32 *tmp = __get_cpu_var(ipv4_cookie_scratch);
+ __u32 *tmp = this_cpu_ptr(ipv4_cookie_scratch);
memcpy(tmp + 4, syncookie_secret[c], sizeof(syncookie_secret[c]));
tmp[0] = (__force u32)saddr;
Index: linux/net/ipv4/tcp_output.c
===================================================================
--- linux.orig/net/ipv4/tcp_output.c 2013-08-26 14:16:59.000000000 -0500
+++ linux/net/ipv4/tcp_output.c 2013-08-26 14:18:37.218005126 -0500
@@ -810,7 +810,7 @@ void tcp_wfree(struct sk_buff *skb)
/* queue this socket to tasklet queue */
local_irq_save(flags);
- tsq = &__get_cpu_var(tsq_tasklet);
+ tsq = this_cpu_ptr(&tsq_tasklet);
list_add(&tp->tsq_node, &tsq->head);
tasklet_schedule(&tsq->tasklet);
local_irq_restore(flags);
Index: linux/net/ipv6/syncookies.c
===================================================================
--- linux.orig/net/ipv6/syncookies.c 2013-08-26 14:16:59.000000000 -0500
+++ linux/net/ipv6/syncookies.c 2013-08-26 14:18:37.214005168 -0500
@@ -66,7 +66,7 @@ static DEFINE_PER_CPU(__u32 [16 + 5 + SH
static u32 cookie_hash(const struct in6_addr *saddr, const struct in6_addr *daddr,
__be16 sport, __be16 dport, u32 count, int c)
{
- __u32 *tmp = __get_cpu_var(ipv6_cookie_scratch);
+ __u32 *tmp = this_cpu_ptr(ipv6_cookie_scratch);
/*
* we have 320 bits of information to hash, copy in the remaining
Index: linux/net/rds/ib_rdma.c
===================================================================
--- linux.orig/net/rds/ib_rdma.c 2013-08-26 14:16:59.000000000 -0500
+++ linux/net/rds/ib_rdma.c 2013-08-26 14:18:37.218005126 -0500
@@ -267,7 +267,7 @@ static inline struct rds_ib_mr *rds_ib_r
unsigned long *flag;
preempt_disable();
- flag = &__get_cpu_var(clean_list_grace);
+ flag = this_cpu_ptr(&clean_list_grace);
set_bit(CLEAN_LIST_BUSY_BIT, flag);
ret = llist_del_first(&pool->clean_list);
if (ret)
Index: linux/include/net/netfilter/nf_conntrack.h
===================================================================
--- linux.orig/include/net/netfilter/nf_conntrack.h 2013-08-26 14:23:46.000000000 -0500
+++ linux/include/net/netfilter/nf_conntrack.h 2013-08-26 14:24:17.190395755 -0500
@@ -243,7 +243,7 @@ extern s16 (*nf_ct_nat_offset)(const str
DECLARE_PER_CPU(struct nf_conn, nf_conntrack_untracked);
static inline struct nf_conn *nf_ct_untracked_get(void)
{
- return &__raw_get_cpu_var(nf_conntrack_untracked);
+ return __this_cpu_ptr(&nf_conntrack_untracked);
}
extern void nf_ct_untracked_status_or(unsigned long bits);
^ permalink raw reply
* Re: [PATCH v4] ipv6:introduce function to find route for redirect
From: Hannes Frederic Sowa @ 2013-09-03 19:17 UTC (permalink / raw)
To: Duan Jiong; +Cc: davem, netdev
In-Reply-To: <5225758F.8080604@cn.fujitsu.com>
On Tue, Sep 03, 2013 at 01:37:19PM +0800, Duan Jiong wrote:
> > Btw. I still think it should be possible to eliminate
> > ip6_redirect_no_header:
> >
> > We could always use ip6_redirect_no_header and use the data of the redirected
> > header option just for finding the socket to be notified. We can do the whole
> > verification and route updating in ndisc layer and then just call into icmpv6
> > layer if upper protocols need a notification of the redirect. But that should
> > go into another patch. ;)
> >
>
> I think this is good, but i have a question below:
>
> if the socket type is connection-based, the dst information is stored in related
> sock struct, so there is no need to look up the route for redirect in ip6_redirect
> or ip6_redirect_no_header, in this case, we do the verification and route
> updating in the upper protocols' err_handler is better.
>
> How do you think of this?
This should not be a problem, because every cached dst should be validated
with ip6_dst_check before it is used. It uses the fib6_node serial number
which is incremented for all fib6_nodes on the path to the new installed
node by fib6_add_1. So we are safe here.
Btw. this is the same logic redirects get currently picked up, too.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH][net-next] gianfar: Fix reported number of sent bytes to BQL
From: Florian Fainelli @ 2013-09-03 19:18 UTC (permalink / raw)
To: Claudiu Manoil; +Cc: netdev, David S. Miller, Eric Dumazet
In-Reply-To: <CAGVrzcaHLa1kT2wZc993cZFX2geQ4JgOO-u6JcWHFKcn-OZhZw@mail.gmail.com>
Le mardi 3 septembre 2013 19:59:42 Florian Fainelli a écrit :
> Hello Claudiu,
>
> 2013/8/30 Claudiu Manoil <claudiu.manoil@freescale.com>:
> > Fix the amount of sent bytes reported to BQL by reporting the
> > number of bytes on wire in the xmit routine, and recording that
> > value for each skb in order to be correctly confirmed on Tx
> > confirmation cleanup.
> >
> > Reporting skb->len to BQL just before exiting xmit is not correct
> > due to possible insertions of TOE block and alignment bytes in the
> > skb->data, which are being stripped off by the controller before
> > transmission on wire. This led to mismatch of (incorrectly)
> > reported bytes to BQL b/w xmit and Tx confirmation, resulting in
> > Tx timeout firing, for the h/w tx timestamping acceleration case.
> >
> > There's no easy way to obtain the number of bytes on wire in the Tx
> > confirmation routine, so skb->cb is used to convey that information
> > from xmit to Tx confirmation, for now (as proposed by Eric). Revived
> > the currently unused GFAR_CB() construct for that purpose.
>
> I do not see much difference between what this patch does and what the
> current net-next drivers does. If you need to correctly account for
> this, it seems to me like you should move the stats/bytes_sent
> computation below this line:
>
> if (unlikely(do_tstamp)) {
> skb_push(skb, GMAC_TXPAL_LEN);
> memset(skb->data, 0, GMAC_TXPAL_LEN);
> }
>
> to account for the SKB length update?
Just realized that this is precisely what your patch is fixing, sorry for the
noise.
--
Florian
^ permalink raw reply
* [PATCH net-next v2] tcp: Change return value of tcp_rcv_established()
From: Vijay Subramanian @ 2013-09-03 19:23 UTC (permalink / raw)
To: netdev; +Cc: davem, Vijay Subramanian
tcp_rcv_established() returns only one value namely 0. We change the return
value to void (as suggested by David Miller).
After commit 0c24604b (tcp: implement RFC 5961 4.2), we no longer send RSTs in
response to SYNs. We can remove the check and processing on the return value of
tcp_rcv_established().
We also fix jtcp_rcv_established() in tcp_probe.c to match that of
tcp_rcv_established().
Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
---
v1 -> v2: removed unnecessary 'return;' statements from v1, and fixed indendation"
include/net/tcp.h | 4 ++--
net/ipv4/tcp_input.c | 13 ++++++-------
net/ipv4/tcp_ipv4.c | 5 +----
net/ipv4/tcp_probe.c | 5 ++---
net/ipv6/tcp_ipv6.c | 3 +--
5 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 6a6a88d..b1aa324 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -371,8 +371,8 @@ extern void tcp_delack_timer_handler(struct sock *sk);
extern int tcp_ioctl(struct sock *sk, int cmd, unsigned long arg);
extern int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb,
const struct tcphdr *th, unsigned int len);
-extern int tcp_rcv_established(struct sock *sk, struct sk_buff *skb,
- const struct tcphdr *th, unsigned int len);
+extern void tcp_rcv_established(struct sock *sk, struct sk_buff *skb,
+ const struct tcphdr *th, unsigned int len);
extern void tcp_rcv_space_adjust(struct sock *sk);
extern void tcp_cleanup_rbuf(struct sock *sk, int copied);
extern int tcp_twsk_unique(struct sock *sk, struct sock *sktw, void *twp);
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1a84fff..93d7e9d 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5049,8 +5049,8 @@ discard:
* the rest is checked inline. Fast processing is turned on in
* tcp_data_queue when everything is OK.
*/
-int tcp_rcv_established(struct sock *sk, struct sk_buff *skb,
- const struct tcphdr *th, unsigned int len)
+void tcp_rcv_established(struct sock *sk, struct sk_buff *skb,
+ const struct tcphdr *th, unsigned int len)
{
struct tcp_sock *tp = tcp_sk(sk);
@@ -5127,7 +5127,7 @@ int tcp_rcv_established(struct sock *sk, struct sk_buff *skb,
tcp_ack(sk, skb, 0);
__kfree_skb(skb);
tcp_data_snd_check(sk);
- return 0;
+ return;
} else { /* Header too small */
TCP_INC_STATS_BH(sock_net(sk), TCP_MIB_INERRS);
goto discard;
@@ -5220,7 +5220,7 @@ no_ack:
if (eaten)
kfree_skb_partial(skb, fragstolen);
sk->sk_data_ready(sk, 0);
- return 0;
+ return;
}
}
@@ -5236,7 +5236,7 @@ slow_path:
*/
if (!tcp_validate_incoming(sk, skb, th, 1))
- return 0;
+ return;
step5:
if (tcp_ack(sk, skb, FLAG_SLOWPATH | FLAG_UPDATE_TS_RECENT) < 0)
@@ -5252,7 +5252,7 @@ step5:
tcp_data_snd_check(sk);
tcp_ack_snd_check(sk);
- return 0;
+ return;
csum_error:
TCP_INC_STATS_BH(sock_net(sk), TCP_MIB_CSUMERRORS);
@@ -5260,7 +5260,6 @@ csum_error:
discard:
__kfree_skb(skb);
- return 0;
}
EXPORT_SYMBOL(tcp_rcv_established);
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 09d45d7..b14266b 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1799,10 +1799,7 @@ int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb)
sk->sk_rx_dst = NULL;
}
}
- if (tcp_rcv_established(sk, skb, tcp_hdr(skb), skb->len)) {
- rsk = sk;
- goto reset;
- }
+ tcp_rcv_established(sk, skb, tcp_hdr(skb), skb->len);
return 0;
}
diff --git a/net/ipv4/tcp_probe.c b/net/ipv4/tcp_probe.c
index 622a437..152df1e 100644
--- a/net/ipv4/tcp_probe.c
+++ b/net/ipv4/tcp_probe.c
@@ -122,8 +122,8 @@ static inline int tcp_probe_avail(void)
* Hook inserted to be called before each receive packet.
* Note: arguments must match tcp_rcv_established()!
*/
-static int jtcp_rcv_established(struct sock *sk, struct sk_buff *skb,
- const struct tcphdr *th, unsigned int len)
+static void jtcp_rcv_established(struct sock *sk, struct sk_buff *skb,
+ const struct tcphdr *th, unsigned int len)
{
const struct tcp_sock *tp = tcp_sk(sk);
const struct inet_sock *inet = inet_sk(sk);
@@ -172,7 +172,6 @@ static int jtcp_rcv_established(struct sock *sk, struct sk_buff *skb,
}
jprobe_return();
- return 0;
}
static struct jprobe tcp_jprobe = {
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 5bcfadf..9acdced 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1360,8 +1360,7 @@ static int tcp_v6_do_rcv(struct sock *sk, struct sk_buff *skb)
}
}
- if (tcp_rcv_established(sk, skb, tcp_hdr(skb), skb->len))
- goto reset;
+ tcp_rcv_established(sk, skb, tcp_hdr(skb), skb->len);
if (opt_skb)
goto ipv6_pktoptions;
return 0;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net-next] bcm87xx: Add MODULE_DEVICE_TABLE
From: David Daney @ 2013-09-03 19:13 UTC (permalink / raw)
To: Ben Hutchings, David Miller; +Cc: David Daney, David Daney, netdev
In-Reply-To: <20130903185305.GC7729@decadent.org.uk>
On 09/03/2013 11:53 AM, Ben Hutchings wrote:
> On Tue, Sep 03, 2013 at 10:32:02AM -0700, David Daney wrote:
>> On 09/01/2013 02:33 PM, Ben Hutchings wrote:
>>> bcm87xx currently isn't auto-loaded if built as a module.
>>>
>>> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>>> ---
>>> Compile-tested only.
>>
>> Then how do you know that it does anything sensible?
>
> This is generally required in modular PHY drivers. I was hoping you'd
> be able to say whether that it's useful or necessary for this one.
OK. I just tested the patch, and it is not sufficient to get the module
loaded automatically.
My configuration also successfully uses drivers/net/phy/marvell.ko, so I
think the modules.alias file is properly generated, and the auto-loading
is working for some PHY drivers, but bcm87xx isn't detected.
I may take a look later this week, but as the patch stands, I don't
think it should be merged.
David Daney
>
>> Other than that, it seems plausible.
>>
>> David Daney
>
> Thanks.
>
> Ben.
>
>>>
>>> Ben.
>>>
>>> drivers/net/phy/bcm87xx.c | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/net/phy/bcm87xx.c b/drivers/net/phy/bcm87xx.c
>>> index 7997895..f5b44ff 100644
>>> --- a/drivers/net/phy/bcm87xx.c
>>> +++ b/drivers/net/phy/bcm87xx.c
>>> @@ -230,4 +230,11 @@ static void __exit bcm87xx_exit(void)
>>> }
>>> module_exit(bcm87xx_exit);
>>>
>>> +static struct mdio_device_id __maybe_unused bcm87xx_tbl[] = {
>>> + { PHY_ID_BCM8706, 0xffffffff },
>>> + { PHY_ID_BCM8727, 0xffffffff },
>>> + { }
>>> +};
>>> +
>>> MODULE_LICENSE("GPL");
>>> +MODULE_DEVICE_TABLE(mdio, bcm87xx_tbl);
>>>
>>
>
^ permalink raw reply
* Re: [PATCH net-next] bcm87xx: Add MODULE_DEVICE_TABLE
From: David Daney @ 2013-09-03 19:28 UTC (permalink / raw)
To: Ben Hutchings, David Miller; +Cc: David Daney, David Daney, netdev
In-Reply-To: <522634D0.7080606@caviumnetworks.com>
On 09/03/2013 12:13 PM, David Daney wrote:
> On 09/03/2013 11:53 AM, Ben Hutchings wrote:
>> On Tue, Sep 03, 2013 at 10:32:02AM -0700, David Daney wrote:
>>> On 09/01/2013 02:33 PM, Ben Hutchings wrote:
>>>> bcm87xx currently isn't auto-loaded if built as a module.
>>>>
>>>> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>>>> ---
>>>> Compile-tested only.
>>>
>>> Then how do you know that it does anything sensible?
>>
>> This is generally required in modular PHY drivers. I was hoping you'd
>> be able to say whether that it's useful or necessary for this one.
>
>
> OK. I just tested the patch, and it is not sufficient to get the module
> loaded automatically.
>
The problem is that get_phy_c45_ids() sets the phy_id that is passed to
request_module() to zero, so it will never match anything.
We need to think about how this should work for 802.3-c45 PHYs.
Most c54 PHYs are conceptually composed of several pieces each with its
own set of identifiers. Which of these should be used? Will something
break if we start supplying a C22 phy_id for these devices?
David Daney
> My configuration also successfully uses drivers/net/phy/marvell.ko, so I
> think the modules.alias file is properly generated, and the auto-loading
> is working for some PHY drivers, but bcm87xx isn't detected.
>
> I may take a look later this week, but as the patch stands, I don't
> think it should be merged.
>
> David Daney
>
>
>>
>>> Other than that, it seems plausible.
>>>
>>> David Daney
>>
>> Thanks.
>>
>> Ben.
>>
>>>>
>>>> Ben.
>>>>
>>>> drivers/net/phy/bcm87xx.c | 7 +++++++
>>>> 1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/drivers/net/phy/bcm87xx.c b/drivers/net/phy/bcm87xx.c
>>>> index 7997895..f5b44ff 100644
>>>> --- a/drivers/net/phy/bcm87xx.c
>>>> +++ b/drivers/net/phy/bcm87xx.c
>>>> @@ -230,4 +230,11 @@ static void __exit bcm87xx_exit(void)
>>>> }
>>>> module_exit(bcm87xx_exit);
>>>>
>>>> +static struct mdio_device_id __maybe_unused bcm87xx_tbl[] = {
>>>> + { PHY_ID_BCM8706, 0xffffffff },
>>>> + { PHY_ID_BCM8727, 0xffffffff },
>>>> + { }
>>>> +};
>>>> +
>>>> MODULE_LICENSE("GPL");
>>>> +MODULE_DEVICE_TABLE(mdio, bcm87xx_tbl);
>>>>
>>>
>>
>
>
^ permalink raw reply
* Re: BQL support in gianfar causes network hiccup
From: Per Dalén @ 2013-09-03 19:33 UTC (permalink / raw)
To: Claudiu Manoil; +Cc: Eric Dumazet, Per Dalén, netdev
In-Reply-To: <522609C9.7030901@freescale.com>
>
>
> On 9/3/2013 6:42 PM, Eric Dumazet wrote:
>> On Tue, 2013-09-03 at 09:55 +0200, Per Dalén wrote:
>>
>>> Yes, it's weird. The only reason I removed the BQL commit
>>> (d8a0f1b0af67679bba886784de10d8c21acc4e0e) was because the error Tino
>>> Keitel had was the similar as mine.
>>
>>
>> I suspect a genuine race in this driver. BQL only makes this race happen
>> more often.
>>
>> gfar_poll_sq() has the following :
>>
>> /* run Tx cleanup to completion */
>> if (tx_queue->tx_skbuff[tx_queue->skb_dirtytx])
>> gfar_clean_tx_ring(tx_queue);
>>
>> While gfar_poll() has a different method :
>>
>> if (tx_queue->tx_skbuff[tx_queue->skb_dirtytx]) {
>> gfar_clean_tx_ring(tx_queue);
>> has_tx_work = 1;
>> }
>>
>> Note the has_tx_work use in gfar_poll() only.
>>
>> Note that memory barriers seems to be missing.
>>
>> 1) In your cases, is it gfar_poll_sq() or gfar_poll() that is used ?
>>
>
> It's gfar_poll_sq(). P2020 single Tx/Rx queues.
>
> I'm also seeing carrier errors and packet collisions in this case
> (100/Half link).
>
>> 2) Is the bug happening if only one CPU is used ?
>>
>
> I didn't try this. Maybe Per did?
>
I use both CPUs.
^ permalink raw reply
* Re: [PATCH v2 0/8] Drop support for Renesas H8/300 architecture
From: Al Viro @ 2013-09-03 19:39 UTC (permalink / raw)
To: Chen Gang F T
Cc: Guenter Roeck, linux-kernel, linux-ide, netdev, linux-watchdog,
Wim Van Sebroeck, David S. Miller, Yoshinori Sato,
Geert Uytterhoeven, Eric Paris, Greg Kroah-Hartman, Jiang Liu,
David Howells, Thomas Gleixner, Stephen Rothwell, Linus Torvalds,
Andrew Morton, Rusty Russell, Linus Walleij
In-Reply-To: <52255CF1.6020700@gmail.com>
On Tue, Sep 03, 2013 at 11:52:17AM +0800, Chen Gang F T wrote:
> extreme sample: let 'kernel code style' and 'gcc code style' in one file, that will make the code very ugly.
gcc style will make any code very ugly, no matter what (if anything) else is
in the same file...
[digs out the ports history table]
x86: 0.01 [alive]
i386: 0.01..2.6.24-rc1 [folded into x86]
x86_64: 2.5.5-pre1..2.6.24-rc1 [folded into x86]
x86: 2.6.24-rc1 [alive]
alpha: 1.1.67 [alive]
sparc: 1.1.77 [alive]
sparc64: 2.1.19..2.6.28 [folded into sparc]
mips: 1.1.82 [alive]
mips64: 2.3.48-pre2..2.6.0-test2 [folded into mips]
powerpc: 1.3.45 [alive]
ppc: 1.3.45..2.6.26 [folded into powerpc]
ppc64: 2.5.5..2.6.15-rc1 [folded into powerpc]
powerpc: 2.6.15-rc1 [alive]
m68k: 1.3.94 [alive]
m68knommu: 2.5.46..2.6.38 [folded into m68k]
arm: 2.1.80 [alive]
arm26: 2.5.71..2.6.23-rc2 [gone]
arm64: 3.7-rc1 [alive][might eventually fold]
sh: 2.3.16 [alive]
sh64: 2.6.8-rc1..2.6.24 [folded into sh, nearly dead there]
ia64: 2.3.43-pre1 [alive]
s390: 2.3.99pre8 [alive]
s390x: 2.5.0..2.5.67 [folded into s390]
parisc: 2.4.0-test12 [alive]
cris: 2.5.0 [alive]
um: 2.5.35 [alive]
v850: 2.5.46..2.6.26 [gone]
h8300: 2.5.68 [moderately responsive]
m32r: 2.6.9-rc3 [alive]
frv: 2.6.11-rc1 [alive]
xtensa: 2.6.13-rc1 [alive]
avr32: 2.6.19-rc1 [alive]
blackfin: 2.6.22-rc1 [alive]
mn10300: 2.6.25-rc1 [alive]
microblaze: 2.6.30-rc2 [alive]
score: 2.6.32-rc1 [abandoned][cloned off mips]
tile: 2.6.36-rc1 [alive]
unicore32: 2.6.39-rc1 [alive][cloned off arm]
openrisc: 3.1-rc1 [alive]
hexagon: 3.2-rc1 [alive]
c6x: 3.3-rc1 [alive]
arc: 3.9-rc1 [alive]
metag: 3.9-rc1 [alive]
Frankly, I would've expected score and lefotvers of sh64 (aka sh5) to be
the first against the wall - h8300 was a bit surprising...
^ permalink raw reply
* Re: [PATCH net] net: ipv6: tcp: fix potential use after free in tcp_v6_do_rcv
From: Jean Sacren @ 2013-09-03 19:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Daniel Borkmann, davem, netdev, yoshfuji
In-Reply-To: <1378230513.7360.37.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 03 Sep 2013 10:48:33 -0700
>
> On Tue, 2013-09-03 at 19:29 +0200, Daniel Borkmann wrote:
> > In tcp_v6_do_rcv() code, when processing pkt options, we soley work
> > on our skb clone opt_skb that we've created earlier before entering
> > tcp_rcv_established() on our way. However, only in condition ...
> >
> > if (np->rxopt.bits.rxtclass)
> > np->rcv_tclass = ipv6_get_dsfield(ipv6_hdr(skb));
> >
> > ... we work on skb itself. As we extract every other information out
> > of opt_skb in ipv6_pktoptions path, this seems wrong, since skb can
> > already be released by tcp_rcv_established() earlier on. When we try
> > to access it in ipv6_hdr(), we will dereference freed skb.
> >
> > Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> > Cc: Eric Dumazet <eric.dumazet@gmail.com>
> > ---
> > net/ipv6/tcp_ipv6.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
> > index 6e1649d..eeb4cb0 100644
> > --- a/net/ipv6/tcp_ipv6.c
> > +++ b/net/ipv6/tcp_ipv6.c
> > @@ -1427,7 +1427,7 @@ ipv6_pktoptions:
> > if (np->rxopt.bits.rxhlim || np->rxopt.bits.rxohlim)
> > np->mcast_hops = ipv6_hdr(opt_skb)->hop_limit;
> > if (np->rxopt.bits.rxtclass)
> > - np->rcv_tclass = ipv6_get_dsfield(ipv6_hdr(skb));
> > + np->rcv_tclass = ipv6_get_dsfield(ipv6_hdr(opt_skb));
> > if (ipv6_opt_accepted(sk, opt_skb)) {
> > skb_set_owner_r(opt_skb, sk);
> > opt_skb = xchg(&np->pktoptions, opt_skb);
>
> Bug added in commit 4c507d2897bd9b
> ("net: implement IP_RECVTOS for IP_PKTOPTIONS")
>
> CC Jiri
>
> Acked-by: Eric Dumazet <edumazet@google.com>
You made a mistake.
It was introduced in commit e7219858a ("ipv6: Use ipv6_get_dsfield()
instead of ipv6_tclass()").
Cc the right party.
--
Jean Sacren
^ permalink raw reply
* Re: [PATCH] rtl8187: fix use after free on failure path in rtl8187_init_urbs()
From: Alexey Khoroshilov @ 2013-09-03 20:09 UTC (permalink / raw)
To: htl10
Cc: larry.finger, linville, linux-wireless, netdev, linux-kernel,
ldv-project, gregkh
In-Reply-To: <1378103685.43571.YahooMailBasic@web172301.mail.ir2.yahoo.com>
On 02.09.2013 10:34, Hin-Tak Leung wrote:
> ------------------------------
> On Mon, Sep 2, 2013 05:06 BST Alexey Khoroshilov wrote:
>
>> On 01.09.2013 10:51, Hin-Tak Leung wrote:
>>> ------------------------------
>>> On Sat, Aug 31, 2013 22:18 BST Alexey Khoroshilov wrote:
>>>
>>> In case of __dev_alloc_skb() failure rtl8187_init_urbs()
>>> calls usb_free_urb(entry) where 'entry' can points to urb
>>> allocated at the previous iteration. That means refcnt will be
>>> decremented incorrectly and the urb can be used after memory
>>> deallocation.
>>>
>>> The patch fixes the issue and implements error handling of init_urbs
>>> in rtl8187_start().
>>>
>>> Found by Linux Driver Verification project (linuxtesting.org).
>>>
>>> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
>>> ---
>>> drivers/net/wireless/rtl818x/rtl8187/dev.c | 15 ++++++++++-----
>>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/rtl818x/rtl8187/dev.c b/drivers/net/wireless/rtl818x/rtl8187/dev.c
>>> index f49220e..e83d53c 100644
>>> --- a/drivers/net/wireless/rtl818x/rtl8187/dev.c
>>> +++ b/drivers/net/wireless/rtl818x/rtl8187/dev.c
>>> @@ -438,17 +438,16 @@ static int rtl8187_init_urbs(struct ieee80211_hw *dev)
>>> skb_queue_tail(&priv->rx_queue, skb);
>>> usb_anchor_urb(entry, &priv->anchored);
>>> ret = usb_submit_urb(entry, GFP_KERNEL);
>>> + usb_free_urb(entry);
>>> if (ret) {
>>> skb_unlink(skb, &priv->rx_queue);
>>> usb_unanchor_urb(entry);
>>> goto err;
>>> }
>>> - usb_free_urb(entry);
>>> }
>>> return ret;
>>>
>>> err:
>>> - usb_free_urb(entry);
>>> kfree_skb(skb);
>>> usb_kill_anchored_urbs(&priv->anchored);
>>> return ret;
>>> This part looks wrong - you free_urb(entry) then unanchor_urb(entry).
>> I do not see any problems here.
>> usb_free_urb() just decrements refcnt of the urb.
>> While usb_anchor_urb() and usb_unanchor_urb() increment and decrement it
>> as well.
>> So actual memory deallocation will happen in usb_unanchor_urb().
> If the routines work as you say, they probably are misnamed, and/or prototyped wrongly?
> Also, you are making assumptions about how they are implemented, and relying
> on the implementation details to be fixed for eternity.
>
> I am just saying,
>
> XXX_free(some_entity);
> if(condtion)
> do_stuff(some_entity);
>
> looks wrong, and if that's intentional, those routines really shouldn't be named as such.
There is an alias for usb_free_urb() named usb_put_urb().
I will resend the patch with such substitution.
--
Alexey
^ permalink raw reply
* Re: [PATCH net] net: ipv6: tcp: fix potential use after free in tcp_v6_do_rcv
From: Eric Dumazet @ 2013-09-03 20:35 UTC (permalink / raw)
To: Jean Sacren; +Cc: Daniel Borkmann, davem, netdev, yoshfuji, Jiri Benc
In-Reply-To: <20130903194620.GE8262@mail.gmail.com>
On Tue, 2013-09-03 at 13:46 -0600, Jean Sacren wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 03 Sep 2013 10:48:33 -0700
> >
> > On Tue, 2013-09-03 at 19:29 +0200, Daniel Borkmann wrote:
> > > In tcp_v6_do_rcv() code, when processing pkt options, we soley work
> > > on our skb clone opt_skb that we've created earlier before entering
> > > tcp_rcv_established() on our way. However, only in condition ...
> > >
> > > if (np->rxopt.bits.rxtclass)
> > > np->rcv_tclass = ipv6_get_dsfield(ipv6_hdr(skb));
> > >
> > > ... we work on skb itself. As we extract every other information out
> > > of opt_skb in ipv6_pktoptions path, this seems wrong, since skb can
> > > already be released by tcp_rcv_established() earlier on. When we try
> > > to access it in ipv6_hdr(), we will dereference freed skb.
> > >
> > > Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> > > Cc: Eric Dumazet <eric.dumazet@gmail.com>
> > > ---
> > > net/ipv6/tcp_ipv6.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
> > > index 6e1649d..eeb4cb0 100644
> > > --- a/net/ipv6/tcp_ipv6.c
> > > +++ b/net/ipv6/tcp_ipv6.c
> > > @@ -1427,7 +1427,7 @@ ipv6_pktoptions:
> > > if (np->rxopt.bits.rxhlim || np->rxopt.bits.rxohlim)
> > > np->mcast_hops = ipv6_hdr(opt_skb)->hop_limit;
> > > if (np->rxopt.bits.rxtclass)
> > > - np->rcv_tclass = ipv6_get_dsfield(ipv6_hdr(skb));
> > > + np->rcv_tclass = ipv6_get_dsfield(ipv6_hdr(opt_skb));
> > > if (ipv6_opt_accepted(sk, opt_skb)) {
> > > skb_set_owner_r(opt_skb, sk);
> > > opt_skb = xchg(&np->pktoptions, opt_skb);
> >
> > Bug added in commit 4c507d2897bd9b
> > ("net: implement IP_RECVTOS for IP_PKTOPTIONS")
> >
> > CC Jiri
> >
> > Acked-by: Eric Dumazet <edumazet@google.com>
>
> You made a mistake.
Really ?
>
> It was introduced in commit e7219858a ("ipv6: Use ipv6_get_dsfield()
> instead of ipv6_tclass()").
>
> Cc the right party.
>
Nope, I did no mistake.
The bug was really added in commit 4c507d2897bd9b as I said.
Then commit e7219858a just did no change : skb was used before and after
the patch
- np->rcv_tclass = ipv6_tclass(ipv6_hdr(skb));
+ np->rcv_tclass = ipv6_get_dsfield(ipv6_hdr(skb));
How did you get your conclusion ?
^ permalink raw reply
* [PATCH v2] rtl8187: fix use after free on failure path in rtl8187_init_urbs()
From: Alexey Khoroshilov @ 2013-09-03 20:37 UTC (permalink / raw)
To: Hin-Tak Leung, Larry Finger
Cc: Alexey Khoroshilov, John W. Linville, linux-wireless, netdev,
linux-kernel, ldv-project
In case of __dev_alloc_skb() failure rtl8187_init_urbs()
calls usb_free_urb(entry) where 'entry' can points to urb
allocated at the previous iteration. That means refcnt will be
decremented incorrectly and the urb can be used after memory
deallocation.
The patch fixes the issue and implements error handling of init_urbs
in rtl8187_start().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
---
drivers/net/wireless/rtl818x/rtl8187/dev.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8187/dev.c b/drivers/net/wireless/rtl818x/rtl8187/dev.c
index f49220e..a668c0e 100644
--- a/drivers/net/wireless/rtl818x/rtl8187/dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187/dev.c
@@ -438,17 +438,16 @@ static int rtl8187_init_urbs(struct ieee80211_hw *dev)
skb_queue_tail(&priv->rx_queue, skb);
usb_anchor_urb(entry, &priv->anchored);
ret = usb_submit_urb(entry, GFP_KERNEL);
+ usb_put_urb(entry);
if (ret) {
skb_unlink(skb, &priv->rx_queue);
usb_unanchor_urb(entry);
goto err;
}
- usb_free_urb(entry);
}
return ret;
err:
- usb_free_urb(entry);
kfree_skb(skb);
usb_kill_anchored_urbs(&priv->anchored);
return ret;
@@ -956,8 +955,12 @@ static int rtl8187_start(struct ieee80211_hw *dev)
(RETRY_COUNT << 8 /* short retry limit */) |
(RETRY_COUNT << 0 /* long retry limit */) |
(7 << 21 /* MAX TX DMA */));
- rtl8187_init_urbs(dev);
- rtl8187b_init_status_urb(dev);
+ ret = rtl8187_init_urbs(dev);
+ if (ret)
+ goto rtl8187_start_exit;
+ ret = rtl8187b_init_status_urb(dev);
+ if (ret)
+ usb_kill_anchored_urbs(&priv->anchored);
goto rtl8187_start_exit;
}
@@ -966,7 +969,9 @@ static int rtl8187_start(struct ieee80211_hw *dev)
rtl818x_iowrite32(priv, &priv->map->MAR[0], ~0);
rtl818x_iowrite32(priv, &priv->map->MAR[1], ~0);
- rtl8187_init_urbs(dev);
+ ret = rtl8187_init_urbs(dev);
+ if (ret)
+ goto rtl8187_start_exit;
reg = RTL818X_RX_CONF_ONLYERLPKT |
RTL818X_RX_CONF_RX_AUTORESETPHY |
--
1.8.1.2
^ permalink raw reply related
* Re: [guv v2 04/31] net: Replace __get_cpu_var uses
From: David Howells @ 2013-09-03 20:39 UTC (permalink / raw)
To: David Miller
Cc: dhowells, cl, tj, akpm, netdev, linux-arch, srostedt,
linux-kernel
In-Reply-To: <20130902.203355.117341085023152754.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
> > Would it be possible to use __thread annotations for per-CPU
> > variables, I wonder?
>
> Paul Mackerras tried it on powerpc and you can't do it.
>
> The problem is that there is no way to tell the compiler that sched()
> and similar (potentially) change the thread pointer base.
>
> It really will cache pre-computed __thread pointer calculations across
> sched().
Yeah... I thought there might be something like that - but I could see x86_64
using %fs as a base.
David
^ permalink raw reply
* Re: [PATCH] ppc: bpf_jit: support MOD operation
From: Daniel Borkmann @ 2013-09-03 20:52 UTC (permalink / raw)
To: Vladimir Murzin
Cc: Benjamin Herrenschmidt, linuxppc-dev, paulus, davem, Matt Evans,
netdev
In-Reply-To: <20130903195819.GA1971@hp530>
On 09/03/2013 09:58 PM, Vladimir Murzin wrote:
> On Tue, Sep 03, 2013 at 06:45:50AM +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2013-09-02 at 19:48 +0200, Vladimir Murzin wrote:
>>> Ping
>>>
>>> On Wed, Aug 28, 2013 at 02:49:52AM +0400, Vladimir Murzin wrote:
>>>> commit b6069a9570 (filter: add MOD operation) added generic
>>>> support for modulus operation in BPF.
>>>>
>> Sorry, nobody got a chance to review that yet. Unfortunately Matt
>> doesn't work for us anymore and none of us has experience with the
>> BPF code, so somebody (possibly me) will need to spend a bit of time
>> figuring it out before verifying that is correct.
>>
>> Do you have a test case/suite by any chance ?
>>
>> Ben.
>>
>
> Hi Ben!
>
> Thanks for your feedback.
>
> This patch is only compile tested. I have no real hardware, but I'll
> probably bring up qemu ppc64 till end of the week...
> Meanwhile, I've made simple how-to for testing. You can use it if you wish.
> It is mainly based on the [1] and rechecked on x86-64.
Please also cc netdev on BPF related changes.
Actually, your test plan can be further simplified ...
For retrieving and disassembling the JIT image, we have bpf_jit_disasm [1].
1) echo 2 > /proc/sys/net/core/bpf_jit_enable
2) ... attach filter ...
3) bpf_jit_disasm -o
For generating a simple stupid test filter, you can use bpfc [2] (also
see its man page). E.g. ...
# cat blub
ldi #10
mod #8
ret a
# bpfc blub
{ 0x0, 0, 0, 0x0000000a },
{ 0x94, 0, 0, 0x00000008 },
{ 0x16, 0, 0, 0x00000000 },
And load this array e.g. either into a small C program that attaches this
as BPF filter, or simply do bpfc blub > blub2 and run netsniff-ng -f blub2\
-s -i eth0, that should also do it.
Then, when attached, the kernel should truncate incoming frames for pf_packet
into max length of 2, just as an example.
[1] kernel tree, tools/net/bpf_jit_disasm.c
[2] git clone git://github.com/borkmann/netsniff-ng.git
> 1. get the tcpdump utility (git clone git://bpf.tcpdump.org/tcpdump)
> 2. get the libcap library (git clone git://bpf.tcpdump.org/libpcap)
> 2.1. apply patch for libcap [2] (against libcap-1.3 branch)
> 2.2. build libcap (./configure && make && ln -s libcap.so.1.3.0 libcap.so)
> 3. build tcpdump (LDFLAGS="-L/path/to/libcap" ./configure && make)
> 4. run
>
> # ./tcpdump -d "(ip[2:2] - 20) % 5 != 0 && ip[6] & 0x20 = 0x20"
> (000) ldh [14]
> (001) jeq #0x800 jt 2 jf 10
> (002) ldh [18]
> (003) sub #20
> (004) mod #5
> (005) jeq #0x0 jt 10 jf 6
> (006) ldb [22]
> (007) and #0x20
> (008) jeq #0x20 jt 9 jf 10
> (009) ret #65535
> (010) ret #0
>
> to get pseudo code (we are interested the most into line #4)
>
> 5. enable bpf jit compiler
>
> # echo 2 > /proc/sys/net/core/bpf_jit_enable
>
> 6. run
>
> ./tcpdump -nv "(ip[2:2] - 20) % 5 != 0 && ip[6] & 0x20 = 0x20"
>
> 7. check dmesg for lines starting with (output for x86-64 is provided as an example)
>
> [ 3768.329253] flen=11 proglen=99 pass=3 image=ffffffffa003c000
> [ 3768.329254] JIT code: ffffffffa003c000: 55 48 89 e5 48 83 ec 60 48 89 5d f8 44 8b 4f 60
> [ 3768.329255] JIT code: ffffffffa003c010: 44 2b 4f 64 4c 8b 87 c0 00 00 00 0f b7 47 76 86
> [ 3768.329256] JIT code: ffffffffa003c020: c4 3d 00 08 00 00 75 37 be 02 00 00 00 e8 9f 3e
> [ 3768.329257] JIT code: ffffffffa003c030: 02 e1 83 e8 14 31 d2 b9 05 00 00 00 f7 f1 89 d0
> [ 3768.329258] JIT code: ffffffffa003c040: 85 c0 74 1b be 06 00 00 00 e8 9f 3e 02 e1 25 20
> [ 3768.329259] JIT code: ffffffffa003c050: 00 00 00 83 f8 20 75 07 b8 ff ff 00 00 eb 02 31
> [ 3768.329259] JIT code: ffffffffa003c060: c0 c9 c3
>
> 8. make sure generated opcodes (JIT code) implement pseudo code form step 4.
>
> Reference
> [1] http://comments.gmane.org/gmane.linux.network/242456
> [2] http://permalink.gmane.org/gmane.network.tcpdump.devel/5973
>
> P.S.
> I hope net people will corect me if I'm wrong there
>
> Cheers
> Vladimir Murzin
>
>>>> This patch brings JIT support for PPC64
>>>>
>>>> Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next] bcm87xx: Add MODULE_DEVICE_TABLE
From: Ben Hutchings @ 2013-09-03 20:53 UTC (permalink / raw)
To: David Daney; +Cc: David Miller, David Daney, David Daney, netdev
In-Reply-To: <52263872.40209@caviumnetworks.com>
On Tue, Sep 03, 2013 at 12:28:50PM -0700, David Daney wrote:
> On 09/03/2013 12:13 PM, David Daney wrote:
> >On 09/03/2013 11:53 AM, Ben Hutchings wrote:
> >>On Tue, Sep 03, 2013 at 10:32:02AM -0700, David Daney wrote:
> >>>On 09/01/2013 02:33 PM, Ben Hutchings wrote:
> >>>>bcm87xx currently isn't auto-loaded if built as a module.
> >>>>
> >>>>Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> >>>>---
> >>>>Compile-tested only.
> >>>
> >>>Then how do you know that it does anything sensible?
> >>
> >>This is generally required in modular PHY drivers. I was hoping you'd
> >>be able to say whether that it's useful or necessary for this one.
> >
> >
> >OK. I just tested the patch, and it is not sufficient to get the module
> >loaded automatically.
> >
>
> The problem is that get_phy_c45_ids() sets the phy_id that is passed
> to request_module() to zero, so it will never match anything.
Right. Now I see that phy_driver::phy_id{,_mask} are actually not
used for this driver because phy_driver::match_phy_device overrides
those.
> We need to think about how this should work for 802.3-c45 PHYs.
>
> Most c54 PHYs are conceptually composed of several pieces each with
> its own set of identifiers.
Yes, I know that but I wasn't sure how libphy deals with them.
> Which of these should be used? Will
> something break if we start supplying a C22 phy_id for these
> devices?
But which one? Maybe it would make sense to generate a modalias for
the device with all MMDs listed:
mdio:<mmd><id>...
where <mmd> is the MMD number converted to a letter (a-z, A-F) and
<id> is the device ID as a bitstring, and they're repeated for all
present MMDs. A module would then have modaliases that match on
any particular MMD's ID, e.g. this module would have the aliases:
mdio:*e00000001010000111011110111000001*
mdio:*e00000001010000111011111111110000*
(I'm assuming that a driver wouldn't need to match on multiple
MMD IDs, which would make the device table structure and
modpost logic more complicated.)
Maybe there's a simpler way to do it, but I don't know what.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
^ permalink raw reply
* Re: [PATCH v2 0/8] Drop support for Renesas H8/300 architecture
From: Guenter Roeck @ 2013-09-03 20:59 UTC (permalink / raw)
To: Al Viro
Cc: Chen Gang F T, linux-kernel, linux-ide, netdev, linux-watchdog,
Wim Van Sebroeck, David S. Miller, Yoshinori Sato,
Geert Uytterhoeven, Eric Paris, Greg Kroah-Hartman, Jiang Liu,
David Howells, Thomas Gleixner, Stephen Rothwell, Linus Torvalds,
Andrew Morton, Rusty Russell, Linus Walleij
In-Reply-To: <20130903193938.GB13318@ZenIV.linux.org.uk>
On Tue, Sep 03, 2013 at 08:39:38PM +0100, Al Viro wrote:
> On Tue, Sep 03, 2013 at 11:52:17AM +0800, Chen Gang F T wrote:
>
> > extreme sample: let 'kernel code style' and 'gcc code style' in one file, that will make the code very ugly.
>
> gcc style will make any code very ugly, no matter what (if anything) else is
> in the same file...
>
> [digs out the ports history table]
> x86: 0.01 [alive]
> i386: 0.01..2.6.24-rc1 [folded into x86]
> x86_64: 2.5.5-pre1..2.6.24-rc1 [folded into x86]
> x86: 2.6.24-rc1 [alive]
> alpha: 1.1.67 [alive]
> sparc: 1.1.77 [alive]
> sparc64: 2.1.19..2.6.28 [folded into sparc]
> mips: 1.1.82 [alive]
> mips64: 2.3.48-pre2..2.6.0-test2 [folded into mips]
> powerpc: 1.3.45 [alive]
> ppc: 1.3.45..2.6.26 [folded into powerpc]
> ppc64: 2.5.5..2.6.15-rc1 [folded into powerpc]
> powerpc: 2.6.15-rc1 [alive]
> m68k: 1.3.94 [alive]
> m68knommu: 2.5.46..2.6.38 [folded into m68k]
> arm: 2.1.80 [alive]
> arm26: 2.5.71..2.6.23-rc2 [gone]
> arm64: 3.7-rc1 [alive][might eventually fold]
> sh: 2.3.16 [alive]
> sh64: 2.6.8-rc1..2.6.24 [folded into sh, nearly dead there]
> ia64: 2.3.43-pre1 [alive]
> s390: 2.3.99pre8 [alive]
> s390x: 2.5.0..2.5.67 [folded into s390]
> parisc: 2.4.0-test12 [alive]
> cris: 2.5.0 [alive]
> um: 2.5.35 [alive]
> v850: 2.5.46..2.6.26 [gone]
> h8300: 2.5.68 [moderately responsive]
> m32r: 2.6.9-rc3 [alive]
> frv: 2.6.11-rc1 [alive]
> xtensa: 2.6.13-rc1 [alive]
> avr32: 2.6.19-rc1 [alive]
> blackfin: 2.6.22-rc1 [alive]
> mn10300: 2.6.25-rc1 [alive]
> microblaze: 2.6.30-rc2 [alive]
> score: 2.6.32-rc1 [abandoned][cloned off mips]
> tile: 2.6.36-rc1 [alive]
> unicore32: 2.6.39-rc1 [alive][cloned off arm]
> openrisc: 3.1-rc1 [alive]
> hexagon: 3.2-rc1 [alive]
> c6x: 3.3-rc1 [alive]
> arc: 3.9-rc1 [alive]
> metag: 3.9-rc1 [alive]
>
> Frankly, I would've expected score and lefotvers of sh64 (aka sh5) to be
> the first against the wall - h8300 was a bit surprising...
>
Great summary.
There seemed to be a consensus to remove h8300, at least so far and sufficiently
enough for me to ask Stephen to add the removal branch to linux-next.
We'll see if that triggers any further responses.
With score, I am not entirely sure. I got one Ack for the removal, but
on the other side the score maintainers came back and claimed they would
still support it. We'll see if anything changes in practice. I am still
not sure if I should ask for the removal branch to be added to linux-next.
Frankly I thought I might jump the gun here more than with h8300.
Either case, what to ultimately do with those two architectures will be
up to the community to decide.
Guenter
^ permalink raw reply
* Re: [PATCH net-next 4/8] net: ipv6: mld: implement RFC3810 MLDv2 mode only
From: Hannes Frederic Sowa @ 2013-09-03 21:00 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev
In-Reply-To: <1378195178-21002-5-git-send-email-dborkman@redhat.com>
Hi Daniel!
On Tue, Sep 03, 2013 at 09:59:34AM +0200, Daniel Borkmann wrote:
> RFC3810, 10. Security Considerations says under subsection 10.1.
> Query Message:
>
> A forged Version 1 Query message will put MLDv2 listeners on that
> link in MLDv1 Host Compatibility Mode. This scenario can be avoided
> by providing MLDv2 hosts with a configuration option to ignore
> Version 1 messages completely.
>
> Hence, implement a MLDv2-only mode that will ignore MLDv1 traffic:
>
> echo 2 > /proc/sys/net/ipv6/conf/ethX/force_mld_version
I just played around with MLDv2-only mode and noticed that the commit message
diverges from the code:
> diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
> index 005b22f..02cd0c5 100644
> --- a/net/ipv6/mcast.c
> +++ b/net/ipv6/mcast.c
> @@ -1112,9 +1112,21 @@ static bool mld_marksources(struct ifmcaddr6 *pmc, int nsrcs,
> return true;
> }
>
> +static bool mld_in_v2_mode_only(const struct inet6_dev *idev)
> +{
> + return dev_net(idev->dev)->ipv6.devconf_all->force_mld_version == 2;
Maybe something like
int val = idev->cnf.force_mld_version ?: dev_net(idev->dev)->ipv6.devconf_all->force_mld_version;
return val == 2;
> +}
> +
> +static bool mld_in_v1_mode_only(const struct inet6_dev *idev)
> +{
> + return dev_net(idev->dev)->ipv6.devconf_all->force_mld_version == 1;
Likewise.
> +}
> +
> static bool mld_in_v1_mode(const struct inet6_dev *idev)
> {
> - if (dev_net(idev->dev)->ipv6.devconf_all->force_mld_version == 1)
> + if (mld_in_v2_mode_only(idev))
> + return false;
> + if (mld_in_v1_mode_only(idev))
> return true;
> if (idev->cnf.force_mld_version == 1)
> return true;
This last if statement could be dropped then.
Thanks,
Hannes
^ permalink raw reply
* [PATCH net-next] tcp: better comments for RTO initiallization
From: Yuchung Cheng @ 2013-09-03 21:14 UTC (permalink / raw)
To: davem, ncardwell, edumazet; +Cc: netdev, Yuchung Cheng
Commit 1b7fdd2ab585("tcp: do not use cached RTT for RTT estimation")
removes important comments on how RTO is initialized and updated.
Hopefully this patch puts those information back.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
---
net/ipv4/tcp_metrics.c | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/tcp_metrics.c b/net/ipv4/tcp_metrics.c
index 273ed73..4a22f3e 100644
--- a/net/ipv4/tcp_metrics.c
+++ b/net/ipv4/tcp_metrics.c
@@ -481,13 +481,27 @@ void tcp_init_metrics(struct sock *sk)
crtt = tcp_metric_get_jiffies(tm, TCP_METRIC_RTT);
rcu_read_unlock();
reset:
+ /* The initial RTT measurement from the SYN/SYN-ACK is not ideal
+ * to seed the RTO for later data packets because SYN packets are
+ * small. Use the per-dst cached values to seed the RTO but keep
+ * the RTT estimator variables intact (e.g., srtt, mdev, rttvar).
+ * Later the RTO will be updated immediately upon obtaining the first
+ * data RTT sample (tcp_rtt_estimator()). Hence the cached RTT only
+ * influences the first RTO but not later RTT estimation.
+ *
+ * But if RTT is not available from the SYN (due to retransmits or
+ * syn cookies) or the cache, force a conservative 3secs timeout.
+ *
+ * A bit of theory. RTT is time passed after "normal" sized packet
+ * is sent until it is ACKed. In normal circumstances sending small
+ * packets force peer to delay ACKs and calculation is correct too.
+ * The algorithm is adaptive and, provided we follow specs, it
+ * NEVER underestimate RTT. BUT! If peer tries to make some clever
+ * tricks sort of "quick acks" for time long enough to decrease RTT
+ * to low value, and then abruptly stops to do it and starts to delay
+ * ACKs, wait for troubles.
+ */
if (crtt > tp->srtt) {
- /* Initial RTT (tp->srtt) from SYN usually don't measure
- * serialization delay on low BW links well so RTO may be
- * under-estimated. Stay conservative and seed RTO with
- * the RTTs from past data exchanges, using the same seeding
- * formula in tcp_rtt_estimator().
- */
inet_csk(sk)->icsk_rto = crtt + max(crtt >> 2, tcp_rto_min(sk));
} else if (tp->srtt == 0) {
/* RFC6298: 5.7 We've failed to get a valid RTT sample from
--
1.8.4
^ permalink raw reply related
* Re: [PATCH net-next 4/8] net: ipv6: mld: implement RFC3810 MLDv2 mode only
From: Daniel Borkmann @ 2013-09-03 21:16 UTC (permalink / raw)
To: davem, netdev; +Cc: Hannes Frederic Sowa
In-Reply-To: <20130903210011.GB28889@order.stressinduktion.org>
On 09/03/2013 11:00 PM, Hannes Frederic Sowa wrote:
> Hi Daniel!
>
> On Tue, Sep 03, 2013 at 09:59:34AM +0200, Daniel Borkmann wrote:
>> RFC3810, 10. Security Considerations says under subsection 10.1.
>> Query Message:
>>
>> A forged Version 1 Query message will put MLDv2 listeners on that
>> link in MLDv1 Host Compatibility Mode. This scenario can be avoided
>> by providing MLDv2 hosts with a configuration option to ignore
>> Version 1 messages completely.
>>
>> Hence, implement a MLDv2-only mode that will ignore MLDv1 traffic:
>>
>> echo 2 > /proc/sys/net/ipv6/conf/ethX/force_mld_version
>
> I just played around with MLDv2-only mode and noticed that the commit message
> diverges from the code:
>
>> diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
>> index 005b22f..02cd0c5 100644
>> --- a/net/ipv6/mcast.c
>> +++ b/net/ipv6/mcast.c
>> @@ -1112,9 +1112,21 @@ static bool mld_marksources(struct ifmcaddr6 *pmc, int nsrcs,
>> return true;
>> }
>>
>> +static bool mld_in_v2_mode_only(const struct inet6_dev *idev)
>> +{
>> + return dev_net(idev->dev)->ipv6.devconf_all->force_mld_version == 2;
>
> Maybe something like
>
> int val = idev->cnf.force_mld_version ?: dev_net(idev->dev)->ipv6.devconf_all->force_mld_version;
> return val == 2;
Hm, true, thanks for spotting. I think it makes sense, first check for individual idev
setting, then for whole namespace. I will update the series and send v2.
>> +}
>> +
>> +static bool mld_in_v1_mode_only(const struct inet6_dev *idev)
>> +{
>> + return dev_net(idev->dev)->ipv6.devconf_all->force_mld_version == 1;
>
> Likewise.
>
>> +}
>> +
>> static bool mld_in_v1_mode(const struct inet6_dev *idev)
>> {
>> - if (dev_net(idev->dev)->ipv6.devconf_all->force_mld_version == 1)
>> + if (mld_in_v2_mode_only(idev))
>> + return false;
>> + if (mld_in_v1_mode_only(idev))
>> return true;
>> if (idev->cnf.force_mld_version == 1)
>> return true;
>
> This last if statement could be dropped then.
>
> Thanks,
>
> Hannes
>
^ permalink raw reply
* Possible to add netfilter hooks to IFB driver?
From: Brad Johnson @ 2013-09-03 21:26 UTC (permalink / raw)
To: netdev
I would like to add netfilter hooks to the IFB driver so I can do
iptables -j IFB (just like we can with IMQ). But I would like to know
first if there are any reasons this can not work. Please advise if this
is possible, and if so any tips would be appreciated.
Cheers,
Brad
^ permalink raw reply
* Re: [PATCH net-next] tcp: better comments for RTO initiallization
From: Neal Cardwell @ 2013-09-03 21:31 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: David Miller, Eric Dumazet, Netdev
In-Reply-To: <1378242875-5172-1-git-send-email-ycheng@google.com>
On Tue, Sep 3, 2013 at 5:14 PM, Yuchung Cheng <ycheng@google.com> wrote:
> Commit 1b7fdd2ab585("tcp: do not use cached RTT for RTT estimation")
> removes important comments on how RTO is initialized and updated.
> Hopefully this patch puts those information back.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> ---
> net/ipv4/tcp_metrics.c | 26 ++++++++++++++++++++------
> 1 file changed, 20 insertions(+), 6 deletions(-)
Acked-by: Neal Cardwell <ncardwell@google.com>
Thanks, Yuchung!
neal
^ permalink raw reply
* Re: [PATCH net-next] tcp: better comments for RTO initiallization
From: Eric Dumazet @ 2013-09-03 21:33 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: davem, ncardwell, edumazet, netdev
In-Reply-To: <1378242875-5172-1-git-send-email-ycheng@google.com>
On Tue, 2013-09-03 at 14:14 -0700, Yuchung Cheng wrote:
> Commit 1b7fdd2ab585("tcp: do not use cached RTT for RTT estimation")
> removes important comments on how RTO is initialized and updated.
> Hopefully this patch puts those information back.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> ---
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [-next] openvswitch BUILD_BUG_ON failed
From: Jesse Gross @ 2013-09-03 21:44 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David Miller, Andy Zhou, dev@openvswitch.org, netdev,
Linux Kernel Mailing List, Linux-Next
In-Reply-To: <CAMuHMdU3M9uUFKd3EQ0HbcAvf5e62PA4NJG_mQHhpvZwFJnUWQ@mail.gmail.com>
On Sat, Aug 31, 2013 at 5:11 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Fri, Aug 30, 2013 at 3:11 AM, Jesse Gross <jesse@nicira.com> wrote:
>> On Thu, Aug 29, 2013 at 3:10 PM, David Miller <davem@davemloft.net> wrote:
>>> From: Jesse Gross <jesse@nicira.com>
>>> Date: Thu, 29 Aug 2013 14:42:22 -0700
>>>
>>>> On Thu, Aug 29, 2013 at 2:21 PM, Geert Uytterhoeven
>>>> <geert@linux-m68k.org> wrote:
>>>>> However, I have some doubts about other alignment "enforcements":
>>>>>
>>>>> "__aligned(__alignof__(long))" makes the whole struct aligned to the
>>>>> alignment rule for "long":
>>>>> 1. This is only 2 bytes on m68k, i.e. != sizeof(long).
>>>>> 2. This is 4 bytes on many 32-bit platforms, which may be less than the
>>>>> default alignment for "__be64" (cfr. some members of struct
>>>>> ovs_key_ipv4_tunnel), so this may make those 64-bit members unaligned.
>>>>
>>>> Do any of those 32-bit architectures actually care about alignment of
>>>> 64 bit values? On 32-bit x86, a long is 32 bits but the alignment
>>>> requirement of __be64 is also 32 bit.
>>>
>>> All except x86-32 do, it is in fact the odd man out with respect to this
>>> issue.
>>
>> Thanks, good to know.
>>
>> Andy, do you want to modify your patch to just drop the alignment
>> specification as Geert suggested (but definitely keep the new build
>> assert that you added)? It's probably better to just send the patch to
>> netdev (against net-next) as well since you'll likely get better
>> comments there and we can fix this faster if you cut out the
>> middleman.
>
> Why do you want to keep the build asserts?
> Is this in-memory structure also transfered as-is over the network?
> If yes, you definitely want the padding.
Well they caught this bug and really don't cost anything.
> Nevertheless, as the struct contains u32 and even __be64 members, the
> size of the struct will always be a multiple of the alignment unit for
> 64-bit quantities (and thus also for long), as per the C standard.
> Hence the check
>
> BUILD_BUG_ON(sizeof(struct sw_flow_key) % __alignof__(long));
>
> will only catch bad compiler bugs or people adding __packed to the struct.
It's possible that we might want to pack the structure in the future.
More generally though, the contents of the struct is really
independent of the alignment requirements here because we're accessing
it as an array of bytes in long-sized chunks so implicitly depending
on the size of the members is not that great.
^ permalink raw reply
* Re: [PATCH] xen-netback: count number required slots for an skb more carefully
From: Wei Liu @ 2013-09-03 21:53 UTC (permalink / raw)
To: David Vrabel
Cc: xen-devel, Konrad Rzeszutek Wilk, Boris Ostrovsky, Ian Campbell,
netdev, wei.liu2, msw, annie.li
In-Reply-To: <1378229390-12919-1-git-send-email-david.vrabel@citrix.com>
On Tue, Sep 03, 2013 at 06:29:50PM +0100, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
>
> When a VM is providing an iSCSI target and the LUN is used by the
> backend domain, the generated skbs for direct I/O writes to the disk
> have large, multi-page skb->data but no frags.
>
> With some lengths and starting offsets, xen_netbk_count_skb_slots()
> would be one short because the simple calculation of
> DIV_ROUND_UP(skb_headlen(), PAGE_SIZE) was not accounting for the
> decisions made by start_new_rx_buffer() which does not guarantee
> responses are fully packed.
>
> For example, a skb with length < 2 pages but which spans 3 pages would
> be counted as requiring 2 slots but would actually use 3 slots.
>
> skb->data:
>
> | 1111|222222222222|3333 |
>
> Fully packed, this would need 2 slots:
>
> |111122222222|22223333 |
>
> But because the 2nd page wholy fits into a slot it is not split across
> slots and goes into a slot of its own:
>
> |1111 |222222222222|3333 |
>
> Miscounting the number of slots means netback may push more responses
> than the number of available requests. This will cause the frontend
> to get very confused and report "Too many frags/slots". The frontend
> never recovers and will eventually BUG.
>
> Fix this by counting the number of required slots more carefully. In
> xen_netbk_count_skb_slots(), more closely follow the algorithm used by
> xen_netbk_gop_skb() by introducing xen_netbk_count_frag_slots() which
> is the dry-run equivalent of netbk_gop_frag_copy().
>
Phew! So this is backend miscounting bug. I thought it was a frontend
bug so it didn't ring a bell when we had our face-to-face discussion,
sorry. :-(
This bug was discussed back in July among Annie, Matt, Ian and I. We
finally agreed to take Matt's solution. Matt agreed to post final
version within a week but obviously he's too busy to do so. I was away
so I didn't follow closely. Eventually it fell through the crack. :-(
Matt, do you fancy sending the final version? IIRC the commit message
needs to be re-written. I personally still prefer Matt's solution as
it a) make efficient use of the ring, b) uses ring pointers to
calculate slots which is most accurate, c) removes the dependence on
MAX_SKB_FRAGS in guest RX path.
Anyway, we should get this fixed ASAP.
Thanks
Wei.
REF:
<1373409659-22383-1-git-send-email-msw@amazon.com>
<1373350520-19985-1-git-send-email-annie.li@oracle.com>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
> [Resend to actually Cc netdev, sorry.]
> ---
> drivers/net/xen-netback/netback.c | 94 +++++++++++++++++++++++++------------
> 1 files changed, 64 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 64828de..f149ce5 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -361,6 +361,49 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
> return false;
> }
>
> +struct xen_netbk_count_slot_state {
> + unsigned long copy_off;
> + bool head;
> +};
> +
> +unsigned int xen_netbk_count_frag_slots(struct xenvif *vif,
> + unsigned long offset, unsigned long size,
> + struct xen_netbk_count_slot_state *state)
> +{
> + unsigned count = 0;
> +
> + offset &= ~PAGE_MASK;
> +
> + while (size > 0) {
> + unsigned long bytes;
> +
> + bytes = PAGE_SIZE - offset;
> +
> + if (bytes > size)
> + bytes = size;
> +
> + if (start_new_rx_buffer(state->copy_off, bytes, state->head)) {
> + count++;
> + state->copy_off = 0;
> + }
> +
> + if (state->copy_off + bytes > MAX_BUFFER_OFFSET)
> + bytes = MAX_BUFFER_OFFSET - state->copy_off;
> +
> + state->copy_off += bytes;
> +
> + offset += bytes;
> + size -= bytes;
> +
> + if (offset == PAGE_SIZE)
> + offset = 0;
> +
> + state->head = false;
> + }
> +
> + return count;
> +}
> +
> /*
> * Figure out how many ring slots we're going to need to send @skb to
> * the guest. This function is essentially a dry run of
> @@ -368,48 +411,39 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
> */
> unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
> {
> + struct xen_netbk_count_slot_state state;
> unsigned int count;
> - int i, copy_off;
> + unsigned char *data;
> + unsigned i;
>
> - count = DIV_ROUND_UP(skb_headlen(skb), PAGE_SIZE);
> + state.head = true;
> + state.copy_off = 0;
>
> - copy_off = skb_headlen(skb) % PAGE_SIZE;
> + /* Slot for the first (partial) page of data. */
> + count = 1;
>
> + /* Need a slot for the GSO prefix for GSO extra data? */
> if (skb_shinfo(skb)->gso_size)
> count++;
>
> - for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
> - unsigned long size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
> - unsigned long offset = skb_shinfo(skb)->frags[i].page_offset;
> - unsigned long bytes;
> -
> - offset &= ~PAGE_MASK;
> -
> - while (size > 0) {
> - BUG_ON(offset >= PAGE_SIZE);
> - BUG_ON(copy_off > MAX_BUFFER_OFFSET);
> -
> - bytes = PAGE_SIZE - offset;
> -
> - if (bytes > size)
> - bytes = size;
> + data = skb->data;
> + while (data < skb_tail_pointer(skb)) {
> + unsigned long offset = offset_in_page(data);
> + unsigned long size = PAGE_SIZE - offset;
>
> - if (start_new_rx_buffer(copy_off, bytes, 0)) {
> - count++;
> - copy_off = 0;
> - }
> + if (data + size > skb_tail_pointer(skb))
> + size = skb_tail_pointer(skb) - data;
>
> - if (copy_off + bytes > MAX_BUFFER_OFFSET)
> - bytes = MAX_BUFFER_OFFSET - copy_off;
> + count += xen_netbk_count_frag_slots(vif, offset, size, &state);
>
> - copy_off += bytes;
> + data += size;
> + }
>
> - offset += bytes;
> - size -= bytes;
> + for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
> + unsigned long size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
> + unsigned long offset = skb_shinfo(skb)->frags[i].page_offset;
>
> - if (offset == PAGE_SIZE)
> - offset = 0;
> - }
> + count += xen_netbk_count_frag_slots(vif, offset, size, &state);
> }
> return count;
> }
> --
> 1.7.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] net: ipv6: tcp: fix potential use after free in tcp_v6_do_rcv
From: Jean Sacren @ 2013-09-03 21:59 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Daniel Borkmann, davem, netdev, yoshfuji, Jiri Benc
In-Reply-To: <1378240517.7360.41.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 03 Sep 2013 13:35:17 -0700
>
> How did you get your conclusion ?
If one changes one line of code, doesn't one own that line?
--
Jean Sacren
^ 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