linuxsh-dev

[linuxsh-dev] slab poisoning

[Stuart M. <Stu...@st...>]

Folks

I've been chasing a problem for a few hours now, and I was just wondering if
anyone else has seen it.

When using the ST-NIC Ethernet interface on the 7750 Solution Engine,
and transferring a fairly large (~ 0.5Mb) using FTP, I start getting the
error message:
  kmem_alloc: Bad poison (name=size-2048)

A big of digging appears to show that an Ethernet frame is being written
into a slab of memory which is on the free list. I can't believe this
is a generic kernel/driver/mm problem, otherwise it would have been
fixed by now, but equally I can't see anything SuperH specific about this
either.

Any ideas anyone?

Stuart

[linuxsh-dev] slab poisoning

[NIIBE Y. <gn...@ch...>]

Stuart Menefy wrote:
 > A big of digging appears to show that an Ethernet frame is being written
 > into a slab of memory which is on the free list. I can't believe this
 > is a generic kernel/driver/mm problem, otherwise it would have been
 > fixed by now, but equally I can't see anything SuperH specific about this
 > either.
 > 
 > Any ideas anyone?

I think that there's a bug at stnic_block_input.  Consider the case
length is odd number.  The variable length is incremented by one.  The
loop handles HALF (2-byte) at a time.  This could be overflow the SKB
buffer by one-byte.  Just a one byte, but the field at skb->end is
used for skb_datarefp macro.  I guess this causes bad effect on
resource calculation of SKB.
-- 

Re: [linuxsh-dev] slab poisoning

[Stuart M. <Stu...@st...>]

Folks

I've found what was causing the 'slab poisoning' problem which I reported
a few days ago. There is a bug in the kernel when setting the interrupt
mask bits in the status register when returning from an exception. This
can result in interrupts being re-enabled when they should not be.

The particular sequence of events which caused this in my situation was:
 - kernel is executing in the slab memory allocator free function
 - executes a spin_lock_irqsave which disables interrupts
 - takes a floating point exception
 - on return from the exception interrupts are erroneously re-enabled
 - an interrupt from the Ethernet controller occurs
 - interrupt handler calls the slab allocator to allocate a packet
 - packet which is returned is one which has been freed but not yet
   poisoned, and so fails the poison test

A patch is attached which fixes this, which I'll check this in in the
next few days if nobody objects. It also feels like it improves
overall reliability, although I've not got any data to back this up.

I'm surprised nobody else is seeing these problems. Are we the only
people using SH4 perhaps?

One thing I did spot while doing this. The irq_imask technique of
interrupt masking will not work with interrupts at priority 15. Not
really a problem, but it might be worth adding a comment somewhere
before this trips somebody up.

Stuart

Re: [linuxsh-dev] slab poisoning

[NIIBE Y. <gn...@ch...>]

Stuart Menefy wrote:
 > I've found what was causing the 'slab poisoning' problem which I reported
 > a few days ago. There is a bug in the kernel when setting the interrupt
 > mask bits in the status register when returning from an exception. This
 > can result in interrupts being re-enabled when they should not be.
[...]

Well spotted.  But still I think that the issue I mentioned exists
(when packet length is odd).

 > I'm surprised nobody else is seeing these problems. Are we the only
 > people using SH4 perhaps?

SolutionEngine SH4 is configured using it's own interrupt controller, 
so it doesn't used irq_mask.

 > One thing I did spot while doing this. The irq_imask technique of
 > interrupt masking will not work with interrupts at priority 15. Not
 > really a problem, but it might be worth adding a comment somewhere
 > before this trips somebody up.

Agreed.

Please check all of the pending patches of yours in.  I have an idea
for handling alias issue of shared page.  I'll modify the code, when
you commit.
-- 

Re: [linuxsh-dev] slab poisoning

[NIIBE Y. <gn...@ch...>]

NIIBE Yutaka wrote:
 > But still I think that the issue I mentioned exists
 > (when packet length is odd).

No, I was wrong.  Since skb->end is aligned, there's no such off-by-one
confusion to be occurred.
--