From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932470AbbIUPrO (ORCPT ); Mon, 21 Sep 2015 11:47:14 -0400 Received: from mail-qg0-f45.google.com ([209.85.192.45]:33812 "EHLO mail-qg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753480AbbIUPrK (ORCPT ); Mon, 21 Sep 2015 11:47:10 -0400 Subject: Re: First kernel patch (optimization) To: Alexander Holler , "Theodore Ts'o" , Greg KH , Josh Boyer , Eric Curtin , Steve Calfee , Valentina Manea , Shuah Khan , USB list , Kernel development list References: <20150916164031.GH7394@thunk.org> <20150918031251.GA30905@thunk.org> <20150918074248.GA10792@kroah.com> <20150919022624.GB2921@thunk.org> <20150919051827.GB17114@kroah.com> <55FD5A76.1020603@ahsoftware.de> <20150919142219.GF2921@thunk.org> <55FD9FAA.3070401@ahsoftware.de> <20150920022142.GA2909@thunk.org> <55FE8D6C.8090309@ahsoftware.de> From: Austin S Hemmelgarn Message-ID: <5600267A.8070605@gmail.com> Date: Mon, 21 Sep 2015 11:47:06 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55FE8D6C.8090309@ahsoftware.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050606020608090102000607" X-Antivirus: avast! (VPS 150921-0, 2015-09-21), Outbound message X-Antivirus-Status: Clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is a cryptographically signed message in MIME format. --------------ms050606020608090102000607 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-09-20 06:41, Alexander Holler wrote: > Am 20.09.2015 um 04:21 schrieb Theodore Ts'o: >> On Sat, Sep 19, 2015 at 07:47:22PM +0200, Alexander Holler wrote: > >> Perhaps not so surprisingly, over a decade later, it is not currently >> at the top of the priority list of any of the current file system or >> VFS developers, as far as I know. One of the reasons for that is that= >> there are a number of other ways of achieving the same functionality. >> These include using tmpfs, or using file system level encryption. >> They require a bit more system administrator setup than just being >> able to set the FS_SECR_FL flag, true, but just because it's more >> convenient doesn't mean that it's worth doing. > > Again, I don't think that encryption is an alternative. Besides that > there is always the thread that strong encrytion will become regulated,= > there is also the very real thread that someone might end up in jail > when using encryption and throwing away the key to delete stuff. E.g., > as to my knowledge, in the UK you might end up in jail if you don't han= d > out a password. So what happens if you've deleted the key and are reall= y > unable to hand it out and the people which have an interest in what > you've once stored don't believe you? First off, this is why I will never live in the UK. Secondly, this is=20 why if it's something that you don't want to store for a long time (that = is, longer than the system will be powered on), you use an ephemeral=20 encryption key. Thirdly, if there is some chance you can lose the key,=20 you make a secure backup (or do like I do and algorithmically generate=20 passwords/encryption keys in a reproducible manner (which is itself=20 secure if you do it right, and of course tell no-one the algorithm you=20 use to generate them)). >> So.... this is a feature request. It's a reasonable feature request, >> in that if someone would like to pay $$$ for some consultant to >> implement it in a way that is bug-free, I suspect it could go >> upstream. Someone who was very motivated and with the sufficient >> skills could also invest their own effort to make a patch that can go >> upstream too. You've elected not, to because you believe it would >> take you months of "unpaid time". That's purely within your rights to= >> do. But you don't have the right to try to tell other people what >> work to do on their behalf --- not unless you are paying their salary.= > > First I haven't request that someone implements it for me. Besides that= > what you're describing is what maintainers do all the time. Of course, > it's their job to request quality, but, in my humble opinion, very ofte= n > they are requesting stuff just to request something. The problem I see with this argument is: 1. There's a lot of code in the kernel that wouldn't be merged today in=20 the state it's in, this creates a false sense of what quality is=20 expected for new code (BTRFS in particular comes to mind here). 2. If the code can be proven to be racy, you fix it, period. Adding=20 known racy code to the kernel should never happen. The same goes for=20 unsafe usage of locking, RCU, or any subsystem related macros/functions. = This should probably be better spelled out in SubmittingPatches. 3. Subsystem maintainers became maintainers because they have a very=20 high degree of knowledge relating to that subsystem, and usually about=20 general kernel programming as well. If a maintainer is asking you to=20 fix something in your patch, I'd be more than willing to bet that they=20 are right in asking you to fix it. > And that "month of unpaid time" was for sure a cynical exaggeration I'v= e > done while having been angry. In fact I believe the way I've outlined > with the ugly code (proof of concept) could be implemented by someone > like you in a weekend. For me it needs quiet some more time because I > had and still have almost zero knowledge about all locks and whatever > else is used in the filesystem code. But nevertheless I was able to fix= > up a lot of stuff during another afternoon. E.g. I've added checks if a= > file is in use or if AT_WIPE was called on a directory and then returne= d > errors in those cases. Unfortunately the code changed in 4.2 and that > patch doesn't apply anymore and now, because I don't really need those > implementation details (I'm aware of the problems of my patch), I've > thrown the patch into the waste bin. Besides that my concept doesn't > work on BTRFS what I'm currently using for various reasons (mainly > compression) on most of my systems. And I have no idea if it ever will > (because I don't know why discard on BTRFS doesn't really discard what = I > think it should discard. ;) ). Discard has never really worked properly in BTRFS, although it is being=20 worked on. If you actually care about security though, you shouldn't be = using discard except when re-provisioning your storage (there are=20 numerous papers about why on the web), trying to use that for secure=20 deletion is creating a false sense of security. If you're using in-line compression, then that at least means that it=20 will take somewhat more effort to get a file off of the disk that has=20 been deleted. --------------ms050606020608090102000607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Brgwgga0MIIEnKADAgECAgMRLfgwDQYJKoZIhvcNAQENBQAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNp Z25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcN MTUwOTIxMTEzNTEzWhcNMTYwMzE5MTEzNTEzWjBjMRgwFgYDVQQDEw9DQWNlcnQgV29UIFVz ZXIxIzAhBgkqhkiG9w0BCQEWFGFoZmVycm9pbjdAZ21haWwuY29tMSIwIAYJKoZIhvcNAQkB FhNhaGVtbWVsZ0BvaGlvZ3QuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA nQ/81tq0QBQi5w316VsVNfjg6kVVIMx760TuwA1MUaNQgQ3NyUl+UyFtjhpkNwwChjgAqfGd LIMTHAdObcwGfzO5uI2o1a8MHVQna8FRsU3QGouysIOGQlX8jFYXMKPEdnlt0GoQcd+BtESr pivbGWUEkPs1CwM6WOrs+09bAJP3qzKIr0VxervFrzrC5Dg9Rf18r9WXHElBuWHg4GYHNJ2V Ab8iKc10h44FnqxZK8RDN8ts/xX93i9bIBmHnFfyNRfiOUtNVeynJbf6kVtdHP+CRBkXCNRZ qyQT7gbTGD24P92PS2UTmDfplSBcWcTn65o3xWfesbf02jF6PL3BCrVnDRI4RgYxG3zFBJuG qvMoEODLhHKSXPAyQhwZINigZNdw5G1NqjXqUw+lIqdQvoPijK9J3eijiakh9u2bjWOMaleI SMRR6XsdM2O5qun1dqOrCgRkM0XSNtBQ2JjY7CycIx+qifJWsRaYWZz0aQU4ZrtAI7gVhO9h pyNaAGjvm7PdjEBiXq57e4QcgpwzvNlv8pG1c/hnt0msfDWNJtl3b6elhQ2Pz4w/QnWifZ8E BrFEmjeeJa2dqjE3giPVWrsH+lOvQQONsYJOuVb8b0zao4vrWeGmW2q2e3pdv0Axzm/60cJQ haZUv8+JdX9ZzqxOm5w5eUQSclt84u+D+hsCAwEAAaOCAVkwggFVMAwGA1UdEwEB/wQCMAAw VgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBo ZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMA4GA1UdDwEB/wQEAwIDqDBABgNV HSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCG SAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2Vy dC5vcmcwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC5jYWNlcnQub3JnL3Jldm9rZS5j cmwwNAYDVR0RBC0wK4EUYWhmZXJyb2luN0BnbWFpbC5jb22BE2FoZW1tZWxnQG9oaW9ndC5j b20wDQYJKoZIhvcNAQENBQADggIBADMnxtSLiIunh/TQcjnRdf63yf2D8jMtYUm4yDoCF++J jCXbPQBGrpCEHztlNSGIkF3PH7ohKZvlqF4XePWxpY9dkr/pNyCF1PRkwxUURqvuHXbu8Lwn 8D3U2HeOEU3KmrfEo65DcbanJCMTTW7+mU9lZICPP7ZA9/zB+L0Gm1UNFZ6AU50N/86vjQfY WgkCd6dZD4rQ5y8L+d/lRbJW7ZGEQw1bSFVTRpkxxDTOwXH4/GpQfnfqTAtQuJ1CsKT12e+H NSD/RUWGTr289dA3P4nunBlz7qfvKamxPymHeBEUcuICKkL9/OZrnuYnGROFwcdvfjGE5iLB kjp/ttrY4aaVW5EsLASNgiRmA6mbgEAMlw3RwVx0sVelbiIAJg9Twzk4Ct6U9uBKiJ8S0sS2 8RCSyTmCRhJs0vvva5W9QUFGmp5kyFQEoSfBRJlbZfGX2ehI2Hi3U2/PMUm2ONuQG1E+a0AP u7I0NJc/Xil7rqR0gdbfkbWp0a+8dAvaM6J00aIcNo+HkcQkUgtfrw+C2Oyl3q8IjivGXZqT 5UdGUb2KujLjqjG91Dun3/RJ/qgQlotH7WkVBs7YJVTCxfkdN36rToPcnMYOI30FWa0Q06gn F6gUv9/mo6riv3A5bem/BdbgaJoPnWQD9D8wSyci9G4LKC+HQAMdLmGoeZfpJzKHMYIE0TCC BM0CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNl cnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAxEt+DANBglghkgBZQMEAgMFAKCCAiEwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwOTIxMTU0NzA2WjBPBgkq hkiG9w0BCQQxQgRANFxZR6nMixDVhQ5QBLMsii27+e0LxD5kBW+pfcRvWQYajiZw0N6buK/Y qA1dQYZ1T0LibQoJmAwZcukblVa4AzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGRBgkrBgEEAYI3EAQxgYMwgYAweTEQMA4GA1UE ChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2Vy dC5vcmcCAxEt+DCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBDQTEe MBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAxEt+DAN BgkqhkiG9w0BAQEFAASCAgA1zRVI946hLe8Ffy4rGPq00R2KP7pgNxOcckHUQM6jQGyyXS2b kXsp9Cs3kOCW+zFlaUmEVO7BnmwaB67wgZafq9fEWevamY8PudVwDHIO6dpNKpm36T/Ufj49 poqa0vGeXxbB+h9ke5keeN5K3bl2c4h+Nax5ieexRtxkxUm8HZ1L45qbFGZCjDacVLl7sSua rlD8Md1vjfUDic9zOzz2zTzYnb6dWK5zvvS73G1O6jnLuelCUrdfGt930MJd/7vCUeVtD7jO cjLOZvS0dK6GCpfOZNrm6RGsdQKMWuLXFx6b0CfYRws/u9L2ypVjiaCOrgbRjw8tIBHOgzE0 B5JTsceyRKzts1CChDSiT/fGzZir8t3yp3uCGvnon+158xuACl5p2t4aOKj2JPZhAoA58+mF OORRtfKS8XqCSkRwMsN4vnMYZDcSPXsVIOvIYEs2bWeW4hEbABQthEadH8/9fpg1xnqYgRWP 95+8iyIko0Jiw/R9zsEQEKFgtMTVjByOK0rLcTce7+SWB+FMJFFgu0u69RmEV1toP9Pn2Qfm k7aBCAAi6n78Ri9jR9dadQ3PQ7N0ouD8SFfTwpsGnRMhdHY0w0UnDyxi3ZOGGdfPR4g9ZgUL lcJDAWfHn9n6NySTr0OrPrrkQogvv30kHwGpVvQEPGEODE5561nK0DyEEwAAAAAAAA== --------------ms050606020608090102000607--