linux-kernel - Re: [PATCH] Fix numerous kcalloc() calls, convert to kzalloc().

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20061209143014.40051036.akpm@osdl.org>
Date:	Sat, 9 Dec 2006 14:30:14 -0800
From:	Andrew Morton <akpm@...l.org>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	"Robert P. J. Day" <rpjday@...dspring.com>,
	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Fix numerous kcalloc() calls, convert to kzalloc().

On Sat, 09 Dec 2006 23:05:58 +0100
Stefan Richter <stefanr@...6.in-berlin.de> wrote:

> >  fs/ocfs2/dlm/dlmrecovery.c          |    6 +++---
> >  fs/ocfs2/localalloc.c               |    2 +-
> >  fs/ocfs2/slot_map.c                 |    2 +-
> >  fs/ocfs2/suballoc.c                 |    6 +++---
> >  fs/ocfs2/super.c                    |    6 +++---
> >  fs/ocfs2/vote.c                     |    4 ++--
> >  include/linux/gameport.h            |    2 +-
> >  kernel/relay.c                      |    4 ++--
> >  net/sunrpc/svc.c                    |    2 +-
> >  sound/pci/hda/patch_realtek.c       |    4 ++--
> >  34 files changed, 91 insertions(+), 91 deletions(-)
> 
> This should really be split up and submitted separately. All the subsystems
> are constantly changing. Although merging these kinds of changes manually
> after eventual conflicts, it's still manual work for the maintainers which
> would be avoided by a little bit extra work by the submitter. A maintainer
> could get a merge conflict on a 100 lines long hunk because of an 8 lines
> long hunk that got upstream on a different route.

Well actually..  With a patch like this, if any hunk clashes with a subsystem
maintainer's tree I'll usually just drop that hunk, or I'll fix it up so
that it applies to the maintainer's devel tree and won't merge it until the
maintainer has merged with mainline.

Or, if the maintainer is being sluggish, I'll just drop the problematic hunk
and I'll merge the rest with Linus.

IOW, what I merge with Linus is that part of the patch which doesn't
conflict with any of the subsystem trees.

Of course, if your subsystem tree isn't in -mm then you lose.
-
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/