From: Dan Carpenter <dan.carpenter@oracle.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
Christoph Hellwig <hch@infradead.org>,
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
ksummit <ksummit-discuss@lists.linuxfoundation.org>,
ksummit@lists.linux.dev
Subject: Re: [TECH TOPIC] Rust
Date: Tue, 21 Jun 2022 18:11:22 +0300 [thread overview]
Message-ID: <20220621151122.GL16517@kadam> (raw)
In-Reply-To: <Yq8pXroV+23xr5w5@pendragon.ideasonboard.com>
On Sun, Jun 19, 2022 at 04:49:18PM +0300, Laurent Pinchart wrote:
> Writing rust code that compiles (without wrapping everything in unsafe)
> requires understanding of life time management of objects. This is also
> required to write safe C code, but as can be seen through the kernel
> it's more often that not completely ignored, especially in drivers (just
> look at how many drivers that expose a chardev to userspace are happy
> using devm_kzalloc() to allocate their private data structure that is
> accessible through userspace calls). It may be caused by a combination
> of both the compiler an the kernel allowing bad practices (the fact that
> devm_kzalloc() exists without a huge flashing red warning around it
> shows that we either don't understand the problem or don't care),
The answer is that we don't understand the problem. I've been vaguely
aware that there is a problem related to this but I've never been clear
enough to the point where I could actually tell if code is buggy.
It sounds like something which could probably be detected with static
analysis. Most of the static analysis devs hang out on kernel-janitors
so if you see a bug and you think it might happen more than once then
send an email to kernel-janitors@vger.kernel.org.
Sometimes if we look at a patch then maybe we can identify several
heuristics to spot the bug.
regards,
dan carpenter
next prev parent reply other threads:[~2022-06-21 15:12 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-18 20:33 Miguel Ojeda
2022-06-18 20:42 ` Laurent Pinchart
2022-06-18 20:42 ` [Ksummit-discuss] " Laurent Pinchart
2022-06-18 20:44 ` Laurent Pinchart
2022-06-18 20:44 ` [Ksummit-discuss] " Laurent Pinchart
2022-06-18 20:49 ` Miguel Ojeda
2022-06-19 6:13 ` Christoph Hellwig
2022-06-19 6:13 ` [Ksummit-discuss] " Christoph Hellwig
2022-06-19 10:04 ` Laurent Pinchart
2022-06-19 10:04 ` [Ksummit-discuss] " Laurent Pinchart
2022-06-19 12:56 ` James Bottomley
2022-06-19 12:56 ` [Ksummit-discuss] " James Bottomley
2022-06-19 13:19 ` Jens Axboe
2022-06-19 13:19 ` [Ksummit-discuss] " Jens Axboe
2022-06-19 13:53 ` Laurent Pinchart
2022-06-19 13:53 ` [Ksummit-discuss] " Laurent Pinchart
2022-06-19 14:27 ` James Bottomley
2022-06-19 14:27 ` [Ksummit-discuss] " James Bottomley
2022-06-19 14:45 ` [MAINTAINER SUMMIT] Are we becoming too fearful? [was Re: [TECH TOPIC] Rust] James Bottomley
2022-06-19 14:45 ` [Ksummit-discuss] " James Bottomley
2022-06-22 9:59 ` Linus Walleij
2022-06-22 10:57 ` Laurent Pinchart
2022-06-22 12:01 ` Linus Walleij
2022-06-22 12:09 ` Laurent Pinchart
2022-06-22 23:13 ` NeilBrown
2022-06-23 11:37 ` James Bottomley
2022-06-25 12:03 ` [Ksummit-discuss] " Mauro Carvalho Chehab
2022-06-25 11:45 ` [Ksummit-discuss] [TECH TOPIC] Rust Mauro Carvalho Chehab
2022-06-25 14:15 ` James Bottomley
2022-06-25 16:18 ` Mauro Carvalho Chehab
2022-06-25 22:29 ` Linus Walleij
2022-06-26 2:52 ` Theodore Ts'o
2022-06-26 3:18 ` Al Viro
2022-06-19 13:49 ` Laurent Pinchart
2022-06-19 13:49 ` [Ksummit-discuss] " Laurent Pinchart
2022-06-19 19:08 ` Geert Uytterhoeven
2022-06-19 19:08 ` [Ksummit-discuss] " Geert Uytterhoeven
2022-06-19 20:57 ` Matthew Wilcox
2022-06-20 13:53 ` Linus Walleij
2022-06-20 14:08 ` James Bottomley
2022-06-21 15:11 ` Dan Carpenter [this message]
2022-06-23 10:58 ` [TECH TOPIC] Why is devm_kzalloc() harmful and what can we do about it Laurent Pinchart
2022-06-23 11:24 ` Dan Carpenter
2022-06-23 11:31 ` Laurent Pinchart
2022-06-21 9:49 ` [TECH TOPIC] Rust David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220621151122.GL16517@kadam \
--to=dan.carpenter@oracle.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=hch@infradead.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=ksummit@lists.linux.dev \
--cc=laurent.pinchart@ideasonboard.com \
--cc=miguel.ojeda.sandonis@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox