Re: [PATCH] mm: kill kmemcheck
On Mon, 16 Mar 2015 21:48:23 -0400 Sasha Levin wrote: > Steven, > > > Since the only objection raised was the too-newiness of GCC 4.9.2/5.0, what > would you consider a good time-line for removal? > > I haven't heard any "over my dead body" objections, so I guess that trying > to remove it while no distribution was shipping the compiler that would make > it possible was premature. > > Although, on the other hand, I'd be happy if we can have a reasonable date > (that is before my kid goes to college), preferably even before the next > LSF/MM so that we could have a mission accomplished thingie with a round > of beers and commemorative t-shirts. Perhaps give it 2 years? With fair notice that it will soon be gone? In 2 years I should be up to gcc 4.9 ;-) I still need to test it out. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: kill kmemcheck
On 03/11/2015 10:52 AM, Steven Rostedt wrote: >> > Could you try KASan for your use case and see if it potentially uncovers >> > anything new? > The problem is, I don't have a setup to build with the latest compiler. > > I could build with my host compiler (that happens to be 4.9.2), but it > would take a while to build, and is not part of my work flow. > > 4.9.2 is very new, I think it's a bit premature to declare that the > only way to test memory allocations is with the latest and greatest > kernel. > > But if kmemcheck really doesn't work anymore, than perhaps we should > get rid of it. Steven, Since the only objection raised was the too-newiness of GCC 4.9.2/5.0, what would you consider a good time-line for removal? I haven't heard any "over my dead body" objections, so I guess that trying to remove it while no distribution was shipping the compiler that would make it possible was premature. Although, on the other hand, I'd be happy if we can have a reasonable date (that is before my kid goes to college), preferably even before the next LSF/MM so that we could have a mission accomplished thingie with a round of beers and commemorative t-shirts. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: kill kmemcheck
On Wed, 11 Mar 2015 10:43:29 -0400 Sasha Levin wrote: > On 03/11/2015 10:26 AM, Steven Rostedt wrote: > >> There's no real hurry to kill kmemcheck right now, but we do want to stop > >> > supporting that in favour of KASan. > > Understood, but the kernel is suppose to support older compilers. > > Perhaps we can keep kmemcheck for now and say it's obsoleted if you > > have a newer compiler. Because it will be a while before I upgrade my > > compilers. I don't upgrade unless I have a good reason to do so. Not > > sure KASan fulfills that requirement. > > It's not that there's a performance overhead with kmemcheck, it's the > maintenance effort that we want to get rid of. I totally understand this. > > The kernel should keep supporting old kernels, and after this kmemcheck > removal your kernel will still keep working - this is more of a removal > of a mostly unused feature that had hooks everywhere in the kernel. > > Did you actually find anything recently with kmemcheck? I have to look. I think I did find something last year. I run it every other month or so, so it's not something I do every day. > How do you deal > with the 1 CPU limit and the massive performance hit? I just deal with it :-) I have test boxes that I kick off and just let run. It's not that bad if you are not using the box for actual work. > > Could you try KASan for your use case and see if it potentially uncovers > anything new? The problem is, I don't have a setup to build with the latest compiler. I could build with my host compiler (that happens to be 4.9.2), but it would take a while to build, and is not part of my work flow. 4.9.2 is very new, I think it's a bit premature to declare that the only way to test memory allocations is with the latest and greatest kernel. But if kmemcheck really doesn't work anymore, than perhaps we should get rid of it. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: kill kmemcheck
On 03/11/2015 03:39 PM, Sasha Levin wrote: > On 03/11/2015 08:40 AM, Steven Rostedt wrote: >> On Wed, 11 Mar 2015 08:34:46 -0400 >> Sasha Levin wrote: >> Fair enough. We knew there are existing kmemcheck users, but KASan should be superior both in performance and the scope of bugs it finds. It also shouldn't impose new limitations beyond requiring gcc 4.9.2+. >> Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3. >> >> It will be a while before I upgrade my build farm to something newer. > > Are you actually compiling new kernels with 4.6.3, or are you using older > kernels as well? > > There's no real hurry to kill kmemcheck right now, but we do want to stop > supporting that in favour of KASan. > Just my $0.017 for me I wish there was the single config MEM_CHECK and the new or old would be selected automatically depending on enabling factors, for example gcc version, if arch dependent and so on. Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: kill kmemcheck
From: Andrey Ryabinin Date: Wed, 11 Mar 2015 23:01:00 +0300 > 2015-03-11 21:44 GMT+03:00 David Miller : >> From: Sasha Levin >> Date: Wed, 11 Mar 2015 13:25:47 -0400 >> >>> You're probably wondering why there are changes to SPARC in that patchset? >>> :) >> >> Libsanitizer doesn't even build have the time on sparc, the release >> manager has to hand patch it into building again every major release >> because of the way ASAN development is done out of tree and local >> commits to the gcc tree are basically written over during the >> next merge. >> > > Libsanitizer is userspace lib it's for userspace ASan, KASan doesn't use it. > We have our own 'libsanitzer' in kernel. I was speaking about ASAN development in general, of which the libsanitizer issue is a byproduct. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: kill kmemcheck
2015-03-11 21:44 GMT+03:00 David Miller : > From: Sasha Levin > Date: Wed, 11 Mar 2015 13:25:47 -0400 > >> You're probably wondering why there are changes to SPARC in that patchset? :) > > Libsanitizer doesn't even build have the time on sparc, the release > manager has to hand patch it into building again every major release > because of the way ASAN development is done out of tree and local > commits to the gcc tree are basically written over during the > next merge. > Libsanitizer is userspace lib it's for userspace ASan, KASan doesn't use it. We have our own 'libsanitzer' in kernel. > So I'm a little bit bitter about this, as you can see. :) > -- Best regards, Andrey Ryabinin -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: kill kmemcheck
From: Sasha Levin Date: Wed, 11 Mar 2015 13:25:47 -0400 > You're probably wondering why there are changes to SPARC in that patchset? :) Libsanitizer doesn't even build have the time on sparc, the release manager has to hand patch it into building again every major release because of the way ASAN development is done out of tree and local commits to the gcc tree are basically written over during the next merge. So I'm a little bit bitter about this, as you can see. :) -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: kill kmemcheck
On 03/11/2015 01:20 PM, David Miller wrote: > From: Sasha Levin > Date: Wed, 11 Mar 2015 09:39:33 -0400 > >> > On 03/11/2015 08:40 AM, Steven Rostedt wrote: >>> >> On Wed, 11 Mar 2015 08:34:46 -0400 >>> >> Sasha Levin wrote: >>> >> > >>> > Fair enough. We knew there are existing kmemcheck users, but KASan > >>> > should be > >>> > superior both in performance and the scope of bugs it finds. It > >>> > also shouldn't > >>> > impose new limitations beyond requiring gcc 4.9.2+. > >>> > >>> >> Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3. >>> >> >>> >> It will be a while before I upgrade my build farm to something newer. >> > >> > Are you actually compiling new kernels with 4.6.3, or are you using older >> > kernels as well? >> > >> > There's no real hurry to kill kmemcheck right now, but we do want to stop >> > supporting that in favour of KASan. > Is the spectrum of CPU's supported by this GCC feature equal to all of the > CPU's supported by the kernel right now? > > If not, removing kmemcheck will always be a regression for someone. You're probably wondering why there are changes to SPARC in that patchset? :) I don't really know. Both kmemcheck and KASan run only on x86. I've also asked Vegard, who didn't know either... I guess it got copy-pasted from a different code. As far as I know the only regression is requiring newer GCC. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: kill kmemcheck
From: Sasha Levin Date: Wed, 11 Mar 2015 09:39:33 -0400 > On 03/11/2015 08:40 AM, Steven Rostedt wrote: >> On Wed, 11 Mar 2015 08:34:46 -0400 >> Sasha Levin wrote: >> >>> > Fair enough. We knew there are existing kmemcheck users, but KASan should >>> > be >>> > superior both in performance and the scope of bugs it finds. It also >>> > shouldn't >>> > impose new limitations beyond requiring gcc 4.9.2+. >>> > >> Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3. >> >> It will be a while before I upgrade my build farm to something newer. > > Are you actually compiling new kernels with 4.6.3, or are you using older > kernels as well? > > There's no real hurry to kill kmemcheck right now, but we do want to stop > supporting that in favour of KASan. Is the spectrum of CPU's supported by this GCC feature equal to all of the CPU's supported by the kernel right now? If not, removing kmemcheck will always be a regression for someone. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: kill kmemcheck
On 03/11/2015 10:26 AM, Steven Rostedt wrote: >> There's no real hurry to kill kmemcheck right now, but we do want to stop >> > supporting that in favour of KASan. > Understood, but the kernel is suppose to support older compilers. > Perhaps we can keep kmemcheck for now and say it's obsoleted if you > have a newer compiler. Because it will be a while before I upgrade my > compilers. I don't upgrade unless I have a good reason to do so. Not > sure KASan fulfills that requirement. It's not that there's a performance overhead with kmemcheck, it's the maintenance effort that we want to get rid of. The kernel should keep supporting old kernels, and after this kmemcheck removal your kernel will still keep working - this is more of a removal of a mostly unused feature that had hooks everywhere in the kernel. Did you actually find anything recently with kmemcheck? How do you deal with the 1 CPU limit and the massive performance hit? Could you try KASan for your use case and see if it potentially uncovers anything new? Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: kill kmemcheck
On Wed, 11 Mar 2015 09:39:33 -0400 Sasha Levin wrote: > On 03/11/2015 08:40 AM, Steven Rostedt wrote: > > On Wed, 11 Mar 2015 08:34:46 -0400 > > Sasha Levin wrote: > > > >> > Fair enough. We knew there are existing kmemcheck users, but KASan > >> > should be > >> > superior both in performance and the scope of bugs it finds. It also > >> > shouldn't > >> > impose new limitations beyond requiring gcc 4.9.2+. > >> > > > Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3. > > > > It will be a while before I upgrade my build farm to something newer. > > Are you actually compiling new kernels with 4.6.3, or are you using older > kernels as well? Yes for both :-) > > There's no real hurry to kill kmemcheck right now, but we do want to stop > supporting that in favour of KASan. Understood, but the kernel is suppose to support older compilers. Perhaps we can keep kmemcheck for now and say it's obsoleted if you have a newer compiler. Because it will be a while before I upgrade my compilers. I don't upgrade unless I have a good reason to do so. Not sure KASan fulfills that requirement. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: kill kmemcheck
On Wed, Mar 11, 2015 at 09:39:33AM -0400, Sasha Levin wrote: > On 03/11/2015 08:40 AM, Steven Rostedt wrote: > > On Wed, 11 Mar 2015 08:34:46 -0400 > > Sasha Levin wrote: > > > >> > Fair enough. We knew there are existing kmemcheck users, but KASan > >> > should be > >> > superior both in performance and the scope of bugs it finds. It also > >> > shouldn't > >> > impose new limitations beyond requiring gcc 4.9.2+. > >> > > > Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3. > > > > It will be a while before I upgrade my build farm to something newer. > > Are you actually compiling new kernels with 4.6.3, or are you using older > kernels as well? > > There's no real hurry to kill kmemcheck right now, but we do want to stop > supporting that in favour of KASan. Another question is "is kmemcheck actually finding anything right now?" I've personally not hit anything with it in quite a while. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: kill kmemcheck
On 03/11/2015 08:40 AM, Steven Rostedt wrote: > On Wed, 11 Mar 2015 08:34:46 -0400 > Sasha Levin wrote: > >> > Fair enough. We knew there are existing kmemcheck users, but KASan should >> > be >> > superior both in performance and the scope of bugs it finds. It also >> > shouldn't >> > impose new limitations beyond requiring gcc 4.9.2+. >> > > Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3. > > It will be a while before I upgrade my build farm to something newer. Are you actually compiling new kernels with 4.6.3, or are you using older kernels as well? There's no real hurry to kill kmemcheck right now, but we do want to stop supporting that in favour of KASan. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: kill kmemcheck
On Wed, 11 Mar 2015 08:34:46 -0400 Sasha Levin wrote: > Fair enough. We knew there are existing kmemcheck users, but KASan should be > superior both in performance and the scope of bugs it finds. It also shouldn't > impose new limitations beyond requiring gcc 4.9.2+. > Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3. It will be a while before I upgrade my build farm to something newer. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: kill kmemcheck
On 03/11/2015 08:19 AM, Steven Rostedt wrote: > I removed the Cc list as it was so large, I'm sure that it exceeded the > LKML Cc size limit, and your email probably didn't make it to the list > (or any of them). Thanks. I'll resend in a bit if it doesn't show up on lkml.org. > On Wed, 11 Mar 2015 07:43:59 -0400 > Sasha Levin wrote: > >> > As discussed on LSF/MM, kill kmemcheck. >> > >> > KASan is a replacement that is able to work without the limitation of >> > kmemcheck (single CPU, slow). KASan is already upstream. >> > >> > We are also not aware of any users of kmemcheck (or users who don't >> > consider >> > KASan as a suitable replacement). > I use kmemcheck and I am unaware of KASan. I'll try to play with KASan > and see if it suites my needs. Fair enough. We knew there are existing kmemcheck users, but KASan should be superior both in performance and the scope of bugs it finds. It also shouldn't impose new limitations beyond requiring gcc 4.9.2+. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
