On Fri, Aug 26, 2016 at 10:04 AM, Cong Wang wrote:
>
> It was correct until...
>
> commit 4cf0b354d92ee2c642532ee39e330f8f580fd985
> Author: Florian Westphal
> Date: Fri Aug 12 12:03:52 2016 +0200
>
> rhashtable: avoid large lock-array allocations
>
>
> which is:
>
> @@ -83,6 +83,9 @@ stati
On Fri, Aug 26, 2016 at 10:00 AM, Cong Wang wrote:
> On Fri, Aug 26, 2016 at 8:41 AM, Eric Dumazet wrote:
>>
>> There is a trivial bug in alloc_bucket_locks()
>> I will send a patch.
>
>
> Yeah, the 'else' branch looks so suspicious. ;)
It was correct until...
commit 4cf0b354d92ee2c642532ee39e3
On Fri, Aug 26, 2016 at 8:41 AM, Eric Dumazet wrote:
>
> There is a trivial bug in alloc_bucket_locks()
> I will send a patch.
Yeah, the 'else' branch looks so suspicious. ;)
ment"
>>
>> Sent: Thursday, August 25, 2016 6:20:03 PM
>> Subject: Re: possible memory leak in ipc
>>
>> On Thu, Aug 25, 2016 at 1:17 PM, CAI Qian wrote:
>> > I am unsure if it is really a memleak (could be a security issue due to
>> > eventual
- Original Message -
> From: "Linus Torvalds"
> To: "CAI Qian" , "Thomas Graf" , "Herbert
> Xu"
> Cc: "Eric Dumazet" , "Network Development"
>
> Sent: Thursday, August 25, 2016 6:20:03 PM
> Subjec
On Thu, Aug 25, 2016 at 1:17 PM, CAI Qian wrote:
> I am unsure if it is really a memleak (could be a security issue due to
> eventually OOM and DoS) or just a soft lockup with in kmemlock code with
> false alarm.
Hmm. The reported leaks look like
unreferenced object 0xc90004857000 (size 4608
