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>] [day] [month] [year] [list]
Message-ID: <8c535191-e24d-6465-e809-81ae9e9b23e0@lge.com>
Date:   Tue, 27 Feb 2018 17:26:00 +0900
From:   Byungchul Park <byungchul.park@....com>
To:     Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     kernel-team@....com, LKML <linux-kernel@...r.kernel.org>
Subject: [QUESTION] Bringing cross-release back to be alive

Hello,

Cross-release introduced a false positive in some fs configs,
which was too hard to solve fundamentally - which requires to
distinguish between all dynamic instances.

I also think it better be removed than making fs developers
disable whole lockdep. But I believe that it's still helpful
in the rest of the configs.

Therefore, I want to bring it back after preventing bothering
them. I think we can achieve it by invalidating problematic
waiters at the moment producing a false positive and letting
them worked out finely later.

For example, in the case where we got trouble in, we can
initialize the completion in submit_bio_wait() with no-map
version. That way, we can achieve our goal easily for all
problems caused by cross-release in the future.

Of course, it would be the best if we solve the problems in a
right way later, but just leaving them invalidated would be
also fine because the cases are exactly same as before
applying cross-release.

I'm curious about what you think about that. If you say yes,
then I will re-summit after adding the work I mentioned above.

-- 
Thanks,
Byungchul

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ