On Fri, Feb 05 2021, Andrew Morton wrote:
> On Fri, 05 Feb 2021 11:36:30 +1100 NeilBrown wrote:
>
>> A recent change to seq_file broke some users which were using seq_file
>> in a non-"standard" way ... though the "standard" isn't documented, so
>&g
fs/seq_file.c: simplify seq_file iteration code and
interface")
Reported-by: Xin Long
Signed-off-by: NeilBrown
---
net/sctp/proc.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/net/sctp/proc.c b/net/sctp/proc.c
index f7da88ae20a5..982a87b3e11f 100
the other.
These three patches:
1/ document and explain the problem
2/ fix the problem user in x86
3/ fix the problem user in net/sctp
I suspect the patches should each go through the relevant subsystems,
but I'm including akpm as the original went through him.
Thanks,
NeilBrown
---
NeilBro
On Thu, May 07 2020, Sasha Levin wrote:
> From: NeilBrown
>
> [ Upstream commit 7c4310ff56422ea43418305d22bbc5fe19150ec4 ]
This one is buggy - it introduces a use-after-free. Best delay it for
now.
NeilBrown
>
> The rpciod workqueue is on the write-out path for freeing dirty
have a proper look next week, if only to
find out how I didn't get the warnings, as I was testing with sparse.
Thanks,
NeilBrown
> ---
> include/linux/rhashtable.h | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/rhashtable.h b/
On Wed, Apr 03 2019, David Laight wrote:
> From: NeilBrown
>> Sent: 02 April 2019 22:11
>>
>> On Tue, Apr 02 2019, David Laight wrote:
>>
>> > From: NeilBrown
>> >> Sent: 02 April 2019 00:08
>> >>
>> >> This patch changes
On Sun, Dec 16 2018, Florian Fainelli wrote:
> On December 16, 2018 3:19:22 PM PST, NeilBrown wrote:
>>On Sun, Dec 16 2018, David Miller wrote:
>>
>>> From: NeilBrown
>>> Date: Mon, 17 Dec 2018 09:08:54 +1100
>>>
>>>> In my
On Sun, Dec 16 2018, David Miller wrote:
> From: NeilBrown
> Date: Mon, 17 Dec 2018 09:08:54 +1100
>
>> In my 4.4 kernel, the build_skb() call in (the equivalent of)
>> mtk_poll_rx() takes about 1.2usec and the call to napi_gro_receive()
>> takes about 3usec.
>
On Tue, Dec 11 2018, NeilBrown wrote:
>
> I got your patch working on 4.20-rc5 and did a performance comparison.
> With the staging driver (using iperf3) I get
> 220 MBit/sec in
> 680 MBit/sec out
>
> with the patched mainline driver I get
> 190 MBit/sec in
>9
On Thu, Dec 13 2018, Herbert Xu wrote:
> On Wed, Dec 12, 2018 at 07:49:08PM +1100, NeilBrown wrote:
>> On Wed, Dec 12 2018, Herbert Xu wrote:
>>
>> > On Wed, Dec 12, 2018 at 05:41:29PM +1100, NeilBrown wrote:
>> >>
>> >> So you would substant
On Wed, Dec 12 2018, Herbert Xu wrote:
> On Wed, Dec 12, 2018 at 05:41:29PM +1100, NeilBrown wrote:
>>
>> So you would substantially slow down the rhashtable_walk_start() step.
>
> This whole thing is meant for uses such as /proc and netlink
> enumeration. Speed is defi
On Wed, Dec 12 2018, Herbert Xu wrote:
> On Wed, Dec 12, 2018 at 11:02:35AM +1100, NeilBrown wrote:
>>
>> So I think this is a real bug - it is quite unlikely to hit, but
>> possibly.
>> You need a chain with at least 2 objects, you need
>> rhashtable_walk_stop
On Tue, Dec 11 2018, Herbert Xu wrote:
> Hi Neil:
>
> On Mon, Dec 10, 2018 at 09:50:43AM +1100, NeilBrown wrote:
>> I think it was agreed that I would not pursue features that were only
>> of use to out-of-tree code, but I don't think that applies here. This
>&
, but thought I would mention it.
Strangely when I test with scp, I get about 10MB/sec in both directions
with both drivers. Maybe the CPU limits encryption speed.
I have a 4.4-based kernel where I get 940MBit/sec both ways - using a
precursor of the current staging driver.
Thanks,
NeilBrown
On Fri, Dec 07 2018, Herbert Xu wrote:
> On Wed, Dec 05, 2018 at 02:51:02PM +1100, NeilBrown wrote:
>>
>> If the sequence:
>>obj = rhashtable_walk_next(iter);
>>rhashtable_walk_stop(iter);
>>rhashtable_remove_fast(ht, &obj->head, p
t()
- when rhashtable_walk_next() is called while p is not NULL and not
safe, it walks the chain looking for the first object with an
address greater than p and returns that. If there is none, it moves
to the next hash chain.
Signed-off-by: NeilBrown
---
This is a resend of a patc
SLAB_TYPESAFE_BY_RCU or changing
the key of an object and re-inserting it in the same table.
These could only be done safely if new objects were inserted
at the *start* of a hash chain, and that is not currently the case.
Acked-by: Herbert Xu
Signed-off-by: NeilBrown
---
Thanks Herbert,
here is the patch
On Sat, Dec 01 2018, Herbert Xu wrote:
> On Fri, Nov 30, 2018 at 10:26:50AM +1100, NeilBrown wrote:
>>
>> diff --git a/lib/rhashtable.c b/lib/rhashtable.c
>> index 30526afa8343..852ffa5160f1 100644
>> --- a/lib/rhashtable.c
>> +++ b/lib/rhashtable.c
>>
SLAB_TYPESAFE_BY_RCU or changing
the key of an object and re-inserting it in the same table.
These could only be done safely if new objects were inserted
at the *start* of a hash chain, and that is not currently the case.
Signed-off-by: NeilBrown
---
This version has an added comment to explain the &quo
On Tue, Jul 24 2018, Paul E. McKenney wrote:
> On Tue, Jul 24, 2018 at 07:52:03AM +1000, NeilBrown wrote:
>> On Mon, Jul 23 2018, Paul E. McKenney wrote:
>>
>> > On Mon, Jul 23, 2018 at 09:13:43AM +1000, NeilBrown wrote:
>> >> On Sun, Jul 22 2018, Paul E.
On Mon, Jul 16 2018, Herbert Xu wrote:
> On Mon, Jul 16, 2018 at 09:57:11AM +1000, NeilBrown wrote:
>>
>> Some users of rhashtable might need to change the key
>> of an object and move it to a different location in the table.
>> Other users might wan
On Mon, May 07 2018, Herbert Xu wrote:
> On Sun, May 06, 2018 at 07:37:49AM +1000, NeilBrown wrote:
>>
>> I can see no evidence that this is required for anything, as it isn't
>> use and I'm fairly sure that in it's current form - it cannot be used.
>
&
On Mon, May 07 2018, Herbert Xu wrote:
> On Sun, May 06, 2018 at 07:50:54AM +1000, NeilBrown wrote:
>>
>> Do we? How could we fix it for both rhashtable and rhltable?
>
> Well I suggested earlier to insert the walker object into the
> hash table, which would be applicab
On Mon, May 07 2018, Herbert Xu wrote:
> On Mon, May 07, 2018 at 08:24:41AM +1000, NeilBrown wrote:
>>
>> This is true, but I don't see how it is relevant.
>> At some point, each thread will find that the table they have just
>> locked for their search key, has a
On Sun, May 06 2018, Herbert Xu wrote:
> On Sun, May 06, 2018 at 08:00:49AM +1000, NeilBrown wrote:
>>
>> The insert function must (and does) take the lock on the bucket before
>> testing if there is a "next" table.
>> If one inserter finds that it has locked
On Sat, May 05 2018, Tom Herbert wrote:
> On Sat, May 5, 2018 at 2:43 AM, Herbert Xu
> wrote:
>> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>>> rhashtable_walk_prev() returns the object returned by
>>> the previous rhashtable_walk_next(), providin
On Sun, May 06 2018, Herbert Xu wrote:
> On Sun, May 06, 2018 at 07:48:20AM +1000, NeilBrown wrote:
>>
>> The spinlock protects 2 or more buckets. The nested table contains at
>> least 512 buckets, maybe more.
>> It is quite possible for two insertions into 2 diffe
On Sat, May 05 2018, Herbert Xu wrote:
> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> rhashtable_try_insert() currently hold a lock on the bucket in
>> the first table, while also locking buckets in subsequent tables.
>> This is unnecessary and looks like
On Sat, May 05 2018, Herbert Xu wrote:
> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> If the sequence:
>>obj = rhashtable_walk_next(iter);
>>rhashtable_walk_stop(iter);
>>rhashtable_remove_fast(ht, &obj->head, params);
>>rh
On Sat, May 05 2018, Herbert Xu wrote:
> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> print_ht in rhashtable_test calls rht_dereference() with neither
>> RCU protection or the mutex. This triggers an RCU warning.
>> So take the mutex to silence the warning.
On Sat, May 05 2018, Herbert Xu wrote:
> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> If two threads run nested_table_alloc() at the same time
>> they could both allocate a new table.
>> Best case is that one of them will never be freed, leaking memory.
>&
On Sat, May 05 2018, Herbert Xu wrote:
> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> Rather than borrowing one of the bucket locks to
>> protect ->future_tbl updates, use cmpxchg().
>> This gives more freedom to change how bucket locking
>> is imp
On Sat, May 05 2018, Herbert Xu wrote:
> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> This "feature" is unused, undocumented, and untested and so
>> doesn't really belong. If a use for the nulls marker
>> is found, all this code would need to
,
NeilBrown
---
NeilBrown (8):
rhashtable: silence RCU warning in rhashtable_test.
rhashtable: remove nulls_base and related code.
rhashtable: use cmpxchg() to protect ->future_tbl.
rhashtable: fix race in nested_table_alloc()
rhashtable: remove rhashtable_walk_p
print_ht in rhashtable_test calls rht_dereference() with neither
RCU protection or the mutex. This triggers an RCU warning.
So take the mutex to silence the warning.
Signed-off-by: NeilBrown
---
lib/test_rhashtable.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/lib
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h | 35 +++
lib/rhashtable.c |8
lib/test_rhashtable.c |5 +
3 files changed, 4 insertions(+), 44 deletions(-)
diff --git a/include/linux/rhashtable.h b/include/linux/rha
Rather than borrowing one of the bucket locks to
protect ->future_tbl updates, use cmpxchg().
This gives more freedom to change how bucket locking
is implemented.
Signed-off-by: NeilBrown
---
lib/rhashtable.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --
htable_walk_next()
- when rhashtable_walk_next() is called while p is not NULL and not
safe, it walks the chain looking for the first object with an
address greater than p and returns that. If there is none, it moves
to the next hash chain.
Signed-off-by: NeilBrown
---
include/lin
the unused table.
Fixes: da20420f83ea ("rhashtable: Add nested tables")
Cc: sta...@vger.kernel.org # 4.11+
Signed-off-by: NeilBrown
---
lib/rhashtable.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index b7
sh the
current location in the table. If it returns NULL, then
rhashtable_walk_next() should be used.
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h |1 +
lib/rhashtable.c | 31 +++
2 files changed, 32 insertions(+)
diff --git a/include
et
table (as the minimum size is 4).
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h | 13 -
lib/rhashtable.c | 42 ++
2 files changed, 10 insertions(+), 45 deletions(-)
diff --git a/include/linux/rhashtable.h b/include/li
eping, so
remove it.
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h |1 -
lib/rhashtable.c | 34 --
2 files changed, 35 deletions(-)
diff --git a/include/linux/rhashtable.h b/include/linux/rhashtable.h
index 8822924dd05a..5091abf975a1 100644
grow_decision and shink_decision no longer exist, so remove
the remaining references to them.
Acked-by: Herbert Xu
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h | 33 ++---
1 file changed, 14 insertions(+), 19 deletions(-)
diff --git a/include/linux
2 patches fixes documentation
1 fixes a bit in rhashtable_walk_start()
1 improves rhashtable_walk stability.
All reviewed and Acked.
Thanks,
NeilBrown
---
NeilBrown (4):
rhashtable: remove outdated comments about grow_decision etc
rhashtable: Revise incorrect comment on r{hl,hash
nd the object even though it is
still in the hashtable if a rehash has moved it to a new table. In
this case it will (eventually) get -EAGAIN and will need to proceed
through the whole table again to be sure to see everything at least
once.
Acked-by: Herbert Xu
Signed-off-by: NeilBrown
The documentation claims that when rhashtable_walk_start_check()
detects a resize event, it will rewind back to the beginning
of the table. This is not true. We need to set ->slot and
->skip to be zero for it to be true.
Acked-by: Herbert Xu
Signed-off-by: NeilBrown
---
lib/rhasht
Neither rhashtable_walk_enter() or rhltable_walk_enter() sleep, though
they do take a spinlock without irq protection.
So revise the comments to accurately state the contexts in which
these functions can be called.
Acked-by: Herbert Xu
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h
On Wed, Apr 18 2018, David Miller wrote:
> From: NeilBrown
> Date: Thu, 19 Apr 2018 09:09:05 +1000
>
>> On Wed, Apr 18 2018, Herbert Xu wrote:
>>
>>> On Wed, Apr 18, 2018 at 04:47:01PM +1000, NeilBrown wrote:
>>>> grow_decision and shink_decision no
On Thu, Apr 19 2018, Herbert Xu wrote:
> On Thu, Apr 19, 2018 at 08:56:28AM +1000, NeilBrown wrote:
>>
>> I don't want to do that - I just want the documentation to be correct
>> (or at least, not be blatantly incorrect). The function does not sleep,
>> and is s
On Wed, Apr 18 2018, Herbert Xu wrote:
> On Wed, Apr 18, 2018 at 04:47:01PM +1000, NeilBrown wrote:
>> grow_decision and shink_decision no longer exist, so remove
>> the remaining references to them.
>>
>> Signed-off-by: NeilBrown
>
> Acked-by: Herbert Xu
Th
On Wed, Apr 18 2018, Herbert Xu wrote:
> On Wed, Apr 18, 2018 at 04:47:02PM +1000, NeilBrown wrote:
>> rhashtable_walk_prev() returns the object returned by
>> the previous rhashtable_walk_next(), providing it is still in the
>> table (or was during this grace period).
On Wed, Apr 18 2018, Herbert Xu wrote:
> On Wed, Apr 18, 2018 at 04:47:01PM +1000, NeilBrown wrote:
>> Neither rhashtable_walk_enter() or rhltable_walk_enter() sleep, so
>> remove the comments which suggest that they do.
>>
>> Signed-off-by: NeilBrown
>> -
y suggested it might be good for some of these patches to
go upstream through 'staging' with the lustre patches. I no longer
think that is necessary. It is probably best for them to go upstream
through net or net-next.
Thanks,
NeilBrown
---
NeilBrown (6):
rhashtable:
grow_decision and shink_decision no longer exist, so remove
the remaining references to them.
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h | 33 ++---
1 file changed, 14 insertions(+), 19 deletions(-)
diff --git a/include/linux/rhashtable.h b/include
Neither rhashtable_walk_enter() or rhltable_walk_enter() sleep, so
remove the comments which suggest that they do.
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h |3 ---
lib/rhashtable.c |3 ---
2 files changed, 6 deletions(-)
diff --git a/include/linux/rhashtable.h
nd the object even though it is
still in the hashtable if a rehash has moved it to a new table. In
this case it will (eventually) get -EAGAIN and will need to proceed
through the whole table again to be sure to see everything at least
once.
Acked-by: Herbert Xu
Signed-off-by: NeilBrown
The documentation claims that when rhashtable_walk_start_check()
detects a resize event, it will rewind back to the beginning
of the table. This is not true. We need to set ->slot and
->skip to be zero for it to be true.
Acked-by: Herbert Xu
Signed-off-by: NeilBrown
---
lib/rhasht
htable_walk_next()
- when rhashtable_walk_next() is called while p is not NULL and not
safe, it walks the chain looking for the first object with an
address greater than p and returns that. If there is none, it moves
to the next hash chain.
Signed-off-by: NeilBrown
---
include/linux
sh the
current location in the table. If it returns NULL, then
rhashtable_walk_next() should be used.
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h |1 +
lib/rhashtable.c | 30 ++
2 files changed, 31 insertions(+)
diff --git a/include
sh the
current location in the table. If it returns NULL, then
rhashtable_walk_next() should be used.
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h |1 +
lib/rhashtable.c | 30 ++
2 files changed, 31 insertions(+)
diff --git a/include
htable_walk_next()
- when rhashtable_walk_next() is called while p is not NULL and not
safe, it walks the chain looking for the first object with an
address greater than p and returns that. If there is none, it moves
to the next hash chain.
Signed-off-by: NeilBrown
---
include/linux
es. I no longer
think that is necessary. It is probably best for them to go upstream
through net or net-next.
Thanks,
NeilBrown
---
NeilBrown (6):
rhashtable: remove outdated comments about grow_decision etc
rhashtable: remove incorrect comment on r{hl,hash}table_walk_enter()
The documentation claims that when rhashtable_walk_start_check()
detects a resize event, it will rewind back to the beginning
of the table. This is not true. We need to set ->slot and
->skip to be zero for it to be true.
Acked-by: Herbert Xu
Signed-off-by: NeilBrown
---
lib/rhasht
nd the object even though it is
still in the hashtable if a rehash has moved it to a new table. In
this case it will (eventually) get -EAGAIN and will need to proceed
through the whole table again to be sure to see everything at least
once.
Acked-by: Herbert Xu
Signed-off-by: NeilBrown
grow_decision and shink_decision no longer exist, so remove
the remaining references to them.
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h | 33 ++---
1 file changed, 14 insertions(+), 19 deletions(-)
diff --git a/include/linux/rhashtable.h b/include
Neither rhashtable_walk_enter() or rhltable_walk_enter() sleep, so
remove the comments which suggest that they do.
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h |3 ---
lib/rhashtable.c |3 ---
2 files changed, 6 deletions(-)
diff --git a/include/linux/rhashtable.h
On Thu, Mar 29 2018, Herbert Xu wrote:
> On Thu, Mar 29, 2018 at 08:26:21AM +1100, NeilBrown wrote:
>>
>> I say "astronomically unlikely", you say "probability .. is extremely
>> low". I think we are in agreement here.
>>
>> The point rema
action to ensure that the
previously returned object remains in the table until the next ->start,
then you can reliably walk the table with no duplicates or omissions
(unless a concurrent rehash causes duplicates)
If you don't keep the object in the table and it gets removed, then
the 'skip' counter is used to find your place, and you might get
duplicates or omissions.
NeilBrown
signature.asc
Description: PGP signature
_prev(struct rhashtable_iter *iter)
{
return iter->p;
}
Thoughts?
Thanks,
NeilBrown
signature.asc
Description: PGP signature
On Fri, Mar 30 2018, David Miller wrote:
> From: NeilBrown
> Date: Thu, 29 Mar 2018 12:19:09 +1100
>
>> These two patches apply on top of my previous "rhashtable: reset iter
>> when rhashtable_walk_start sees new table" patch.
>>
>> The first
."
This version doesn't require an API change and should be reliable for
rhltables too (my first version didn't handle these correctly).
Thanks,
NeilBrown
---
NeilBrown (2):
rhashtable: fix insertion of in rhltable when duplicate found.
rhashtable: improve rhashtable_walk
ant change.
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h |4 +++-
lib/rhashtable.c |4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/linux/rhashtable.h b/include/linux/rhashtable.h
index c9df2527e0cd..668a21f04b09 100644
--- a/include/linux/rh
nd the object even though it is
still in the hashtable if a rehash has moved it to a new table. In
this case it will (eventually) get -EAGAIN and will need to proceed
through the whole table again to be sure to see everything at least
once.
Signed-off-by: NeilBrown
On Thu, Mar 29 2018, NeilBrown wrote:
>
> How about storing the hash chains in order by object address?
> Then rhashtable_walk_start() can easily find it's place regardless of
> whether the old object was still present or not, using <= on the
> address.
> "Insert&
lock_iter_next() (And hence gfs2_glock_seq_start()) will sometimes
exit with gl_held true, and sometimes with it false.
gfs2_glock_seq_stop() assumes that it is false.
Normally gfs2_glock_seq_next() will normally be called between these
two and will clear gl_held, but I don't think t
On Wed, Mar 28 2018, Herbert Xu wrote:
> On Wed, Mar 28, 2018 at 06:17:57PM +1100, NeilBrown wrote:
>>
>> Sounds like over-kill to me.
>> It might be reasonable to have a CONFIG_DEBUG_RHASHTABLE which enables
>> extra to code to catch misuse, but I don't see
On Wed, Mar 28 2018, Herbert Xu wrote:
> On Wed, Mar 28, 2018 at 06:04:40PM +1100, NeilBrown wrote:
>>
>> I disagree. My patch 6 only makes it common instead of exceedingly
>> rare. If any table in the list other than the first has a chain with 16
>> elements, then
On Wed, Mar 28 2018, Herbert Xu wrote:
> On Wed, Mar 28, 2018 at 08:54:41AM +1100, NeilBrown wrote:
>>
>> Possibly.
>> I particularly want the interface to require that you pass the
>> previously returned object to _continue. That makes it easy to see that
>> th
On Wed, Mar 28 2018, Herbert Xu wrote:
> On Wed, Mar 28, 2018 at 08:34:19AM +1100, NeilBrown wrote:
>>
>> It is easy to get an -EBUSY insertion failure when .disable_count is
>> enabled, and I did get that. Blindly propagating that up caused lustre
>> to get
On Wed, Mar 28 2018, Andreas Grünbacher wrote:
> Neil,
>
> 2018-03-27 1:33 GMT+02:00 NeilBrown :
>> The documentation for rhashtable_walk_peek() wrong. It claims to
>> return the *next* entry, whereas it in fact returns the *previous*
>> entry.
>> However if
On Tue, Mar 27 2018, Herbert Xu wrote:
> On Tue, Mar 27, 2018 at 10:33:04AM +1100, NeilBrown wrote:
>>
>> -int rhashtable_walk_start_check(struct rhashtable_iter *iter)
>> +int rhashtable_walk_start_continue(struct rhashtable_iter *iter, struct
>> rhash_head *
On Tue, Mar 27 2018, David Miller wrote:
> From: NeilBrown
> Date: Tue, 27 Mar 2018 10:33:04 +1100
>
>> In many cases where the walker needs to drop out of RCU protection,
>> it will take a reference to the object and this can prevent it from
>> being removed from the
In this version I:
- fixed brace-after-else coding style, thanks Sergei Shtylyov,
- explained where the one user is, thanks David Miller
- added CC for author of rhashtable_walk_peek (Tom Herbert) and
of the one usage (Andreas Gruenbacher) - thanks Herbert Xu
NeilBrown
-8
On Tue, Mar 27 2018, Herbert Xu wrote:
> On Tue, Mar 27, 2018 at 10:33:04AM +1100, NeilBrown wrote:
>> The current rhashtable will fail an insertion if the hashtable
>> it "too full", one of:
>> - table already has 2^31 elements (-E2BIG)
>> - a max_size was
go in through the netdev tree if you
prefer - the last 4 are needed for lustre to work
correctly/optimally.
Thanks,
NeilBrown
---
NeilBrown (6):
rhashtable: improve documentation for rhashtable_walk_peek()
rhashtable: remove outdated comments about grow_decision etc
rhashtable:
the documentation can be correct without
listing too many special cases. I don't think the one user will
be affected by the code change.
Signed-off-by: NeilBrown
---
lib/rhashtable.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/lib/rhashtable.c
able will return every object that was in the
hastable for the duration of the walk, at least once. This can be
used, for example, to selectively delete objects from the table.
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h | 28 ++--
lib/rhashtable.c
The documentation claims that when rhashtable_walk_start_check()
detects a resize event, it will rewind back to the beginning
of the table. This is not true. We need to set ->slot and
->skip to be zero for it to be true.
Signed-off-by: NeilBrown
---
lib/rhashtable.c |2 ++
1 file c
ing the
new ->long_chain without locking cannot cause any corruption.
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h | 18 +++---
lib/rhashtable.c | 27 +++
2 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/include/lin
grow_decision and shink_decision no longer exist, so remove
the remaining references to them.
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h | 33 ++---
1 file changed, 14 insertions(+), 19 deletions(-)
diff --git a/include/linux/rhashtable.h b/include
ver to decrease it.
If a client wants minimal contention while still maintaining
a shorter chain length, it can run a periodic task which
counts the number of elements and updates ->nelems directly.
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h | 26 ++
lib/r
poll() flakes when receiving RST")
Cc: sta...@vger.kernel.org (v4.12)
Signed-off-by: NeilBrown
---
net/sunrpc/xprtsock.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index d5b54c020dec..4f154d388748 100644
--- a/net/sunrpc/xprtsock.c
+++
They don't really save that much, and aren't worth the hassle.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./include/linux/sunrpc/svc.h |2 --
./net/sunrpc/svcsock.c | 13 +++--
2 files changed, 3 insertions(+), 12 deletions(-)
diff .prev/include/linux
When recv_msg is called with a size of 0 and MSG_PEEK (and
sunrpc/svcsock.c does), it is clear that we only interested in
metadata (from/to addresses) and not the data, so don't do any
checksum checking at this point. Leave that until the data is
requested.
Signed-off-by: Neil Brown <[EMAIL PROT
The sunrpc server code needs to know the source and destination address
for UDP packets so it can reply properly.
It currently copies code out of the network stack to pick the pieces out
of the skb.
This is ugly and causes compile problems with the IPv6 stuff.
So, rip that out and use recv_msg i
small
optimisation.
Finally the last patch removes all the
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
from sunrpc as it really isn't needed and just hides this sort of problem.
Patches 1 and 3 are suitable for 2.6.21. Patch 2 needs confirmation.
Thanks,
NeilBrown
[PATC
96 matches
Mail list logo
