ok mvs@
> On 8 Dec 2021, at 16:41, Alexander Bluhm wrote:
>
> On Wed, Dec 08, 2021 at 02:41:47AM +0300, Vitaliy Makkoveev wrote:
>> [IN] looks strange. If this field modified after creation it is
>> mutable. There are cases when such field could modified only once,
>> but it still is atomic.
>
>> [IN] looks strange. If this field modified after creation it is
>> mutable. There are cases when such field could modified only once,
>> but it still is atomic.
It is mistype. I mean "..could modified only once, but it still
is mutable"
> On 8 Dec 2021, at 08:56, Visa Hankala wrote:
>
> On W
On Wed, Dec 08, 2021 at 02:41:47AM +0300, Vitaliy Makkoveev wrote:
> [IN] looks strange. If this field modified after creation it is
> mutable. There are cases when such field could modified only once,
> but it still is atomic.
You are right. tdb_dst and tdb_src are initialized before the TDB
is
On Wed, Dec 08, 2021 at 02:41:47AM +0300, Vitaliy Makkoveev wrote:
> [IN] looks strange. If this field modified after creation it is
> mutable. There are cases when such field could modified only once,
> but it still is atomic.
>
> We have cases where we do assignment only once, like `unp_addr’
>
[IN] looks strange. If this field modified after creation it is
mutable. There are cases when such field could modified only once,
but it still is atomic.
We have cases where we do assignment only once, like `unp_addr’
when we bind(2)ing socket and we don’t modify if until socket’s
destruction. Si
Hi,
I have started documenting the locking strategy of struct tdb fields.
Note that gettdb_dir() is MP safe now.
In udpencap_ctlinput() we had an unprotected access to tdb_snext.
Grab the tdb_sadb_mtx mutex there. Make the braces consistently
for all these loops.
Move NET_ASSERT_LOCKED() into t
