[<prev] [next>] [day] [month] [year] [list]
Message-ID: <VI1PR04MB5567E279DEA30D7B147F9E2EECA80@VI1PR04MB5567.eurprd04.prod.outlook.com>
Date: Mon, 19 Aug 2019 11:29:50 +0000
From: Madalin-cristian Bucur <madalin.bucur@....com>
To: "fw@...len.de" <fw@...len.de>,
"steffen.klassert@...unet.com" <steffen.klassert@...unet.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: patch inclusion in lts trees
Hi Florian, Steffen,
the fix below, addressing a problem from kernel v4.9, did not get picked
up in the lts trees, is there a reason for this? Are there more such fixes
that were left out?
Thank you,
Madalin
commit 7a474c36586f4277f930ab7e6865c97e44dfc3bc
Author: Florian Westphal <fw@...len.de>
Date: Fri Jan 4 14:17:01 2019 +0100
xfrm: policy: increment xfrm_hash_generation on hash rebuild
Hash rebuild will re-set all the inexact entries, then re-insert them.
Lookups that can occur in parallel will therefore not find any policies.
This was safe when lookups were still guarded by rwlock.
After rcu-ification, lookups check the hash_generation seqcount to detect
when a hash resize takes place. Hash rebuild missed the needed increment.
Hash resizes and hash rebuilds cannot occur in parallel (both acquire
hash_resize_mutex), so just increment xfrm_hash_generation, like resize.
Fixes: a7c44247f704e3 ("xfrm: policy: make xfrm_policy_lookup_bytype lockless")
Signed-off-by: Florian Westphal <fw@...len.de>
Signed-off-by: Steffen Klassert <steffen.klassert@...unet.com>
Powered by blists - more mailing lists