Re: [2.6.24 patch] fix netx-eth.c compilation
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Sat, 5 Jan 2008 23:46:16 +0200 > This was missed when commit e2ac455a18806b31c2d0da0a51d8740af5010b7a > fixed the compile errors in drivers/net/netx-eth.c caused by > commit 09f75cd7bf13720738e6a196cc0107ce9a5bd5a0. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Applied, thanks Adrian. -- 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][RFC] Simple tamper-proof device filesystem.
On Sun, Jan 06, 2008 at 04:36:06PM +0900, Tetsuo Handa wrote: > Hello. > > Willy Tarreau wrote: > > Your patch is very confusing. In your description, as well as in the > > comments you talk about tmpfs, but your patch does not touch even one > > line of tmpfs and only changes ramfs. Even your variables and arguments > > refer to tmpfs. The Kconfig entry indicates that the feature depends > > on TMPFS too. > > > > Judging from the following comment : > > * Original tmpfs doesn't set ramfs_dir_inode_operations.setattr field. > > > > I suspect that you confuse both filesystems. > > - ramfs is in fs/ramfs and is always compiled in, you cannot disable it > > - tmpfs is in mm/shmem.c and is optional. It also supports options that > > ramfs does not (eg: size) and data may be swapped. > > > > Please understand that I'm not discussing the usefulness of your patch, > > I'm just trying to avoid a huge confusion. > > Oh, I thought the filesystem mounted by "mount -t tmpfs none /tmp" is "tmpfs" Yes, that is a tmpfs. > and the source code of "tmpfs" is located in fs/ramfs directory. No, ramfs is what you get by "mount -t ramfs none /tmp" :-) You will notice that "df" will not report your ramfs by default because it reports zero blocks. But "mount" or "df /tmp" will report it. > So, I should write the description as "an extension to ramfs" rather than > "an extension to tmpfs". and please also the comments, macros and variable names in the code, as they are what confused me first. > I'll fix it in next posting. Thanks, Willy -- 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][RFC] Simple tamper-proof device filesystem.
Hello. Willy Tarreau wrote: > Your patch is very confusing. In your description, as well as in the > comments you talk about tmpfs, but your patch does not touch even one > line of tmpfs and only changes ramfs. Even your variables and arguments > refer to tmpfs. The Kconfig entry indicates that the feature depends > on TMPFS too. > > Judging from the following comment : > * Original tmpfs doesn't set ramfs_dir_inode_operations.setattr field. > > I suspect that you confuse both filesystems. > - ramfs is in fs/ramfs and is always compiled in, you cannot disable it > - tmpfs is in mm/shmem.c and is optional. It also supports options that > ramfs does not (eg: size) and data may be swapped. > > Please understand that I'm not discussing the usefulness of your patch, > I'm just trying to avoid a huge confusion. Oh, I thought the filesystem mounted by "mount -t tmpfs none /tmp" is "tmpfs" and the source code of "tmpfs" is located in fs/ramfs directory. So, I should write the description as "an extension to ramfs" rather than "an extension to tmpfs". I'll fix it in next posting. Thank you. -- 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] Fix regression in ip command line processing
From: Amos Waterland <[EMAIL PROTECTED]> Date: Sat, 5 Jan 2008 22:58:16 -0500 > ADDRESS ASSIGNED > > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=on" > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=dhcp" > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=both" > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=any" > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=::on" > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=::dhcp" > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append > "ip=10.0.2.15::10.0.2.2:255.255.255.0::eth0:off" > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append > "ip=10.0.2.15::10.0.2.2:255.255.255.0::eth0:on" > > ADDRESS NOT ASSIGNED > > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=" > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=off" > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=::off" I really wish Simon had tested his original patch as extensively as you have, this is the second major regression it has caused. :-/ I'll apply your fix, although I'll break up some super long lines you've added, thanks a lot. -- 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/
[PATCH] block2mtd lockdep_init_map warning
Hi David,
I've reported before a lockdep warning when block2mtd is modloaded, and a
device is initialized, as in
modprobe block2mtd block2mtd=/dev/loop0
A typical warning looks like this:
BUG: key f88565c0 not in .data!
WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
Pid: 1823, comm: modprobe Not tainted 2.6.24-rc6-unionfs2 #135
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack+0x6c/0x72
[] lockdep_init_map+0x94/0x374
[] debug_mutex_init+0x2c/0x3c
[] __mutex_init+0x38/0x40
[] 0xf885520d
[] parse_args+0x121/0x1fb
[] sys_init_module+0x10e8/0x1576
[] sysenter_past_esp+0x5f/0xa5
===
This is a long-standing problem I've seen in several of the latest stable
kernels. Once lockdep turns itself off, there's no easy way to turn it back
on short of a reboot.
I looked more closely at the mtd code. I believe the problem is that
lockdep doesn't like a mutex_init to be called from a module_init code path,
possibly because the module's symbols aren't all initialized yet. (This
could arguably be considered a limitation of lockdep.)
So I tried to defer the call to module_init until it's absolutely needed. I
couldn't find a clean way to do that via the struct mtd_info ops (there's no
suitable ->init op), so instead I used an int to mark whether the mutex is
initialized or not. Below is a patch. It works, but it's not as clean as
it should be: a better way would be to probably add an mtd_info ->init op or
so.
At least with this patch, lockdep doesn't complain any longer, so I can run
a clean set of regression tests w/ unionfs on top of jffs2 and other file
systems.
In lieu of a better fix, is this patch acceptable?
Thanks,
Erez.
--
block2mtd: defer mutex initialization to avoid a lockdep warning
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
diff --git a/drivers/mtd/devices/block2mtd.c b/drivers/mtd/devices/block2mtd.c
index be4b994..2c6d3e7 100644
--- a/drivers/mtd/devices/block2mtd.c
+++ b/drivers/mtd/devices/block2mtd.c
@@ -32,6 +32,7 @@ struct block2mtd_dev {
struct list_head list;
struct block_device *blkdev;
struct mtd_info mtd;
+ int mutex_initialized;
struct mutex write_mutex;
};
@@ -85,6 +86,11 @@ static int block2mtd_erase(struct mtd_info *mtd, struct
erase_info *instr)
size_t len = instr->len;
int err;
+ if (!dev->mutex_initialized) {
+ mutex_init(>write_mutex);
+ dev->mutex_initialized = 1;
+ }
+
instr->state = MTD_ERASING;
mutex_lock(>write_mutex);
err = _block2mtd_erase(dev, from, len);
@@ -194,6 +200,11 @@ static int block2mtd_write(struct mtd_info *mtd, loff_t
to, size_t len,
struct block2mtd_dev *dev = mtd->priv;
int err;
+ if (!dev->mutex_initialized) {
+ mutex_init(>write_mutex);
+ dev->mutex_initialized = 1;
+ }
+
if (!len)
return 0;
if (to >= mtd->size)
@@ -275,8 +286,6 @@ static struct block2mtd_dev *add_device(char *devname, int
erase_size)
goto devinit_err;
}
- mutex_init(>write_mutex);
-
/* Setup the MTD structure */
/* make the name contain the block device in */
dev->mtd.name = kmalloc(sizeof("block2mtd: ") + strlen(devname),
--
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: sparc oops in ip_fast_csum
From: Herbert Xu <[EMAIL PROTECTED]> Date: Sun, 06 Jan 2008 11:22:04 +1100 > [IPV4] raw: Strengthen check on validity of iph->ihl > > We currently check that iph->ihl is bounded by the real length and that > the real length is greater than the minimum IP header length. However, > we did not check the caes where iph->ihl is less than the minimum IP > header length. > > This breaks because some ip_fast_csum implementations assume that which > is quite reasonable. > > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Applied, I'll push this to -stable too, thanks Herbert. -- 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][RFC] Simple tamper-proof device filesystem.
Hello, On Sun, Jan 06, 2008 at 03:20:00PM +0900, Tetsuo Handa wrote: > Hello. > > Changes from previous posting: > > (1) Added kernel config so that users can choose > whether to compile this filesystem or not. > > I didn't receive any ACK/NACK regarding whether I'm permitted to > implement this filesystem as an extension to tmpfs or not. > So, I continued implementing this filesystem as an extension to tmpfs. > > (2) Removed indirect grabbing of blkdev_open() and chrdev_open(). > > The previous posting was using indirect approach to call > blkdev_open() and chrdev_open() so that users can compile > this filesystem as a module without exporting blkdev_open() > from fs/block_dev.c and chrdev_open() from fs/char_dev.c . > But since tmpfs cannot be compiled as a module, > I changed it to direct accessing. > > (3) Splitted single file into three files. > > syaoran_init.c: initialization part > syaoran_main.c: access control part > syaoran_debug.c: taking snapshot part > > This patch is for 2.6.24-rc6-mm1. > > Regards. > -- > Subject: Simple tamper-proof device filesystem. > > The goal of this filesystem is to guarantee that > "applications using well-known device locations under /dev > get the device they want" (e.g. an application that accesses /dev/null can > always get a character special device with major=1 and minor=3). > > This idea sounds silly? Indeed, if you think the root can do whatever > he/she wants do do. But this filesystem makes sense when used with > access control mechanisms like MAC (mandatory access control). > I want to use this filesystem in case where a process with root privilege was > hijacked but the behavior of the hijacked process is still restricted by MAC. > > Why not use FUSE? > > Because /dev has to be available through the lifetime of the kernel. > It is not acceptable if /dev stops working due to SIGKILL or OOM-killer. > > Why not use SELinux? > > Because SELinux doesn't guarantee filename and its attribute. > As far as I know, no MAC implementation can handle filename and its > attribute. > I guess this is because > > Filename and its attributes pairs are conventionally considered as > constant and reliable. > > It makes the MAC's policy syntax complicated to describe this attribute > enforcement information in MAC's policy. > > I want to add functionality that the MACs are missing. > Instead of adding this functionality per MAC, > I propose to add it as ground work, to be combined with any MAC. > > Why not drop CAP_MKNOD? > > Dropping CAP_MKNOD is not enough for emulating this filesystem because > a process can still rename()/unlink() to break filename and its attributes > handling (e.g. mv /dev/sda1 /dev/sda1.tmp; mv /dev/sda2 /dev/sda1; > mv /dev/sda1.tmp /dev/sda2 or unlink /dev/null; touch /dev/null ). > > This time, I'm implementing this filesystem as an extension to tmpfs > because what this filesystem does are nothing but check filename and > its attributes in addition to what tmpfs does. > > Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]> > --- > fs/Kconfig | 18 + > fs/ramfs/inode.c | 177 ++ > fs/ramfs/syaoran.h | 75 ++ > fs/ramfs/syaoran_debug.c | 183 +++ > fs/ramfs/syaoran_init.c | 568 > +++ > fs/ramfs/syaoran_main.c | 207 + > 6 files changed, 1222 insertions(+), 6 deletions(-) Your patch is very confusing. In your description, as well as in the comments you talk about tmpfs, but your patch does not touch even one line of tmpfs and only changes ramfs. Even your variables and arguments refer to tmpfs. The Kconfig entry indicates that the feature depends on TMPFS too. Judging from the following comment : * Original tmpfs doesn't set ramfs_dir_inode_operations.setattr field. I suspect that you confuse both filesystems. - ramfs is in fs/ramfs and is always compiled in, you cannot disable it - tmpfs is in mm/shmem.c and is optional. It also supports options that ramfs does not (eg: size) and data may be swapped. Please understand that I'm not discussing the usefulness of your patch, I'm just trying to avoid a huge confusion. Regards, Willy > --- linux-2.6-mm.orig/fs/ramfs/inode.c > +++ linux-2.6-mm/fs/ramfs/inode.c > @@ -36,6 +36,20 @@ > #include > #include "internal.h" > > +static struct inode *__ramfs_get_inode(struct super_block *sb, int mode, > +dev_t dev, bool tmpfs_with_mac); > + > +#define TMPFS_WITH_MAC1 > +#define TMPFS_WITHOUT_MAC 0 > +#include > + > +#ifdef CONFIG_SYAORAN > +#include "syaoran.h" > +#include "syaoran_init.c" > +#include "syaoran_main.c" > +#include "syaoran_debug.c" > +#endif > + > /* some random number */ > #define RAMFS_MAGIC 0x858458f6 > > @@ -51,6 +65,12 @@ static struct backing_dev_info ramfs_bac >
[PATCH][RFC] Simple tamper-proof device filesystem.
Hello.
Changes from previous posting:
(1) Added kernel config so that users can choose
whether to compile this filesystem or not.
I didn't receive any ACK/NACK regarding whether I'm permitted to
implement this filesystem as an extension to tmpfs or not.
So, I continued implementing this filesystem as an extension to tmpfs.
(2) Removed indirect grabbing of blkdev_open() and chrdev_open().
The previous posting was using indirect approach to call
blkdev_open() and chrdev_open() so that users can compile
this filesystem as a module without exporting blkdev_open()
from fs/block_dev.c and chrdev_open() from fs/char_dev.c .
But since tmpfs cannot be compiled as a module,
I changed it to direct accessing.
(3) Splitted single file into three files.
syaoran_init.c: initialization part
syaoran_main.c: access control part
syaoran_debug.c: taking snapshot part
This patch is for 2.6.24-rc6-mm1.
Regards.
--
Subject: Simple tamper-proof device filesystem.
The goal of this filesystem is to guarantee that
"applications using well-known device locations under /dev
get the device they want" (e.g. an application that accesses /dev/null can
always get a character special device with major=1 and minor=3).
This idea sounds silly? Indeed, if you think the root can do whatever
he/she wants do do. But this filesystem makes sense when used with
access control mechanisms like MAC (mandatory access control).
I want to use this filesystem in case where a process with root privilege was
hijacked but the behavior of the hijacked process is still restricted by MAC.
Why not use FUSE?
Because /dev has to be available through the lifetime of the kernel.
It is not acceptable if /dev stops working due to SIGKILL or OOM-killer.
Why not use SELinux?
Because SELinux doesn't guarantee filename and its attribute.
As far as I know, no MAC implementation can handle filename and its attribute.
I guess this is because
Filename and its attributes pairs are conventionally considered as
constant and reliable.
It makes the MAC's policy syntax complicated to describe this attribute
enforcement information in MAC's policy.
I want to add functionality that the MACs are missing.
Instead of adding this functionality per MAC,
I propose to add it as ground work, to be combined with any MAC.
Why not drop CAP_MKNOD?
Dropping CAP_MKNOD is not enough for emulating this filesystem because
a process can still rename()/unlink() to break filename and its attributes
handling (e.g. mv /dev/sda1 /dev/sda1.tmp; mv /dev/sda2 /dev/sda1;
mv /dev/sda1.tmp /dev/sda2 or unlink /dev/null; touch /dev/null ).
This time, I'm implementing this filesystem as an extension to tmpfs
because what this filesystem does are nothing but check filename and
its attributes in addition to what tmpfs does.
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
fs/Kconfig | 18 +
fs/ramfs/inode.c | 177 ++
fs/ramfs/syaoran.h | 75 ++
fs/ramfs/syaoran_debug.c | 183 +++
fs/ramfs/syaoran_init.c | 568 +++
fs/ramfs/syaoran_main.c | 207 +
6 files changed, 1222 insertions(+), 6 deletions(-)
--- linux-2.6-mm.orig/fs/ramfs/inode.c
+++ linux-2.6-mm/fs/ramfs/inode.c
@@ -36,6 +36,20 @@
#include
#include "internal.h"
+static struct inode *__ramfs_get_inode(struct super_block *sb, int mode,
+ dev_t dev, bool tmpfs_with_mac);
+
+#define TMPFS_WITH_MAC1
+#define TMPFS_WITHOUT_MAC 0
+#include
+
+#ifdef CONFIG_SYAORAN
+#include "syaoran.h"
+#include "syaoran_init.c"
+#include "syaoran_main.c"
+#include "syaoran_debug.c"
+#endif
+
/* some random number */
#define RAMFS_MAGIC0x858458f6
@@ -51,6 +65,12 @@ static struct backing_dev_info ramfs_bac
struct inode *ramfs_get_inode(struct super_block *sb, int mode, dev_t dev)
{
+ return __ramfs_get_inode(sb, mode, dev, TMPFS_WITHOUT_MAC);
+}
+
+static struct inode *__ramfs_get_inode(struct super_block *sb, int mode,
+ dev_t dev, const bool tmpfs_with_mac)
+{
struct inode * inode = new_inode(sb);
if (inode) {
@@ -65,10 +85,18 @@ struct inode *ramfs_get_inode(struct sup
switch (mode & S_IFMT) {
default:
init_special_inode(inode, mode, dev);
+#ifdef CONFIG_SYAORAN
+ if (tmpfs_with_mac)
+ init_syaoran_inode(inode, mode);
+#endif
break;
case S_IFREG:
inode->i_op = _file_inode_operations;
inode->i_fop = _file_operations;
+#ifdef CONFIG_SYAORAN
+ if (tmpfs_with_mac)
+ init_syaoran_inode(inode, mode);
+#endif
break;
case
Re: [PATCH] x86: ioport_{32|64}.c unification
On Sun, 06 Jan 2008 02:20:45 +0100, Miguel =?utf-8?q?Bot=C3=B3n?= said:
> #ifdef CONFIG_X86_32
> asmlinkage long sys_iopl(unsigned long regsp)
> {
> volatile struct pt_regs *regs = (struct pt_regs *)
> unsigned int level = regs->bx;
> #else
> asmlinkage long sys_iopl(unsigned int level, struct pt_regs *regs)
> {
> #endif
> return do_iopl(level, (long *)>flags);
> }
That looks like an unholy marriage between the preprocessor, a function
definition, and a Duff Device. :)
Do it like this:
#ifdef CONFIG_X86_32
asmlinkage sys_iopl( prototype_needed)
{
/* the whole thing */
}
#else
asmlinkage long sys_iopl(alternate_prototype)
{
/* the entire body */
}
#endif
You'll still need some ad-croc ifdef-ery at the call site to make it use
the correct prototype (unless you can come up with some clever way of making
the two use the same prototype, possibly by passing a dummy argument on
some architectures...
pgpSqMEeiTIh2.pgp
Description: PGP signature
Re: [RESEND PATCH 06/10] ide-floppy: report DMA handling in idefloppy_pc_intr() properly
On Sat, Jan 05, 2008 at 04:46:05PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Hmm, no. The driver is called ide-floppy (ide_floppy) and it is more
> readable this way.
>
> > {
> > idefloppy_t *floppy = drive->driver_data;
> > struct gendisk *g = floppy->disk;
> > @@ -1479,7 +1450,7 @@ static ide_proc_entry_t idefloppy_proc[] = {
> > };
> > #endif /* CONFIG_IDE_PROC_FS */
> >
> > -static int ide_floppy_probe(ide_drive_t *);
> > +static int idefloppy_probe(ide_drive_t *);
>
> ditto
>
> [...]
>
> > @@ -1733,7 +1704,7 @@ static struct block_device_operations idefloppy_ops =
> > {
> > .revalidate_disk= idefloppy_revalidate_disk
> > };
> >
> > -static int ide_floppy_probe(ide_drive_t *drive)
> > +static int idefloppy_probe(ide_drive_t *drive)
>
> ditto
Shouldn't those also conform to the driver function format idefloppy_bla() -
after all, those function names are unambiguous for the whole file...?
--
Regards/Gruß,
Boris.
--
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/5] USB Kconfig: Select SCSI for USB Mass Storage support
Sam Ravnborg wrote: > On Sat, Jan 05, 2008 at 11:03:30PM +0200, Adrian Bunk wrote: > > For kconfig users, "select" is _much_ better than sending them through > > different menus. > > Only if used within the current limitations of Kconfig. > And that requires you to use select only to select symbols with > no dependencies. > > In this case we do not know if BLOCK is enabled or not. Good point! How about we solve it like this: menuconfig USB_STORAGE tristate "USB Mass Storage support" - depends on USB && SCSI + depends on USB && BLOCK + select SCSI Thanks! -- Al -- 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: Forcing modes in libata (was: SATA buffered read VERY slow)
Alan Cox wrote: > Al Boldi <[EMAIL PROTECTED]> wrote: > > What's hindering the ability to force a mode in libata, as is possible > > with the normal ide-driver? > > We want it to be correct and race free. That means we have to synchronize > all the devices on the controller, quiesce them and recompute the speeds > for each device then turn them all back on and resume command processing. > > It is quite hairy although Tejun's EH work has provided the framework for > all of this. > > For now you can boot with libata.dma=1 to select DMA on disks but not CD Great, but why isn't this in the documentation? Thanks! -- Al -- 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: sparc oops in ip_fast_csum
On Sun, Jan 06, 2008 at 02:02:14AM +, Al Viro wrote:
>
> E.g. what about ipt_REJECT.c::send_reset()? Or myri10ge_get_frag_header()?
Yes both look wrong.
Patrick, please have a look at the former. In fact it's not just
that ihl may be bogus (which might be harmless as long as the REJECT
hook only gets called from within the IP stack), I think REJECT would
also do the wrong thing if the packet had IP options. So perhaps we
should just make it create a packet from scratch rather than being
too clever in reusing the old one.
As to LRO, I must say it was a pretty shoddy job. Now I can't complain
too much because I wasn't able to spend any time in 2007 working on it.
But it's definitely high on my todo list for 2008.
Oh and Al, your effort in going through all the ip_fast_csum callers
is much appreciated!
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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] PM: Acquire device locks on suspend
On Sat, 5 Jan 2008, Rafael J. Wysocki wrote: > On Saturday, 5 of January 2008, Alan Stern wrote: > > On Sat, 5 Jan 2008, Rafael J. Wysocki wrote: > > > Still, even doing that is not enough, since someone can call > > > destroy_suspended_device() from a .suspend() routine and then the device > > > will end up on a wrong list just as well. > > > > That should never happen. The whole idea of destroy_suspended_device() > > is that the device couldn't be resumed and in fact should be > > unregistered because it is no longer working or no longer present. A > > suspend routine won't detect this sort of thing since it doesn't try to > > resume the device. > > > > But it wouldn't hurt to mention in the kerneldoc that > > destroy_suspended_device() is meant to be called only during a system > > resume. > > Hmm. Please have a look at the appended patch. > > I have removed the warning from device_del() and used list_empty() to detect > removed devices in the .suspend() routines. Is that viable? It's not good. The warning in device_del() is vital. It's what will tell people where the problem is when a deadlock occurs during system resume because some driver has mistakenly tried to unregister a device at the wrong time. It would have pointed immediately to the msr driver in the case of the bug Andrew found, for instance. If you can figure out a way to disable the warning in device_del() for just the one device being unregistered by device_pm_destroy_suspended(), I suppose that would be okay. Alan Stern -- 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/
[PATCH] Fix regression in ip command line processing
The recent changes for ip command line processing fixed some problems
but unfortunately broke some common usage scenarios. In current
2.6.24-rc6 the following command line results in no IP address
assignment, which is surely a regression:
ip=10.0.2.15::10.0.2.2:255.255.255.0::eth0:off
Please find below a patch that works for all cases I can find.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
For convenience, here are the test cases phrased as qemu invocations:
ADDRESS ASSIGNED
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=on"
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=dhcp"
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=both"
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=any"
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=::on"
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=::dhcp"
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append
"ip=10.0.2.15::10.0.2.2:255.255.255.0::eth0:off"
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append
"ip=10.0.2.15::10.0.2.2:255.255.255.0::eth0:on"
ADDRESS NOT ASSIGNED
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip="
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=off"
qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=::off"
---
Documentation/nfsroot.txt |1 +
net/ipv4/ipconfig.c | 19 +++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/Documentation/nfsroot.txt b/Documentation/nfsroot.txt
index c86dd38..1a4d199 100644
--- a/Documentation/nfsroot.txt
+++ b/Documentation/nfsroot.txt
@@ -145,6 +145,7 @@
ip=::
this option.
off or none: don't use autoconfiguration
+ (do static IP assignment instead)
on or any: use any protocol available in the kernel
(default)
dhcp:use DHCP
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 56a6757..8563b2e 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -1404,8 +1404,7 @@ static int __init ic_proto_name(char *name)
return 1;
}
if (!strcmp(name, "off") || !strcmp(name, "none")) {
- ic_enable = 0;
- return 1;
+ return 0;
}
#ifdef CONFIG_IP_PNP_DHCP
else if (!strcmp(name, "dhcp")) {
@@ -1442,10 +1441,20 @@ static int __init ip_auto_config_setup(char *addrs)
ic_set_manually = 1;
ic_enable = 1;
+ /*
+* If any dhcp, bootp etc options are set, leave autoconfig on
+* and skip the below static IP processing.
+*/
if (ic_proto_name(addrs))
return 1;
- /* Parse the whole string */
+ /* If no static IP is given, turn off autoconfig and bail. */
+ if (*addrs == 0 || strcmp(addrs, "off") == 0 || strcmp(addrs, "none")
== 0) {
+ ic_enable = 0;
+ return 1;
+ }
+
+ /* Parse string for static IP assignment. */
ip = addrs;
while (ip && *ip) {
if ((cp = strchr(ip, ':')))
@@ -1483,7 +1492,9 @@ static int __init ip_auto_config_setup(char *addrs)
strlcpy(user_dev_name, ip,
sizeof(user_dev_name));
break;
case 6:
- ic_proto_name(ip);
+ if (ic_proto_name(ip) == 0 && ic_myaddr ==
NONE) {
+ ic_enable = 0;
+ }
break;
}
}
--
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: [Bluez-devel] Oops involving RFCOMM and sysfs
Hello, Al Viro wrote: > On Sun, Jan 06, 2008 at 11:54:43AM +0900, Tejun Heo wrote: >> That means sysfs_remove_dir() is called on parent while other operations >> are in progress on children, right? sysfs has never allowed such things >> && AFAIK no one does that. It's somewhat implied in the interface (such >> as recursive removing) but I fully agree it's problematic. Things like >> these are why I think we need to unify/simplify locking as I wrote >> previously. > > All it takes is kobject_rename() or kobject_move() called asynchronously > wrt removal... I don't see an explicit ban for that. There really hasn't been any stone-set rules for how sysfs can be used and what operations are allowed simultaneously although sysfs implementation always had a lot of assumptions about which ops can and can't be done simultaneously. The general assumption is that the caller is responsible for its and its children's lifetime management which is usually followed as sysfs nodes are removed when a device goes away or driver detaches at which point no other ops should be in progress anyway. I think this stems partially from tight coupling with kobject / driver model. kobject and driver model have certain rules about how they can be used (again not explicit enough) and sysfs implementation kind of piggy backed on those rules and added its own assumptions on top of it. After a while, it's hard to track what's assumed where and implementing or changing one feature somewhere breaks some assumption elsewhere. This is the primary reason why I think sysfs should be an independent component which the driver model uses not something intertwined into driver model while having mostly separate implementation. > FWIW, what happens here *is* fishy, but I don't see an outright ban on > that in documentation - rfcomm_tty_open() does > device_move(dev->tty_dev, rfcomm_get_device(dev)); > when we get openers, rfcomm_tty_close() does > device_move(dev->tty_dev, NULL); > when the number of openers hits zero. Can happen repeatedly. > > Note that device_move() with new parent being NULL is explicitly allowed > and handled, so... (cc'ing Kay Sievers) IIRC, that's device class compatibility thing. Overlapping move's are okay tho as they're protected from each other by sysfs_rename_mutex. I'll take a look at the rfcomm code and see what's going on tomorrow. Gotta hit the road now. Thanks. -- tejun -- 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: Idle loadavg of ~1, maybe MD related
> Maybe, but we can usually work around it pretty comfortably. > > If smu_set_fan() is only ever called by a kernel thread then we can simply > flip it over to using wait_for_completion_interruptible(). Hrm... as of today, it's mostly called from a kernel thread but I don't totally iron out the possibility that we add control to those things via sysfs... But that's definitely an option for now. However, that's only part of the problem. There's a lot of I2C accesses (and other SMU accesses to read SMU based sensors) and I doubt we can make all of that "magically" interruptible. I would much prefer if we had a way to tag a kernel thread to not add to the load average when in interruptible sleep :-) > If smu_set_fan() is also called from user processes then things aren't so > easy... Ben. -- 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: Top 10 kernel oopses for the week ending January 5th, 2008
On Sat, Jan 05, 2008 at 07:31:29PM -0800, Arjan van de Ven wrote: > Andi Kleen wrote: > >Arjan van de Ven <[EMAIL PROTECTED]> writes: > >>Rank 4: remove_proc_entry > >>Was also ranked 4th last week > >>Only in tainted oopses > >>Reported 3 times (12 total reports) > >>More info: > >>http://www.kerneloops.org/search.php?search=remove_proc_entry > > > >Likely a broken module_exit() function that corrupts the list. To track > >these down it might be useful to keep a list of recently unloaded modules > >and dump these too in the oops module list with a special flag. > > > I suspect that simply printing the currently unloading module will catch > 90%+ already; There are a few cases where the corruption is only visible next time someone accesses the list. So a small ring buffer might make sense. -Andi -- 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] scsi: revert "[SCSI] Get rid of scsi_cmnd->done"
On Sat, 6 Jan 2008, Peter Osterlund wrote:
>
> The problem is that pktcdvd opens the cd device in non-blocking mode
> when pktsetup is run, and doesn't close it again until pktsetup -d
> is run. The effect is that if you meanwhile open the cd device,
> blkdev.c:do_open() doesn't call bd_set_size() because bdev->bd_openers
> is non-zero.
>
> I don't know the correct way to fix this. Maybe adding bd_set_size()
> to sr.c:get_sectorsize() which already does set_capacity() would
> work.
Hmm.. I wouldn't say that's the correct way to fix it. The thing is, if
somebody has explicitly set the size of the device, than that *is* the
size.
The kernel should do what it is told, and it very much on purpose does the
size probing only on the first open: exactly because other open fd's in
progress may be there explicitly to fix up something, or may simply depend
on some size it already knew about (ie we don't want to change the size
behind its back).
And in particular, setting the size with bd_set_size also sets the
block-size, and while most things migt react fairly well to the pure
*size* changing, they will react very badly indeed to the blocksize
changing!
So no, doing a "bd_set_size()" in any but the outermost opener simply
isn't acceptable. It would cause serious problems and total chaos for the
block cache (we do not handle aliasing of multiple different blocksizes).
So we are very careful indeed to only call bd_set_size() when bd_openers
is zero.
That said, at least in your scenario:
> 1. Start with an empty drive.
> 2. pktsetup 0 /dev/scd0
> 3. Insert a CD containing an isofs filesystem.
> 4. mount /dev/pktcdvd/0 /mnt/tmp
> 5. umount /mnt/tmp
> 6. Press the eject button.
> 7. Insert a DVD containing a non-writable filesystem.
> 8. mount /dev/scd0 /mnt/tmp
> 9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
> 10. If the DVD contains data beyond the physical size of a CD, you
> get I/O errors in the terminal, and dmesg reports lots of
> "attempt to access beyond end of device" errors.
part of the problem here seems to be that the "media change" notification
that /dev/scd0 hopefully handled correctly and caused the "set_capacity()"
hass not made it to the i_size thing (that the block device layer checks).
So the way things are *supposed* to work is that the media-change function
("revalidate_disk()") should have triggered as part of the media change,
and that *should* have already done the set_capacity(), and that in turn
is the thing that should do it all (sets the disk capacity *without*
changing the blocksize!)
But since "set_capacity()" doesn't actually change "i_size", only
dev->capacity (which is correct - there may be many inodes associated with
one device), we actually ended up having this subtle dependency on
calling bd_set_size() (which we can *only* do on the first open, due to
the blocksize issues).
Which means that media-change won't fix these things like it is supposed
to. And I suspect we've had this bug (well, it *appears* to be a bug) for
a while, simply because all *normal* uses will open and close the device
properly.
Maybe a patch something like this might work out. I haven't really thought
it through entirely - but it basically just sets the size, without doing
the whole blocksize thing.
Jens? Al? Comments?
Does a patch like this change the behaviour you see at all?
This all still leaves the question unanswered why that commit
6f5391c283d7fdcf24bf40786ea79061919d1e1d changed any behaviour at all.
Because the thing that Peter is describing has nothing to do with any
low-level drivers what-so-ever.
Linus
---
fs/block_dev.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 993f78c..6a20da9 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1191,6 +1191,7 @@ static int do_open(struct block_device *bdev, struct file
*file, int for_part)
}
if (bdev->bd_invalidated)
rescan_partitions(bdev->bd_disk, bdev);
+ bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
}
}
bdev->bd_openers++;
--
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: [Bluez-devel] Oops involving RFCOMM and sysfs
On Sun, Jan 06, 2008 at 11:54:43AM +0900, Tejun Heo wrote: > That means sysfs_remove_dir() is called on parent while other operations > are in progress on children, right? sysfs has never allowed such things > && AFAIK no one does that. It's somewhat implied in the interface (such > as recursive removing) but I fully agree it's problematic. Things like > these are why I think we need to unify/simplify locking as I wrote > previously. All it takes is kobject_rename() or kobject_move() called asynchronously wrt removal... I don't see an explicit ban for that. FWIW, what happens here *is* fishy, but I don't see an outright ban on that in documentation - rfcomm_tty_open() does device_move(dev->tty_dev, rfcomm_get_device(dev)); when we get openers, rfcomm_tty_close() does device_move(dev->tty_dev, NULL); when the number of openers hits zero. Can happen repeatedly. Note that device_move() with new parent being NULL is explicitly allowed and handled, so... -- 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: Top 10 kernel oopses for the week ending January 5th, 2008
Andi Kleen wrote: Arjan van de Ven <[EMAIL PROTECTED]> writes: Rank 4: remove_proc_entry Was also ranked 4th last week Only in tainted oopses Reported 3 times (12 total reports) More info: http://www.kerneloops.org/search.php?search=remove_proc_entry Likely a broken module_exit() function that corrupts the list. To track these down it might be useful to keep a list of recently unloaded modules and dump these too in the oops module list with a special flag. I suspect that simply printing the currently unloading module will catch 90%+ already; I'll look into adding this, it's a very good idea. -- 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: Top 10 kernel oopses for the week ending January 5th, 2008
Arjan van de Ven <[EMAIL PROTECTED]> writes: > > Rank 4: remove_proc_entry > Was also ranked 4th last week > Only in tainted oopses > Reported 3 times (12 total reports) > More info: http://www.kerneloops.org/search.php?search=remove_proc_entry Likely a broken module_exit() function that corrupts the list. To track these down it might be useful to keep a list of recently unloaded modules and dump these too in the oops module list with a special flag. -Andi -- 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.24-rc6-mm1
On Sat, 5 Jan 2008 17:25:24 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Sat, 5 Jan 2008 23:10:17 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
>
> > On Jan 5, 2008 3:52 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> > > On Jan 5, 2008 11:13 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > > > On Sat, Jan 05, 2008 at 09:01:02AM +0100, Torsten Kaiser wrote:
> > > > > On Jan 5, 2008 1:07 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > > > > > I think it would be easier just to start with this working -rc6 and
> > > > > > simply check if we have 'right' suspects, so: git-net.patch and
> > > > > > git-nfsd.patch from -mm1-broken-out, as suggested by Herbert (I
> > > > > > hope,
> > > > > > can compile - otherwise you could try the other way: add the whole
> > > > > > -mm
> > > > > > and revert these two). Using current gits could complicate this
> > > > > > "investigation".
> > > > >
> > > > > OK, I will try this...
> > >
> > > still on the todo-list, I had no time to try this yet...
> >
> > working on it...
> > 2.6.24-rc6 + mm-patches up to git.battery (includes git-net and
> > git-netdev-all) worked for 110 packages, then I proclaimed it good.
> > 2.6.24-rc6 + mm-patches up to (including) git.nfsd is currently
> > getting testet (9 packages done...)
> >
> > But the cause of my mail is the following question:
> > Regarding my "iommu-sg-merging-patches are new in -rc3-mm and could be
> > the cause"-suspicion I looked at these patches and came across these
> > hunks:
> >
> > This is removed from arch/x86/lib/bitstr_64.c:
> > -/* Find string of zero bits in a bitmap */
> > -unsigned long
> > -find_next_zero_string(unsigned long *bitmap, long start, long nbits, int
> > len)
> > -{
> > - unsigned long n, end, i;
> > -
> > - again:
> > - n = find_next_zero_bit(bitmap, nbits, start);
> > - if (n == -1)
> > - return -1;
> > -
> > - /* could test bitsliced, but it's hardly worth it */
> > - end = n+len;
> > - if (end > nbits)
> > - return -1;
> > - for (i = n+1; i < end; i++) {
> > - if (test_bit(i, bitmap)) {
> > - start = i+1;
> > - goto again;
> > - }
> > - }
> > - return n;
> > -}
> >
> > This is added to lib/iommu-helper.c:
> > +static unsigned long find_next_zero_area(unsigned long *map,
> > +unsigned long size,
> > +unsigned long start,
> > +unsigned int nr)
> > +{
> > + unsigned long index, end, i;
> > +again:
> > + index = find_next_zero_bit(map, size, start);
> > + end = index + nr;
> > + if (end > size)
> > + return -1;
> > + for (i = index + 1; i < end; i++) {
> > + if (test_bit(i, map)) {
> > + start = i+1;
> > + goto again;
> > + }
> > + }
> > + return index;
> > +}
> >
> > The old version checks, if find_next_zero_bit returns -1, the new
> > version doesn't do this.
> > Is this intended and can find_next_zero_bit never fail?
> > Hmm... but in the worst case it should only loop forever if I'm
> > reading this right (index = -1 => for-loop counts from 0 to nr, if any
> > bit is set it will jump to "again:" and if the next call to
> > find_next_zero_bit also fails, its an endless loop)
find_next_zero_bit returns -1?
It seems that x86_64 doesn't. POWER and SPARC64 IOMMUs use
find_next_zero_bit too but both doesn't check if find_next_zero_bit
returns -1. If find_next_zero_bit fails, it returns size. So it
doesn't leads to an endless loop.
But this patch has other bugs that break POWER IOMMUs.
If you use the IOMMUs on POWER, please try the following patch:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg12702.html
>
> I susect these are doing different things.
> iommu-sg-kill-__clear_bit_string-and-find_next_zero_string.patch says:
>
> This kills unused __clear_bit_string and find_next_zero_string (they
> were used by only gart and calgary IOMMUs).
>
> iommu-sg-add-iommu-helper-functions-for-the-free-area-management.patch says:
>
> This adds IOMMU helper functions for the free area management. These
> functions take care of LLD's segment boundary limit for IOMMUs. They
> would be useful for IOMMUs that use bitmap for the free area management.
>
> > So even if this can not explain my bug, could somebody check if this
> > is a real bug or not?
>
> Let's cc the author of those changes.
>
> Thanks for persisting with this bug.
--
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: init wont start on VIA EPIA 5000 500mhz board and randomely wont start on VIA EPIA MII 10000
On Sat, Jan 05, 2008 at 05:14:08PM -0800, mathewss wrote:
> I have been trying to figure this out a while now with printk's all over my
> kernel as well as adding kdb and tracing the int3 events.
>
> I have tried various 2.6 kernels and so far all i have tried do this.
>
> My current tests are on 2.6.22.10
>
> I have a simple init binary I compiled static that is my init that is loaded
> into an init file system. I am not using cpio but that did not seem to matter.
> begin testinit.c
> #include
> #include
> int main(int argc, char *argv[])
> {
>printf("Hello world!\n");
>sleep(9);
> }
> end
>
> I am using syslunux to start my kernel and appending the follwiing startup
> command most of this is specific to my true init script but again im using a
> "hello world" script to debug this for now.
>
> append debug kidb=early console=ttyS0,384008n initrd=ufoinit.img
> init=/testinit rw var_size=12M tmp_size=MAX log_size=16M root_size=64M
> root=/dev/ram0 boot=/dev/hda1,msdos rw pkgpath=/dev/hda1:msdos rw verbose
> DELAY=0 TEST=0 DEBUG=0 VERBOSE=0 UFO=root,etc,modules
>
> On an intel CA810EEA 800mhz board or QEMU this runs fine but on the via
> boards it dies right after "Freeing unused kernel memory: 132k freed"
>
That will be where it invokes the init program, I think, so the
kernel is probably not to blame.
> on the 500mhz board it dies every time on the 800mhz it is random.
>
For the 500MHz, this sounds like the "i686 implies cmov" problem -
gcc thinks that all i686 CPUs understand a particular instruction
('cmov', if my brain cells haven't totally given up), but early via
processors didn't. Haven't seen too many references to this
recently, so perhaps recent versions of gcc have fixed this, or
perhaps people know of a workaround.
I suggest that your userspace (glibc and gcc, I suppose) is built
for i686 and uses the instruction that your CPU doesn't understand.
The 800MHz might be different, I thought those did provide the
instruction. Have you checked the memory with memtest86 ? For the
cases where it doesn't die, perhaps you should give it an init which
is going to do something, and see if it actually manages to boot any
of the time. If so, that would confirm that the two CPUs are not
identical in their capabilities. It wouldn't explain the less than
100% success, of course, so the usual suspects (crap hardware,
failing memory, dodgy power supplies) would need to be investigated.
As always, this is intended to be helpful, but treat it with a
grain of salt, I could well be talking out of a different orifice
than my mouth. My last experience with a via processor was a 1.2GHz
beastie which certainly understood all i686 instructions, but
managed to make snails look fast, and wasn't as power-frugal as
expected, so I might be prejudiced.
> I have noticed that i get the elf binarly loading into user space with some
> page_faults then I get blasted with do_notify_resume with 0x04 or
> TIF_SIGPENDING over and over as if its in an infinite loop.
>
> This begins shortly after load_elf_binary -> clear_user i think right after
> a page_fault during the clear_user. I dont even know why that signal is being
> sent on other hardware it never happens.
>
> I am not even sure what do try next.
>
Find a toolchain built for i586 ? (Or preferably i486, I think I
remember comments that early via CPUs run better when optimised for
i486).
If you think your own toolchain is compiled for i586, you could try
downloading one of the distros which definitely is built for i586 or
i486 - if that works, it's a userspace compile problem. Or, perhaps,
the kernel actually needs to be built for i486 - I doubt that, but I
don't have the hardware.
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
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.24-rc6-mm1
On Jan 5, 2008 11:10 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote: > 2.6.24-rc6 + mm-patches up to git.battery (includes git-net and > git-netdev-all) worked for 110 packages, then I proclaimed it good. > 2.6.24-rc6 + mm-patches up to (including) git.nfsd is currently > getting testet (9 packages done...) That kernel did also work for all 110 packages. 2.6.24-rc6 + mm-patches up to (including) git.xfs -> crash [ 576.899332] [ cut here ] [ 576.903661] kernel BUG at lib/list_debug.c:33! [ 576.903661] invalid opcode: [1] SMP [ 576.903661] last sysfs file: /devices/system/cpu/cpu3/cache/index2/shared_cpu_map [ 576.903661] CPU 3 [ 576.903661] Modules linked in: radeon drm w83792d ipv6 tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx tea5761 tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg videobuf_core btcx_risc tveeprom videodev v4l2_common usbhid v4l1_compat sg hid i2c_nforce2 pata_amd [ 576.903661] Pid: 5559, comm: nfsv4-svc Not tainted 2.6.24-rc6-mm-git.xfs #2 [ 576.903661] RIP: 0010:[] [] __list_add+0x54/0x60 [ 576.903661] RSP: 0018:81007d4e1dc0 EFLAGS: 00010282 [ 576.903661] RAX: 0088 RBX: 81007e955800 RCX: fc6c7900 [ 576.903661] RDX: 81007d53eef0 RSI: 0001 RDI: 80760140 [ 576.903661] RBP: 81007d4e1dc0 R08: 0001 R09: [ 576.903661] R10: 810080062008 R11: 0001 R12: 81007ed00900 [ 576.903661] R13: 81007ed00938 R14: 81007ed00938 R15: 81007dd6f100 [ 576.903661] FS: 7f1b7e6a36f0() GS:81011ff1b780() knlGS: [ 576.903661] CS: 0010 DS: ES: CR0: 8005003b [ 576.903661] CR2: 7ffb28c2c000 CR3: 741ab000 CR4: 06e0 [ 576.903661] DR0: DR1: DR2: [ 576.903661] DR3: DR6: 0ff0 DR7: 0400 [ 576.903661] Process nfsv4-svc (pid: 5559, threadinfo 81007d4e, task 81007d53eef0) [ 576.903661] Stack: 81007d4e1e00 805c4dbb 81007ed00908 81007dd6f100 [ 576.903661] 81011ad7bc00 81007d458000 81007e955800 81007dd6f110 [ 576.903661] 81007d4e1e10 805c4ea7 81007d4e1ee0 805c5fd4 [ 576.903661] Call Trace: [ 576.903661] [] svc_xprt_enqueue+0x1ab/0x240 [ 576.903661] [] svc_xprt_received+0x17/0x20 [ 576.903661] [] svc_recv+0x394/0x7c0 [ 576.903661] [] svc_send+0xae/0xd0 [ 576.903661] [] default_wake_function+0x0/0x10 [ 576.903661] [] nfs_callback_svc+0x79/0x130 [ 576.903662] [] finish_task_switch+0xcc/0xe0 [ 576.903662] [] child_rip+0xa/0x12 [ 576.903662] [] restore_args+0x0/0x30 [ 576.903662] [] __svc_create_thread+0xdd/0x200 [ 576.903662] [] nfs_callback_svc+0x0/0x130 [ 576.903662] [] child_rip+0x0/0x12 [ 576.903662] [ 576.903662] [ 576.903662] Code: 0f 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 8b 16 48 89 e5 e8 [ 576.903662] RIP [] __list_add+0x54/0x60 [ 576.903662] RSP [ 576.903673] ---[ end trace d46de6b99ae8cd5a ]--- [ 576.913664] Kernel panic - not syncing: Aiee, killing interrupt handler! Torsten -- 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.25 patch] remove a.out interpreter for ELF executables
On Sun, Jan 06, 2008 at 03:09:01AM +1030, David Newall wrote: > On Tue, 1 Jan 2008 15:36:32 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote: > >> ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/remove-aout-interpreter >> >> Also removal of the old unused iBCS hooks while I was on it >> >> ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/remove-ibcs-support > > Is iBCS support the basis for SCO & SVr4 support? (These both sound > useful.) Yes, but that always required an external patchkit which AFAIK existed only for 2.4. The point is that if you have to apply an external patchkit anyways you can as well apply the small patches for these hooks too. But it doesn't make sense to carry the (admittedly minor) overhead for this in all kernels. Also the ELF loader is quite hairy code and any simplification of it helps. -Andi -- 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/
[patch 4/5] bugh-remove-have_arch_bug--have_arch_warn
From: Olof Johansson <[EMAIL PROTECTED]>
No need to have the HAVE_ARCH_BUG.* / HAVE_ARCH_WARN.* defines, when
the generic implementation can just use #ifndef on the macros themselves.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/asm-alpha/bug.h |1 -
include/asm-arm/bug.h |1 -
include/asm-avr32/bug.h |3 ---
include/asm-frv/bug.h |1 -
include/asm-generic/bug.h | 10 +-
include/asm-ia64/bug.h|1 -
include/asm-m68k/bug.h|1 -
include/asm-mips/bug.h|4
include/asm-parisc/bug.h |2 --
include/asm-powerpc/bug.h |3 ---
include/asm-s390/bug.h|2 --
include/asm-sparc/bug.h |1 -
include/asm-sparc64/bug.h |1 -
include/asm-v850/bug.h|1 -
include/asm-x86/bug.h |1 -
15 files changed, 5 insertions(+), 28 deletions(-)
Index: linux-2.6.24-rc6/include/asm-alpha/bug.h
===
--- linux-2.6.24-rc6.orig/include/asm-alpha/bug.h
+++ linux-2.6.24-rc6/include/asm-alpha/bug.h
@@ -10,7 +10,6 @@
__asm__ __volatile__("call_pal %0 # bugchk\n\t"".long %1\n\t.8byte %2" \
: : "i" (PAL_bugchk), "i"(__LINE__), "i"(__FILE__))
-#define HAVE_ARCH_BUG
#endif
#include
Index: linux-2.6.24-rc6/include/asm-arm/bug.h
===
--- linux-2.6.24-rc6.orig/include/asm-arm/bug.h
+++ linux-2.6.24-rc6/include/asm-arm/bug.h
@@ -16,7 +16,6 @@ extern void __bug(const char *file, int
#endif
-#define HAVE_ARCH_BUG
#endif
#include
Index: linux-2.6.24-rc6/include/asm-avr32/bug.h
===
--- linux-2.6.24-rc6.orig/include/asm-avr32/bug.h
+++ linux-2.6.24-rc6/include/asm-avr32/bug.h
@@ -63,9 +63,6 @@
unlikely(__ret_warn_on);\
})
-#define HAVE_ARCH_BUG
-#define HAVE_ARCH_WARN_ON
-
#endif /* CONFIG_BUG */
#include
Index: linux-2.6.24-rc6/include/asm-frv/bug.h
===
--- linux-2.6.24-rc6.orig/include/asm-frv/bug.h
+++ linux-2.6.24-rc6/include/asm-frv/bug.h
@@ -32,7 +32,6 @@ do { \
asm volatile("nop");\
} while(0)
-#define HAVE_ARCH_BUG
#define BUG() \
do { \
_debug_bug_printk();\
Index: linux-2.6.24-rc6/include/asm-generic/bug.h
===
--- linux-2.6.24-rc6.orig/include/asm-generic/bug.h
+++ linux-2.6.24-rc6/include/asm-generic/bug.h
@@ -20,14 +20,14 @@ struct bug_entry {
#define BUGFLAG_WARNING(1<<0)
#endif /* CONFIG_GENERIC_BUG */
-#ifndef HAVE_ARCH_BUG
+#ifndef BUG
#define BUG() do { \
printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__,
__FUNCTION__); \
panic("BUG!"); \
} while (0)
#endif
-#ifndef HAVE_ARCH_BUG_ON
+#ifndef BUG_ON
#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
#endif
@@ -49,15 +49,15 @@ extern void warn_on_slowpath(const char
#endif
#else /* !CONFIG_BUG */
-#ifndef HAVE_ARCH_BUG
+#ifndef BUG
#define BUG()
#endif
-#ifndef HAVE_ARCH_BUG_ON
+#ifndef BUG_ON
#define BUG_ON(condition) do { if (condition) ; } while(0)
#endif
-#ifndef HAVE_ARCH_WARN_ON
+#ifndef WARN_ON
#define WARN_ON(condition) ({ \
int __ret_warn_on = !!(condition); \
unlikely(__ret_warn_on);\
Index: linux-2.6.24-rc6/include/asm-ia64/bug.h
===
--- linux-2.6.24-rc6.orig/include/asm-ia64/bug.h
+++ linux-2.6.24-rc6/include/asm-ia64/bug.h
@@ -6,7 +6,6 @@
#define BUG() do { printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__);
ia64_abort(); } while (0)
/* should this BUG be made generic? */
-#define HAVE_ARCH_BUG
#endif
#include
Index: linux-2.6.24-rc6/include/asm-m68k/bug.h
===
--- linux-2.6.24-rc6.orig/include/asm-m68k/bug.h
+++ linux-2.6.24-rc6/include/asm-m68k/bug.h
@@ -21,7 +21,6 @@
} while (0)
#endif
-#define HAVE_ARCH_BUG
#endif
#include
Index: linux-2.6.24-rc6/include/asm-mips/bug.h
===
--- linux-2.6.24-rc6.orig/include/asm-mips/bug.h
+++ linux-2.6.24-rc6/include/asm-mips/bug.h
@@ -12,8 +12,6 @@ do {
\
__asm__ __volatile__("break %0" : : "i" (BRK_BUG)); \
} while (0)
-#define HAVE_ARCH_BUG
-
#if (_MIPS_ISA > _MIPS_ISA_MIPS1)
#define BUG_ON(condition) \
[patch 5/5] PowerPC: switch to generic WARN_ON / BUG_ON
From: Olof Johansson <[EMAIL PROTECTED]>
Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about
4K text on a ppc64_defconfig. The main reason seems to be that prepping
the arguments to the conditional trap instructions is more work than just
doing a compare and branch.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Cc: Scott Wood <[EMAIL PROTECTED]>
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Cc: Paul Mackerras <[EMAIL PROTECTED]>,
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/asm-powerpc/bug.h | 37 -
1 file changed, 37 deletions(-)
Index: linux-2.6.24-rc6/include/asm-powerpc/bug.h
===
--- linux-2.6.24-rc6.orig/include/asm-powerpc/bug.h
+++ linux-2.6.24-rc6/include/asm-powerpc/bug.h
@@ -54,12 +54,6 @@
".previous\n"
#endif
-/*
- * BUG_ON() and WARN_ON() do their best to cooperate with compile-time
- * optimisations. However depending on the complexity of the condition
- * some compiler versions may not produce optimal results.
- */
-
#define BUG() do { \
__asm__ __volatile__( \
"1: twi 31,0,0\n" \
@@ -69,20 +63,6 @@
for(;;) ; \
} while (0)
-#define BUG_ON(x) do { \
- if (__builtin_constant_p(x)) { \
- if (x) \
- BUG(); \
- } else {\
- __asm__ __volatile__( \
- "1: "PPC_TLNEI" %4,0\n" \
- _EMIT_BUG_ENTRY \
- : : "i" (__FILE__), "i" (__LINE__), "i" (0),\
- "i" (sizeof(struct bug_entry)), \
- "r" ((__force long)(x))); \
- } \
-} while (0)
-
#define __WARN() do { \
__asm__ __volatile__( \
"1: twi 31,0,0\n" \
@@ -92,23 +72,6 @@
"i" (sizeof(struct bug_entry))); \
} while (0)
-#define WARN_ON(x) ({ \
- int __ret_warn_on = !!(x); \
- if (__builtin_constant_p(__ret_warn_on)) { \
- if (__ret_warn_on) \
- __WARN(); \
- } else {\
- __asm__ __volatile__( \
- "1: "PPC_TLNEI" %4,0\n" \
- _EMIT_BUG_ENTRY \
- : : "i" (__FILE__), "i" (__LINE__), \
- "i" (BUGFLAG_WARNING),\
- "i" (sizeof(struct bug_entry)), \
- "r" (__ret_warn_on)); \
- } \
- unlikely(__ret_warn_on);\
-})
-
#endif /* __ASSEMBLY __ */
#endif /* CONFIG_BUG */
--
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
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/
[patch 3/5] Add the end-of-trace marker and the module list to WARN_ON()
Subject: Add the end-of-trace marker and the module list to WARN_ON()
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
CC: Olof Johansson <[EMAIL PROTECTED]>
Unlike oopses, WARN_ON() currently does't print the loaded modules list.
This makes it harder to take action on certain bug reports. For example,
recently there were a set of WARN_ON()s reported in the mac80211 stack,
which were just signalling a driver bug. It takes then anther round trip
to the bug reporter (if he responds at all) to find out which driver
is at fault.
Another issue is that, unlike oopses, WARN_ON() doesn't currently printk
the helpful "cut here" line, nor the "end of trace" marker.
Now that WARN_ON() is out of line, the size increase due to this is
minimal and it's worth adding.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
kernel/panic.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
Index: linux-2.6.24-rc6/kernel/panic.c
===
--- linux-2.6.24-rc6.orig/kernel/panic.c
+++ linux-2.6.24-rc6/kernel/panic.c
@@ -281,6 +281,13 @@ static int init_oops_id(void)
}
late_initcall(init_oops_id);
+static void print_oops_end_marker(void)
+{
+ init_oops_id();
+ printk(KERN_WARNING "---[ end trace %016llx ]---\n",
+ (unsigned long long)oops_id);
+}
+
/*
* Called when the architecture exits its oops handler, after printing
* everything.
@@ -288,9 +295,7 @@ late_initcall(init_oops_id);
void oops_exit(void)
{
do_oops_enter_exit();
- init_oops_id();
- printk(KERN_WARNING "---[ end trace %016llx ]---\n",
- (unsigned long long)oops_id);
+ print_oops_end_marker();
}
#ifdef WANT_WARNON_SLOWPATH
@@ -298,11 +303,14 @@ void warn_on_slowpath(const char *file,
{
char function[KSYM_SYMBOL_LEN];
unsigned long caller = (unsigned long) __builtin_return_address(0);
-
sprint_symbol(function, caller);
+
+ printk(KERN_WARNING "[ cut here ]\n");
printk(KERN_WARNING "WARNING: at %s:%d %s()\n", file,
line, function);
+ print_modules();
dump_stack();
+ print_oops_end_marker();
}
EXPORT_SYMBOL(warn_on_slowpath);
#endif
--
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
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/
[patch 2/5] move WARN_ON() out of line
Subject: move WARN_ON() out of line
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
CC: Olof Johansson <[EMAIL PROTECTED]>
Acked-by: Matt Meckall <[EMAIL PROTECTED]>
A quick grep shows that there are currently 1145 instances of WARN_ON
in the kernel. Currently, WARN_ON is pretty much entirely inlined,
which makes it hard to enhance it without growing the size of the kernel
(and getting Andrew unhappy).
This patch build on top of Olof's patch that introduces __WARN,
and places the slowpath out of line. It also uses Ingo's suggestion
to not use __FUNCTION__ but to use kallsyms to do the lookup;
this saves a ton of extra space since gcc doesn't need to store the function
string twice now:
3936367 833603 624736 5394706 525112 vmlinux.before
3917508 833603 624736 5375847 520767 vmlinux-slowpath
15Kb savings...
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
include/asm-generic/bug.h | 10 +-
kernel/panic.c| 15 +++
2 files changed, 20 insertions(+), 5 deletions(-)
Index: linux-2.6.24-rc6/include/asm-generic/bug.h
===
--- linux-2.6.24-rc6.orig/include/asm-generic/bug.h
+++ linux-2.6.24-rc6/include/asm-generic/bug.h
@@ -32,11 +32,11 @@ struct bug_entry {
#endif
#ifndef __WARN
-#define __WARN() do { \
- printk("WARNING: at %s:%d %s()\n", __FILE__,\
- __LINE__, __FUNCTION__);\
- dump_stack(); \
-} while (0)
+#ifndef __ASSEMBLY__
+extern void warn_on_slowpath(const char *file, const int line);
+#define WANT_WARN_ON_SLOWPATH
+#endif
+#define __WARN() warn_on_slowpath(__FILE__, __LINE__)
#endif
#ifndef WARN_ON
Index: linux-2.6.24-rc6/kernel/panic.c
===
--- linux-2.6.24-rc6.orig/kernel/panic.c
+++ linux-2.6.24-rc6/kernel/panic.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
int panic_on_oops;
int tainted;
@@ -292,6 +293,20 @@ void oops_exit(void)
(unsigned long long)oops_id);
}
+#ifdef WANT_WARN_ON_SLOWPATH
+void warn_on_slowpath(const char *file, int line)
+{
+ char function[KSYM_SYMBOL_LEN];
+ unsigned long caller = (unsigned long) __builtin_return_address(0);
+
+ sprint_symbol(function, caller);
+ printk(KERN_WARNING "WARNING: at %s:%d %s()\n", file,
+ line, function);
+ dump_stack();
+}
+EXPORT_SYMBOL(warn_on_slowpath);
+#endif
+
#ifdef CONFIG_CC_STACKPROTECTOR
/*
* Called when gcc's -fstack-protector feature is used, and
--
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
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/
[patch 1/5] Introduce __WARN()
From: Olof Johansson <[EMAIL PROTECTED]>
Introduce __WARN() in the generic case, so the generic WARN_ON()
can use arch-specific code for when the condition is true.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/asm-generic/bug.h | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
Index: linux-2.6.24-rc6/include/asm-generic/bug.h
===
--- linux-2.6.24-rc6.orig/include/asm-generic/bug.h
+++ linux-2.6.24-rc6/include/asm-generic/bug.h
@@ -31,14 +31,19 @@ struct bug_entry {
#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
#endif
-#ifndef HAVE_ARCH_WARN_ON
+#ifndef __WARN
+#define __WARN() do { \
+ printk("WARNING: at %s:%d %s()\n", __FILE__,\
+ __LINE__, __FUNCTION__);\
+ dump_stack(); \
+} while (0)
+#endif
+
+#ifndef WARN_ON
#define WARN_ON(condition) ({ \
int __ret_warn_on = !!(condition); \
- if (unlikely(__ret_warn_on)) { \
- printk("WARNING: at %s:%d %s()\n", __FILE__,\
- __LINE__, __FUNCTION__);\
- dump_stack(); \
- } \
+ if (unlikely(__ret_warn_on))\
+ __WARN(); \
unlikely(__ret_warn_on);\
})
#endif
--
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
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/
[patch 0/5] enhance WARN_ON series
3rd try for this patch series; now with a split up patch for __WARN_ON This series has the goal of extending the usefulness of the WARN_ON() information, at least on architectures that use the generic WARN_ON() infrastructure. (Those who do their own thing either already have the extra information, or could consider switching to the generic code). In order to do that, WARN_ON() first needs to be uninlined since there's like 1200 callsites and adding code to each of those isn't pretty. As part of this, I had to split the __WARN_ON patch in -mm into 2 pieces, one to introduce __WARN_ON, and a separate one to do the ifdef cleanup. -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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: Idle loadavg of ~1, maybe MD related
On Sat, 05 Jan 2008 21:18:52 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > On Sat, 2008-01-05 at 02:04 -0800, Robin H. Johnson wrote: > > On Sat, Jan 05, 2008 at 01:30:37AM -0800, Andrew Morton wrote: > > > >From that I'd suspect that kwindfarm is being a bad citizen. > > > If a process is consistently stuck in D state, run > > Windfarm. > > It's an unfortunate artifact that kernel threads that do > non-interruptible sleep are counted as load... > > In the case of windfarm, it does a lot (a _LOT_) of accesses to various > i2c busses and the SMU (the system management unit which controls the > fans). All those are done in the form of short requests during which the > process is doing a wait_for_completion() or similar. > > I don't see a better way to do that, I think we could have good use of > something that stops counting those in the load average... Maybe, but we can usually work around it pretty comfortably. If smu_set_fan() is only ever called by a kernel thread then we can simply flip it over to using wait_for_completion_interruptible(). If smu_set_fan() is also called from user processes then things aren't so easy... -- 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] scsi: revert "[SCSI] Get rid of scsi_cmnd->done"
Linus Torvalds <[EMAIL PROTECTED]> writes: > On Wed, 2 Jan 2008, James Bottomley wrote: > > > Look at the taxonomy of the bug. This is the form of the error: > > > > buffer I/O error on device sr0, logical block 20304 > > attempt to access beyond end of device > > sr0: rw=0, want=81224, limit=40944 > > > > The last limit is the most suggestive, that comes straight from > > bdev->bd_inode->i_size>>9 and is supposed to be the size of the block > > device in 512 byte blocks. For a 4.7GB DVD, it's a little small. > > Nothing in the sr code sets this directly (although it does come from > > get_blkdev() for the first opener). pktcdvd does set it, though ... and > > probably wrongly if the drive in question isn't UDF formatted. pktcdvd sets it when opening the /dev/pktcdvd device, but when the drive is later opened as /dev/scd0, there is nothing that sets it back. (Btw, 40944 is possible if the disk is a CDRW that was formatted with "cdrwtool -m 10236".) The problem is that pktcdvd opens the cd device in non-blocking mode when pktsetup is run, and doesn't close it again until pktsetup -d is run. The effect is that if you meanwhile open the cd device, blkdev.c:do_open() doesn't call bd_set_size() because bdev->bd_openers is non-zero. I don't know the correct way to fix this. Maybe adding bd_set_size() to sr.c:get_sectorsize() which already does set_capacity() would work. > .. but you're ignoring the fact that if pktcdvd sets it wrong, then it > should be visible with the pre-commit kernel *also*. I can repeat this bug, both with and without the scsi patch that is claimed to make a difference, both with an external USB drive and an internal IDE drive. To repeat: 1. Start with an empty drive. 2. pktsetup 0 /dev/scd0 3. Insert a CD containing an isofs filesystem. 4. mount /dev/pktcdvd/0 /mnt/tmp 5. umount /mnt/tmp 6. Press the eject button. 7. Insert a DVD containing a non-writable filesystem. 8. mount /dev/scd0 /mnt/tmp 9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null 10. If the DVD contains data beyond the physical size of a CD, you get I/O errors in the terminal, and dmesg reports lots of "attempt to access beyond end of device" errors. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 -- 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: [Bluez-devel] Oops involving RFCOMM and sysfs
Hello, Al Viro. Al Viro wrote: > On Sun, Jan 06, 2008 at 11:07:52AM +0900, Tejun Heo wrote: > >> Right, I haven't thought about that. When sysfs_get_dentry() is called, >> @sd is always valid so unless there was existing negative dentry, lookup >> is guaranteed to return positive dentry, but by populating dcache with >> negative dentry before a node is created, things can go wrong. I don't >> think that's what's going on here tho. If that was the case, the >> while() loop looking up the next sd to lookup (@cur) should have blown >> up as negative dentry will have NULL d_fsdata which doesn't match any sd. > > No. What happens if sd gets unlinked while we are on the way to > sysfs_get_dentry() and so does its parent? That means sysfs_remove_dir() is called on parent while other operations are in progress on children, right? sysfs has never allowed such things && AFAIK no one does that. It's somewhat implied in the interface (such as recursive removing) but I fully agree it's problematic. Things like these are why I think we need to unify/simplify locking as I wrote previously. > The parent is off the > sibling list, we get negative dentry from lookup. It's not hashed, > so won't stick around in dcache (which is apparently what you are > thinking about). However, _THIS_ lookup has returned you a dentry > with NULL ->d_inode and you are well and truly buggered. So, the assumption is that while @sd is held and being operated on its ancestry can never change except for rename and move and those are protected with sysfs_rename_mutex. I agree that the locking is awkward but sysfs's internal implementation has completely changed over last six or so months and the conversion still isn't complete. It isn't pretty at all but is at least understandable now, IMHO. :-) The last pending change is separating out kobject from sysfs and simplifying locking. I had some disagreement with Greg about the future of kobject and then there was tsunami of ATA bugs because most major distros converted to libata from IDE in the second half of the last year and I'm still buried under it. I'll get back to sysfs once these ATA bugs subside a bit. Thanks. -- tejun -- 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: kexec refuses to boot latest -mm
On Fri, 4 Jan 2008 21:24:15 +0530 Dhaval Giani <[EMAIL PROTECTED]> wrote: > On Fri, Jan 04, 2008 at 05:58:16PM +0530, Dhaval Giani wrote: > > On Thu, Jan 03, 2008 at 10:42:00PM +0100, Rafael J. Wysocki wrote: > > > On Thursday, 3 of January 2008, Dhaval Giani wrote: > > > > On Mon, Dec 31, 2007 at 10:08:43AM -0500, Vivek Goyal wrote: > > > > > On Sat, Dec 29, 2007 at 11:11:13AM +0530, Dhaval Giani wrote: > > > > > > On Fri, Dec 28, 2007 at 09:27:39AM -0500, Vivek Goyal wrote: > > > > > > > On Fri, Dec 28, 2007 at 06:15:32PM +0530, Dhaval Giani wrote: > > > > > > > > Hi Vivek, > > > > > > > > > > > > I've no clue what I managed to do wrong last night, probably tried to boot > > 2.6.24-rc6-mm1 thinking it was 2.6.24-rc6. 2.6.24-rc6 boots, but -mm > > does not. Sorry for the noise. > > > > So I went ahead and bisected -mm, and the culprit is git-x86. It boots > fine before it, but with git-x86 applied, it fails to boot. > > Ingo/Thomas, could you please point me to the git-x86 tree so that I can > bisect it? Every git-foo.patch in -mm identifies where it came from in its changelog. The first few lines of ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/broken-out/git-x86.patch are: GIT 27197ba67cbaa0e22598a10c82b10dacb1309ed8 irqs_disabled git+ssh://master.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git#mm I'm not sure what the "irqs_disabled\n\n" is doing there: maybe I added it by mistake. 2.6.24-rc5-mm1 correctly had GIT b668e28b74558b3a8277b5fde363ae5f803b36f0 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git#mm But still. The git URL is always there. -- 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: [Bluez-devel] Oops involving RFCOMM and sysfs
On Sun, Jan 06, 2008 at 11:07:52AM +0900, Tejun Heo wrote: > Right, I haven't thought about that. When sysfs_get_dentry() is called, > @sd is always valid so unless there was existing negative dentry, lookup > is guaranteed to return positive dentry, but by populating dcache with > negative dentry before a node is created, things can go wrong. I don't > think that's what's going on here tho. If that was the case, the > while() loop looking up the next sd to lookup (@cur) should have blown > up as negative dentry will have NULL d_fsdata which doesn't match any sd. No. What happens if sd gets unlinked while we are on the way to sysfs_get_dentry() and so does its parent? The parent is off the sibling list, we get negative dentry from lookup. It's not hashed, so won't stick around in dcache (which is apparently what you are thinking about). However, _THIS_ lookup has returned you a dentry with NULL ->d_inode and you are well and truly buggered. -- 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: acpi/apm events as inputs: how to handle?
Hi Michael, On Wednesday 02 January 2008, Michael Tokarev wrote: > What I'm thinking about is: why ACPI events are > routed over input subsystem, instead of hotplug > subsystem? With input, there's a need for a > special daemon/application listening on the > specific "keyboard" device, while with hotplug > subsystem, it's already here - linux (by default > anyway, if not running udev etc), kernel fires > up a script when an event occurs. I don't see > how this special application/daemon is different > from ol'good acpid. There are keyboards (USB, PS2) with Sleep and Suspend buttons that are not related to ACPI nor APM. We had 2 options - add an input handler that would translate input events into ACPI events and feed /proc/acpi/event[*] or go other way around and use input layer for delivering suspend and sleep requests for all types of keyboards/buttons, including ACPI buttons. The secons option is better because userspace solution using input layer will not be tied to a particular technology (ACPI) and can be used on other platforms as well. -- Dmitry [*] Embedded people are not particularly interested in processing suspend requests in userspace and would rather do it right in the kernel. I am about to apply a patch from Richard Purdie that adds transaltion from input events into APM events. -- 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: [Bluez-devel] Oops involving RFCOMM and sysfs
Hello, Al Viro wrote: > On Sat, Jan 05, 2008 at 11:30:25PM +0900, Tejun Heo wrote: >>> Assuming that this is what we get, everything looks explainable - we >>> have sysfs_rename_dir() calling sysfs_get_dentry() while the parent >>> gets evicted. We don't have any exclusion, so while we are playing >>> silly buggers with lookups in sysfs_get_dentry() we have parent become >>> negative; the rest is obvious... >> That part of code is walking down the sysfs tree from the s_root of >> sysfs hierarchy and on each step parent is held using dget() while being >> referenced, so I don't think they can turn negative there. > > Turn? Just what stops you from getting a negative (and unhashed) from > lookup_one_noperm() and on the next iteration being buggered on mutex_lock()? Right, I haven't thought about that. When sysfs_get_dentry() is called, @sd is always valid so unless there was existing negative dentry, lookup is guaranteed to return positive dentry, but by populating dcache with negative dentry before a node is created, things can go wrong. I don't think that's what's going on here tho. If that was the case, the while() loop looking up the next sd to lookup (@cur) should have blown up as negative dentry will have NULL d_fsdata which doesn't match any sd. I guess what's needed here is d_revalidate() as other distributed filesystems do. I'll test whether this can be actually triggered and prepare a fix. Thanks a lot for pointing out the problem. >>> AFAICS, the locking here is quite broken and frankly, sysfs_get_dentry() >>> and the way it plays with fs/namei.c are ucking fugly. >> Can you elaborate a bit? The locking in sysfs is unconventional but >> that's mostly from necessity. It has dual interface - vfs and driver >> model && vfs data structures (dentry and inode) are too big to always >> keep around, so it basically becomes a small distributed file system >> where the backing data can change asynchronously. > > ... with all fun that creates. As it is, you have those async changers > of backing data using VFS locking _under_ sysfs locks via lookup_one_noperm() > and yet it needs sysfs_mutex inside sysfs_lookup(). So you can't have > sysfs_get_dentry() under it. So you don't have exclusion with arseloads > of sysfs tree changes in there. Joy... There are two locks. sysfs_rename_mutex and sysfs_mutex. sysfs_rename_mutex is above VFS locks while sysfs_mutex is below VFS locks. sysfs_rename_mutex() protects against move/rename which can change the ancestry of a held sysfs_dirent while sysfs_mutex protects the sd hierarchy itself. Locking can be wrong if sysfs_rename_mutex locking is missing from the places where ancestry of a held sd can change but I can't find one ATM. If I'm missing your point again, feel free to scream at me. :-) As it's unnecessarily unintuitive, there's a pending change to rename sysfs_rename_mutex and use it to protect the whole tree structure to make locking simpler while using sysfs_mutex to guard VFS access such that the locking hierarchy plainly becomes sysfs_rename_mutex - VFS locks - sysfs_mutex where all internal sysfs structure is protected by the outer mutex and the inner one just protects VFS accesses. > Frankly, with the current state of sysfs the last vestiges of arguments > used to push it into the tree back then are dead and buried. I'm not > blaming you, BTW - the shitpile *did* grow past the point where its > memory footprint became far too large and something needed to be done. > Unfortunately, it happened too late for that something being "get rid > of the entire mess" and now we are saddled with it for good. Yeah, it's too late to get rid of sysfs and regardless implementation ugliness, which BTW I think has improved a lot during last six or so months, it's now pretty useful and important to drivers, so I guess the only option is trying hard to make it better. Oh, BTW, the ugly lookup_one_noperm() can be removed if LOOKUP_NOPERM flag is added. The only reason sysfs_lookup() uses the specialized lookup is to avoid permission check. Thanks. -- tejun -- 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: sparc oops in ip_fast_csum
On Sun, Jan 06, 2008 at 11:22:04AM +1100, Herbert Xu wrote: > Actually if you read the code for ip_fast_csum it's obvious what has > happened. %o1 == iph->ihl contains the value 2 which is bogus. > > [IPV4] raw: Strengthen check on validity of iph->ihl > > We currently check that iph->ihl is bounded by the real length and that > the real length is greater than the minimum IP header length. However, > we did not check the caes where iph->ihl is less than the minimum IP > header length. > > This breaks because some ip_fast_csum implementations assume that which > is quite reasonable. Humm... Point, but that makes me wonder what other callers do... E.g. what about ipt_REJECT.c::send_reset()? Or myri10ge_get_frag_header()? -- 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: Oops in evdev_disconnect for kernel 2.6.23.12
Hi. Berthold Cogel wrote: > Al Viro schrieb: >> On Tue, Jan 01, 2008 at 08:26:05PM +0100, Berthold Cogel wrote: >> >>> Jan 1 17:34:39 wonderland kernel: BUG: unable to handle kernel >>> paging request at virtual address 00100100 >> >> LIST_POISON1 >> >>> Jan 1 17:34:39 wonderland kernel: EIP is at evdev_disconnect+0x65/0x9e >> >> and by the look of code, it's a bit before the call of something that >> gets >> 0x20006 as one of its arguments. Which, by the look of evdev.s, gets >> passed only to kill_fasync(). So it's POLL_HUP, so this code could be >> these days: >> spin_lock(>client_lock); >> list_for_each_entry(client, >client_list, node) >> kill_fasync(>fasync, SIGIO, POLL_HUP); >> spin_unlock(>client_lock); >> in evdev_hangup() >> prior to commit 6addb1d6de1968b84852f54561cc9a09b5a9: >> list_for_each_entry(client, >client_list, node) >> kill_fasync(>fasync, SIGIO, POLL_HUP); >> in evdev_disconnect() >> >> >>> I'm using Debian stable/testing/unstable with homemade kernel >>> 2.6.23.12 (patched with tuxonice-3.0-rc3-for-2.6.23.9). >> >> ... and seeing that this changeset postdates 2.6.23 *and* adds locking to >> the lists we are traversing in either variant, I'd bet that the kernel >> you >> have does *NOT* have the changeset in question, that you have list >> corruption >> from race and that your oops is list_for_each_entry() trying to walk >> forward from entry that just had list_del() poisoning its ->next. >> >> There are only 4 changesets between 2.6.23 and this one affecting >> drivers/input >> and only >> 8006479c9b75fb6594a7b746af3d7f1fbb68f18f and >> 6addb1d6de1968b84852f54561cc9a09b5a9 >> appear to be relevant. Apply to your kernel and see if it helps... > > Looks as if I have to start using git ... I always feared that this day > will come. ;-) > > If I'm able to reproduce the oops with my patched kernel, I will gladly > follow your advice. > > Regards, > > Berthold I can't do it immediately but I'll send you the patches to try a later in the day if you like. Nigel -- 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/
init wont start on VIA EPIA 5000 500mhz board and randomely wont start on VIA EPIA MII 10000
I have been trying to figure this out a while now with printk's all over my
kernel as well as adding kdb and tracing the int3 events.
I have tried various 2.6 kernels and so far all i have tried do this.
My current tests are on 2.6.22.10
I have a simple init binary I compiled static that is my init that is loaded
into an init file system. I am not using cpio but that did not seem to matter.
begin testinit.c
#include
#include
int main(int argc, char *argv[])
{
printf("Hello world!\n");
sleep(9);
}
end
I am using syslunux to start my kernel and appending the follwiing startup
command most of this is specific to my true init script but again im using a
"hello world" script to debug this for now.
append debug kidb=early console=ttyS0,384008n initrd=ufoinit.img
init=/testinit rw var_size=12M tmp_size=MAX log_size=16M root_size=64M
root=/dev/ram0 boot=/dev/hda1,msdos rw pkgpath=/dev/hda1:msdos rw verbose
DELAY=0 TEST=0 DEBUG=0 VERBOSE=0 UFO=root,etc,modules
On an intel CA810EEA 800mhz board or QEMU this runs fine but on the via boards
it dies right after "Freeing unused kernel memory: 132k freed"
on the 500mhz board it dies every time on the 800mhz it is random.
I have noticed that i get the elf binarly loading into user space with some
page_faults then I get blasted with do_notify_resume with 0x04 or
TIF_SIGPENDING over and over as if its in an infinite loop.
This begins shortly after load_elf_binary -> clear_user i think right after a
page_fault during the clear_user. I dont even know why that signal is being
sent on other hardware it never happens.
I am not even sure what do try next.
I have been trying to get my distro up on 2.6 for a while now and away from
2.4 but im currently stuck here.
Any and all suggestions and help welcome..
my kernel config is here
http://pastebin.cross-lfs.org/4561
Thanks in advance..
Regards
Sean Mathews
struct SoftwareProfessional {
double salary;
long lunches;
float jobs;
char unstable;
void work;
short tempers;
};
Sent via the WebMail system at mail.nutech.com
--
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.24-rc6-mm1
On Sat, 5 Jan 2008 23:10:17 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> On Jan 5, 2008 3:52 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> > On Jan 5, 2008 11:13 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > > On Sat, Jan 05, 2008 at 09:01:02AM +0100, Torsten Kaiser wrote:
> > > > On Jan 5, 2008 1:07 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > > > > I think it would be easier just to start with this working -rc6 and
> > > > > simply check if we have 'right' suspects, so: git-net.patch and
> > > > > git-nfsd.patch from -mm1-broken-out, as suggested by Herbert (I hope,
> > > > > can compile - otherwise you could try the other way: add the whole -mm
> > > > > and revert these two). Using current gits could complicate this
> > > > > "investigation".
> > > >
> > > > OK, I will try this...
> >
> > still on the todo-list, I had no time to try this yet...
>
> working on it...
> 2.6.24-rc6 + mm-patches up to git.battery (includes git-net and
> git-netdev-all) worked for 110 packages, then I proclaimed it good.
> 2.6.24-rc6 + mm-patches up to (including) git.nfsd is currently
> getting testet (9 packages done...)
>
> But the cause of my mail is the following question:
> Regarding my "iommu-sg-merging-patches are new in -rc3-mm and could be
> the cause"-suspicion I looked at these patches and came across these
> hunks:
>
> This is removed from arch/x86/lib/bitstr_64.c:
> -/* Find string of zero bits in a bitmap */
> -unsigned long
> -find_next_zero_string(unsigned long *bitmap, long start, long nbits, int len)
> -{
> - unsigned long n, end, i;
> -
> - again:
> - n = find_next_zero_bit(bitmap, nbits, start);
> - if (n == -1)
> - return -1;
> -
> - /* could test bitsliced, but it's hardly worth it */
> - end = n+len;
> - if (end > nbits)
> - return -1;
> - for (i = n+1; i < end; i++) {
> - if (test_bit(i, bitmap)) {
> - start = i+1;
> - goto again;
> - }
> - }
> - return n;
> -}
>
> This is added to lib/iommu-helper.c:
> +static unsigned long find_next_zero_area(unsigned long *map,
> +unsigned long size,
> +unsigned long start,
> +unsigned int nr)
> +{
> + unsigned long index, end, i;
> +again:
> + index = find_next_zero_bit(map, size, start);
> + end = index + nr;
> + if (end > size)
> + return -1;
> + for (i = index + 1; i < end; i++) {
> + if (test_bit(i, map)) {
> + start = i+1;
> + goto again;
> + }
> + }
> + return index;
> +}
>
> The old version checks, if find_next_zero_bit returns -1, the new
> version doesn't do this.
> Is this intended and can find_next_zero_bit never fail?
> Hmm... but in the worst case it should only loop forever if I'm
> reading this right (index = -1 => for-loop counts from 0 to nr, if any
> bit is set it will jump to "again:" and if the next call to
> find_next_zero_bit also fails, its an endless loop)
I susect these are doing different things.
iommu-sg-kill-__clear_bit_string-and-find_next_zero_string.patch says:
This kills unused __clear_bit_string and find_next_zero_string (they
were used by only gart and calgary IOMMUs).
iommu-sg-add-iommu-helper-functions-for-the-free-area-management.patch says:
This adds IOMMU helper functions for the free area management. These
functions take care of LLD's segment boundary limit for IOMMUs. They
would be useful for IOMMUs that use bitmap for the free area management.
> So even if this can not explain my bug, could somebody check if this
> is a real bug or not?
Let's cc the author of those changes.
Thanks for persisting with this bug.
--
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/
[PATCH 5/7] udf: convert byte order of constant instead of variable
convert byte order of constant instead of variable,
which can be done at compile time (vs run time)
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
---
fs/udf/directory.c |4 ++--
fs/udf/inode.c | 16
fs/udf/misc.c | 12 ++--
fs/udf/super.c | 16
4 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/fs/udf/directory.c b/fs/udf/directory.c
index d4ae723..598bcf7 100644
--- a/fs/udf/directory.c
+++ b/fs/udf/directory.c
@@ -225,7 +225,7 @@ struct fileIdentDesc *udf_get_fileident(void *buffer, int
bufsize, int *offset)
if ((*offset > 0) && (*offset < bufsize))
ptr += *offset;
fi = (struct fileIdentDesc *)ptr;
- if (le16_to_cpu(fi->descTag.tagIdent) != TAG_IDENT_FID) {
+ if (fi->descTag.tagIdent != cpu_to_le16(TAG_IDENT_FID)) {
udf_debug("0x%x != TAG_IDENT_FID\n",
le16_to_cpu(fi->descTag.tagIdent));
udf_debug("offset: %u sizeof: %lu bufsize: %u\n",
@@ -262,7 +262,7 @@ static extent_ad *udf_get_fileextent(void *buffer, int
bufsize, int *offset)
fe = (struct fileEntry *)buffer;
- if (le16_to_cpu(fe->descTag.tagIdent) != TAG_IDENT_FE) {
+ if (fe->descTag.tagIdent != cpu_to_le16(TAG_IDENT_FE)) {
udf_debug("0x%x != TAG_IDENT_FE\n",
le16_to_cpu(fe->descTag.tagIdent));
return NULL;
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 6751945..bb73635 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1103,7 +1103,7 @@ static void __udf_read_inode(struct inode *inode)
fe = (struct fileEntry *)bh->b_data;
- if (le16_to_cpu(fe->icbTag.strategyType) == 4096) {
+ if (fe->icbTag.strategyType == cpu_to_le16(4096)) {
struct buffer_head *ibh = NULL, *nbh = NULL;
struct indirectEntry *ie;
@@ -1140,7 +1140,7 @@ static void __udf_read_inode(struct inode *inode)
} else {
brelse(ibh);
}
- } else if (le16_to_cpu(fe->icbTag.strategyType) != 4) {
+ } else if (fe->icbTag.strategyType != cpu_to_le16(4)) {
printk(KERN_ERR "udf: unsupported strategy type: %d\n",
le16_to_cpu(fe->icbTag.strategyType));
brelse(bh);
@@ -1164,9 +1164,9 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
fe = (struct fileEntry *)bh->b_data;
efe = (struct extendedFileEntry *)bh->b_data;
- if (le16_to_cpu(fe->icbTag.strategyType) == 4)
+ if (fe->icbTag.strategyType == cpu_to_le16(4))
UDF_I_STRAT4096(inode) = 0;
- else /* if (le16_to_cpu(fe->icbTag.strategyType) == 4096) */
+ else /* if (fe->icbTag.strategyType == cpu_to_le16(4096)) */
UDF_I_STRAT4096(inode) = 1;
UDF_I_ALLOCTYPE(inode) = le16_to_cpu(fe->icbTag.flags) &
@@ -1177,7 +1177,7 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
UDF_I_LENALLOC(inode) = 0;
UDF_I_NEXT_ALLOC_BLOCK(inode) = 0;
UDF_I_NEXT_ALLOC_GOAL(inode) = 0;
- if (le16_to_cpu(fe->descTag.tagIdent) == TAG_IDENT_EFE) {
+ if (fe->descTag.tagIdent == cpu_to_le16(TAG_IDENT_EFE)) {
UDF_I_EFE(inode) = 1;
UDF_I_USE(inode) = 0;
if (udf_alloc_i_data(inode, inode->i_sb->s_blocksize -
@@ -1189,7 +1189,7 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
bh->b_data + sizeof(struct extendedFileEntry),
inode->i_sb->s_blocksize -
sizeof(struct extendedFileEntry));
- } else if (le16_to_cpu(fe->descTag.tagIdent) == TAG_IDENT_FE) {
+ } else if (fe->descTag.tagIdent == cpu_to_le16(TAG_IDENT_FE)) {
UDF_I_EFE(inode) = 0;
UDF_I_USE(inode) = 0;
if (udf_alloc_i_data(inode, inode->i_sb->s_blocksize -
@@ -1199,7 +1199,7 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
}
memcpy(UDF_I_DATA(inode), bh->b_data + sizeof(struct fileEntry),
inode->i_sb->s_blocksize - sizeof(struct fileEntry));
- } else if (le16_to_cpu(fe->descTag.tagIdent) == TAG_IDENT_USE) {
+ } else if (fe->descTag.tagIdent == cpu_to_le16(TAG_IDENT_USE)) {
UDF_I_EFE(inode) = 0;
UDF_I_USE(inode) = 1;
UDF_I_LENALLOC(inode) = le32_to_cpu(
@@ -1458,7 +1458,7 @@ static int udf_update_inode(struct inode *inode, int
do_sync)
fe = (struct fileEntry *)bh->b_data;
efe = (struct extendedFileEntry *)bh->b_data;
- if (le16_to_cpu(fe->descTag.tagIdent) == TAG_IDENT_USE) {
+ if (fe->descTag.tagIdent == cpu_to_le16(TAG_IDENT_USE)) {
struct unallocSpaceEntry *use =
(struct unallocSpaceEntry
[PATCH 4/7] udf: replace loops coded with goto to real loops
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
---
fs/udf/balloc.c | 309 ---
1 files changed, 157 insertions(+), 152 deletions(-)
diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
index d1d4b8f..5ce7926 100644
--- a/fs/udf/balloc.c
+++ b/fs/udf/balloc.c
@@ -183,46 +183,46 @@ static void udf_bitmap_free_blocks(struct super_block *sb,
block = bloc.logicalBlockNum + offset +
(sizeof(struct spaceBitmapDesc) << 3);
-do_more:
- overflow = 0;
- block_group = block >> (sb->s_blocksize_bits + 3);
- bit = block % (sb->s_blocksize << 3);
+ do {
+ overflow = 0;
+ block_group = block >> (sb->s_blocksize_bits + 3);
+ bit = block % (sb->s_blocksize << 3);
- /*
-* Check to see if we are freeing blocks across a group boundary.
-*/
- if (bit + count > (sb->s_blocksize << 3)) {
- overflow = bit + count - (sb->s_blocksize << 3);
- count -= overflow;
- }
- bitmap_nr = load_block_bitmap(sb, bitmap, block_group);
- if (bitmap_nr < 0)
- goto error_return;
+ /*
+ * Check to see if we are freeing blocks across a group boundary.
+ */
+ if (bit + count > (sb->s_blocksize << 3)) {
+ overflow = bit + count - (sb->s_blocksize << 3);
+ count -= overflow;
+ }
+ bitmap_nr = load_block_bitmap(sb, bitmap, block_group);
+ if (bitmap_nr < 0)
+ goto error_return;
- bh = bitmap->s_block_bitmap[bitmap_nr];
- for (i = 0; i < count; i++) {
- if (udf_set_bit(bit + i, bh->b_data)) {
- udf_debug("bit %ld already set\n", bit + i);
- udf_debug("byte=%2x\n",
- ((char *)bh->b_data)[(bit + i) >> 3]);
- } else {
- if (inode)
- DQUOT_FREE_BLOCK(inode, 1);
- udf_inc_free_space(sbi, sbi->s_partition, 1);
+ bh = bitmap->s_block_bitmap[bitmap_nr];
+ for (i = 0; i < count; i++) {
+ if (udf_set_bit(bit + i, bh->b_data)) {
+ udf_debug("bit %ld already set\n", bit + i);
+ udf_debug("byte=%2x\n",
+ ((char *)bh->b_data)[(bit + i) >> 3]);
+ } else {
+ if (inode)
+ DQUOT_FREE_BLOCK(inode, 1);
+ udf_inc_free_space(sbi, sbi->s_partition, 1);
+ }
}
- }
- mark_buffer_dirty(bh);
- if (overflow) {
- block += count;
- count = overflow;
- goto do_more;
- }
+ mark_buffer_dirty(bh);
+ if (overflow) {
+ block += count;
+ count = overflow;
+ }
+ } while (overflow);
+
error_return:
sb->s_dirt = 1;
if (sbi->s_lvid_bh)
mark_buffer_dirty(sbi->s_lvid_bh);
mutex_unlock(>s_alloc_mutex);
- return;
}
static int udf_bitmap_prealloc_blocks(struct super_block *sb,
@@ -246,39 +246,40 @@ static int udf_bitmap_prealloc_blocks(struct super_block
*sb,
if (first_block + block_count > part_len)
block_count = part_len - first_block;
-repeat:
- nr_groups = (sbi->s_partmaps[partition].s_partition_len +
-(sizeof(struct spaceBitmapDesc) << 3) +
-(sb->s_blocksize * 8) - 1) / (sb->s_blocksize * 8);
- block = first_block + (sizeof(struct spaceBitmapDesc) << 3);
- block_group = block >> (sb->s_blocksize_bits + 3);
- group_start = block_group ? 0 : sizeof(struct spaceBitmapDesc);
+ do {
+ nr_groups = (sbi->s_partmaps[partition].s_partition_len +
+ (sizeof(struct spaceBitmapDesc) << 3) +
+ (sb->s_blocksize * 8) - 1) / (sb->s_blocksize * 8);
+ block = first_block + (sizeof(struct spaceBitmapDesc) << 3);
+ block_group = block >> (sb->s_blocksize_bits + 3);
+ group_start = block_group ? 0 : sizeof(struct spaceBitmapDesc);
- bitmap_nr = load_block_bitmap(sb, bitmap, block_group);
- if (bitmap_nr < 0)
- goto out;
- bh = bitmap->s_block_bitmap[bitmap_nr];
+ bitmap_nr = load_block_bitmap(sb, bitmap, block_group);
+ if (bitmap_nr < 0)
+ goto out;
+ bh = bitmap->s_block_bitmap[bitmap_nr];
- bit = block % (sb->s_blocksize << 3);
+ bit = block % (sb->s_blocksize << 3);
- while (bit < (sb->s_blocksize << 3) &&
[PATCH 3/7] udf: create common function for changing free space counter
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
---
fs/udf/balloc.c | 49 -
1 files changed, 20 insertions(+), 29 deletions(-)
diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
index 17b67dc..d1d4b8f 100644
--- a/fs/udf/balloc.c
+++ b/fs/udf/balloc.c
@@ -140,6 +140,20 @@ static inline int load_block_bitmap(struct super_block *sb,
return slot;
}
+static inline bool udf_inc_free_space(struct udf_sb_info *sbi,
+ u16 partition, u32 cnt)
+{
+ if (sbi->s_lvid_bh) {
+ struct logicalVolIntegrityDesc *lvid =
+ (struct logicalVolIntegrityDesc *)
+ sbi->s_lvid_bh->b_data;
+ lvid->freeSpaceTable[partition] =
+ cpu_to_le32(le32_to_cpu(
+ lvid->freeSpaceTable[partition]) + cnt);
+ }
+ return sbi->s_lvid_bh != NULL;
+}
+
static void udf_bitmap_free_blocks(struct super_block *sb,
struct inode *inode,
struct udf_bitmap *bitmap,
@@ -194,11 +208,7 @@ do_more:
} else {
if (inode)
DQUOT_FREE_BLOCK(inode, 1);
- if (sbi->s_lvid_bh) {
- struct logicalVolIntegrityDesc *lvid = (struct
logicalVolIntegrityDesc *)sbi->s_lvid_bh->b_data;
- lvid->freeSpaceTable[sbi->s_partition] =
-
cpu_to_le32(le32_to_cpu(lvid->freeSpaceTable[sbi->s_partition]) + 1);
- }
+ udf_inc_free_space(sbi, sbi->s_partition, 1);
}
}
mark_buffer_dirty(bh);
@@ -270,12 +280,8 @@ repeat:
if (block_count > 0)
goto repeat;
out:
- if (sbi->s_lvid_bh) {
- struct logicalVolIntegrityDesc *lvid = (struct
logicalVolIntegrityDesc *)sbi->s_lvid_bh->b_data;
- lvid->freeSpaceTable[partition] =
-
cpu_to_le32(le32_to_cpu(lvid->freeSpaceTable[partition]) - alloc_count);
+ if (udf_inc_free_space(sbi, partition, -alloc_count))
mark_buffer_dirty(sbi->s_lvid_bh);
- }
sb->s_dirt = 1;
mutex_unlock(>s_alloc_mutex);
return alloc_count;
@@ -406,12 +412,8 @@ got_block:
mark_buffer_dirty(bh);
- if (sbi->s_lvid_bh) {
- struct logicalVolIntegrityDesc *lvid = (struct
logicalVolIntegrityDesc *)sbi->s_lvid_bh->b_data;
- lvid->freeSpaceTable[partition] =
-
cpu_to_le32(le32_to_cpu(lvid->freeSpaceTable[partition]) - 1);
+ if (udf_inc_free_space(sbi, partition, -1))
mark_buffer_dirty(sbi->s_lvid_bh);
- }
sb->s_dirt = 1;
mutex_unlock(>s_alloc_mutex);
*err = 0;
@@ -452,12 +454,8 @@ static void udf_table_free_blocks(struct super_block *sb,
could occure, but.. oh well */
if (inode)
DQUOT_FREE_BLOCK(inode, count);
- if (sbi->s_lvid_bh) {
- struct logicalVolIntegrityDesc *lvid = (struct
logicalVolIntegrityDesc *)sbi->s_lvid_bh->b_data;
- lvid->freeSpaceTable[sbi->s_partition] =
-
cpu_to_le32(le32_to_cpu(lvid->freeSpaceTable[sbi->s_partition]) + count);
+ if (udf_inc_free_space(sbi, sbi->s_partition, count))
mark_buffer_dirty(sbi->s_lvid_bh);
- }
start = bloc.logicalBlockNum + offset;
end = bloc.logicalBlockNum + offset + count - 1;
@@ -721,10 +719,7 @@ static int udf_table_prealloc_blocks(struct super_block
*sb,
brelse(epos.bh);
- if (alloc_count && sbi->s_lvid_bh) {
- struct logicalVolIntegrityDesc *lvid = (struct
logicalVolIntegrityDesc *)sbi->s_lvid_bh->b_data;
- lvid->freeSpaceTable[partition] =
-
cpu_to_le32(le32_to_cpu(lvid->freeSpaceTable[partition]) - alloc_count);
+ if (alloc_count && udf_inc_free_space(sbi, partition, -alloc_count)) {
mark_buffer_dirty(sbi->s_lvid_bh);
sb->s_dirt = 1;
}
@@ -824,12 +819,8 @@ static int udf_table_new_block(struct super_block *sb,
udf_delete_aext(table, goal_epos, goal_eloc, goal_elen);
brelse(goal_epos.bh);
- if (sbi->s_lvid_bh) {
- struct logicalVolIntegrityDesc *lvid = (struct
logicalVolIntegrityDesc *)sbi->s_lvid_bh->b_data;
- lvid->freeSpaceTable[partition] =
-
cpu_to_le32(le32_to_cpu(lvid->freeSpaceTable[partition]) - 1);
+ if (udf_inc_free_space(sbi, partition, -1))
mark_buffer_dirty(sbi->s_lvid_bh);
- }
sb->s_dirt = 1;
mutex_unlock(>s_alloc_mutex);
--
1.5.3.7
--
To unsubscribe from this list: send the
Re: [PATCH] x86: ioport_{32|64}.c unification
I just realize that in some cases 'regs->flags' is a long instead of an
unsigned long so... this would be a proper solution?
static long do_iopl(unsigned int level, long *flags)
{
...
}
#ifdef CONFIG_X86_32
asmlinkage long sys_iopl(unsigned long regsp)
{
volatile struct pt_regs *regs = (struct pt_regs *)
unsigned int level = regs->bx;
#else
asmlinkage long sys_iopl(unsigned int level, struct pt_regs *regs)
{
#endif
return do_iopl(level, (long *)>flags);
}
Or maybe would be better if 'do_iopl' prototype is:
static long do_iopl(unsigned int level, struct pt_regs *regs);
--
Miguel Botón
--
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/
[PATCH 0/7] udf: more cleanups
Hi This patchset contains various UDF fs cleanups. [PATCH 1/7] udf: fix coding style This is really big (~170kB) and boring (style cleanup) patch, so I'm not sending it to LKML. You can find it here: http://www.kadu.net/~joi/kernel/2008.01.06/0001-udf-fix-coding-style.patch [PATCH 2/7] udf: create common function for tag checksumming [PATCH 3/7] udf: create common function for changing free space counter [PATCH 4/7] udf: replace loops coded with goto to real loops [PATCH 5/7] udf: convert byte order of constant instead of variable [PATCH 6/7] udf: remove UDF_I_* macros and open code them This is preparation for 7th patch. [PATCH 7/7] udf: cache struct udf_inode_info Patchset depends on udf patches in -mm and this: http://lkml.org/lkml/2008/1/5/196 (Runtime tested: mount, open, read, seek, close, umount) Marcin Slusarz -- 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/
[PATCH 2/7] udf: create common function for tag checksumming
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
---
fs/udf/inode.c | 15 ++-
fs/udf/misc.c| 24 +++-
fs/udf/namei.c |9 +
fs/udf/super.c | 16 ++--
fs/udf/udfdecl.h | 12
5 files changed, 20 insertions(+), 56 deletions(-)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 9adde18..6751945 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1440,7 +1440,6 @@ static int udf_update_inode(struct inode *inode, int
do_sync)
uint32_t udfperms;
uint16_t icbflags;
uint16_t crclen;
- int i;
kernel_timestamp cpu_time;
int err = 0;
struct udf_sb_info *sbi = UDF_SB(inode->i_sb);
@@ -1476,12 +1475,7 @@ static int udf_update_inode(struct inode *inode, int
do_sync)
use->descTag.descCRC = cpu_to_le16(udf_crc((char *)use +
sizeof(tag), crclen,
0));
-
- use->descTag.tagChecksum = 0;
- for (i = 0; i < 16; i++)
- if (i != 4)
- use->descTag.tagChecksum +=
- ((uint8_t *)&(use->descTag))[i];
+ use->descTag.tagChecksum = udf_tag_checksum(>descTag);
mark_buffer_dirty(bh);
brelse(bh);
@@ -1650,12 +1644,7 @@ static int udf_update_inode(struct inode *inode, int
do_sync)
fe->descTag.descCRCLength = cpu_to_le16(crclen);
fe->descTag.descCRC = cpu_to_le16(udf_crc((char *)fe + sizeof(tag),
crclen, 0));
-
- fe->descTag.tagChecksum = 0;
- for (i = 0; i < 16; i++)
- if (i != 4)
- fe->descTag.tagChecksum +=
- ((uint8_t *)&(fe->descTag))[i];
+ fe->descTag.tagChecksum = udf_tag_checksum(>descTag);
/* write the data blocks */
mark_buffer_dirty(bh);
diff --git a/fs/udf/misc.c b/fs/udf/misc.c
index a0bf415..badc8de 100644
--- a/fs/udf/misc.c
+++ b/fs/udf/misc.c
@@ -51,7 +51,6 @@ struct genericFormat *udf_add_extendedattr(struct inode
*inode, uint32_t size,
uint8_t *ea = NULL, *ad = NULL;
int offset;
uint16_t crclen;
- int i;
ea = UDF_I_DATA(inode);
if (UDF_I_LENEATTR(inode)) {
@@ -138,11 +137,7 @@ struct genericFormat *udf_add_extendedattr(struct inode
*inode, uint32_t size,
eahd->descTag.descCRCLength = cpu_to_le16(crclen);
eahd->descTag.descCRC = cpu_to_le16(udf_crc((char *)eahd +
sizeof(tag), crclen, 0));
- eahd->descTag.tagChecksum = 0;
- for (i = 0; i < 16; i++)
- if (i != 4)
- eahd->descTag.tagChecksum +=
- ((uint8_t *)&(eahd->descTag))[i];
+ eahd->descTag.tagChecksum = udf_tag_checksum(>descTag);
UDF_I_LENEATTR(inode) += size;
return (struct genericFormat *)[offset];
}
@@ -207,8 +202,6 @@ struct buffer_head *udf_read_tagged(struct super_block *sb,
uint32_t block,
{
tag *tag_p;
struct buffer_head *bh = NULL;
- register uint8_t checksum;
- register int i;
struct udf_sb_info *sbi = UDF_SB(sb);
/* Read the block */
@@ -234,12 +227,7 @@ struct buffer_head *udf_read_tagged(struct super_block
*sb, uint32_t block,
}
/* Verify the tag checksum */
- checksum = 0U;
- for (i = 0; i < 4; i++)
- checksum += (uint8_t)(bh->b_data[i]);
- for (i = 5; i < 16; i++)
- checksum += (uint8_t)(bh->b_data[i]);
- if (checksum != tag_p->tagChecksum) {
+ if (udf_tag_checksum(tag_p) != tag_p->tagChecksum) {
printk(KERN_ERR "udf: tag checksum failed block %d\n", block);
goto error_out;
}
@@ -277,17 +265,11 @@ struct buffer_head *udf_read_ptagged(struct super_block
*sb, kernel_lb_addr loc,
void udf_update_tag(char *data, int length)
{
tag *tptr = (tag *)data;
- int i;
-
length -= sizeof(tag);
- tptr->tagChecksum = 0;
tptr->descCRCLength = cpu_to_le16(length);
tptr->descCRC = cpu_to_le16(udf_crc(data + sizeof(tag), length, 0));
-
- for (i = 0; i < 16; i++)
- if (i != 4)
- tptr->tagChecksum += (uint8_t)(data[i]);
+ tptr->tagChecksum = udf_tag_checksum(tptr);
}
void udf_new_tag(char *data, uint16_t ident, uint16_t version, uint16_t snum,
diff --git a/fs/udf/namei.c b/fs/udf/namei.c
index 25d518b..f1cf18f 100644
--- a/fs/udf/namei.c
+++ b/fs/udf/namei.c
@@ -47,8 +47,6 @@ int udf_write_fi(struct inode *inode, struct fileIdentDesc
*cfi,
{
uint16_t crclen = fibh->eoffset - fibh->soffset -
Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage support
Stefan Richter wrote: Adrian Bunk wrote: Whether or not an option requires an additional subsystem like e.g. SCSI or SSB are hardware and implementation details we shouldn't bother kconfig users with. What is an implementation detail and what is not? In the end, everything that we configure in Kconfig is implementation details. PS: Kill 'select' already, and instead work on better UIs if you have got trouble with the complexities of the dependencies graph. The graphic UIs including menuconfig currently work best for tree-like dependencies, but the graph isn't a tree. Think about how to present this properly in an UI. The Kconfig files are the wrong place to attack this problem. PPS: Really, it's *not* hard *at all* to configure a 2.6.24-rc6 kernel with USB storage support. I don't read linux-usb --- has there been repeated questions how to enable usb-storage in the kernel configuration? I can I do read linux-usb. I don't think that USB storage configuration is a big issue (currently, without using "select"). But that's just my take on it. tell you that there has been no such question about sbp2 (FireWire storage support) in years. Don't fix what ain't broken. In fact, don't /break/ what ain't broken by adding more of the (as yet) broken 'select' everywhere. -- ~Randy desserts: http://www.xenotime.net/linux/recipes/ -- 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: sparc oops in ip_fast_csum
On Sun, Jan 06, 2008 at 01:57:13AM +0100, Jan Engelhardt wrote:
>
> >@@ -304,7 +305,8 @@ static int raw_send_hdrinc(struct sock *sk, void *from,
> >size_t length,
> > goto error_fault;
> >
> > /* We don't modify invalid header */
> >-if (length >= sizeof(*iph) && iph->ihl * 4U <= length) {
> >+iphlen = iph->ihl * 4;
> >+if (iphlen >= sizeof(*iph) && iphlen <= length) {
>
> Humm, this could use ip_hdrlen(skb) :-)
That would not necessarily be an improvement since we'd have to reload
the values from skb.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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: Oops in evdev_disconnect for kernel 2.6.23.12
Al Viro schrieb: On Tue, Jan 01, 2008 at 08:26:05PM +0100, Berthold Cogel wrote: Jan 1 17:34:39 wonderland kernel: BUG: unable to handle kernel paging request at virtual address 00100100 LIST_POISON1 Jan 1 17:34:39 wonderland kernel: EIP is at evdev_disconnect+0x65/0x9e and by the look of code, it's a bit before the call of something that gets 0x20006 as one of its arguments. Which, by the look of evdev.s, gets passed only to kill_fasync(). So it's POLL_HUP, so this code could be these days: spin_lock(>client_lock); list_for_each_entry(client, >client_list, node) kill_fasync(>fasync, SIGIO, POLL_HUP); spin_unlock(>client_lock); in evdev_hangup() prior to commit 6addb1d6de1968b84852f54561cc9a09b5a9: list_for_each_entry(client, >client_list, node) kill_fasync(>fasync, SIGIO, POLL_HUP); in evdev_disconnect() I'm using Debian stable/testing/unstable with homemade kernel 2.6.23.12 (patched with tuxonice-3.0-rc3-for-2.6.23.9). ... and seeing that this changeset postdates 2.6.23 *and* adds locking to the lists we are traversing in either variant, I'd bet that the kernel you have does *NOT* have the changeset in question, that you have list corruption from race and that your oops is list_for_each_entry() trying to walk forward from entry that just had list_del() poisoning its ->next. There are only 4 changesets between 2.6.23 and this one affecting drivers/input and only 8006479c9b75fb6594a7b746af3d7f1fbb68f18f and 6addb1d6de1968b84852f54561cc9a09b5a9 appear to be relevant. Apply to your kernel and see if it helps... Looks as if I have to start using git ... I always feared that this day will come. ;-) If I'm able to reproduce the oops with my patched kernel, I will gladly follow your advice. Regards, Berthold -- 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] x86: ioport_{32|64}.c unification
On Sunday 06 January 2008 01:47:47 Arnd Bergmann wrote:
> This #ifdef overload could probably be avoided if you just move
> the body of this function into an extra place and do
>
> static int do_iopl(unsigned int level, unsigned long *flags)
> {
> unsigned int old = (*flags >> 12) & 3;
> ...
> *flags = (*flags & ~X86_EFLAGS_IOPL) | (level << 12);;
> }
>
> #ifdef CONFIG_X86_32
> asmlinkage long sys_iopl(unsigned long regsp)
> {
> /* why is this volatle anyway? */
> volatile struct pt_regs *regs = (struct pt_regs *)
> unsigned int level = regs->bx;
> return do_iopl(regs->bx, >flags);
> }
> #else
> asmlinkage long sys_iopl(unsigned int level, struct pt_regs *regs)
> {
> return do_iopl(level, >flags);
> }
> #endif
>
> Arnd <><
I agree. I'll send the a proper patch soon.
--
Miguel Botón
--
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/5] USB Kconfig: Select SCSI for USB Mass Storage support
On Sun, Jan 06, 2008 at 01:35:21AM +0100, Stefan Richter wrote: > Adrian Bunk wrote: > > Whether or not an option requires an additional subsystem like e.g. SCSI > > or SSB are hardware and implementation details we shouldn't bother > > kconfig users with. > > What is an implementation detail and what is not? In the end, > everything that we configure in Kconfig is implementation details. With the use case "system administrator" we can expect people to know the name of their ethernet card and which filesystems they use, but we should not bother them with the fact that their network card might require the Sonics Silicon Backplane support. > PS: > Kill 'select' already, and instead work on better UIs if you have got > trouble with the complexities of the dependencies graph. The graphic > UIs including menuconfig currently work best for tree-like dependencies, > but the graph isn't a tree. Think about how to present this properly in > an UI. The Kconfig files are the wrong place to attack this problem. >... Duplicating the structure in each UI should be an improvement? Hardly. > Stefan Richter cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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: sparc oops in ip_fast_csum
On Jan 6 2008 11:22, Herbert Xu wrote:
>@@ -271,6 +271,7 @@ static int raw_send_hdrinc(struct sock *sk, void *from,
>size_t length,
> int hh_len;
> struct iphdr *iph;
> struct sk_buff *skb;
>+ unsigned int iphlen;
> int err;
>
> if (length > rt->u.dst.dev->mtu) {
>@@ -304,7 +305,8 @@ static int raw_send_hdrinc(struct sock *sk, void *from,
>size_t length,
> goto error_fault;
>
> /* We don't modify invalid header */
>- if (length >= sizeof(*iph) && iph->ihl * 4U <= length) {
>+ iphlen = iph->ihl * 4;
>+ if (iphlen >= sizeof(*iph) && iphlen <= length) {
Humm, this could use ip_hdrlen(skb) :-)
--
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 0/6] udf: improve code related to super_block v3
Ehh, forgot to add patching order :( Should be: [PATCH 1/6] udf: fix coding style of super.c [PATCH 2/6] udf: remove some ugly macros [PATCH 3/6] udf: convert UDF_SB_ALLOC_PARTMAPS macro to udf_sb_alloc_partition_maps function [PATCH 4/6] udf: check if udf_load_logicalvol failed [PATCH 5/6] udf: convert some macros to functions [PATCH 6/6] udf: fix sparse warnings (shadowing & mismatch between declaration and definition) -- 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] x86: ioport_{32|64}.c unification
On Sunday 06 January 2008, Miguel Botón wrote:
> +#ifdef CONFIG_X86_32
> +asmlinkage long sys_iopl(unsigned long regsp)
> +#else
> +asmlinkage long sys_iopl(unsigned int level, struct pt_regs *regs)
> +#endif
> +{
> +#ifdef CONFIG_X86_32
> + volatile struct pt_regs *regs = (struct pt_regs *)
> + unsigned int level = regs->bx;
> +#endif
This #ifdef overload could probably be avoided if you just move
the body of this function into an extra place and do
static int do_iopl(unsigned int level, unsigned long *flags)
{
unsigned int old = (*flags >> 12) & 3;
...
*flags = (*flags & ~X86_EFLAGS_IOPL) | (level << 12);;
}
#ifdef CONFIG_X86_32
asmlinkage long sys_iopl(unsigned long regsp)
{
/* why is this volatle anyway? */
volatile struct pt_regs *regs = (struct pt_regs *)
unsigned int level = regs->bx;
return do_iopl(regs->bx, >flags);
}
#else
asmlinkage long sys_iopl(unsigned int level, struct pt_regs *regs)
{
return do_iopl(level, >flags);
}
#endif
Arnd <><
--
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/
[PATCH] udf: convert some macros to functions
convert UDF_SB_ALLOC_BITMAP macro to udf_sb_alloc_bitmap function
convert UDF_SB_FREE_BITMAP macro to udf_sb_free_bitmap function
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
CC: Christoph Hellwig <[EMAIL PROTECTED]>
---
fs/udf/super.c | 49 +++--
fs/udf/udf_sb.h | 38 --
2 files changed, 43 insertions(+), 44 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index c09e968..5423d26 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -937,6 +937,27 @@ static void udf_load_fileset(struct super_block *sb,
struct buffer_head *bh,
root->logicalBlockNum, root->partitionReferenceNum);
}
+static struct udf_bitmap *udf_sb_alloc_bitmap(struct super_block *sb, __u32
index)
+{
+ struct udf_part_map *map = _SB(sb)->s_partmaps[index];
+ int nr_groups = (map->s_partition_len + (sizeof(struct spaceBitmapDesc)
<< 3) +
+ (sb->s_blocksize * 8) - 1) / (sb->s_blocksize * 8);
+ int size = sizeof(struct udf_bitmap) + (sizeof(struct buffer_head *) *
nr_groups);
+ struct udf_bitmap *bitmap;
+
+ if (size <= PAGE_SIZE)
+ bitmap = kmalloc(size, GFP_KERNEL);
+ else
+ bitmap = vmalloc(size);
+ if (bitmap != NULL) {
+ memset(bitmap, 0x00, size);
+ bitmap->s_block_bitmap = (struct buffer_head **)(bitmap + 1);
+ bitmap->s_nr_groups = nr_groups;
+ } else
+ udf_error(sb, __FUNCTION__, "Unable to allocate space for
bitmap and %d buffer_head pointers", nr_groups);
+ return bitmap;
+}
+
static int udf_load_partdesc(struct super_block *sb, struct buffer_head *bh)
{
struct partitionDesc *p;
@@ -987,7 +1008,7 @@ static int udf_load_partdesc(struct super_block *sb,
struct buffer_head *bh)
i,
map->s_uspace.s_table->i_ino);
}
if (phd->unallocSpaceBitmap.extLength) {
- UDF_SB_ALLOC_BITMAP(sb, i, s_uspace);
+ map->s_uspace.s_bitmap =
udf_sb_alloc_bitmap(sb, i);
if (map->s_uspace.s_bitmap != NULL) {
map->s_uspace.s_bitmap->s_extLength =
le32_to_cpu(phd->unallocSpaceBitmap.extLength);
@@ -1017,7 +1038,7 @@ static int udf_load_partdesc(struct super_block *sb,
struct buffer_head *bh)
i,
map->s_fspace.s_table->i_ino);
}
if (phd->freedSpaceBitmap.extLength) {
- UDF_SB_ALLOC_BITMAP(sb, i, s_fspace);
+ map->s_fspace.s_bitmap =
udf_sb_alloc_bitmap(sb, i);
if (map->s_fspace.s_bitmap != NULL) {
map->s_fspace.s_bitmap->s_extLength =
le32_to_cpu(phd->freedSpaceBitmap.extLength);
@@ -1506,6 +1527,22 @@ static void udf_close_lvid(struct super_block *sb)
}
}
+static void udf_sb_free_bitmap(struct udf_bitmap *bitmap)
+{
+ int i;
+ int nr_groups = bitmap->s_nr_groups;
+ int size = sizeof(struct udf_bitmap) + (sizeof(struct buffer_head *) *
nr_groups);
+
+ for (i = 0; i < nr_groups; i++)
+ if (bitmap->s_block_bitmap[i])
+ brelse(bitmap->s_block_bitmap[i]);
+
+ if (size <= PAGE_SIZE)
+ kfree(bitmap);
+ else
+ vfree(bitmap);
+}
+
/*
* udf_read_super
*
@@ -1691,9 +1728,9 @@ error_out:
if (map->s_partition_flags & UDF_PART_FLAG_FREED_TABLE)
iput(map->s_fspace.s_table);
if (map->s_partition_flags & UDF_PART_FLAG_UNALLOC_BITMAP)
- UDF_SB_FREE_BITMAP(sb, sbi->s_partition, s_uspace);
+ udf_sb_free_bitmap(map->s_uspace.s_bitmap);
if (map->s_partition_flags & UDF_PART_FLAG_FREED_BITMAP)
- UDF_SB_FREE_BITMAP(sb, sbi->s_partition, s_fspace);
+ udf_sb_free_bitmap(map->s_fspace.s_bitmap);
if (map->s_partition_type == UDF_SPARABLE_MAP15)
for (i = 0; i < 4; i++)
brelse(map->s_type_specific.s_sparing.s_spar_map[i]);
@@ -1769,9 +1806,9 @@ static void udf_put_super(struct super_block *sb)
if (map->s_partition_flags & UDF_PART_FLAG_FREED_TABLE)
iput(map->s_fspace.s_table);
if (map->s_partition_flags & UDF_PART_FLAG_UNALLOC_BITMAP)
-
[PATCH] udf: fix sparse warnings (shadowing & mismatch between declaration and definition)
fix sparse warnings:
fs/udf/super.c:1431:24: warning: symbol 'bh' shadows an earlier one
fs/udf/super.c:1347:21: originally declared here
fs/udf/super.c:472:6: warning: symbol 'udf_write_super' was not declared.
Should it be static?
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
CC: Christoph Hellwig <[EMAIL PROTECTED]>
---
fs/udf/super.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 5423d26..a5fb461 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -474,7 +474,7 @@ static int udf_parse_options(char *options, struct
udf_options *uopt)
return 1;
}
-void udf_write_super(struct super_block *sb)
+static void udf_write_super(struct super_block *sb)
{
lock_kernel();
@@ -1433,7 +1433,6 @@ static int udf_load_partition(struct super_block *sb,
kernel_lb_addr *fileset)
map->s_type_specific.s_virtual.s_num_entries =
(sbi->s_vat_inode->i_size - 36) >> 2;
} else if (map->s_partition_type == UDF_VIRTUAL_MAP20) {
- struct buffer_head *bh = NULL;
uint32_t pos;
pos = udf_block_map(sbi->s_vat_inode, 0);
--
1.5.3.7
--
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/
[PATCH] udf: convert UDF_SB_ALLOC_PARTMAPS macro to udf_sb_alloc_partition_maps function
- convert UDF_SB_ALLOC_PARTMAPS macro to udf_sb_alloc_partition_maps function
- convert kmalloc + memset to kcalloc
- check if kcalloc failed (partially)
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
Acked-by: Christoph Hellwig <[EMAIL PROTECTED]>
---
fs/udf/super.c | 25 +++--
fs/udf/udf_sb.h | 13 -
2 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 246868c..3f5b632 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -52,6 +52,7 @@
#include
#include
#include
+#include
#include
#include
@@ -226,6 +227,24 @@ static void __exit exit_udf_fs(void)
module_init(init_udf_fs)
module_exit(exit_udf_fs)
+static int udf_sb_alloc_partition_maps(struct super_block *sb, u32 count)
+{
+ struct udf_sb_info *sbi = UDF_SB(sb);
+
+ sbi->s_partmaps = kcalloc(count, sizeof(struct udf_part_map),
+ GFP_KERNEL);
+ if (!sbi->s_partmaps) {
+ udf_error(sb, __FUNCTION__,
+ "Unable to allocate space for %d partition maps",
+ count);
+ sbi->s_partitions = 0;
+ return -ENOMEM;
+ }
+
+ sbi->s_partitions = count;
+ return 0;
+}
+
/*
* udf_parse_options
*
@@ -1037,7 +1056,9 @@ static int udf_load_logicalvol(struct super_block *sb,
struct buffer_head *bh,
lvd = (struct logicalVolDesc *)bh->b_data;
- UDF_SB_ALLOC_PARTMAPS(sb, le32_to_cpu(lvd->numPartitionMaps));
+ i = udf_sb_alloc_partition_maps(sb, le32_to_cpu(lvd->numPartitionMaps));
+ if (i != 0)
+ return i;
for (i = 0, offset = 0;
i < sbi->s_partitions && offset < le32_to_cpu(lvd->mapTableLength);
@@ -1242,7 +1263,7 @@ static int udf_process_sequence(struct super_block *sb,
long block,
if (i == VDS_POS_PRIMARY_VOL_DESC) {
udf_load_pvoldesc(sb, bh);
} else if (i == VDS_POS_LOGICAL_VOL_DESC) {
- udf_load_logicalvol(sb, bh, fileset);
+ udf_load_logicalvol(sb, bh, fileset); /* TODO:
check return value */
} else if (i == VDS_POS_PARTITION_DESC) {
struct buffer_head *bh2 = NULL;
if (udf_load_partdesc(sb, bh)) {
diff --git a/fs/udf/udf_sb.h b/fs/udf/udf_sb.h
index 92e6d75..4d3bd77 100644
--- a/fs/udf/udf_sb.h
+++ b/fs/udf/udf_sb.h
@@ -43,19 +43,6 @@ static inline struct udf_sb_info *UDF_SB(struct super_block
*sb)
struct logicalVolIntegrityDescImpUse *udf_sb_lvidiu(struct udf_sb_info *sbi);
-#define UDF_SB_ALLOC_PARTMAPS(X,Y)\
-{\
- struct udf_sb_info *sbi = UDF_SB(X);\
- sbi->s_partmaps = kmalloc(sizeof(struct udf_part_map) * Y, GFP_KERNEL);\
- if (sbi->s_partmaps != NULL) {\
- sbi->s_partitions = Y;\
- memset(sbi->s_partmaps, 0x00, sizeof(struct udf_part_map) * Y);\
- } else {\
- sbi->s_partitions = 0;\
- udf_error(X, __FUNCTION__, "Unable to allocate space for %d
partition maps", Y);\
- }\
-}
-
#define UDF_SB_ALLOC_BITMAP(X,Y,Z)\
{\
struct udf_sb_info *sbi = UDF_SB(X);\
--
1.5.3.7
--
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/
[PATCH] udf: check if udf_load_logicalvol failed
udf_load_logicalvol may fail eg in out of memory conditions - check it
and propagate error further
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
CC: Christoph Hellwig <[EMAIL PROTECTED]>
---
fs/udf/super.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 3f5b632..c09e968 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -1188,6 +1188,7 @@ static int udf_process_sequence(struct super_block *sb,
long block,
uint32_t vdsn;
uint16_t ident;
long next_s = 0, next_e = 0;
+ int ret;
memset(vds, 0, sizeof(struct udf_vds_record) * VDS_POS_LENGTH);
@@ -1263,7 +1264,11 @@ static int udf_process_sequence(struct super_block *sb,
long block,
if (i == VDS_POS_PRIMARY_VOL_DESC) {
udf_load_pvoldesc(sb, bh);
} else if (i == VDS_POS_LOGICAL_VOL_DESC) {
- udf_load_logicalvol(sb, bh, fileset); /* TODO:
check return value */
+ ret = udf_load_logicalvol(sb, bh, fileset);
+ if (ret != 0) {
+ brelse(bh);
+ return ret;
+ }
} else if (i == VDS_POS_PARTITION_DESC) {
struct buffer_head *bh2 = NULL;
if (udf_load_partdesc(sb, bh)) {
--
1.5.3.7
--
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/
[PATCH] udf: fix coding style of super.c
fix coding style errors found by checkpatch:
- assignments in if conditions
- braces {} around single statement blocks
- no spaces after commas
- printks without KERN_*
- lines longer than 80 characters
before: total: 50 errors, 207 warnings, 1835 lines checked
after: total: 0 errors, 164 warnings, 1872 lines checked
all 164 warnings left are lines longer than 80 characters;
this file has too much indentation with really long expressions
to break all those lines
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/super.c | 295 +++
1 files changed, 166 insertions(+), 129 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 4360c7a..57788f1 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -33,8 +33,8 @@
* 10/17/98 added freespace count for "df"
* 11/11/98 gr added novrs option
* 11/26/98 dgb added fileset,anchor mount options
- * 12/06/98 blf really hosed things royally. vat/sparing support. sequenced
vol descs
- *rewrote option handling based on isofs
+ * 12/06/98 blf really hosed things royally. vat/sparing support. sequenced
+ *vol descs. rewrote option handling based on isofs
* 12/20/98 find the free space bitmap (if it exists)
*/
@@ -116,7 +116,7 @@ static struct kmem_cache *udf_inode_cachep;
static struct inode *udf_alloc_inode(struct super_block *sb)
{
struct udf_inode_info *ei;
- ei = (struct udf_inode_info *)kmem_cache_alloc(udf_inode_cachep,
GFP_KERNEL);
+ ei = kmem_cache_alloc(udf_inode_cachep, GFP_KERNEL);
if (!ei)
return NULL;
@@ -561,47 +561,52 @@ static int udf_vrs(struct super_block *sb, int silent)
/* Look for ISO descriptors */
vsd = (struct volStructDesc *)(bh->b_data +
- (sector & (sb->s_blocksize -
1)));
+ (sector & (sb->s_blocksize - 1)));
if (vsd->stdIdent[0] == 0) {
brelse(bh);
break;
- } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_CD001,
VSD_STD_ID_LEN)) {
+ } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_CD001,
+ VSD_STD_ID_LEN)) {
iso9660 = sector;
switch (vsd->structType) {
case 0:
udf_debug("ISO9660 Boot Record found\n");
break;
case 1:
- udf_debug
- ("ISO9660 Primary Volume Descriptor
found\n");
+ udf_debug("ISO9660 Primary Volume Descriptor "
+ "found\n");
break;
case 2:
- udf_debug
- ("ISO9660 Supplementary Volume Descriptor
found\n");
+ udf_debug("ISO9660 Supplementary Volume "
+ "Descriptor found\n");
break;
case 3:
- udf_debug
- ("ISO9660 Volume Partition Descriptor
found\n");
+ udf_debug("ISO9660 Volume Partition Descriptor "
+ "found\n");
break;
case 255:
- udf_debug
- ("ISO9660 Volume Descriptor Set Terminator
found\n");
+ udf_debug("ISO9660 Volume Descriptor Set "
+ "Terminator found\n");
break;
default:
udf_debug("ISO9660 VRS (%u) found\n",
vsd->structType);
break;
}
- } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_BEA01,
VSD_STD_ID_LEN)) {
- } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_TEA01,
VSD_STD_ID_LEN)) {
+ } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_BEA01,
+ VSD_STD_ID_LEN))
+ ; /* nothing */
+ else if (!strncmp(vsd->stdIdent, VSD_STD_ID_TEA01,
+ VSD_STD_ID_LEN)) {
brelse(bh);
break;
- } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_NSR02,
VSD_STD_ID_LEN)) {
+ } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_NSR02,
+ VSD_STD_ID_LEN))
nsr02 =
[PATCH 0/6] udf: improve code related to super_block v3
Hi This patchset converts macros related to super_block into functions. Besides that it fixes some sparse warnings (6th), improves coding style (1st) and fixes error handling (4th). Note that udf files has really long lines and these patches won't validate by checkpatch. Next patchset will clean it up almost completely. (Only 3rd patch changed from second version) Second version: http://lkml.org/lkml/2007/12/23/197 First version: http://lkml.org/lkml/2007/12/22/150 Marcin Slusarz -- 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/5] USB Kconfig: Select SCSI for USB Mass Storage support
Adrian Bunk wrote: > Whether or not an option requires an additional subsystem like e.g. SCSI > or SSB are hardware and implementation details we shouldn't bother > kconfig users with. What is an implementation detail and what is not? In the end, everything that we configure in Kconfig is implementation details. PS: Kill 'select' already, and instead work on better UIs if you have got trouble with the complexities of the dependencies graph. The graphic UIs including menuconfig currently work best for tree-like dependencies, but the graph isn't a tree. Think about how to present this properly in an UI. The Kconfig files are the wrong place to attack this problem. PPS: Really, it's *not* hard *at all* to configure a 2.6.24-rc6 kernel with USB storage support. I don't read linux-usb --- has there been repeated questions how to enable usb-storage in the kernel configuration? I can tell you that there has been no such question about sbp2 (FireWire storage support) in years. Don't fix what ain't broken. In fact, don't /break/ what ain't broken by adding more of the (as yet) broken 'select' everywhere. -- Stefan Richter -=-==--- ---= --==- http://arcgraph.de/sr/ -- 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: wistron_btns-add-support-for-x86_64-systems.patch in -mm
On Saturday 05 January 2008 17:52:06 Rémi Hérilier wrote: > What about finding what does this BIOS function and writing > an equivalent in C? There would be no BIOS call anymore and > this module could be used in the x86-64 port. > > But, is it a sane solution? The problem is that the BIOS call would be unique to each supported machine as in which memory addresses, EC registers etc get touched and with what values. You would end up needing to reimplement this on a case-by-case basis. This was an idea that was considered by acerhk, but they considered it far too much work and completely impractical. For at least all modern Acer laptops, this direct BIOS calling is completely deprecated, in favour of ACPI-WMI (which in turn, on those systems, usually either triggers SMI traps or touches EC registers, and is 32/ 64 bit agnostic), so the question for those laptops is becoming more and more irrelevant (and modern Acer laptops of the last four years, at least, don't have problems with missing keycodes that require us to poll). For Fujitsu-Siemens laptops, I did come across someone who was looking into poking at ACPI to generate keypresses for the keys that don't generate standard keycodes[1], as a 32/ 64 bit agnostic solution (since most Fujitsu Siemens laptops don't support the required BIOS call from long mode, and also still don't produce standard keycodes on certain button presses). -Carlos [1] http://code.google.com/p/fscamiloa16xx/ -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
[BUG] 2.6.24-rc5: 'sysctl table check failed' when turning on printer
(Resending as there were no replies on my first post mid December; issue is still there with -rc6.) This is the first time I've seen this error. Last time I used the printer was with 2.6.24-rc3 and that time this error did not occur. The error occurs when I start a print job, not when I turn the printer on. System is Pentium D x86_64 kernel running Debian unstable. Printer is a HP Photosmart P1100 connected via parallel port. Not sure who should be CCed on this. ppdev0: registered pardevice sysctl table check failed: /dev/parport/parport0/devices/ppdev0/timeslice Sysctl already exists Pid: 14491, comm: hpijs Not tainted 2.6.24-rc5 #1 Call Trace: [] set_fail+0x3f/0x47 [] sysctl_check_table+0x4ae/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] register_sysctl_table+0x52/0x9d [] :parport:parport_device_proc_register+0xc3/0xe3 [] :parport:parport_register_device+0x206/0x267 [] :ppdev:pp_irq+0x0/0x40 [] :ppdev:pp_ioctl+0x13f/0x77c [] do_ioctl+0x55/0x6b [] vfs_ioctl+0x243/0x25c [] sys_ioctl+0x51/0x71 [] system_call+0x7e/0x83 Cheers, FJP -- 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: sparc oops in ip_fast_csum
Al Viro <[EMAIL PROTECTED]> wrote:
>
> ip_fast_csum() called from raw_send_hdrinc() from raw_sendmsg() ran through
> the page boundary into unmapped page... Bloody odd, that, seeing that
> we have checked iph->ihl * 4U <= length and had done
>err = memcpy_fromiovecend((void *)iph, from, 0, length);
> before the
>iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl);
> that had triggered that crap..
Actually if you read the code for ip_fast_csum it's obvious what has
happened. %o1 == iph->ihl contains the value 2 which is bogus.
[IPV4] raw: Strengthen check on validity of iph->ihl
We currently check that iph->ihl is bounded by the real length and that
the real length is greater than the minimum IP header length. However,
we did not check the caes where iph->ihl is less than the minimum IP
header length.
This breaks because some ip_fast_csum implementations assume that which
is quite reasonable.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 66b42f5..e7050f8 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -271,6 +271,7 @@ static int raw_send_hdrinc(struct sock *sk, void *from,
size_t length,
int hh_len;
struct iphdr *iph;
struct sk_buff *skb;
+ unsigned int iphlen;
int err;
if (length > rt->u.dst.dev->mtu) {
@@ -304,7 +305,8 @@ static int raw_send_hdrinc(struct sock *sk, void *from,
size_t length,
goto error_fault;
/* We don't modify invalid header */
- if (length >= sizeof(*iph) && iph->ihl * 4U <= length) {
+ iphlen = iph->ihl * 4;
+ if (iphlen >= sizeof(*iph) && iphlen <= length) {
if (!iph->saddr)
iph->saddr = rt->rt_src;
iph->check = 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.24-rc6: possible recursive locking detected
On Sat, 5 Jan 2008, Davide Libenzi wrote: A solution may be to move the call to ep_poll_safewake() (that'd become a simple wake_up()) inside a tasklet or whatever is today trendy for delayed work. But his kinda scares me to be honest, since epoll has already a bunch of places where it could be asynchronously hit (plus performance regression will need to be verified). Although I'm not able to reproduce this one right now, I'm happy to test any patches you guys come up with. Thanks for your time, Christian. -- BOFH excuse #78: Yes, yes, its called a design limitation -- 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: Oops in evdev_disconnect for kernel 2.6.23.12
On Sun, Jan 06, 2008 at 01:14:40AM +0100, Berthold Cogel wrote: > >There are only 4 changesets between 2.6.23 and this one affecting > >drivers/input > >and only > >8006479c9b75fb6594a7b746af3d7f1fbb68f18f and > >6addb1d6de1968b84852f54561cc9a09b5a9 > >appear to be relevant. Apply to your kernel and see if it helps... > > Looks as if I have to start using git ... I always feared that this day > will come. ;-) > > If I'm able to reproduce the oops with my patched kernel, I will gladly > follow your advice. AFAICS, lkml.org/lkml/2007/7/24/20 is the same patch... -- 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/
[PATCH] x86: paravirt_patch_{32|64}.c unification
paravirt_patch_{32|64}.c unification.
This patch unifies the code from the paravirt_patcht_32.c and
paravirt_patch_64.c files.
I couldn't test this modification but it shouldn't have any bugs
(it's a very simple modification).
Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 5ed68b4..92d9ac6 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -66,7 +66,7 @@ obj-$(CONFIG_K8_NB) += k8.o
obj-$(CONFIG_MGEODE_LX)+= geode_32.o mfgpt_32.o
obj-$(CONFIG_VMI) += vmi_32.o vmiclock_32.o
-obj-$(CONFIG_PARAVIRT) += paravirt.o paravirt_patch_$(BITS).o
+obj-$(CONFIG_PARAVIRT) += paravirt.o paravirt_patch.o
obj-y += pcspeaker.o
obj-$(CONFIG_SCx200) += scx200_32.o
diff --git a/arch/x86/kernel/paravirt_patch.c b/arch/x86/kernel/paravirt_patch.c
new file mode 100644
index 000..7e756ea
--- /dev/null
+++ b/arch/x86/kernel/paravirt_patch.c
@@ -0,0 +1,69 @@
+#include
+
+DEF_NATIVE(pv_irq_ops, irq_enable, "sti");
+DEF_NATIVE(pv_irq_ops, irq_disable, "cli");
+DEF_NATIVE(pv_cpu_ops, clts, "clts");
+
+#ifdef CONFIG_X86_32
+DEF_NATIVE(pv_irq_ops, restore_fl, "push %eax; popf");
+DEF_NATIVE(pv_irq_ops, save_fl, "pushf; pop %eax");
+DEF_NATIVE(pv_cpu_ops, iret, "iret");
+DEF_NATIVE(pv_cpu_ops, irq_enable_syscall_ret, "sti; sysexit");
+DEF_NATIVE(pv_mmu_ops, read_cr2, "mov %cr2, %eax");
+DEF_NATIVE(pv_mmu_ops, read_cr3, "mov %cr3, %eax");
+DEF_NATIVE(pv_mmu_ops, write_cr3, "mov %eax, %cr3");
+DEF_NATIVE(pv_cpu_ops, read_tsc, "rdtsc");
+#else
+DEF_NATIVE(pv_irq_ops, restore_fl, "pushq %rdi; popfq");
+DEF_NATIVE(pv_irq_ops, save_fl, "pushfq; popq %rax");
+DEF_NATIVE(pv_cpu_ops, iret, "iretq");
+DEF_NATIVE(pv_cpu_ops, irq_enable_syscall_ret, "movq %gs:"
__stringify(pda_oldrsp) ", %rsp; swapgs; sysretq;");
+DEF_NATIVE(pv_mmu_ops, read_cr2, "movq %cr2, %rax");
+DEF_NATIVE(pv_mmu_ops, read_cr3, "movq %cr3, %rax");
+DEF_NATIVE(pv_mmu_ops, write_cr3, "movq %rdi, %cr3");
+DEF_NATIVE(pv_mmu_ops, flush_tlb_single, "invlpg (%rdi)");
+DEF_NATIVE(pv_cpu_ops, wbinvd, "wbinvd");
+DEF_NATIVE(pv_cpu_ops, swapgs, "swapgs");
+#endif
+
+unsigned native_patch(u8 type, u16 clobbers, void *ibuf,
+ unsigned long addr, unsigned len)
+{
+ const unsigned char *start, *end;
+ unsigned ret;
+
+#define PATCH_SITE(ops, x) \
+ case PARAVIRT_PATCH(ops.x): \
+ start = start_##ops##_##x; \
+ end = end_##ops##_##x; \
+ goto patch_site
+ switch (type) {
+ PATCH_SITE(pv_irq_ops, irq_enable);
+ PATCH_SITE(pv_irq_ops, irq_disable);
+ PATCH_SITE(pv_irq_ops, restore_fl);
+ PATCH_SITE(pv_irq_ops, save_fl);
+ PATCH_SITE(pv_cpu_ops, iret);
+ PATCH_SITE(pv_cpu_ops, irq_enable_syscall_ret);
+ PATCH_SITE(pv_mmu_ops, read_cr2);
+ PATCH_SITE(pv_mmu_ops, read_cr3);
+ PATCH_SITE(pv_mmu_ops, write_cr3);
+ PATCH_SITE(pv_cpu_ops, clts);
+#ifdef CONFIG_X86_32
+ PATCH_SITE(pv_cpu_ops, read_tsc);
+#else
+ PATCH_SITE(pv_mmu_ops, flush_tlb_single);
+ PATCH_SITE(pv_cpu_ops, wbinvd);
+ PATCH_SITE(pv_cpu_ops, swapgs);
+#endif
+
+patch_site:
+ ret = paravirt_patch_insns(ibuf, len, start, end);
+ break;
+
+default:
+ ret = paravirt_patch_default(type, clobbers, ibuf, addr, len);
+ break;
+ }
+#undef PATCH_SITE
+ return ret;
+}
diff --git a/arch/x86/kernel/paravirt_patch_32.c
b/arch/x86/kernel/paravirt_patch_32.c
deleted file mode 100644
index 82fc5fc..000
--- a/arch/x86/kernel/paravirt_patch_32.c
+++ /dev/null
@@ -1,49 +0,0 @@
-#include
-
-DEF_NATIVE(pv_irq_ops, irq_disable, "cli");
-DEF_NATIVE(pv_irq_ops, irq_enable, "sti");
-DEF_NATIVE(pv_irq_ops, restore_fl, "push %eax; popf");
-DEF_NATIVE(pv_irq_ops, save_fl, "pushf; pop %eax");
-DEF_NATIVE(pv_cpu_ops, iret, "iret");
-DEF_NATIVE(pv_cpu_ops, irq_enable_syscall_ret, "sti; sysexit");
-DEF_NATIVE(pv_mmu_ops, read_cr2, "mov %cr2, %eax");
-DEF_NATIVE(pv_mmu_ops, write_cr3, "mov %eax, %cr3");
-DEF_NATIVE(pv_mmu_ops, read_cr3, "mov %cr3, %eax");
-DEF_NATIVE(pv_cpu_ops, clts, "clts");
-DEF_NATIVE(pv_cpu_ops, read_tsc, "rdtsc");
-
-unsigned native_patch(u8 type, u16 clobbers, void *ibuf,
- unsigned long addr, unsigned len)
-{
- const unsigned char *start, *end;
- unsigned ret;
-
-#define PATCH_SITE(ops, x) \
- case PARAVIRT_PATCH(ops.x): \
- start = start_##ops##_##x; \
- end = end_##ops##_##x; \
- goto
[PATCH] x86: ioport_{32|64}.c unification
ioport_{32|64}.c unification.
This patch unifies the code from the ioport_32.c and ioport_64.c files.
Tested and working fine with i386 and x86_64 kernels.
Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 0903bbf..5ed68b4 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -10,7 +10,7 @@ CFLAGS_vsyscall_64.o := $(PROFILING) -g0
obj-y := process_$(BITS).o signal_$(BITS).o entry_$(BITS).o
obj-y += traps_$(BITS).o irq_$(BITS).o
-obj-y += time_$(BITS).o ioport_$(BITS).o ldt.o
+obj-y += time_$(BITS).o ioport.o ldt.o
obj-y += setup_$(BITS).o i8259_$(BITS).o
obj-$(CONFIG_X86_32) += sys_i386_32.o i386_ksyms_32.o
obj-$(CONFIG_X86_64) += sys_x86_64.o x8664_ksyms_64.o
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
new file mode 100644
index 000..be3d521
--- /dev/null
+++ b/arch/x86/kernel/ioport.c
@@ -0,0 +1,138 @@
+/*
+ * This contains the io-permission bitmap code - written by obz, with changes
+ * by Linus. 32/64 bits code unification by Miguel Botón.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Set EXTENT bits starting at BASE in BITMAP to value TURN_ON. */
+static void set_bitmap(unsigned long *bitmap, unsigned int base,
+ unsigned int extent, int new_value)
+{
+ unsigned int i;
+
+ for (i = base; i < base + extent; i++) {
+ if (new_value)
+ __set_bit(i, bitmap);
+ else
+ __clear_bit(i, bitmap);
+ }
+}
+
+/*
+ * this changes the io permissions bitmap in the current task.
+ */
+asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int turn_on)
+{
+ struct thread_struct *t = >thread;
+ struct tss_struct *tss;
+ unsigned int i, max_long, bytes, bytes_updated;
+
+ if ((from + num <= from) || (from + num > IO_BITMAP_BITS))
+ return -EINVAL;
+ if (turn_on && !capable(CAP_SYS_RAWIO))
+ return -EPERM;
+
+ /*
+* If it's the first ioperm() call in this thread's lifetime, set the
+* IO bitmap up. ioperm() is much less timing critical than clone(),
+* this is why we delay this operation until now:
+*/
+ if (!t->io_bitmap_ptr) {
+ unsigned long *bitmap = kmalloc(IO_BITMAP_BYTES, GFP_KERNEL);
+
+ if (!bitmap)
+ return -ENOMEM;
+
+ memset(bitmap, 0xff, IO_BITMAP_BYTES);
+ t->io_bitmap_ptr = bitmap;
+ set_thread_flag(TIF_IO_BITMAP);
+ }
+
+ /*
+* do it in the per-thread copy and in the TSS ...
+*
+* Disable preemption via get_cpu() - we must not switch away
+* because the ->io_bitmap_max value must match the bitmap
+* contents:
+*/
+ tss = _cpu(init_tss, get_cpu());
+
+ set_bitmap(t->io_bitmap_ptr, from, num, !turn_on);
+
+ /*
+* Search for a (possibly new) maximum. This is simple and stupid,
+* to keep it obviously correct:
+*/
+ max_long = 0;
+ for (i = 0; i < IO_BITMAP_LONGS; i++)
+ if (t->io_bitmap_ptr[i] != ~0UL)
+ max_long = i;
+
+ bytes = (max_long + 1) * sizeof(unsigned long);
+ bytes_updated = max(bytes, t->io_bitmap_max);
+
+ t->io_bitmap_max = bytes;
+
+#ifdef CONFIG_X86_32
+ /*
+* Sets the lazy trigger so that the next I/O operation will
+* reload the correct bitmap.
+* Reset the owner so that a process switch will not set
+* tss->io_bitmap_base to IO_BITMAP_OFFSET.
+*/
+ tss->x86_tss.io_bitmap_base = INVALID_IO_BITMAP_OFFSET_LAZY;
+ tss->io_bitmap_owner = NULL;
+#else
+ /* Update the TSS: */
+ memcpy(tss->io_bitmap, t->io_bitmap_ptr, bytes_updated);
+#endif
+
+ put_cpu();
+
+ return 0;
+}
+
+/*
+ * sys_iopl has to be used when you want to access the IO ports
+ * beyond the 0x3ff range: to get the full 65536 ports bitmapped
+ * you'd need 8kB of bitmaps/process, which is a bit excessive.
+ *
+ * Here we just change the flags value on the stack: we allow
+ * only the super-user to do it. This depends on the stack-layout
+ * on system-call entry - see also fork() and the signal handling
+ * code.
+ */
+#ifdef CONFIG_X86_32
+asmlinkage long sys_iopl(unsigned long regsp)
+#else
+asmlinkage long sys_iopl(unsigned int level, struct pt_regs *regs)
+#endif
+{
+#ifdef CONFIG_X86_32
+ volatile struct pt_regs *regs = (struct pt_regs *)
+ unsigned int level = regs->bx;
+#endif
+ unsigned int old = (regs->flags >> 12) & 3;
+
+ if (level > 3)
+ return -EINVAL;
+ /* Trying to gain more privileges? */
+ if (level > old) {
+
Re: acpi/apm events as inputs: how to handle?
On Wed 2008-01-02 12:56:40, Michael Tokarev wrote: > (Not so) recently, ACPI events started appearing as > key press events over linux input subsystem. The > question regarding this is simple: how it's supposed > to be handled? > > First of all, I don't know any software so far that > can handle input layer in userspace when not running > X. In X, it's usually done using window manager > setup or with special application (like, volume > up/down keys etc). But without X, there's no such > application, as far as I can see. > > It's easy to write one, but there may be.. issues > with finding which input device to use. > > Now, linux already have hotplug subsystem, using > /sbin/hotplug helper (or whatever it points to, > or using netlink). ACPI key events are rare. > > What I'm thinking about is: why ACPI events are > routed over input subsystem, instead of hotplug > subsystem? With input, there's a need for a > special daemon/application listening on the > specific "keyboard" device, while with hotplug > subsystem, it's already here - linux (by default > anyway, if not running udev etc), kernel fires > up a script when an event occurs. I don't see > how this special application/daemon is different > from ol'good acpid. > > Or.. maybe I missed something? No, you are not missing anything. Yes, we could use /sbin/hotplug, but it would be an ugly hack. So better write that daemon, or teach udevd to read from input... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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/5] USB Kconfig: Select SCSI for USB Mass Storage support
On Sat, Jan 05, 2008 at 03:22:14PM -0800, Randy Dunlap wrote: >... > For Aunt Tillie cases, "select" makes sense. For other cases, > I'd argue that it makes sense for config users to know when they > do something that causes an entire subsystem to be added to their > kernel (like SCSI or NET). We are not talking about Aunt Tillie [1] since she anyway does not build her own kernel. The vast majority of kconfig users should be covered by the "system administrator" use case. And for them it's a lot easier if they simply find the options for their hardware in the logical places without additional hassle. Whether or not an option requires an additional subsystem like e.g. SCSI or SSB are hardware and implementation details we shouldn't bother kconfig users with. cu Adrian [1] kconfig version of Godwin's law -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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.24-rc6-git12: Reported regressions from 2.6.23
Rafael J. Wysocki wrote: This message contains a list of some regressions from 2.6.23 reported since 2.6.24-rc1 was released, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. .. Subject : 2+ wake-ups/second in 2.6.24 Submitter : Mark Lord <[EMAIL PROTECTED]> Date: 2007-12-02 04:23 References : http://lkml.org/lkml/2007/12/1/141 http://bugzilla.kernel.org/show_bug.cgi?id=9489 Handled-By : Arjan van de Ven <[EMAIL PROTECTED]> .. I have only seen that one once, and I think it was Arjan who said that it has been observed rarely by other people as well. The bugzilla entry is mostly just to track the darned thing, but it seems unlikely that anyone will find/fix it for 2.6.24. No big deal, but it would be good to have somebody knowledgeable in clocks/interrupts try and track it down. I wonder if it's just a babbling IRQ on resume, before the driver has run it's resume code or something ? Cheers -- 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.24-rc6-git12: Reported regressions from 2.6.23
On Saturday, 5 of January 2008, Alan Cox wrote: > > Subject : PATA_HPT37X embezzles two ports > > Submitter : "Bjoern Olausson" <[EMAIL PROTECTED]> > > Date: 2007-12-12 11:05 > > References : http://lkml.org/lkml/2007/12/12/161 > > http://bugzilla.kernel.org/show_bug.cgi?id=9551 > > HPT374 patch was posted. Udated status, thanks. > We also have a newly reported regression in USB pl2303 > > See [pl2303 regression] Linux 2.6.23 breaks gpsbabel's DG-100 support on > [EMAIL PROTECTED] > > No bug # yet but will try and sort a patch out next week. Well, that's not a regression from 2.6.23. -- 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: Regression: VIDIOCGMBUF ioctl hangs on bttv driver (2.6.24-rc6)
On Saturday, 5 of January 2008, Gregor Jasny wrote: > Hi, > > During some tests I've noticed that the VIDIOCGMBUF ioctl hangs on my > bttv video device. It simply does not return and the process is stuck in > the D+ state. With Kernel 2.6.22.9 the (attached) testcase works like a > charm. The V4L2 interface is working with 2.6.24, too (at least displays > xawtv the usual pixel snow). Do the 2.6.23.x kernels work? Rafael -- 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/5] USB Kconfig: Select SCSI for USB Mass Storage support
Sam Ravnborg wrote: On Sat, Jan 05, 2008 at 11:03:30PM +0200, Adrian Bunk wrote: On Sat, Jan 05, 2008 at 11:30:24AM -0800, Randy Dunlap wrote: On Sat, 5 Jan 2008 18:41:39 +0300 Al Boldi wrote: Select SCSI for USB Mass Storage support. Cc: David Brownell <[EMAIL PROTECTED]> Cc: Greg KH <[EMAIL PROTECTED]> Cc: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Al Boldi <[EMAIL PROTECTED]> --- --- 23.a/drivers/usb/storage/Kconfig +++ 23.b/drivers/usb/storage/Kconfig @@ -2,14 +2,10 @@ # USB Storage driver configuration # -comment "NOTE: USB_STORAGE needs SCSI, and 'SCSI disk support' may" - depends on USB -comment "also be needed; see USB_STORAGE Help for more information" - depends on USB - menuconfig USB_STORAGE tristate "USB Mass Storage support" - depends on USB && SCSI + depends on USB + select SCSI We try not to use 'select' on subsystems and try to limit its use to library-like code that is relatively small. Selecting SCSI breaks both of those efforts. ... _You_ are trying to do this. I'd say that sometimes Andrew helps also. For kconfig users, "select" is _much_ better than sending them through different menus. Only if used within the current limitations of Kconfig. And that requires you to use select only to select symbols with no dependencies. Right. One of the main (or maybe even the only) problem(s) is that select does not follow dependency chains. and that no one works on that problem. In this case we do not know if BLOCK is enabled or not. For Aunt Tillie cases, "select" makes sense. For other cases, I'd argue that it makes sense for config users to know when they do something that causes an entire subsystem to be added to their kernel (like SCSI or NET). -- ~Randy desserts: http://www.xenotime.net/linux/recipes/ -- 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: freeze vs freezer
Hi. Pavel Machek wrote: > On Fri 2008-01-04 21:54:06, Oliver Neukum wrote: >> Am Donnerstag, 3. Januar 2008 23:06:07 schrieb Nigel Cunningham: >>> Oliver Neukum wrote: Am Donnerstag, 3. Januar 2008 10:52:53 schrieb Nigel Cunningham: > Oliver Neukum wrote: >> Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham: >>> On top of this, I made a (too simple at the moment) freeze_filesystems >>> function which iterates through _blocks in reverse order, freezing >>> fuse filesystems or ordinary ones. I say 'too simple' because it doesn't >>> currently allow for the possibility of someone mounting (say) ext3 on >>> fuse, but that would just be an extension of what's already done. >> How do you deal with fuse server tasks using other fuse filesystems? > Since they're frozen in reverse order, the dependant one would be frozen > first. Say I do: a) mount fuse on /tmp/first b) mount fuse on /tmp/second Then the server task for (a) does "ls /tmp/second". So it will be frozen, right? How do you then freeze (a)? And keep in mind that the server task may have forked. >>> I guess I should first ask, is this a real life problem or a >>> hypothetical twisted web? I don't see why you would want to make two >>> filesystems interdependent - it sounds like the way to create livelock >>> and deadlocks in normal use, before we even begin to think about >>> hibernating. >> Good questions. I personally don't use fuse, but I do care about power >> management. The problem I see is that an unprivileged user could make >> that dependency, even inadvertedly. > > Other problem is that unprivileged user can do it with evil intent. So > called "denial-of-service" attack. Only in this case it would be a denial-of-denial-of-service attack, since it would stop you hibernating or suspending :). This is still all hypothetical. If I could have a real life case where this could actually happen, it would help a lot. Nigel -- 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/
Regression: VIDIOCGMBUF ioctl hangs on bttv driver (2.6.24-rc6)
Hi,
During some tests I've noticed that the VIDIOCGMBUF ioctl hangs on my
bttv video device. It simply does not return and the process is stuck in
the D+ state. With Kernel 2.6.22.9 the (attached) testcase works like a
charm. The V4L2 interface is working with 2.6.24, too (at least displays
xawtv the usual pixel snow).
Hard and Software:
64 bit Linux 2.6.24-rc6 (todays pull) on a Intel Core 2 Duo
WinTV PCI:
05:02.0 0400: 109e:036e (rev 02)
05:02.1 0480: 109e:0878 (rev 02)
dmesg:
Rincewind:~# dmesg |grep bttv
bttv: driver version 0.9.17 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
bttv0: Bt878 (rev 2) at :05:02.0, irq: 23, latency: 64, mmio: 0xdfefe000
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,autodetected]
bttv0: gpio: en=, out= in=00db [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
bttv0: Hauppauge eeprom indicates model#61324
bttv0: tuner type=14
bttv0: i2c: checking for MSP34xx @ 0x80... found
bttv0: i2c: checking for TDA9875 @ 0xb0... not found
bttv0: i2c: checking for TDA7432 @ 0x8a... not found
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: registered device radio0
bttv0: PLL: 28636363 => 35468950 .. ok
from /proc/interrupts:
23: 55900 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb5,
bttv0
If I could help with more logs, a bisection, some debug printks, please contact
me.
Thanks!
Gregor
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int main( int argc, char *argv[])
{
const char device[] = "/dev/video0";
int r;
int fd = open (device, O_RDWR);
assert(fd);
struct video_mbuf mbuf = { 0 };
r = ioctl (fd, VIDIOCGMBUF, );
assert (r == 0);
printf ("Frames: %i\n", mbuf.frames);
close (fd);
return 0;
}
[PATCH] system timer: fix crash in <100Hz system timer
The kernel has a divide by zero crash when trying to run the system
timer less than 100Hz. The problem is x/(HZ/USER_HZ) and related.
Now x*(USER_HZ/HZ) will be used if HZ
--
David Fries <[EMAIL PROTECTED]>
http://fries.net/~david/ (PGP encryption key available)
diff --git a/include/linux/acct.h b/include/linux/acct.h
index 302eb72..86b848d 100644
--- a/include/linux/acct.h
+++ b/include/linux/acct.h
@@ -173,7 +173,11 @@ typedef struct acct acct_t;
static inline u32 jiffies_to_AHZ(unsigned long x)
{
#if (TICK_NSEC % (NSEC_PER_SEC / AHZ)) == 0
- return x / (HZ / AHZ);
+ #if HZ < AHZ
+ return x * (AHZ / HZ);
+ #else
+ return x / (HZ / AHZ);
+ #endif
#else
u64 tmp = (u64)x * TICK_NSEC;
do_div(tmp, (NSEC_PER_SEC / AHZ));
diff --git a/kernel/time.c b/kernel/time.c
index 09d3c45..23af26f 100644
--- a/kernel/time.c
+++ b/kernel/time.c
@@ -565,7 +565,11 @@ EXPORT_SYMBOL(jiffies_to_timeval);
clock_t jiffies_to_clock_t(long x)
{
#if (TICK_NSEC % (NSEC_PER_SEC / USER_HZ)) == 0
+ #if HZ < USER_HZ
+ return x * (USER_HZ / HZ);
+ #else
return x / (HZ / USER_HZ);
+ #endif
#else
u64 tmp = (u64)x * TICK_NSEC;
do_div(tmp, (NSEC_PER_SEC / USER_HZ));
@@ -598,7 +602,12 @@ EXPORT_SYMBOL(clock_t_to_jiffies);
u64 jiffies_64_to_clock_t(u64 x)
{
#if (TICK_NSEC % (NSEC_PER_SEC / USER_HZ)) == 0
- do_div(x, HZ / USER_HZ);
+ #if HZ < USER_HZ
+ x *= USER_HZ;
+ do_div(x, HZ);
+ #else
+ do_div(x, HZ / USER_HZ);
+ #endif
#else
/*
* There are better ways that don't overflow early,
pgpDGxaNrzHTU.pgp
Description: PGP signature
Re: [PATCH] mmc: Handle suspend/resume in Ricoh MMC disabler
On Sat, 29 Dec 2007 00:11:42 -0800 Philip Langdale <[EMAIL PROTECTED]> wrote: > As pci config space is reinitialised on a suspend/resume cycle, the > disabler needs to work its magic at resume time. For symmetry this > change also explicitly enables the controller at suspend time but > it's not strictly necessary. > > Signed-off-by: Philipl Langdale <[EMAIL PROTECTED]> > Thanks applied. Your patch was a bit borked though (a bunch of extra spaces). You should have a look at that for future patches. Rgds Pierre signature.asc Description: PGP signature
Re: [patch 2.6.24-rc6-mm 4/9] gpiolib: avr32 at32ap platform support
On Saturday 05 January 2008, Haavard Skinnemoen wrote: > On Sat, 5 Jan 2008 12:10:56 -0800 > David Brownell <[EMAIL PROTECTED]> wrote: > > > From: David Brownell <[EMAIL PROTECTED]> > > > > Teach AVR32 to use the "GPIO Library" when exposing its GPIOs, so that > > signals on external chips (like GPIO expanders) can easily be used. > > > > This mostly reorganizes some existing logic ... > > Acked-by: Haavard Skinnemoen <[EMAIL PROTECTED]> Thanks ... an ack is better than that informal "OK". ;) > I'm not going to merge it since the rest of gpiolib isn't in mainline > yet. Right. That's why the PXA support is going through Andrew too. -- 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: Can ARM use drivers/Kconfig [Was: Kconfig: Source "drivers/usb/gadget/Kconfig" for ARCH=arm]
On Saturday 05 January 2008, Russell King wrote: > Not everything in drivers/ is suitable for every ARM configuration. It > was felt at the time better for ARM to remain separate because people > didn't want to pollute drivers/Kconfig with the ARM specific conditionals. We made drivers/Kconfig work for s390 in the meantime, which is far more special than arm in this regard, so I think you should try to give it another go. What are the main obstacles on arm that prevent you from building these drivers? Arnd <>< -- 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.24-rc6-mm1
On Jan 5, 2008 3:52 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> On Jan 5, 2008 11:13 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > On Sat, Jan 05, 2008 at 09:01:02AM +0100, Torsten Kaiser wrote:
> > > On Jan 5, 2008 1:07 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > > > I think it would be easier just to start with this working -rc6 and
> > > > simply check if we have 'right' suspects, so: git-net.patch and
> > > > git-nfsd.patch from -mm1-broken-out, as suggested by Herbert (I hope,
> > > > can compile - otherwise you could try the other way: add the whole -mm
> > > > and revert these two). Using current gits could complicate this
> > > > "investigation".
> > >
> > > OK, I will try this...
>
> still on the todo-list, I had no time to try this yet...
working on it...
2.6.24-rc6 + mm-patches up to git.battery (includes git-net and
git-netdev-all) worked for 110 packages, then I proclaimed it good.
2.6.24-rc6 + mm-patches up to (including) git.nfsd is currently
getting testet (9 packages done...)
But the cause of my mail is the following question:
Regarding my "iommu-sg-merging-patches are new in -rc3-mm and could be
the cause"-suspicion I looked at these patches and came across these
hunks:
This is removed from arch/x86/lib/bitstr_64.c:
-/* Find string of zero bits in a bitmap */
-unsigned long
-find_next_zero_string(unsigned long *bitmap, long start, long nbits, int len)
-{
- unsigned long n, end, i;
-
- again:
- n = find_next_zero_bit(bitmap, nbits, start);
- if (n == -1)
- return -1;
-
- /* could test bitsliced, but it's hardly worth it */
- end = n+len;
- if (end > nbits)
- return -1;
- for (i = n+1; i < end; i++) {
- if (test_bit(i, bitmap)) {
- start = i+1;
- goto again;
- }
- }
- return n;
-}
This is added to lib/iommu-helper.c:
+static unsigned long find_next_zero_area(unsigned long *map,
+unsigned long size,
+unsigned long start,
+unsigned int nr)
+{
+ unsigned long index, end, i;
+again:
+ index = find_next_zero_bit(map, size, start);
+ end = index + nr;
+ if (end > size)
+ return -1;
+ for (i = index + 1; i < end; i++) {
+ if (test_bit(i, map)) {
+ start = i+1;
+ goto again;
+ }
+ }
+ return index;
+}
The old version checks, if find_next_zero_bit returns -1, the new
version doesn't do this.
Is this intended and can find_next_zero_bit never fail?
Hmm... but in the worst case it should only loop forever if I'm
reading this right (index = -1 => for-loop counts from 0 to nr, if any
bit is set it will jump to "again:" and if the next call to
find_next_zero_bit also fails, its an endless loop)
So even if this can not explain my bug, could somebody check if this
is a real bug or not?
Torsten
--
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] PM: Acquire device locks on suspend
On Saturday, 5 of January 2008, Alan Stern wrote:
> On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
>
> > On Saturday, 5 of January 2008, Alan Stern wrote:
> > > On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
> > >
> > > > > Another thing to watch out for: Just in case somebody ends up calling
> > > > > destroy_suspended_device(dev) from within dev's own resume method,
> > > > > you
> > > > > should interchange the resume_device() and the list_move_tail()
> > > > > calls in dpm_resume().
> > > >
> > > > However, if we unregister them all at once after releasing
> > > > pm_sleep_rwsem,
> > > > that shouldn't be necessary, right?
> > >
> > > It's still necessary, because destroy_suspended_device() still has to
> > > move the device from one list to another. You don't want it to end up
> > > on the dpm_locked list.
> >
> > Hmm. That means we'd have to do the same thing in dpm_power_up() in case
> > someone calls destroy_suspended_device() from resume_device_early(dev).
>
> Yes.
>
> > Still, even doing that is not enough, since someone can call
> > destroy_suspended_device() from a .suspend() routine and then the device
> > will end up on a wrong list just as well.
>
> That should never happen. The whole idea of destroy_suspended_device()
> is that the device couldn't be resumed and in fact should be
> unregistered because it is no longer working or no longer present. A
> suspend routine won't detect this sort of thing since it doesn't try to
> resume the device.
>
> But it wouldn't hurt to mention in the kerneldoc that
> destroy_suspended_device() is meant to be called only during a system
> resume.
Hmm. Please have a look at the appended patch.
I have removed the warning from device_del() and used list_empty() to detect
removed devices in the .suspend() routines. Is that viable?
Rafael
---
arch/x86/kernel/cpuid.c|6
arch/x86/kernel/msr.c |6
drivers/base/core.c| 67 +-
drivers/base/power/main.c | 454 ++---
drivers/base/power/power.h | 12 +
include/linux/device.h |8
6 files changed, 354 insertions(+), 199 deletions(-)
Index: linux-2.6/drivers/base/core.c
===
--- linux-2.6.orig/drivers/base/core.c
+++ linux-2.6/drivers/base/core.c
@@ -726,11 +726,20 @@ int device_add(struct device *dev)
{
struct device *parent = NULL;
struct class_interface *class_intf;
- int error = -EINVAL;
+ int error;
+
+ error = pm_sleep_lock();
+ if (error) {
+ dev_warn(dev, "Illegal %s during suspend\n", __FUNCTION__);
+ dump_stack();
+ return error;
+ }
dev = get_device(dev);
- if (!dev || !strlen(dev->bus_id))
- goto Error;
+ if (!dev || !strlen(dev->bus_id)) {
+ error = -EINVAL;
+ goto Done;
+ }
pr_debug("DEV: registering device: ID = '%s'\n", dev->bus_id);
@@ -795,6 +804,7 @@ int device_add(struct device *dev)
}
Done:
put_device(dev);
+ pm_sleep_unlock();
return error;
BusError:
device_pm_remove(dev);
@@ -1156,14 +1173,11 @@ error:
EXPORT_SYMBOL_GPL(device_create);
/**
- * device_destroy - removes a device that was created with device_create()
+ * find_device - finds a device that was created with device_create()
* @class: pointer to the struct class that this device was registered with
* @devt: the dev_t of the device that was previously registered
- *
- * This call unregisters and cleans up a device that was created with a
- * call to device_create().
*/
-void device_destroy(struct class *class, dev_t devt)
+static struct device *find_device(struct class *class, dev_t devt)
{
struct device *dev = NULL;
struct device *dev_tmp;
@@ -1176,12 +1190,49 @@ void device_destroy(struct class *class,
}
}
up(>sem);
+ return dev;
+}
+
+/**
+ * device_destroy - removes a device that was created with device_create()
+ * @class: pointer to the struct class that this device was registered with
+ * @devt: the dev_t of the device that was previously registered
+ *
+ * This call unregisters and cleans up a device that was created with a
+ * call to device_create().
+ */
+void device_destroy(struct class *class, dev_t devt)
+{
+ struct device *dev;
+ dev = find_device(class, devt);
if (dev)
device_unregister(dev);
}
EXPORT_SYMBOL_GPL(device_destroy);
+#ifdef CONFIG_PM_SLEEP
+/**
+ * destroy_suspended_device - asks the PM core to remove a suspended device
+ * @class: pointer to the struct class that this device was registered with
+ * @devt: the dev_t of the device that was previously registered
+ *
+ * This call causes the PM core to release and unregister a suspended device
+ * created with a call to device_create() (devices cannot be unregistered
+ * directly
Re: rtl8187 rate control doesn't work
On Jan 5, 2008 9:47 AM, Hauke Mehrtens <[EMAIL PROTECTED]> wrote: > Hi > > Now the compat-wireless-2.6 package is working and I get an Internet > connection with my rtl8187 based card. (It's on an ASUS P5B Deluxe) > > I used the compat-wireless-2.6 package for this log, but I have the same > problem with the version integrated in kernel 2.6.24-rc6 > > The Access Point is some rooms away so the signal is not the best at my > location. When starting the device with no fixed rate it wants to > connect with 54MBit/s and as iwconfig says it was successful but I can't > ping any device in the wireless LAN. (it's the first part of the log) > The rate will not be slowed down it stays fixed at 54MBit/s. > > After starting the device with rate fixed to 11M I get a connection to > the Access Point and iwconfig's output looks the same as without fixed > rate, but I'm able to ping the all devices in the network. (second part > of the log) > Now it slows down the rate to 1MBit/s Seems to be the new PID rate control algorithm. I believe Stephano (CC'd) was sending some patches for this. Please try changing in config.mk >From this value: CONFIG_MAC80211_RC_DEFAULT=pid To this: CONFIG_MAC80211_RC_DEFAULT=simple and let us know how that goes. Oh and linux-kernel is the wrong list to use, please just use linux-wireless for future e-mails. Luis -- 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-usb-devel] [FEATURE REQUEST] Transparent hot plugging of root file system on portable storage devices.
On Wed 2008-01-02 15:23:30, Alan Stern wrote: > On Wed, 2 Jan 2008, Oliver Neukum wrote: > > > Am Dienstag 01 Januar 2008 schrieb Pavel Machek: > > > Hi1 > > > > > > > I would like to request a feature in the Linux kernel that would allow > > > > a user to unplug a live read-only root file system which exists on a > > > > detachable storage device such as a USB key drive. The desired > > > > behavior is that once the same device is reattached to the computer > > > > the user can continue work transparently without having to reboot. > > > > > > > > Having such a feature is becoming more important with advances in > > > > detachable solid state drive technology. > > > > > > Yep, that would be nice In fact, patch would be very welcome :-). > > > > Use the USB persist feature and hibernate. It should work. If you modify > > the fs in any way, you'll crash and burn. Unmounting / is harder which you > > need if you want to do this safely. > > What about people who prefer (for reasons of restart latency or > non-availability of swap space) to suspend rather than hibernate? For suspend to RAM, we can keep the power session, and be _sure_ noone unplugged our USB disks, right? So that one should work nicely. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: [RFC] sleepy linux
On Sun 2007-12-30 12:15:52, Ingo Molnar wrote: > > * Pavel Machek <[EMAIL PROTECTED]> wrote: > > > Todays hardware is mostly capable of doing better: with correctly set > > up wakeups, machine can sleep and successfully pretend it is not > > sleeping -- by waking up whenever something interesting happens. Of > > course, it is easier on machines not connected to the network, and on > > notebook computers. > > > > Requirements: > > > > 0) Working suspend-to-RAM, with kernel being able to bring video back. > > > > 1) RTC clock that can wake up system > > very nice approach! It might require smarter hardware to be really > efficient, but the generic ability for Linux to utilize S3 automatically > would _quickly_ drive the creation of smarter hardware i'm sure - so i'd > propose to include this even if it wastes power in some cases. > > a quick feature request: could you please make the wake-on-RTC > capability generic and add a CONFIG_DEBUG_SUSPEND_ON_RAM=y config option > (disabled by default) that does a short 1-second suspend-to-RAM sequence > upon bootup? That way we could test s2ram automatically (which is a MUCH > needed feature for automated regression testing and automatic > bisection). In addition, some sort of 'suspend for N seconds' /sys or > /dev/rtc capability would be nice as well. Hmm, are you sure it is good idea to do this from kernel? I guess this is better done from script... > btw., how far are you from having a working prototype? SCSI/SATA issues stop me just now, but even if I get that to work, it will be extremely disgusting hack... and it is unclear how to do it nicely :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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.24-rc6-mm 4/9] gpiolib: avr32 at32ap platform support
On Sat, 5 Jan 2008 12:10:56 -0800 David Brownell <[EMAIL PROTECTED]> wrote: > From: David Brownell <[EMAIL PROTECTED]> > > Teach AVR32 to use the "GPIO Library" when exposing its GPIOs, so that > signals on external chips (like GPIO expanders) can easily be used. > > This mostly reorganizes some existing logic, with two minor changes > in behavior: > > - The PSR registers are used instead of the previous "gpio_mask" > values, matching AT91 behavior and removing some duplication between > that role and that of "pinmux_mask". > > - NR_IRQs grew to acommodate a bank of external GPIOs. Eventually > this number should probably become a board-specific config option. > > There's a debugfs dump of status for the built-in GPIOs, showing which > pins have deglitching, pullups, or open drain drive enabled, as well > as the ID string used when requesting each IRQ. > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> > Cc: Haavard Skinnemoen <[EMAIL PROTECTED]> Acked-by: Haavard Skinnemoen <[EMAIL PROTECTED]> I'm not going to merge it since the rest of gpiolib isn't in mainline yet. Haavard -- 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/
[2.6.24 patch] fix netx-eth.c compilation
This was missed when commit e2ac455a18806b31c2d0da0a51d8740af5010b7a fixed the compile errors in drivers/net/netx-eth.c caused by commit 09f75cd7bf13720738e6a196cc0107ce9a5bd5a0. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- 15e5efb728c61333ca10648334185efba86c4815 diff --git a/drivers/net/netx-eth.c b/drivers/net/netx-eth.c index 5267e03..78d34af 100644 --- a/drivers/net/netx-eth.c +++ b/drivers/net/netx-eth.c @@ -169,8 +169,8 @@ static void netx_eth_receive(struct net_device *ndev) ndev->last_rx = jiffies; skb->protocol = eth_type_trans(skb, ndev); netif_rx(skb); - dev->stats.rx_packets++; - dev->stats.rx_bytes += len; + ndev->stats.rx_packets++; + ndev->stats.rx_bytes += len; } static irqreturn_t -- 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: Kohjinsha sleep problems
Hi!
> > > On kohjinsha, wakeup code does not seem to be reached at all. I tried
> > > looking around FACS, but it seems very empty:
> > >
> > > ...
> >
> > The same on my laptop:
> >
> > FACS @ 0x2fefafc0
signature length hwsignature waking_vector
> > : 46 41 43 53 40 00 00 00 62 12 00 00 00 00 00 00 [EMAIL PROTECTED]
> > 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >
> >
> > I've never been able to resume from STR with Linux (works with Windows
> > Vista).
> > STD works, although I have to press the power button in order to
> > resume.
Hmm, that is strange. firmware_waking_vector seems to be all
zeros. How can that work?
struct acpi_table_facs {
char signature[4]; /* ASCII table signature */
u32 length; /* Length of structure, in bytes */
u32 hardware_signature; /* Hardware configuration signature */
u32 firmware_waking_vector; /* 32-bit physical address of
the Firmware Waking Vector */
...aha, firmware_waking_vector is to be filled by Linux, so I guess
this was false alarm.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] PM: Acquire device locks on suspend
On Sat, 5 Jan 2008, Rafael J. Wysocki wrote: > On Saturday, 5 of January 2008, Alan Stern wrote: > > On Sat, 5 Jan 2008, Rafael J. Wysocki wrote: > > > > > > Another thing to watch out for: Just in case somebody ends up calling > > > > destroy_suspended_device(dev) from within dev's own resume method, you > > > > should interchange the resume_device() and the list_move_tail() > > > > calls in dpm_resume(). > > > > > > However, if we unregister them all at once after releasing pm_sleep_rwsem, > > > that shouldn't be necessary, right? > > > > It's still necessary, because destroy_suspended_device() still has to > > move the device from one list to another. You don't want it to end up > > on the dpm_locked list. > > Hmm. That means we'd have to do the same thing in dpm_power_up() in case > someone calls destroy_suspended_device() from resume_device_early(dev). Yes. > Still, even doing that is not enough, since someone can call > destroy_suspended_device() from a .suspend() routine and then the device > will end up on a wrong list just as well. That should never happen. The whole idea of destroy_suspended_device() is that the device couldn't be resumed and in fact should be unregistered because it is no longer working or no longer present. A suspend routine won't detect this sort of thing since it doesn't try to resume the device. But it wouldn't hurt to mention in the kerneldoc that destroy_suspended_device() is meant to be called only during a system resume. Alan Stern -- 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: Top 10 kernel oopses for the week ending January 5th, 2008
On Sat, Jan 05, 2008 at 01:06:17PM -0800, Arjan van de Ven wrote: > The http://www.kerneloops.org website collects kernel oops and > warning reports from various mailing lists and bugzillas as well as > with a client users can install to auto-submit oopses. > Below is a top 10 list of the oopses collected in the last 7 days. > (Reports prior to 2.6.23 have been omitted in collecting the top 10) > > This week, a total of 49 oopses and warnings have been reported, > compared to 53 reports in the previous week. FWIW, people moaning about the lack of entry-level kernel work would do well by decoding those to the level of "this place in this function, called from , with so-and-so variable being " and posting the results. As skills go, it's far more useful than "how to trim the trailing whitespace" and the rest of checkpatch.pl-inspired crap that got so popular lately... -- 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.24-rc6: possible recursive locking detected
On Sat, 5 Jan 2008, Peter Zijlstra wrote:
>
> On Sat, 2008-01-05 at 17:53 +0100, Peter Zijlstra wrote:
> > On Sat, 2008-01-05 at 18:12 +1100, Herbert Xu wrote:
> > > On Fri, Jan 04, 2008 at 09:30:49AM +0100, Ingo Molnar wrote:
> > > >
> > > > > > [ 1310.670986] =
> > > > > > [ 1310.671690] [ INFO: possible recursive locking detected ]
> > > > > > [ 1310.672097] 2.6.24-rc6 #1
> > > > > > [ 1310.672421] -
> > > > > > [ 1310.672828] FahCore_a0.exe/3692 is trying to acquire lock:
> > > > > > [ 1310.673238] (>lock){++..}, at: []
> > > > > > __wake_up+0x1b/0x50
> > > > > > [ 1310.673869]
> > > > > > [ 1310.673870] but task is already holding lock:
> > > > > > [ 1310.674567] (>lock){++..}, at: []
> > > > > > __wake_up+0x1b/0x50
> > > > > > [ 1310.675267]
> > > > > > [ 1310.675268] other info that might help us debug this:
> > > > > > [ 1310.675952] 5 locks held by FahCore_a0.exe/3692:
> > > > > > [ 1310.676334] #0: (rcu_read_lock){..--}, at: []
> > > > > > net_rx_action+0x60/0x1b0
> > > > > > [ 1310.677251] #1: (rcu_read_lock){..--}, at: []
> > > > > > netif_receive_skb+0x100/0x470
> > > > > > [ 1310.677924] #2: (rcu_read_lock){..--}, at: []
> > > > > > ip_local_deliver_finish+0x32/0x210
> > > > > > [ 1310.678460] #3: (clock-AF_INET){-.-?}, at: []
> > > > > > sock_def_readable+0x1e/0x80
> > > > > > [ 1310.679250] #4: (>lock){++..}, at: []
> > > > > > __wake_up+0x1b/0x50
> > >
> > > The net part might just be a red herring, since the problem is that
> > > __wake_up is somehow reentering itself.
> >
> > /*
> > * Perform a safe wake up of the poll wait list. The problem is that
> > * with the new callback'd wake up system, it is possible that the
> > * poll callback is reentered from inside the call to wake_up() done
> > * on the poll wait queue head. The rule is that we cannot reenter the
> > * wake up code from the same task more than EP_MAX_POLLWAKE_NESTS times,
> > * and we cannot reenter the same wait queue head at all. This will
> > * enable to have a hierarchy of epoll file descriptor of no more than
> > * EP_MAX_POLLWAKE_NESTS deep. We need the irq version of the spin lock
> > * because this one gets called by the poll callback, that in turn is called
> > * from inside a wake_up(), that might be called from irq context.
> > */
> >
> > Seems to suggest that the epoll code can indeed recurse into wakeup.
> >
> > Davide, Johannes, any ideas?
>
> Since EP_MAX_POLLWAKE_NESTS < MAX_LOCKDEP_SUBCLASSES we could perhaps do
> something like:
>
> wake_up_nested(..., wake_nests);
>
> although I'm not quite sure that is correct, my understanding of this
> code is still fragile at best.
I remember I talked with Arjan about this time ago. Basically, since 1)
you can drop an epoll fd inside another epoll fd 2) callback-based wakeups
are used, you can see a wake_up() from inside another wake_up(), but they
will never refer to the same lock instance.
Think about:
dfd = socket(...);
efd1 = epoll_create();
efd2 = epoll_create();
epoll_ctl(efd1, EPOLL_CTL_ADD, dfd, ...);
epoll_ctl(efd2, EPOLL_CTL_ADD, efd1, ...);
When a packet arrives to the device underneath "dfd", the net code will
issue a wake_up() on its poll wake list. Epoll (efd1) has installed a
callback wakeup entry on that queue, and the wake_up() performed by the
"dfd" net code will end up in ep_poll_callback(). At this point epoll
(efd1) notices that it may have some event ready, so it needs to wake up
the waiters on its poll wait list (efd2). So it calls ep_poll_safewake()
that ends up in another wake_up(), after having checked about the
recursion constraints. That are, no more than EP_MAX_POLLWAKE_NESTS, to
avoid stack blasting. Never hit the same queue, to avoid loops like:
epoll_ctl(efd2, EPOLL_CTL_ADD, efd1, ...);
epoll_ctl(efd3, EPOLL_CTL_ADD, efd2, ...);
epoll_ctl(efd4, EPOLL_CTL_ADD, efd3, ...);
epoll_ctl(efd1, EPOLL_CTL_ADD, efd4, ...);
The code "if (tncur->wq == wq || ..." prevents re-entering the same
queue/lock.
I don't know how the lockdep code works, so I can't say about
wake_up_nested(). Although I have a feeling is not enough in this case.
A solution may be to move the call to ep_poll_safewake() (that'd become a
simple wake_up()) inside a tasklet or whatever is today trendy for delayed
work. But his kinda scares me to be honest, since epoll has already a
bunch of places where it could be asynchronously hit (plus performance
regression will need to be verified).
- Davide
--
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: Kohjinsha sleep problems
HI! > > On kohjinsha, wakeup code does not seem to be reached at all. I tried > > looking around FACS, but it seems very empty: > > > > ... > > The same on my laptop: > > FACS @ 0x2fefafc0 > : 46 41 43 53 40 00 00 00 62 12 00 00 00 00 00 00 [EMAIL PROTECTED] > 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > I've never been able to resume from STR with Linux (works with Windows > Vista). > STD works, although I have to press the power button in order to > resume. Hmm, it is pretty empty on thinkpad x60, too, and s2ram actually works here: [EMAIL PROTECTED]:/home/pavel# acpidump -t FACS FACS @ 0x7f6f4000 : 46 41 43 53 40 00 00 00 95 15 00 00 00 00 00 00 [EMAIL PROTECTED] 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...and iasl actually segfaults here, too :-( [EMAIL PROTECTED]:/data/l/kohji# iasl -d FACS.x60.aml Intel ACPI Component Architecture AML Disassembler version 20061109 [May 18 2007] Copyright (C) 2000 - 2006 Intel Corporation Supports ACPI Specification Revision 3.0a Loading Acpi table from file FACS.x60.aml Segmentation fault (core dumped) [EMAIL PROTECTED]:/data/l/kohji# ...hmm, if it is buffer overflow, we have security problem in iasl. Anyway, how do I decode FACS? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: BUG: unable to handle kernel paging request at virtual address
On Sun, 6 Jan 2008 00:20:50 +0300 Alexey Dobriyan <[EMAIL PROTECTED]> wrote: > netconsole should be more quick: Thanks a lot for the tip, I'll try that. Alexander -- 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: Top 10 kernel oopses for the week ending January 5th, 2008
On Sat, Jan 05, 2008 at 01:06:17PM -0800, Arjan van de Ven wrote: > Rank 3: d_splice_alias > NULL pointer deref > Reported 3 times > Happens in the isofs code > Only seen in 2.6.24-rc5-mm1 > More info: http://www.kerneloops.org/search.php?search=d_splice_alias in -rc6-mm1 as well, fixes on l-k... > Rank 8: evdev_disconnect > kernel page fault > Reported 2 times (10 total reports) > Previously seen in older kernels including 2.6.21 but as far back as > 2.6.16 > More info: > http://www.kerneloops.org/search.php?search=evdev_disconnect Practically certain to be fixed by 6addb1d6de1968b84852f54561cc9a09b5a9; it's list_for_each_entry() walking from the entry that just got list_del() and kernels without that sucker have no protection of the list in question whatsoever. > Rank 9: mutex_lock > kernel null pointer due to rfcomm_tty_close sysfs interaction > Reported 2 times (9 total reports) > Ranked 9th last week as well > More info: http://www.kerneloops.org/search.php?search=mutex_lock pissfs locking problems; AFAICS, its sysfs_get_dentry() walking into already unlinked sysfs directory node on the way to target; no exclusion against that is there and it's not trivial to add. -- 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] [Coding Style]: misc fixes for fs/ext{3,4}/acl.{c,h} from checkpatch.pl
On Jan 4 2008 19:39, Theodore Tso wrote: >On Sat, Jan 05, 2008 at 01:12:44AM +0100, Paolo Ciarrocchi wrote: > >But because running some kind of mechanical script and fixing up the >problems is relatively mindless, it doesn't *add* anything. Only the >maintainer knows when it is a reasonably convenient time to fix all of >the problems, or when to fix portions of the code that is being >reworked anyway --- and the maintainer can just run the script by >himself, for himself. I have to agree. Best use of checkpatch is right before submitting, uh, a patch actually. The option that makes it work on non-patch files should be, hm, hidden or removed. -- 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: BUG: unable to handle kernel paging request at virtual address
On Sun, Jan 06, 2008 at 12:30:34AM +0400, Alexander Shaduri wrote:
> > Get a serial console? Take another box, plug e.g. pl2303-based
> > usb-to-serial (several bucks these days) into it, stick null-modem
> > convertor (ditto) on its serial end and attach to ttyS0 on the
> > victim. console=ttyS0 on victim, something like minicom on watcher
> > and tell it to capture log into file...
>
> I will try that (as soon as I acquire the necessary parts).
netconsole should be more quick:
* one more box with ethernet card
* CONFIG_NETCONSOLE=y
* CONFIG_ {your NIC driver} =y
* on crashing box add the following line to the kernel boot options
[EMAIL PROTECTED]/eth0,[EMAIL PROTECTED]/dst-MAC
where scr-ip -- IP of crashing box
eth0 -- interface on crashing box
9353 -- destination port (for netcat to listen on target box)
dst-ip -- IP of a box which collect logs
dst-MAC -- MAC of the interface on destination box
* on destination box run netcat
nc -u -l -p 9353 &>1.log
[* add ignore_loglevel on crashing box if paranoid]
Now reboot crashing box and reproduce the bug, chances are high that it
will send oops over network.
--
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: freeze vs freezer
On Fri 2008-01-04 21:54:06, Oliver Neukum wrote: > Am Donnerstag, 3. Januar 2008 23:06:07 schrieb Nigel Cunningham: > > Hi. > > > > Oliver Neukum wrote: > > > Am Donnerstag, 3. Januar 2008 10:52:53 schrieb Nigel Cunningham: > > >> Hi. > > >> > > >> Oliver Neukum wrote: > > >>> Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham: > > On top of this, I made a (too simple at the moment) freeze_filesystems > > function which iterates through _blocks in reverse order, > > freezing > > fuse filesystems or ordinary ones. I say 'too simple' because it > > doesn't > > currently allow for the possibility of someone mounting (say) ext3 on > > fuse, but that would just be an extension of what's already done. > > >>> How do you deal with fuse server tasks using other fuse filesystems? > > >> Since they're frozen in reverse order, the dependant one would be frozen > > >> first. > > > > > > Say I do: > > > > > > a) mount fuse on /tmp/first > > > b) mount fuse on /tmp/second > > > > > > Then the server task for (a) does "ls /tmp/second". So it will be frozen, > > > right? How do you then freeze (a)? And keep in mind that the server task > > > may have forked. > > > > I guess I should first ask, is this a real life problem or a > > hypothetical twisted web? I don't see why you would want to make two > > filesystems interdependent - it sounds like the way to create livelock > > and deadlocks in normal use, before we even begin to think about > > hibernating. > > Good questions. I personally don't use fuse, but I do care about power > management. The problem I see is that an unprivileged user could make > that dependency, even inadvertedly. Other problem is that unprivileged user can do it with evil intent. So called "denial-of-service" attack. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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/
