[git pull] single_open() leak fixes

[git pull] single_open() leak fixes

[Al Viro]

	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(-)

Re: [git pull] single_open() leak fixes

[Roland Eggner]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]