lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72n8ZV_bs_xp5rNtar4vmfknJtZg4OHJW6vHuhVFmGs8mg@mail.gmail.com>
Date:   Tue, 11 Apr 2023 16:13:36 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Willy Tarreau <w@....eu>
Cc:     Hans Verkuil <hverkuil@...all.nl>,
        Daniel Almeida <daniel.almeida@...labora.com>,
        wedsonaf@...il.com, ojeda@...nel.org, mchehab@...nel.org,
        rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-media@...r.kernel.org, kernel@...labora.com
Subject: Re: [PATCH 0/6] Initial Rust V4L2 support

On Tue, Apr 11, 2023 at 2:49 PM Willy Tarreau <w@....eu> wrote:
>
> This might sound strange, but I suspect that having a TAINT_RUST flag
> could possibly help maintainers that are already lacking time, because
> it may quickly allow some of them to ask "please try again without the
> Rust code to see if the problem is still there", just like happens with
> out-of-tree code for which the knowledge is limited to null. This could
> allow to route issue reports to one maintainer when an issue is confirmed
> in both cases or to another one when it only happens in a single case.
>
> Of course it will not help with code reviews but we know that a great
> part of maintainers' time it spent trying to analyse problem reports
> that happen under vague conditions. All the time not spent debugging
> something not well understood is more time available for reviews.

You can already ask to disable `CONFIG_RUST`.

In fact, we asked that a few times, when people reported a problem
that looked unrelated to Rust, to confirm that was the case and thus
redirect the report.

So it is definitely a good idea to ask for that when you get a report
with `RUST=y` and you suspect it may be related to that, especially in
the beginning where `RUST=y` should not be common.

However, I think Rust in-tree code is different to out-of-tree code,
since you do have the code, and thus (in general) you should be able
to reproduce the build, and you can ask for help to the given
maintainers to understand it.

Cheers,
Miguel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ