Re: [WIP RFC 5/5] upload-pack: send part of packfile response as uri

[Stefan Beller]

On Mon, Dec 3, 2018 at 3:38 PM Jonathan Tan  wrote:
>
> This is a partial implementation of upload-pack sending part of its
> packfile response as URIs.

It does so by implementing a new flag `--exclude-configured-blobs`
in pack-objects, which would change the output of pack-objects to
output a list of URLs (of the excluded blobs) followed by the
pack to be asked for.

This design seems easy to implement as then upload-pack
can just parse the output and only needs to insert
"packfile" and "packfile-uris\n" at the appropriate places
of the stream, otherwise it just passes through the information
obtained from pack-objects.

The design as-is would make for hard documentation of
pack-objects (its output is not just a pack anymore when that
flag is given, but a highly optimized byte stream).

Initially I did not anticipate this to be one of the major design problems
as I assumed we'd want to use this pack feature over broadly (e.g.
eventually by offloading most of the objects into a base pack that
is just always included as the likelihood for any object in there is
very high on initial clone), but it makes total sense to only
output the URIs that we actually need.

An alternative that comes very close to the current situation
would be to either pass a file path or file descriptor (that upload-pack
listens to in parallel) to pack-objects as an argument of the new flag.
Then we would not need to splice the protocol sections into the single
output stream, but we could announce the sections, then flush
the URIs and then flush the pack afterwards.

I looked at this quickly, but that would need either extensions in
run-command.c for setting up the new fd for us, as there we already
have OS specific code for these setups, or we'd have to duplicate
some of the logic here, which doesn't enthuse me either.

So maybe we'd create a temp file via mkstemp and pass
the file name to pack-objects for writing the URIs and then
we'd just need to stream that file?

> +   # NEEDSWORK: "git clone" fails here because it ignores the URI 
> provided
> +   # instead of fetching it.
> +   test_must_fail env GIT_TRACE_PACKET="$(pwd)/log" \
> +   git -c protocol.version=2 clone \
> +   "$HTTPD_URL/smart/http_parent" http_child 2>err &&
> +   # Although "git clone" fails, we can still check that the server
> +   # provided the URI we requested and that the error message pinpoints
> +   # the object that is missing.
> +   grep "clone< uri https://example.com/a-uri; log &&
> +   test_i18ngrep "did not receive expected object $(cat h)" err

That is a nice test!

Re: [WIP RFC 0/5] Design for offloading part of packfile response to CDN

[Stefan Beller]

On Mon, Dec 3, 2018 at 3:37 PM Jonathan Tan  wrote:

>
> There is a potential issue: a server which produces both the URIs and
> the packfile at roughly the same time (like the implementation in this
> patch set) will not have sideband access until it has concluded sending
> the URIs. Among other things, this means that the server cannot send
> keepalive packets until quite late in the response. One solution to this
> might be to add a feature that allows the server to use a sideband
> throughout the whole response - and this has other benefits too like
> allowing servers to inform the client throughout the whole fetch, not
> just at the end.

While side band sounds like the right thing to do, we could also
sending (NULL)-URIs within this feature.

[WIP RFC 0/5] Design for offloading part of packfile response to CDN

[Jonathan Tan]

Some of us have been working on a design to improve the scalability of
Git servers by allowing them to offload part of the packfile response to
CDNs in this way: returning HTTP(S) URIs in fetch responses in addition
to packfiles.

This can reduce the load on individual Git servers and improves
proximity (by having data served from closer to the user).

I have included here a design document (patch 2) and a rough
implementation of the server (patch 5). Currently, the implementation
only allows replacing single blobs with URIs, but the protocol
improvement is designed in such a way as to allow independent
improvement of Git server implementations.

There is a potential issue: a server which produces both the URIs and
the packfile at roughly the same time (like the implementation in this
patch set) will not have sideband access until it has concluded sending
the URIs. Among other things, this means that the server cannot send
keepalive packets until quite late in the response. One solution to this
might be to add a feature that allows the server to use a sideband
throughout the whole response - and this has other benefits too like
allowing servers to inform the client throughout the whole fetch, not
just at the end.

Jonathan Tan (5):
  Documentation: order protocol v2 sections
  Documentation: add Packfile URIs design doc
  upload-pack: refactor reading of pack-objects out
  upload-pack: refactor writing of "packfile" line
  upload-pack: send part of packfile response as uri

 Documentation/technical/packfile-uri.txt |  83 +
 Documentation/technical/protocol-v2.txt  |  22 ++--
 builtin/pack-objects.c   |  48 
 fetch-pack.c |   9 ++
 t/t5702-protocol-v2.sh   |  25 
 upload-pack.c| 150 ---
 6 files changed, 285 insertions(+), 52 deletions(-)
 create mode 100644 Documentation/technical/packfile-uri.txt

-- 
2.19.0.271.gfe8321ec05.dirty

[WIP RFC 5/5] upload-pack: send part of packfile response as uri

[Jonathan Tan]

This is a partial implementation of upload-pack sending part of its
packfile response as URIs.

The client is not fully implemented - it knows to ignore the
"packfile-uris" section, but because it does not actually fetch those
URIs, the returned packfile is incomplete. A test is included to show
that the appropriate URI is indeed transmitted, and that the returned
packfile is lacking exactly the expected object.

Signed-off-by: Jonathan Tan 
---
 builtin/pack-objects.c | 48 ++
 fetch-pack.c   |  9 
 t/t5702-protocol-v2.sh | 25 ++
 upload-pack.c  | 37 
 4 files changed, 115 insertions(+), 4 deletions(-)

diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index e7ea206c08..2abbddd3cb 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -117,6 +117,15 @@ enum missing_action {
 static enum missing_action arg_missing_action;
 static show_object_fn fn_show_object;
 
+struct configured_exclusion {
+   struct oidmap_entry e;
+   char *uri;
+};
+static struct oidmap configured_exclusions;
+
+static int exclude_configured_blobs;
+static struct oidset excluded_by_config;
+
 /*
  * stats
  */
@@ -831,6 +840,23 @@ static off_t write_reused_pack(struct hashfile *f)
return reuse_packfile_offset - sizeof(struct pack_header);
 }
 
+static void write_excluded_by_configs(void)
+{
+   struct oidset_iter iter;
+   const struct object_id *oid;
+
+   oidset_iter_init(_by_config, );
+   while ((oid = oidset_iter_next())) {
+   struct configured_exclusion *ex =
+   oidmap_get(_exclusions, oid);
+
+   if (!ex)
+   BUG("configured exclusion wasn't configured");
+   write_in_full(1, ex->uri, strlen(ex->uri));
+   write_in_full(1, "\n", 1);
+   }
+}
+
 static const char no_split_warning[] = N_(
 "disabling bitmap writing, packs are split due to pack.packSizeLimit"
 );
@@ -1124,6 +1150,12 @@ static int want_object_in_pack(const struct object_id 
*oid,
}
}
 
+   if (exclude_configured_blobs &&
+   oidmap_get(_exclusions, oid)) {
+   oidset_insert(_by_config, oid);
+   return 0;
+   }
+
return 1;
 }
 
@@ -2728,6 +2760,19 @@ static int git_pack_config(const char *k, const char *v, 
void *cb)
pack_idx_opts.version);
return 0;
}
+   if (!strcmp(k, "uploadpack.blobpackfileuri")) {
+   struct configured_exclusion *ex = xmalloc(sizeof(*ex));
+   const char *end;
+
+   if (parse_oid_hex(v, >e.oid, ) || *end != ' ')
+   die(_("value of uploadpack.blobpackfileuri must be "
+ "of the form ' ' (got '%s')"), v);
+   if (oidmap_get(_exclusions, >e.oid))
+   die(_("object already configured in another "
+ "uploadpack.blobpackfileuri (got '%s')"), v);
+   ex->uri = xstrdup(end + 1);
+   oidmap_put(_exclusions, ex);
+   }
return git_default_config(k, v, cb);
 }
 
@@ -3314,6 +3359,8 @@ int cmd_pack_objects(int argc, const char **argv, const 
char *prefix)
 N_("do not pack objects in promisor packfiles")),
OPT_BOOL(0, "delta-islands", _delta_islands,
 N_("respect islands during delta compression")),
+   OPT_BOOL(0, "exclude-configured-blobs", 
_configured_blobs,
+N_("respect uploadpack.blobpackfileuri")),
OPT_END(),
};
 
@@ -3487,6 +3534,7 @@ int cmd_pack_objects(int argc, const char **argv, const 
char *prefix)
return 0;
if (nr_result)
prepare_pack(window, depth);
+   write_excluded_by_configs();
write_pack_file();
if (progress)
fprintf_ln(stderr,
diff --git a/fetch-pack.c b/fetch-pack.c
index 9691046e64..6e1985ab55 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -1413,6 +1413,15 @@ static struct ref *do_fetch_pack_v2(struct 
fetch_pack_args *args,
receive_wanted_refs(, sought, nr_sought);
 
/* get the pack */
+   if (process_section_header(, "packfile-uris", 
1)) {
+   /* skip the whole section */
+   process_section_header(, 
"packfile-uris", 0);
+   while (packet_reader_read() == 
PACKET_READ_NORMAL) {
+   /* do nothing */
+   }
+   if (read

Re: Parsing a git HTTP protocol response

[Bryan Turner]

On Fri, Nov 30, 2018 at 6:58 PM Bryan Turner  wrote:
>
> Here's a (very ugly) patch I threw together on top of your code:
...snip

Gmail butchered my patch, so here it is as an attachment.

Bryan


short-size-reads.patch
Description: Binary data

Re: Parsing a git HTTP protocol response

[Bryan Turner]

On Fri, Nov 30, 2018 at 5:05 PM Farhan Khan  wrote:
>
> Hi all,
>
> I am writing an implementation of the git HTTP pack protocol in C. It
> just does a request to clone a repository. It works pretty well for
> small repositories, but seems to fail on larger repositories and I do
> not understand why.
>
> All that my code does is send a hard-coded "want" request. As I
> understand it, responses come with a four-byte size prefix, then the
> data of the size - 4. The first four bytes are the size of the object
> in ASCII and after that size, a new object should begin by specifying
> its size. The final "" string should signify the end.
>
> On small repositories my code works fine. But when use a large git
> repository, I hit an object size that cannot be interpreted by ASCII
> into a number. In particular, right before the crash I am pretty
> consistently getting a size starting with 0x32,0x00 or 0x32,0x30,0x00
> (note, it starts with 0x32 and has 0x00 in there). This is not a
> readable four byte ascii value, likely an erroneous size value, which
> causes the next object size calculation to land incorrectly and
> subsequently the program to malfunction.
>
> My questions:
> 1. Am I misunderstanding the protocol?
> 2. Does 0x32 signify something?
> 3. Also, where can I see in the source code git parses the data it
> receives from a "want" request?
>
> If you would like to see my code, it is located here:
> http://git.farhan.codes/farhan/post
> To compile to Linux run: gcc post.c main.c -lcurl -o post
> To compile on FreeBSD you can use the Makefile or: cc -L
> /usr/local/lib -I /usr/local/include -lcurl main.c post.c -o post
> In both cases you need to have libcurl installed.
>
> To run do: ./post [a git http url] [a commit value]
> ie: ./post http://git.farhan.codes/farhan/openbsd
> 373dd5ba116d42cddf1fdcb58b578a4274f6d589
>
> I have a lot of debugging printf() messages, but it eventually hits a
> point where you see this:
>
> Start=
> Current stats: Current state: 999 Received: 1448
> We have enough bytes, moving forward
> == New Object
> No Error, object is 32 bytes
> Size bytes: 32 30 00 00

I modified your debugging output a little bit, and right before the
failure happens I see this in my output:

Start=
Current stats: Current state: 999 Received: 1298
Read complete; still missing 1296 bytes (6901 read of 8197)
Offset: 1298

Start=
Current stats: Current state: 999 Received: 1298
Read complete; 2 more bytes in buffer
== New Object
Size bytes: 32 30 00 2b

Based on that, it appears what's happening is you're not handling the
case where you end up with fewer than 4 bytes in the buffer. As a
result, memcpy reads past the end of the response buffer and gets
whatever it gets, resulting in an incorrect parsed size.

The while loop in pack_protocol_line is checking +1, but I think it
should be checking +3 to ensure there's at least 4 bytes so it can get
a complete size. The "parseread" struct will need to grow a couple
more fields to allow buffering some additional bytes between
pack_protocol_line calls (because curl requires the write function to
always consume the full buffer) and, at the start of the loop, when
reading/parsing a size, the code will need to consider any buffered
bytes from the previous function call. That requires some knock-on
changes to how the offset is handled, as well as the the initial
"psize" set when starting a new packet.

Once you start accounting for reads that cut off in 1, 2 or 3 bytes
into the 4 required to parse a size, your program should be able to
run to completion.

Here's a (very ugly) patch I threw together on top of your code:

diff --git a/main.c b/main.c
index 956362b..8873fd5 100644
--- a/main.c
+++ b/main.c
@@ -71,7 +71,7 @@ int main(int argc, char *argv[]) {
  curl_easy_setopt(curl, CURLOPT_HTTPHEADER, list);
  curl_easy_setopt(curl, CURLOPT_POSTFIELDSIZE, (long)content_length);
  curl_easy_setopt(curl, CURLOPT_WRITEDATA, );
- curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, pack_protocol_line);
+ curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, _protocol_line);

  res = curl_easy_perform(curl);
  if (curl != CURLE_OK)
diff --git a/post.c b/post.c
index cfffd5c..4f8512c 100644
--- a/post.c
+++ b/post.c
@@ -36,89 +36,83 @@ size_t pack_protocol_line(void *buffer, size_t
size, size_t nmemb, void *userp)
 {
  unsigned char *reply = buffer;
  struct parseread *parseread = userp;
- int offset = 0;
+ int offset = 0, pending = 0, remaining = 0;
  char tmp[5];
- int check;
-
- int pool = size * nmemb;

  printf("\n\nStart=\n");
- printf("Current stats: Current state: %d Received: %ld\n",
parseread->state, size*nmemb);
+ printf("Current stats: Current state: %d Received: %ld\n",
parseread

Parsing a git HTTP protocol response

[Farhan Khan]

Hi all,

I am writing an implementation of the git HTTP pack protocol in C. It
just does a request to clone a repository. It works pretty well for
small repositories, but seems to fail on larger repositories and I do
not understand why.

All that my code does is send a hard-coded "want" request. As I
understand it, responses come with a four-byte size prefix, then the
data of the size - 4. The first four bytes are the size of the object
in ASCII and after that size, a new object should begin by specifying
its size. The final "" string should signify the end.

On small repositories my code works fine. But when use a large git
repository, I hit an object size that cannot be interpreted by ASCII
into a number. In particular, right before the crash I am pretty
consistently getting a size starting with 0x32,0x00 or 0x32,0x30,0x00
(note, it starts with 0x32 and has 0x00 in there). This is not a
readable four byte ascii value, likely an erroneous size value, which
causes the next object size calculation to land incorrectly and
subsequently the program to malfunction.

My questions:
1. Am I misunderstanding the protocol?
2. Does 0x32 signify something?
3. Also, where can I see in the source code git parses the data it
receives from a "want" request?

If you would like to see my code, it is located here:
http://git.farhan.codes/farhan/post
To compile to Linux run: gcc post.c main.c -lcurl -o post
To compile on FreeBSD you can use the Makefile or: cc -L
/usr/local/lib -I /usr/local/include -lcurl main.c post.c -o post
In both cases you need to have libcurl installed.

To run do: ./post [a git http url] [a commit value]
ie: ./post http://git.farhan.codes/farhan/openbsd
373dd5ba116d42cddf1fdcb58b578a4274f6d589

I have a lot of debugging printf() messages, but it eventually hits a
point where you see this:

Start=
Current stats: Current state: 999 Received: 1448
We have enough bytes, moving forward
== New Object
No Error, object is 32 bytes
Size bytes: 32 30 00 00

The program interprets the size of {0x32,0x30,0x00,0x00} to be "20"
which in decimal is 32, causing the next read to fail.
This problem repeats on a few different repositories.

Any assistance is welcome, I am very stuck on how the HTTP git protocol works.
Thanks,
--
Farhan Khan
PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE

[Spam]Quick Response

[Annable Katherine Grosvenor]

Good day,

My name is Annable Katherine Grosvenor, I'm 57yrs old, a widow, no kids, from 
the United Kingdom, I'm very sorry to bother you with this message but it is 
very important for me that I send out this message because I am very sick and 
at the point of death, I'm diagnosed with Ovarian Cancer and from all 
indications, I will not survive it because my Doctor courageously told me that 
I have few months to live, and also I can see that my health is fast 
deteriorating, the aggression of cancer has reached a critical stage.

I'm contacting you from my sick bed with the help of my personal nurse, I need 
a trustworthy, Godfearing and a reliable person I can bank on to carry out my 
last wish for me which is also the wish of my late husband, I have a 
humanitarian project worth three million, five hundred thousand dollars only, 
if you promise to help me accomplish this my last dying wish to the Glory of 
God and humanity, I will give you thirty percent of the total sum.

For further Enquiry about my mail to you pls kindly get back to me on my 
private email address so I can give you further details on how to go about this

Thank you very much for taking out time to read my message to you.

Yours Truly,
Annable Katherine Grosvenor
annablekatherinegrosve...@gmail.com

Re: [PATCH] fetch-pack: be more precise in parsing v2 response

[Stefan Beller]

On Thu, Oct 25, 2018 at 2:04 AM Junio C Hamano  wrote:
>
> Junio C Hamano  writes:
>
> > Jonathan Tan  writes:
> >
> >> +GIT_TRACE_PACKET="$(pwd)/log" test_must_fail git -C http_child \
> >> +-c protocol.version=2 \
> >> +fetch "$HTTPD_URL/one_time_sed/http_parent" 2> err &&
> >
> > Because test_must_fail is a shell function, the above is not a
> > correct way to say "I want GIT_TRACE_PACKET exported only while this
> > thing runs".
> >
> > I'll squash the following in.
> >
> >  t/t5702-protocol-v2.sh | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/t/t5702-protocol-v2.sh b/t/t5702-protocol-v2.sh
> > index 51009ca391..d58fbfa9e5 100755
> > --- a/t/t5702-protocol-v2.sh
> > +++ b/t/t5702-protocol-v2.sh
> > @@ -555,7 +555,7 @@ test_expect_success 'when server does not send "ready", 
> > expect FLUSH' '
> >   printf "/acknowledgments/,$ s//0001/" \
> >   >"$HTTPD_ROOT_PATH/one-time-sed" &&
> >
> > - GIT_TRACE_PACKET="$(pwd)/log" test_must_fail git -C http_child \
> > + test_must_fail env GIT_TRACE_PACKET="$(pwd)/log" git -C http_child \
> >   -c protocol.version=2 \
> >   fetch "$HTTPD_URL/one_time_sed/http_parent" 2> err &&
> >   grep "fetch< acknowledgments" log &&
>
> I know it only has been a few days, but is there any other issue
> in the patch, anybody?

I have reviewed the patch and I think it is good with the squashed change above.

Thanks,
Stefan

Re: [PATCH] fetch-pack: be more precise in parsing v2 response

[Junio C Hamano]

Junio C Hamano  writes:

> Jonathan Tan  writes:
>
>> +GIT_TRACE_PACKET="$(pwd)/log" test_must_fail git -C http_child \
>> +-c protocol.version=2 \
>> +fetch "$HTTPD_URL/one_time_sed/http_parent" 2> err &&
>
> Because test_must_fail is a shell function, the above is not a
> correct way to say "I want GIT_TRACE_PACKET exported only while this
> thing runs".
>
> I'll squash the following in.
>
>  t/t5702-protocol-v2.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t5702-protocol-v2.sh b/t/t5702-protocol-v2.sh
> index 51009ca391..d58fbfa9e5 100755
> --- a/t/t5702-protocol-v2.sh
> +++ b/t/t5702-protocol-v2.sh
> @@ -555,7 +555,7 @@ test_expect_success 'when server does not send "ready", 
> expect FLUSH' '
>   printf "/acknowledgments/,$ s//0001/" \
>   >"$HTTPD_ROOT_PATH/one-time-sed" &&
>  
> - GIT_TRACE_PACKET="$(pwd)/log" test_must_fail git -C http_child \
> + test_must_fail env GIT_TRACE_PACKET="$(pwd)/log" git -C http_child \
>   -c protocol.version=2 \
>   fetch "$HTTPD_URL/one_time_sed/http_parent" 2> err &&
>   grep "fetch< acknowledgments" log &&

I know it only has been a few days, but is there any other issue
in the patch, anybody?

Otherwise, I am wondering if we can move this forwared after
squashing the above fix in.

Thanks.

Re: [PATCH] fetch-pack: be more precise in parsing v2 response

[Junio C Hamano]

Jonathan Tan  writes:

> + GIT_TRACE_PACKET="$(pwd)/log" test_must_fail git -C http_child \
> + -c protocol.version=2 \
> + fetch "$HTTPD_URL/one_time_sed/http_parent" 2> err &&

Because test_must_fail is a shell function, the above is not a
correct way to say "I want GIT_TRACE_PACKET exported only while this
thing runs".

I'll squash the following in.

 t/t5702-protocol-v2.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t5702-protocol-v2.sh b/t/t5702-protocol-v2.sh
index 51009ca391..d58fbfa9e5 100755
--- a/t/t5702-protocol-v2.sh
+++ b/t/t5702-protocol-v2.sh
@@ -555,7 +555,7 @@ test_expect_success 'when server does not send "ready", 
expect FLUSH' '
printf "/acknowledgments/,$ s//0001/" \
>"$HTTPD_ROOT_PATH/one-time-sed" &&
 
-   GIT_TRACE_PACKET="$(pwd)/log" test_must_fail git -C http_child \
+   test_must_fail env GIT_TRACE_PACKET="$(pwd)/log" git -C http_child \
-c protocol.version=2 \
fetch "$HTTPD_URL/one_time_sed/http_parent" 2> err &&
grep "fetch< acknowledgments" log &&

[PATCH] fetch-pack: be more precise in parsing v2 response

[Jonathan Tan]

Each section in a protocol v2 response is followed by either a DELIM
packet (indicating more sections to follow) or a FLUSH packet
(indicating none to follow). But when parsing the "acknowledgments"
section, do_fetch_pack_v2() is liberal in accepting both, but determines
whether to continue reading or not based solely on the contents of the
"acknowledgments" section, not on whether DELIM or FLUSH was read.

There is no issue with a protocol-compliant server, but can result in
confusing error messages when communicating with a server that
serves unexpected additional sections. Consider a server that sends
"new-section" after "acknowledgments":

 - client writes request
 - client reads the "acknowledgments" section which contains no "ready",
   then DELIM
 - since there was no "ready", client needs to continue negotiation, and
   writes request
 - client reads "new-section", and reports to the end user "expected
   'acknowledgments', received 'new-section'"

For the person debugging the involved Git implementation(s), the error
message is confusing in that "new-section" was not received in response
to the latest request, but to the first one.

One solution is to always continue reading after DELIM, but in this
case, we can do better. We know from the protocol that "ready" means at
least the packfile section is coming (hence, DELIM) and that no "ready"
means that no sections are to follow (hence, FLUSH). So teach
process_acks() to enforce this.

Signed-off-by: Jonathan Tan 
---
 fetch-pack.c   | 12 ++
 t/t5702-protocol-v2.sh | 50 ++
 2 files changed, 62 insertions(+)

diff --git a/fetch-pack.c b/fetch-pack.c
index b3ed7121bc..9691046e64 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -1248,6 +1248,18 @@ static int process_acks(struct fetch_negotiator 
*negotiator,
reader->status != PACKET_READ_DELIM)
die(_("error processing acks: %d"), reader->status);
 
+   /*
+* If an "acknowledgments" section is sent, a packfile is sent if and
+* only if "ready" was sent in this section. The other sections
+* ("shallow-info" and "wanted-refs") are sent only if a packfile is
+* sent. Therefore, a DELIM is expected if "ready" is sent, and a FLUSH
+* otherwise.
+*/
+   if (received_ready && reader->status != PACKET_READ_DELIM)
+   die(_("expected packfile to be sent after 'ready'"));
+   if (!received_ready && reader->status != PACKET_READ_FLUSH)
+   die(_("expected no other sections to be sent after no 
'ready'"));
+
/* return 0 if no common, 1 if there are common, or 2 if ready */
return received_ready ? 2 : (received_ack ? 1 : 0);
 }
diff --git a/t/t5702-protocol-v2.sh b/t/t5702-protocol-v2.sh
index 8360188c01..51009ca391 100755
--- a/t/t5702-protocol-v2.sh
+++ b/t/t5702-protocol-v2.sh
@@ -512,6 +512,56 @@ test_expect_success 'push with http:// and a config of v2 
does not request v2' '
! grep "git< version 2" log
 '
 
+test_expect_success 'when server sends "ready", expect DELIM' '
+   rm -rf "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" http_child &&
+
+   git init "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" &&
+   test_commit -C "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" one &&
+
+   git clone "$HTTPD_URL/smart/http_parent" http_child &&
+
+   test_commit -C "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" two &&
+
+   # After "ready" in the acknowledgments section, pretend that a FLUSH
+   # () was sent instead of a DELIM (0001).
+   printf "/ready/,$ s/0001//" \
+   >"$HTTPD_ROOT_PATH/one-time-sed" &&
+
+   test_must_fail git -C http_child -c protocol.version=2 \
+   fetch "$HTTPD_URL/one_time_sed/http_parent" 2> err &&
+   test_i18ngrep "expected packfile to be sent after .ready." err
+'
+
+test_expect_success 'when server does not send "ready", expect FLUSH' '
+   rm -rf "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" http_child log &&
+
+   git init "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" &&
+   test_commit -C "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" one &&
+
+   git clone "$HTTPD_URL/smart/http_parent" http_child &&
+
+   test_commit -C "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" two &&
+
+   # Create many commits to extend the negotiation phase across multiple
+   # requests, so that the server does not send "ready" in the first
+   #

URGENT RESPONSE NEEDED

[Sean Kim.]

Hello my dear.

Did you receive my email message to you? Please, get back to me ASAP as the 
matter is becoming late.  Expecting your urgent response.

Sean.

URGENT RESPONSE NEEDED

[Sean Kim.]

Hello my dear.

Did you receive my email message to you? Please, get back to me ASAP as the 
matter is becoming late.  Expecting your urgent response.

Sean.

URGENT RESPONSE NEEDED

[Sean Kim.]

Hello my dear.

Did you receive my email message to you? Please, get back to me ASAP as the 
matter is becoming late.  Expecting your urgent response.

Sean.

URGENT RESPONSE PLEASE.

[Sean Kim.]

Hello my dear.

Did you receive my email message to you? Please, get back to me ASAP as the 
matter is becoming late.  Expecting your urgent response.

Sean.

URGENT RESPONSE PLEASE.

[Sean Kim.]

Hello my dear.

Did you receive my email message to you? Please, get back to me ASAP as the 
matter is becoming late.  Expecting your urgent response.

Sean.

Expecting Response.

[Mr. Sean Kimasala.]

Hello my dear.

I have been expecting your response based on the email I sent you few days ago. 
 Please, study my mail and respond back to me as the matter is becoming late.  
Expecting your urgent response.

Yours Sincerely,

Mr. Kimasala.

Dear friend, I have emailed you earlier without a response. In my first email I mentioned about my late client whose relatives I cannot get in touch with but both of you have the same last name, so it

[Jacob Tape]

Re: QUICK RESPONSE

[Aabidullah Aaiz Finance®]

-- 
Dear Sir/Madam

Are you a business man or woman ? Do you need a loan or funding for
any reason such as:

1) Personal Loan,Business Expansion , 2) Business Start-up ,Education,
3) Debt Consolidation , Home Improvement Loans 4) Hard Money Loans,
Investment Loans, We offer loan at low interest rate of 2% Percent and
with no credit check. Contact us' via below email for more
information' Company. Contact E-Mail: alifinanceander...@aim.com

Thanks
Yours In Service:
Customer Care Unit
For More Details:

I wait for your prompt response.

[SAM AZADA]

Good day,

I am Mr. Sam Azada from Burkina Faso  a Minister confide on me to look
for foreign partner who will assist him to invest the sum of  Fifty
Million  Dollars  ($50,000,000) in your country.

He has investment interest in mining, exotic properties for commercial
resident, development properties, hotels and any other viable
investment opportunities in your country based on your recommendation
will be highly welcomed.

Hence your co -operation is highly needed to actualize this investment project

I wait for your prompt response.

Sincerely yours

Mr Sam Azada.

I await your response for more close discussions.

[Mr Jeremiah]

Hello dear ,
I am Mr. Jeremiah Bworo , nationality of Ethiopia but currently In Benin 
Republic as a Principal Director with Federal Ministry Of Works and Housing 
here .

I will be delighted to invest with you there in your country into lucrative 
investments under your management as far as you could promise me of your 
country's economic stability . 

I await your response for more close discussions.

Regards,
Mr. Jeremiah Bworo
Principal director
Ministry of Works and Housing 
Benin Republic.

I await your response for more close discussions.

[Mr Jeremiah]

Hello dear ,
I am Mr. Jeremiah Bworo , nationality of Ethiopia but currently In Benin 
Republic as a Principal Director with Federal Ministry Of Works and Housing 
here .

I will be delighted to invest with you there in your country into lucrative 
investments under your management as far as you could promise me of your 
country's economic stability . 

I await your response for more close discussions.

Regards,
Mr. Jeremiah Bworo
Principal director
Ministry of Works and Housing 
Benin Republic.

I await your response for more close discussions.

[Mr Jeremiah]

Hello dear ,
I am Mr. Jeremiah Bworo , nationality of Ethiopia but currently In Benin 
Republic as a Principal Director with Federal Ministry Of Works and Housing 
here .

I will be delighted to invest with you there in your country into lucrative 
investments under your management as far as you could promise me of your 
country's economic stability . 

I await your response for more close discussions.

Regards,
Mr. Jeremiah Bworo
Principal director
Ministry of Works and Housing 
Benin Republic.

Re: git svn clone - Malformed network data: The XML response contains invalid XML: Malformed XML: no element found at /usr/share/perl5/vendor_perl/5.26/Git/SVN/Ra.pm line 312

[Eric Wong]

Jason Pyeron <jpye...@pdinc.us> wrote:
> 
> I am asuming that this is an issue caused by codeplex's svn
> from tfs implementation. Does anyone here have any insight?

Seems like it, even using svn(1) fails (see below)

> r27599 = 9e769d8327767a155d7b96b7cc28579cf0ed4c93 (refs/remotes/git-svn)
> Malformed network data: The XML response contains invalid XML: Malformed XML: 
> no element found at /usr/share/perl5/vendor_perl/5.26/Git/SVN/Ra.pm line 312.

OK, so lets find out what the next commit is after r27599:

  svn log -v -r 27599:HEAD https://smtp4dev.svn.codeplex.com/svn

  # which tells me r27864

  svn diff -r 27599:27864 https://smtp4dev.svn.codeplex.com/svn
  # which tells me:
  svn: E130003: The XML response contains invalid XML

strace only shows encrypted data, so maybe there's a flag or
debug option you can enable in SVN itself to see what was in the
bad XML or maybe contact the admin to see if it can be fixed.

git svn clone - Malformed network data: The XML response contains invalid XML: Malformed XML: no element found at /usr/share/perl5/vendor_perl/5.26/Git/SVN/Ra.pm line 312

[Jason Pyeron]

I am asuming that this is an issue caused by codeplex's svn from tfs 
implementation. Does anyone here have any insight?

$ git --version
git version 2.15.0

$ git svn clone https://smtp4dev.svn.codeplex.com/svn smtp4dev
Initialized empty Git repository in 
/cygdrive/c/Users/Public/Desktop/projects/smtp4dev/.git/
r20111 = 443d627cdfeeb240162b9f089ab50c6f058a1260 (refs/remotes/git-svn)
A   trunk/smtp4dev/smtp4dev.csproj
A   trunk/smtp4dev/Resources/Icon2.ico
A   trunk/smtp4dev/Resources/Icon1.ico
A   trunk/smtp4dev/RegistrySettings.cs
A   trunk/smtp4dev/Properties/Settings.settings
A   trunk/smtp4dev/Properties/Settings.Designer.cs
A   trunk/smtp4dev/Properties/Resources.resx
A   trunk/smtp4dev/Properties/Resources.Designer.cs
A   trunk/smtp4dev/Properties/AssemblyInfo.cs
A   trunk/smtp4dev/Program.cs
A   trunk/smtp4dev/OptionsForm.resx
A   trunk/smtp4dev/OptionsForm.Designer.cs
A   trunk/smtp4dev/OptionsForm.cs
A   
trunk/smtp4dev/obj/Debug/TempPE/Properties.Resources.Designer.cs.dll
A   trunk/smtp4dev/obj/Debug/smtp4dev.Properties.Resources.resources
A   trunk/smtp4dev/obj/Debug/smtp4dev.pdb
A   trunk/smtp4dev/obj/Debug/smtp4dev.OptionsForm.resources
A   trunk/smtp4dev/obj/Debug/smtp4dev.MainForm.resources
A   trunk/smtp4dev/obj/Debug/smtp4dev.exe
A   trunk/smtp4dev/obj/Debug/smtp4dev.csproj.GenerateResource.Cache
A   trunk/smtp4dev/obj/Debug/smtp4dev.csproj.FileListAbsolute.txt
A   trunk/smtp4dev/obj/Debug/ResolveAssemblyReference.cache
A   trunk/smtp4dev/MainForm.resx
A   trunk/smtp4dev/MainForm.Designer.cs
A   trunk/smtp4dev/MainForm.cs
A   trunk/smtp4dev/lib/log4net.dll
A   trunk/smtp4dev/lib/cses.smtp.server.xml
A   trunk/smtp4dev/lib/cses.smtp.server.dll
A   trunk/smtp4dev/Email.cs
A   trunk/smtp4dev/bin/Debug/smtp4dev.vshost.exe
A   trunk/smtp4dev/bin/Debug/smtp4dev.vshost.exe.manifest
A   trunk/smtp4dev/bin/Debug/smtp4dev.vshost.exe.config
A   trunk/smtp4dev/bin/Debug/smtp4dev.pdb
A   trunk/smtp4dev/bin/Debug/smtp4dev.exe
A   trunk/smtp4dev/bin/Debug/smtp4dev.exe.config
A   trunk/smtp4dev/bin/Debug/log4net.dll
A   trunk/smtp4dev/bin/Debug/cses.smtp.server.xml
A   trunk/smtp4dev/bin/Debug/cses.smtp.server.dll
A   trunk/smtp4dev/app.config
A   trunk/smtp4dev.suo
A   trunk/smtp4dev.sln
A   trunk/smtp4dev.4.5.resharper.user
A   trunk/Setup/Setup.vdproj
A   trunk/Setup/Debug/smtp4dev-1.0.0.0.zip
A   trunk/Setup/Debug/Setup.msi
A   trunk/Setup/Debug/setup.exe
A   trunk/Setup/Debug/LICENSE
A   trunk/Setup/Debug/LICENSE.log4net
A   trunk/Setup/Debug/LICENSE.cses-smtp-server
A   trunk/LICENSE
A   trunk/LICENSE.rtf
A   trunk/LICENSE.log4net
A   trunk/LICENSE.cses-smtp-server
A   trunk/_ReSharper.smtp4dev/Xaml/CacheProvider.dat
A   trunk/_ReSharper.smtp4dev/WordIndex.New/6/61e28584.dat
A   trunk/_ReSharper.smtp4dev/WordIndex.New/.version
A   trunk/_ReSharper.smtp4dev/WebsiteFileReferences/.version
A   trunk/_ReSharper.smtp4dev/TodoCache/9/3ace61b9.dat
A   trunk/_ReSharper.smtp4dev/TodoCache/.version
A   trunk/_ReSharper.smtp4dev/ProjectModel/ProjectModel.dat
A   trunk/_ReSharper.smtp4dev/CachesImage.bin
W: +empty_dir: trunk/Setup/Release
W: +empty_dir: trunk/smtp4dev/obj/Debug/Refactor
r20114 = 569cc523b14d6346f3198f37b27fccb8cb572ab1 (refs/remotes/git-svn)
... It chugs along then ...
W: -empty_dir: trunk/Rnwood.Smtp4dev/Behaviour.cs
W: -empty_dir: trunk/Rnwood.SmtpServer/SmtpRequest.cs
r27599 = 9e769d8327767a155d7b96b7cc28579cf0ed4c93 (refs/remotes/git-svn)
Malformed network data: The XML response contains invalid XML: Malformed XML: 
no element found at /usr/share/perl5/vendor_perl/5.26/Git/SVN/Ra.pm line 312.


I have tried to fiddle with --log-window-size but nothing seemed to work. 
(https://stackoverflow.com/questions/38071052/getting-error-while-migrating-code-from-svn-to-git-repository-malformed-network)


-Jason

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

I wait for your prompt response.

[SAM AZADA]

Good day,

I am Mr. Sam Azada from Burkina Faso  a Minister confide on me to look
for foreign partner who will assist him to invest the sum of  Fifty
Million  Dollars  ($50,000,000) in your country.

He has investment interest in mining, exotic properties for commercial
resident, development properties, hotels and any other viable
investment opportunities in your country based on your recommendation
will be highly welcomed.

Hence your co -operation is highly needed to actualize this investment project

I wait for your prompt response.

Sincerely yours

Mr Sam Azada.

I wait for your prompt response.

[SAM AZADA]

Good day,

I am Mr. Sam Azada from Burkina Faso  a Minister confide on me to look
for foreign partner who will assist him to invest the sum of  Fifty
Million  Dollars  ($50,000,000) in your country.

He has investment interest in mining, exotic properties for commercial
resident, development properties, hotels and any other viable
investment opportunities in your country based on your recommendation
will be highly welcomed.

Hence your co -operation is highly needed to actualize this investment project

I wait for your prompt response.

Sincerely yours

Mr Sam Azada.

I wait for your prompt response.

[SAM AZADA]

Good day,

I am Mr. Sam Azada from Burkina Faso  a Minister confide on me to look
for foreign partner who will assist him to invest the sum of  Fifty
Million  Dollars  ($50,000,000) in your country.

He has investment interest in mining, exotic properties for commercial
resident, development properties, hotels and any other viable
investment opportunities in your country based on your recommendation
will be highly welcomed.

Hence your co -operation is highly needed to actualize this investment project

I wait for your prompt response.

Sincerely yours

Mr Sam Azada.

I wait for your prompt response.

[SAM AZADA]

Good day,

I am Mr. Sam Azada from Burkina Faso  a Minister confide on me to look
for foreign partner who will assist him to invest the sum of  Fifty
Million  Dollars  ($50,000,000) in your country.

He has investment interest in mining, exotic properties for commercial
resident, development properties, hotels and any other viable
investment opportunities in your country based on your recommendation
will be highly welcomed.

Hence your co -operation is highly needed to actualize this investment project

I wait for your prompt response.

Sincerely yours

Mr Sam Azada.

I wait for your prompt response.

[SAM AZADA]

Good day,

I am Mr. Sam Azada from Burkina Faso  a Minister confide on me to look
for foreign partner who will assist him to invest the sum of  Fifty
Million  Dollars  ($50,000,000) in your country.

He has investment interest in mining, exotic properties for commercial
resident, development properties, hotels and any other viable
investment opportunities in your country based on your recommendation
will be highly welcomed.

Hence your co -operation is highly needed to actualize this investment project

I wait for your prompt response.

Sincerely yours

Mr Sam Azada.

Urgent response !!!

[Melisa Mehmet]

Greetings,

I have a business proposal I would love to discuss with you. please reply me 
for more details
Yours Sincerely,
miss.melisa.mehmet

RE: STILL WAITING FOR YOUR RESPONSE

[Kim Kyeong]

Hello,

Did you received my previous message? 

Regards.

[PATCH v4 06/11] connect: teach client to recognize v1 server response

[Brandon Williams]

Teach a client to recognize that a server understands protocol v1 by
looking at the first pkt-line the server sends in response.  This is
done by looking for the response "version 1" send by upload-pack or
receive-pack.

Signed-off-by: Brandon Williams <bmw...@google.com>
---
 connect.c | 30 ++
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/connect.c b/connect.c
index 8e2e276b6..a5e708a61 100644
--- a/connect.c
+++ b/connect.c
@@ -12,6 +12,7 @@
 #include "sha1-array.h"
 #include "transport.h"
 #include "strbuf.h"
+#include "protocol.h"
 
 static char *server_capabilities;
 static const char *parse_feature_value(const char *, const char *, int *);
@@ -129,9 +130,23 @@ static int read_remote_ref(int in, char **src_buf, size_t 
*src_len,
return len;
 }
 
-#define EXPECTING_FIRST_REF 0
-#define EXPECTING_REF 1
-#define EXPECTING_SHALLOW 2
+#define EXPECTING_PROTOCOL_VERSION 0
+#define EXPECTING_FIRST_REF 1
+#define EXPECTING_REF 2
+#define EXPECTING_SHALLOW 3
+
+/* Returns 1 if packet_buffer is a protocol version pkt-line, 0 otherwise. */
+static int process_protocol_version(void)
+{
+   switch (determine_protocol_version_client(packet_buffer)) {
+   case protocol_v1:
+   return 1;
+   case protocol_v0:
+   return 0;
+   default:
+   die("server is speaking an unknown protocol");
+   }
+}
 
 static void process_capabilities(int *len)
 {
@@ -224,12 +239,19 @@ struct ref **get_remote_heads(int in, char *src_buf, 
size_t src_len,
 */
int responded = 0;
int len;
-   int state = EXPECTING_FIRST_REF;
+   int state = EXPECTING_PROTOCOL_VERSION;
 
*list = NULL;
 
while ((len = read_remote_ref(in, _buf, _len, ))) {
switch (state) {
+   case EXPECTING_PROTOCOL_VERSION:
+   if (process_protocol_version()) {
+   state = EXPECTING_FIRST_REF;
+   break;
+   }
+   state = EXPECTING_FIRST_REF;
+   /* fallthrough */
case EXPECTING_FIRST_REF:
process_capabilities();
if (process_dummy_ref()) {
-- 
2.15.0.rc0.271.g36b669edcc-goog

[PATCH v3 06/10] connect: teach client to recognize v1 server response

[Brandon Williams]

Teach a client to recognize that a server understands protocol v1 by
looking at the first pkt-line the server sends in response.  This is
done by looking for the response "version 1" send by upload-pack or
receive-pack.

Signed-off-by: Brandon Williams <bmw...@google.com>
---
 connect.c | 30 ++
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/connect.c b/connect.c
index 8e2e276b6..a5e708a61 100644
--- a/connect.c
+++ b/connect.c
@@ -12,6 +12,7 @@
 #include "sha1-array.h"
 #include "transport.h"
 #include "strbuf.h"
+#include "protocol.h"
 
 static char *server_capabilities;
 static const char *parse_feature_value(const char *, const char *, int *);
@@ -129,9 +130,23 @@ static int read_remote_ref(int in, char **src_buf, size_t 
*src_len,
return len;
 }
 
-#define EXPECTING_FIRST_REF 0
-#define EXPECTING_REF 1
-#define EXPECTING_SHALLOW 2
+#define EXPECTING_PROTOCOL_VERSION 0
+#define EXPECTING_FIRST_REF 1
+#define EXPECTING_REF 2
+#define EXPECTING_SHALLOW 3
+
+/* Returns 1 if packet_buffer is a protocol version pkt-line, 0 otherwise. */
+static int process_protocol_version(void)
+{
+   switch (determine_protocol_version_client(packet_buffer)) {
+   case protocol_v1:
+   return 1;
+   case protocol_v0:
+   return 0;
+   default:
+   die("server is speaking an unknown protocol");
+   }
+}
 
 static void process_capabilities(int *len)
 {
@@ -224,12 +239,19 @@ struct ref **get_remote_heads(int in, char *src_buf, 
size_t src_len,
 */
int responded = 0;
int len;
-   int state = EXPECTING_FIRST_REF;
+   int state = EXPECTING_PROTOCOL_VERSION;
 
*list = NULL;
 
while ((len = read_remote_ref(in, _buf, _len, ))) {
switch (state) {
+   case EXPECTING_PROTOCOL_VERSION:
+   if (process_protocol_version()) {
+   state = EXPECTING_FIRST_REF;
+   break;
+   }
+   state = EXPECTING_FIRST_REF;
+   /* fallthrough */
case EXPECTING_FIRST_REF:
process_capabilities();
if (process_dummy_ref()) {
-- 
2.14.2.920.gcf0c67979c-goog

Your response is highly appreciated

[Mr.Adams Salem]

Hello ,

I am specifically contacting you in respect of a business proposal that I
have for you as you appear very relevant in the proposal.

Please kindly reply back to me for further details.

Waiting to hear from you.

Regards,

Mr.Adams Salem

Re: [PATCH v2 6/9] connect: teach client to recognize v1 server response

[Brandon Williams]

On 09/27, Junio C Hamano wrote:
> Brandon Williams  writes:
> 
> > +/* Returns 1 if packet_buffer is a protocol version pkt-line, 0 otherwise. 
> > */
> > +static int process_protocol_version(void)
> > +{
> > +   switch (determine_protocol_version_client(packet_buffer)) {
> > +   case protocol_v1:
> > +   return 1;
> > +   case protocol_v0:
> > +   return 0;
> > +   default:
> > +   die("server is speaking an unknown protocol");
> > +   }
> > +}
> 
> For the purpose of "technology demonstration" v1 protocol, it is OK
> to discard the result of "determine_pvc()" like the above code, but
> in a real application, we would do a bit more than just ignoring an
> extra "version #" packet that appears at the beginning, no?
> 
> It would be sensible to design how the result of determien_pvc()
> call is propagated to the remainder of the program in this patch and
> implement it.  Perhaps add a new global (like server_capabilities
> already is) and store the value there, or something?  Or pass a
> pointer to enum protocol_version as a return-location parameter to
> this helper function so that the process_capabilities() can pass a
> pointer to its local variable?

Yes, once we actually implement a v2 we would need to not throw away the
result of 'determine_pvc()' and instead do control flow based on the
resultant version.  I was trying to implement 'v1' as simply as possible
so that I wouldn't have to do a large amount of refactoring when
proposing this transition, though it seems Jonathan ended up doing more
than I planned, as I figured we didn't really know what the code will
need to be refactored to, in order to handle another protocol version.
I would suspect that we maybe wouldn't want to determine which version a
server is speaking in 'get_remote_heads()' but rather at some point
before that so we can branch off to do v2 like things, for example,
capability discovery and not ref discovery.

If you do think we need to do more of that refactoring now, before a v2,
I can most certainly work on that.


> 
> >  static void process_capabilities(int *len)
> >  {
> > @@ -224,12 +239,19 @@ struct ref **get_remote_heads(int in, char *src_buf, 
> > size_t src_len,
> >  */
> > int responded = 0;
> > int len;
> > -   int state = EXPECTING_FIRST_REF;
> > +   int state = EXPECTING_PROTOCOL_VERSION;
> >  
> > *list = NULL;
> >  
> > while ((len = read_remote_ref(in, _buf, _len, ))) {
> > switch (state) {
> > +   case EXPECTING_PROTOCOL_VERSION:
> > +   if (process_protocol_version()) {
> > +   state = EXPECTING_FIRST_REF;
> > +   break;
> > +   }
> > +   state = EXPECTING_FIRST_REF;
> > +   /* fallthrough */
> > case EXPECTING_FIRST_REF:
> > process_capabilities();
> > if (process_dummy_ref()) {

-- 
Brandon Williams

Re: [PATCH v2 6/9] connect: teach client to recognize v1 server response

[Brandon Williams]

On 09/27, Junio C Hamano wrote:
> Brandon Williams  writes:
> 
> > +/* Returns 1 if packet_buffer is a protocol version pkt-line, 0 otherwise. 
> > */
> > +static int process_protocol_version(void)
> > +{
> > +   switch (determine_protocol_version_client(packet_buffer)) {
> > +   case protocol_v1:
> > +   return 1;
> > +   case protocol_v0:
> > +   return 0;
> > +   default:
> > +   die("server is speaking an unknown protocol");
> > +   }
> > +}
> 
> checkpatch.pl yells at me:
> 
> ERROR: switch and case should be at the same indent
> 
> and we would probably want to teach "make style" the same, if we
> already don't.

'make style' actually already understands this, I just forgot it run it
on this change :)

-- 
Brandon Williams

Re: [PATCH v2 6/9] connect: teach client to recognize v1 server response

[Junio C Hamano]

Brandon Williams  writes:

> +/* Returns 1 if packet_buffer is a protocol version pkt-line, 0 otherwise. */
> +static int process_protocol_version(void)
> +{
> + switch (determine_protocol_version_client(packet_buffer)) {
> + case protocol_v1:
> + return 1;
> + case protocol_v0:
> + return 0;
> + default:
> + die("server is speaking an unknown protocol");
> + }
> +}

For the purpose of "technology demonstration" v1 protocol, it is OK
to discard the result of "determine_pvc()" like the above code, but
in a real application, we would do a bit more than just ignoring an
extra "version #" packet that appears at the beginning, no?

It would be sensible to design how the result of determien_pvc()
call is propagated to the remainder of the program in this patch and
implement it.  Perhaps add a new global (like server_capabilities
already is) and store the value there, or something?  Or pass a
pointer to enum protocol_version as a return-location parameter to
this helper function so that the process_capabilities() can pass a
pointer to its local variable?

>  static void process_capabilities(int *len)
>  {
> @@ -224,12 +239,19 @@ struct ref **get_remote_heads(int in, char *src_buf, 
> size_t src_len,
>*/
>   int responded = 0;
>   int len;
> - int state = EXPECTING_FIRST_REF;
> + int state = EXPECTING_PROTOCOL_VERSION;
>  
>   *list = NULL;
>  
>   while ((len = read_remote_ref(in, _buf, _len, ))) {
>   switch (state) {
> + case EXPECTING_PROTOCOL_VERSION:
> + if (process_protocol_version()) {
> + state = EXPECTING_FIRST_REF;
> + break;
> + }
> + state = EXPECTING_FIRST_REF;
> + /* fallthrough */
>   case EXPECTING_FIRST_REF:
>   process_capabilities();
>   if (process_dummy_ref()) {

Re: [PATCH v2 6/9] connect: teach client to recognize v1 server response

[Junio C Hamano]

Brandon Williams  writes:

> +/* Returns 1 if packet_buffer is a protocol version pkt-line, 0 otherwise. */
> +static int process_protocol_version(void)
> +{
> + switch (determine_protocol_version_client(packet_buffer)) {
> + case protocol_v1:
> + return 1;
> + case protocol_v0:
> + return 0;
> + default:
> + die("server is speaking an unknown protocol");
> + }
> +}

checkpatch.pl yells at me:

ERROR: switch and case should be at the same indent

and we would probably want to teach "make style" the same, if we
already don't.

[PATCH v2 6/9] connect: teach client to recognize v1 server response

[Brandon Williams]

Teach a client to recognize that a server understands protocol v1 by
looking at the first pkt-line the server sends in response.  This is
done by looking for the response "version 1" send by upload-pack or
receive-pack.

Signed-off-by: Brandon Williams <bmw...@google.com>
---
 connect.c | 30 ++
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/connect.c b/connect.c
index 8e2e276b6..1805debf3 100644
--- a/connect.c
+++ b/connect.c
@@ -12,6 +12,7 @@
 #include "sha1-array.h"
 #include "transport.h"
 #include "strbuf.h"
+#include "protocol.h"
 
 static char *server_capabilities;
 static const char *parse_feature_value(const char *, const char *, int *);
@@ -129,9 +130,23 @@ static int read_remote_ref(int in, char **src_buf, size_t 
*src_len,
return len;
 }
 
-#define EXPECTING_FIRST_REF 0
-#define EXPECTING_REF 1
-#define EXPECTING_SHALLOW 2
+#define EXPECTING_PROTOCOL_VERSION 0
+#define EXPECTING_FIRST_REF 1
+#define EXPECTING_REF 2
+#define EXPECTING_SHALLOW 3
+
+/* Returns 1 if packet_buffer is a protocol version pkt-line, 0 otherwise. */
+static int process_protocol_version(void)
+{
+   switch (determine_protocol_version_client(packet_buffer)) {
+   case protocol_v1:
+   return 1;
+   case protocol_v0:
+   return 0;
+   default:
+   die("server is speaking an unknown protocol");
+   }
+}
 
 static void process_capabilities(int *len)
 {
@@ -224,12 +239,19 @@ struct ref **get_remote_heads(int in, char *src_buf, 
size_t src_len,
 */
int responded = 0;
int len;
-   int state = EXPECTING_FIRST_REF;
+   int state = EXPECTING_PROTOCOL_VERSION;
 
*list = NULL;
 
while ((len = read_remote_ref(in, _buf, _len, ))) {
switch (state) {
+   case EXPECTING_PROTOCOL_VERSION:
+   if (process_protocol_version()) {
+   state = EXPECTING_FIRST_REF;
+   break;
+   }
+   state = EXPECTING_FIRST_REF;
+   /* fallthrough */
case EXPECTING_FIRST_REF:
process_capabilities();
if (process_dummy_ref()) {
-- 
2.14.1.992.g2c7b836f3a-goog

[PATCH 5/8] connect: teach client to recognize v1 server response

[Brandon Williams]

Teach a client to recognize that a server understands protocol v1 by
looking at the first pkt-line the server sends in response.  This is
done by looking for the response "version 1" send by upload-pack or
receive-pack.

Signed-off-by: Brandon Williams <bmw...@google.com>
---
 connect.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/connect.c b/connect.c
index 49b28b83b..2702e1f2e 100644
--- a/connect.c
+++ b/connect.c
@@ -11,6 +11,7 @@
 #include "string-list.h"
 #include "sha1-array.h"
 #include "transport.h"
+#include "protocol.h"
 
 static char *server_capabilities;
 static const char *parse_feature_value(const char *, const char *, int *);
@@ -142,6 +143,27 @@ struct ref **get_remote_heads(int in, char *src_buf, 
size_t src_len,
if (len < 0)
die_initial_contact(saw_response);
 
+   /* Only check for version information on first response */
+   if (!saw_response) {
+   switch (determine_protocol_version_client(buffer)) {
+   case protocol_v1:
+   /*
+* First pkt-line contained the version string.
+* Continue on to process the ref advertisement.
+*/
+   continue;
+   case protocol_v0:
+   /*
+* Server is speaking protocol v0 and sent a
+* ref so we need to process it.
+*/
+   break;
+   default:
+   die("server is speaking an unknown protocol");
+   break;
+   }
+   }
+
if (!len)
break;
 
-- 
2.14.1.690.gbb1197296e-goog

Your response is required

[Dean]

Hello there, I sent you an email yesterday with a proposal that I think is 
going to be of mutual benefit but I did not receive a response from you yet so 
I am sending you this follow up to confirm if you actually received my email 
yesterday.

Please let me know if you did not receive my proposal so that I can resend it 
to you. Use the email below to contact me.

Regards,
Dean
dohn20...@secsuremailer.com

[RFC 6/7] transport: teach client to recognize v2 server response

[Brandon Williams]

Teach a client to recognize that a server understand protocol v2 by
looking at the first pkt-line the server sends in response.  This is
done by looking for the response "version 2" sent by upload-pack.

Signed-off-by: Brandon Williams <bmw...@google.com>
---
 builtin/fetch-pack.c |   4 +-
 builtin/send-pack.c  |   5 +-
 connect.c| 165 ++-
 remote-curl.c|   7 ++-
 remote.h |  22 ++-
 transport.c  |  60 ---
 6 files changed, 178 insertions(+), 85 deletions(-)

diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index 366b9d13f..a2a5e1c73 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -52,6 +52,7 @@ int cmd_fetch_pack(int argc, const char **argv, const char 
*prefix)
struct fetch_pack_args args;
struct oid_array shallow = OID_ARRAY_INIT;
struct string_list deepen_not = STRING_LIST_INIT_DUP;
+   struct remote_refs_scanner scanner;
 
packet_trace_identity("fetch-pack");
 
@@ -193,7 +194,8 @@ int cmd_fetch_pack(int argc, const char **argv, const char 
*prefix)
if (!conn)
return args.diag_url ? 0 : 1;
}
-   get_remote_heads(fd[0], NULL, 0, , 0, NULL, );
+   remote_refs_scanner_init(, , 0, NULL, );
+   get_remote_heads(fd[0], NULL, 0, );
 
ref = fetch_pack(, fd, conn, ref, dest, sought, nr_sought,
 , pack_lockfile_ptr);
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index fc4f0bb5f..92ec1f871 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -154,6 +154,7 @@ int cmd_send_pack(int argc, const char **argv, const char 
*prefix)
int progress = -1;
int from_stdin = 0;
struct push_cas_option cas = {0};
+   struct remote_refs_scanner scanner;
 
struct option options[] = {
OPT__VERBOSITY(),
@@ -256,8 +257,8 @@ int cmd_send_pack(int argc, const char **argv, const char 
*prefix)
args.verbose ? CONNECT_VERBOSE : 0);
}
 
-   get_remote_heads(fd[0], NULL, 0, _refs, REF_NORMAL,
-_have, );
+   remote_refs_scanner_init(, _refs, REF_NORMAL, 
_have, );
+   get_remote_heads(fd[0], NULL, 0, );
 
transport_verify_remote_names(nr_refspecs, refspecs);
 
diff --git a/connect.c b/connect.c
index d609267be..732b651d9 100644
--- a/connect.c
+++ b/connect.c
@@ -107,97 +107,124 @@ static void annotate_refs_with_symref_info(struct ref 
*ref)
string_list_clear(, 0);
 }
 
-/*
- * Read all the refs from the other end
- */
-struct ref **get_remote_heads(int in, char *src_buf, size_t src_len,
+void remote_refs_scanner_init(struct remote_refs_scanner *scanner,
  struct ref **list, unsigned int flags,
  struct oid_array *extra_have,
  struct oid_array *shallow_points)
 {
-   struct ref **orig_list = list;
+   memset(scanner, 0, sizeof(*scanner));
+
+   scanner->orig_list = list;
+   *list = NULL;
+   scanner->list = list;
+   scanner->flags = flags;
+   scanner->extra_have = extra_have;
+   scanner->shallow_points = shallow_points;
+}
+
+int process_ref(struct remote_refs_scanner *scanner,
+   const char *buffer, int len)
+{
+   struct ref *ref;
+   struct object_id old_oid;
+   const char *name;
+   int name_len;
+   const char *arg;
+   int ret = 1;
+
+   if (len < 0)
+   die_initial_contact(scanner->seen_response);
+
+   if (!len) {
+   ret = 0;
+   goto out;
+   }
+
+   if (len > 4 && skip_prefix(buffer, "ERR ", ))
+   die("remote error: %s", arg);
+
+   if (len == GIT_SHA1_HEXSZ + strlen("shallow ") &&
+   skip_prefix(buffer, "shallow ", )) {
+   if (get_oid_hex(arg, _oid))
+   die("protocol error: expected shallow sha-1, got '%s'", 
arg);
+   if (!scanner->shallow_points)
+   die("repository on the other end cannot be shallow");
+   oid_array_append(scanner->shallow_points, _oid);
+   goto out;
+   }
+
+   if (len < GIT_SHA1_HEXSZ + 2 || get_oid_hex(buffer, _oid) ||
+   buffer[GIT_SHA1_HEXSZ] != ' ')
+   die("protocol error: expected sha/ref, got '%s'", buffer);
+   name = buffer + GIT_SHA1_HEXSZ + 1;
+
+   name_len = strlen(name);
+   if (len != name_len + GIT_SHA1_HEXSZ + 1) {
+   free(server_capabilities);
+   server_capabilities = xstrdup(name + name_len + 1);
+   }
+
+   if (scanner->extra_have && !strcmp(name, ".have")) {
+   oid_array_append(scanner->extra_have, _oid)

Your response is highly appreciated!!!

[Mr.Adams Salem]

Hello , 

I am specifically contacting you in respect of a business proposal that I have 
for you as you appear very relevant in the proposal. 

Please kindly reply back to me for further details.

Waiting to hear from you. 

Regards,

Mr.Adams Salem

Email: mradamssale...@outlook.my

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

your response is highly appreciated

[Mr. Adams Salem]

Hello ,

I am specifically contacting you in respect of a business proposal that I have 
for you as you appear very relevant in the proposal.

Please kindly reply back to me for further details.

Waiting to hear from you.

Regards,

Mr. Adams Salem

Private E-mail: mradamssa...@outlook.my

Looking forward to hear your response regarding the fund tranfer in your account

[Edmund Benedetti]

Waiting to hear your response regarding the fund tranfer in your account

[Edmund Benedetti]

[PATCH 2/6] send-pack: extract parsing of "unpack" response

[Jeff King]

After sending the pack, we call receive_status() which gets
both the "unpack" line and the ref status. Let's break these
into two functions so we can call the first part
independently.

Signed-off-by: Jeff King 
---
 send-pack.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/send-pack.c b/send-pack.c
index 6195b43e9..12e229e44 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -130,22 +130,27 @@ static int pack_objects(int fd, struct ref *refs, struct 
sha1_array *extra, stru
return 0;
 }
 
-static int receive_status(int in, struct ref *refs)
+static int receive_unpack_status(int in)
 {
-   struct ref *hint;
-   int ret = 0;
-   char *line = packet_read_line(in, NULL);
+   const char *line = packet_read_line(in, NULL);
if (!starts_with(line, "unpack "))
return error("did not receive remote status");
-   if (strcmp(line, "unpack ok")) {
-   error("unpack failed: %s", line + 7);
-   ret = -1;
-   }
+   if (strcmp(line, "unpack ok"))
+   return error("unpack failed: %s", line + 7);
+   return 0;
+}
+
+static int receive_status(int in, struct ref *refs)
+{
+   struct ref *hint;
+   int ret;
+
hint = NULL;
+   ret = receive_unpack_status(in);
while (1) {
char *refname;
char *msg;
-   line = packet_read_line(in, NULL);
+   char *line = packet_read_line(in, NULL);
if (!line)
break;
if (!starts_with(line, "ok ") && !starts_with(line, "ng ")) {
-- 
2.12.0.429.gde83c8049

Haster Response.//..

[UNCLAIMED ASSET]

Mr. Steve Bhatti,
Drift / regionsjef
Santander Bank Plc,
47-48 Piccadilly
PICCADILLY
W1J0DT
London, Storbritannia
 
Hei,

Jeg er Steve Bhatti, fra Harlesden North West London, leder for regnskap 
Revisjonen og formell senior programmerer sjef hos Deutsche bank, her i England 
(Santander Bank Plc). Jeg har også jobbet for Nyeste ministrene Bank Plc.
 
Jeg trenger din haster hjelp til å overføre summen av (£ 21,5) millioner 
britiske pund på kontoen din innen 11 eller 15 bankdager. Disse pengene har 
vært sovende i mange år i vår Bank uten krav. Jeg ønsker banken å frigjøre 
penger til deg som nærmeste person til vår avdøde kunden (eieren av kontoen) 
som dessverre mistet livet februar 2003 gjennom det sørlige USA romfergen 
Columbia, døde han en enkelt mann. Jeg ønsker ikke penger til å gå inn i 
bankens egne konto som en forlatt fondet. Så dette er grunnen til at jeg 
kontakter deg slik at banken kan frigjøre penger til deg som skal pårørende til 
den avdøde kunden. (Late David McDowell Brown) en amerikansk statsborger av 
Arlington Virginia.
Vennligst Jeg vil at du skal holde Forslaget som en topp hemmelig og slette den 
hvis du ikke er interessert.
 
Her deler ratio; 50% til meg og 40% til deg mens 10% er for eventuelle utgifter 
i løpet av transaksjonen. Hvis du er interessert, ta kontakt med meg 
umiddelbart via min private / direkte post: steve.s.bha...@gmail.com

Gi meg følgende under, som vi har 7 dager for å kjøre den gjennom. Dette er 
veldig HASTER.
 
1. Fullt navn:
2. Direkte Mobilnummer:
3. Kontakt Adresse:
4. Yrke:
5. Alder:
6. Kjønn:
7. Nasjonalitet:
 
Vennlig hilsen,
Dr. Steve Bhatti.

Nujna response.//..

[UNCLAIMED ASSET]

Steve Bhatti,
Operations / regionalni direktor
Santander Bank Plc,
47-48 Piccadilly
PICCADILLY
W1J0DT
London, Združeno Kraljestvo
 
Hi,

Sem Steve Bhatti, od Harlesden North West London, vodja oddelka racunovodskega 
revidiranja in formalno višji vodja programer pri Deutsche bank, tukaj v 
Angliji (Santander Bank Plc). Delal sem tudi za novejše ministrov Bank Plc.
 
Rabim nujno pomoc pri prenosu vsoto (£ 21,5) milijona britanskih funtov na svoj 
racun v 11 ali 15 bancnih dni. Ta denar je bil v mirovanju za let v naši banki 
brez zahtevka. Želim banka sprostiti denar za vas, najbližje osebe v naši 
pokojnega Stranka (lastnik racuna), ki je na žalost izgubil življenje februarja 
2003, po južnem ZDA raketoplana Columbia, je umrl en sam clovek. Nocem, da je 
denar šel v zakladniškega racuna banke kot zapušceni sklada. To je torej 
razlog, zakaj sem kontakt z vami, da bi lahko banka spustite denar za vas, saj 
naj ožjih sorodnikov na umrlega kupca. (Late David McDowell Brown), ameriški 
državljan Arlington v Virginiji.
Prosimo, da bi vas rad, da ta predlog kot top skrivnost in ga izbrisati, ce vas 
ne zanimajo.
 
Tu je delitev razmerje; 50% za mene in 40% za vas, medtem ko 10% je za vse 
stroške, ki so nastali v casu transakcije. Ce ste zainteresirani, se obrnite mi 
neposredno preko mojega zasebnega / direktno pošto: steve.s.bha...@gmail.com

Navedite mi sledi spodaj, kot smo 7 dni teci skozi. To je zelo nujna.
 
1. Polno ime:
2. Direct Mobile Število:
3. Kontaktni naslov:
4. Poklic:
5. Age:
6. Spol:
7. Državljanstvo:
 
S spoštovanjem,
Dr. Steve Bhatti.

Re: [PATCH] Documentation: pack-protocol correct NAK response

[Junio C Hamano]

On Fri, Jul 22, 2016 at 1:28 PM, Stefan Beller  wrote:
> In the transport protocol we use NAK to signal the non existence of a
> common base, so fix the documentation.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Documentation: pack-protocol correct NAK response

[Stefan Beller]

In the transport protocol we use NAK to signal the non existence of a
common base, so fix the documentation. This helps readers of the document,
as they don't have to wonder about the difference between NAK and NACK.
As NACK is used in git archive and upload-archive, this is easy to get
wrong.

Signed-off-by: Stefan Beller <sbel...@google.com>
---
 Documentation/technical/pack-protocol.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/technical/pack-protocol.txt 
b/Documentation/technical/pack-protocol.txt
index 8b36343..d40ab65 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -307,7 +307,7 @@ In multi_ack mode:
 ready to make a packfile, it will blindly ACK all 'have' obj-ids
 back to the client.
 
-  * the server will then send a 'NACK' and then wait for another response
+  * the server will then send a 'NAK' and then wait for another response
 from the client - either a 'done' or another list of 'have' lines.
 
 In multi_ack_detailed mode:
-- 
2.9.2.370.g4a59376.dirty

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

URGENT RESPONSE NEEDED, PLEASE REPLY....

[Mr. Ragner Henderson]

Dear Friend,

Pardon me for not having the pleasure of knowing your mindset before making you 
this offer and it is utterly confidential and genuine by virtue of its nature I 
write to solicit your assistance in a funds transfer deal involving £15.2M.This 
fund has been stashed out of the excess profit made last 2years by my branch 
office of  the Co-operative Bank Plc here in United Kingdom which I am the 
manager.

I have already submitted an approved end-of-the-year report for the year 2015 
to my head office here in Manchester UK. and they will never know of this 
excess.

I have since then, placed this amount on a Non-Investment Account without a 
beneficiary. Upon your response, I will configure your name on our database as 
holder of the Non-Investment Account. I will then guide you on how to apply to 
my head office for the Account Closure/bank-to-bank remittance of the funds to 
your designated bank account.
If you concur with this proposal, I intend for you to retain 30% of the funds 
while 70% shall be for me. Kindly forward your response to me immediately to my 
private mail box: (mr.ragnerhender...@yahoo.com) thank you.

With Regards,

Mr. Ragner Henderson.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] imap-send: fix CRAM-MD5 response calculation

[Kazuki Yamaguchi]

Remove extra + 1 from resp_len, the length of the byte sequence to be
Base64 encoded and passed to the server as the response. Or the response
incorrectly contains an extra \0.

Signed-off-by: Kazuki Yamaguchi <k...@rhe.jp>
---
 imap-send.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/imap-send.c b/imap-send.c
index 30979f0c63cc..407e46bc8c0e 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -890,7 +890,7 @@ static char *cram(const char *challenge_64, const char 
*user, const char *pass)
 
    /* response: " " */
response = xstrfmt("%s %s", user, hex);
-   resp_len = strlen(response) + 1;
+   resp_len = strlen(response);
 
response_64 = xmallocz(ENCODED_SIZE(resp_len));
encoded_len = EVP_EncodeBlock((unsigned char *)response_64,
-- 
2.8.1.104.g07d5700.dirty

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Response Required

[G89AHJ900]

Good day,
I wish to contact you personally for an important proposal that might be of 
interest to you. 
Regards,
shu...@qq.com
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 12/17] transport-helper: read helper response with strbuf_getline_crlf()

[Junio C Hamano]

Our implementation of helpers never use CRLF line endings, and they
do not depend on the ability to place a CR as payload at the end of
the line, so this is essentially a no-op for in-tree users.  However,
this allows third-party implementation of helpers to give us their
line with CRLF line ending (they cannot expect us to feed CRLF to
them, though).

Signed-off-by: Junio C Hamano 
---
 transport-helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/transport-helper.c b/transport-helper.c
index 63d5427..7de52e1 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -54,7 +54,7 @@ static int recvline_fh(FILE *helper, struct strbuf *buffer, 
const char *name)
strbuf_reset(buffer);
if (debug)
fprintf(stderr, "Debug: Remote helper: Waiting...\n");
-   if (strbuf_getline(buffer, helper, '\n') == EOF) {
+   if (strbuf_getline_crlf(buffer, helper) == EOF) {
if (debug)
fprintf(stderr, "Debug: Remote helper quit.\n");
return 1;
-- 
2.7.0-rc1-83-ga8b6b9e

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 12/17] transport-helper: read helper response with strbuf_gets()

[Junio C Hamano]

Our implementation of helpers never use CRLF line endings, and they
do not depend on the ability to place a CR as payload at the end of
the line, so this is essentially a no-op for in-tree users.  However,
this allows third-party implementation of helpers to give us their
line with CRLF line ending (they cannot expect us to feed CRLF to
them, though).

Signed-off-by: Junio C Hamano 
---
 transport-helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/transport-helper.c b/transport-helper.c
index 63d5427..e0e1c9c 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -54,7 +54,7 @@ static int recvline_fh(FILE *helper, struct strbuf *buffer, 
const char *name)
strbuf_reset(buffer);
if (debug)
fprintf(stderr, "Debug: Remote helper: Waiting...\n");
-   if (strbuf_getline(buffer, helper, '\n') == EOF) {
+   if (strbuf_gets(buffer, helper) == EOF) {
if (debug)
fprintf(stderr, "Debug: Remote helper quit.\n");
return 1;
-- 
2.6.2-423-g5314b62

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Response

[Wendy Nealon]

Sent from my Boost Mobile phone.

Re: Still waiting for your response

[Mrs. Supini Thrunkul]

Hello,

I am Mrs. Supini Thrunkul from Tai Yau Bank Hong Kong, I need your cooperation 
to transfer $ 47.3 million US Dollars to any trusted account within your 
control.

Contact me for more details.  

Mrs. Supini Thrunkul
Tel: +85 2580 848 65



--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Urgent Response.

[George Daniels]

Hello,
 I am George Daniels, a Banker and credit system programmer (HSBC bank).
I saw your email address while browsing through the bank D.T.C Screen in
 my office
 yesterday so I decided to use this very chance to know you. I believe
 we should use every opportunity to know each other better.

 However, I am contacting you for obvious reason which you will understand.
 I am sending this mail just to know if this email address is OK,
 reply me back so that I will send more details to you.
 I have a very important thing to discuss with you, I look forward to
 receiving your response at
 georgedaniels...@yahoo.com.hk. Have a pleasant day.

 George Daniels





















--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: This is sequel to your non-response of my earlier letter to you

[Barr Brenda Hoffman]

Dear Friend

After five years of waiting the crown (British government) has given me
the power to contact you so that you become the beneficiary to total
amount £15,000,000.00 GBP in the intent of the deceased who died without a
will.
I am contacting you because I believe you are related. Please if you are
interested respond immediately with your full names, physical address and
cell number.

Yours Truly,

Brenda Hoffman





-- 
DISCLAIMER:
---
 This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have received this email in error please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. Before opening any mail and attachments please 
check them for viruses and defect If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.
-
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

Regional Cancer Centre, Thiruvananthapuram
www.rcctvm.org

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: This is sequel to your non-response of my earlier letter to you

[Barr Brenda Hoffman]

Dear Friend

After five years of waiting the crown (British government) has given me
the power to contact you so that you become the beneficiary to total
amount £15,000,000.00 GBP in the intent of the deceased who died without a
will.
I am contacting you because I believe you are related. Please if you are
interested respond immediately with your full names, physical address and
cell number.

Yours Truly,

Brenda Hoffman





-- 
DISCLAIMER:
---
 This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have received this email in error please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. Before opening any mail and attachments please 
check them for viruses and defect If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.
-
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

Regional Cancer Centre, Thiruvananthapuram
www.rcctvm.org

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 12/14] reduce confusion over smart server response behaviour

[Tay Ray Chuan]

The MUST and the following 'If' scenario may seem contradictory at first
glance; swap their order to alleviate this.

Also mention that the response should specifically be for the requested
service, for clarity's sake.

Based on:

  From:   Junio C Hamano gits...@pobox.com
  Message-ID: 7vskdss3ei@alter.siamese.dyndns.org

   +Smart Server Response
   +^
   +
   +Smart servers MUST respond with the smart server reply format.
   +If the server does not recognize the requested service name, or the
   +requested service name has been disabled by the server administrator,
   +the server MUST respond with the '403 Forbidden' HTTP status code.

  This is a bit confusing.

  If you as a server administrator want to disable the smart upload-pack for
  one repository (but not for other repositories), you would not be able to
  force smart clients to fall back to the dumb protocol by giving 403 for
  that repository.

  Maybe in 2 years somebody smarter than us will have invented a more
  efficient git-upload-pack-2 service, which is the only fetch protocol his
  server supports other than dumb.  If your v1 smart client asks for the
  original git-upload-pack service and gets a 403, you won't be able to
  fall back to dumb.

  The solution for such cases likely is to pretend as if you are a dumb
  server for the smart request.  That unfortunately means that the first
  sentence is misleading, and the second sentence is also an inappropriate
  advice.

Signed-off-by: Tay Ray Chuan rcta...@gmail.com
---
 Documentation/technical/http-protocol.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/technical/http-protocol.txt 
b/Documentation/technical/http-protocol.txt
index 4bb1614..63a089a 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -234,12 +234,13 @@ description of the dumb server response.
 
 Smart Server Response
 ^
-Smart servers MUST respond with the smart server reply format.
-
 If the server does not recognize the requested service name, or the
 requested service name has been disabled by the server administrator,
 the server MUST respond with the '403 Forbidden' HTTP status code.
 
+Otherwise, smart servers MUST respond with the smart server reply
+format for the requested service name.
+
 Cache-Control headers SHOULD be used to disable caching of the
 returned entity.
 
-- 
1.8.4.rc4.527.g303b16c

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitweb patch, no response

[Junio C Hamano]

Christopher Durkin cjdur...@gmail.com writes:

 I submitted a small feature addition patch for gitweb (see
 http://article.gmane.org/gmane.comp.version-control.git/232327/match=gitweb)
 a couple of weeks ago.

 I didn't get any responses, good or bad. Was there something wrong
 with my submission in terms of formatting? Something else that I
 missed? Any suggestions are greatly appreciated.

It either fell through cracks, as this is a high traffic list, or
nobody was interested in seeing the new feature.

Thanks for a pointer; I'll take a look at it soonish.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

gitweb patch, no response

[Christopher Durkin]

I submitted a small feature addition patch for gitweb (see
http://article.gmane.org/gmane.comp.version-control.git/232327/match=gitweb)
a couple of weeks ago.

I didn't get any responses, good or bad. Was there something wrong
with my submission in terms of formatting? Something else that I
missed? Any suggestions are greatly appreciated.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

URGENT RESPONSE!!

[GEORGE DANIELS]

Greetings from George Daniels

I am George Daniels, a Banker and credit system programmer (HSBC bank).
I saw your email address while browsing through  the bank D.T.C Screen in
my office
yesterday so I decided to use this very chance to know you. I believe
we should use every opportunity to know each other better.

However, I am contacting you for obvious reason which you will understand.
I am sending this mail just to know if this email address is OK,
reply me back so that I will send  more details to you.
I have a very important thing to discuss with you, I look forward to
receiving your response at
georgedaniels...@yahoo.com.hk. Have a pleasant day.

George Daniels







--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

URGENT RESPONSE!!

[GEORGE DANIELS]

Greetings from George Daniels

I am George Daniels, a Banker and credit system programmer (HSBC bank).
I saw your email address while browsing through  the bank D.T.C Screen in
my office
yesterday so I decided to use this very chance to know you. I believe
we should use every opportunity to know each other better.

However, I am contacting you for obvious reason which you will understand.
I am sending this mail just to know if this email address is OK,
reply me back so that I will send  more details to you.
I have a very important thing to discuss with you, I look forward to
receiving your response at
georgedaniels...@yahoo.com.hk. Have a pleasant day.

George Daniels























































--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

URGENT RESPONSE!!

[GEORGE DANIELS]

Greetings from George Daniels

I am George Daniels, a Banker and credit system programmer (HSBC bank).
I saw your email address while browsing through  the bank D.T.C Screen in
my office
yesterday so I decided to use this very chance to know you. I believe
we should use every opportunity to know each other better.

However, I am contacting you for obvious reason which you will understand.
I am sending this mail just to know if this email address is OK,
reply me back so that I will send  more details to you.
I have a very important thing to discuss with you, I look forward to
receiving your response at
georgedaniels...@yahoo.com.hk. Have a pleasant day.

George Daniels















































--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[S390] cio: make sense id procedure work with partial hardware response

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6f52ac29712f3eec192599249b12612360948646
Commit: 6f52ac29712f3eec192599249b12612360948646
Parent: 9ef9dc69d4167276c04590d67ee55de8380bc1ad
Author: Peter Oberparleiter [EMAIL PROTECTED]
AuthorDate: Tue Feb 5 16:50:33 2008 +0100
Committer:  Martin Schwidefsky [EMAIL PROTECTED]
CommitDate: Tue Feb 5 16:50:52 2008 +0100

[S390] cio: make sense id procedure work with partial hardware response

In some cases the current sense id procedure trips over incomplete
hardware responses. In these cases, checking against the preset value
of 0x is not enough. More critically, the VM DIAG call will always be
considered to have provided data after such an incident, even if it was not
successful at all.

The solution is to always initialize the control unit data before doing a
sense id call. Check the condition code before considering the control unit
data. And initialize again, before evaluating the VM data.

Signed-off-by: Peter Oberparleiter [EMAIL PROTECTED]
Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED]
---
 drivers/s390/cio/device_id.c |  107 +-
 1 files changed, 64 insertions(+), 43 deletions(-)

diff --git a/drivers/s390/cio/device_id.c b/drivers/s390/cio/device_id.c
index 918b8b8..dc4d87f 100644
--- a/drivers/s390/cio/device_id.c
+++ b/drivers/s390/cio/device_id.c
@@ -26,17 +26,18 @@
 #include ioasm.h
 #include io_sch.h
 
-/*
- * Input :
- *   devno - device number
- *   ps   - pointer to sense ID data area
- * Output : none
+/**
+ * vm_vdev_to_cu_type - Convert vm virtual device into control unit type
+ * for certain devices.
+ * @class: virtual device class
+ * @type: virtual device type
+ *
+ * Returns control unit type if a match was made or %0x otherwise.
  */
-static void
-VM_virtual_device_info (__u16 devno, struct senseid *ps)
+static int vm_vdev_to_cu_type(int class, int type)
 {
static struct {
-   int vrdcvcla, vrdcvtyp, cu_type;
+   int class, type, cu_type;
} vm_devices[] = {
{ 0x08, 0x01, 0x3480 },
{ 0x08, 0x02, 0x3430 },
@@ -68,8 +69,26 @@ VM_virtual_device_info (__u16 devno, struct senseid *ps)
{ 0x40, 0xc0, 0x5080 },
{ 0x80, 0x00, 0x3215 },
};
+   int i;
+
+   for (i = 0; i  ARRAY_SIZE(vm_devices); i++)
+   if (class == vm_devices[i].class  type == vm_devices[i].type)
+   return vm_devices[i].cu_type;
+
+   return 0x;
+}
+
+/**
+ * diag_get_dev_info - retrieve device information via DIAG X'210'
+ * @devno: device number
+ * @ps: pointer to sense ID data area
+ *
+ * Returns zero on success, non-zero otherwise.
+ */
+static int diag_get_dev_info(u16 devno, struct senseid *ps)
+{
struct diag210 diag_data;
-   int ccode, i;
+   int ccode;
 
CIO_TRACE_EVENT (4, VMvdinf);
 
@@ -79,21 +98,21 @@ VM_virtual_device_info (__u16 devno, struct senseid *ps)
};
 
ccode = diag210 (diag_data);
-   ps-reserved = 0xff;
+   if ((ccode == 0) || (ccode == 2)) {
+   ps-reserved = 0xff;
 
-   /* Special case for bloody osa devices. */
-   if (diag_data.vrdcvcla == 0x02 
-   diag_data.vrdcvtyp == 0x20) {
-   ps-cu_type = 0x3088;
-   ps-cu_model = 0x60;
-   return;
-   }
-   for (i = 0; i  ARRAY_SIZE(vm_devices); i++)
-   if (diag_data.vrdcvcla == vm_devices[i].vrdcvcla 
-   diag_data.vrdcvtyp == vm_devices[i].vrdcvtyp) {
-   ps-cu_type = vm_devices[i].cu_type;
-   return;
+   /* Special case for osa devices. */
+   if (diag_data.vrdcvcla == 0x02  diag_data.vrdcvtyp == 0x20) {
+   ps-cu_type = 0x3088;
+   ps-cu_model = 0x60;
+   return 0;
}
+   ps-cu_type = vm_vdev_to_cu_type(diag_data.vrdcvcla,
+   diag_data.vrdcvtyp);
+   if (ps-cu_type != 0x)
+   return 0;
+   }
+
CIO_MSG_EVENT(0, DIAG X'210' for device %04X returned (cc = %d):
  vdev class : %02X, vdev type : %04X \n ...  
  rdev class : %02X, rdev type : %04X, 
@@ -102,6 +121,8 @@ VM_virtual_device_info (__u16 devno, struct senseid *ps)
  diag_data.vrdcvcla, diag_data.vrdcvtyp,
  diag_data.vrdcrccl, diag_data.vrdccrty,
  diag_data.vrdccrmd);
+
+   return -ENODEV;
 }
 
 /*
@@ -130,6 +151,7 @@ __ccw_device_sense_id_start(struct ccw_device *cdev)
/* Try on every path. */
ret = -ENODEV;
while (cdev-private-imask != 0) {
+   cdev-private-senseid.cu_type

[S390] cio: Clean up chsc response code handling.

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b9c9a21a7c8faeff1d13a23d2c57a5d4b512cfa0
Commit: b9c9a21a7c8faeff1d13a23d2c57a5d4b512cfa0
Parent: 6f52ac29712f3eec192599249b12612360948646
Author: Cornelia Huck [EMAIL PROTECTED]
AuthorDate: Tue Feb 5 16:50:34 2008 +0100
Committer:  Martin Schwidefsky [EMAIL PROTECTED]
CommitDate: Tue Feb 5 16:50:53 2008 +0100

[S390] cio: Clean up chsc response code handling.

This provides unified return codes for common response codes and
also makes the debug feature messages more similar and informational.

Signed-off-by: Cornelia Huck [EMAIL PROTECTED]
Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED]
---
 drivers/s390/cio/chsc.c |  147 ++-
 1 files changed, 55 insertions(+), 92 deletions(-)

diff --git a/drivers/s390/cio/chsc.c b/drivers/s390/cio/chsc.c
index e7ba16a..007aaeb 100644
--- a/drivers/s390/cio/chsc.c
+++ b/drivers/s390/cio/chsc.c
@@ -26,6 +26,25 @@
 
 static void *sei_page;
 
+static int chsc_error_from_response(int response)
+{
+   switch (response) {
+   case 0x0001:
+   return 0;
+   case 0x0002:
+   case 0x0003:
+   case 0x0006:
+   case 0x0007:
+   case 0x0008:
+   case 0x000a:
+   return -EINVAL;
+   case 0x0004:
+   return -EOPNOTSUPP;
+   default:
+   return -EIO;
+   }
+}
+
 struct chsc_ssd_area {
struct chsc_header request;
u16 :10;
@@ -75,11 +94,11 @@ int chsc_get_ssd_info(struct subchannel_id schid, struct 
chsc_ssd_info *ssd)
ret = (ccode == 3) ? -ENODEV : -EBUSY;
goto out_free;
}
-   if (ssd_area-response.code != 0x0001) {
+   ret = chsc_error_from_response(ssd_area-response.code);
+   if (ret != 0) {
CIO_MSG_EVENT(2, chsc: ssd failed for 0.%x.%04x (rc=%04x)\n,
  schid.ssid, schid.sch_no,
  ssd_area-response.code);
-   ret = -EIO;
goto out_free;
}
if (!ssd_area-sch_valid) {
@@ -717,36 +736,15 @@ __chsc_do_secm(struct channel_subsystem *css, int enable, 
void *page)
return (ccode == 3) ? -ENODEV : -EBUSY;
 
switch (secm_area-response.code) {
-   case 0x0001: /* Success. */
-   ret = 0;
-   break;
-   case 0x0003: /* Invalid block. */
-   case 0x0007: /* Invalid format. */
-   case 0x0008: /* Other invalid block. */
-   CIO_CRW_EVENT(2, Error in chsc request block!\n);
-   ret = -EINVAL;
-   break;
-   case 0x0004: /* Command not provided in model. */
-   CIO_CRW_EVENT(2, Model does not provide secm\n);
-   ret = -EOPNOTSUPP;
-   break;
-   case 0x0102: /* cub adresses incorrect */
-   CIO_CRW_EVENT(2, Invalid addresses in chsc request block\n);
-   ret = -EINVAL;
-   break;
-   case 0x0103: /* key error */
-   CIO_CRW_EVENT(2, Access key error in secm\n);
+   case 0x0102:
+   case 0x0103:
ret = -EINVAL;
-   break;
-   case 0x0105: /* error while starting */
-   CIO_CRW_EVENT(2, Error while starting channel measurement\n);
-   ret = -EIO;
-   break;
default:
-   CIO_CRW_EVENT(2, Unknown CHSC response %d\n,
- secm_area-response.code);
-   ret = -EIO;
+   ret = chsc_error_from_response(secm_area-response.code);
}
+   if (ret != 0)
+   CIO_CRW_EVENT(2, chsc: secm failed (rc=%04x)\n,
+ secm_area-response.code);
return ret;
 }
 
@@ -827,27 +825,14 @@ int chsc_determine_channel_path_description(struct chp_id 
chpid,
goto out;
}
 
-   switch (scpd_area-response.code) {
-   case 0x0001: /* Success. */
+   ret = chsc_error_from_response(scpd_area-response.code);
+   if (ret == 0)
+   /* Success. */
memcpy(desc, scpd_area-desc,
   sizeof(struct channel_path_desc));
-   ret = 0;
-   break;
-   case 0x0003: /* Invalid block. */
-   case 0x0007: /* Invalid format. */
-   case 0x0008: /* Other invalid block. */
-   CIO_CRW_EVENT(2, Error in chsc request block!\n);
-   ret = -EINVAL;
-   break;
-   case 0x0004: /* Command not provided in model. */
-   CIO_CRW_EVENT(2, Model does not provide scpd\n);
-   ret = -EOPNOTSUPP;
-   break;
-   default:
-   CIO_CRW_EVENT(2, Unknown CHSC response %d\n,
+   else
+   CIO_CRW_EVENT(2, chsc: scpd failed (rc=%04x)\n,
  scpd_area-response.code);
-   ret = -EIO

sata_mv ncq Ignore response status LSB on NCQ

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=cb92441973ebd71d556fc7cdd9e597582327dd71
Commit: cb92441973ebd71d556fc7cdd9e597582327dd71
Parent: 8c0aeb4a483334613336ef895f34cecc0ecbbfa6
Author: Mark Lord [EMAIL PROTECTED]
AuthorDate: Sat Jan 26 18:32:09 2008 -0500
Committer:  Jeff Garzik [EMAIL PROTECTED]
CommitDate: Fri Feb 1 11:29:47 2008 -0500

sata_mv ncq Ignore response status LSB on NCQ

The lower 8 bits of response status are not valid for NCQ.

Signed-off-by: Mark Lord [EMAIL PROTECTED]
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
---
 drivers/ata/sata_mv.c |9 -
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index c602558..207c400 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -1590,13 +1590,12 @@ static void mv_intr_edma(struct ata_port *ap)
 
qc = ata_qc_from_tag(ap, tag);
 
-   /* lower 8 bits of status are EDMA_ERR_IRQ_CAUSE_OFS
-* bits (WARNING: might not necessarily be associated
-* with this command), which -should- be clear
-* if all is well
+   /* For non-NCQ mode, the lower 8 bits of status
+* are from EDMA_ERR_IRQ_CAUSE_OFS,
+* which should be zero if all went well.
 */
status = le16_to_cpu(pp-crpb[out_index].flags);
-   if (unlikely(status  0xff)) {
+   if ((status  0xff)  !(pp-pp_flags  MV_PP_FLAG_NCQ_EN)) {
mv_err_intr(ap, qc);
return;
}
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

libertas: ensure response buffer size is always set for lbs_cmd_with_response

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9fae899c2b5dc224042da63b14118abdb22ae9b6
Commit: 9fae899c2b5dc224042da63b14118abdb22ae9b6
Parent: 3399ea5f239d49522212db179bca4de9e84b09df
Author: David Woodhouse [EMAIL PROTECTED]
AuthorDate: Sat Dec 15 03:46:44 2007 -0500
Committer:  David S. Miller [EMAIL PROTECTED]
CommitDate: Mon Jan 28 15:07:37 2008 -0800

libertas: ensure response buffer size is always set for 
lbs_cmd_with_response

Signed-off-by: David Woodhouse [EMAIL PROTECTED]
Signed-off-by: John W. Linville [EMAIL PROTECTED]
---
 drivers/net/wireless/libertas/cmd.c|4 +++-
 drivers/net/wireless/libertas/cmd.h|4 
 drivers/net/wireless/libertas/if_usb.c |1 +
 3 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/libertas/cmd.c 
b/drivers/net/wireless/libertas/cmd.c
index 3079b3f..c3d7f60 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -115,6 +115,7 @@ int lbs_host_sleep_cfg(struct lbs_private *priv, uint32_t 
criteria)
struct cmd_ds_host_sleep cmd_config;
int ret;
 
+   cmd_config.hdr.size = cpu_to_le16(sizeof(cmd_config));
cmd_config.criteria = cpu_to_le32(criteria);
cmd_config.gpio = priv-wol_gpio;
cmd_config.gap = priv-wol_gap;
@@ -1101,7 +1102,7 @@ int lbs_mesh_access(struct lbs_private *priv, uint16_t 
cmd_action,
lbs_deb_enter_args(LBS_DEB_CMD, action %d, cmd_action);
 
cmd-hdr.command = cpu_to_le16(CMD_MESH_ACCESS);
-   cmd-hdr.size = cpu_to_le16(sizeof(struct cmd_ds_mesh_access) + 
S_DS_GEN);
+   cmd-hdr.size = cpu_to_le16(sizeof(*cmd));
cmd-hdr.result = 0;
 
cmd-action = cpu_to_le16(cmd_action);
@@ -1121,6 +1122,7 @@ int lbs_mesh_config(struct lbs_private *priv, uint16_t 
enable, uint16_t chan)
cmd.action = cpu_to_le16(enable);
cmd.channel = cpu_to_le16(chan);
cmd.type = cpu_to_le16(priv-mesh_tlv);
+   cmd.hdr.size = cpu_to_le16(sizeof(cmd));
 
if (enable) {
cmd.length = cpu_to_le16(priv-mesh_ssid_len);
diff --git a/drivers/net/wireless/libertas/cmd.h 
b/drivers/net/wireless/libertas/cmd.h
index 2f4c1ec..e334f0e 100644
--- a/drivers/net/wireless/libertas/cmd.h
+++ b/drivers/net/wireless/libertas/cmd.h
@@ -9,6 +9,10 @@
 #define lbs_cmd(priv, cmdnr, cmd, cb, cb_arg)  \
__lbs_cmd(priv, cmdnr, (cmd)-hdr, sizeof(*(cmd)), cb, cb_arg)
 
+
+/* lbs_cmd_with_response() infers the size of the command to be _sent_
+   and requires that the caller sets cmd-size to the (LE) size of
+   the _response_ buffer. */
 #define lbs_cmd_with_response(priv, cmdnr, cmd)\
lbs_cmd(priv, cmdnr, cmd, lbs_cmd_copyback, (unsigned long) (cmd))
 
diff --git a/drivers/net/wireless/libertas/if_usb.c 
b/drivers/net/wireless/libertas/if_usb.c
index cf88251..8bc23b3 100644
--- a/drivers/net/wireless/libertas/if_usb.c
+++ b/drivers/net/wireless/libertas/if_usb.c
@@ -106,6 +106,7 @@ static void if_usb_set_boot2_ver(struct lbs_private *priv)
 {
struct cmd_ds_set_boot2_ver b2_cmd;
 
+   b2_cmd.hdr.size = cpu_to_le16(sizeof(b2_cmd));
b2_cmd.action = 0;
b2_cmd.version = priv-boot2_version;
 
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

mac80211: don't read ERP information from (re)association response

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c27f9830f367a041ca976ccd102f590d27d4deb2
Commit: c27f9830f367a041ca976ccd102f590d27d4deb2
Parent: 176e4f84423af3105894a7d71b23c1a16678a6be
Author: Johannes Berg [EMAIL PROTECTED]
AuthorDate: Wed Dec 19 23:38:24 2007 +0100
Committer:  David S. Miller [EMAIL PROTECTED]
CommitDate: Mon Jan 28 14:59:54 2008 -0800

mac80211: don't read ERP information from (re)association response

According to the standard, the field cannot be present, so don't
try to interpret it either.

Signed-off-by: Johannes Berg [EMAIL PROTECTED]
Cc: Daniel Drake [EMAIL PROTECTED]
Signed-off-by: John W. Linville [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]
---
 net/mac80211/ieee80211_sta.c |   14 --
 1 files changed, 0 insertions(+), 14 deletions(-)

diff --git a/net/mac80211/ieee80211_sta.c b/net/mac80211/ieee80211_sta.c
index 2e225ae..5b8f484 100644
--- a/net/mac80211/ieee80211_sta.c
+++ b/net/mac80211/ieee80211_sta.c
@@ -1371,20 +1371,6 @@ static void ieee80211_rx_mgmt_assoc_resp(struct 
net_device *dev,
return;
}
 
-   /* it probably doesn't, but if the frame includes an ERP value then
-* update our stored copy */
-   if (elems.erp_info  elems.erp_info_len = 1) {
-   struct ieee80211_sta_bss *bss
-   = ieee80211_rx_bss_get(dev, ifsta-bssid,
-  local-hw.conf.channel,
-  ifsta-ssid, ifsta-ssid_len);
-   if (bss) {
-   bss-erp_value = elems.erp_info[0];
-   bss-has_erp_value = 1;
-   ieee80211_rx_bss_put(dev, bss);
-   }
-   }
-
printk(KERN_DEBUG %s: associated\n, dev-name);
ifsta-aid = aid;
ifsta-ap_capab = capab_info;
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[DCCP]: Handle timestamps on Request/Response exchange separately

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b4d4f7c70fd3361c6c889752e08ea9be304cf5f4
Commit: b4d4f7c70fd3361c6c889752e08ea9be304cf5f4
Parent: 8109616e2ef978d142ea45850efd4f102b9bdce4
Author: Gerrit Renker [EMAIL PROTECTED]
AuthorDate: Thu Dec 13 12:37:19 2007 -0200
Committer:  David S. Miller [EMAIL PROTECTED]
CommitDate: Mon Jan 28 14:57:51 2008 -0800

[DCCP]: Handle timestamps on Request/Response exchange separately

In DCCP, timestamps can occur on packets anytime, CCID3 uses a 
timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small 
time in between:
* the first timestamp value gets overwritten by the second connection 
request.

This is not really good, so this patch separates timestamps into
 * those which are received by the server during the initial handshake (on 
dccp_request_sock);
 * those which are received by the client or the client after connection 
establishment.

As before, a timestamp of 0 is regarded as indicating that no (meaningful) 
timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued 
timestamps).

The timestamp-echoing now works as follows:
 * when a timestamp is present on the initial Request, it is placed into 
dreq, due to the
   call to dccp_parse_options in dccp_v{4,6}_conn_request;
 * when a timestamp is present on the Ack leading from RESPOND = OPEN, it 
is copied over
   from the request_sock into the child cocket in dccp_create_openreq_child;
 * timestamps received on an (established) dccp_sock are treated as before.

Since Elapsed Time is measured in hundredths of milliseconds (13.2), the 
new dccp_timestamp()
function is used, as it is expected that the time between receiving the 
timestamp and
sending the timestamp echo will be very small against the wrap-around time. 
As a byproduct,
this allows smaller timestamping-time fields.

Furthermore, inserting the Timestamp Echo option has been taken out of the 
block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any 
packet (5.8 and 13.3).

Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
Acked-by: Ian McDonald [EMAIL PROTECTED]
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]
---
 include/linux/dccp.h |   16 -
 net/dccp/minisocks.c |   21 +++---
 net/dccp/options.c   |   56 -
 3 files changed, 63 insertions(+), 30 deletions(-)

diff --git a/include/linux/dccp.h b/include/linux/dccp.h
index 7214031..484e45c 100644
--- a/include/linux/dccp.h
+++ b/include/linux/dccp.h
@@ -407,11 +407,23 @@ struct dccp_opt_pend {
 
 extern void dccp_minisock_init(struct dccp_minisock *dmsk);
 
+/**
+ * struct dccp_request_sock  -  represent DCCP-specific connection request
+ * @dreq_inet_rsk: structure inherited from
+ * @dreq_iss: initial sequence number sent on the Response (RFC 4340, 7.1)
+ * @dreq_isr: initial sequence number received on the Request
+ * @dreq_service: service code present on the Request (there is just one)
+ * The following two fields are analogous to the ones in dccp_sock:
+ * @dreq_timestamp_echo: last received timestamp to echo (13.1)
+ * @dreq_timestamp_echo: the time of receiving the last @dreq_timestamp_echo
+ */
 struct dccp_request_sock {
struct inet_request_sock dreq_inet_rsk;
__u64dreq_iss;
__u64dreq_isr;
__be32   dreq_service;
+   __u32dreq_timestamp_echo;
+   __u32dreq_timestamp_time;
 };
 
 static inline struct dccp_request_sock *dccp_rsk(const struct request_sock 
*req)
@@ -477,8 +489,8 @@ struct dccp_ackvec;
  * @dccps_gar - greatest valid ack number received on a non-Sync; initialized 
to %dccps_iss
  * @dccps_service - first (passive sock) or unique (active sock) service code
  * @dccps_service_list - second .. last service code on passive socket
- * @dccps_timestamp_time - time of latest TIMESTAMP option
  * @dccps_timestamp_echo - latest timestamp received on a TIMESTAMP option
+ * @dccps_timestamp_time - time of receiving latest @dccps_timestamp_echo
  * @dccps_l_ack_ratio - feature-local Ack Ratio
  * @dccps_r_ack_ratio - feature-remote Ack Ratio
  * @dccps_pcslen - sender   partial checksum coverage (via sockopt)
@@ -514,8 +526,8 @@ struct dccp_sock {
__u64   dccps_gar;
__be32  dccps_service;
struct dccp_service_list*dccps_service_list;
-   ktime_t

[CIFS] Fix buffer overflow if server sends corrupt response to small

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=133672efbc1085f9af990bdc145e1822ea93bcf3
Commit: 133672efbc1085f9af990bdc145e1822ea93bcf3
Parent: 9418d5dc9ba40b88737580457bf3b7c63c60ec43
Author: Steve French [EMAIL PROTECTED]
AuthorDate: Tue Nov 13 22:41:37 2007 +
Committer:  Steve French [EMAIL PROTECTED]
CommitDate: Tue Nov 13 22:41:37 2007 +

[CIFS] Fix buffer overflow if server sends corrupt response to small
request

In SendReceive() function in transport.c - it memcpy's
message payload into a buffer passed via out_buf param. The function
assumes that all buffers are of size (CIFSMaxBufSize +
MAX_CIFS_HDR_SIZE) , unfortunately it is also called with smaller
(MAX_CIFS_SMALL_BUFFER_SIZE) buffers.  There are eight callers
(SMB worker functions) which are primarily affected by this change:

TreeDisconnect, uLogoff, Close, findClose, SetFileSize, SetFileTimes,
Lock and PosixLock

CC: Dave Kleikamp [EMAIL PROTECTED]
CC: Przemyslaw Wegrzyn [EMAIL PROTECTED]
Acked-by: Jeff Layton [EMAIL PROTECTED]
Signed-off-by: Steve French [EMAIL PROTECTED]
---
 fs/cifs/cifsglob.h  |   11 ++
 fs/cifs/cifsproto.h |5 ++-
 fs/cifs/cifssmb.c   |   97 +++
 fs/cifs/connect.c   |9 +++--
 fs/cifs/file.c  |   14 
 fs/cifs/sess.c  |2 +-
 fs/cifs/transport.c |   91 ---
 7 files changed, 133 insertions(+), 96 deletions(-)

diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
index 87f51f2..4ff8179 100644
--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -471,6 +471,17 @@ struct dir_notify_req {
 #define   CIFS_LARGE_BUFFER 2
 #define   CIFS_IOVEC4/* array of response buffers */
 
+/* Type of Request to SendReceive2 */
+#define   CIFS_STD_OP  0/* normal request timeout */
+#define   CIFS_LONG_OP  1/* long op (up to 45 sec, oplock time) */
+#define   CIFS_VLONG_OP 2/* sloow op - can take up to 180 seconds 
*/
+#define   CIFS_BLOCKING_OP  4/* operation can block */
+#define   CIFS_ASYNC_OP 8/* do not wait for response */
+#define   CIFS_TIMEOUT_MASK 0x00F/* only one of 5 above set in req */
+#define   CIFS_LOG_ERROR0x010/* log NT STATUS if non-zero */
+#define   CIFS_LARGE_BUF_OP 0x020/* large request buffer */
+#define   CIFS_NO_RESP  0x040/* no response buffer required */
+
 /* Security Flags: indicate type of session setup needed */
 #define   CIFSSEC_MAY_SIGN 0x1
 #define   CIFSSEC_MAY_NTLM 0x2
diff --git a/fs/cifs/cifsproto.h b/fs/cifs/cifsproto.h
index dd1d7c2..0c55dff 100644
--- a/fs/cifs/cifsproto.h
+++ b/fs/cifs/cifsproto.h
@@ -48,10 +48,11 @@ extern int SendReceive(const unsigned int /* xid */ , 
struct cifsSesInfo *,
struct smb_hdr * /* input */ ,
struct smb_hdr * /* out */ ,
int * /* bytes returned */ , const int long_op);
+extern int SendReceiveNoRsp(const unsigned int xid, struct cifsSesInfo *ses,
+   struct smb_hdr *in_buf, int flags);
 extern int SendReceive2(const unsigned int /* xid */ , struct cifsSesInfo *,
struct kvec *, int /* nvec to send */,
-   int * /* type of buf returned */ , const int long_op,
-   const int logError /* whether to log status code*/ );
+   int * /* type of buf returned */ , const int flags);
 extern int SendReceiveBlockingLock(const unsigned int /* xid */ ,
struct cifsTconInfo *,
struct smb_hdr * /* input */ ,
diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index 59d7b7c..9e8a6be 100644
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -698,9 +698,7 @@ int
 CIFSSMBTDis(const int xid, struct cifsTconInfo *tcon)
 {
struct smb_hdr *smb_buffer;
-   struct smb_hdr *smb_buffer_response; /* BB removeme BB */
int rc = 0;
-   int length;
 
cFYI(1, (In tree disconnect));
/*
@@ -737,16 +735,12 @@ CIFSSMBTDis(const int xid, struct cifsTconInfo *tcon)
if (rc) {
up(tcon-tconSem);
return rc;
-   } else {
-   smb_buffer_response = smb_buffer; /* BB removeme BB */
}
-   rc = SendReceive(xid, tcon-ses, smb_buffer, smb_buffer_response,
-length, 0);
+
+   rc = SendReceiveNoRsp(xid, tcon-ses, smb_buffer, 0);
if (rc)
cFYI(1, (Tree disconnect failed %d, rc));
 
-   if (smb_buffer)
-   cifs_small_buf_release(smb_buffer);
up(tcon-tconSem);
 
/* No need to return error on this operation if tid invalidated and
@@ -760,10 +754,8 @@ CIFSSMBTDis(const int xid, struct cifsTconInfo *tcon)
 int
 CIFSSMBLogoff(const int xid

[SCSI] qla1280: eliminate wasted space in request and response ring

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=20d2d3afa87781fe2674ce17bfb16af08a436e81
Commit: 20d2d3afa87781fe2674ce17bfb16af08a436e81
Parent: fc2adcfd37f6f1c32d246b5b43f83e38233358ae
Author: Johannes Dickgreber [EMAIL PROTECTED]
AuthorDate: Thu Sep 20 01:07:50 2007 +0200
Committer:  James Bottomley [EMAIL PROTECTED]
CommitDate: Tue Oct 23 12:35:35 2007 -0400

[SCSI] qla1280: eliminate wasted space in request and response ring

i think there is wasted space in allocated pages for request and
response rings.  The allocations are made with REQUEST_ENTRY_CNT + 1
and RESPONSE_ENTRY_CNT + 1, but they are set with 256 and 16.

So we got more pages, which we dont use very much so eliminate them.

Signed-off-by: Johannes Dickgreber [EMAIL PROTECTED]
Acked-by: Jes Sorensen [EMAIL PROTECTED]
Signed-off-by: James Bottomley [EMAIL PROTECTED]
---
 drivers/scsi/qla1280.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/qla1280.h b/drivers/scsi/qla1280.h
index 59915fb..ff2c363 100644
--- a/drivers/scsi/qla1280.h
+++ b/drivers/scsi/qla1280.h
@@ -91,8 +91,8 @@
 #define INVALID_HANDLE (MAX_OUTSTANDING_COMMANDS + 2)
 
 /* ISP request and response entry counts (37-65535) */
-#define REQUEST_ENTRY_CNT  256 /* Number of request entries. */
-#define RESPONSE_ENTRY_CNT 16  /* Number of response entries. */
+#define REQUEST_ENTRY_CNT  255 /* Number of request entries. */
+#define RESPONSE_ENTRY_CNT 63  /* Number of response entries. */
 
 /*
  * SCSI Request Block structure  (sp)  that is placed
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[CIFS] parse server_GUID in SPNEGO negProt response

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e187e44eb8902089da0c7725d606b0e20fee981d
Commit: e187e44eb8902089da0c7725d606b0e20fee981d
Parent: 7111d2144f17155b66e89b3655fcddbedefcf8a6
Author: Jeff Layton [EMAIL PROTECTED]
AuthorDate: Tue Oct 16 17:10:44 2007 +
Committer:  Steve French [EMAIL PROTECTED]
CommitDate: Tue Oct 16 17:10:44 2007 +

[CIFS] parse server_GUID in SPNEGO negProt response

SPNEGO NegProt response also contains a server_GUID. Parse it as we
would for RawNTLMSSP.

Signed-off-by: Jeff Layton [EMAIL PROTECTED]
Signed-off-by: Steve French [EMAIL PROTECTED]
---
 fs/cifs/cifssmb.c |   32 ++--
 1 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index 9eef724..14dabbb 100644
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -621,22 +621,26 @@ CIFSSMBNegotiate(unsigned int xid, struct cifsSesInfo 
*ses)
if ((pSMBr-hdr.Flags2  SMBFLG2_EXT_SEC) 
(server-capabilities  CAP_EXTENDED_SECURITY)) {
count = pSMBr-ByteCount;
-   if (count  16)
+   if (count  16) {
rc = -EIO;
-   else if (count == 16) {
-   server-secType = RawNTLMSSP;
-   if (server-socketUseCount.counter  1) {
-   if (memcmp(server-server_GUID,
-  pSMBr-u.extended_response.
-  GUID, 16) != 0) {
-   cFYI(1, (server UID changed));
-   memcpy(server-server_GUID,
-   pSMBr-u.extended_response.GUID,
-   16);
-   }
-   } else
+   goto neg_err_exit;
+   }
+
+   if (server-socketUseCount.counter  1) {
+   if (memcmp(server-server_GUID,
+  pSMBr-u.extended_response.
+  GUID, 16) != 0) {
+   cFYI(1, (server UID changed));
memcpy(server-server_GUID,
-  pSMBr-u.extended_response.GUID, 16);
+   pSMBr-u.extended_response.GUID,
+   16);
+   }
+   } else
+   memcpy(server-server_GUID,
+  pSMBr-u.extended_response.GUID, 16);
+
+   if (count == 16) {
+   server-secType = RawNTLMSSP;
} else {
rc = decode_negTokenInit(pSMBr-u.extended_response.
 SecurityBlob,
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[CIFS] Print better error when server returns malformed QueryUnixInfo response

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1e71f25d14d70f2bf607b40ab6d7e18daca57f36
Commit: 1e71f25d14d70f2bf607b40ab6d7e18daca57f36
Parent: 5a44b3190e3441986648ff664ef045685995324b
Author: Steve French [EMAIL PROTECTED]
AuthorDate: Thu Sep 20 15:30:07 2007 +
Committer:  Steve French [EMAIL PROTECTED]
CommitDate: Thu Sep 20 15:30:07 2007 +

[CIFS] Print better error when server returns malformed QueryUnixInfo 
response

Signed-off-by: Steve French [EMAIL PROTECTED]
---
 fs/cifs/cifssmb.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index bb30455..f33c89c 100644
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -3361,6 +3361,9 @@ UnixQPathInfoRetry:
rc = validate_t2((struct smb_t2_rsp *)pSMBr);
 
if (rc || (pSMBr-ByteCount  sizeof(FILE_UNIX_BASIC_INFO))) {
+   cERROR(1, (Malformed FILE_UNIX_BASIC_INFO response.\n
+  Unix Extensions can be disabled on mount 
+  by specifying the nosfu mount option.));
rc = -EIO;  /* bad smb */
} else {
__u16 data_offset = le16_to_cpu(pSMBr-t2.DataOffset);
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

IB/core: Fix handling of multicast response failures

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=57cb61d587e990d556385d367589ff61f6c2c0f2
Commit: 57cb61d587e990d556385d367589ff61f6c2c0f2
Parent: 9faa559c01311281f26544291322252327b65922
Author: Ralph Campbell [EMAIL PROTECTED]
AuthorDate: Thu Sep 20 16:33:44 2007 -0700
Committer:  Roland Dreier [EMAIL PROTECTED]
CommitDate: Tue Oct 9 19:59:14 2007 -0700

IB/core: Fix handling of multicast response failures

I was looking at the code for multicast.c and noticed that
ib_sa_join_multicast() calls queue_join() which puts the
request at the front of the group-pending_list.  If this
is a second request, it seems like it would interfere with
process_join_error() since group-last_join won't point
to the member at the head of the pending_list. The sequence
would thus be:

1. ib_sa_join_multicast()
   puts member1 on head of pending_list and starts work thread
2. mcast_work_handler()
   calls send_join() which sets group-last_join to member1
3. ib_sa_join_multicast()
   puts member2 on head of pending_list
4. join operation for member1 receives failures response from SA.
5. join_handler() is called with error status
6. process_join_error() fails to process member1 since
   it doesn't match the first entry in the group-pending_list.

The impact is that the failed join request is tossed.  The second
request is processed, and after it completes, the original request ends
up being retried.

This change also results in join requests being processed in FIFO
order.

Signed-off-by: Ralph Campbell [EMAIL PROTECTED]
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
 drivers/infiniband/core/multicast.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/infiniband/core/multicast.c 
b/drivers/infiniband/core/multicast.c
index 15b4c4d..1bc1fe6 100644
--- a/drivers/infiniband/core/multicast.c
+++ b/drivers/infiniband/core/multicast.c
@@ -196,7 +196,7 @@ static void queue_join(struct mcast_member *member)
unsigned long flags;
 
spin_lock_irqsave(group-lock, flags);
-   list_add(member-list, group-pending_list);
+   list_add_tail(member-list, group-pending_list);
if (group-state == MCAST_IDLE) {
group-state = MCAST_BUSY;
atomic_inc(group-refcount);
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

IB/ehca: Adjust 64-bit alignment of create QP response for userspace

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a66072237500f31cec19fa688210150de9c9f957
Commit: a66072237500f31cec19fa688210150de9c9f957
Parent: 03f72a51cb1a0ba530e3308e3de84399a75b41ec
Author: Hoang-Nam Nguyen [EMAIL PROTECTED]
AuthorDate: Fri Sep 28 17:18:47 2007 +0200
Committer:  Roland Dreier [EMAIL PROTECTED]
CommitDate: Tue Oct 9 19:59:14 2007 -0700

IB/ehca: Adjust 64-bit alignment of create QP response for userspace

Signed-off-by: Hoang-Nam Nguyen [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
 drivers/infiniband/hw/ehca/ehca_classes.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h 
b/drivers/infiniband/hw/ehca/ehca_classes.h
index d670696..0f7a55d 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -351,6 +351,7 @@ struct ehca_create_qp_resp {
/* qp_num assigned by ehca: sqp0/1 may have got different numbers */
u32 real_qp_num;
u32 fw_handle_ofs;
+   u32 dummy;
struct ipzu_queue_resp ipz_squeue;
struct ipzu_queue_resp ipz_rqueue;
 };
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

IB/cm: Modify interface to send MRAs in response to duplicate messages

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=de98b693e9857e183679cd2f49b3c30d2bc57629
Commit: de98b693e9857e183679cd2f49b3c30d2bc57629
Parent: 1a1eb6a646f52dc62e3f9ceac4aab9c27e781186
Author: Sean Hefty [EMAIL PROTECTED]
AuthorDate: Wed Aug 1 13:49:53 2007 -0700
Committer:  Roland Dreier [EMAIL PROTECTED]
CommitDate: Tue Oct 9 19:59:17 2007 -0700

IB/cm: Modify interface to send MRAs in response to duplicate messages

The IB CM provides a message received acknowledged (MRA) message that
can be sent to indicate that a REQ or REP message has been received, but
will require more time to process than the timeout specified by those
messages.  In many cases, the application may not know how long it will
take to respond to a CM message, but the majority of the time, it will
usually respond before a retry has been sent.  Rather than sending an
MRA in response to all messages just to handle the case where a longer
timeout is needed, it is more efficient to queue the MRA for sending in
case a duplicate message is received.

This avoids sending an MRA when it is not needed, but limits the number
of times that a REQ or REP will be resent.  It also provides for a
simpler implementation than generating the MRA based on a timer event.
(That is, trying to send the MRA after receiving the first REQ or REP if
a response has not been generated, so that it is received at the remote
side before a duplicate REQ or REP has been received)

Signed-off-by: Sean Hefty [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
 drivers/infiniband/core/cm.c |   51 +++---
 include/rdma/ib_cm.h |7 -
 2 files changed, 28 insertions(+), 30 deletions(-)

diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index 4df269f..2e39236 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -2219,6 +2219,9 @@ int ib_send_cm_mra(struct ib_cm_id *cm_id,
 {
struct cm_id_private *cm_id_priv;
struct ib_mad_send_buf *msg;
+   enum ib_cm_state cm_state;
+   enum ib_cm_lap_state lap_state;
+   enum cm_msg_response msg_response;
void *data;
unsigned long flags;
int ret;
@@ -2235,48 +2238,40 @@ int ib_send_cm_mra(struct ib_cm_id *cm_id,
spin_lock_irqsave(cm_id_priv-lock, flags);
switch(cm_id_priv-id.state) {
case IB_CM_REQ_RCVD:
-   ret = cm_alloc_msg(cm_id_priv, msg);
-   if (ret)
-   goto error1;
-
-   cm_format_mra((struct cm_mra_msg *) msg-mad, cm_id_priv,
- CM_MSG_RESPONSE_REQ, service_timeout,
- private_data, private_data_len);
-   ret = ib_post_send_mad(msg, NULL);
-   if (ret)
-   goto error2;
-   cm_id-state = IB_CM_MRA_REQ_SENT;
+   cm_state = IB_CM_MRA_REQ_SENT;
+   lap_state = cm_id-lap_state;
+   msg_response = CM_MSG_RESPONSE_REQ;
break;
case IB_CM_REP_RCVD:
-   ret = cm_alloc_msg(cm_id_priv, msg);
-   if (ret)
-   goto error1;
-
-   cm_format_mra((struct cm_mra_msg *) msg-mad, cm_id_priv,
- CM_MSG_RESPONSE_REP, service_timeout,
- private_data, private_data_len);
-   ret = ib_post_send_mad(msg, NULL);
-   if (ret)
-   goto error2;
-   cm_id-state = IB_CM_MRA_REP_SENT;
+   cm_state = IB_CM_MRA_REP_SENT;
+   lap_state = cm_id-lap_state;
+   msg_response = CM_MSG_RESPONSE_REP;
break;
case IB_CM_ESTABLISHED:
+   cm_state = cm_id-state;
+   lap_state = IB_CM_MRA_LAP_SENT;
+   msg_response = CM_MSG_RESPONSE_OTHER;
+   break;
+   default:
+   ret = -EINVAL;
+   goto error1;
+   }
+
+   if (!(service_timeout  IB_CM_MRA_FLAG_DELAY)) {
ret = cm_alloc_msg(cm_id_priv, msg);
if (ret)
goto error1;
 
cm_format_mra((struct cm_mra_msg *) msg-mad, cm_id_priv,
- CM_MSG_RESPONSE_OTHER, service_timeout,
+ msg_response, service_timeout,
  private_data, private_data_len);
ret = ib_post_send_mad(msg, NULL);
if (ret)
goto error2;
-   cm_id-lap_state = IB_CM_MRA_LAP_SENT;
-   break;
-   default:
-   ret = -EINVAL;
-   goto error1;
}
+
+   cm_id-state = cm_state;
+   cm_id-lap_state = lap_state;
cm_id_priv-service_timeout

SCTP: Send ABORT chunk with correct tag in response to INIT ACK

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=02c4e12c6400b6dccdc6b5c2c18325551e4b2dc9
Commit: 02c4e12c6400b6dccdc6b5c2c18325551e4b2dc9
Parent: a09c83847b664dcd67a72613374061c900afb799
Author: Wei Yongjun [EMAIL PROTECTED]
AuthorDate: Fri Aug 31 10:03:58 2007 +0800
Committer:  David S. Miller [EMAIL PROTECTED]
CommitDate: Tue Sep 25 22:55:46 2007 -0700

SCTP: Send ABORT chunk with correct tag in response to INIT ACK

When SCTP client received an INIT ACK chunk with missing mandatory
parameter such as cookie parameter, it will send back a ABORT
with T-bit not set and verification tag is set to 0.
This is because before we accept this INIT ACK chunk, we do not know
the peer's tag.  This patch change to reflect vtag when responding to
INIT ACK with missing mandatory parameter.

Signed-off-by: Wei Yongjun [EMAIL PROTECTED]
Signed-off-by: Vlad Yasevich [EMAIL PROTECTED]
---
 net/sctp/sm_statefuns.c |   17 -
 1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index 177528e..385f175 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -5176,7 +5176,22 @@ static struct sctp_packet *sctp_ootb_pkt_new(const 
struct sctp_association *asoc
 * association exists, otherwise, use the peer's vtag.
 */
if (asoc) {
-   vtag = asoc-peer.i.init_tag;
+   /* Special case the INIT-ACK as there is no peer's vtag
+* yet.
+*/
+   switch(chunk-chunk_hdr-type) {
+   case SCTP_CID_INIT_ACK:
+   {
+   sctp_initack_chunk_t *initack;
+
+   initack = (sctp_initack_chunk_t *)chunk-chunk_hdr;
+   vtag = ntohl(initack-init_hdr.init_tag);
+   break;
+   }
+   default:
+   vtag = asoc-peer.i.init_tag;
+   break;
+   }
} else {
/* Special case the INIT and stale COOKIE_ECHO as there is no
 * vtag yet.
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

ocfs2: Pack vote message and response structures

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=813d974c53a2b353566a86bb127625b403696dae
Commit: 813d974c53a2b353566a86bb127625b403696dae
Parent: 5c26a7b70f89c36e8d9acc95cb896c3cd205fc8d
Author: Sunil Mushran [EMAIL PROTECTED]
AuthorDate: Thu Sep 20 10:59:48 2007 -0700
Committer:  Mark Fasheh [EMAIL PROTECTED]
CommitDate: Thu Sep 20 15:06:10 2007 -0700

ocfs2: Pack vote message and response structures

The ocfs2_vote_msg and ocfs2_response_msg structs needed to be
packed to ensure similar sizeofs in 32-bit and 64-bit arches. Without this,
we had inadvertantly broken 32/64 bit cross mounts.

Signed-off-by: Sunil Mushran [EMAIL PROTECTED]
Signed-off-by: Mark Fasheh [EMAIL PROTECTED]
---
 fs/ocfs2/vote.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/ocfs2/vote.c b/fs/ocfs2/vote.c
index 66a13ee..c053585 100644
--- a/fs/ocfs2/vote.c
+++ b/fs/ocfs2/vote.c
@@ -66,7 +66,7 @@ struct ocfs2_vote_msg
 {
struct ocfs2_msg_hdr v_hdr;
__be32 v_reserved1;
-};
+} __attribute__ ((packed));
 
 /* Responses are given these values to maintain backwards
  * compatibility with older ocfs2 versions */
@@ -78,7 +78,7 @@ struct ocfs2_response_msg
 {
struct ocfs2_msg_hdr r_hdr;
__be32 r_response;
-};
+} __attribute__ ((packed));
 
 struct ocfs2_vote_work {
struct list_head   w_list;
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

IB/mad: Fix error path if response alloc fails in ib_mad_recv_done_handler()

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=445d68070c9c02acdda38e6d69bd43096f521035
Commit: 445d68070c9c02acdda38e6d69bd43096f521035
Parent: 5399891052badf97948098d01772113801f6ef58
Author: Hal Rosenstock [EMAIL PROTECTED]
AuthorDate: Fri Aug 3 10:45:17 2007 -0700
Committer:  Roland Dreier [EMAIL PROTECTED]
CommitDate: Fri Aug 3 10:45:17 2007 -0700

IB/mad: Fix error path if response alloc fails in ib_mad_recv_done_handler()

If ib_mad_recv_done_handler() fails to allocate response, then it just
printed a warning and continued, which leads to an oops if the MAD is
being handled for a switch device, because the switch code uses
response without checking for NULL.  Fix this by bailing out of the
function if the allocation fails.

Signed-off-by: Suresh Shelvapille [EMAIL PROTECTED]
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
 drivers/infiniband/core/mad.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
index bc547f1..9697857 100644
--- a/drivers/infiniband/core/mad.c
+++ b/drivers/infiniband/core/mad.c
@@ -1842,16 +1842,11 @@ static void ib_mad_recv_done_handler(struct 
ib_mad_port_private *port_priv,
 {
struct ib_mad_qp_info *qp_info;
struct ib_mad_private_header *mad_priv_hdr;
-   struct ib_mad_private *recv, *response;
+   struct ib_mad_private *recv, *response = NULL;
struct ib_mad_list_head *mad_list;
struct ib_mad_agent_private *mad_agent;
int port_num;
 
-   response = kmem_cache_alloc(ib_mad_cache, GFP_KERNEL);
-   if (!response)
-   printk(KERN_ERR PFX ib_mad_recv_done_handler no memory 
-  for response buffer\n);
-
mad_list = (struct ib_mad_list_head *)(unsigned long)wc-wr_id;
qp_info = mad_list-mad_queue-qp_info;
dequeue_mad(mad_list);
@@ -1879,6 +1874,13 @@ static void ib_mad_recv_done_handler(struct 
ib_mad_port_private *port_priv,
if (!validate_mad(recv-mad.mad, qp_info-qp-qp_num))
goto out;
 
+   response = kmem_cache_alloc(ib_mad_cache, GFP_KERNEL);
+   if (!response) {
+   printk(KERN_ERR PFX ib_mad_recv_done_handler no memory 
+  for response buffer\n);
+   goto out;
+   }
+
if (port_priv-device-node_type == RDMA_NODE_IB_SWITCH)
port_num = wc-port_num;
else
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

knfsd: set the response bitmask for NFS4_CREATE_EXCLUSIVE

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=749997e5127a1df6b68a10c686af3f5b819a41a2
Commit: 749997e5127a1df6b68a10c686af3f5b819a41a2
Parent: 421cee293587081efef165b137514884b8472565
Author: Jeff Layton [EMAIL PROTECTED]
AuthorDate: Tue Jul 31 00:37:51 2007 -0700
Committer:  Linus Torvalds [EMAIL PROTECTED]
CommitDate: Tue Jul 31 15:39:38 2007 -0700

knfsd: set the response bitmask for NFS4_CREATE_EXCLUSIVE

RFC 3530 says:

 If the server uses an attribute to store the exclusive create verifier, it
 will signify which attribute by setting the appropriate bit in the 
attribute
 mask that is returned in the results.

Linux uses the atime and mtime to store the verifier, but sends a zeroed out
bitmask back to the client.  This patch makes sure that we set the correct
bits in the bitmask in this situation.

Signed-off-by: Jeff Layton [EMAIL PROTECTED]
Signed-off-by: J. Bruce Fields [EMAIL PROTECTED]
Cc: Neil Brown [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
 fs/nfsd/nfs4proc.c |   10 +-
 fs/nfsd/vfs.c  |5 -
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
index 3c62712..29b7e63 100644
--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -100,7 +100,15 @@ do_open_lookup(struct svc_rqst *rqstp, struct svc_fh 
*current_fh, struct nfsd4_o
status = nfsd_create_v3(rqstp, current_fh, open-op_fname.data,
open-op_fname.len, open-op_iattr,
resfh, open-op_createmode,
-   (u32 *)open-op_verf.data, 
open-op_truncate, created);
+   (u32 *)open-op_verf.data,
+   open-op_truncate, created);
+
+   /* If we ever decide to use different attrs to store the
+* verifier in nfsd_create_v3, then we'll need to change this
+*/
+   if (open-op_createmode == NFS4_CREATE_EXCLUSIVE  status == 0)
+   open-op_bmval[1] |= (FATTR4_WORD1_TIME_ACCESS |
+   FATTR4_WORD1_TIME_MODIFY);
} else {
status = nfsd_lookup(rqstp, current_fh,
 open-op_fname.data, open-op_fname.len, 
resfh);
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index ee96a89..a0c2b25 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -1309,7 +1309,10 @@ nfsd_create_v3(struct svc_rqst *rqstp, struct svc_fh 
*fhp,
 
if (createmode == NFS3_CREATE_EXCLUSIVE) {
/* solaris7 gets confused (bugid 4218508) if these have
-* the high bit set, so just clear the high bits.
+* the high bit set, so just clear the high bits. If this is
+* ever changed to use different attrs for storing the
+* verifier, then do_open_lookup() will also need to be fixed
+* accordingly.
 */
v_mtime = verifier[0]0x7fff;
v_atime = verifier[1]0x7fff;
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

mmc-omap: fix sd response type 6 vs. 1

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0107a4b32e36dccd4456e2c5e34c5cd22c94e094
Commit: 0107a4b32e36dccd4456e2c5e34c5cd22c94e094
Parent: a0e1d1d075cc0efe9a3ac8579bce9393d070e09f
Author: Ragner Magalhaes [EMAIL PROTECTED]
AuthorDate: Wed Jun 13 19:09:28 2007 +0200
Committer:  Pierre Ossman [EMAIL PROTECTED]
CommitDate: Wed Jun 13 19:11:14 2007 +0200

mmc-omap: fix sd response type 6 vs. 1

Ignoring OMAP_MMC_STAT_CARD_ERR, treating it as if the command
completed correctly.

Signed-off-by: Ragner Magalhaes [EMAIL PROTECTED]
Signed-off-by: Carlos Eduardo Aguiar [EMAIL PROTECTED]
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
---
 drivers/mmc/host/omap.c |   24 +++-
 1 files changed, 3 insertions(+), 21 deletions(-)

diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 1914e65..b0824a3 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -522,28 +522,10 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
}
 
if (status  OMAP_MMC_STAT_CARD_ERR) {
-   if (host-cmd  host-cmd-opcode == 
MMC_STOP_TRANSMISSION) {
-   u32 response = OMAP_MMC_READ(host, RSP6)
-   | (OMAP_MMC_READ(host, RSP7)  16);
-   /* STOP sometimes sets must-ignore bits */
-   if (!(response  (R1_CC_ERROR
-   | 
R1_ILLEGAL_COMMAND
-   | 
R1_COM_CRC_ERROR))) {
-   end_command = 1;
-   continue;
-   }
-   }
-
-   dev_dbg(mmc_dev(host-mmc), card status error 
(CMD%d)\n,
+   dev_dbg(mmc_dev(host-mmc),
+   ignoring card status error (CMD%d)\n,
host-cmd-opcode);
-   if (host-cmd) {
-   host-cmd-error = MMC_ERR_FAILED;
-   end_command = 1;
-   }
-   if (host-data) {
-   host-data-error = MMC_ERR_FAILED;
-   transfer_error = 1;
-   }
+   end_command = 1;
}
 
/*
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pxamci: fix PXA27x MMC workaround for bad CRC with 136 bit response

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=90e07d9f54c61449dd48eff82e2354d0124d4f7e
Commit: 90e07d9f54c61449dd48eff82e2354d0124d4f7e
Parent: fe6b4c8840c5e23fe9b8696450cee8f2e8cebffd
Author: Nicolas Pitre [EMAIL PROTECTED]
AuthorDate: Sun May 13 18:03:08 2007 +0200
Committer:  Pierre Ossman [EMAIL PROTECTED]
CommitDate: Mon May 14 18:51:48 2007 +0200

pxamci: fix PXA27x MMC workaround for bad CRC with 136 bit response

... and make it depend on the response flag instead of the command type.

Signed-off-by: Nicolas Pitre [EMAIL PROTECTED]
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
---
 drivers/mmc/host/pxamci.c |   18 ++
 1 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c
index d97d386..f8985c5 100644
--- a/drivers/mmc/host/pxamci.c
+++ b/drivers/mmc/host/pxamci.c
@@ -232,20 +232,14 @@ static int pxamci_cmd_done(struct pxamci_host *host, 
unsigned int stat)
/*
 * workaround for erratum #42:
 * Intel PXA27x Family Processor Specification Update Rev 001
+* A bogus CRC error can appear if the msb of a 136 bit
+* response is a one.
 */
-   if (cmd-opcode == MMC_ALL_SEND_CID ||
-   cmd-opcode == MMC_SEND_CSD ||
-   cmd-opcode == MMC_SEND_CID) {
-   /* a bogus CRC error can appear if the msb of
-  the 15 byte response is a one */
-   if ((cmd-resp[0]  0x8000) == 0)
-   cmd-error = MMC_ERR_BADCRC;
-   } else {
-   pr_debug(ignoring CRC from command %d - 
*risky*\n,cmd-opcode);
-   }
-#else
-   cmd-error = MMC_ERR_BADCRC;
+   if (cmd-flags  MMC_RSP_136  cmd-resp[0]  0x8000) {
+   pr_debug(ignoring CRC from command %d - *risky*\n, 
cmd-opcode);
+   } else
 #endif
+   cmd-error = MMC_ERR_BADCRC;
}
 
pxamci_disable_irq(host, END_CMD_RES);
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

firewire: Clean up response handling.

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=36bfe49d076404fcdf5766098de21724635a1816
Commit: 36bfe49d076404fcdf5766098de21724635a1816
Parent: e636fe2576be552252a5b63e9287915e810b37d8
Author: Kristian Høgsberg [EMAIL PROTECTED]
AuthorDate: Fri Jan 26 00:38:13 2007 -0500
Committer:  Stefan Richter [EMAIL PROTECTED]
CommitDate: Fri Mar 9 22:02:46 2007 +0100

firewire: Clean up response handling.

Signed-off-by: Kristian Høgsberg [EMAIL PROTECTED]
Signed-off-by: Stefan Richter [EMAIL PROTECTED]
---
 drivers/firewire/fw-transaction.c |   54 ++--
 1 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/firewire/fw-transaction.c 
b/drivers/firewire/fw-transaction.c
index 4ca39f0..a116ffa 100644
--- a/drivers/firewire/fw-transaction.c
+++ b/drivers/firewire/fw-transaction.c
@@ -107,9 +107,9 @@ transmit_complete_callback(struct fw_packet *packet,
 }
 
 static void
-fw_fill_packet(struct fw_packet *packet, int tcode, int tlabel,
-  int node_id, int generation, int speed,
-  unsigned long long offset, void *payload, size_t length)
+fw_fill_request(struct fw_packet *packet, int tcode, int tlabel,
+   int node_id, int generation, int speed,
+   unsigned long long offset, void *payload, size_t length)
 {
int ext_tcode;
 
@@ -240,8 +240,8 @@ fw_send_request(struct fw_card *card, struct fw_transaction 
*t,
t-callback = callback;
t-callback_data = callback_data;
 
-   fw_fill_packet(t-packet, tcode, t-tlabel,
-  node_id, generation, speed, offset, payload, length);
+   fw_fill_request(t-packet, tcode, t-tlabel,
+   node_id, generation, speed, offset, payload, length);
t-packet.callback = transmit_complete_callback;
 
card-driver-send_request(card, t-packet);
@@ -409,6 +409,7 @@ EXPORT_SYMBOL(fw_core_remove_address_handler);
 
 struct fw_request {
struct fw_packet response;
+   u32 request_header[4];
int ack;
u32 length;
u32 data[0];
@@ -425,22 +426,24 @@ free_response_callback(struct fw_packet *packet,
 }
 
 static void
-fw_fill_response(struct fw_packet *response,
-struct fw_packet *request, void *data)
+fw_fill_response(struct fw_packet *response, u32 *request_header,
+int rcode, void *payload, size_t length)
 {
int tcode, tlabel, extended_tcode, source, destination;
 
-   tcode  = header_get_tcode(request-header[0]);
-   tlabel = header_get_tlabel(request-header[0]);
-   source = header_get_destination(request-header[0]);
-   destination= header_get_source(request-header[1]);
-   extended_tcode = header_get_extended_tcode(request-header[3]);
+   tcode  = header_get_tcode(request_header[0]);
+   tlabel = header_get_tlabel(request_header[0]);
+   source = header_get_destination(request_header[0]);
+   destination= header_get_source(request_header[1]);
+   extended_tcode = header_get_extended_tcode(request_header[3]);
 
response-header[0] =
header_retry(RETRY_1) |
header_tlabel(tlabel) |
header_destination(destination);
-   response-header[1] = header_source(source);
+   response-header[1] =
+   header_source(source) |
+   header_rcode(rcode);
response-header[2] = 0;
 
switch (tcode) {
@@ -454,7 +457,7 @@ fw_fill_response(struct fw_packet *response,
case TCODE_READ_QUADLET_REQUEST:
response-header[0] |=
header_tcode(TCODE_READ_QUADLET_RESPONSE);
-   response-header[3] = 0;
+   response-header[3] = *(u32 *)payload;
response-header_length = 16;
response-payload_length = 0;
break;
@@ -463,11 +466,11 @@ fw_fill_response(struct fw_packet *response,
case TCODE_LOCK_REQUEST:
response-header[0] |= header_tcode(tcode + 2);
response-header[3] =
-   header_data_length(request-payload_length) |
+   header_data_length(length) |
header_extended_tcode(extended_tcode);
response-header_length = 16;
-   response-payload = data;
-   response-payload_length = request-payload_length;
+   response-payload = payload;
+   response-payload_length = length;
break;
 
default:
@@ -530,7 +533,7 @@ allocate_request(struct fw_packet *p)
if (data)
memcpy(request-data, p-payload, p-payload_length);
 
-   fw_fill_response(request-response, p, request-data);
+   memcpy(request-request_header, p-header, sizeof p-header);
 
return request;
 }
@@ -538,21 +541,18 @@ allocate_request

[TCP] FRTO: Response should reset also snd_cwnd_cnt

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=aa8b6a7ad147dfbaaf10368ff15df9418b670d8b
Commit: aa8b6a7ad147dfbaaf10368ff15df9418b670d8b
Parent: 95c4922bf9330eb2c71b752359dd89c4e166f3c5
Author: Ilpo Järvinen [EMAIL PROTECTED]
AuthorDate: Wed Feb 21 23:06:03 2007 -0800
Committer:  David S. Miller [EMAIL PROTECTED]
CommitDate: Wed Apr 25 22:23:08 2007 -0700

[TCP] FRTO: Response should reset also snd_cwnd_cnt

Since purpose is to reduce CWND, we prevent immediate growth. This
is not a major issue nor is the correct way specified anywhere.

Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]
---
 net/ipv4/tcp_input.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index cc935c8..924b2e6 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2490,6 +2490,7 @@ static int tcp_ack_update_window(struct sock *sk, struct 
tcp_sock *tp,
 static void tcp_conservative_spur_to_response(struct tcp_sock *tp)
 {
tp-snd_cwnd = min(tp-snd_cwnd, tp-snd_ssthresh);
+   tp-snd_cwnd_cnt = 0;
tcp_moderate_cwnd(tp);
 }
 
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[TCP]: FRTO undo response falls back to ratehalving one if ECEd

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e317f6f69cb95527799d308a9421b7dc1252989a
Commit: e317f6f69cb95527799d308a9421b7dc1252989a
Parent: e01f9d7793be82e6c252efbd52c399d3eb65abe4
Author: Ilpo Järvinen [EMAIL PROTECTED]
AuthorDate: Fri Mar 2 13:34:19 2007 -0800
Committer:  David S. Miller [EMAIL PROTECTED]
CommitDate: Wed Apr 25 22:23:26 2007 -0700

[TCP]: FRTO undo response falls back to ratehalving one if ECEd

Undoing ssthresh is disabled in fastretrans_alert whenever
FLAG_ECE is set by clearing prior_ssthresh. The clearing does
not protect FRTO because FRTO operates before fastretrans_alert.
Moving the clearing of prior_ssthresh earlier seems to be a
suboptimal solution to the FRTO case because then FLAG_ECE will
cause a second ssthresh reduction in try_to_open (the first
occurred when FRTO was entered). So instead, FRTO falls back
immediately to the rate halving response, which switches TCP to
CA_CWR state preventing the latter reduction of ssthresh.

If the first ECE arrived before the ACK after which FRTO is able
to decide RTO as spurious, prior_ssthresh is already cleared.
Thus no undoing for ssthresh occurs. Besides, FLAG_ECE should be
set also in the following ACKs resulting in rate halving response
that sees TCP is already in CA_CWR, which again prevents an extra
ssthresh reduction on that round-trip.

If the first ECE arrived before RTO, ssthresh has already been
adapted and prior_ssthresh remains cleared on entry because TCP
is in CA_CWR (the same applies also to a case where FRTO is
entered more than once and ECE comes in the middle).

High_seq must not be touched after tcp_enter_cwr because CWR
round-trip calculation depends on it.

I believe that after this patch, FRTO should be ECN-safe and
even able to take advantage of synergy benefits.

Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]
---
 net/ipv4/tcp_input.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index cb715ea..d894bbc 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2587,14 +2587,15 @@ static void tcp_conservative_spur_to_response(struct 
tcp_sock *tp)
  */
 static void tcp_ratehalving_spur_to_response(struct sock *sk)
 {
-   struct tcp_sock *tp = tcp_sk(sk);
tcp_enter_cwr(sk, 0);
-   tp-high_seq = tp-frto_highmark;   /* Smoother w/o this? - ij */
 }
 
-static void tcp_undo_spur_to_response(struct sock *sk)
+static void tcp_undo_spur_to_response(struct sock *sk, int flag)
 {
-   tcp_undo_cwr(sk, 1);
+   if (flagFLAG_ECE)
+   tcp_ratehalving_spur_to_response(sk);
+   else
+   tcp_undo_cwr(sk, 1);
 }
 
 /* F-RTO spurious RTO detection algorithm (RFC4138)
@@ -2681,7 +2682,7 @@ static int tcp_process_frto(struct sock *sk, u32 
prior_snd_una, int flag)
} else /* frto_counter == 2 */ {
switch (sysctl_tcp_frto_response) {
case 2:
-   tcp_undo_spur_to_response(sk);
+   tcp_undo_spur_to_response(sk, flag);
break;
case 1:
tcp_conservative_spur_to_response(tp);
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[TCP] FRTO: Separated response from FRTO detection algorithm

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9ead9a1d385ae2c52a6dcf2828d84ce66be04fc2
Commit: 9ead9a1d385ae2c52a6dcf2828d84ce66be04fc2
Parent: 522e7548a9bd40305df41c0beae69448b7620d6b
Author: Ilpo Järvinen [EMAIL PROTECTED]
AuthorDate: Wed Feb 21 22:56:19 2007 -0800
Committer:  David S. Miller [EMAIL PROTECTED]
CommitDate: Wed Apr 25 22:23:01 2007 -0700

[TCP] FRTO: Separated response from FRTO detection algorithm

FRTO spurious RTO detection algorithm (RFC4138) does not include response
to a detected spurious RTO but can use different response algorithms.

Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]
---
 net/ipv4/tcp_input.c |   16 ++--
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index b21e232..c5be3d0 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2467,6 +2467,15 @@ static int tcp_ack_update_window(struct sock *sk, struct 
tcp_sock *tp,
return flag;
 }
 
+/* A very conservative spurious RTO response algorithm: reduce cwnd and
+ * continue in congestion avoidance.
+ */
+static void tcp_conservative_spur_to_response(struct tcp_sock *tp)
+{
+   tp-snd_cwnd = min(tp-snd_cwnd, tp-snd_ssthresh);
+   tcp_moderate_cwnd(tp);
+}
+
 static void tcp_process_frto(struct sock *sk, u32 prior_snd_una)
 {
struct tcp_sock *tp = tcp_sk(sk);
@@ -2488,12 +2497,7 @@ static void tcp_process_frto(struct sock *sk, u32 
prior_snd_una)
 */
tp-snd_cwnd = tcp_packets_in_flight(tp) + 2;
} else {
-   /* Also the second ACK after RTO advances the window.
-* The RTO was likely spurious. Reduce cwnd and continue
-* in congestion avoidance
-*/
-   tp-snd_cwnd = min(tp-snd_cwnd, tp-snd_ssthresh);
-   tcp_moderate_cwnd(tp);
+   tcp_conservative_spur_to_response(tp);
}
 
/* F-RTO affects on two new ACKs following RTO.
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

IB/srp: Don't wait for response when QP is in error state.

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1033ff670d49760604f5d4c73a1b60741863a406
Commit: 1033ff670d49760604f5d4c73a1b60741863a406
Parent: 062dbb69f32b9ccea701b30f8cc0049482e6211f
Author: Ishai Rabinovitz [EMAIL PROTECTED]
AuthorDate: Tue Jan 16 17:26:22 2007 +0200
Committer:  Roland Dreier [EMAIL PROTECTED]
CommitDate: Sun Feb 4 14:11:56 2007 -0800

IB/srp: Don't wait for response when QP is in error state.

When there is a call to send_tsk_mgmt SRP posts a send and waits for 5
seconds to get a response.

When the QP is in the error state it is obvious that there will be no
response so it is quite useless to wait.  In fact, the timeout causes
SRP to wait a long time to reconnect when a QP error occurs. (Each
abort and each reset_device calls send_tsk_mgmt, which waits for the
timeout).  The following patch solves this problem by identifying the
failure and returning an immediate error code.

Signed-off-by: Ishai Rabinovitz [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
 drivers/infiniband/ulp/srp/ib_srp.c |7 +++
 drivers/infiniband/ulp/srp/ib_srp.h |1 +
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/ulp/srp/ib_srp.c 
b/drivers/infiniband/ulp/srp/ib_srp.c
index 72611fd..5e8ac57 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -548,6 +548,7 @@ static int srp_reconnect_target(struct srp_target_port 
*target)
target-tx_head  = 0;
target-tx_tail  = 0;
 
+   target-qp_in_error = 0;
ret = srp_connect_target(target);
if (ret)
goto err;
@@ -878,6 +879,7 @@ static void srp_completion(struct ib_cq *cq, void 
*target_ptr)
printk(KERN_ERR PFX failed %s status %d\n,
   wc.wr_id  SRP_OP_RECV ? receive : send,
   wc.status);
+   target-qp_in_error = 1;
break;
}
 
@@ -1337,6 +1339,8 @@ static int srp_abort(struct scsi_cmnd *scmnd)
 
printk(KERN_ERR SRP abort called\n);
 
+   if (target-qp_in_error)
+   return FAILED;
if (srp_find_req(target, scmnd, req))
return FAILED;
if (srp_send_tsk_mgmt(target, req, SRP_TSK_ABORT_TASK))
@@ -1365,6 +1369,8 @@ static int srp_reset_device(struct scsi_cmnd *scmnd)
 
printk(KERN_ERR SRP reset_device called\n);
 
+   if (target-qp_in_error)
+   return FAILED;
if (srp_find_req(target, scmnd, req))
return FAILED;
if (srp_send_tsk_mgmt(target, req, SRP_TSK_LUN_RESET))
@@ -1801,6 +1807,7 @@ static ssize_t srp_create_target(struct class_device 
*class_dev,
goto err_free;
}
 
+   target-qp_in_error = 0;
ret = srp_connect_target(target);
if (ret) {
printk(KERN_ERR PFX Connection failed\n);
diff --git a/drivers/infiniband/ulp/srp/ib_srp.h 
b/drivers/infiniband/ulp/srp/ib_srp.h
index c217723..2f3319c 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.h
+++ b/drivers/infiniband/ulp/srp/ib_srp.h
@@ -158,6 +158,7 @@ struct srp_target_port {
struct completion   done;
int status;
enum srp_target_state   state;
+   int qp_in_error;
 };
 
 struct srp_iu {
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

omap: Update MMC response types

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1b3b2631842ab60c1b7923bef102c610439ba3dd
Commit: 1b3b2631842ab60c1b7923bef102c610439ba3dd
Parent: 0404f87f2e0a0aadbda47be0f54812671207492f
Author: Carlos Eduardo Aguiar [EMAIL PROTECTED]
AuthorDate: Mon Jan 15 06:38:15 2007 +0100
Committer:  Pierre Ossman [EMAIL PROTECTED]
CommitDate: Mon Jan 15 06:39:00 2007 +0100

omap: Update MMC response types

This patch is a fix in order to update MMC response types. This 
modification is
needed to allow SD card support on OMAP platforms.

Signed-off-by: Carlos Eduardo Aguiar [EMAIL PROTECTED]
Signed-off-by: Yuha Yrjola [EMAIL PROTECTED]
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
---
 drivers/mmc/omap.c |   16 +++-
 1 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/omap.c b/drivers/mmc/omap.c
index 9488408..1e5407d 100644
--- a/drivers/mmc/omap.c
+++ b/drivers/mmc/omap.c
@@ -91,7 +91,6 @@
 
 
 #define DRIVER_NAME mmci-omap
-#define RSP_TYPE(x)((x)  ~(MMC_RSP_BUSY|MMC_RSP_OPCODE))
 
 /* Specifies how often in millisecs to poll for card status changes
  * when the cover switch is open */
@@ -204,18 +203,25 @@ mmc_omap_start_command(struct mmc_omap_host *host, struct 
mmc_command *cmd)
cmdtype = 0;
 
/* Our hardware needs to know exact type */
-   switch (RSP_TYPE(mmc_resp_type(cmd))) {
-   case RSP_TYPE(MMC_RSP_R1):
+   switch (mmc_resp_type(cmd)) {
+   case MMC_RSP_NONE:
+   break;
+   case MMC_RSP_R1:
+   case MMC_RSP_R1B:
/* resp 1, resp 1b */
resptype = 1;
break;
-   case RSP_TYPE(MMC_RSP_R2):
+   case MMC_RSP_R2:
resptype = 2;
break;
-   case RSP_TYPE(MMC_RSP_R3):
+   case MMC_RSP_R3:
resptype = 3;
break;
+   case MMC_RSP_R6:
+   resptype = 6;
+   break;
default:
+   dev_err(mmc_dev(host-mmc), Invalid response type: %04x\n, 
mmc_resp_type(cmd));
break;
}
 
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] KVM: Improve interrupt response

[Linux Kernel Mailing List]

Gitweb: 
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c1150d8cf9e9d2b356fab52d79f2366985e5511b
Commit: c1150d8cf9e9d2b356fab52d79f2366985e5511b
Parent: e097f35ce58eb8d687f3a300247cf1a978fcea39
Author: Dor Laor [EMAIL PROTECTED]
AuthorDate: Fri Jan 5 16:36:24 2007 -0800
Committer:  Linus Torvalds [EMAIL PROTECTED]
CommitDate: Fri Jan 5 23:55:22 2007 -0800

[PATCH] KVM: Improve interrupt response

The current interrupt injection mechanism might delay an interrupt under
the following circumstances:

 - if injection fails because the guest is not interruptible (rflags.IF 
clear,
   or after a 'mov ss' or 'sti' instruction).  Userspace can check rflags,
   but the other cases or not testable under the current API.
 - if injection fails because of a fault during delivery.  This probably
   never happens under normal guests.
 - if injection fails due to a physical interrupt causing a vmexit so that
   it can be handled by the host.

In all cases the guest proceeds without processing the interrupt, reducing
the interactive feel and interrupt throughput of the guest.

This patch fixes the situation by allowing userspace to request an exit
when the 'interrupt window' opens, so that it can re-inject the interrupt
at the right time.  Guest interactivity is very visibly improved.

Signed-off-by: Dor Laor [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
Acked-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
 drivers/kvm/kvm.h  |4 ++
 drivers/kvm/kvm_main.c |   11 --
 drivers/kvm/svm.c  |   94 
 drivers/kvm/vmx.c  |   88 
 include/linux/kvm.h|   11 +-
 5 files changed, 180 insertions(+), 28 deletions(-)

diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 100df6f..32023d1 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -173,6 +173,7 @@ struct kvm_vcpu {
struct mutex mutex;
int   cpu;
int   launched;
+   int interrupt_window_open;
unsigned long irq_summary; /* bit vector: 1 per word in irq_pending */
 #define NR_IRQ_WORDS KVM_IRQ_BITMAP_SIZE(unsigned long)
unsigned long irq_pending[NR_IRQ_WORDS];
@@ -247,6 +248,9 @@ struct kvm_stat {
u32 io_exits;
u32 mmio_exits;
u32 signal_exits;
+   u32 irq_window_exits;
+   u32 halt_exits;
+   u32 request_irq_exits;
u32 irq_exits;
 };
 
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index b54caf0..aca1413 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -58,6 +58,9 @@ static struct kvm_stats_debugfs_item {
{ io_exits, kvm_stat.io_exits },
{ mmio_exits, kvm_stat.mmio_exits },
{ signal_exits, kvm_stat.signal_exits },
+   { irq_window, kvm_stat.irq_window_exits },
+   { halt_exits, kvm_stat.halt_exits },
+   { request_irq, kvm_stat.request_irq_exits },
{ irq_exits, kvm_stat.irq_exits },
{ 0, 0 }
 };
@@ -1693,12 +1696,12 @@ static long kvm_dev_ioctl(struct file *filp,
if (copy_from_user(kvm_run, (void *)arg, sizeof kvm_run))
goto out;
r = kvm_dev_ioctl_run(kvm, kvm_run);
-   if (r  0)
+   if (r  0   r != -EINTR)
goto out;
-   r = -EFAULT;
-   if (copy_to_user((void *)arg, kvm_run, sizeof kvm_run))
+   if (copy_to_user((void *)arg, kvm_run, sizeof kvm_run)) {
+   r = -EFAULT;
goto out;
-   r = 0;
+   }
break;
}
case KVM_GET_REGS: {
diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index fa04287..855207a 100644
--- a/drivers/kvm/svm.c
+++ b/drivers/kvm/svm.c
@@ -235,6 +235,8 @@ static void skip_emulated_instruction(struct kvm_vcpu *vcpu)
 
vcpu-rip = vcpu-svm-vmcb-save.rip = vcpu-svm-next_rip;
vcpu-svm-vmcb-control.int_state = ~SVM_INTERRUPT_SHADOW_MASK;
+
+   vcpu-interrupt_window_open = 1;
 }
 
 static int has_svm(void)
@@ -1031,10 +1033,11 @@ static int halt_interception(struct kvm_vcpu *vcpu, 
struct kvm_run *kvm_run)
 {
vcpu-svm-next_rip = vcpu-svm-vmcb-save.rip + 1;
skip_emulated_instruction(vcpu);
-   if (vcpu-irq_summary  (vcpu-svm-vmcb-save.rflags  X86_EFLAGS_IF))
+   if (vcpu-irq_summary)
return 1;
 
kvm_run-exit_reason = KVM_EXIT_HLT;
+   ++kvm_stat.halt_exits;
return 0;
 }
 
@@ -1186,6 +1189,24 @@ static int msr_interception(struct kvm_vcpu *vcpu, 
struct kvm_run *kvm_run)
return rdmsr_interception(vcpu, kvm_run);
 }
 
+static int interrupt_window_interception(struct kvm_vcpu *vcpu

[PATCH] ipmi: fix panic ipmb response

[Linux Kernel Mailing List]

tree ccb6709a781bdfaf774aa7774f0c22b6bbc923e8
parent 1fdd75bd6cfa60a54b6db91d9256a711ab52fef3
author Corey Minyard [EMAIL PROTECTED] Wed, 07 Sep 2005 05:18:42 -0700
committer Linus Torvalds [EMAIL PROTECTED] Thu, 08 Sep 2005 06:57:48 -0700

[PATCH] ipmi: fix panic ipmb response

The null message handler in the IPMI driver is used in startup and panic
situations to handle messages.  It was only designed to work with messages
from the local management controller, but in some cases it was used to get
messages from remote managmenet controllers, and the system would then
panic.  This patch makes the null message handler in the IPMI driver more
general so it works with any kind of message.

Signed-off-by: Corey Minyard [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]

 drivers/char/ipmi/ipmi_msghandler.c |  107 ++--
 include/linux/ipmi.h|3 -
 2 files changed, 69 insertions(+), 41 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -219,7 +219,7 @@ struct ipmi_smi
   interface comes in with a NULL user, call this routine with
   it.  Note that the message will still be freed by the
   caller.  This only works on the system interface. */
-   void (*null_user_handler)(ipmi_smi_t intf, struct ipmi_smi_msg *msg);
+   void (*null_user_handler)(ipmi_smi_t intf, struct ipmi_recv_msg *msg);
 
/* When we are scanning the channels for an SMI, this will
   tell which channel we are scanning. */
@@ -459,7 +459,27 @@ unsigned int ipmi_addr_length(int addr_t
 
 static void deliver_response(struct ipmi_recv_msg *msg)
 {
-   msg-user-handler-ipmi_recv_hndl(msg, msg-user-handler_data);
+   if (! msg-user) {
+   ipmi_smi_tintf = msg-user_msg_data;
+   unsigned long flags;
+
+   /* Special handling for NULL users. */
+   if (intf-null_user_handler) {
+   intf-null_user_handler(intf, msg);
+   spin_lock_irqsave(intf-counter_lock, flags);
+   intf-handled_local_responses++;
+   spin_unlock_irqrestore(intf-counter_lock, flags);
+   } else {
+   /* No handler, so give up. */
+   spin_lock_irqsave(intf-counter_lock, flags);
+   intf-unhandled_local_responses++;
+   spin_unlock_irqrestore(intf-counter_lock, flags);
+   }
+   ipmi_free_recv_msg(msg);
+   } else {
+   msg-user-handler-ipmi_recv_hndl(msg,
+  msg-user-handler_data);
+   }
 }
 
 /* Find the next sequence number not being used and add the given
@@ -1389,6 +1409,8 @@ int ipmi_request_settime(ipmi_user_t
unsigned char saddr, lun;
int   rv;
 
+   if (! user)
+   return -EINVAL;
rv = check_addr(user-intf, addr, saddr, lun);
if (rv)
return rv;
@@ -1418,6 +1440,8 @@ int ipmi_request_supply_msgs(ipmi_user_t
unsigned char saddr, lun;
int   rv;
 
+   if (! user)
+   return -EINVAL;
rv = check_addr(user-intf, addr, saddr, lun);
if (rv)
return rv;
@@ -1638,7 +1662,7 @@ send_channel_info_cmd(ipmi_smi_t intf, i
  (struct ipmi_addr *) si,
  0,
  msg,
- NULL,
+ intf,
  NULL,
  NULL,
  0,
@@ -1648,19 +1672,20 @@ send_channel_info_cmd(ipmi_smi_t intf, i
 }
 
 static void
-channel_handler(ipmi_smi_t intf, struct ipmi_smi_msg *msg)
+channel_handler(ipmi_smi_t intf, struct ipmi_recv_msg *msg)
 {
int rv = 0;
int chan;
 
-   if ((msg-rsp[0] == (IPMI_NETFN_APP_RESPONSE  2))
-(msg-rsp[1] == IPMI_GET_CHANNEL_INFO_CMD))
+   if ((msg-addr.addr_type == IPMI_SYSTEM_INTERFACE_ADDR_TYPE)
+(msg-msg.netfn == IPMI_NETFN_APP_RESPONSE)
+(msg-msg.cmd == IPMI_GET_CHANNEL_INFO_CMD))
{
/* It's the one we want */
-   if (msg-rsp[2] != 0) {
+   if (msg-msg.data[0] != 0) {
/* Got an error from the channel, just go on. */
 
-   if (msg-rsp[2] == IPMI_INVALID_COMMAND_ERR) {
+   if (msg-msg.data[0] == IPMI_INVALID_COMMAND_ERR) {
/* If the MC does not support this
   command, that is legal.  We just
   assume it has one IPMB at channel
@@ -1677,13 +1702,13 @@ channel_handler