Hi Takashi,

On Fri, 2018-09-28 at 12:44 +0900, Takashi Sakamoto wrote:
> Hi Scott,
> 
> On Sep 24 2018 18:32, Scott Bahling wrote:

> > 
> > The kernel was unstable and the system hard locked frequently with the
> > patches enabled (with and without the GFP_KERNEL patch). But I was able
> > to map out all the controller functions to the bits in the first 16
> > quadlets. I will write up my findings and send them later.
> 
> I'm sorry but I have applied wrong changes to the remote branch for
> kernel patch. It includes three issues:
> 
> 1. call vfree() to memory object allocated by kmalloc()
> 2. bring kernel oops due to double free corruption of 'tscm->status'
> 3. invalid page mapping of 'tscm->status' to process' VMA
> 
> I pushed additional three patches. Would you please test with them?
> 
>   - 1777454 firewire-tascam: fix kernel oops to call vfree() to memory 
> object allocated by kmalloc
>   - e11d941 firewire-tascam: fix double free corruption
>   - 5e7fef9 firewire-tascam: use one page for mmap(2)ed data
> 
> Espeially, when allocating in kernel logical space instead of kernel
> virtual space, I should have kept one page for 'tscm->status' because
> kmalloc() allocates memory object unaligned to page boundary by kernel
> SLAB/SLOB/SLUB allocaters. This is a cause which you cannot see updated
> data. A page mapped to process' VMA doesn't include region of
> 'tscm->status' data correctly.
> 
> Again, I'm sorry to lost your time due to this kind of my stupid
> codes...

No worries! It did not waste too much time at all. I assumed it's just
quick test code anyway. I was able to get the button press events and
control levels mapped to the quadlet bits which was my goal (I'm still
documenting my findings).

I will test your new patches this weekend and let you know if it works
better.

Are you still thinking to try to make mmap the solution to pass the
control data to userspace, or do we need to find another method in the
long run?

Regards,

Scott
>