netdev - Re: [PATCH 02/14] net/fec: release mem_region requested in probe in error path and remove

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]

Date:	Mon, 14 Feb 2011 09:25:25 +0100
From:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, shawn.guo@...escale.com,
	kernel@...gutronix.de
Subject: Re: [PATCH 02/14] net/fec: release mem_region requested in probe
 in error path and remove

Hi David,

On Sun, Feb 13, 2011 at 01:15:31PM -0800, David Miller wrote:
> From: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
> Date: Sun, 13 Feb 2011 22:07:09 +0100
> > On Fri, Feb 11, 2011 at 09:25:32PM -0800, David Miller wrote:
> >> I can't pull from that tree because it is _NOT_ based upon net-next-2.6
> >> and therefore brings in all kinds of commits not related to your work.
> > Sorry, I'm not used to the customs on netdev.  I can rebase, but still I
> > wonder about the reason you cannot pull for.  The only reason I can
> > imagine is that you fear unrelated breakage when taking these patches
> > that are already in Linus' tree.  But if it's that, wouldn't it be great
> > the realize this breakage already now and not only during the next merge
> > window?
> 
> My trees only merge in Linus's tree when absolutely necessary,
> to resolve conflicts or similar.
You don't merge Linus' tree, you merge mine that just happen to be based
on a newer version of Linus' tree. I'm sure Linus won't yell on you for
that. He only objects to merge directly from his tree, because the
result for him is an "empty" merge.
 
> We don't bring in unrelated changes into my tree, just for the
> sake of doing so.
> 
> Otherwise Linus gets all of these ugly merge commits when he
> pulls from me, which are entirely unnecessary.
The result Linus gets if you pull my tree based on
v2.6.38-rc4-106-gd247852 (as it is now) is the same as if it were based
on v2.6.38-rc2-210-gc69b909 (which is the most recent commit net-next
currently bases on): my 14 patches and your merge commit. The reason for
that is that Linus already has the commits between
v2.6.38-rc2-210-gc69b909 and v2.6.38-rc4-106-gd247852. So this is really
only about when these commits enter *your* tree.

There are currently the following commits in Linus' tree that are used
by commits in net-next as parents:

	c56eb8fb6dccb83d9fe62fd4dc00c834de9bc470
	ff76015f3bdfbc482c723cb4f2559cef84d178ca (*)
	c753796769e4fb0cd813b6e5801b3c01f4681d4f
	0c21e3aaf6ae85bee804a325aa29c325209180fd (*)
	e92427b289d252cfbd4cb5282d92f4ce1a5bb1fb (*)
	1bae4ce27c9c90344f23c65ea6966c50ffeae2f5
	7cc2edb83447775a34ed3bf9d29d8295a434b523 (*)
	8f2771f2b85aea4d0f9a0137ad3b63d1173c0962 (*)
	c4c93106741bbf61ecd05a2a835af8e3bf31c1bd (*)
	c7c1806098752c1f46943d8db2c69aff07f5d4bc (*)
	479600777bb588724d044815415f7d708d06644b (*)
	1e6d93e45b231b3ae87c01902ede2315aacfe976 (*)
	9b00b4157f7b3265de291ac8979a5f1611ce64ab
	c69b90920a36b88ab0d649963d81355d865eeb05 (*)

and you don't want to take d247852 to this list because it's newer than
all these? How did you decide to take the newest in the list above and
why was that OK?
And as a last point let me note, that from Linus' POV the commits marked
with an asterisk above go into net-next by an empty merge. 
	
Can you please reping me if you still consider that I should rebase my
tree for you to be able to merge it?

Best regards and thanks
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html