* fdisk
From: Bruce Dubbs @ 2011-06-24 18:25 UTC (permalink / raw)
To: util-linux
In fdisk, printing a partition table gives the headers:
Device Boot Start End Blocks Id System
What's a block? It does not seem to be defined anywhere. Perhaps an
update to the man page would be appropriate. A line in the explanation
above the partition listing would be even better.
On my system, a block appears to be 2-512 byte sectors, but is it always so?
-- Bruce
^ permalink raw reply
* [PATCH] lscpu: fix bogomips detection for s390
From: Heiko Carstens @ 2011-06-21 11:24 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
From: Heiko Carstens <heiko.carstens@de.ibm.com>
s390 has a "bogomips per cpu" string instead of a "bogomips" string in
/proc/sysinfo. So add a second bogomips lookup which detects the s390
variant.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
sys-utils/lscpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sys-utils/lscpu.c b/sys-utils/lscpu.c
index 027a298..1481fef 100644
--- a/sys-utils/lscpu.c
+++ b/sys-utils/lscpu.c
@@ -369,6 +369,8 @@ read_basicinfo(struct lscpu_desc *desc)
else if (lookup(buf, "cpu MHz", &desc->mhz)) ;
else if (lookup(buf, "flags", &desc->flags)) ;
else if (lookup(buf, "bogomips", &desc->bogomips)) ;
+ /* S390 */
+ else if (lookup(buf, "bogomips per cpu", &desc->bogomips)) ;
else
continue;
}
^ permalink raw reply related
* [PATCH] mkfs.minix: check for misalignment
From: Davidlohr Bueso @ 2011-06-21 3:11 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
From: Davidlohr Bueso <dave@gnu.org>
Date: Mon, 20 Jun 2011 23:10:13 -0400
Produce a warning if the device is misaligned.
Signed-off-by: Davidlohr Bueso <dave@gnu.org>
---
disk-utils/mkfs.minix.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/disk-utils/mkfs.minix.c b/disk-utils/mkfs.minix.c
index 405e241..bc7d941 100644
--- a/disk-utils/mkfs.minix.c
+++ b/disk-utils/mkfs.minix.c
@@ -653,6 +653,11 @@ int main(int argc, char ** argv) {
DEV = open(device_name,O_RDWR | O_EXCL);
else
DEV = open(device_name,O_RDWR);
+
+ if (blkdev_is_misaligned(DEV))
+ warnx(_("warning: %s is misaligned"), device_name);
+
+
if (DEV<0)
err(MKFS_ERROR, _("%s: open failed"), device_name);
if (S_ISBLK(statbuf.st_mode)) {
--
1.7.5.4
^ permalink raw reply related
* [PATCH] blkdev: add blkdev_get_physector_size()
From: Davidlohr Bueso @ 2011-06-21 2:58 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
From: Davidlohr Bueso <dave@gnu.org>
Date: Mon, 20 Jun 2011 22:51:47 -0400
This function uses the BLKPBSZGET ioctl to get the physical block size of the device.
Signed-off-by: Davidlohr Bueso <dave@gnu.org>
---
include/blkdev.h | 3 +++
lib/blkdev.c | 14 ++++++++++++++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/include/blkdev.h b/include/blkdev.h
index 6a64172..0024897 100644
--- a/include/blkdev.h
+++ b/include/blkdev.h
@@ -95,4 +95,7 @@ int blkdev_get_sector_size(int fd, int *sector_size);
/* specifies whether or not the device is misaligned */
int blkdev_is_misaligned(int fd);
+/* get physical block device size */
+int blkdev_get_physector_size(int fd);
+
#endif /* BLKDEV_H */
diff --git a/lib/blkdev.c b/lib/blkdev.c
index 5cb6554..94df803 100644
--- a/lib/blkdev.c
+++ b/lib/blkdev.c
@@ -221,6 +221,20 @@ int blkdev_is_misaligned(int fd)
#endif
}
+/* get physical block device size */
+int blkdev_get_physector_size(int fd)
+{
+#ifdef BLKPBSZGET
+ int bsz;
+
+ if (ioctl(fd, BLKPBSZGET, &bsz) < 0)
+ return 0;
+ return bsz;
+#else
+ return 0;
+#endif
+}
+
#ifdef TEST_PROGRAM
#include <stdio.h>
#include <stdlib.h>
--
1.7.5.4
^ permalink raw reply related
* Re: blkid: excessive random reads probing for ZFS on NTFS filesystem
From: Karel Zak @ 2011-06-20 14:57 UTC (permalink / raw)
To: John Lindgren; +Cc: util-linux, Andreas Dilger
In-Reply-To: <4DFF5712.4070606@tds.net>
On Mon, Jun 20, 2011 at 10:20:02AM -0400, John Lindgren wrote:
> On 06/20/2011 10:04 AM, Karel Zak wrote:
> > On Mon, Jun 20, 2011 at 09:05:36AM -0400, John Lindgren wrote:
> >> I did try that; however, blkid checks *all* filesystems, even after it
> >> finds a match, just in case two probes turn up positive. Even passing
> >> "-n nozfs" doesn't actually prevent it from checking for ZFS.
> > The name of the FS in libblkid is zfs_member :-)
> >
> > blkid -p -o udev -n nozfs_member
> >
> > Yeah, crazy name, see our TODO file:
> >
> > - add something like "blkid --list-known" to list all supported
> > filesystems/raids
Implemented,
blkid -k
lists all known filesystems/RAIDs now.
> Perhaps a "-q/--quick" option could be added to blkid to allow an early
> exit once the first positive match is found?
That's dangerous, and many times rejected by udev upstream. The
mainstream distributions rely on the automatic FS detection on many
places. We are not able to control mkfs and partitioning tools, so we
are not sure that the device has been properly wiped and there is
really only one valid superblock. We already have bad experience with
FAT, linux swap, luks, ... some people already lost data.
> Then more difficult checks
> such as ZFS could be moved to the end of the list, as you suggest, with
> a performance benefit.
What about to set to blkid (during boot) greater I/O priority than to
read-ahead?
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: blkid: excessive random reads probing for ZFS on NTFS filesystem
From: John Lindgren @ 2011-06-20 14:20 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux, Andreas Dilger
In-Reply-To: <20110620140457.GI17967@nb.net.home>
On 06/20/2011 10:04 AM, Karel Zak wrote:
> On Mon, Jun 20, 2011 at 09:05:36AM -0400, John Lindgren wrote:
>> I did try that; however, blkid checks *all* filesystems, even after it
>> finds a match, just in case two probes turn up positive. Even passing
>> "-n nozfs" doesn't actually prevent it from checking for ZFS.
> The name of the FS in libblkid is zfs_member :-)
>
> blkid -p -o udev -n nozfs_member
>
> Yeah, crazy name, see our TODO file:
>
> - add something like "blkid --list-known" to list all supported
> filesystems/raids
>
> Karel
My bad. "-n nozfs_member" does work, so I will add it to my udev rules
locally.
Perhaps a "-q/--quick" option could be added to blkid to allow an early
exit once the first positive match is found? Then more difficult checks
such as ZFS could be moved to the end of the list, as you suggest, with
a performance benefit.
-- John
^ permalink raw reply
* Re: blkid: excessive random reads probing for ZFS on NTFS filesystem
From: Karel Zak @ 2011-06-20 14:04 UTC (permalink / raw)
To: John Lindgren; +Cc: util-linux, Andreas Dilger
In-Reply-To: <4DFF45A0.1040703@tds.net>
On Mon, Jun 20, 2011 at 09:05:36AM -0400, John Lindgren wrote:
> I did try that; however, blkid checks *all* filesystems, even after it
> finds a match, just in case two probes turn up positive. Even passing
> "-n nozfs" doesn't actually prevent it from checking for ZFS.
The name of the FS in libblkid is zfs_member :-)
blkid -p -o udev -n nozfs_member
Yeah, crazy name, see our TODO file:
- add something like "blkid --list-known" to list all supported
filesystems/raids
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: blkid: excessive random reads probing for ZFS on NTFS filesystem
From: John Lindgren @ 2011-06-20 13:05 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux, Andreas Dilger
In-Reply-To: <20110620124612.GF17967@nb.net.home>
On 06/20/2011 08:46 AM, Karel Zak wrote:
> Unfortunately, the old less expensive version of the ZFS detection
> code was insufficient. See Andreas' patches:
>
> commit e54a76ca076625b1883ddf0595162eb8de81d5d1
> Author: Andreas Dilger <adilger@sun.com>
> Date: Wed Feb 17 10:21:27 2010 +0100
>
> commit a1fbeb3df35d1441c4ef64ea7e04c2b1fda38ba2
> Author: Andreas Dilger <adilger@sun.com>
> Date: Thu Mar 11 15:16:46 2010 +0100
Understood. The older implementation performed a less thorough search
for a valid uberblock, which I would expect to sometimes fail.
>> Andreas: As far as implementation, I think the ZFS code could be
>> improved by parsing the name-value pair list *before* searching for a
>> valid uberblock, rather than after.
> Doesn't depend the position of the list on the position of the valid
> uberblock?
No, it's at a fixed offset of 16k within the vdev label (before the
uberblock array, which is at 128k).
>> I don't have any ZFS filesystems
>> around to test with, or I would try to do this myself.
> There is a test image, see tests/ts/blkid/images-fs/zfs.img.bz2
Okay, thanks.
> Maybe you can try to move zfs to the end of the probed filesystems
> in libblkid/src/superblocks/superblocks.c. It would be better to
> probe for exotic and "expensive" filesytems later.
I did try that; however, blkid checks *all* filesystems, even after it
finds a match, just in case two probes turn up positive. Even passing
"-n nozfs" doesn't actually prevent it from checking for ZFS.
Maybe it would be better to change this behavior and leave the ZFS code
as is?
-- John
^ permalink raw reply
* Re: blkid: excessive random reads probing for ZFS on NTFS filesystem
From: Karel Zak @ 2011-06-20 12:46 UTC (permalink / raw)
To: John Lindgren; +Cc: util-linux, Andreas Dilger
In-Reply-To: <4DFF3613.9050705@tds.net>
On Mon, Jun 20, 2011 at 07:59:15AM -0400, John Lindgren wrote:
> On 06/20/2011 07:16 AM, Karel Zak wrote:
> > On Sun, Jun 12, 2011 at 03:02:48PM -0400, John Lindgren wrote:
> >> I noticed blkid causing a noticeable amount of disk hits while
> >> identifying an NTFS (Win7) partition, and did an strace to find out why
> >> this was. It seems that the probe_zfs() function does a
> >> seek-and-read-41-bytes pattern 64 times in the 130 to 520 KB region of
> >> the partition.
> > Is it really so big problem on traditional HDDs?
> Many traditional HD's are rated with a seek time of ~10 ms (though I
> work with older hardware mostly; newer ones may be better). So by a
> naive calculation that would make probe_zfs take 0.64 seconds. Now, in
> the case of probe_zfs, the seeks have good locality, so in practice it
> will not take that long -- provided blkid is the only program accessing
> the disk at that time. If the system has some sort of read-ahead
> process running during boot (as I do), then locality is lost for both
> blkid and the read-ahead process, and you get thrashing.
>
> Also take into consideration that while 64 seeks may not seem excessive
> in itself, that is for only one filesystem, and blkid checks something
> on the order of 40 different filesystems. (Fortunately none of the
> others take anywhere near the number of seeks that zfs_probe does.)
Unfortunately, the old less expensive version of the ZFS detection
code was insufficient. See Andreas' patches:
commit e54a76ca076625b1883ddf0595162eb8de81d5d1
Author: Andreas Dilger <adilger@sun.com>
Date: Wed Feb 17 10:21:27 2010 +0100
commit a1fbeb3df35d1441c4ef64ea7e04c2b1fda38ba2
Author: Andreas Dilger <adilger@sun.com>
Date: Thu Mar 11 15:16:46 2010 +0100
> Andreas: As far as implementation, I think the ZFS code could be
> improved by parsing the name-value pair list *before* searching for a
> valid uberblock, rather than after.
Doesn't depend the position of the list on the position of the valid
uberblock?
> I don't have any ZFS filesystems
> around to test with, or I would try to do this myself.
There is a test image, see tests/ts/blkid/images-fs/zfs.img.bz2
Maybe you can try to move zfs to the end of the probed filesystems
in libblkid/src/superblocks/superblocks.c. It would be better to
probe for exotic and "expensive" filesytems later.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH 1/4] uuidgen: fail if uuidd isn't running
From: Ludwig Nussel @ 2011-06-20 12:18 UTC (permalink / raw)
To: util-linux; +Cc: Karel Zak, Ted Ts'o
In-Reply-To: <20110620104548.GC17967@nb.net.home>
Karel Zak wrote:
> On Thu, Jun 16, 2011 at 10:07:56PM -0400, Ted Ts'o wrote:
> > On Thu, Jun 16, 2011 at 03:59:36PM +0200, Ludwig Nussel wrote:
> > > time bases uuids are not safe if uuidd is not running.
> > > Add option --force to generate a uuid in this case nevertheless.
> >
> > I really wouldn't worry about time-based uuid if you're grabbing them
> > from uuidgen. Yes, if you're generating thousands of uuid's in
> > parallel via the C interface, it's possible that you potentially force
> > a collision. But via the command-line interface of uuidgen?
>=20
> I agree with Ted.=20
>=20
> Let's go one step back (sorry Ludwig). It would be really better to
> add --safe rather than --force. We can use the --safe option to test
> the new *_safe functions or for really paranoid environments, but we
> should not force people use the new functionality.
Actually never mind, forget about the patches. I'm perfectly fine
with a 'no'. This discussion now finally documents in public the
background and reasons why things are the way they are. Thanks a lot
for your patience and Ted for the detailed explanation!
cu
Ludwig
=2D-=20
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffe=
r, HRB 16746 (AG N=FCrnberg)=20
^ permalink raw reply
* Re: blkid: excessive random reads probing for ZFS on NTFS filesystem
From: John Lindgren @ 2011-06-20 12:02 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
In-Reply-To: <20110620111640.GE17967@nb.net.home>
On 06/20/2011 07:16 AM, Karel Zak wrote:
> CC: Andreas who is the code (co)author.
His sun.com address is not active any more (as you have probably noticed).
-- John
^ permalink raw reply
* Re: blkid: excessive random reads probing for ZFS on NTFS filesystem
From: John Lindgren @ 2011-06-20 11:59 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux, Andreas Dilger
In-Reply-To: <20110620111640.GE17967@nb.net.home>
On 06/20/2011 07:16 AM, Karel Zak wrote:
> On Sun, Jun 12, 2011 at 03:02:48PM -0400, John Lindgren wrote:
>> I noticed blkid causing a noticeable amount of disk hits while
>> identifying an NTFS (Win7) partition, and did an strace to find out why
>> this was. It seems that the probe_zfs() function does a
>> seek-and-read-41-bytes pattern 64 times in the 130 to 520 KB region of
>> the partition.
> Is it really so big problem on traditional HDDs?
Many traditional HD's are rated with a seek time of ~10 ms (though I
work with older hardware mostly; newer ones may be better). So by a
naive calculation that would make probe_zfs take 0.64 seconds. Now, in
the case of probe_zfs, the seeks have good locality, so in practice it
will not take that long -- provided blkid is the only program accessing
the disk at that time. If the system has some sort of read-ahead
process running during boot (as I do), then locality is lost for both
blkid and the read-ahead process, and you get thrashing.
Also take into consideration that while 64 seeks may not seem excessive
in itself, that is for only one filesystem, and blkid checks something
on the order of 40 different filesystems. (Fortunately none of the
others take anywhere near the number of seeks that zfs_probe does.)
Andreas: As far as implementation, I think the ZFS code could be
improved by parsing the name-value pair list *before* searching for a
valid uberblock, rather than after. I don't have any ZFS filesystems
around to test with, or I would try to do this myself.
-- John
^ permalink raw reply
* Re: [PATCH 2/4] uuid: implement uuid_generate_random_safe
From: Theodore Tso @ 2011-06-20 11:45 UTC (permalink / raw)
To: Ludwig Nussel; +Cc: util-linux
In-Reply-To: <201106170937.36082.ludwig.nussel@suse.de>
On Jun 17, 2011, at 3:37 AM, Ludwig Nussel wrote:
>>
>> Also please note that there's only *one* user of the uuid library, the
>> proprietary SAP R/3 system, that generates enough uuids, and with a
>> high enough frequency, where "safety" has ever been an issue. Most of
>> the time, people simply aren't generating uuid's at the rate of
>> thousands a second.
>
> I can't judge. We got quite some pressure to set the setuid bit on
> uuidd by default because 'several customers' demand it. Making the
> interface more explicitly require uuidd would defeat arguments that
> an application and the admin can't even notice there's a problem.
Look, a time-based UUID is composed of a ethernet MAC address
(for uniqueness in space, assuming NIC's are assigned unique
MAC addresses0, a 100ns granularity timestamp (for uniqueness
in time), and a 13-bit counter.
We are using gettimeofday(), which has microsecond granularity,
so if you have multiple calls to generate UUID's within the same
microsecond, called from different CPU's, now the only thing
protecting you is the 13-bit counter, which is initialized to a
random value w/o uuidd. To make matters worse, the proprietary
SAP system abuses UUID's by folding, spindling, and mutilating
UUID's so the timestamp appears in the most significant bits,
so that its btree lookups (it's using the UUID's as a object id) in
the database can be as efficient as possible. Which is why they
can't use /dev/random generated UUID's --- well, that and this
is being used in their database initialization program, where
they are generating literally millions of uuid's, and /dev/random
or some kind of scheme where you throttle time-based UUID
generation would slow down the SAP R/3 database load
process unacceptably. (I worked with your predecessor at
SuSE/Novell, and wrote uuidd specifically because to help
out SAP, mainly because (a) I was at IBM at the time, and figured
customers of IBM hardware would care, and (b) I have one
or two friends who work at SAP, and wanted to help them out.
But I never intended for uuidd to become mandatory, and I
got complaints from some distro's about adding yet another
daemon.)
This is why I'm pretty confident *no* *one* other than SAP is
going to be running into this problem, because I don't know of
anyone else which is generating UUID's at this insane rate ---
and would be quite, quite surprised if they were.
These days, we have a higher resolution clock interface, so at
least in theory we could use clock_gettime(), which would give
us a nanosecond interface. This would give us another factor
of 10 improvement on the granularity of time-based UUID's.
This might be worth doing, if someone really cared. If they do,
though, I'd request that it be autoconf'ed, so that this library
remains portable to non-Linux environments --- there are folks
who are using this library to build GNOME and other OSS
packages on *BSD's and Solaris systems, for example ---
although I suspect many of them are still using the uuid library
from e2fsprogs.
-- Ted
^ permalink raw reply
* Re: blkid: excessive random reads probing for ZFS on NTFS filesystem
From: Karel Zak @ 2011-06-20 11:16 UTC (permalink / raw)
To: John Lindgren; +Cc: util-linux, Andreas Dilger
In-Reply-To: <4DF50D58.9020800@tds.net>
On Sun, Jun 12, 2011 at 03:02:48PM -0400, John Lindgren wrote:
> I noticed blkid causing a noticeable amount of disk hits while
> identifying an NTFS (Win7) partition, and did an strace to find out why
> this was. It seems that the probe_zfs() function does a
> seek-and-read-41-bytes pattern 64 times in the 130 to 520 KB region of
> the partition.
Is it really so big problem on traditional HDDs?
> This of course is slow on a traditional hard disk, and
> seems excessive. I don't know the internals of NTFS or of ZFS. Can
> someone with a little more knowledge in this area provide some pointers
> as to why this might be happening?
CC: Andreas who is the code (co)author.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH] lscpu: detect VMware hypervisor
From: Karel Zak @ 2011-06-20 10:54 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: util-linux
In-Reply-To: <20110616165407.00c4d7ab@s6510.ftrdhcpuser.net>
On Thu, Jun 16, 2011 at 04:54:07PM -0400, Stephen Hemminger wrote:
> Add detection of VMware.
> Tested on VMware Workstation 7.1.4
> ---
> sys-utils/lscpu.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
Applied, thanks.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH,HURD] Fix Hurd build
From: Karel Zak @ 2011-06-20 10:52 UTC (permalink / raw)
To: Samuel Thibault, util-linux
In-Reply-To: <20110619153435.GA28888@const.famille.thibault.fr>
On Sun, Jun 19, 2011 at 05:34:35PM +0200, Samuel Thibault wrote:
> There are a lot of build failures due to BLKALIGNOFF not being available
> on the Hurd, as well as a few other glitches, see log below. I've also
> attached a proposed patch.
Applied, thanks.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH 1/4] uuidgen: fail if uuidd isn't running
From: Karel Zak @ 2011-06-20 10:45 UTC (permalink / raw)
To: Ted Ts'o; +Cc: Ludwig Nussel, util-linux
In-Reply-To: <20110617020756.GB29725@thunk.org>
On Thu, Jun 16, 2011 at 10:07:56PM -0400, Ted Ts'o wrote:
> On Thu, Jun 16, 2011 at 03:59:36PM +0200, Ludwig Nussel wrote:
> > time bases uuids are not safe if uuidd is not running.
> > Add option --force to generate a uuid in this case nevertheless.
>
> I really wouldn't worry about time-based uuid if you're grabbing them
> from uuidgen. Yes, if you're generating thousands of uuid's in
> parallel via the C interface, it's possible that you potentially force
> a collision. But via the command-line interface of uuidgen?
I agree with Ted.
Let's go one step back (sorry Ludwig). It would be really better to
add --safe rather than --force. We can use the --safe option to test
the new *_safe functions or for really paranoid environments, but we
should not force people use the new functionality.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH 3/4] uuid: use new functions by default
From: Karel Zak @ 2011-06-20 10:35 UTC (permalink / raw)
To: Ludwig Nussel; +Cc: util-linux
In-Reply-To: <1308232779-21018-3-git-send-email-ludwig.nussel@suse.de>
On Thu, Jun 16, 2011 at 03:59:38PM +0200, Ludwig Nussel wrote:
> -void uuid_generate(uuid_t out);
> -void uuid_generate_random(uuid_t out);
> -void uuid_generate_time(uuid_t out);
> int uuid_generate_time_safe(uuid_t out) __attribute__((warn_unused_result));
> int uuid_generate_random_safe(uuid_t out) __attribute__((warn_unused_result));
> int uuid_generate_safe(uuid_t out) __attribute__((warn_unused_result));
> +#ifdef LIBUUID_UNSAFE_LEGACY_PROTOTYPES
> +void uuid_generate(uuid_t out) __attribute__((deprecated));
> +void uuid_generate_random(uuid_t out) __attribute__((deprecated));
> +void uuid_generate_time(uuid_t out) __attribute__((deprecated));
> +#else
> +static inline int uuid_generate_time(uuid_t out) { return uuid_generate_time_safe(out); }
> +static inline int uuid_generate_random(uuid_t out) { return uuid_generate_random_safe(out); }
> +static inline int uuid_generate(uuid_t out) { return uuid_generate_safe(out); }
> +#endif
Oh, <censored> ... :-)
Please, move this change to your (SAP) applications. I really don't
want to mess up the library API for a reason which is completely
irrelevant for 99% of all users.
I don't think that overwrite any exported symbols with in-line
functions is a good way how maintain any API.
I don't see a problem to support the *_safe functions for you, but
don't force us to use it.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: Pentecost weekend pull request
From: Karel Zak @ 2011-06-20 10:19 UTC (permalink / raw)
To: Sami Kerola; +Cc: util-linux
In-Reply-To: <1307978030-13006-1-git-send-email-kerolasa@iki.fi>
On Mon, Jun 13, 2011 at 05:13:50PM +0200, Sami Kerola wrote:
> I feel a bit embarrassed to see how many patches I wrote. My
> excuse is long, mostly rainy, weekend. Here comes a pull request;
:-)
> [01/33] mount: take xalloc.h in use
It would be better to keep my_free() in mount/ sources only. I don't
think that we will use this crap outside the mount code.
Note that the final solution will be libmount/mount.c as the mount(8)
command implementation. So, let's keep the current mount/* code in
maintenance mode and don't try to rewrite it :-)
> [02/33] checktty: NGROUP -> sysconf
> This patch was sent earlier, see details bellow.
>
> date Thu, Jun 9, 2011 at 21:31
> subject Re: [PATCH 3/6] checktty: Use NGROUPS_MAX instead of NGROUPS
You cannot use xalloc() (and friends) in login(1). The login has to
call pam_end and report to syslog before exit.
I'd like to clean up login(1), it means:
- code refactoring
- support PAM or /etc/{passwd,shadow} *only*
- remove checktty support
- remove cryptocard support
- remove kerberos support
> [04/33] login-utils: include fix
> Inspired what P?draig Brady did with coreutils I thought
> to give a shot to include-what-you-use as well.
> http://lists.gnu.org/archive/html/coreutils/2011-06/msg00004.html
>
> The utility clearly works. So it is a good time to think
> if checking headers in all files should be TODO item?
Nice!
What about to add any wrapper to the tools/ directory and call it
from our top-level Makefile?
We already have some stuff there, and I use it before release.
> [10/33] mcookie: change coding style
> The mcookie patches are trivial, with exception of docs
> change. Updating manual pages with help2man seems to be
> quite good idea. Using the output as is is pretty brain
> dead idea, but copy pasting bits of syntax etc seems to
> work great. Is this an approach you would like to see in
> future?
It depends, the --help output is usually very brief and space-saving.
Don't forget that GNU guys hate man pages and all their documentation
is in the horrible info files, so help2man makes sense for them ;-)
We don't have info files, but we have real man pages.
> [11/33] whereis: maintenance fixes
I can imagine more than one patch for these changes.
> [12/33] cal: maintenance fixes
I'll use this patch, but next time don't mix any real changes in the
code with indentation changes. Please!
> [15/33] docs: rename.1 verbose, long options and warning
> Looking the code this utility seems to be in wrong
> package. Rewriting the command to rely heavily on gnulib
> copy.h and backupfile.h would make this to be good
> addition to coreutils, assuming they accept the command.
Yep, go ahead and ask at coreutils mailing list.
> Or it could time to deprecate the whole command, and
> recommend users to multimove by using scripts.
The command is used by many users. I don't think that deprecation is
a good idea. And I also don't think that change the default behavior
is a good idea. Maybe we can add --dry-run.
> [18/33] write: maintenance fixes
Don't use
return (1);
use
return 1;
The "return" is not a function.
> [23/33] uuidd: maintenance fixes
- remove die() -- use err()
- remove printf() + exit() -- use err[x]()
- print all error messages (!= debug) to stderr
> [32/33] getopt: inform where to send bug reports
> I wonder should the config.h PACKAGE_BUGREPORT be
> util-linux mail list...
Probably ;-)
We shouldn't use PACKAGE_BUGREPORT in man pages or --help output. I
don't think that upstream is the right place for end-users and their
bug reports.
The ideal solution is downstream --patch--> upstream ;-)
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* [PATCH,HURD] Fix Hurd build
From: Samuel Thibault @ 2011-06-19 15:34 UTC (permalink / raw)
To: util-linux
[-- Attachment #1: Type: text/plain, Size: 5128 bytes --]
Hello,
There are a lot of build failures due to BLKALIGNOFF not being available
on the Hurd, as well as a few other glitches, see log below. I've also
attached a proposed patch.
Samuel
$ make -k
[...]
make[2]: Entering directory `/home/sthibaul-guest/util-linux-ng/disk-utils'
CC mkswap-blkdev.o
../lib/blkdev.c: In function 'blkdev_is_misaligned':
../lib/blkdev.c:215: error: 'BLKALIGNOFF' undeclared (first use in this function)
../lib/blkdev.c:215: error: (Each undeclared identifier is reported only once
../lib/blkdev.c:215: error: for each function it appears in.)
[...]
make[4]: Entering directory `/home/sthibaul-guest/util-linux-ng/libblkid/src'
CC blkdev.lo
../../lib/blkdev.c: In function 'blkdev_is_misaligned':
../../lib/blkdev.c:215: error: 'BLKALIGNOFF' undeclared (first use in this function)
../../lib/blkdev.c:215: error: (Each undeclared identifier is reported only once
../../lib/blkdev.c:215: error: for each function it appears in.)
[...]
make[3]: Leaving directory `/home/sthibaul-guest/util-linux-ng/libblkid/src'
make[2]: *** [../libblkid/src/libblkid.la] Error 2
CC blkdev.o
../lib/blkdev.c: In function 'blkdev_is_misaligned':
../lib/blkdev.c:215: error: 'BLKALIGNOFF' undeclared (first use in this function)
../lib/blkdev.c:215: error: (Each undeclared identifier is reported only once
../lib/blkdev.c:215: error: for each function it appears in.)
make[2]: *** [blkdev.o] Error 1
CC swaplabel-blkdev.o
../lib/blkdev.c: In function 'blkdev_is_misaligned':
../lib/blkdev.c:215: error: 'BLKALIGNOFF' undeclared (first use in this function)
../lib/blkdev.c:215: error: (Each undeclared identifier is reported only once
../lib/blkdev.c:215: error: for each function it appears in.)
[...]
make[2]: Entering directory `/home/sthibaul-guest/util-linux-ng/fdisk'
CC fdisk-blkdev.o
../lib/blkdev.c: In function 'blkdev_is_misaligned':
../lib/blkdev.c:215: error: 'BLKALIGNOFF' undeclared (first use in this function)
../lib/blkdev.c:215: error: (Each undeclared identifier is reported only once
../lib/blkdev.c:215: error: for each function it appears in.)
[...]
make[4]: Entering directory
`/home/sthibaul-guest/util-linux-ng/libblkid/src'
CC blkdev.lo
../../lib/blkdev.c: In function 'blkdev_is_misaligned':
../../lib/blkdev.c:215: error: 'BLKALIGNOFF' undeclared (first use in
this function)
../../lib/blkdev.c:215: error: (Each undeclared identifier is reported
only once
../../lib/blkdev.c:215: error: for each function it appears in.)
[...]
make[2]: Entering directory `/home/sthibaul-guest/util-linux-ng/lib'
CC blkdev.o
blkdev.c: In function 'blkdev_is_misaligned':
blkdev.c:215: error: 'BLKALIGNOFF' undeclared (first use in this function)
blkdev.c:215: error: (Each undeclared identifier is reported only once
blkdev.c:215: error: for each function it appears in.)
make[2]: *** [blkdev.o] Error 1
CC procutils.o
procutils.c: In function 'proc_open_tasks':
procutils.c:35: error: 'PATH_MAX' undeclared (first use in this function)
procutils.c:35: error: (Each undeclared identifier is reported only once
procutils.c:35: error: for each function it appears in.)
make[2]: *** [procutils.o] Error 1
[...]
make[4]: Entering directory `/home/sthibaul-guest/util-linux-ng/libblkid/src'
CC blkdev.lo
../../lib/blkdev.c: In function 'blkdev_is_misaligned':
../../lib/blkdev.c:215: error: 'BLKALIGNOFF' undeclared (first use in this function)
../../lib/blkdev.c:215: error: (Each undeclared identifier is reported only once
../../lib/blkdev.c:215: error: for each function it appears in.)
[...]
make[4]: Entering directory `/home/sthibaul-guest/util-linux-ng/libblkid/src'
CC blkdev.lo
../../lib/blkdev.c: In function 'blkdev_is_misaligned':
../../lib/blkdev.c:215: error: 'BLKALIGNOFF' undeclared (first use in this function)
../../lib/blkdev.c:215: error: (Each undeclared identifier is reported only once
../../lib/blkdev.c:215: error: for each function it appears in.)
[...]
make[2]: Entering directory `/home/sthibaul-guest/util-linux-ng/schedutils'
CC procutils.o
../lib/procutils.c: In function 'proc_open_tasks':
../lib/procutils.c:35: error: 'PATH_MAX' undeclared (first use in this function)
../lib/procutils.c:35: error: (Each undeclared identifier is reported only once
../lib/procutils.c:35: error: for each function it appears in.)
make[2]: *** [procutils.o] Error 1
[...]
make[2]: Entering directory
`/home/sthibaul-guest/util-linux-ng/term-utils'
CC agetty.o
agetty.c: In function 'reset_vc':
agetty.c:1042: error: 'OFDEL' undeclared (first use in this function)
agetty.c:1042: error: (Each undeclared identifier is reported only
once
agetty.c:1042: error: for each function it appears in.)
agetty.c:1045: error: 'XCASE' undeclared (first use in this function)
agetty.c:1071: error: 'VSWTCH' undeclared (first use in this function)
agetty.c: In function 'log_err':
agetty.c:1608: error: 'LOG_ERR' undeclared (first use in this
function)
agetty.c: In function 'log_warn':
agetty.c:1621: error: 'LOG_WARNING' undeclared (first use in this
function)
make[2]: *** [agetty.o] Error 1
Samuel
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 2810 bytes --]
Hurd build fixes
Make blkdev_is_misaligned return 0 when BLKALIGNOFF is not available.
Make procutils.c include c.h to get a PATH_MAX replacement
Provide agetty.c USE_SYSLOG, DEFAULT_VCTERM and DEFAULT_STERM defaults for Hurd.
Make agetty.c only deal with OFDEL, XCASE and VSWTCH if they are available.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
diff --git a/lib/blkdev.c b/lib/blkdev.c
index fb69e88..5cb6554 100644
--- a/lib/blkdev.c
+++ b/lib/blkdev.c
@@ -210,11 +210,15 @@ blkdev_get_sector_size(int fd, int *sector_size)
*/
int blkdev_is_misaligned(int fd)
{
+#ifdef BLKALIGNOFF
int aligned;
if (ioctl(fd, BLKALIGNOFF, &aligned) < 0)
return 0; /* probably kernel < 2.6.32 */
return aligned;
+#else
+ return 0;
+#endif
}
#ifdef TEST_PROGRAM
diff --git a/lib/procutils.c b/lib/procutils.c
index 6a9ee74..2c9e837 100644
--- a/lib/procutils.c
+++ b/lib/procutils.c
@@ -23,6 +23,7 @@
#include <ctype.h>
#include "procutils.h"
+#include "c.h"
/*
* @pid: process ID for which we want to obtain the threads group
diff --git a/term-utils/agetty.c b/term-utils/agetty.c
index 45624f5..6120a26 100644
--- a/term-utils/agetty.c
+++ b/term-utils/agetty.c
@@ -49,6 +49,14 @@
# ifndef DEFAULT_STERM
# define DEFAULT_STERM "vt102"
# endif
+#elif defined(__GNU__)
+# define USE_SYSLOG
+# ifndef DEFAULT_VCTERM
+# define DEFAULT_VCTERM "hurd"
+# endif
+# ifndef DEFAULT_STERM
+# define DEFAULT_STERM "vt102"
+# endif
#else
# ifndef DEFAULT_VCTERM
# define DEFAULT_VCTERM "vt100"
@@ -1039,15 +1047,21 @@ static void reset_vc(const struct options *op, struct termios *tp)
tp->c_iflag |= (BRKINT | ICRNL | IMAXBEL);
tp->c_iflag &= ~(IGNBRK | INLCR | IGNCR | IXOFF | IUCLC | IXANY | ISTRIP);
tp->c_oflag |= (OPOST | ONLCR | NL0 | CR0 | TAB0 | BS0 | VT0 | FF0);
- tp->c_oflag &= ~(OLCUC | OCRNL | ONOCR | ONLRET | OFILL | OFDEL |\
+ tp->c_oflag &= ~(OLCUC | OCRNL | ONOCR | ONLRET | OFILL | \
NLDLY|CRDLY|TABDLY|BSDLY|VTDLY|FFDLY);
tp->c_lflag |= (ISIG | ICANON | IEXTEN | ECHO|ECHOE|ECHOK|ECHOKE);
- tp->c_lflag &= ~(ECHONL|ECHOCTL|ECHOPRT | NOFLSH | XCASE | TOSTOP);
+ tp->c_lflag &= ~(ECHONL|ECHOCTL|ECHOPRT | NOFLSH | TOSTOP);
if ((op->flags & F_KEEPCFLAGS) == 0) {
tp->c_cflag |= (CREAD | CS8 | HUPCL);
tp->c_cflag &= ~(PARODD | PARENB);
}
+#ifdef OFDEL
+ tp->c_oflag &= ~OFDEL;
+#endif
+#ifdef XCASE
+ tp->c_lflag &= ~XCASE;
+#endif
#ifdef IUTF8
if (op->flags & F_UTF8)
tp->c_iflag |= IUTF8; /* Set UTF-8 input flag */
@@ -1067,7 +1081,7 @@ static void reset_vc(const struct options *op, struct termios *tp)
tp->c_cc[VEOF] = CEOF;
#ifdef VSWTC
tp->c_cc[VSWTC] = _POSIX_VDISABLE;
-#else
+#elif defined(VSWTCH)
tp->c_cc[VSWTCH] = _POSIX_VDISABLE;
#endif
tp->c_cc[VSTART] = CSTART;
^ permalink raw reply related
* Re: [PATCH 2/4] uuid: implement uuid_generate_random_safe
From: Ludwig Nussel @ 2011-06-17 7:37 UTC (permalink / raw)
To: util-linux, Ted Ts'o
In-Reply-To: <20110617021517.GC29725@thunk.org>
Ted Ts'o wrote:
> On Thu, Jun 16, 2011 at 03:59:37PM +0200, Ludwig Nussel wrote:
> > +int uuid_generate_random_safe(uuid_t out)
> > +{
> > + int num = 1;
> > + /* No real reason to use the daemon for random uuid's -- yet */
>
> Note that amongst some distributions, there is a very strong
> resistance against using the uuidd daemon. Partially because it's
> "yet another daemon", partially because any long-running daemon has to
> get extra review/auditing because for potential security problems,
> etc.
Yes, that concerns us too. However I'd rather have uuidd running all
the time, started in a clean environment rather than making it
getuid/setgid. A third option would be to make uuidd startable via
inetd.
> Also please note that there's only *one* user of the uuid library, the
> proprietary SAP R/3 system, that generates enough uuids, and with a
> high enough frequency, where "safety" has ever been an issue. Most of
> the time, people simply aren't generating uuid's at the rate of
> thousands a second.
I can't judge. We got quite some pressure to set the setuid bit on
uuidd by default because 'several customers' demand it. Making the
interface more explicitly require uuidd would defeat arguments that
an application and the admin can't even notice there's a problem.
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH 1/4] uuidgen: fail if uuidd isn't running
From: Ted Ts'o @ 2011-06-17 2:07 UTC (permalink / raw)
To: Ludwig Nussel; +Cc: util-linux
In-Reply-To: <1308232779-21018-1-git-send-email-ludwig.nussel@suse.de>
On Thu, Jun 16, 2011 at 03:59:36PM +0200, Ludwig Nussel wrote:
> time bases uuids are not safe if uuidd is not running.
> Add option --force to generate a uuid in this case nevertheless.
I really wouldn't worry about time-based uuid if you're grabbing them
from uuidgen. Yes, if you're generating thousands of uuid's in
parallel via the C interface, it's possible that you potentially force
a collision. But via the command-line interface of uuidgen?
There are plenty of other things to worry about.
- Ted
^ permalink raw reply
* Re: [PATCH 2/4] uuid: implement uuid_generate_random_safe
From: Ted Ts'o @ 2011-06-17 2:15 UTC (permalink / raw)
To: Ludwig Nussel; +Cc: util-linux
In-Reply-To: <1308232779-21018-2-git-send-email-ludwig.nussel@suse.de>
On Thu, Jun 16, 2011 at 03:59:37PM +0200, Ludwig Nussel wrote:
> +int uuid_generate_random_safe(uuid_t out)
> +{
> + int num = 1;
> + /* No real reason to use the daemon for random uuid's -- yet */
Note that amongst some distributions, there is a very strong
resistance against using the uuidd daemon. Partially because it's
"yet another daemon", partially because any long-running daemon has to
get extra review/auditing because for potential security problems,
etc.
Also please note that there's only *one* user of the uuid library, the
proprietary SAP R/3 system, that generates enough uuids, and with a
high enough frequency, where "safety" has ever been an issue. Most of
the time, people simply aren't generating uuid's at the rate of
thousands a second. So I'm really not convinced it's a good idea to
assume that the uuidd daemon will *always* be installed, let alone be
running, and the wholesale deprecation of the existing interfaces
(which are compatible with interfaces used by a number of other
operating systems, BTW), just because there is this idea that the
exsting interfaces are "unsafe". Really, they're not.
- Ted
^ permalink raw reply
* [PATCH] lscpu: detect VMware hypervisor
From: Stephen Hemminger @ 2011-06-16 20:54 UTC (permalink / raw)
To: util-linux
Add detection of VMware.
Tested on VMware Workstation 7.1.4
---
sys-utils/lscpu.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/sys-utils/lscpu.c b/sys-utils/lscpu.c
index 0d94883..8edf997 100644
--- a/sys-utils/lscpu.c
+++ b/sys-utils/lscpu.c
@@ -66,13 +66,15 @@ enum {
HYPER_NONE = 0,
HYPER_XEN,
HYPER_KVM,
- HYPER_MSHV
+ HYPER_MSHV,
+ HYPER_VMWARE
};
const char *hv_vendors[] = {
[HYPER_NONE] = NULL,
[HYPER_XEN] = "Xen",
[HYPER_KVM] = "KVM",
- [HYPER_MSHV] = "Microsoft"
+ [HYPER_MSHV] = "Microsoft",
+ [HYPER_VMWARE] = "VMware"
};
/* CPU modes */
@@ -511,6 +513,8 @@ read_hypervisor_cpuid(struct lscpu_desc *desc)
desc->hyper = HYPER_KVM;
else if (!strncmp("Microsoft Hv", hyper_vendor_id, 12))
desc->hyper = HYPER_MSHV;
+ else if (!strncmp("VMwareVMware", hyper_vendor_id, 12))
+ desc->hyper = HYPER_VMWARE;
}
#else /* ! __x86_64__ */
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH 2/4] uuid: implement uuid_generate_random_safe
From: Karel Zak @ 2011-06-16 15:54 UTC (permalink / raw)
To: Ludwig Nussel; +Cc: util-linux
In-Reply-To: <1308232779-21018-2-git-send-email-ludwig.nussel@suse.de>
On Thu, Jun 16, 2011 at 03:59:37PM +0200, Ludwig Nussel wrote:
> uuid_generate_random_safe() cannot really fail but it may use a weak
> random number generator as fallback.
> ---
> libuuid/src/gen_uuid.c | 32 +++++++++++++++++++++++++++++---
> libuuid/src/uuid.h | 4 +++-
> libuuid/src/uuid.sym | 2 ++
> misc-utils/uuidgen.c | 10 ++++++++--
> 4 files changed, 42 insertions(+), 6 deletions(-)
>
> diff --git a/libuuid/src/gen_uuid.c b/libuuid/src/gen_uuid.c
> index f4c8997..0c81a5c 100644
> --- a/libuuid/src/gen_uuid.c
> +++ b/libuuid/src/gen_uuid.c
> @@ -693,6 +693,18 @@ void uuid_generate_random(uuid_t out)
> __uuid_generate_random(out, &num);
> }
>
> +int uuid_generate_random_safe(uuid_t out)
> +{
> + int num = 1;
> + /* No real reason to use the daemon for random uuid's -- yet */
> +
> + if (get_random_fd() < 0)
> + return -1;
> +
> + __uuid_generate_random(out, &num);
> + return 0;
> +}
> +
It would be nice to use the same concept for the *_random functions as
we already use for the *_time functions. It means to rename
__uuid_generate_random() to uuid_generate_random_generic().
> /*
> * This is the generic front-end to uuid_generate_random and
> @@ -700,10 +712,24 @@ void uuid_generate_random(uuid_t out)
> * /dev/urandom is available, since otherwise we won't have
> * high-quality randomness.
> */
> -void uuid_generate(uuid_t out)
> +static int _uuid_generate(uuid_t out)
rename to: static int uuid_generate_genetic()
> +void uuid_generate(uuid_t out)
> +{
> + (void)_uuid_generate(out);
Don't use "(void)" in the code :-) It's unnecessary.
> +int uuid_generate_time_safe(uuid_t out) __attribute__((warn_unused_result));
> +int uuid_generate_random_safe(uuid_t out) __attribute__((warn_unused_result));
> +int uuid_generate_safe(uuid_t out) __attribute__((warn_unused_result));
Good idea, but is warn_unused_result supported in old gcc versions?
See include/c.h where we have __GNUC_PREREQ stuff.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox