A user reports the following issue with a system that has a DAHDI device
using the ZapHFC driver:

Everything works nicely, except the zaphfc driver is leaking skbuff
kernel memory at a rate of ~1 KiByte per minute. Please see kmemleak
output below. It took me a while to figure this out, because the
Asterisk machine has 8 GB of RAM.

I am no expert with skb functionality, but from what I could gather
reading the driver source code file base.c, it appears the leak is
occuring in function hfc_frame_arrived.  That dev_alloc_skb is
apparantly not freed when required.  Symptom of the leak is the line
SUnreclaim in /proc/meminfo steadily increasing and of course kmemleak
thread reporting unreferenced objects.

unreferenced object 0xffff880211868200 (size 256):
  comm "hardirq", pid 0, jiffies 4305662577 (age 35733.616s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff816cba06>] kmemleak_alloc+0x26/0x50
    [<ffffffff8118651b>] kmem_cache_alloc+0xab/0x170
    [<ffffffff815d6cc4>] build_skb+0x34/0x1c0
    [<ffffffff815da9b2>] __netdev_alloc_skb+0xa2/0xf0
    [<ffffffffa03be793>] hfc_frame_arrived+0xf3/0x1e0 [zaphfc]
    [<ffffffffa03bea6c>] hfc_interrupt+0x1ec/0x790 [zaphfc]
    [<ffffffff810ee475>] handle_irq_event_percpu+0x55/0x210
    [<ffffffff810ee67e>] handle_irq_event+0x4e/0x80
    [<ffffffff810f1894>] handle_fasteoi_irq+0x64/0x120
    [<ffffffff810166f2>] handle_irq+0x22/0x40
    [<ffffffff81700caa>] do_IRQ+0x5a/0xe0
    [<ffffffff816f672d>] ret_from_intr+0x0/0x15
    [<ffffffff8158d620>] cpuidle_enter_tk+0x10/0x20
    [<ffffffff8158d1df>] cpuidle_idle_call+0xaf/0x2b0
    [<ffffffff8101dacf>] cpu_idle+0xcf/0x120
    [<ffffffff816c8f62>] rest_init+0x72/0x80

Hi,

I also experienced this bug on my machine (bug is still present in latest dahdi-linux code in SID), so I investigated a bit into the code.

Analysis:

I recognized that the sk_buff at first sight is needed in both cases of the if statement,
but the memcpy to the sk_buff in the true case is totally pointless as the data is not passed on at all.
It seems to be a relic of the software based HDLC times, when we passed the frame data on to the dahdi-hdlc code.

The struct sk_buff is only used as a temporary buffer to remove the frame from the FIFO without any further processing, if the channel is not open.

Patch:

1. Replace the struct sk_buff with a plain void * that is only allocated when needed. It’s a throw away buffer, so no need the added complexity of sk_buff.
2. Remove memcpy which copies frame data from the channel buffer to the SKB in the channel open case.
3. As a consequence of (2) the alloc/dealloc code is moved into the channel closed case of the if statement.

The attached patch is tested successfully on my live EDSS1 line here in Germany.


Kind Regards

Karsten

[Karsten Richter 2015-02-13]
a good idea to get their input on the changes, and it is probably best if
you have direct contact with them instead of trying to pass in through
others.

I believe upstream uses <URL: https://issues.asterisk.org/jira/browse/DAHLIN >
as their bug tracker.

That specific driver was never included in upstream DAHDI and right now
does not seem to have any upstream maintainers. I'm not sure if I tried
to apply it and it caused problems, or not.

[Tzafrir Cohen]

I tried, and it fail to apply.  The drivers/dahdi/zaphfc/base.c file no
longer mention sk_buf, no idea what happened.  The git history on salsa
only mention 'New upstream version 3.1.0+git20230717~dfsg' when the file
was added, so there is at least ten years of unknown history here.

Dropping the patch tag as it no longer applies.