Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
On Tue, Jan 29, 2008 at 03:59:44PM +0100, Markus Rechberger wrote:
(quote reformatted)
> On Mon, Jan 28, 2008 at 10:44:15PM -0800, Greg KH wrote:
> > On Tue, Jan 29, 2008 at 12:32:44AM -0600, Michael E Brown wrote:
> > > BIOS updates are broken on all Dell systems due to Commit
> > > 109f0e93b6b728f03c1eb4af02bc25d71b646c59, which is now in 2.6.24.
> > >
> > > static inline void fw_setup_device_id(struct device *f_dev, struct
> > > device *dev)
> > > {
> > > - /* XXX warning we should watch out for name collisions */
> > > - strlcpy(f_dev->bus_id, dev->bus_id, BUS_ID_SIZE);
> > > + snprintf(f_dev->bus_id, BUS_ID_SIZE, "firmware-%s",
> > > dev->bus_id);
> > > }
> > >
> > > Two programs are broken by this change:
> > > 1) dellBiosUpdate, which is part of libsmbios
> > > 2) All of the Dell Update Packages (DUPs) that are part of Dell
> > > OpenManage: each BIOS release for each of 3-4 dozen platforms.
> > >
> > > These programs are broken due to the pathname change from
> > > /sys/class/firmware/dell_rbu/ to
> > > /sys/class/firmware/firmware-dell_rbu/loading.
> > >
> > > Realistically, I can fix libsmbios in a couple of weeks, but there is no
> > > way that we can go back and fix a couple hundred DUP packages for this
> > > change. If this stays, we are looking at over 6 months before we have an
> > > officially-available Dell OpenManage that can deal with it, and that
> > > would be for new BIOS releases only, I suspect.
> > >
> > > Some of the relevant threads from when this was submitted and accepted:
> > > http://lkml.org/lkml/2005/5/23/73
> > > http://lkml.org/lkml/2005/5/23/62
> > >
> > > Due to the extremely large and disruptive nature of this bug, it would
> > > be nice to get a 2.6.24.1 with this patch reverted.
> > >
> > > I have copied the relevant developers at Dell who maintain this driver.
> > > Please preserve the cc: list when replying.
> >
> > Fair enough, I have no problem reverting this.
> >
> > Anyone want to keep it in?
>
> Hi Greg,
>
> reverting this breaks support for several media (DVB/V4L) devices. I
> would have to look up some bugreports the same name collision happened
> with several different drivers.
> There was a comment in the fw code to watch out for name collisions
> earlier already, so it needs a fix somewhere.
>
> Here's some history:
> http://mcentral.de/wiki/index.php5/Bugtracker#i2c_dev_problem
What about creating symlinks with the old device names? That shouldn't give
rise to any collisions, as it only works in the /sys/class/firmware/ namespace
(correct me if I'm wrong, I haven't actually taken the time to investigate the
problem properly and have no experience with the firmware driver).
I've created the simple patch below. I have no idea if it actually works,
though, as I don't appear to have any hardware for which a linux driver
supports firmware loading. Please comment.
Oh, and I almost forgot to ask about __FUNCTION__, which is gcc-specific;
wouldn't it be a good idea to simply replace all occurrences in the kernel
source with __func__?
Sytse
---
drivers/base/Kconfig | 11 +++
drivers/base/firmware_class.c |7 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index d7da109..d0a9cf6 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -34,6 +34,17 @@ config FW_LOADER
require userspace firmware loading support, but a module built outside
the kernel tree does.
+config FW_LOADER_SYSFS_COMPAT
+ bool "Deprecated /sys/class/firmware/ folders"
+ depends on FW_LOADER
+ default y
+ help
+ Folders in /sys/class/firmware/ have been prefixed with 'firmware-'
+ to prevent name collisions. Enable this option to create symlinks
+ for backward compatibility.
+
+ If unsure, say Y.
+
config DEBUG_DRIVER
bool "Driver Core verbose debug messages"
depends on DEBUG_KERNEL
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 0295855..f8aba6c 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -330,6 +330,13 @@ static int fw_register_device(struct device **dev_p, const
char *fw_name,
__FUNCTION__);
goto error_kfree;
}
+
+#ifdef CONFIG_FW_LOADER_SYSFS_COMPAT
+ if (sysfs_create_link(_class.subsys.kobj, _dev->kobj,
device->bus_id))
+ printk(KERN_WARNING "%s: sysfs_create_link failed for %s\n",
+ __FUNCTION__, device->bus_id);
+#endif
+
*dev_p = f_dev;
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
On Tue, Jan 29, 2008 at 03:59:44PM +0100, Markus Rechberger wrote:
(quote reformatted)
On Mon, Jan 28, 2008 at 10:44:15PM -0800, Greg KH wrote:
On Tue, Jan 29, 2008 at 12:32:44AM -0600, Michael E Brown wrote:
BIOS updates are broken on all Dell systems due to Commit
109f0e93b6b728f03c1eb4af02bc25d71b646c59, which is now in 2.6.24.
static inline void fw_setup_device_id(struct device *f_dev, struct
device *dev)
{
- /* XXX warning we should watch out for name collisions */
- strlcpy(f_dev-bus_id, dev-bus_id, BUS_ID_SIZE);
+ snprintf(f_dev-bus_id, BUS_ID_SIZE, firmware-%s,
dev-bus_id);
}
Two programs are broken by this change:
1) dellBiosUpdate, which is part of libsmbios
2) All of the Dell Update Packages (DUPs) that are part of Dell
OpenManage: each BIOS release for each of 3-4 dozen platforms.
These programs are broken due to the pathname change from
/sys/class/firmware/dell_rbu/ to
/sys/class/firmware/firmware-dell_rbu/loading.
Realistically, I can fix libsmbios in a couple of weeks, but there is no
way that we can go back and fix a couple hundred DUP packages for this
change. If this stays, we are looking at over 6 months before we have an
officially-available Dell OpenManage that can deal with it, and that
would be for new BIOS releases only, I suspect.
Some of the relevant threads from when this was submitted and accepted:
http://lkml.org/lkml/2005/5/23/73
http://lkml.org/lkml/2005/5/23/62
Due to the extremely large and disruptive nature of this bug, it would
be nice to get a 2.6.24.1 with this patch reverted.
I have copied the relevant developers at Dell who maintain this driver.
Please preserve the cc: list when replying.
Fair enough, I have no problem reverting this.
Anyone want to keep it in?
Hi Greg,
reverting this breaks support for several media (DVB/V4L) devices. I
would have to look up some bugreports the same name collision happened
with several different drivers.
There was a comment in the fw code to watch out for name collisions
earlier already, so it needs a fix somewhere.
Here's some history:
http://mcentral.de/wiki/index.php5/Bugtracker#i2c_dev_problem
What about creating symlinks with the old device names? That shouldn't give
rise to any collisions, as it only works in the /sys/class/firmware/ namespace
(correct me if I'm wrong, I haven't actually taken the time to investigate the
problem properly and have no experience with the firmware driver).
I've created the simple patch below. I have no idea if it actually works,
though, as I don't appear to have any hardware for which a linux driver
supports firmware loading. Please comment.
Oh, and I almost forgot to ask about __FUNCTION__, which is gcc-specific;
wouldn't it be a good idea to simply replace all occurrences in the kernel
source with __func__?
Sytse
---
drivers/base/Kconfig | 11 +++
drivers/base/firmware_class.c |7 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index d7da109..d0a9cf6 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -34,6 +34,17 @@ config FW_LOADER
require userspace firmware loading support, but a module built outside
the kernel tree does.
+config FW_LOADER_SYSFS_COMPAT
+ bool Deprecated /sys/class/firmware/ folders
+ depends on FW_LOADER
+ default y
+ help
+ Folders in /sys/class/firmware/ have been prefixed with 'firmware-'
+ to prevent name collisions. Enable this option to create symlinks
+ for backward compatibility.
+
+ If unsure, say Y.
+
config DEBUG_DRIVER
bool Driver Core verbose debug messages
depends on DEBUG_KERNEL
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 0295855..f8aba6c 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -330,6 +330,13 @@ static int fw_register_device(struct device **dev_p, const
char *fw_name,
__FUNCTION__);
goto error_kfree;
}
+
+#ifdef CONFIG_FW_LOADER_SYSFS_COMPAT
+ if (sysfs_create_link(firmware_class.subsys.kobj, f_dev-kobj,
device-bus_id))
+ printk(KERN_WARNING %s: sysfs_create_link failed for %s\n,
+ __FUNCTION__, device-bus_id);
+#endif
+
*dev_p = f_dev;
return 0;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc2-mm1: fuse patch needs new libs
On Thu, Jan 27, 2005 at 10:45:09AM -0500, Bill Davidsen wrote:
> Sytse Wielinga wrote:
> >It is great that this is fixed, don't remove it, but it does require the fuse
> >libs to be updated at the same time, or opening dirs for listings will break
> >like this:
> >
> >open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOSYS (Function
> >not implemented)
> >
> >As I personally like for my ls to keep on working, and I assume others will,
> >too, I would appreciate it if you could add a warning to your announcements
> >the
> >following one or two weeks or so, so that people can remove this patch if
> >they
> >don't want to update their libs.
>
> By any chance would this also break perl programs which readdir?
Of course; I haven't tested it, but the actual ioctls aren't working anymore,
so it's not even _possible_ to get them to work with this patch and an old
version of the fuse libs, even with perl bindings, which go through the fuse
libs anyway.
Sytse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc2-mm1: fuse patch needs new libs
On Thu, Jan 27, 2005 at 10:45:09AM -0500, Bill Davidsen wrote: Sytse Wielinga wrote: It is great that this is fixed, don't remove it, but it does require the fuse libs to be updated at the same time, or opening dirs for listings will break like this: open(., O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOSYS (Function not implemented) As I personally like for my ls to keep on working, and I assume others will, too, I would appreciate it if you could add a warning to your announcements the following one or two weeks or so, so that people can remove this patch if they don't want to update their libs. By any chance would this also break perl programs which readdir? Of course; I haven't tested it, but the actual ioctls aren't working anymore, so it's not even _possible_ to get them to work with this patch and an old version of the fuse libs, even with perl bindings, which go through the fuse libs anyway. Sytse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: don't let mmap allocate down to zero
On Wed, Jan 26, 2005 at 11:38:15AM -0500, linux-os wrote: > On Wed, 26 Jan 2005, Rik van Riel wrote: > > >With some programs the 2.6 kernel can end up allocating memory > >at address zero, for a non-MAP_FIXED mmap call! This causes > >problems with some programs and is generally rude to do. This > >simple patch fixes the problem in my tests. > > Does this mean that we can't mmap the screen regen buffer at > 0x000b8000 anymore? If you would have looked inside mmap.c, you would have seen that his check is executed *after* trying for a specific address if it was given. Mmapping 0x000b8000 should still work. I don't know if this patch was very clean (it probably isn't) but what it's supposed to do is only fail if no specific address has been given to it. > How do I look at the real-mode interrupt table starting at > offset 0? You know that the return value of mmap is to be > checked for MAP_FAILED, not for NULL, don't you? > > What 'C' standard do you refer to? Seg-faults on null pointers > have nothing to do with the 'C' standard and everything to > do with the platform. Oh come on. Every normal program checks whether a variable has been allocated or not by comparing it to NULL. I have no knowledge of the internals of glibc though, and wouldn't know whether this should be handled inside the kernel or if having it checked in glibc and userspace programs that use mmap directly should be enough, but AFAIK every C coder assumes that NULL pointers point to nothing. Sytse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: thoughts on kernel security issues
On Wed, Jan 26, 2005 at 02:31:00PM -0500, John Richard Moser wrote:
> Sytse Wielinga wrote:
> > On Tue, Jan 25, 2005 at 03:03:04PM -0500, John Richard Moser wrote:
> >[...]
> >>true. Very very true.
> >>
> >>With things like Gr, there's like a million features. Normally the
> >>first step I take is "Disable it all". If it still breaks, THEN THERE'S
> >>A PROBLEM. If it works, then the binary searching begins.
> >
> >
> > So how do you think you would do a binary search within big patches, if it
> > would take you 10,000 man-hours to split up the patch? Disabling a lot of
> > small patches is easy, disabling a part of a big one takes a lot more work.
>
> 'make menuconfig' is not a lot more work wtf
>
>
> [*] Grsecurity
> Security Level (Custom) --->
> Address Space Protection --->
> Role Based Access Control Options --->
> Filesystem Protections --->
> Kernel Auditing --->
> Executable Protections --->
> Network Protections --->
> Sysctl support --->
> Logging Options --->
>
> ?? Address Space Protection ??
> [ ] Deny writing to /dev/kmem, /dev/mem, and /dev/port
> [ ] Disable privileged I/O
> [*] Remove addresses from /proc//[maps|stat]
> [*] Deter exploit bruteforcing
> [*] Hide kernel symbols
>
> Need I continue? There's some 30 or 40 more options I could show. If
> you can't use your enter, left, right, up, y, n, and ? keys, you're
> crippled and won't be able to patch and unpatch crap either.
Granted, in some patches you can disable certain features by turning off config
options. Even though it's much less convenient and you might miss out on some
parts because bugs may be introduced that aren't disabled by any option and
even if you find the option that triggers the bug, you still may have lots of
code to check because the option enables a large piece of code, and will have
to work with the entire patch instead of just a small one, in the case of a
well-written patch it's mostly very inconvenient. It still is a good habit to
split out the work you do into small parts though.
> >>>Which is why lots of small patches usually have _different_ bug behaviour
> >>>than the patch they fix. To go back to the A+B fix: the bug they fix may
> >>>be fixed only by the _combination_ of the patch, but the bug they cause is
> >>>often an artifact of _one_ of the patches.
> >>>
> >>
> >>Wasn't talking about bugfixes, see above.
> >
> >
> > Oh, so you're saying that security fixes don't cause bugs? Great world you
> > live
> > in, then...
> >
>
> I didn't say that. I said I wasn't talking about bugfix patches. I
> wasn't talking about "mremap(0,0) gives you root," I was talking about
> "preventing following links under X conditions breaks nothing legitimate
> but deadstops /tmp races" or "properly setting CPU protections for
> PROT_EXEC stops code injection" or "ASLR stops ret2libc attacks."
>
> If you people ever bothered to read what I say, you wouldn't continually
> say stupid shit like You get milk from cows wtf idiot
> chocolate milk doens't come from chocolate cows
I'm sorry about the rant. Besides, your comment ('Wasn't talking about
bugfixes') makes some sense, too. You were actually talking about two patches
though, which close two closely related holes. Linus was talking about the
possible bugs caused by either one of these two patches, which may be totally
unrelated to the thing they try to fix.
Sytse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: thoughts on kernel security issues
On Wed, Jan 26, 2005 at 03:39:08PM -0500, John Richard Moser wrote:
> > I'm sorry about the rant. Besides, your comment ('Wasn't talking about
> > bugfixes') makes some sense, too. You were actually talking about two
> > patches
> > though, which close two closely related holes. Linus was talking about the
> > possible bugs caused by either one of these two patches, which may be
> > totally
> > unrelated to the thing they try to fix.
> Sorry, I just woke up, this thread has me under a lot of stress. I
> should go back to arguing things that have some end goal to them, rather
> than arguing simply because I have nothing better to do.
Yes.. it seems that the thread has gone in a rather pointless direction, noone
seems to know exactly what it was about anymore but everyone keeps carrying
huge emotions all over the place. Let's just forget it and move on :-)
Sytse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: thoughts on kernel security issues
On Tue, Jan 25, 2005 at 03:03:04PM -0500, John Richard Moser wrote:
> That being said, you should also consider (unless somebody forgot to
> tell me something) that it takes two source trees to make a split-out
> patch. The author also has to chew down everything but the feature he
> wants to split out. I could probably log 10,000 man-hours splitting up
> GrSecurity. :)
I'd try out Andrew's patch scripts if I were you. If you're making a patch to
the kernel, you'd best keep it in separate patches from the beginning, and
that's exactly what those scripts are very useful for.
> > It's also a lot easier to find the (inevitable) bugs. Either you already
> > have a clue ("try reverting that one patch") or you can do things like
> > binary searching. The bugs introduced a patch often have very little to do
> > with the thing a patch fixes - exactly because the patch _fixes_
> > something, it's been tested with that particular problem, and the new
> > problem it introduces is usually orthogonal.
>
> true. Very very true.
>
> With things like Gr, there's like a million features. Normally the
> first step I take is "Disable it all". If it still breaks, THEN THERE'S
> A PROBLEM. If it works, then the binary searching begins.
So how do you think you would do a binary search within big patches, if it
would take you 10,000 man-hours to split up the patch? Disabling a lot of
small patches is easy, disabling a part of a big one takes a lot more work.
> > Which is why lots of small patches usually have _different_ bug behaviour
> > than the patch they fix. To go back to the A+B fix: the bug they fix may
> > be fixed only by the _combination_ of the patch, but the bug they cause is
> > often an artifact of _one_ of the patches.
> >
>
> Wasn't talking about bugfixes, see above.
Oh, so you're saying that security fixes don't cause bugs? Great world you live
in, then...
> > IOW, splitting the patches up makes them
> > - easier to merge
> > - easier to verify
> > - easier to debug
> >
> > and combining them has _zero_ advantages (whatever bug the combined patch
> > fix _will_ be fixed by the series of individual patches too - even if the
> > splitting was buggy in some respect, you are pretty much guaranteed of
> > this, since the bug you were trying to fix is the _one_ thing you are
> > really testing for).
>
> Lots of work to split up a patch though.
See above.
Sytse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/29] x86-i8259-shutdown
On Wed, Jan 26, 2005 at 07:06:50AM -0700, Eric W. Biederman wrote: > Sytse Wielinga <[EMAIL PROTECTED]> writes: > > > On my box this patch breaks shutdown instead, while it was working without > > it > > on -rc2-mm1. > > > > I have an Asus A7V8X motherboard with a VIA VT8377 (KT400) north bridge and > > a > > VT8235 south bridge (according to lspci). The IO-APIC is used for interrupt > > routing. > > Hmm. The patch had a couple of hard coded assumptions about the > configuration (using ACPI etc), but I don't think it was significant > enough to break anything. You have a UP board and a K7 processor > so my removal of set_cpus_allowed that should not affect anything. > > But you are using an SMP kernel or at least the apic support. Yes, I have only one processor but I am using the IO-APIC. > Are you using ACPI poweroff? Yes. > How does the kernel shutdown fail? It halts after saying 'acpi_power_off called'. Strangely, it only breaks when using the Alt-SysRq-O poweroff function. Shutting down normally still powers off the system (and does print 'acpi_power_off called'). I think it must have something to do with the IDE devices not having powered down before acpi_power_off is called, but I haven't seen the code so I have no idea what really causes it to break. Sytse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2] I2C: lm80 driver improvement (From Aurelien)
On Wed, Jan 26, 2005 at 03:05:09PM +0100, I wrote: > BTW, can anyone tell me why the uints in this parameter list are declared as > 'unsigned' and not as 'unsigned int'? $ find /usr/src/linux/ -name \*.c |xargs grep unsigned\ [^icsl] |wc -l 3151 - Gives himself a good smack on the head - Sorry about that. I suppose it's just used a lot as a shorthand for 'unsigned int', which is used a lot more in the kernel (the above command finds 22656 occurrences). On a sidenote, however, wouldn't it be nice for things like this to be consistent throughout the kernel? Don't think I have an opinion on this, because I don't, but I'd like to see those of the ones who do. Sytse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2] I2C: lm80 driver improvement (From Aurelien)
On Wed, Jan 26, 2005 at 02:49:23AM -0500, Shawn Starr wrote:
> static inline unsigned char FAN_TO_REG(unsigned rpm, unsigned div)
> {
> - if (rpm == 0)
> + if (rpm <= 0)
The rpm parameter is unsigned so this change is useless. The rest makes sense
to me.
BTW, can anyone tell me why the uints in this parameter list are declared as
'unsigned' and not as 'unsigned int'?
Sytse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/29] x86-i8259-shutdown
On Tue, Jan 25, 2005 at 03:12:00PM -0700, Eric W. Biederman wrote:
> "Barry K. Nathan" <[EMAIL PROTECTED]> writes:
>
> > On Tue, Jan 25, 2005 at 05:12:43AM -0700, Eric W. Biederman wrote:
> > > Could you try this patch on your system with acpi that
> > > is having problems.
> > >
> > > The patch needs some work before it goes into a mainline kernel
> > > as I have hacked the call to acpi_power_off_prepare into roughly
> > > the proper position in the call chain instead of use a proper
> > > hook. But I can't quickly find an existing hook in the proper
> > > location.
> >
> > I had to fix a couple of typos ("apci" and "offf") to get it to compile.
> > Once I did that, the patch made shutdown work again.
>
> Thanks. Now I just need to come up with the good version unless one of
> the acpi guys wants to volunteer.
On my box this patch breaks shutdown instead, while it was working without it
on -rc2-mm1.
I have an Asus A7V8X motherboard with a VIA VT8377 (KT400) north bridge and a
VT8235 south bridge (according to lspci). The IO-APIC is used for interrupt
routing.
Sytse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/29] x86-i8259-shutdown
On Tue, Jan 25, 2005 at 03:12:00PM -0700, Eric W. Biederman wrote: Barry K. Nathan [EMAIL PROTECTED] writes: On Tue, Jan 25, 2005 at 05:12:43AM -0700, Eric W. Biederman wrote: Could you try this patch on your system with acpi that is having problems. The patch needs some work before it goes into a mainline kernel as I have hacked the call to acpi_power_off_prepare into roughly the proper position in the call chain instead of use a proper hook. But I can't quickly find an existing hook in the proper location. I had to fix a couple of typos (apci and offf) to get it to compile. Once I did that, the patch made shutdown work again. Thanks. Now I just need to come up with the good version unless one of the acpi guys wants to volunteer. On my box this patch breaks shutdown instead, while it was working without it on -rc2-mm1. I have an Asus A7V8X motherboard with a VIA VT8377 (KT400) north bridge and a VT8235 south bridge (according to lspci). The IO-APIC is used for interrupt routing. Sytse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2] I2C: lm80 driver improvement (From Aurelien)
On Wed, Jan 26, 2005 at 02:49:23AM -0500, Shawn Starr wrote:
static inline unsigned char FAN_TO_REG(unsigned rpm, unsigned div)
{
- if (rpm == 0)
+ if (rpm = 0)
The rpm parameter is unsigned so this change is useless. The rest makes sense
to me.
BTW, can anyone tell me why the uints in this parameter list are declared as
'unsigned' and not as 'unsigned int'?
Sytse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2] I2C: lm80 driver improvement (From Aurelien)
On Wed, Jan 26, 2005 at 03:05:09PM +0100, I wrote: BTW, can anyone tell me why the uints in this parameter list are declared as 'unsigned' and not as 'unsigned int'? $ find /usr/src/linux/ -name \*.c |xargs grep unsigned\ [^icsl] |wc -l 3151 - Gives himself a good smack on the head - Sorry about that. I suppose it's just used a lot as a shorthand for 'unsigned int', which is used a lot more in the kernel (the above command finds 22656 occurrences). On a sidenote, however, wouldn't it be nice for things like this to be consistent throughout the kernel? Don't think I have an opinion on this, because I don't, but I'd like to see those of the ones who do. Sytse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/29] x86-i8259-shutdown
On Wed, Jan 26, 2005 at 07:06:50AM -0700, Eric W. Biederman wrote: Sytse Wielinga [EMAIL PROTECTED] writes: On my box this patch breaks shutdown instead, while it was working without it on -rc2-mm1. I have an Asus A7V8X motherboard with a VIA VT8377 (KT400) north bridge and a VT8235 south bridge (according to lspci). The IO-APIC is used for interrupt routing. Hmm. The patch had a couple of hard coded assumptions about the configuration (using ACPI etc), but I don't think it was significant enough to break anything. You have a UP board and a K7 processor so my removal of set_cpus_allowed that should not affect anything. But you are using an SMP kernel or at least the apic support. Yes, I have only one processor but I am using the IO-APIC. Are you using ACPI poweroff? Yes. How does the kernel shutdown fail? It halts after saying 'acpi_power_off called'. Strangely, it only breaks when using the Alt-SysRq-O poweroff function. Shutting down normally still powers off the system (and does print 'acpi_power_off called'). I think it must have something to do with the IDE devices not having powered down before acpi_power_off is called, but I haven't seen the code so I have no idea what really causes it to break. Sytse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: thoughts on kernel security issues
On Tue, Jan 25, 2005 at 03:03:04PM -0500, John Richard Moser wrote: That being said, you should also consider (unless somebody forgot to tell me something) that it takes two source trees to make a split-out patch. The author also has to chew down everything but the feature he wants to split out. I could probably log 10,000 man-hours splitting up GrSecurity. :) I'd try out Andrew's patch scripts if I were you. If you're making a patch to the kernel, you'd best keep it in separate patches from the beginning, and that's exactly what those scripts are very useful for. It's also a lot easier to find the (inevitable) bugs. Either you already have a clue (try reverting that one patch) or you can do things like binary searching. The bugs introduced a patch often have very little to do with the thing a patch fixes - exactly because the patch _fixes_ something, it's been tested with that particular problem, and the new problem it introduces is usually orthogonal. true. Very very true. With things like Gr, there's like a million features. Normally the first step I take is Disable it all. If it still breaks, THEN THERE'S A PROBLEM. If it works, then the binary searching begins. So how do you think you would do a binary search within big patches, if it would take you 10,000 man-hours to split up the patch? Disabling a lot of small patches is easy, disabling a part of a big one takes a lot more work. Which is why lots of small patches usually have _different_ bug behaviour than the patch they fix. To go back to the A+B fix: the bug they fix may be fixed only by the _combination_ of the patch, but the bug they cause is often an artifact of _one_ of the patches. Wasn't talking about bugfixes, see above. Oh, so you're saying that security fixes don't cause bugs? Great world you live in, then... IOW, splitting the patches up makes them - easier to merge - easier to verify - easier to debug and combining them has _zero_ advantages (whatever bug the combined patch fix _will_ be fixed by the series of individual patches too - even if the splitting was buggy in some respect, you are pretty much guaranteed of this, since the bug you were trying to fix is the _one_ thing you are really testing for). Lots of work to split up a patch though. See above. Sytse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: thoughts on kernel security issues
On Wed, Jan 26, 2005 at 03:39:08PM -0500, John Richard Moser wrote:
I'm sorry about the rant. Besides, your comment ('Wasn't talking about
bugfixes') makes some sense, too. You were actually talking about two
patches
though, which close two closely related holes. Linus was talking about the
possible bugs caused by either one of these two patches, which may be
totally
unrelated to the thing they try to fix.
Sorry, I just woke up, this thread has me under a lot of stress. I
should go back to arguing things that have some end goal to them, rather
than arguing simply because I have nothing better to do.
Yes.. it seems that the thread has gone in a rather pointless direction, noone
seems to know exactly what it was about anymore but everyone keeps carrying
huge emotions all over the place. Let's just forget it and move on :-)
Sytse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: thoughts on kernel security issues
On Wed, Jan 26, 2005 at 02:31:00PM -0500, John Richard Moser wrote:
Sytse Wielinga wrote:
On Tue, Jan 25, 2005 at 03:03:04PM -0500, John Richard Moser wrote:
[...]
true. Very very true.
With things like Gr, there's like a million features. Normally the
first step I take is Disable it all. If it still breaks, THEN THERE'S
A PROBLEM. If it works, then the binary searching begins.
So how do you think you would do a binary search within big patches, if it
would take you 10,000 man-hours to split up the patch? Disabling a lot of
small patches is easy, disabling a part of a big one takes a lot more work.
'make menuconfig' is not a lot more work wtf
[*] Grsecurity
Security Level (Custom) ---
Address Space Protection ---
Role Based Access Control Options ---
Filesystem Protections ---
Kernel Auditing ---
Executable Protections ---
Network Protections ---
Sysctl support ---
Logging Options ---
?? Address Space Protection ??
[ ] Deny writing to /dev/kmem, /dev/mem, and /dev/port
[ ] Disable privileged I/O
[*] Remove addresses from /proc/pid/[maps|stat]
[*] Deter exploit bruteforcing
[*] Hide kernel symbols
Need I continue? There's some 30 or 40 more options I could show. If
you can't use your enter, left, right, up, y, n, and ? keys, you're
crippled and won't be able to patch and unpatch crap either.
Granted, in some patches you can disable certain features by turning off config
options. Even though it's much less convenient and you might miss out on some
parts because bugs may be introduced that aren't disabled by any option and
even if you find the option that triggers the bug, you still may have lots of
code to check because the option enables a large piece of code, and will have
to work with the entire patch instead of just a small one, in the case of a
well-written patch it's mostly very inconvenient. It still is a good habit to
split out the work you do into small parts though.
Which is why lots of small patches usually have _different_ bug behaviour
than the patch they fix. To go back to the A+B fix: the bug they fix may
be fixed only by the _combination_ of the patch, but the bug they cause is
often an artifact of _one_ of the patches.
Wasn't talking about bugfixes, see above.
Oh, so you're saying that security fixes don't cause bugs? Great world you
live
in, then...
I didn't say that. I said I wasn't talking about bugfix patches. I
wasn't talking about mremap(0,0) gives you root, I was talking about
preventing following links under X conditions breaks nothing legitimate
but deadstops /tmp races or properly setting CPU protections for
PROT_EXEC stops code injection or ASLR stops ret2libc attacks.
If you people ever bothered to read what I say, you wouldn't continually
say stupid shit like me You get milk from cows you wtf idiot
chocolate milk doens't come from chocolate cows
I'm sorry about the rant. Besides, your comment ('Wasn't talking about
bugfixes') makes some sense, too. You were actually talking about two patches
though, which close two closely related holes. Linus was talking about the
possible bugs caused by either one of these two patches, which may be totally
unrelated to the thing they try to fix.
Sytse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: don't let mmap allocate down to zero
On Wed, Jan 26, 2005 at 11:38:15AM -0500, linux-os wrote: On Wed, 26 Jan 2005, Rik van Riel wrote: With some programs the 2.6 kernel can end up allocating memory at address zero, for a non-MAP_FIXED mmap call! This causes problems with some programs and is generally rude to do. This simple patch fixes the problem in my tests. Does this mean that we can't mmap the screen regen buffer at 0x000b8000 anymore? If you would have looked inside mmap.c, you would have seen that his check is executed *after* trying for a specific address if it was given. Mmapping 0x000b8000 should still work. I don't know if this patch was very clean (it probably isn't) but what it's supposed to do is only fail if no specific address has been given to it. How do I look at the real-mode interrupt table starting at offset 0? You know that the return value of mmap is to be checked for MAP_FAILED, not for NULL, don't you? What 'C' standard do you refer to? Seg-faults on null pointers have nothing to do with the 'C' standard and everything to do with the platform. Oh come on. Every normal program checks whether a variable has been allocated or not by comparing it to NULL. I have no knowledge of the internals of glibc though, and wouldn't know whether this should be handled inside the kernel or if having it checked in glibc and userspace programs that use mmap directly should be enough, but AFAIK every C coder assumes that NULL pointers point to nothing. Sytse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2: vmnet breaks; put skb_copy_datagram b
On Tue, Jan 25, 2005 at 02:46:56AM +0100, Petr Vandrovec wrote: > On 25 Jan 05 at 1:41, Sytse Wielinga wrote: > > Linus, could you please put skb_copy_datagram back in place? It's not used > > anymore in the kernel, but the vmnet module (in vmware) still uses this > > interface to skb_copy_datagram_iovec. > > There is no reason for doing this. Just grab latest vmmon & vmnet > from http://platan.vc.cvut.cz/ftp/pub/vmware/vmware-any-any-update89.tar.gz, > and enjoy latest and greatest modules. Besides this one you'll get lot > of other fixes and improvements for free ;-) I'm very sorry, you're completely right. That version uses skb_copy_datagram_iovec. I'll file a bug for gentoo instead, that it needs to update from 88 to 89. On the other hand, though, I would think it would be a good idea to leave this function in until after 2.6.11, so that distributions and people have plenty of time to update their vmware. After all, it's not like we'd be missing out on an important fix or something; we're just moving a couple of bytes out of the kernel into vmnet. Sytse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2: vmnet breaks; put skb_copy_datagram b
On Tue, Jan 25, 2005 at 02:46:56AM +0100, Petr Vandrovec wrote: On 25 Jan 05 at 1:41, Sytse Wielinga wrote: Linus, could you please put skb_copy_datagram back in place? It's not used anymore in the kernel, but the vmnet module (in vmware) still uses this interface to skb_copy_datagram_iovec. There is no reason for doing this. Just grab latest vmmon vmnet from http://platan.vc.cvut.cz/ftp/pub/vmware/vmware-any-any-update89.tar.gz, and enjoy latest and greatest modules. Besides this one you'll get lot of other fixes and improvements for free ;-) I'm very sorry, you're completely right. That version uses skb_copy_datagram_iovec. I'll file a bug for gentoo instead, that it needs to update from 88 to 89. On the other hand, though, I would think it would be a good idea to leave this function in until after 2.6.11, so that distributions and people have plenty of time to update their vmware. After all, it's not like we'd be missing out on an important fix or something; we're just moving a couple of bytes out of the kernel into vmnet. Sytse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2: vmnet breaks; put skb_copy_datagram back in place
Linus, could you please put skb_copy_datagram back in place? It's not used
anymore in the kernel, but the vmnet module (in vmware) still uses this
interface to skb_copy_datagram_iovec.
Patch for 2.6.11-rc2 follows. It compiles cleanly; I have not tested it yet,
but I assume it's okay. I'll test it right after sending this mail and report
back here if something goes wrong.
Sytse
diff -ru a/include/linux/skbuff.h b/include/linux/skbuff.h
--- a/include/linux/skbuff.h2005-01-25 01:27:00.0 +0100
+++ b/include/linux/skbuff.h2005-01-25 01:31:20.0 +0100
@@ -1086,6 +1086,8 @@
int noblock, int *err);
extern unsigned intdatagram_poll(struct file *file, struct socket *sock,
struct poll_table_struct *wait);
+extern intskb_copy_datagram(const struct sk_buff *from,
+int offset, char __user *to, int size);
extern intskb_copy_datagram_iovec(const struct sk_buff *from,
int offset, struct iovec *to,
int size);
diff -ru a/net/core/datagram.c b/net/core/datagram.c
--- a/net/core/datagram.c 2005-01-25 01:27:01.0 +0100
+++ b/net/core/datagram.c 2005-01-25 01:31:20.0 +0100
@@ -199,6 +199,19 @@
kfree_skb(skb);
}
+/*
+ * Copy a datagram to a linear buffer.
+ */
+int skb_copy_datagram(const struct sk_buff *skb, int offset, char __user *to,
int size)
+{
+ struct iovec iov = {
+ .iov_base = to,
+ .iov_len =size,
+ };
+
+ return skb_copy_datagram_iovec(skb, offset, , size);
+}
+
/**
* skb_copy_datagram_iovec - Copy a datagram to an iovec.
* @skb - buffer to copy
@@ -477,6 +490,7 @@
EXPORT_SYMBOL(datagram_poll);
EXPORT_SYMBOL(skb_copy_and_csum_datagram_iovec);
+EXPORT_SYMBOL(skb_copy_datagram);
EXPORT_SYMBOL(skb_copy_datagram_iovec);
EXPORT_SYMBOL(skb_free_datagram);
EXPORT_SYMBOL(skb_recv_datagram);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc2-mm1: fuse patch needs new libs
Hi Andrew,
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> fuse-transfer-readdir-data-through-device.patch
> fuse: transfer readdir data through device
It is great that this is fixed, don't remove it, but it does require the fuse
libs to be updated at the same time, or opening dirs for listings will break
like this:
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOSYS (Function
not implemented)
As I personally like for my ls to keep on working, and I assume others will,
too, I would appreciate it if you could add a warning to your announcements the
following one or two weeks or so, so that people can remove this patch if they
don't want to update their libs.
Thank you.
Sytse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc2-mm1: fuse patch needs new libs
Hi Andrew, On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote: fuse-transfer-readdir-data-through-device.patch fuse: transfer readdir data through device It is great that this is fixed, don't remove it, but it does require the fuse libs to be updated at the same time, or opening dirs for listings will break like this: open(., O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOSYS (Function not implemented) As I personally like for my ls to keep on working, and I assume others will, too, I would appreciate it if you could add a warning to your announcements the following one or two weeks or so, so that people can remove this patch if they don't want to update their libs. Thank you. Sytse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2: vmnet breaks; put skb_copy_datagram back in place
Linus, could you please put skb_copy_datagram back in place? It's not used
anymore in the kernel, but the vmnet module (in vmware) still uses this
interface to skb_copy_datagram_iovec.
Patch for 2.6.11-rc2 follows. It compiles cleanly; I have not tested it yet,
but I assume it's okay. I'll test it right after sending this mail and report
back here if something goes wrong.
Sytse
diff -ru a/include/linux/skbuff.h b/include/linux/skbuff.h
--- a/include/linux/skbuff.h2005-01-25 01:27:00.0 +0100
+++ b/include/linux/skbuff.h2005-01-25 01:31:20.0 +0100
@@ -1086,6 +1086,8 @@
int noblock, int *err);
extern unsigned intdatagram_poll(struct file *file, struct socket *sock,
struct poll_table_struct *wait);
+extern intskb_copy_datagram(const struct sk_buff *from,
+int offset, char __user *to, int size);
extern intskb_copy_datagram_iovec(const struct sk_buff *from,
int offset, struct iovec *to,
int size);
diff -ru a/net/core/datagram.c b/net/core/datagram.c
--- a/net/core/datagram.c 2005-01-25 01:27:01.0 +0100
+++ b/net/core/datagram.c 2005-01-25 01:31:20.0 +0100
@@ -199,6 +199,19 @@
kfree_skb(skb);
}
+/*
+ * Copy a datagram to a linear buffer.
+ */
+int skb_copy_datagram(const struct sk_buff *skb, int offset, char __user *to,
int size)
+{
+ struct iovec iov = {
+ .iov_base = to,
+ .iov_len =size,
+ };
+
+ return skb_copy_datagram_iovec(skb, offset, iov, size);
+}
+
/**
* skb_copy_datagram_iovec - Copy a datagram to an iovec.
* @skb - buffer to copy
@@ -477,6 +490,7 @@
EXPORT_SYMBOL(datagram_poll);
EXPORT_SYMBOL(skb_copy_and_csum_datagram_iovec);
+EXPORT_SYMBOL(skb_copy_datagram);
EXPORT_SYMBOL(skb_copy_datagram_iovec);
EXPORT_SYMBOL(skb_free_datagram);
EXPORT_SYMBOL(skb_recv_datagram);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Announce loop-AES-v3.0b file/swap crypto package
On Mon, Jan 17, 2005 at 08:14:58PM +0100, Fruhwirth Clemens wrote: > http://clemens.endorphin.org/LinuxHDEncSettings I found two typos on your page: - In LinuxHDEncSettings: at the beginning, 'pose a thread', should be 'threat' - In 'cryptography': AFsplitter written as AFspliter. Sytse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce loop-AES-v3.0b file/swap crypto package
On Mon, Jan 17, 2005 at 08:14:58PM +0100, Fruhwirth Clemens wrote: http://clemens.endorphin.org/LinuxHDEncSettings I found two typos on your page: - In LinuxHDEncSettings: at the beginning, 'pose a thread', should be 'threat' - In 'cryptography': AFsplitter written as AFspliter. Sytse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild: Implicit dependence on the C compiler
On Wed, Jan 19, 2005 at 11:35:55AM -0500, linux-os wrote: > >Sam Ravnborg <[EMAIL PROTECTED]> wrote: > >>1) Unconditionally execute make install assuming vmlinux is up-to-date. > >> make modules_install run unconditionally, so this is already know > >> practice > > You must never execute `make install` or `make modules_install` without > the explicit action of the operator! To do so could (will) result > in an un-bootable system. I can't imagine what somebody would be > thinking to propose an automatic install. Whoever proposed this > must have lots of time and little knowledge. They are going to > be reinstalling everything from the distribution CD as a hobby. What I think Sam meant was, to let make install assume that vmlinux is up-to-date, IOW, just to remove the dependency of install on vmlinux. Err, to put it in your words: I can't imagine what somebody would be thinking to think he proposed an automatic install. :-P Sytse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild: Implicit dependence on the C compiler
On Wed, Jan 19, 2005 at 11:35:55AM -0500, linux-os wrote: Sam Ravnborg [EMAIL PROTECTED] wrote: 1) Unconditionally execute make install assuming vmlinux is up-to-date. make modules_install run unconditionally, so this is already know practice You must never execute `make install` or `make modules_install` without the explicit action of the operator! To do so could (will) result in an un-bootable system. I can't imagine what somebody would be thinking to propose an automatic install. Whoever proposed this must have lots of time and little knowledge. They are going to be reinstalling everything from the distribution CD as a hobby. What I think Sam meant was, to let make install assume that vmlinux is up-to-date, IOW, just to remove the dependency of install on vmlinux. Err, to put it in your words: I can't imagine what somebody would be thinking to think he proposed an automatic install. :-P Sytse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4: "access beyond end of device" after ext2 mount
On Tue, Jan 18, 2005 at 04:55:34PM +0100, I wrote: > multiples of the block size. The 2.6 kernel does not have this problem; it > appears to accept partial blocks, and doesn't even appear to calculate the > device size (blockdev --getsz and --getsize return 0 on my machine.) ^^^ Please disregard the second half of that sentence; when I ran blockdev --getsz, I had deleted my loop device already. The device size still reads 20002 sectors in 2.6. This doesn't change anything though, since the last two sectors of the device, or the first two sectors of the last block, are still usable in 2.6 and not in 2.4. Sytse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4: "access beyond end of device" after ext2 mount
On Tue, Jan 18, 2005 at 04:20:06PM +0100, Mario Holbe wrote: > On Tue, Jan 18, 2005 at 03:17:07PM +0100, Sytse Wielinga wrote: > > Why not just use dd if=/dev/xxx `blockdev --getbsz /dev/xxx` ...? > > because it doesn't work, as I've demonstrated in > Message-ID: <[EMAIL PROTECTED]> > > > [EMAIL PROTECTED]:~# dd if=/dev/hdg7 of=/dev/null bs=512 > > attempt to access beyond end of device > > 22:07: rw=0, want=4996184, limit=4996183 > > dd: reading `/dev/hdg7': Input/output error > > 9992360+0 records in > > 9992360+0 records out > > 5116088320 bytes transferred in 92,603241 seconds (55247400 bytes/sec) > > [EMAIL PROTECTED]:~# > > > > Fixing dd's blocksize to 512 doesn't help either. That's not what I said; the block size of /dev/hdg7 there is 4096, not 512. Besides, the blocksize of dd is 512 by default and independent of the blocksize of the device. Anyhow, the block size set for dd doesn't matter as even if the block size is huge dd copies over the last partial block. The problem was that with the 2.4 kernel only whole blocks are usable, but it rounds off the device size to multiples of the sector size (i.e., not; the device size is given in multiples of the sector size, which, by default, is 512) instead of rounding off to multiples of the block size. The 2.6 kernel does not have this problem; it appears to accept partial blocks, and doesn't even appear to calculate the device size (blockdev --getsz and --getsize return 0 on my machine.) I think the fix could be as simple as rounding off the device size in one location, but, as I haven't had a look at the source, I'm not sure, maybe every driver needs a fix. Sytse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4: "access beyond end of device" after ext2 mount
Why not just use dd if=/dev/xxx `blockdev --getbsz /dev/xxx` ...? Sytse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4: access beyond end of device after ext2 mount
Why not just use dd if=/dev/xxx `blockdev --getbsz /dev/xxx` ...? Sytse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4: access beyond end of device after ext2 mount
On Tue, Jan 18, 2005 at 04:20:06PM +0100, Mario Holbe wrote: On Tue, Jan 18, 2005 at 03:17:07PM +0100, Sytse Wielinga wrote: Why not just use dd if=/dev/xxx `blockdev --getbsz /dev/xxx` ...? because it doesn't work, as I've demonstrated in Message-ID: [EMAIL PROTECTED] [EMAIL PROTECTED]:~# dd if=/dev/hdg7 of=/dev/null bs=512 attempt to access beyond end of device 22:07: rw=0, want=4996184, limit=4996183 dd: reading `/dev/hdg7': Input/output error 9992360+0 records in 9992360+0 records out 5116088320 bytes transferred in 92,603241 seconds (55247400 bytes/sec) [EMAIL PROTECTED]:~# Fixing dd's blocksize to 512 doesn't help either. That's not what I said; the block size of /dev/hdg7 there is 4096, not 512. Besides, the blocksize of dd is 512 by default and independent of the blocksize of the device. Anyhow, the block size set for dd doesn't matter as even if the block size is huge dd copies over the last partial block. The problem was that with the 2.4 kernel only whole blocks are usable, but it rounds off the device size to multiples of the sector size (i.e., not; the device size is given in multiples of the sector size, which, by default, is 512) instead of rounding off to multiples of the block size. The 2.6 kernel does not have this problem; it appears to accept partial blocks, and doesn't even appear to calculate the device size (blockdev --getsz and --getsize return 0 on my machine.) I think the fix could be as simple as rounding off the device size in one location, but, as I haven't had a look at the source, I'm not sure, maybe every driver needs a fix. Sytse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4: access beyond end of device after ext2 mount
On Tue, Jan 18, 2005 at 04:55:34PM +0100, I wrote: multiples of the block size. The 2.6 kernel does not have this problem; it appears to accept partial blocks, and doesn't even appear to calculate the device size (blockdev --getsz and --getsize return 0 on my machine.) ^^^ Please disregard the second half of that sentence; when I ran blockdev --getsz, I had deleted my loop device already. The device size still reads 20002 sectors in 2.6. This doesn't change anything though, since the last two sectors of the device, or the first two sectors of the last block, are still usable in 2.6 and not in 2.4. Sytse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/13] FAT: Lindent fs/vfat/namei.c
On Tue, Jan 18, 2005 at 02:49:21AM +0900, OGAWA Hirofumi wrote: > diff -puN fs/vfat/namei.c~fat_lindent-vfat fs/vfat/namei.c > --- linux-2.6.10/fs/vfat/namei.c~fat_lindent-vfat 2005-01-10 > 01:57:31.0 +0900 > +++ linux-2.6.10-hirofumi/fs/vfat/namei.c 2005-01-10 01:57:44.0 > +0900 > @@ -12,7 +12,7 @@ > * Short name translation 1999, 2001 by Wolfram Pienkoss <[EMAIL PROTECTED]> > * > * Support Multibyte character and cleanup by ^^^ Shouldn't that be 'characters'? Yup, that was it.. sorry if I'm nitpicking :-P Sytse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [request for inclusion] Realtime LSM
On Sun, Jan 16, 2005 at 05:57:23PM -0600, Jack O'Quin wrote: > > * Jack O'Quin <[EMAIL PROTECTED]> wrote: > >> According to the manpage, nice(2) is per-process not per-thread. That > >> does not give the granularity we need. > > Ingo Molnar <[EMAIL PROTECTED]> writes: > > the manpage is incorrect - sys_nice() is per-thread. (Btw., you could > > use setpriority() too.) > > OK. Where is this stuff documented? > > BTW, I think this violates POSIX, which states... > > The nice value set with nice() shall be applied to the process. If > the process is multi-threaded, the nice value shall affect all > system scope threads in the process. We are talking about two different things here. POSIX is just about API and has, correct me if I'm wrong, nothing to do with system calls whatsoever. The manpage nice(2) is about the libc library call nice(), which is per-process, which it should be according to POSIX. The system call, called sys_nice() in C, is per-thread. Apparently glibc or some thread library contains some magic to make the translation. Sytse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [request for inclusion] Realtime LSM
On Sun, Jan 16, 2005 at 05:57:23PM -0600, Jack O'Quin wrote: * Jack O'Quin [EMAIL PROTECTED] wrote: According to the manpage, nice(2) is per-process not per-thread. That does not give the granularity we need. Ingo Molnar [EMAIL PROTECTED] writes: the manpage is incorrect - sys_nice() is per-thread. (Btw., you could use setpriority() too.) OK. Where is this stuff documented? BTW, I think this violates POSIX, which states... The nice value set with nice() shall be applied to the process. If the process is multi-threaded, the nice value shall affect all system scope threads in the process. We are talking about two different things here. POSIX is just about API and has, correct me if I'm wrong, nothing to do with system calls whatsoever. The manpage nice(2) is about the libc library call nice(), which is per-process, which it should be according to POSIX. The system call, called sys_nice() in C, is per-thread. Apparently glibc or some thread library contains some magic to make the translation. Sytse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/13] FAT: Lindent fs/vfat/namei.c
On Tue, Jan 18, 2005 at 02:49:21AM +0900, OGAWA Hirofumi wrote: diff -puN fs/vfat/namei.c~fat_lindent-vfat fs/vfat/namei.c --- linux-2.6.10/fs/vfat/namei.c~fat_lindent-vfat 2005-01-10 01:57:31.0 +0900 +++ linux-2.6.10-hirofumi/fs/vfat/namei.c 2005-01-10 01:57:44.0 +0900 @@ -12,7 +12,7 @@ * Short name translation 1999, 2001 by Wolfram Pienkoss [EMAIL PROTECTED] * * Support Multibyte character and cleanup by ^^^ Shouldn't that be 'characters'? Yup, that was it.. sorry if I'm nitpicking :-P Sytse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
