All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1213765922.25608.36.camel@ymzhang>

diff --git a/a/1.txt b/N1/1.txt
index cb3bf41..4a2186f 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -6,7 +6,7 @@ On Tue, 2008-06-17 at 20:37 -0700, David Miller wrote:
 > > This issue is caused by tcp defer accept. Mostly, process context calls lock_sock
 > > to apply a sleeping lock. BH (SoftIRQ) context calls bh_lock_sock(_nested) to just apply
 > > for the sk->sk_lock.slock without sleeping, then do appropriate processing based on
-> > if sk->sk_lock.owned=0. That works well if both process context and BH context operate
+> > if sk->sk_lock.owned==0. That works well if both process context and BH context operate
 > > the same sk at the same time. But with tcp defer accept, it doesn't, because
 > > process context(for example, in inet_csk_accept) locks the listen sk, while BH
 > > context (in tcp_v4_rcv, for example) locks the child sk and calls
diff --git a/a/content_digest b/N1/content_digest
index 1563d52..ca4fa13 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -2,8 +2,8 @@
  "ref\01213759663.25608.33.camel@ymzhang\0"
  "ref\020080617.203703.254889774.davem@davemloft.net\0"
  "From\0Zhang, Yanmin <yanmin_zhang@linux.intel.com>\0"
- "Subject\0Re: IPF Montvale machine panic when running a network-relevent\0"
- "Date\0Wed, 18 Jun 2008 05:12:02 +0000\0"
+ "Subject\0Re: IPF Montvale machine panic when running a network-relevent testing\0"
+ "Date\0Wed, 18 Jun 2008 13:12:02 +0800\0"
  "To\0David Miller <davem@davemloft.net>\0"
  "Cc\0netdev@vger.kernel.org"
   linux-kernel@vger.kernel.org
@@ -18,7 +18,7 @@
  "> > This issue is caused by tcp defer accept. Mostly, process context calls lock_sock\n"
  "> > to apply a sleeping lock. BH (SoftIRQ) context calls bh_lock_sock(_nested) to just apply\n"
  "> > for the sk->sk_lock.slock without sleeping, then do appropriate processing based on\n"
- "> > if sk->sk_lock.owned=0. That works well if both process context and BH context operate\n"
+ "> > if sk->sk_lock.owned==0. That works well if both process context and BH context operate\n"
  "> > the same sk at the same time. But with \357\273\277tcp defer accept, it doesn't, because\n"
  "> > process context(for example, in inet_csk_accept) locks the listen sk, while BH\n"
  "> > context (in tcp_v4_rcv, for example) locks the child sk and calls\n"
@@ -37,4 +37,4 @@
  "\n"
  -yanmin
 
-140814985eca0a320def00a75078a4dab5f361fa53141edef5baa1d9274bd2a8
+52b873b8930621885d9109fa7c648b2ef89c3d341405fa272bfdec0198e73267

diff --git a/a/1.txt b/N2/1.txt
index cb3bf41..471ed5c 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -6,7 +6,7 @@ On Tue, 2008-06-17 at 20:37 -0700, David Miller wrote:
 > > This issue is caused by tcp defer accept. Mostly, process context calls lock_sock
 > > to apply a sleeping lock. BH (SoftIRQ) context calls bh_lock_sock(_nested) to just apply
 > > for the sk->sk_lock.slock without sleeping, then do appropriate processing based on
-> > if sk->sk_lock.owned=0. That works well if both process context and BH context operate
+> > if sk->sk_lock.owned==0. That works well if both process context and BH context operate
 > > the same sk at the same time. But with tcp defer accept, it doesn't, because
 > > process context(for example, in inet_csk_accept) locks the listen sk, while BH
 > > context (in tcp_v4_rcv, for example) locks the child sk and calls
@@ -24,3 +24,9 @@ I happened to download git tree on June 16th, which includes the reverting patch
 I confirm it fixes the hang issue.
 
 -yanmin
+
+
+--
+To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
+the body of a message to majordomo@vger.kernel.org
+More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff --git a/a/content_digest b/N2/content_digest
index 1563d52..01e4b3f 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -2,8 +2,8 @@
  "ref\01213759663.25608.33.camel@ymzhang\0"
  "ref\020080617.203703.254889774.davem@davemloft.net\0"
  "From\0Zhang, Yanmin <yanmin_zhang@linux.intel.com>\0"
- "Subject\0Re: IPF Montvale machine panic when running a network-relevent\0"
- "Date\0Wed, 18 Jun 2008 05:12:02 +0000\0"
+ "Subject\0Re: IPF Montvale machine panic when running a network-relevent testing\0"
+ "Date\0Wed, 18 Jun 2008 13:12:02 +0800\0"
  "To\0David Miller <davem@davemloft.net>\0"
  "Cc\0netdev@vger.kernel.org"
   linux-kernel@vger.kernel.org
@@ -18,7 +18,7 @@
  "> > This issue is caused by tcp defer accept. Mostly, process context calls lock_sock\n"
  "> > to apply a sleeping lock. BH (SoftIRQ) context calls bh_lock_sock(_nested) to just apply\n"
  "> > for the sk->sk_lock.slock without sleeping, then do appropriate processing based on\n"
- "> > if sk->sk_lock.owned=0. That works well if both process context and BH context operate\n"
+ "> > if sk->sk_lock.owned==0. That works well if both process context and BH context operate\n"
  "> > the same sk at the same time. But with \357\273\277tcp defer accept, it doesn't, because\n"
  "> > process context(for example, in inet_csk_accept) locks the listen sk, while BH\n"
  "> > context (in tcp_v4_rcv, for example) locks the child sk and calls\n"
@@ -35,6 +35,12 @@
  "\n"
  "I confirm it fixes the hang issue.\n"
  "\n"
- -yanmin
+ "-yanmin\n"
+ "\n"
+ "\n"
+ "--\n"
+ "To unsubscribe from this list: send the line \"unsubscribe linux-ia64\" in\n"
+ "the body of a message to majordomo@vger.kernel.org\n"
+ More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
-140814985eca0a320def00a75078a4dab5f361fa53141edef5baa1d9274bd2a8
+44f09e46070561089295ea87c6dc52f352318e7fee537cab1b88ccc50314b86f

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.