A bunch of fixes for a moderately common class of bugs: file with
single_open() done by its ->open() and seq_release as its ->release().
That leaks; fortunately, it's not _too_ common (either people manage to
RTFM that says "When using single_open(), the programmer should use
single_release() instead of seq_release() in the file_operations structure
to avoid a memory leak", or they just copy a correct instance), but grepping
through the tree has caught quite a pile. All of that is, AFAICS, -stable
fodder, for as far as the patches apply. I tried to carve it up into
reasonably-sized pieces (more or less "comes from the same tree"). Please,
pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (15):
arm: single_open() leaks
cris: single_open() leaks
h8300: single_open() leaks
ia64: single_open() leaks
mips: single_open() leaks
parisc: single_open() leaks
sh: single_open() leaks
ds1620: single_open() leak
rtc: single_open() leaks
input: single_open() leak
wireless: single_open() leaks
megaraid: single_open() leak
staging: single_open() leaks
gadget: single_open() leaks
rcutrace: single_open() leaks
Diffstat:
arch/arm/kernel/swp_emulate.c | 2 +-
arch/arm/mach-omap1/pm.c | 2 +-
arch/cris/arch-v10/kernel/fasttimer.c | 2 +-
arch/cris/arch-v32/kernel/fasttimer.c | 2 +-
arch/h8300/kernel/gpio.c | 2 +-
arch/ia64/kernel/palinfo.c | 2 +-
arch/ia64/kernel/salinfo.c | 2 +-
arch/ia64/sn/kernel/sn2/prominfo_proc.c | 4 ++--
arch/mips/kernel/smtc-proc.c | 2 +-
arch/mips/pci/ops-pmcmsp.c | 4 ++--
arch/mips/sibyte/sb1250/bus_watcher.c | 2 +-
arch/parisc/kernel/pdc_chassis.c | 2 +-
arch/sh/drivers/dma/dma-api.c | 2 +-
drivers/char/ds1620.c | 2 +-
drivers/char/efirtc.c | 2 +-
drivers/char/genrtc.c | 2 +-
drivers/input/misc/hp_sdc_rtc.c | 2 +-
drivers/net/wireless/atmel.c | 2 +-
drivers/net/wireless/hostap/hostap_ap.c | 4 ++--
drivers/net/wireless/hostap/hostap_hw.c | 2 +-
drivers/net/wireless/hostap/hostap_proc.c | 6 +++---
drivers/scsi/megaraid.c | 2 +-
drivers/staging/comedi/proc.c | 2 +-
drivers/staging/csr/io.c | 2 +-
drivers/staging/cxt1e1/sbeproc.c | 2 +-
drivers/staging/ft1000/ft1000-pcmcia/ft1000_proc.c | 2 +-
drivers/staging/ft1000/ft1000-usb/ft1000_proc.c | 2 +-
drivers/staging/rtl8187se/r8180_core.c | 2 +-
drivers/staging/rtl8192u/r8192U_core.c | 2 +-
drivers/staging/wlags49_h2/wl_main.c | 2 +-
drivers/usb/gadget/fsl_udc_core.c | 2 +-
drivers/usb/gadget/goku_udc.c | 2 +-
kernel/rcutree_trace.c | 8 ++++----
33 files changed, 41 insertions(+), 41 deletions(-)
On 2013-05-05 Sunday at 06:54 +0100 Al Viro wrote:
> A bunch of fixes for a moderately common class of bugs: file with
> single_open() done by its ->open() and seq_release as its ->release().
> That leaks; fortunately, it's not _too_ common (either people manage to
> RTFM that says "When using single_open(), the programmer should use
> single_release() instead of seq_release() in the file_operations structure
> to avoid a memory leak", or they just copy a correct instance), but grepping
> through the tree has caught quite a pile. All of that is, AFAICS, -stable
> fodder, for as far as the patches apply. … …
Some 40 memory leaks plugged at once … quite elegant :)
Additionally maybe your cunning grep commands are checkpatch.pl fodder?
At patch level risk of false warnings probably would be lower than at C code
level.
--
Regards
Roland Eggner