* Re: extending ndo_add_rx_vxlan_port
From: Or Gerlitz @ 2013-10-27 20:34 UTC (permalink / raw)
To: Joseph Gasparakis
Cc: Or Gerlitz, John Fastabend, Yan Burman, netdev, Stephen Hemminger
In-Reply-To: <alpine.LFD.2.03.1310271017120.19783@intel.com>
On Sun, Oct 27, 2013 at 7:25 PM, Joseph Gasparakis
<joseph.gasparakis@intel.com> wrote:
>
>
> On Sun, 27 Oct 2013, Or Gerlitz wrote:
>
>> Hi,
>>
>> So with commit 53cf527513eed6e7170e9dceacd198f9267171b0 "vxlan: Notify drivers
>> for listening UDP port changes" drivers that have HW offloads for vxlan can be
>> notified on which UDP port to listen. Taking this further, some HW may need to
>> know the multicast address and/or the VNID used by the vxlan instance/s set
>> above them. In that respect, do we prefer to extend ndo_add_rx_vxlan_port() or
>> introduce new ndo?
>>
>> Or.
>>
>
> The way this patch works is to notify the drivers when a VXLAN UDP port
> comes up or down. This way drivers do not need to do any sort of accounting. As
Could you elaborate why do we want to notify all the netdev instances
in the system (on a certain name-space)
that vxlan instance/s are set to listen on certain UDP port and not
only the device over which the
vxlan device is being set? say the HW can listen limited amount of UDP
ports and few vxlan instances are created
one of top of each "real" netdev in the system and each on different
port. Each netdevice will get all callbacks on port addition
and at some point will start to fail adding them into the HW when the
HW limit is met.
Or.
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] bonding: patchset for rcu use in bonding
From: David Miller @ 2013-10-27 20:37 UTC (permalink / raw)
To: dingtianhong; +Cc: fubar, andy, nikolay, vfalico, netdev
In-Reply-To: <52688F33.30904@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Thu, 24 Oct 2013 11:08:35 +0800
> The slave list will add and del by bond_master_upper_dev_link() and bond_upper_dev_unlink(),
> which will call call_netdevice_notifiers(), even it is safe to call it in write bond lock now,
> but we can't sure that whether it is safe later, because other drivers may deal NETDEV_CHANGEUPPER
> in sleep way, so I didn't admit move the bond_upper_dev_unlink() in write bond lock.
>
> now the bond_for_each_slave only protect by rtnl_lock(), maybe use bond_for_each_slave_rcu is a good
> way to protect slave list for bond, but as a system slow path, it is no need to transform bond_for_each_slave()
> to bond_for_each_slave_rcu() in slow path, so in the patchset, I will remove the unused read bond lock
> for monitor function, maybe it is a better way, I will wait to accept any relay for it.
>
> Thanks for the Veaceslav Falico opinion.
>
> v2: add and modify commit for patchset and patch, it will be the first step for the whole patchset.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/2] net_sched: Remove broken tc actions
From: Alexander Duyck @ 2013-10-27 20:37 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Eric W. Biederman, David Miller, netdev, alexander.h.duyck
In-Reply-To: <526D463E.6040000@mojatatu.com>
On 10/27/2013 09:58 AM, Jamal Hadi Salim wrote:
> On 10/27/13 09:40, Eric W. Biederman wrote:
>>
>> While auditing the code to make certain it would be safe to enable the
>> user namespace root to use tc actions I stumbled on the strange fact
>> that two of the tc modules in the kernel have been broken for more
>> years than I care to think about.
>>
>> In particular neither of these two modules implements the tc_action_ops
>> lookup method. Which means that in practice neither RTM_GETACTION nor
>> RTM_DELACTION work. And with RTM_DELACTION broken that looks like a
>> permanent leak of kernel memory to me.
>>
>>
>> A leak I am not happy at root having and certainly not something I want
>> to allow unprivileged users access to.
>>
>> On the premise that 5+ years is too long to wait for someone to notice,
>> complain and get this code fixed let's just remove these broken tc
>> modules.
>>
>
>
> Nah, dude.
> You dont have to implement the get/del. Actions are typically bound
> to filters; when the filters disappears the action is destroyed.
> You Get the filter, you Get the bound actions.
> you can add actions without filters - but in such a case, for both
> of these ones you picked, you can dump or flush them unless they are
> bound to a filter. Thats the minimal requirement (which is met).
>
> What is your use case to need explicit get/del?
> Given act_simple is pedagogical in nature, I think
> that will be useful for illustration purposes.
>
> cheers,
> jamal
The primary use case for act_skbedit was to have it associated with a
filter. I based it off of act_simple so it isn't surprising that it
inherited this issue.
>From what I can tell all of the other actions are just using
tcf_hash_search for lookup. Is there anything special that is needed in
order to add the lookup call, or could we just add a one liner
associating simple and skbedit lookup with tcf_hash_search?
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH net v4] be2net: Warn users of possible broken functionality on BE2 cards with very old FW versions with latest driver
From: David Miller @ 2013-10-27 20:38 UTC (permalink / raw)
To: somnath.kotur; +Cc: netdev
In-Reply-To: <62f97dab-6b78-43bd-9b77-36c7f0dcdbf8@CMEXHTCAS1.ad.emulex.com>
From: Somnath Kotur <somnath.kotur@emulex.com>
Date: Thu, 24 Oct 2013 14:37:53 +0530
> On very old FW versions < 4.0, the mailbox command to set interrupts
> on the card succeeds even though it is not supported and should have
> failed, leading to a scenario where interrupts do not work.
> Hence warn users to upgrade to a suitable FW version to avoid seeing
> broken functionality.
>
> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
Applied, thanks.
^ permalink raw reply
* Re: [BUG 3.12.rc4] Oops: unable to handle kernel paging request during shutdown
From: Linus Torvalds @ 2013-10-27 20:39 UTC (permalink / raw)
To: Thomas Gleixner, Pablo Neira Ayuso, Patrick McHardy,
Jozsef Kadlecsik, David Miller
Cc: Knut Petersen, Ingo Molnar, Paul McKenney,
Frédéric Weisbecker, Greg KH, linux-kernel,
Network Development, netfilter-devel
In-Reply-To: <CA+55aFyb72qoZ1Tjpb+=q-6+GmwoOXjfntY_zZnf300gg3d1Hg@mail.gmail.com>
On Sun, Oct 27, 2013 at 8:20 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Appended is a warning I get with DEBUG_TIMER_OBJECTS. Seems to be a
> device-mapper issue.
.. and here's another one. This time it looks like nf_conntrack_free()
is freeing something that has a delayed work in it (again, likely an
embedded 'struct kobject'). Looks like it is the
kmem_cache_destroy(net->ct.nf_conntrack_cachep);
that triggers this. Which probably means that there are still slab
entries on that slab cache or something, but I didn't dig any deeper..
David? Patrick? Pablo? Jozsef? Any ideas? This was immediately preceded by
[ 1136.316280] kobject: 'nf_conntrack_ffff8800b74d0000'
(ffff8801196fac78): kobject_uevent_env
[ 1136.316287] kobject: 'nf_conntrack_ffff8800b74d0000'
(ffff8801196fac78): fill_kobj_path: path =
'/kernel/slab/nf_conntrack_ffff8800b74d0000'
[ 1136.316331] kobject: 'nf_conntrack_ffff8800b74d0000'
(ffff8801196fac78): kobject_release, parent (null) (delayed)
and I think it's that delayed "kobject_release()" that triggers this.
Notice that kobject_release() can be delayed *without* the magic
kobject debugging option by simply having a reference count on it from
some external source. So this particular issue is probably triggered
by my extra debug options in this case (I'm running with all those
nasty "try to find bad object freeing" options, and doing module
unloading etc), but can happen without it (it's just very hard to
trigger in practice without the debug options).
Linus
---
[ 1136.321294] ------------[ cut here ]------------
[ 1136.321305] WARNING: CPU: 2 PID: 2483 at lib/debugobjects.c:260
debug_print_object+0x83/0xa0()
[ 1136.321311] ODEBUG: free active (active state 0) object type:
timer_list hint: delayed_work_timer_fn+0x0/0x20
[ 1136.321313] Modules linked in: fuse nf_conntrack_netbios_ns
nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT xt_conntrack bnep
bluetooth ebtable_nat ebt
[ 1136.321357] mfd_core mei snd_page_alloc snd_timer snd soundcore
sony_laptop rfkill uinput dm_crypt crc32_pclmul crc32c_intel i915
i2c_algo_bit drm_kms_h
[ 1136.321371] CPU: 2 PID: 2483 Comm: kworker/u8:2 Tainted: G W
3.12.0-rc6-00331-ga2ff82065b5b #2
[ 1136.321373] Hardware name: Sony Corporation SVP11213CXB/VAIO, BIOS
R0270V7 05/17/2013
[ 1136.321378] Workqueue: netns cleanup_net
[ 1136.321380] 0000000000000009 ffff8800a86cdbc8 ffffffff8160d4a2
ffff8800a86cdc10
[ 1136.321384] ffff8800a86cdc00 ffffffff810514e8 ffff8800b745f848
ffffffff81c365e0
[ 1136.321387] ffffffff819f9133 ffffffff81f34750 0000000000000001
ffff8800a86cdc60
[ 1136.321390] Call Trace:
[ 1136.321398] [<ffffffff8160d4a2>] dump_stack+0x45/0x56
[ 1136.321405] [<ffffffff810514e8>] warn_slowpath_common+0x78/0xa0
[ 1136.321410] [<ffffffff81051557>] warn_slowpath_fmt+0x47/0x50
[ 1136.321414] [<ffffffff812f8883>] debug_print_object+0x83/0xa0
[ 1136.321420] [<ffffffff8106aa90>] ? execute_in_process_context+0x90/0x90
[ 1136.321424] [<ffffffff812f99fb>] debug_check_no_obj_freed+0x20b/0x250
[ 1136.321429] [<ffffffff8112e7f2>] ? kmem_cache_destroy+0x92/0x100
[ 1136.321433] [<ffffffff8115d945>] kmem_cache_free+0x125/0x210
[ 1136.321436] [<ffffffff8112e7f2>] kmem_cache_destroy+0x92/0x100
[ 1136.321443] [<ffffffffa046b806>]
nf_conntrack_cleanup_net_list+0x126/0x160 [nf_conntrack]
[ 1136.321449] [<ffffffffa046c43d>]
nf_conntrack_pernet_exit+0x6d/0x80 [nf_conntrack]
[ 1136.321453] [<ffffffff81511cc3>] ops_exit_list.isra.3+0x53/0x60
[ 1136.321457] [<ffffffff815124f0>] cleanup_net+0x100/0x1b0
[ 1136.321460] [<ffffffff8106b31e>] process_one_work+0x18e/0x430
[ 1136.321463] [<ffffffff8106bf49>] worker_thread+0x119/0x390
[ 1136.321467] [<ffffffff8106be30>] ? manage_workers.isra.23+0x2a0/0x2a0
[ 1136.321470] [<ffffffff8107210b>] kthread+0xbb/0xc0
[ 1136.321472] [<ffffffff81072050>] ? kthread_create_on_node+0x110/0x110
[ 1136.321477] [<ffffffff8161b8fc>] ret_from_fork+0x7c/0xb0
[ 1136.321479] [<ffffffff81072050>] ? kthread_create_on_node+0x110/0x110
[ 1136.321481] ---[ end trace 25f53c192da70825 ]---
^ permalink raw reply
* Re: [PATCH net] tcp: fix SYNACK RTT estimation in Fast Open
From: David Miller @ 2013-10-27 20:51 UTC (permalink / raw)
To: ycheng; +Cc: ncardwell, edumazet, panweiping3, netdev
In-Reply-To: <1382629465-20310-1-git-send-email-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Thu, 24 Oct 2013 08:44:25 -0700
> tp->lsndtime may not always be the SYNACK timestamp if a passive
> Fast Open socket sends data before handshake completes. And if the
> remote acknowledges both the data and the SYNACK, the RTT sample
> is already taken in tcp_ack(), so no need to call
> tcp_update_ack_rtt() in tcp_synack_rtt_meas() aagain.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] tcp: fix SYNACK RTT estimation in Fast Open
From: David Miller @ 2013-10-27 20:51 UTC (permalink / raw)
To: ycheng; +Cc: ncardwell, edumazet, panweiping3, netdev
In-Reply-To: <1382629465-20310-1-git-send-email-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Thu, 24 Oct 2013 08:44:25 -0700
> tp->lsndtime may not always be the SYNACK timestamp if a passive
> Fast Open socket sends data before handshake completes. And if the
> remote acknowledges both the data and the SYNACK, the RTT sample
> is already taken in tcp_ack(), so no need to call
> tcp_update_ack_rtt() in tcp_synack_rtt_meas() aagain.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] tcp: only take RTT from timestamps if new data is acked
From: David Miller @ 2013-10-27 20:51 UTC (permalink / raw)
To: ycheng; +Cc: ncardwell, edumazet, netdev
In-Reply-To: <1382630125-21416-1-git-send-email-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Thu, 24 Oct 2013 08:55:25 -0700
> Patch ed08495c3 "tcp: use RTT from SACK for RTO" has a bug that
> it does not check if the ACK acknowledge new data before taking
> the RTT sample from TCP timestamps. This patch adds the check
> back as required by the RFC.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] tcp: do not rearm RTO when future data are sacked
From: David Miller @ 2013-10-27 20:52 UTC (permalink / raw)
To: ycheng; +Cc: ncardwell, edumazet, brakmo, netdev
In-Reply-To: <1382630367-21964-1-git-send-email-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Thu, 24 Oct 2013 08:59:27 -0700
> Patch ed08495c3 "tcp: use RTT from SACK for RTO" always re-arms RTO upon
> obtaining a RTT sample from newly sacked data.
>
> But technically RTO should only be re-armed when the data sent before
> the last (re)transmission of write queue head are (s)acked. Otherwise
> the RTO may continue to extend during loss recovery on data sent
> in the future.
>
> Note that RTTs from ACK or timestamps do not have this problem, as the RTT
> source must be from data sent before.
>
> The new RTO re-arm policy is
> 1) Always re-arm RTO if SND.UNA is advanced
> 2) Re-arm RTO if sack RTT is available, provided the sacked data was
> sent before the last time write_queue_head was sent.
>
> Signed-off-by: Larry Brakmo <brakmo@google.com>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Also applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH] pkt_sched: fq: clear time_next_packet for reused flows
From: David Miller @ 2013-10-27 20:52 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1382612508.7572.53.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 24 Oct 2013 04:01:48 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> When a socket is freed/reallocated, we need to clear time_next_packet
> or else we can inherit a prior value and delay first packets of the
> new flow.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Eric this has been mangled by your email client, please fix.
^ permalink raw reply
* Re: [PATCH] Documentation/networking: netdev-FAQ typo corrections
From: David Miller @ 2013-10-27 20:56 UTC (permalink / raw)
To: paul.gortmaker; +Cc: rdunlap, netdev
In-Reply-To: <526ABED4.8020605@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri, 25 Oct 2013 14:56:20 -0400
> On 13-10-24 09:56 PM, Randy Dunlap wrote:
>> From: Randy Dunlap <rdunlap@infradead.org>
>>
>> Various typo fixes to netdev-FAQ.txt:
>> - capitalize Linux
>> - hyphenate dual-word adjectives
>> - minor punctuation fixes
>>
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>> Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> I've no objections to those kinds of changes.
>
> Acked-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Applied, thanks everyone.
^ permalink raw reply
* [PATCH net] cxgb3: Fix length calculation in write_ofld_wr() on 32-bit architectures
From: Ben Hutchings @ 2013-10-27 21:02 UTC (permalink / raw)
To: David Miller, Divy Le Ray; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]
The length calculation here is now invalid on 32-bit architectures,
since sk_buff::tail is a pointer and sk_buff::transport_header is
an integer offset:
drivers/net/ethernet/chelsio/cxgb3/sge.c: In function 'write_ofld_wr':
drivers/net/ethernet/chelsio/cxgb3/sge.c:1603:9: warning: passing argument 4 of 'make_sgl' makes integer from pointer without a cast [enabled by default]
adap->pdev);
^
drivers/net/ethernet/chelsio/cxgb3/sge.c:964:28: note: expected 'unsigned int' but argument is of type 'sk_buff_data_t'
static inline unsigned int make_sgl(const struct sk_buff *skb,
^
Use the appropriate skb accessor functions.
Compile-tested only.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Fixes: 1a37e412a022 ('net: Use 16bits for *_headers fields of struct skbuff')
---
This is needed for 3.11-stable.
Ben.
drivers/net/ethernet/chelsio/cxgb3/sge.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c b/drivers/net/ethernet/chelsio/cxgb3/sge.c
index 9c89dc8..632b318 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
@@ -1599,7 +1599,8 @@ static void write_ofld_wr(struct adapter *adap, struct sk_buff *skb,
flits = skb_transport_offset(skb) / 8;
sgp = ndesc == 1 ? (struct sg_ent *)&d->flit[flits] : sgl;
sgl_flits = make_sgl(skb, sgp, skb_transport_header(skb),
- skb->tail - skb->transport_header,
+ skb_tail_pointer(skb) -
+ skb_transport_header(skb),
adap->pdev);
if (need_skb_unmap()) {
setup_deferred_unmapping(skb, adap->pdev, sgp, sgl_flits);
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply related
* Re: [PATCH v2 next] be2net: add support for ndo_busy_poll
From: David Miller @ 2013-10-27 21:05 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <1382677816-7762-1-git-send-email-sathya.perla@emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Fri, 25 Oct 2013 10:40:16 +0530
> Includes:
> - ndo_busy_poll implementation
> - Locking between napi and busy_poll
> - Fix rx_post_starvation (replenish rx-queues in out-of-mememory scenario)
> logic to accomodate busy_poll.
>
> v2 changes:
> [Eric D.'s comment] call alloc_pages() with GFP_ATOMIC even in ndo_busy_poll
> context as it is not allowed to sleep.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] bonding: patchset for rcu use in bonding
From: Veaceslav Falico @ 2013-10-27 21:10 UTC (permalink / raw)
To: David Miller; +Cc: dingtianhong, fubar, andy, nikolay, netdev
In-Reply-To: <20131027.163712.1324471504006808112.davem@davemloft.net>
On Sun, Oct 27, 2013 at 04:37:12PM -0400, David Miller wrote:
>From: Ding Tianhong <dingtianhong@huawei.com>
>Date: Thu, 24 Oct 2013 11:08:35 +0800
>
>> The slave list will add and del by bond_master_upper_dev_link() and bond_upper_dev_unlink(),
>> which will call call_netdevice_notifiers(), even it is safe to call it in write bond lock now,
>> but we can't sure that whether it is safe later, because other drivers may deal NETDEV_CHANGEUPPER
>> in sleep way, so I didn't admit move the bond_upper_dev_unlink() in write bond lock.
>>
>> now the bond_for_each_slave only protect by rtnl_lock(), maybe use bond_for_each_slave_rcu is a good
>> way to protect slave list for bond, but as a system slow path, it is no need to transform bond_for_each_slave()
>> to bond_for_each_slave_rcu() in slow path, so in the patchset, I will remove the unused read bond lock
>> for monitor function, maybe it is a better way, I will wait to accept any relay for it.
>>
>> Thanks for the Veaceslav Falico opinion.
>>
>> v2: add and modify commit for patchset and patch, it will be the first step for the whole patchset.
>
>Series applied, thanks.
David,
Either I've missed something, or I don't understand something. I've
explicitly Nacked it - http://www.spinics.net/lists/netdev/msg254998.html .
All the changelogs for the patches are *the same*, and, while they try to
explain what's done overall, the don't explain what's done per-patch, why
it's done and why is it safe to move those locks around.
And, while the code changes are small, they touch really sensitive stuff -
locking, and not only bond->lock, but also rtnl. Without proper changelogs
it's really hard to review them per-patch, that's why I've asked for them
several times.
Anyway, care to explain what did I miss?
Thank you!
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] bonding: patchset for rcu use in bonding
From: David Miller @ 2013-10-27 21:44 UTC (permalink / raw)
To: vfalico; +Cc: dingtianhong, fubar, andy, nikolay, netdev
In-Reply-To: <20131027211048.GA557@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Sun, 27 Oct 2013 22:10:48 +0100
> All the changelogs for the patches are *the same*, and, while they try
> to
> explain what's done overall, the don't explain what's done per-patch,
> why
> it's done and why is it safe to move those locks around.
He did say so, he listed in fact three alternative ways to fix the
locking problem and then explciitly stated which of the three he
choose.
I would have preferred that he did all of this in the initial 0/N
patch posting, but I can't defer forever.
^ permalink raw reply
* [PATCH 0/8] Fix minor address type errors
From: Ben Hutchings @ 2013-10-27 21:47 UTC (permalink / raw)
To: LKML
Cc: linux-scsi, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]
Various bits of code are mixing making assumptions about the size of
dma_addr_t or resource_size_t, or mixing up pointer and integer types.
All these fixes are based on compiler warnings and so far as I can see
the bugs are practically harmless.
Ben.
Ben Hutchings (8):
IB/cxgb4: Fix formatting of physical address
farsync: Fix confusion about DMA address and buffer offset types
drm: Do not include page offset in argument to virt_to_page()
drm: Pass pointers to virt_to_page()
[SCSI] tgt: Pass pointers to virt_to_page(), not integers
uio: Pass pointers to virt_to_page(), not integers
rds: Pass pointers to virt_to_page(), not integers
[SCSI] pmcraid: Pass pointers to access_ok(), not integers
drivers/gpu/drm/drm_pci.c | 4 ++--
drivers/gpu/drm/drm_vm.c | 2 +-
drivers/infiniband/hw/cxgb4/device.c | 4 ++--
drivers/net/wan/farsync.c | 19 +++++++------------
drivers/scsi/pmcraid.c | 3 ++-
drivers/scsi/scsi_tgt_if.c | 2 +-
drivers/uio/uio.c | 6 ++++--
net/rds/message.c | 2 +-
8 files changed, 20 insertions(+), 22 deletions(-)
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH 2/8] farsync: Fix confusion about DMA address and buffer offset types
From: Ben Hutchings @ 2013-10-27 21:51 UTC (permalink / raw)
To: Kevin Curtis; +Cc: LKML, netdev
In-Reply-To: <1382910437.2994.43.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2809 bytes --]
Use dma_addr_t for DMA address parameters and u32 for shared memory
offset parameters.
Do not assume that dma_addr_t is the same as unsigned long; it will
not be in PAE configurations. Truncate DMA addresses to 32 bits when
printing them. This is OK because the DMA mask for this device is
32-bit (per default).
Compile-tested only.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/net/wan/farsync.c | 19 +++++++------------
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wan/farsync.c b/drivers/net/wan/farsync.c
index 3f0c4f2..4b36676 100644
--- a/drivers/net/wan/farsync.c
+++ b/drivers/net/wan/farsync.c
@@ -886,15 +886,13 @@ fst_rx_dma_complete(struct fst_card_info *card, struct fst_port_info *port,
* Receive a frame through the DMA
*/
static inline void
-fst_rx_dma(struct fst_card_info *card, dma_addr_t skb,
- dma_addr_t mem, int len)
+fst_rx_dma(struct fst_card_info *card, dma_addr_t skb, u32 mem, int len)
{
/*
* This routine will setup the DMA and start it
*/
- dbg(DBG_RX, "In fst_rx_dma %lx %lx %d\n",
- (unsigned long) skb, (unsigned long) mem, len);
+ dbg(DBG_RX, "In fst_rx_dma %x %x %d\n", (u32)skb, mem, len);
if (card->dmarx_in_progress) {
dbg(DBG_ASS, "In fst_rx_dma while dma in progress\n");
}
@@ -915,20 +913,19 @@ fst_rx_dma(struct fst_card_info *card, dma_addr_t skb,
* Send a frame through the DMA
*/
static inline void
-fst_tx_dma(struct fst_card_info *card, unsigned char *skb,
- unsigned char *mem, int len)
+fst_tx_dma(struct fst_card_info *card, dma_addr_t skb, u32 mem, int len)
{
/*
* This routine will setup the DMA and start it.
*/
- dbg(DBG_TX, "In fst_tx_dma %p %p %d\n", skb, mem, len);
+ dbg(DBG_TX, "In fst_tx_dma %x %x %d\n", (u32)skb, mem, len);
if (card->dmatx_in_progress) {
dbg(DBG_ASS, "In fst_tx_dma while dma in progress\n");
}
- outl((unsigned long) skb, card->pci_conf + DMAPADR1); /* Copy from here */
- outl((unsigned long) mem, card->pci_conf + DMALADR1); /* to here */
+ outl(skb, card->pci_conf + DMAPADR1); /* Copy from here */
+ outl(mem, card->pci_conf + DMALADR1); /* to here */
outl(len, card->pci_conf + DMASIZ1); /* for this length */
outl(0x000000004, card->pci_conf + DMADPR1); /* In this direction */
@@ -1405,9 +1402,7 @@ do_bottom_half_tx(struct fst_card_info *card)
card->dma_len_tx = skb->len;
card->dma_txpos = port->txpos;
fst_tx_dma(card,
- (char *) card->
- tx_dma_handle_card,
- (char *)
+ card->tx_dma_handle_card,
BUF_OFFSET(txBuffer[pi]
[port->txpos][0]),
skb->len);
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply related
* [PATCH 7/8] rds: Pass pointers to virt_to_page(), not integers
From: Ben Hutchings @ 2013-10-27 21:54 UTC (permalink / raw)
To: Venkat Venkatsubra; +Cc: LKML, rds-devel, netdev
In-Reply-To: <1382910437.2994.43.camel@deadeye.wl.decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 923 bytes --]
Most architectures define virt_to_page() as a macro that casts its
argument such that an argument of type unsigned long will be accepted
without complaint. However, the proper type is void *, and passing
unsigned long results in a warning on MIPS.
Compile-tested only.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
net/rds/message.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/rds/message.c b/net/rds/message.c
index aba232f..1913fc9 100644
--- a/net/rds/message.c
+++ b/net/rds/message.c
@@ -257,7 +257,7 @@ struct rds_message *rds_message_map_pages(unsigned long *page_addrs, unsigned in
for (i = 0; i < rm->data.op_nents; ++i) {
sg_set_page(&rm->data.op_sg[i],
- virt_to_page(page_addrs[i]),
+ virt_to_page((void *)page_addrs[i]),
PAGE_SIZE, 0);
}
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply related
* Re: [PATCH] pkt_sched: fq: clear time_next_packet for reused flows
From: Vijay Subramanian @ 2013-10-27 22:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1382612508.7572.53.camel@edumazet-glaptop.roam.corp.google.com>
On 24 October 2013 04:01, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> When a socket is freed/reallocated, we need to clear time_next_packet
> or else we can inherit a prior value and delay first packets of the
> new flow.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Eric,
By the way, it looks like fq_flow_set_throttled() uses
f->time_next_packet in an incorrect way.
It is used as key to insert the flow into the delayed rb-tree but does
not seem to check for duplicates.
This could lead to rb tree corruption. I assume it is possible for
different flows to have same f->time_next_packet.
Do we at least we need a BUG_ON(f->time_next_packet ==
aux->time_next_packet) here?
Code in fq_flow_set_throttled():
while (*p) {
struct fq_flow *aux;
parent = *p;
aux = container_of(parent, struct fq_flow, rate_node);
if (f->time_next_packet >= aux->time_next_packet)
p = &parent->rb_right;
else
p = &parent->rb_left;
}
rb_link_node(&f->rate_node, parent, p);
rb_insert_color(&f->rate_node, &q->delayed);
Thanks!
-vijay
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] bonding: patchset for rcu use in bonding
From: Veaceslav Falico @ 2013-10-27 22:10 UTC (permalink / raw)
To: David Miller; +Cc: dingtianhong, fubar, andy, nikolay, netdev
In-Reply-To: <20131027.174458.627996500790326920.davem@davemloft.net>
On Sun, Oct 27, 2013 at 05:44:58PM -0400, David Miller wrote:
>From: Veaceslav Falico <vfalico@redhat.com>
>Date: Sun, 27 Oct 2013 22:10:48 +0100
>
>> All the changelogs for the patches are *the same*, and, while they try
>> to
>> explain what's done overall, the don't explain what's done per-patch,
>> why
>> it's done and why is it safe to move those locks around.
>
>He did say so, he listed in fact three alternative ways to fix the
>locking problem and then explciitly stated which of the three he
>choose.
He just rephrased me - http://www.spinics.net/lists/netdev/msg254618.html .
And still the patches didn't say how he did it and why is it safe/good to
do it the way he did it. That's, basically, code without commit messages,
which touches really sensitive parts. As I've said in the above link, it's
really hard to review them this way.
>
>I would have preferred that he did all of this in the initial 0/N
>patch posting, but I can't defer forever.
Maybe I'm too picky. Anyway - understood, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] bonding: patchset for rcu use in bonding
From: Veaceslav Falico @ 2013-10-27 22:53 UTC (permalink / raw)
To: Ding Tianhong
Cc: Jay Vosburgh, Andy Gospodarek, David S. Miller,
Nikolay Aleksandrov, Netdev
In-Reply-To: <52688F33.30904@huawei.com>
On Thu, Oct 24, 2013 at 11:08:35AM +0800, Ding Tianhong wrote:
>Hi:
>
>The slave list will add and del by bond_master_upper_dev_link() and bond_upper_dev_unlink(),
>which will call call_netdevice_notifiers(), even it is safe to call it in write bond lock now,
>but we can't sure that whether it is safe later, because other drivers may deal NETDEV_CHANGEUPPER
>in sleep way, so I didn't admit move the bond_upper_dev_unlink() in write bond lock.
>
>now the bond_for_each_slave only protect by rtnl_lock(), maybe use bond_for_each_slave_rcu is a good
>way to protect slave list for bond, but as a system slow path, it is no need to transform bond_for_each_slave()
>to bond_for_each_slave_rcu() in slow path, so in the patchset, I will remove the unused read bond lock
>for monitor function, maybe it is a better way, I will wait to accept any relay for it.
>
>Thanks for the Veaceslav Falico opinion.
>
>v2: add and modify commit for patchset and patch, it will be the first step for the whole patchset.
>
>Ding Tianhong (5):
> bonding: remove bond read lock for bond_mii_monitor()
> bonding: remove bond read lock for bond_alb_monitor()
> bonding: remove bond read lock for bond_loadbalance_arp_mon()
> bonding: remove bond read lock for bond_activebackup_arp_mon()
This patch introduces a regression by boot-test with active backup mode:
bond_activebackup_arp_mon() is already not holding the bond->lock, however
it might call bond_change_active_slave(), which does (in case of new_active):
912 write_unlock_bh(&bond->curr_slave_lock);
913 read_unlock(&bond->lock);
914
915 call_netdevice_notifiers(NETDEV_BONDING_FAILOVER, bond->dev);
916 if (should_notify_peers)
917 call_netdevice_notifiers(NETDEV_NOTIFY_PEERS,
918 bond->dev);
919
920 read_lock(&bond->lock);
921 write_lock_bh(&bond->curr_slave_lock);
so it drops the bond->lock (which wasn't taken previously), and then takes
it (without anyone dropping it afterwards).
I don't know how to fix it - cause a lot of other callers already take it,
and we can't just drop them (we'd race), and we can't remove it here (cause
we can't call notifiers while atomic).
Which begs the question - was this patchset tested at all?
[ 21.796823] =====================================
[ 21.796823] [ BUG: bad unlock balance detected! ]
[ 21.796823] 3.12.0-rc6+ #305 Tainted: G I
[ 21.796823] -------------------------------------
[ 21.796823] kworker/u8:5/59 is trying to release lock (&bond->lock) at:
[ 21.796823] [<ffffffffa00b6c38>] bond_change_active_slave+0x2c8/0x390 [bonding]
[ 21.796823] but there are no more locks to release!
[ 21.796823]
[ 21.796823] other info that might help us debug this:
[ 21.796823] 3 locks held by kworker/u8:5/59:
[ 21.796823] #0: (%s#4){.+.+..}, at: [<ffffffff810cfeb9>] process_one_work+0x189/0x580
[ 21.796823] #1: ((&(&bond->arp_work)->work)){+.+...}, at: [<ffffffff810cfeb9>] process_one_work+0x189/0x580
[ 21.796823] #2: (rtnl_mutex){+.+.+.}, at: [<ffffffff8169ea05>] rtnl_trylock+0x15/0x20
[ 21.796823]
[ 21.796823] stack backtrace:
[ 21.796823] CPU: 0 PID: 59 Comm: kworker/u8:5 Tainted: G I 3.12.0-rc6+ #305
[ 21.796823] Hardware name: Hewlett-Packard HP xw4600 Workstation/0AA0h, BIOS 786F3 v01.15 08/28/2008
[ 21.796823] Workqueue: bond0 bond_activebackup_arp_mon [bonding]
[ 21.796823] ffffffffa00b6c38 ffff880079ecdae8 ffffffff817aa048 0000000000000002
[ 21.796823] ffff880079ec4b40 ffff880079ecdb18 ffffffff81129af9 00000000001d5400
[ 21.796823] ffff880079ec4b40 ffff880078a36c88 ffff880079ec5440 ffff880079ecdba8
[ 21.796823] Call Trace:
[ 21.796823] [<ffffffffa00b6c38>] ? bond_change_active_slave+0x2c8/0x390 [bonding]
[ 21.796823] [<ffffffff817aa048>] dump_stack+0x59/0x81
[ 21.796823] [<ffffffff81129af9>] print_unlock_imbalance_bug+0xf9/0x100
[ 21.796823] [<ffffffff8112d67f>] lock_release_non_nested+0x26f/0x3f0
[ 21.796823] [<ffffffff810f3aa8>] ? sched_clock_cpu+0xb8/0x120
[ 21.796823] [<ffffffffa00b6c38>] ? bond_change_active_slave+0x2c8/0x390 [bonding]
[ 21.796823] [<ffffffffa00b6c38>] ? bond_change_active_slave+0x2c8/0x390 [bonding]
[ 21.796823] [<ffffffff8112d892>] __lock_release+0x92/0x1b0
[ 21.796823] [<ffffffffa00b6c38>] ? bond_change_active_slave+0x2c8/0x390 [bonding]
[ 21.796823] [<ffffffff8112da0b>] lock_release+0x5b/0x130
[ 21.796823] [<ffffffff817b0553>] _raw_read_unlock+0x23/0x50
[ 21.796823] [<ffffffffa00b6c38>] bond_change_active_slave+0x2c8/0x390 [bonding]
[ 21.796823] [<ffffffffa00b6df7>] bond_select_active_slave+0xf7/0x1d0 [bonding]
[ 21.796823] [<ffffffffa00b7006>] bond_ab_arp_commit+0x136/0x200 [bonding]
[ 21.796823] [<ffffffffa00b9dd8>] bond_activebackup_arp_mon+0xc8/0xd0 [bonding]
[ 21.796823] [<ffffffff810cff2a>] process_one_work+0x1fa/0x580
[ 21.796823] [<ffffffff810cfeb9>] ? process_one_work+0x189/0x580
[ 21.796823] [<ffffffff810d231f>] worker_thread+0x11f/0x3a0
[ 21.796823] [<ffffffff810d2200>] ? manage_workers+0x170/0x170
[ 21.796823] [<ffffffff810dbdfe>] kthread+0xee/0x100
[ 21.796823] [<ffffffff8112d93b>] ? __lock_release+0x13b/0x1b0
[ 21.796823] [<ffffffff810dbd10>] ? __init_kthread_worker+0x70/0x70
[ 21.796823] [<ffffffff817ba3ec>] ret_from_fork+0x7c/0xb0
[ 21.796823] [<ffffffff810dbd10>] ? __init_kthread_worker+0x70/0x70
> bonding: remove bond read lock for bond_3ad_state_machine_handler()
>
> drivers/net/bonding/bond_3ad.c | 9 ++--
> drivers/net/bonding/bond_alb.c | 20 ++------
> drivers/net/bonding/bond_main.c | 100 +++++++++++++---------------------------
> 3 files changed, 40 insertions(+), 89 deletions(-)
>
>--
>1.8.2.1
>
>
>
>--
>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
* [PATCH v2] pkt_sched: fq: clear time_next_packet for reused flows
From: Eric Dumazet @ 2013-10-27 23:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1382612508.7572.53.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
When a socket is freed/reallocated, we need to clear time_next_packet
or else we can inherit a prior value and delay first packets of the
new flow.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
v2: wrapping issue
net/sched/sch_fq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/sched/sch_fq.c b/net/sched/sch_fq.c
index a9dfdda..fdc041c 100644
--- a/net/sched/sch_fq.c
+++ b/net/sched/sch_fq.c
@@ -255,6 +255,7 @@ static struct fq_flow *fq_classify(struct sk_buff *skb, struct fq_sched_data *q)
f->socket_hash != sk->sk_hash)) {
f->credit = q->initial_quantum;
f->socket_hash = sk->sk_hash;
+ f->time_next_packet = 0ULL;
}
return f;
}
^ permalink raw reply related
* Re: extending ndo_add_rx_vxlan_port
From: Joseph Gasparakis @ 2013-10-27 23:44 UTC (permalink / raw)
To: Or Gerlitz
Cc: Joseph Gasparakis, Or Gerlitz, John Fastabend, Yan Burman, netdev,
Stephen Hemminger
In-Reply-To: <CAJZOPZ+S6ngqMjV-2ZMcpzkuWzzLWwCQMtd_1_SjDkqWh_tbYg@mail.gmail.com>
On Sun, 27 Oct 2013, Or Gerlitz wrote:
> On Sun, Oct 27, 2013 at 7:25 PM, Joseph Gasparakis
> <joseph.gasparakis@intel.com> wrote:
> >
> >
> > On Sun, 27 Oct 2013, Or Gerlitz wrote:
> >
> >> Hi,
> >>
> >> So with commit 53cf527513eed6e7170e9dceacd198f9267171b0 "vxlan: Notify drivers
> >> for listening UDP port changes" drivers that have HW offloads for vxlan can be
> >> notified on which UDP port to listen. Taking this further, some HW may need to
> >> know the multicast address and/or the VNID used by the vxlan instance/s set
> >> above them. In that respect, do we prefer to extend ndo_add_rx_vxlan_port() or
> >> introduce new ndo?
> >>
> >> Or.
> >>
> >
> > The way this patch works is to notify the drivers when a VXLAN UDP port
> > comes up or down. This way drivers do not need to do any sort of accounting. As
>
> Could you elaborate why do we want to notify all the netdev instances
> in the system (on a certain name-space)
> that vxlan instance/s are set to listen on certain UDP port and not
> only the device over which the
> vxlan device is being set? say the HW can listen limited amount of UDP
> ports and few vxlan instances are created
> one of top of each "real" netdev in the system and each on different
> port. Each netdevice will get all callbacks on port addition
> and at some point will start to fail adding them into the HW when the
> HW limit is met.
>
> Or.
>
VXLAN implementation is not done like VLAN. VLANs are stacked on top of
real interfaces and what you are saying makes sense. VXLAN however is
using ip[6]_tunnel_xmit, and this is why we need to notify all the
netdevs in the system that implement the add/del vxlan port ndo (i.e. are
capable of offloading inner csums). In effect all physical "real" netdevs
are candidates to receive/transmit VXLAN traffic, subject to routing
tables changing or not.
Joseph
^ permalink raw reply
* Re: linux-next: Tree for Oct 18 (netdev: nf_tables_bridge.c)
From: Pablo Neira Ayuso @ 2013-10-27 23:29 UTC (permalink / raw)
To: Randy Dunlap
Cc: Mark Brown, Thierry Reding, linux-next, linux-kernel,
Patrick McHardy, netdev@vger.kernel.org, netfilter-devel
In-Reply-To: <5262BFD5.4060204@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
On Sat, Oct 19, 2013 at 10:22:29AM -0700, Randy Dunlap wrote:
> On 10/19/13 05:50, Mark Brown wrote:
> > Hi all,
> >
> > I've uploaded today's linux-next tree to the master branch of the
> > repository below:
> >
> > git://gitorious.org/thierryreding/linux-next.git
> >
> > A next-20131018 tag is also provided for convenience.
> >
> > A few new conflicts today but otherwise uneventful. x86_64 allmodconfig
> > builds after each merge but no other build tests were done.
>
> on i386:
>
> when CONFIG_NF_TABLES[_MODULE] is not enabled,
> but CONFIG_NF_TABLES_BRIDGE is enabled:
Patch attached, thanks for reporting.
[-- Attachment #2: 0001-netfilter-bridge-fix-nf_tables-bridge-dependencies-w.patch --]
[-- Type: text/x-diff, Size: 1718 bytes --]
>From 2724ade097d59aaa3879ca485ae0fd61994cbc38 Mon Sep 17 00:00:00 2001
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 28 Oct 2013 00:18:33 +0100
Subject: [PATCH] netfilter: bridge: fix nf_tables bridge dependencies with
main core
when CONFIG_NF_TABLES[_MODULE] is not enabled,
but CONFIG_NF_TABLES_BRIDGE is enabled:
net/bridge/netfilter/nf_tables_bridge.c: In function 'nf_tables_bridge_init_net':
net/bridge/netfilter/nf_tables_bridge.c:24:5: error: 'struct net' has no member named 'nft'
net/bridge/netfilter/nf_tables_bridge.c:25:9: error: 'struct net' has no member named 'nft'
net/bridge/netfilter/nf_tables_bridge.c:28:2: error: 'struct net' has no member named 'nft'
net/bridge/netfilter/nf_tables_bridge.c:30:34: error: 'struct net' has no member named 'nft'
net/bridge/netfilter/nf_tables_bridge.c:35:11: error: 'struct net' has no member named 'nft'
net/bridge/netfilter/nf_tables_bridge.c: In function 'nf_tables_bridge_exit_net':
net/bridge/netfilter/nf_tables_bridge.c:41:27: error: 'struct net' has no member named 'nft'
net/bridge/netfilter/nf_tables_bridge.c:42:11: error: 'struct net' has no member named 'nft'
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/bridge/netfilter/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bridge/netfilter/Kconfig b/net/bridge/netfilter/Kconfig
index 68f8128..5ca74a0 100644
--- a/net/bridge/netfilter/Kconfig
+++ b/net/bridge/netfilter/Kconfig
@@ -3,6 +3,7 @@
#
#
config NF_TABLES_BRIDGE
+ depends on NF_TABLES
tristate "Ethernet Bridge nf_tables support"
menuconfig BRIDGE_NF_EBTABLES
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] pkt_sched: fq: clear time_next_packet for reused flows
From: Eric Dumazet @ 2013-10-27 23:35 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: David Miller, netdev
In-Reply-To: <CAGK4HS945jCtfOoa_ENhTwZQvnSRJpHdWVDyhF+wjE56bjT8Pw@mail.gmail.com>
On Sun, 2013-10-27 at 15:06 -0700, Vijay Subramanian wrote:
> Eric,
> By the way, it looks like fq_flow_set_throttled() uses
> f->time_next_packet in an incorrect way.
> It is used as key to insert the flow into the delayed rb-tree but does
> not seem to check for duplicates.
> This could lead to rb tree corruption. I assume it is possible for
> different flows to have same f->time_next_packet.
> Do we at least we need a BUG_ON(f->time_next_packet ==
> aux->time_next_packet) here?
>
What exact RB corruptions do you see ?
RB trees allow items with the same key.
HTB and netem use this property and I never saw any corruption,
but you could be right so please elaborate, thanks !
^ 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