linux-kernel - Re: [PATCH] Use vprintk rather that vsnprintf where possible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20081207000554.95a5d259.akpm@linux-foundation.org>
Date:	Sun, 7 Dec 2008 00:05:54 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Matt Mackall <mpm@...enic.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Use vprintk rather that vsnprintf where possible

On Thu, 04 Dec 2008 14:41:49 -0600 Matt Mackall <mpm@...enic.com> wrote:

> 
> This does away with lots of large static and on-stack buffers as well
> as a few associated locks.

Please add diffstats to the patches.

 drivers/cpufreq/cpufreq.c    |   11 +------
 drivers/scsi/arm/fas216.c    |    6 +---
 drivers/scsi/nsp32.c         |   25 +++++++----------
 drivers/scsi/pcmcia/nsp_cs.c |   24 +++++++---------
 fs/adfs/super.c              |   12 +++-----
 fs/affs/amigaffs.c           |   22 ++++++---------
 fs/befs/debug.c              |   47 ++++++---------------------------
 fs/hpfs/super.c              |    7 +---
 fs/jfs/super.c               |    7 ++--
 fs/ntfs/debug.c              |   46 ++++++++++++--------------------
 fs/ocfs2/super.c             |   22 +++++++--------
 fs/partitions/ldm.c          |    7 ++--
 fs/udf/super.c               |   16 +++++------
 fs/ufs/super.c               |   46 ++++++++++++++++----------------
 fs/xfs/support/debug.c       |   26 ++++--------------
 15 files changed, 121 insertions(+), 203 deletions(-)

argh.  I count at least thirteen separate developers who need to review
this patch.  Many of them would ideally be the ones who merge their
piece of it.  If they have issues or request updates, that churns the
whole patch.

I think I'll skip this one.

Overall it looks sensible (better than what we have now).  But
maintainers are funny things.  Parts of it will survive, others won't.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/