[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2f3e0bdb-5c5f-541a-486e-b6385ad600bb@yandex-team.ru>
Date: Wed, 18 Mar 2020 13:01:58 +0300
From: Konstantin Khlebnikov <khlebnikov@...dex-team.ru>
To: Pavel Machek <pavel@...x.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Dmitry Yakunin <zeil@...dex-team.ru>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH 4.19 03/89] cgroup, netclassid: periodically release
file_lock on classid updating
On 18/03/2020 12.02, Pavel Machek wrote:
> Hi!
>
>> From: Dmitry Yakunin <zeil@...dex-team.ru>
>>
>> [ Upstream commit 018d26fcd12a75fb9b5fe233762aa3f2f0854b88 ]
> ...
>> Now update is non atomic and socket may be skipped using calls:
>>
>> dup2(oldfd, newfd);
>> close(oldfd);
>>
>> But this case is not typical. Moreover before this patch skip is possible
>> too by hiding socket fd in unix socket buffer.
>
> Dunno. This makes interface even more interesting.
This is part of brilliant cgroup-v1 design. =)
Cgroup-v2 doesn't recolor sockets when task is moved.
>
>> +
>> static int update_classid_sock(const void *v, struct file *file, unsigned n)
>> {
>> int err;
>> + struct update_classid_context *ctx = (void *)v;
>> struct socket *sock = sock_from_file(file, &err);
>>
> ...
>> + if (--ctx->batch == 0) {
>> + ctx->batch = UPDATE_CLASSID_BATCH;
>> + return n + 1;
>> + }
>> return 0;
>> }
>
> We take "const void *" and then write to it. That's asking for
> trouble... right? Should the const annotation be removed, at least for
> sake of humans trying to understand the code?
Indeed, there is no much sense in opaque const void *.
This is how iterate_fd() is declared.
>
> Best regards,
> Pavel
>
Powered by blists - more mailing lists