[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180925.104416.341573509848387687.davem@davemloft.net>
Date: Tue, 25 Sep 2018 10:44:16 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: vakul.garg@....com
Cc: netdev@...r.kernel.org, borisp@...lanox.com, aviadye@...lanox.com,
davejwatson@...com, doronrk@...com
Subject: Re: [PATCH net-next] tls: Fix socket mem accounting error under
async encryption
From: Vakul Garg <vakul.garg@....com>
Date: Tue, 25 Sep 2018 16:26:17 +0530
> Current async encryption implementation sometimes showed up socket
> memory accounting error during socket close. This results in kernel
> warning calltrace. The root cause of the problem is that socket var
> sk_forward_alloc gets corrupted due to access in sk_mem_charge()
> and sk_mem_uncharge() being invoked from multiple concurrent contexts
> in multicore processor. The apis sk_mem_charge() and sk_mem_uncharge()
> are called from functions alloc_plaintext_sg(), free_sg() etc. It is
> required that memory accounting apis are called under a socket lock.
>
> The plaintext sg data sent for encryption is freed using free_sg() in
> tls_encryption_done(). It is wrong to call free_sg() from this function.
> This is because this function may run in irq context. We cannot acquire
> socket lock in this function.
>
> We remove calling of function free_sg() for plaintext data from
> tls_encryption_done() and defer freeing up of plaintext data to the time
> when the record is picked up from tx_list and transmitted/freed. When
> tls_tx_records() gets called, socket is already locked and thus there is
> no concurrent access problem.
>
> Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption")
> Signed-off-by: Vakul Garg <vakul.garg@....com>
Applied.
Powered by blists - more mailing lists