On Thu, Apr 26, 2018 at 02:54:26PM -0400, Mikulas Patocka wrote: > > > On Thu, 26 Apr 2018, Michael S. Tsirkin wrote: > > > On Thu, Apr 26, 2018 at 12:07:25PM -0400, Mikulas Patocka wrote: > > > > IIUC debug kernels mainly exist so people who experience e.g. memory > > > > corruption can try and debug the failure. In this case, CONFIG_DEBUG_SG > > > > will *already* catch a failure early. Nothing special needs to be done. > > > > > > The patch helps people debug such memory coprruptions (such as using DMA > > > API on the result of kvmalloc). > > > > That's my point. I don't think your patch helps debug any memory > > corruptions. With CONFIG_DEBUG_SG using DMA API already causes a > > BUG_ON, that's before any memory can get corrupted. > > The patch turns a hard-to-reproduce bug into an easy-to-reproduce bug. It's still not a memory corruption. It's a BUG_ON the source of which - should it trigger - can be typically found using grep. > Obviously we don't want this in production kernels, but in the debug > kernels it should be done. > > Mikulas I'm not so sure. debug kernels should make debugging easier, definitely. Unfortunately they are already slower so some races don't trigger. If they also start crashing more because we are injecting memory allocation errors, people are even less likely to be able to use them. Just add a comment near the BUG_ON within DMA API telling people how they can inject this error some more if the bug does not reproduce, and leave it at that. -- MST -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
