Updated for libhail's anet. Not yet committed, waiting for more time to
pass.
Makefile.am |2
configure.ac |1
iscsiutil.h | 52 +
target.c | 53 ++
target.h |3
util.c | 223 ++-
Updated for move to libhail. Not committed on main branch until sme
more time passes.
server/bucket.c |8 -
server/object.c | 56 +-
server/server.c | 294 ++--
server/status.c |3
server/tabled.h | 45 ++--
5 files c
Just committed into libhail... renamed the include to 'anet.h' for
'asynchronous networking'.
include/Makefile.am |2
include/anet.h | 111 +++
lib/Makefile.am |1
lib/atcp.c | 241
4 files ch
On 09/22/2010 10:37 PM, Pete Zaitcev wrote:
On Wed, 22 Sep 2010 21:26:13 -0400
Jeff Garzik wrote:
It is a common idiom even in GLib that callbacks receive two anonymous
pointers; witness the data type GFunc's 'data' and 'user_data'
arguments:
http://library.gnome.org/devel/glib/stable/glib-Doub
On 09/23/2010 11:28 AM, Jim Meyering wrote:
Every developer should have MALLOC_PERTURB_=N (N in 1..255) set in
his/her environment on glibc-based systems. Almost all the time.
I heard about it a while ago, even submitted a bugzilla bug to have it
documented adequately. But apparently its abs
This converts itd over to using [a local copy of] atcp.
Makefile.am |1
iscsiutil.h | 52 +
target.c| 27 +++
target.h|2
util.c | 223 ++--
5 files changed, 29 insertions(+), 276 deletions(-)
di
Changes from v1:
- avoid referencing dead struct client (grep for 'invalidate_cli'),
by changing FSM callback prototype.
- insert 'void *priv' member into struct atcp_wr_state, and replace
cb_data1/cb_data2 callback parameters with (struct atcp_wr_state *, void *).
struct client / struct ses
On 09/23/2010 10:07 AM, Pete Zaitcev wrote:
On Thu, 23 Sep 2010 13:03:15 +0200
Jim Meyering wrote:
Just noticed that sometimes tabled uses this idiom:
if (!(key = malloc(klen + 1)))
and sometimes this:
if ((key = malloc(klen + 1)) == NULL)
This time I used "... == NULL".
Er... The bang
On 09/23/2010 03:19 PM, Jeff Garzik wrote:
3) I process patches similar to how Linus and others in the kernel do
it: "git am /path/to/mbox_of_patches" That tends to impose some
restrictions on the contents of each email.
FWIW, 'git pull' submissions are welcome. Standard kernel-style pull
sub
On 09/23/2010 10:03 AM, Pete Zaitcev wrote:
On Thu, 23 Sep 2010 12:53:06 +0200
Jim Meyering wrote:
I factored out the append_const definition to avoid
having to wrap the long lines with the increased indentation.
p = s;
+#define append_const(buf, c) \
+ do { memcpy(buf, c, sizeof(
On 09/23/2010 04:43 AM, Jim Meyering wrote:
From fb7865d158b0d32907dde703c4d37c70a26e738c Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 23 Sep 2010 10:11:44 +0200
Subject: [PATCH tabled 1/2] server/config.c: don't dereference NULL on OOM
(see other email for general response to these
On 09/23/2010 04:43 AM, Jim Meyering wrote:
Looking at tabled's code, I see a few places where unchecked strdup
can lead to NULL deref, whereas the majority are checked carefully.
Patches for the first two I found are below -- haven't completed the job.
In most cases, I see that care is taken t
On 09/23/2010 09:57 AM, Pete Zaitcev wrote:
Side effect or not, if one applies your patch and executes
"export MALLOC_PERTURB_=43" command before "make check",
the result is a crash:
Yes, it is clear my patch re-introduces the problem. I thanked you for
pointing that out in the original reply
Pete Zaitcev wrote:
> On Thu, 23 Sep 2010 00:32:09 -0400
> Jeff Garzik wrote:
>
>> >>> So, we go a longer route and re-hook the list of completions
>> >>> to a per-server global instead of a client. The patch is straight-
>> >>> forward. The only thing we need to be careful is to
On Thu, 23 Sep 2010 13:03:15 +0200
Jim Meyering wrote:
> Just noticed that sometimes tabled uses this idiom:
> if (!(key = malloc(klen + 1)))
> and sometimes this:
> if ((key = malloc(klen + 1)) == NULL)
> This time I used "... == NULL".
Er... The bang is Jeff's, which I try to follow always
On Thu, 23 Sep 2010 12:53:06 +0200
Jim Meyering wrote:
> I factored out the append_const definition to avoid
> having to wrap the long lines with the increased indentation.
> p = s;
>
> +#define append_const(buf, c) \
> + do { memcpy(buf, c, sizeof(c)-1); (buf) += sizeof(c)-1; } while (0
On Thu, 23 Sep 2010 00:32:09 -0400
Jeff Garzik wrote:
> >>> So, we go a longer route and re-hook the list of completions
> >>> to a per-server global instead of a client. The patch is straight-
> >>> forward. The only thing we need to be careful is to make sure
> >>> that
Signed-off-by: Jim Meyering
---
Just noticed that sometimes tabled uses this idiom:
if (!(key = malloc(klen + 1)))
and sometimes this:
if ((key = malloc(klen + 1)) == NULL)
This time I used "... == NULL".
server/server.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --
This was a little more work to fix.
Can't return early without leaking, so I made all
of those P derefs conditional on P being non-NULL.
I factored out the append_const definition to avoid
having to wrap the long lines with the increased indentation.
>From b354befe9f7fe754c5fe012e424ccec84ef4e96d
>From aed01fa24688257fdf6f3c5ecf6983f61b8749f8 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 23 Sep 2010 11:12:27 +0200
Subject: [PATCH tabled] server/status.c: don't deref NULL on failed strdup
Use a non-malloc'd string upon failed strdup so
we don't have to diagnose failure.
Signed-o
>From 6193423b13197c63ff36d01438a23b4b1278825b Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 23 Sep 2010 11:02:36 +0200
Subject: [PATCH tabled] server/server.c: don't deref NULL on failed strdup
Here, pathtokey does handle a NULL argument, but the following
applog/printf would dereferen
This first one is so small it barely deserved a commit.
The second fixes a bug.
>From 8e6255aa5cddd7bd58d7e4dbd2ecc81f84c51ea2 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 23 Sep 2010 10:47:22 +0200
Subject: [PATCH tabled 1/2] server/server.c: use "sizeof s" rather than
equivalent "64"
Looking at tabled's code, I see a few places where unchecked strdup
can lead to NULL deref, whereas the majority are checked carefully.
Patches for the first two I found are below -- haven't completed the job.
In most cases, I see that care is taken to detect failure and propagate
that to higher
Jeff Garzik wrote:
> On 09/23/2010 03:55 AM, Jim Meyering wrote:
>> Better safe than sorry...
>> Unreported write failures can be unpleasant.
>> I fixed the one below so that a failure indication
>> can propagate up the call tree. You might also want to
>> report the failure to stderr.
>>
>> I le
On 09/23/2010 03:55 AM, Jim Meyering wrote:
Better safe than sorry...
Unreported write failures can be unpleasant.
I fixed the one below so that a failure indication
can propagate up the call tree. You might also want to
report the failure to stderr.
I let my editor automatically update the cop
Better safe than sorry...
Unreported write failures can be unpleasant.
I fixed the one below so that a failure indication
can propagate up the call tree. You might also want to
report the failure to stderr.
I let my editor automatically update the copyright date
and remove trailing spaces.
If you
26 matches
Mail list logo
