Re: [dm-devel] [PATCH RESEND] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Thu, 26 Apr 2018, Mikulas Patocka wrote: > > Hmmm... order 4 for these caches may cause some concern. These should stay > > under costly order I think. Otherwise allocations are no longer > > guaranteed. > > You said that slub has fallback to smaller order allocations. Yes it does... > The

[dm-devel] Undo removing a missing PV to a VG, which caused inconsistent metadata

I had (4) platter disks and (1) SSD in a VG lvm. LV's were either on platters or the SSD, none were across both. Long story short, booted without SSD plugged in, and didn't need access to the LV's on the SSD. Needed to create a temporary LV on the platters, and got an error about not being able

Re: [dm-devel] dm/raid1: Remove VLA usage

On Thu, Apr 26 2018 at 7:31pm -0400, Kees Cook wrote: > On Tue, Apr 10, 2018 at 9:43 PM, Kees Cook wrote: > > On the quest to remove all VLAs from the kernel[1], this avoids VLAs > > in dm-raid1.c by just using the maximum size for the stack

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Fri, 27 Apr 2018, Michal Hocko wrote: > On Thu 26-04-18 18:52:05, Mikulas Patocka wrote: > > > > > > On Fri, 27 Apr 2018, Michael S. Tsirkin wrote: > [...] > > >But assuming it's important to control this kind of > > >fault injection to be controlled from > > >a dedicated

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu 26-04-18 18:52:05, Mikulas Patocka wrote: > > > On Fri, 27 Apr 2018, Michael S. Tsirkin wrote: [...] > >But assuming it's important to control this kind of > >fault injection to be controlled from > >a dedicated menuconfig option, why not the rest of > >faults? > > The

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, Apr 26, 2018 at 05:50:20PM -0400, Mikulas Patocka wrote: > How is the user or developer supposed to learn about this option, if > he gets no crash at all? Look in /sys/kernel/debug/fail* ? That actually lets you filter by module, process etc. I think this patch conflates two things: 1.

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, Apr 26, 2018 at 03:36:14PM -0400, Mikulas Patocka wrote: > People on this list argue "this should be a kernel parameter". How about making it a writeable attribute, so it's easy to turn on/off after boot. Then you can keep it deterministic, userspace can play with the attribute at random

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, Apr 26, 2018 at 11:44:21AM -0400, Mikulas Patocka wrote: > > > On Thu, 26 Apr 2018, James Bottomley wrote: > > > On Thu, 2018-04-26 at 11:05 -0400, Mikulas Patocka wrote: > > > > > > On Thu, 26 Apr 2018, James Bottomley wrote: > > [...] > > > > Perhaps find out beforehand instead of

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

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

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Thu, Apr 26, 2018 at 02:58:08PM -0400, Mikulas Patocka wrote: > > > On Thu, 26 Apr 2018, Michael S. Tsirkin wrote: > > > How do you make sure QA tests a specific corner case? Add it to > > the test plan :) > > BTW. how many "lines of code" of corporate bureaucracy would that take? :-) It's

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

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