linux-kernel - Re: [PATCH] hlist: drop the node parameter from iterators

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20130130162243.8137c424.akpm@linux-foundation.org>
Date:	Wed, 30 Jan 2013 16:22:43 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Sasha Levin <sasha.levin@...cle.com>
Cc:	torvalds@...ux-foundation.org,
	Peter Senna Tschudin <peter.senna@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] hlist: drop the node parameter from iterators

On Wed, 30 Jan 2013 19:09:49 -0500
Sasha Levin <sasha.levin@...cle.com> wrote:

> I would accept a "it's not worth the effort" if you think it's not worth
> the effort.

I don't recall ever saying that to anything, really.  Yes, there are
things which make small improvements at large effort costs, but if we
rule out an improvement just because it's a lot of work, we suck.

I'm particularly relaxed when all that effort is yours and Linus's :)

> If not, should I send it over to you on -rc1?

Probably that's the way to go, but there's no point in going via my
tree on this - put it straight into mainline and we'll have any adverse
fallout fixed up pretty soon afterwards.


But... how confident can we be that the code is correct?

I guess a bit of linux-next testing wouldn't hurt, however applying the
v2 patch to current linux-next is not pretty:

1 out of 3 hunks FAILED -- saving rejects to file arch/mips/kernel/kprobes.c.rej
4 out of 4 hunks FAILED -- saving rejects to file arch/x86/kernel/kprobes.c.rej
1 out of 3 hunks FAILED -- saving rejects to file block/blk-cgroup.c.rej
1 out of 2 hunks FAILED -- saving rejects to file block/cfq-iosched.c.rej
1 out of 1 hunk FAILED -- saving rejects to file block/elevator.c.rej
1 out of 17 hunks FAILED -- saving rejects to file drivers/clk/clk.c.rej
2 out of 2 hunks FAILED -- saving rejects to file drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c.rej
2 out of 2 hunks FAILED -- saving rejects to file drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c.rej
4 out of 4 hunks FAILED -- saving rejects to file kernel/cgroup.c.rej
6 out of 7 hunks FAILED -- saving rejects to file kernel/workqueue.c.rej
2 out of 8 hunks FAILED -- saving rejects to file net/batman-adv/bat_iv_ogm.c.rej
11 out of 23 hunks FAILED -- saving rejects to file net/batman-adv/bridge_loop_avoidance.c.rej
2 out of 15 hunks FAILED -- saving rejects to file net/batman-adv/originator.c.rej
1 out of 4 hunks FAILED -- saving rejects to file net/batman-adv/routing.c.rej
2 out of 3 hunks FAILED -- saving rejects to file net/batman-adv/send.c.rej
2 out of 38 hunks FAILED -- saving rejects to file net/batman-adv/translation-table.c.rej
4 out of 16 hunks FAILED -- saving rejects to file net/batman-adv/vis.c.rej
2 out of 6 hunks FAILED -- saving rejects to file net/ipv4/inet_connection_sock.c.rej
1 out of 2 hunks FAILED -- saving rejects to file net/ipv6/inet6_connection_sock.c.rej


Hum.  Perhaps to move this thing forward you could prepare a diff
against current linux-next and I'll see how painful it is to maintain
for a month?

--
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/