* Re: [PATCH 1/6] bnx2: Fix excessive stack usage
From: Michael Chan @ 2005-05-24 4:29 UTC (permalink / raw)
To: Jeff Garzik; +Cc: davem, netdev
In-Reply-To: <429286A3.1060606@pobox.com>
On Mon, 2005-05-23 at 21:42 -0400, Jeff Garzik wrote:
>
> memleak -- you need to free good_mbuf.
>
Oops, here is the revised patch with kfree(). Thanks.
Fix excessive stack usage in bnx2_alloc_bad_rbuf() by replacing local
variable array with kmalloc array. Also changed function to return error
code, and changed some of the callers to check for the return code.
Spotted by Jeff Garzik.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff -Nru 10/drivers/net/bnx2.c 11/drivers/net/bnx2.c
--- 10/drivers/net/bnx2.c 2005-05-23 10:20:02.000000000 -0700
+++ 11/drivers/net/bnx2.c 2005-05-23 21:13:46.000000000 -0700
@@ -1138,13 +1138,20 @@
}
}
-static void
+static int
bnx2_alloc_bad_rbuf(struct bnx2 *bp)
{
- u16 good_mbuf[512];
+ u16 *good_mbuf;
u32 good_mbuf_cnt;
u32 val;
+ good_mbuf = kmalloc(512 * sizeof(u16), GFP_KERNEL);
+ if (good_mbuf == NULL) {
+ printk(KERN_ERR PFX "Failed to allocate memory in "
+ "bnx2_alloc_bad_rbuf\n");
+ return -ENOMEM;
+ }
+
REG_WR(bp, BNX2_MISC_ENABLE_SET_BITS,
BNX2_MISC_ENABLE_SET_BITS_RX_MBUF_ENABLE);
@@ -1178,6 +1185,8 @@
REG_WR_IND(bp, BNX2_RBUF_FW_BUF_FREE, val);
}
+ kfree(good_mbuf);
+ return 0;
}
static void
@@ -2710,7 +2719,7 @@
bnx2_reset_chip(struct bnx2 *bp, u32 reset_code)
{
u32 val;
- int i;
+ int i, rc = 0;
/* Wait for the current PCI transaction to complete before
* issuing a reset. */
@@ -2785,10 +2794,10 @@
REG_WR(bp, BNX2_MISC_VREG_CONTROL, 0x000000fa);
/* Remove bad rbuf memory from the free pool. */
- bnx2_alloc_bad_rbuf(bp);
+ rc = bnx2_alloc_bad_rbuf(bp);
}
- return 0;
+ return rc;
}
static int
@@ -3097,8 +3106,13 @@
static int
bnx2_reset_nic(struct bnx2 *bp, u32 reset_code)
{
- bnx2_reset_chip(bp, reset_code);
+ int rc;
+
+ rc = bnx2_reset_chip(bp, reset_code);
bnx2_free_skbs(bp);
+ if (rc)
+ return rc;
+
bnx2_init_chip(bp);
bnx2_init_tx_ring(bp);
bnx2_init_rx_ring(bp);
@@ -3108,7 +3122,11 @@
static int
bnx2_init_nic(struct bnx2 *bp)
{
- bnx2_reset_nic(bp, BNX2_DRV_MSG_CODE_RESET);
+ int rc;
+
+ if ((rc = bnx2_reset_nic(bp, BNX2_DRV_MSG_CODE_RESET)) != 0)
+ return rc;
+
bnx2_init_phy(bp);
bnx2_set_link(bp);
return 0;
^ permalink raw reply
* Re: [PATCH 1/6] bnx2: Fix excessive stack usage
From: Jeff Garzik @ 2005-05-24 5:43 UTC (permalink / raw)
To: Michael Chan; +Cc: davem, netdev
In-Reply-To: <1116908956.5984.4.camel@rh4>
Michael Chan wrote:
> On Mon, 2005-05-23 at 21:42 -0400, Jeff Garzik wrote:
>
>>memleak -- you need to free good_mbuf.
>>
>
>
> Oops, here is the revised patch with kfree(). Thanks.
>
> Fix excessive stack usage in bnx2_alloc_bad_rbuf() by replacing local
> variable array with kmalloc array. Also changed function to return error
> code, and changed some of the callers to check for the return code.
>
> Spotted by Jeff Garzik.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
ACK
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Linus Torvalds @ 2005-05-24 6:08 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, Netdev, Linux Kernel
In-Reply-To: <4292BA66.8070806@pobox.com>
On Tue, 24 May 2005, Jeff Garzik wrote:
> Please pull the 'for-linus' branch from
>
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
Is this really what you meant to do? There's seven merges there, none of
which have _any_ information about _what_ you merged, because you've mixed
everything up in one tree, so that there's absolutely no record of the
fact that you actually had seven different repositories that you pulled..
That sucks, Jeff.
I don't understand why you don't use different trees, like you did with
BK. You can share the object directory with the different trees, but the
way you work now, it all looks like mush.
Even if you don't get confused youself, you sure are confusing everybody
else with it..
Anyway, if you really want to work this way, with one big mushed-together
thing that has different heads that you keep track of, can you _please_ at
least make the commit message tell what you're doing. It's not a complex
script, and you're definitely mis-using it as things stand now by
switching heads around inside one repository, and not telling other people
about it.
--- side note ---
Also, the way you work, I think you actually may want to do a multi-parent
merge. That is, you may want to merge multiple parents in _one_ commit,
rather than having seven commits for it.
The way to do that is to just do "git-read-tree -m" (and the subsequent
merge) several times. You do not have to commit in between each step, you
just need to remember the parents, and then you do the final commit with
git-commit-tree $result_tree -p $head -p $p1 -p $p2 -p $p3 ...
ie you build up a commit command line that grows one more "-p xxxx" for
each parent you have merged. That requires a bit more work, but as it is,
your merges just look like crap.
--- end side note ----
Please?
Linus
----
commit fd3fac6ffe20bc6ca75b3ad38be0a8be6666b5d3
tree 49b4cfa6c95094612438b1ddeb0c9511a19125fe
parent c97f5a778ed33aef8f62496d7b82ba3cb896a587
parent b3dd65f958354226275522b5a64157834bdc5415
author <jgarzik@pretzel.yyz.us> Tue, 24 May 2005 00:47:58 -0400
committer Jeff Garzik <jgarzik@pobox.com> Tue, 24 May 2005 00:47:58 -0400
Automatic merge of /spare/repo/netdev-2.6/.git
commit c97f5a778ed33aef8f62496d7b82ba3cb896a587
tree c72dbed812b0ffa83700a1896895714248407daf
parent 09fc75b6757852798969e7585456499784a982e1
parent 1bcd315362e215a72b56d1330bbf32f1c74eefb5
author <jgarzik@pretzel.yyz.us> Tue, 24 May 2005 00:47:43 -0400
committer Jeff Garzik <jgarzik@pobox.com> Tue, 24 May 2005 00:47:43 -0400
Automatic merge of /spare/repo/netdev-2.6/.git
commit 09fc75b6757852798969e7585456499784a982e1
tree 60a2d2893cb757307edf0a0c450689610644cac2
parent b5545f2a2d915f5b6d86fb57e6ccc96b3010259e
parent ac79c82e793bc2440c4765e5eb1b834d2c18edf2
author <jgarzik@pretzel.yyz.us> Tue, 24 May 2005 00:47:28 -0400
committer Jeff Garzik <jgarzik@pobox.com> Tue, 24 May 2005 00:47:28 -0400
Automatic merge of /spare/repo/netdev-2.6/.git
commit b5545f2a2d915f5b6d86fb57e6ccc96b3010259e
tree 0ece2dd139d1fa4a6b0c5f61fc2be75692d0ea47
parent f180e742711ce512e62161436d166eb4df92b34d
parent 2648345fcbadfae8e7113112ff9402e465a184dc
author <jgarzik@pretzel.yyz.us> Tue, 24 May 2005 00:47:20 -0400
committer Jeff Garzik <jgarzik@pobox.com> Tue, 24 May 2005 00:47:20 -0400
Automatic merge of /spare/repo/netdev-2.6/.git
commit f180e742711ce512e62161436d166eb4df92b34d
tree 21fcfc0ca4a47776bc1182898d9b394529aa1daf
parent 7b5c2db59567052805771e1de2ad4e089b88c847
parent 042e2fb70006f135469d546726451b7d14768980
author <jgarzik@pretzel.yyz.us> Tue, 24 May 2005 00:47:12 -0400
committer Jeff Garzik <jgarzik@pobox.com> Tue, 24 May 2005 00:47:12 -0400
Automatic merge of /spare/repo/netdev-2.6/.git
commit 7b5c2db59567052805771e1de2ad4e089b88c847
tree d18dc44dcfd34a99ac11a83e6d324730784b7d81
parent 02dd6b49b3f75dacfa7eddf7f2faa8b810906e47
parent 9092f46b5aed4515d9a427d5dab3be1584851f07
author <jgarzik@pretzel.yyz.us> Tue, 24 May 2005 00:45:05 -0400
committer Jeff Garzik <jgarzik@pobox.com> Tue, 24 May 2005 00:45:05 -0400
Merge of /spare/repo/netdev-2.6/.git
commit 02dd6b49b3f75dacfa7eddf7f2faa8b810906e47
tree 240cfa2396a6ed006ee28f3848b4cceebfc35b11
parent 187a1a94d629621d1471b42308e63573b1150773
parent dfa1b73ffb414b64dc0452260132a090eb25bf52
author <jgarzik@pretzel.yyz.us> Tue, 24 May 2005 00:44:49 -0400
committer Jeff Garzik <jgarzik@pobox.com> Tue, 24 May 2005 00:44:49 -0400
Automatic merge of /spare/repo/netdev-2.6/.git
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Jeff Garzik @ 2005-05-24 6:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, Netdev, Linux Kernel
In-Reply-To: <Pine.LNX.4.58.0505232253160.2307@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Tue, 24 May 2005, Jeff Garzik wrote:
>
>
>>Please pull the 'for-linus' branch from
>>
>>rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
>
>
> Is this really what you meant to do? There's seven merges there, none of
> which have _any_ information about _what_ you merged, because you've mixed
> everything up in one tree, so that there's absolutely no record of the
> fact that you actually had seven different repositories that you pulled..
>
> That sucks, Jeff.
>
> I don't understand why you don't use different trees, like you did with
> BK. You can share the object directory with the different trees, but the
> way you work now, it all looks like mush.
>
> Even if you don't get confused youself, you sure are confusing everybody
> else with it..
You are getting precisely the same thing you got under BitKeeper: pull
from X, you get my tree, which was composed from $N repositories. The
tree you pull was created by my running 'bk pull' locally $N times.
Ultimately, you appear to be complaining about:
* your own git-pull-script, which doesn't record the $2 (branch)
argument in the commit message.
* the fact that my changelog includes the merge csets that were
present-but-invisible by my BitKeeper submissions. i.e. I lack a
shortlog that filters out merge csets.
> Anyway, if you really want to work this way, with one big mushed-together
> thing that has different heads that you keep track of, can you _please_ at
> least make the commit message tell what you're doing. It's not a complex
Hey, I didn't write git-pull-script, I just use it :)
> script, and you're definitely mis-using it as things stand now by
> switching heads around inside one repository, and not telling other people
> about it.
Switching heads around? It sounds like you did not pull from the branch
I mentioned. This is how git-pull-script pulls from a branch:
git-pull-script \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git\
refs/heads/for-linus
Jeff
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Jeff Garzik @ 2005-05-24 6:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, Netdev, Linux Kernel
In-Reply-To: <Pine.LNX.4.58.0505232253160.2307@ppc970.osdl.org>
Linus Torvalds wrote:
> I don't understand why you don't use different trees, like you did with
> BK. You can share the object directory with the different trees, but the
You really can't beat
cp .git/refs/heads/master .git/refs/heads/new-branch
as the fastest way to create a new branch off the tip.
Jeff
^ permalink raw reply
* Re: [PATCH] : bug fix in multipath drr code.
From: pravin b shelar @ 2005-05-24 6:46 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, David S. Miller
In-Reply-To: <20050523232224.GA25349@gondor.apana.org.au>
Herbert Xu wrote:
>On Mon, May 23, 2005 at 05:56:39PM +0530, pravin wrote:
>
>
>> /* if necessary and possible utilize the old alternative */
>>- if ((flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE) != 0 &&
>>- last_selection != NULL) {
>>- result = last_selection;
>>- *rp = result;
>>- return;
>>+ if ((flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE) != 0 ) {
>>+ struct rtable *last_result = last_selection;
>>+ if(last_result != NULL &&
>>+ multipath_comparekeys(&last_result->fl, flp)) {
>>+ *rp = last_result;
>>+ return;
>>+ }
>> }
>>
>>
>
>You don't need all this code. All you need to do is do
>result = last_selection before the if condition and then
>check result in the if condition instead of last_selection.
>
>The multipath_comparekeys isn't necessary either.
>
>
>
In concurrent invocations of drr_select_route() last_selection will
change to different route.
So in that case we can not use last_selection route on basis of
FLOWI_FLAG_MULTIPATHOLDROUTE flag only, since old
route might be totally different due another invocation of same function.
So, I think multipath_comparekeys is necessary.
Please correct me if I am wrong.
Regards,
Pravin.
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Linus Torvalds @ 2005-05-24 6:48 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, Netdev, Linux Kernel
In-Reply-To: <4292C8EF.3090307@pobox.com>
On Tue, 24 May 2005, Jeff Garzik wrote:
>
> You are getting precisely the same thing you got under BitKeeper: pull
> from X, you get my tree, which was composed from $N repositories. The
> tree you pull was created by my running 'bk pull' locally $N times.
No. Under BK, you had DIFFERENT TREES.
What does that mean? They had DIFFERENT NAMES.
Which meant that the commit message was MEANINGFUL.
> Ultimately, you appear to be complaining about:
>
> * your own git-pull-script, which doesn't record the $2 (branch)
> argument in the commit message.
Yes, because _my_ pull script is meant to work with the way _I_ have told
people (including you) they should work.
The fact that you mush everything up in one tree _despite_ me having told
you that isn't a good thing to do is the problem.
Git can technically do it, but then you shouldn't use my scripts, which
aren't written for that behaviour.
> Hey, I didn't write git-pull-script, I just use it :)
You don't use it, you MIS-use it. Which is what I'm complaining about.
> Switching heads around? It sounds like you did not pull from the branch
> I mentioned.
No, I pulled exactly from the head you mentioned.
In fact, go look at YOUR OWN changelog. And then compare that changelog to
the changelog you had when you used BK, and realize that IT IS NOT AT ALL
EQUIVALENT. You used to have valid changelogs, even for the merge heads.
You don't any more:
Automatic merge of /spare/repo/netdev-2.6/.git
Automatic merge of /spare/repo/netdev-2.6/.git
Automatic merge of /spare/repo/netdev-2.6/.git
Automatic merge of /spare/repo/netdev-2.6/.git
Merge of /spare/repo/netdev-2.6/.git
See a pattern?
Your BK usage was equivalent to having multiple GIT repositories.
Linus
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Linus Torvalds @ 2005-05-24 6:50 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, Netdev, Linux Kernel
In-Reply-To: <4292CB01.6090506@pobox.com>
On Tue, 24 May 2005, Jeff Garzik wrote:
>
> You really can't beat
>
> cp .git/refs/heads/master .git/refs/heads/new-branch
>
> as the fastest way to create a new branch off the tip.
So? It's the fastest, but it's also BROKEN. Exactly because the way you do
things, the merge messages are meaningless.
So fix your merge messages.
Linus
^ permalink raw reply
* Re: [PATCH] : bug fix in multipath drr code.
From: Herbert Xu @ 2005-05-24 7:11 UTC (permalink / raw)
To: pravin b shelar; +Cc: netdev, David S. Miller
In-Reply-To: <4292CDCE.2090600@calsoftinc.com>
On Tue, May 24, 2005 at 12:16:38PM +0530, pravin b shelar wrote:
>
> >The multipath_comparekeys isn't necessary either.
>
> In concurrent invocations of drr_select_route() last_selection will
> change to different route.
> So in that case we can not use last_selection route on basis of
> FLOWI_FLAG_MULTIPATHOLDROUTE flag only, since old
> route might be totally different due another invocation of same function.
> So, I think multipath_comparekeys is necessary.
Indeed. In fact this whole MULTIPATHOLDROUTE thing can't possibly
work at all. I'd suggest that it be removed.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [XFRM] Call dst_check() with appropriate cookie
From: Herbert Xu @ 2005-05-24 7:16 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ????; +Cc: davem, netdev
In-Reply-To: <20050524.124919.00464304.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki / ???? <yoshfuji@linux-ipv6.org> wrote:
> From: Kazunori Miyazawa <kazunori@miyazawa.org>
>
> [XFRM] Call dst_check() with appropriate cookie.
>
> This fixes infinite loop issue with IPv6 tunnel mode.
Can someone please tell me where this infinite loop is?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] [BRIDGE]
From: Catalin(ux aka Dino) BOIE @ 2005-05-24 7:29 UTC (permalink / raw)
To: netdev; +Cc: davem
[-- Attachment #1: Type: TEXT/PLAIN, Size: 384 bytes --]
Hello!
This patch set bridge device features using the common features of all
slaves. Also, it reacts to features change using ethtool on the slaves.
This patch depends on NETDEV_FEAT_CHANGE.patch.
David, please apply if it looks good.
Thank you.
Signed-off-by: Catalin BOIE <catab at umrella.ro>
---
Catalin(ux aka Dino) BOIE
catab at deuroconsult.ro
http://kernel.umbrella.ro/
[-- Attachment #2: Type: TEXT/PLAIN, Size: 2886 bytes --]
--- bridge1/net/bridge/br_private.h 2005-03-02 09:37:50.000000000 +0200
+++ linux/net/bridge/br_private.h 2005-05-23 11:11:22.000000000 +0300
@@ -27,6 +27,10 @@
#define BR_PORT_BITS 10
#define BR_MAX_PORTS (1<<BR_PORT_BITS)
+#define BR_FEAT_MASK (NETIF_F_SG \
+ | NETIF_F_FRAGLIST \
+ | NETIF_F_HIGHDMA | NETIF_F_TSO)
+
typedef struct bridge_id bridge_id;
typedef struct mac_addr mac_addr;
typedef __u16 port_id;
@@ -174,6 +178,7 @@ extern int br_add_if(struct net_bridge *
extern int br_del_if(struct net_bridge *br,
struct net_device *dev);
extern int br_min_mtu(const struct net_bridge *br);
+extern void br_features_recompute(struct net_bridge *br);
/* br_input.c */
extern int br_handle_frame_finish(struct sk_buff *skb);
--- bridge1/net/bridge/br_notify.c 2005-03-26 05:28:14.000000000 +0200
+++ linux/net/bridge/br_notify.c 2005-05-23 11:20:14.000000000 +0300
@@ -65,6 +65,10 @@ static int br_device_event(struct notifi
}
break;
+ case NETDEV_FEAT_CHANGE:
+ br_features_recompute(br);
+ break;
+
case NETDEV_DOWN:
if (br->dev->flags & IFF_UP)
br_stp_disable_port(p);
--- bridge1/net/bridge/br_device.c 2005-03-02 09:37:30.000000000 +0200
+++ linux/net/bridge/br_device.c 2005-05-20 08:53:37.000000000 +0300
@@ -107,4 +107,5 @@ void br_dev_setup(struct net_device *dev
dev->tx_queue_len = 0;
dev->set_mac_address = NULL;
dev->priv_flags = IFF_EBRIDGE;
+ dev->features = BR_FEAT_MASK | NETIF_F_NO_CSUM | NETIF_F_LLTX;
}
--- bridge1/net/bridge/br_if.c 2005-03-02 09:38:33.000000000 +0200
+++ linux/net/bridge/br_if.c 2005-05-20 09:18:29.000000000 +0300
@@ -314,6 +314,27 @@ int br_min_mtu(const struct net_bridge *
return mtu;
}
+/*
+ * If slave device (@dev) doesn't support special features,
+ * turn them off globally.
+ */
+void br_features_change(struct net_bridge *br, struct net_device *dev)
+{
+ br->dev->features &= dev->features | ~BR_FEAT_MASK;
+}
+
+/*
+ * Recomputes features using slave's features
+ */
+void br_features_recompute(struct net_bridge *br)
+{
+ struct net_bridge_port *p;
+
+ br->dev->features |= BR_FEAT_MASK;
+ list_for_each_entry(p, &br->port_list, list)
+ br_features_change(br, p->dev);
+}
+
/* called with RTNL */
int br_add_if(struct net_bridge *br, struct net_device *dev)
{
@@ -332,9 +353,10 @@ int br_add_if(struct net_bridge *br, str
if (IS_ERR(p = new_nbp(br, dev, br_initial_port_cost(dev))))
return PTR_ERR(p);
+ br_features_change(br, dev);
+
if ((err = br_fdb_insert(br, p, dev->dev_addr, 1)))
destroy_nbp(p);
-
else if ((err = br_sysfs_addif(p)))
del_nbp(p);
else {
@@ -368,6 +390,7 @@ int br_del_if(struct net_bridge *br, str
spin_lock_bh(&br->lock);
br_stp_recalculate_bridge_id(br);
+ br_features_recompute(br);
spin_unlock_bh(&br->lock);
return 0;
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Jeff Garzik @ 2005-05-24 7:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, Netdev, Linux Kernel
In-Reply-To: <Pine.LNX.4.58.0505232343260.2307@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Tue, 24 May 2005, Jeff Garzik wrote:
>
>>You are getting precisely the same thing you got under BitKeeper: pull
>>from X, you get my tree, which was composed from $N repositories. The
>>tree you pull was created by my running 'bk pull' locally $N times.
>
>
> No. Under BK, you had DIFFERENT TREES.
>
> What does that mean? They had DIFFERENT NAMES.
>
> Which meant that the commit message was MEANINGFUL.
Ok, I'll fix the commit message.
As for different trees, I'm afraid you've written something that is _too
useful_ to be used in that manner.
Git has brought with it a _major_ increase in my productivity because I
can now easily share ~50 branches with 50 different kernel hackers,
without spending all day running rsync. Suddenly my kernel development
is a whole lot more _open_ to the world, with a single "./push". And
it's awesome.
That wasn't possible before with BitKeeper, just due to sheer network
overhead of 50 trees. With BitKeeper, the _only_ thing that kernel
hackers and users could get from me is a mush tree with everything
merged into a big 'ALL' repository.
So I'll continue to be the oddball, because more people can work in
parallel with me that way. I'll just have to make sure the commit
messages look right to you.
Jeff
^ permalink raw reply
* Re: [XFRM] Call dst_check() with appropriate cookie
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-05-24 7:30 UTC (permalink / raw)
To: herbert; +Cc: davem, netdev, yoshfuji, kazunori
In-Reply-To: <E1DaTeW-00085B-00@gondolin.me.apana.org.au>
In article <E1DaTeW-00085B-00@gondolin.me.apana.org.au> (at Tue, 24 May 2005 17:16:36 +1000), Herbert Xu <herbert@gondor.apana.org.au> says:
> > This fixes infinite loop issue with IPv6 tunnel mode.
>
> Can someone please tell me where this infinite loop is?
Honestly speaking, we haven't tracked down deeply where it is,
but that patch is logically reauired and it definetely solves grave
"freeze" issue with ipv6 tunnel mode xfrm.
--yoshfuji
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Linus Torvalds @ 2005-05-24 7:46 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, Netdev, Linux Kernel
In-Reply-To: <4292D7E1.80601@pobox.com>
On Tue, 24 May 2005, Jeff Garzik wrote:
>
> Ok, I'll fix the commit message.
>
> As for different trees, I'm afraid you've written something that is _too
> useful_ to be used in that manner.
I really think you'll eventually confuse yourself terminally, but as long
as the commit messages end up being meaningful, your "mush everything
together" clearly is the thing that is going to perform best.
> Git has brought with it a _major_ increase in my productivity because I
> can now easily share ~50 branches with 50 different kernel hackers,
> without spending all day running rsync.
Hey, I'm happy it works for you, but are you sure those 50 other kernel
hackers aren't confused?
IOW, your work model is pretty extreme, and I'm much more worried about
mixing up trees by mistake than about the technical side of git per se.
That's also why I think it's important that the commit logs are
meaningful: they do end up containing the SHA1 key, so clearly "all the
information" is there, but if something gets mixed up, I'd like some human
to be able to eventualyl say "Aaahhh.. _that's_ where it got mixed up".
Linus
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: David Lang @ 2005-05-24 7:55 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linus Torvalds, Andrew Morton, Netdev, Linux Kernel
In-Reply-To: <4292D7E1.80601@pobox.com>
On Tue, 24 May 2005, Jeff Garzik wrote:
> Linus Torvalds wrote:
>>
>> On Tue, 24 May 2005, Jeff Garzik wrote:
>>
>>> You are getting precisely the same thing you got under BitKeeper: pull
>>> from X, you get my tree, which was composed from $N repositories. The
>>> tree you pull was created by my running 'bk pull' locally $N times.
>>
>>
>> No. Under BK, you had DIFFERENT TREES.
>>
>> What does that mean? They had DIFFERENT NAMES.
>>
>> Which meant that the commit message was MEANINGFUL.
>
> Ok, I'll fix the commit message.
>
> As for different trees, I'm afraid you've written something that is _too
> useful_ to be used in that manner.
>
> Git has brought with it a _major_ increase in my productivity because I can
> now easily share ~50 branches with 50 different kernel hackers, without
> spending all day running rsync. Suddenly my kernel development is a whole
> lot more _open_ to the world, with a single "./push". And it's awesome.
>
> That wasn't possible before with BitKeeper, just due to sheer network
> overhead of 50 trees. With BitKeeper, the _only_ thing that kernel hackers
> and users could get from me is a mush tree with everything merged into a big
> 'ALL' repository.
couldn't you just have your multiple 'trees' use the same object
repository directory (still a single group of files to push), but still
have your trees with different names? it would be just a little more then
the copy of the HEAD object (you'd have to change the name in it), but it
should be easily scriptable)
or is there a limit in git that I'm overlooking that would prohibit this?
David Lang
^ permalink raw reply
* Re: [XFRM] Call dst_check() with appropriate cookie
From: Herbert Xu @ 2005-05-24 8:11 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ?$B5HF#1QL@; +Cc: davem, netdev, kazunori
In-Reply-To: <20050524.163018.29919354.yoshfuji@linux-ipv6.org>
On Tue, May 24, 2005 at 04:30:18PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>
> Honestly speaking, we haven't tracked down deeply where it is,
> but that patch is logically reauired and it definetely solves grave
> "freeze" issue with ipv6 tunnel mode xfrm.
I'm happy with your patch as it is. However, I'd like us to track
this freeze down first because if it is caused by another bug then
this patch may make it harder to find it.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [XFRM] Call dst_check() with appropriate cookie
From: Herbert Xu @ 2005-05-24 8:20 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ?$B5HF#1QL@; +Cc: davem, netdev
In-Reply-To: <20050524.124919.00464304.yoshfuji@linux-ipv6.org>
On Tue, May 24, 2005 at 03:49:19AM +0000, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>
> diff -ruN linux-2.6.12-rc4-git7/net/ipv4/xfrm4_policy.c linux-2.6.12-rc4-git7-ipv6ipsec/net/ipv4/xfrm4_policy.c
> --- linux-2.6.12-rc4-git7/net/ipv4/xfrm4_policy.c 2005-05-24 00:15:27.000000000 +0900
> +++ linux-2.6.12-rc4-git7-ipv6ipsec/net/ipv4/xfrm4_policy.c 2005-05-24 00:20:29.000000000 +0900
> @@ -95,6 +95,7 @@
>
> xdst = (struct xfrm_dst *)dst1;
> xdst->route = &rt->u.dst;
> + xdst->route_cookie = 0;
>
> dst1->next = dst_prev;
> dst_prev = dst1;
> @@ -119,6 +120,7 @@
>
> dst_prev->child = &rt->u.dst;
> dst->path = &rt->u.dst;
> + ((struct xfrm_dst*)dst)->path_cookie = 0;
This isn't necessary since dst_alloc zeros the entire xfrm_dst entry.
> dst_prev->child = &rt->u.dst;
> dst->path = &rt->u.dst;
> + ((struct xfrm_dst*)dst)->path_cookie = rt->rt6i_node->fn_sernum;
Please add a space between xfrm_dst and the asterisk, i.e.
(struct xfrm_dst *)dst
Also, can rt6i_node be NULL?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [XFRM] Call dst_check() with appropriate cookie
From: Kazunori Miyazawa @ 2005-05-24 8:26 UTC (permalink / raw)
To: Herbert Xu; +Cc: YOSHIFUJI Hideaki / ????, davem, netdev
In-Reply-To: <E1DaTeW-00085B-00@gondolin.me.apana.org.au>
Hello,
Without our patch, the dst_check in xfrm_bundle_ok returns NULL
when it is IPv6 route, then xfrm_bundle_ok always fails.
xfrm_lookup calls xfrm_bundle_ok via stalbe_bundle so that
it goes to restart and recreate bundles.
But stale_bundle always fails. It results the infinite loop accordingly.
This bug only occurs on IPv6. IPv4 works correctly without the patch.
I can not show the evidence of the infinite loop
because the kernel freezes :-<
Herbert Xu wrote:
> YOSHIFUJI Hideaki / ???? <yoshfuji@linux-ipv6.org> wrote:
>
>>From: Kazunori Miyazawa <kazunori@miyazawa.org>
>>
>>[XFRM] Call dst_check() with appropriate cookie.
>>
>>This fixes infinite loop issue with IPv6 tunnel mode.
>
>
> Can someone please tell me where this infinite loop is?
>
> Thanks,
--
Kazunori Miyazawa
^ permalink raw reply
* Re: [XFRM] Call dst_check() with appropriate cookie
From: Herbert Xu @ 2005-05-24 8:34 UTC (permalink / raw)
To: Kazunori Miyazawa; +Cc: YOSHIFUJI Hideaki / ????, davem, netdev
In-Reply-To: <4292E53D.7030805@miyazawa.org>
On Tue, May 24, 2005 at 05:26:37PM +0900, Kazunori Miyazawa wrote:
>
> Without our patch, the dst_check in xfrm_bundle_ok returns NULL
> when it is IPv6 route, then xfrm_bundle_ok always fails.
> xfrm_lookup calls xfrm_bundle_ok via stalbe_bundle so that
> it goes to restart and recreate bundles.
> But stale_bundle always fails. It results the infinite loop accordingly.
Yes this makes perfect sense. However, I'd still like to know why I
have never seen it myself. Let me double-check my test setup.
Anyway, I'm happy with the patch apart from the comments I gave elsewhere
in this thread.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [XFRM] Call dst_check() with appropriate cookie
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-05-24 8:49 UTC (permalink / raw)
To: davem; +Cc: herbert, netdev, yoshfuji, kazunori
In-Reply-To: <20050524082021.GA31446@gondor.apana.org.au>
In article <20050524082021.GA31446@gondor.apana.org.au> (at Tue, 24 May 2005 18:20:21 +1000), Herbert Xu <herbert@gondor.apana.org.au> says:
> Also, can rt6i_node be NULL?
Good point. Here's updated patch.
-----------------
From: Kazunori Miyazawa <kazunori@miyazawa.org>
[XFRM] Call dst_check() with appropriate cookie
This fixes infinite loop issue with IPv6 tunnel mode.
Signed-off-by: Kazunori Miyazawa <kazunori@miyazawa.org>
Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Index: include/net/xfrm.h
===================================================================
--- 5b713315560487f8c288820b17061fe27016c2cc/include/net/xfrm.h (mode:100644)
+++ uncommitted/include/net/xfrm.h (mode:100644)
@@ -515,6 +515,8 @@
struct dst_entry *route;
u32 route_mtu_cached;
u32 child_mtu_cached;
+ u32 route_cookie;
+ u32 path_cookie;
};
static inline void xfrm_dst_destroy(struct xfrm_dst *xdst)
Index: net/ipv6/xfrm6_policy.c
===================================================================
--- 5b713315560487f8c288820b17061fe27016c2cc/net/ipv6/xfrm6_policy.c (mode:100644)
+++ uncommitted/net/ipv6/xfrm6_policy.c (mode:100644)
@@ -113,6 +113,8 @@
xdst = (struct xfrm_dst *)dst1;
xdst->route = &rt->u.dst;
+ if (rt->rt6i_node)
+ xdst->route_cookie = rt->rt6i_node->fn_sernum;
dst1->next = dst_prev;
dst_prev = dst1;
@@ -137,6 +139,8 @@
dst_prev->child = &rt->u.dst;
dst->path = &rt->u.dst;
+ if (rt->rt6i_node)
+ ((struct xfrm_dst *)dst)->path_cookie = rt->rt6i_node->fn_sernum;
*dst_p = dst;
dst = dst_prev;
Index: net/xfrm/xfrm_policy.c
===================================================================
--- 5b713315560487f8c288820b17061fe27016c2cc/net/xfrm/xfrm_policy.c (mode:100644)
+++ uncommitted/net/xfrm/xfrm_policy.c (mode:100644)
@@ -1136,7 +1136,7 @@
struct xfrm_dst *last;
u32 mtu;
- if (!dst_check(dst->path, 0) ||
+ if (!dst_check(dst->path, ((struct xfrm_dst *)dst)->path_cookie) ||
(dst->dev && !netif_running(dst->dev)))
return 0;
@@ -1156,7 +1156,7 @@
xdst->child_mtu_cached = mtu;
}
- if (!dst_check(xdst->route, 0))
+ if (!dst_check(xdst->route, xdst->route_cookie))
return 0;
mtu = dst_mtu(xdst->route);
if (xdst->route_mtu_cached != mtu) {
--
YOSHIFUJI Hideaki @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply
* (no subject)
From: root @ 2005-05-24 9:11 UTC (permalink / raw)
by smtp.nexlab.net (Postfix) with ESMTP id 69107FA5F
for <buffer@sniffo.org>; Tue, 24 May 2005 05:18:55 +0200 (CEST)
Received: from oss (localhost [127.0.0.1])
by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O2eUF3007815;
Mon, 23 May 2005 19:40:30 -0700
Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 19:39:10 -0700 (PDT)
Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168])
by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O2d3F3007472
for <netdev@oss.sgi.com>; Mon, 23 May 2005 19:39:07 -0700
Received: from localhost ([127.0.0.1] ident=davem)
by sunset.davemloft.net with esmtp (Exim 4.50)
id 1DaPJB-0000Zl-8x; Mon, 23 May 2005 19:38:17 -0700
Date: Mon, 23 May 2005 19:38:17 -0700 (PDT)
Message-Id: <20050523.193817.112290763.davem@davemloft.net>
To: herbert@gondor.apana.org.au
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH] Super TSO v3
From: "David S. Miller" <davem@davemloft.net>
In-Reply-To: <20050524023256.GA29242@gondor.apana.org.au>
References: <20050524003208.GA25778@gondor.apana.org.au>
<20050523.192917.48530622.davem@davemloft.net>
<20050524023256.GA29242@gondor.apana.org.au>
X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-archive-position: 1540
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-To: netdev-bounce@oss.sgi.com
X-original-sender: davem@davemloft.net
Precedence: bulk
X-list: netdev
X-Virus-Scanned: ClamAV 0.83/892/Mon May 23 10:52:19 2005 on oss.sgi.com
X-Virus-Status: Clean
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 24 May 2005 12:32:57 +1000
> True, the Nagle algorithm itself aims to do something different
> from this function. However, the act of turning Nagle off is
> an indication that the application wants to minimise the latency
> by sending things out ASAP. So we should either respect that
> here by not delaying the packets to increase the TSO size, or
> we'll need a new socket option to do that for TSO.
Sure, we can check tp->nonagle to turn this deferring off.
But, I bet there are folks who want traditional Nagle turned
off, yet TSO chunking enabled.
^ permalink raw reply
* (no subject)
From: root @ 2005-05-24 9:12 UTC (permalink / raw)
by smtp.nexlab.net (Postfix) with ESMTP id E2FB1F9E7
for <buffer@sniffo.org>; Tue, 24 May 2005 04:13:52 +0200 (CEST)
Received: from oss (localhost [127.0.0.1])
by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1kGF3003197;
Mon, 23 May 2005 18:46:16 -0700
Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 18:43:59 -0700 (PDT)
Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58])
by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1htF3002796
for <netdev@oss.sgi.com>; Mon, 23 May 2005 18:43:55 -0700
Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88])
by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux))
id 1DaORj-00017L-8S; Tue, 24 May 2005 01:43:04 +0000
Message-ID: <429286A3.1060606@pobox.com>
Date: Mon, 23 May 2005 21:42:59 -0400
From: Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Chan <mchan@broadcom.com>
Cc: davem@davemloft.net, netdev@oss.sgi.com
Subject: Re: [PATCH 1/6] bnx2: Fix excessive stack usage
References: <1116892439.4908.1.camel@rh4> <1116894307.4908.28.camel@rh4>
In-Reply-To: <1116894307.4908.28.camel@rh4>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-archive-position: 1536
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-To: netdev-bounce@oss.sgi.com
X-original-sender: jgarzik@pobox.com
Precedence: bulk
X-list: netdev
X-Virus-Scanned: ClamAV 0.83/892/Mon May 23 10:52:19 2005 on oss.sgi.com
X-Virus-Status: Clean
Michael Chan wrote:
> diff -Nru 10/drivers/net/bnx2.c 11/drivers/net/bnx2.c
> --- 10/drivers/net/bnx2.c 2005-05-23 10:20:02.000000000 -0700
> +++ 11/drivers/net/bnx2.c 2005-05-23 10:20:20.000000000 -0700
> @@ -1138,13 +1138,20 @@
> }
> }
>
> -static void
> +static int
> bnx2_alloc_bad_rbuf(struct bnx2 *bp)
> {
> - u16 good_mbuf[512];
> + u16 *good_mbuf;
> u32 good_mbuf_cnt;
> u32 val;
>
> + good_mbuf = kmalloc(512 * sizeof(u16), GFP_KERNEL);
> + if (good_mbuf == NULL) {
> + printk(KERN_ERR PFX "Failed to allocate memory in "
> + "bnx2_alloc_bad_rbuf\n");
> + return -ENOMEM;
> + }
> +
> REG_WR(bp, BNX2_MISC_ENABLE_SET_BITS,
> BNX2_MISC_ENABLE_SET_BITS_RX_MBUF_ENABLE);
>
> @@ -1178,6 +1185,7 @@
>
> REG_WR_IND(bp, BNX2_RBUF_FW_BUF_FREE, val);
> }
> + return 0;
> }
>
> static void
memleak -- you need to free good_mbuf.
Jeff
^ permalink raw reply
* (no subject)
From: root @ 2005-05-24 9:14 UTC (permalink / raw)
by smtp.nexlab.net (Postfix) with ESMTP id 1C84EFB6B
for <chiakotay@nexlab.it>; Tue, 24 May 2005 10:01:41 +0200 (CEST)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S261200AbVEXG0J (ORCPT <rfc822;chiakotay@nexlab.it>);
Tue, 24 May 2005 02:26:09 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261302AbVEXG0J
(ORCPT <rfc822;linux-kernel-outgoing>);
Tue, 24 May 2005 02:26:09 -0400
Received: from mail.dvmed.net ([216.237.124.58]:4813 "EHLO mail.dvmed.net")
by vger.kernel.org with ESMTP id S261200AbVEXGZ5 (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Tue, 24 May 2005 02:25:57 -0400
Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88])
by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux))
id 1DaSrU-0001Og-4d; Tue, 24 May 2005 06:25:56 +0000
Message-ID: <4292C8EF.3090307@pobox.com>
Date: Tue, 24 May 2005 02:25:51 -0400
From: Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Linus Torvalds <torvalds@osdl.org>
Cc: Andrew Morton <akpm@osdl.org>, Netdev <netdev@oss.sgi.com>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [git patches] 2.6.x net driver updates
References: <4292BA66.8070806@pobox.com> <Pine.LNX.4.58.0505232253160.2307@ppc970.osdl.org>
In-Reply-To: <Pine.LNX.4.58.0505232253160.2307@ppc970.osdl.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Linus Torvalds wrote:
>
> On Tue, 24 May 2005, Jeff Garzik wrote:
>
>
>>Please pull the 'for-linus' branch from
>>
>>rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
>
>
> Is this really what you meant to do? There's seven merges there, none of
> which have _any_ information about _what_ you merged, because you've mixed
> everything up in one tree, so that there's absolutely no record of the
> fact that you actually had seven different repositories that you pulled..
>
> That sucks, Jeff.
>
> I don't understand why you don't use different trees, like you did with
> BK. You can share the object directory with the different trees, but the
> way you work now, it all looks like mush.
>
> Even if you don't get confused youself, you sure are confusing everybody
> else with it..
You are getting precisely the same thing you got under BitKeeper: pull
from X, you get my tree, which was composed from $N repositories. The
tree you pull was created by my running 'bk pull' locally $N times.
Ultimately, you appear to be complaining about:
* your own git-pull-script, which doesn't record the $2 (branch)
argument in the commit message.
* the fact that my changelog includes the merge csets that were
present-but-invisible by my BitKeeper submissions. i.e. I lack a
shortlog that filters out merge csets.
> Anyway, if you really want to work this way, with one big mushed-together
> thing that has different heads that you keep track of, can you _please_ at
> least make the commit message tell what you're doing. It's not a complex
Hey, I didn't write git-pull-script, I just use it :)
> script, and you're definitely mis-using it as things stand now by
> switching heads around inside one repository, and not telling other people
> about it.
Switching heads around? It sounds like you did not pull from the branch
I mentioned. This is how git-pull-script pulls from a branch:
git-pull-script \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git\
refs/heads/for-linus
Jeff
^ permalink raw reply
* (no subject)
From: root @ 2005-05-24 9:15 UTC (permalink / raw)
by smtp.nexlab.net (Postfix) with ESMTP id 2366BFB72
for <chiakotay@nexlab.it>; Tue, 24 May 2005 10:01:46 +0200 (CEST)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S261334AbVEXGsu (ORCPT <rfc822;chiakotay@nexlab.it>);
Tue, 24 May 2005 02:48:50 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261362AbVEXGst
(ORCPT <rfc822;linux-kernel-outgoing>);
Tue, 24 May 2005 02:48:49 -0400
Received: from fire.osdl.org ([65.172.181.4]:20097 "EHLO smtp.osdl.org")
by vger.kernel.org with ESMTP id S261334AbVEXGsj (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Tue, 24 May 2005 02:48:39 -0400
Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6])
by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4O6mWjA025872
(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
Mon, 23 May 2005 23:48:32 -0700
Received: from localhost (shell0.pdx.osdl.net [10.9.0.31])
by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4O6mVWw012672;
Mon, 23 May 2005 23:48:31 -0700
Date: Mon, 23 May 2005 23:50:36 -0700 (PDT)
From: Linus Torvalds <torvalds@osdl.org>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Andrew Morton <akpm@osdl.org>, Netdev <netdev@oss.sgi.com>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [git patches] 2.6.x net driver updates
In-Reply-To: <4292CB01.6090506@pobox.com>
Message-ID: <Pine.LNX.4.58.0505232349020.2307@ppc970.osdl.org>
References: <4292BA66.8070806@pobox.com> <Pine.LNX.4.58.0505232253160.2307@ppc970.osdl.org>
<4292CB01.6090506@pobox.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Status: No, hits=0 required=5 tests=
X-Spam-Checker-Version: SpamAssassin 2.63-osdl_revision__1.40__
X-MIMEDefang-Filter: osdl$Revision: 1.109 $
X-Scanned-By: MIMEDefang 2.36
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
On Tue, 24 May 2005, Jeff Garzik wrote:
>
> You really can't beat
>
> cp .git/refs/heads/master .git/refs/heads/new-branch
>
> as the fastest way to create a new branch off the tip.
So? It's the fastest, but it's also BROKEN. Exactly because the way you do
things, the merge messages are meaningless.
So fix your merge messages.
Linus
^ permalink raw reply
* (no subject)
From: root @ 2005-05-24 9:16 UTC (permalink / raw)
by smtp.nexlab.net (Postfix) with ESMTP id 8C315FB6B
for <chiakotay@nexlab.it>; Tue, 24 May 2005 10:01:41 +0200 (CEST)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S261350AbVEXGeu (ORCPT <rfc822;chiakotay@nexlab.it>);
Tue, 24 May 2005 02:34:50 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261334AbVEXGeu
(ORCPT <rfc822;linux-kernel-outgoing>);
Tue, 24 May 2005 02:34:50 -0400
Received: from mail.dvmed.net ([216.237.124.58]:8141 "EHLO mail.dvmed.net")
by vger.kernel.org with ESMTP id S261353AbVEXGep (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Tue, 24 May 2005 02:34:45 -0400
Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88])
by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux))
id 1DaT00-0001Ow-FO; Tue, 24 May 2005 06:34:44 +0000
Message-ID: <4292CB01.6090506@pobox.com>
Date: Tue, 24 May 2005 02:34:41 -0400
From: Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Linus Torvalds <torvalds@osdl.org>
Cc: Andrew Morton <akpm@osdl.org>, Netdev <netdev@oss.sgi.com>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [git patches] 2.6.x net driver updates
References: <4292BA66.8070806@pobox.com> <Pine.LNX.4.58.0505232253160.2307@ppc970.osdl.org>
In-Reply-To: <Pine.LNX.4.58.0505232253160.2307@ppc970.osdl.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Linus Torvalds wrote:
> I don't understand why you don't use different trees, like you did with
> BK. You can share the object directory with the different trees, but the
You really can't beat
cp .git/refs/heads/master .git/refs/heads/new-branch
as the fastest way to create a new branch off the tip.
Jeff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox