Discussion:
[rancid] Problem backing up HP switches on RHEL 6.2 (x86_64) -- patch included
David Byers
2012-02-08 11:52:12 UTC
Permalink
On 2010-06-25 a change was checked in to GNU libc that changes how
memcpy works on certain architectures. Previously it copied overlapping
memory regions correctly; now it doesn't.

The net result for rancid is that backups of HP switches don't work on
e.g. RedHat Enterprise Linux with glibc-2.12-1.47 (x86_64). The output
gets garbled, and rancid fails to complete the backup process in many
cases. The cause appears to be memcpy calls in hpuifilter.

The patch below appears to solve the problem (at least our backups look
OK again); I've simply replaced all memcpy calls with calls to memmove;
probably some of them don't need to be replaced, but I don't see any
harm in doing so -- memmove may be a little slower, but I doubt that
this is a bottleneck in rancid.

Unified diff follows below.

David Byers
Linköping University



--- hpuifilter.c 2012-02-08 09:45:18.427498055 +0100
+++ hpuifilter_org.c 2012-02-08 08:30:28.856503169 +0100
@@ -367,7 +367,7 @@
break;
} else if (bytes > 0) {
hlen -= bytes;
- memmove(hbuf, hbuf + bytes, hlen + 1);
+ memcpy(hbuf, hbuf + bytes, hlen + 1);
if (hlen < 1)
pfds[2].events &= ~POLLOUT;
}
@@ -423,7 +423,7 @@
break;
} else if (bytes > 0) {
tlen -= bytes;
- memmove(tbuf, tbuf + bytes, tlen + 1);
+ memcpy(tbuf, tbuf + bytes, tlen + 1);
if (tlen < 1)
pfds[1].events &= ~POLLOUT;
}
@@ -593,7 +593,7 @@
if (len - pmatch[0].rm_eo <= 0) {
buf[pmatch[0].rm_so] = '\0';
} else {
- memmove(buf + pmatch[0].rm_so, buf + pmatch[0].rm_eo,
+ memcpy(buf + pmatch[0].rm_so, buf + pmatch[0].rm_eo,
len - pmatch[0].rm_eo + 1);
}
len -= pmatch[0].rm_eo - pmatch[0].rm_so;
@@ -616,7 +616,7 @@
if (len - pmatch[0].rm_eo == 0) {
buf[pmatch[0].rm_so] = '\0';
} else {
- memmove(buf + pmatch[0].rm_so, buf + pmatch[0].rm_eo,
+ memcpy(buf + pmatch[0].rm_so, buf + pmatch[0].rm_eo,
len - pmatch[0].rm_eo + 1);
}
len -= pmatch[0].rm_eo - pmatch[0].rm_so;
heasley
2012-02-08 18:05:33 UTC
Permalink
Post by David Byers
On 2010-06-25 a change was checked in to GNU libc that changes how
memcpy works on certain architectures. Previously it copied overlapping
memory regions correctly; now it doesn't.
The net result for rancid is that backups of HP switches don't work on
e.g. RedHat Enterprise Linux with glibc-2.12-1.47 (x86_64). The output
gets garbled, and rancid fails to complete the backup process in many
cases. The cause appears to be memcpy calls in hpuifilter.
The patch below appears to solve the problem (at least our backups look
OK again); I've simply replaced all memcpy calls with calls to memmove;
probably some of them don't need to be replaced, but I don't see any
harm in doing so -- memmove may be a little slower, but I doubt that
this is a bottleneck in rancid.
Oh, you are a gentleman and a scholar. Thanks! It must now be using block
copy ops.
Andy Cobaugh
2012-02-09 00:27:20 UTC
Permalink
This patch works, though the diff provided was done in the wrong
direction.

--andy
David Byers
2012-02-09 05:54:19 UTC
Permalink
Post by Andy Cobaugh
This patch works, though the diff provided was done in the wrong
direction.
Yeah. Sorry about that; I was a bit rushed yesterday.
--
David Byers.
Loading...