Re: panic: Unaligned free (was: kernel panic while copying files)

From: Edward Tomasz Napierała <trasz_at_freebsd.org>
Date: Mon, 05 Jul 2021 14:04:48 UTC
On 0701T1330, Gary Jennejohn wrote:
> Gary Jennejohn <gljennjohn@gmail.com> wrote:
> > I noticed that the value of vm.debug.divisor affects what value is
> > returned in uma_core.c:uma_dbg_kskip(), so I decided to try a few
> > different values.
> > 
> > The returned value is used to set skipdbg in uma_core.c:item_dtor().
> > 
> > The default is vm.debug.divisor=1.
> > 
> > vm.debug.divisor is only present when INVARIANTS is defined.
> > 
> > kskipdbg eventually affects the value of freei.
> > 
> > With these values:
> > vm.debug.divisor: 0
> > kern.cam.da.enable_uma_ccbs: 1
> > I can turn on the disk and it comes up without a panic!
> > 
> > However, I didn't try to do any large data transfers to the disk.
> > 
> > So, it appears that at least vm.debug.divisor is a big factor in
> > whether or not a panic happens with INVARIANTS.
> > 
> 
> I decided to do a real test.  So I built a kernel w/o INVARIANTS and
> installed it to /boot/test.
> 
> Then I stuck a 160GB disk I had around into an external USB3 enclosure
> and put a filesystem on it.
> 
> The I booted the new kernel from /boot/test and set the sysctls so:
> kern.cam.da.enable_uma_ccbs: 1
> kern.cam.ada.enable_uma_ccbs: 1
> 
> After that I plugged in the external USB3 enclosure and copied about
> 114GiB of data from an internal SSD to it - without a kernel panic:
> Filesystem    Size    Used   Avail Capacity  Mounted on
> /dev/da0p1    144G    114G     18G    86%    /mnt
> 
> I'm pretty sure that's more than I could copy without a kernel panic
> prior to the recent changes made in cam and umass.
> 
> My test may not be real proof that all bugs have been squashed, but it
> certainly seems to be a better situation than we had before.

I think the vm.debug.divisor simply masks the problem; the underlying
bug is still there.

Could you go back to the setup which panics, and then test the patch
at https://reviews.freebsd.org/D31054?  It fixes the scenario described
by Warner.