[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200318090253.GA32397@duo.ucw.cz>
Date: Wed, 18 Mar 2020 10:02:53 +0100
From: Pavel Machek <pavel@...x.de>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Dmitry Yakunin <zeil@...dex-team.ru>,
Konstantin Khlebnikov <khlebnikov@...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
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.
> +
> 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?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)
Powered by blists - more mailing lists