Re: [PATCH] Chinese translation of Documentation/HOWTO
On Wed, Jun 20, 2007 at 05:22:49AM +, dave young wrote: > Hi, > 2007/6/20, Li Yang-r58472 <[EMAIL PROTECTED]>: > > > -Original Message- > > > From: dave young [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, June 20, 2007 9:58 AM > > > To: WANG Cong > > > Cc: Li Yang-r58472; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; > > TripleX Chung; > > > Maggie Chen; Tejun Heo; Fengguang Wu; Chen Li-jun > > > Subject: Re: [PATCH] Chinese translation of Documentation/HOWTO > > > > > > Hi, > > > IMHO, it is not very suitable for translations merging into kernel. > > > > > > first, It's impossible to be 100% accurate. > > > > It can be accurate by meaning. And it can be improved. > > > > > second, two or more language need to be synced with english one, it's > > > a problem in the long run. > > > > This can be done through good maintenance. I don't think it's harder > > than maintaining the code in kernel source tree. > > Yes, but the documents updating are always late than the sources. These files change _very_ slowly, only 5 minor changes in the past 3 years or so. I think the translators can keep up with that :) thanks, greg k-h - 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/
[RFC PATCH 4/4] Directory listing support for union mounted directories.
From: Bharata B Rao <[EMAIL PROTECTED]>
Subject: Directory listing support for union mounted directories.
Modifies readdir()/getdents() to support union mounted directories.
This patch adds support to readdir()/getdents() to read directory entries
from all the directories of the union stack, and present a merged view to
the userspace. This is achieved by maintaining a cache of read entries.
TODO: Breaks lseek on union mounted directories, Fix this.
Signed-off-by: Bharata B Rao <[EMAIL PROTECTED]>
---
fs/file_table.c|1
fs/readdir.c | 242 -
include/linux/fs.h | 12 ++
3 files changed, 254 insertions(+), 1 deletion(-)
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -174,6 +174,7 @@ void fastcall __fput(struct file *file)
if (file->f_mode & FMODE_WRITE)
put_write_access(inode);
put_pid(file->f_owner.pid);
+ put_rdstate(file->f_rdstate);
file_kill(file);
file->f_path.dentry = NULL;
file->f_path.mnt = NULL;
--- a/fs/readdir.c
+++ b/fs/readdir.c
@@ -19,6 +19,8 @@
#include
+int readdir_union(struct file *file, void *buf, filldir_t filler);
+
int vfs_readdir(struct file *file, filldir_t filler, void *buf)
{
struct inode *inode = file->f_path.dentry->d_inode;
@@ -33,7 +35,10 @@ int vfs_readdir(struct file *file, filld
mutex_lock(>i_mutex);
res = -ENOENT;
if (!IS_DEADDIR(inode)) {
- res = file->f_op->readdir(file, buf, filler);
+ if (IS_MNT_UNION(file->f_path.mnt))
+ res = readdir_union(file, buf, filler);
+ else
+ res = file->f_op->readdir(file, buf, filler);
file_accessed(file);
}
mutex_unlock(>i_mutex);
@@ -303,3 +308,238 @@ out_putf:
out:
return error;
}
+
+/*
+ * NOTE: Some of the code below which maintains a list of dirents as a cache
+ * is from Jan Blunck's original union mount readdir patch.
+ */
+
+/* The readdir cache object */
+struct rdcache_entry {
+ struct list_head list;
+ struct qstr name;
+};
+
+struct rdcache_callback {
+ void *buf; /* original callback buffer */
+ filldir_t filldir; /* the filldir() we should call */
+ int error; /* stores filldir error */
+ struct rdstate *rdstate;/* readdir state */
+};
+
+static int rdcache_add_entry(struct list_head *list,
+const char *name, int namelen)
+{
+ struct rdcache_entry *this;
+ char *tmp_name;
+
+ this = kmalloc(sizeof(*this), GFP_KERNEL);
+ if (!this) {
+ printk(KERN_CRIT "rdcache_add_entry(): out of kernel memory\n");
+ return -ENOMEM;
+ }
+
+ tmp_name = kmalloc(namelen + 1, GFP_KERNEL);
+ if (!tmp_name) {
+ printk(KERN_CRIT "rdcache_add_entry(): out of kernel memory\n");
+ kfree(this);
+ return -ENOMEM;
+ }
+
+ this->name.name = tmp_name;
+ this->name.len = namelen;
+ this->name.hash = 0;
+ memcpy(tmp_name, name, namelen);
+ tmp_name[namelen] = 0;
+ INIT_LIST_HEAD(>list);
+ list_add(>list, list);
+ return 0;
+}
+
+static void rdcache_free(struct list_head *list)
+{
+ struct list_head *p;
+ struct list_head *ptmp;
+ int count = 0;
+
+ list_for_each_safe(p, ptmp, list) {
+ struct rdcache_entry *this;
+
+ this = list_entry(p, struct rdcache_entry, list);
+ list_del_init(>list);
+ kfree(this->name.name);
+ kfree(this);
+ count++;
+ }
+ return;
+}
+
+static int rdcache_find_entry(struct list_head *uc_list,
+ const char *name, int namelen)
+{
+ struct rdcache_entry *p;
+ int ret = 0;
+
+ list_for_each_entry(p, uc_list, list) {
+ if (p->name.len != namelen)
+ continue;
+ if (strncmp(p->name.name, name, namelen) == 0) {
+ ret = 1;
+ break;
+ }
+ }
+ return ret;
+}
+
+/*
+ * filldir routine for union mounted directories.
+ * Handles duplicate elimination by building a readdir cache.
+ * TODO: readdir cache is a linked list. Check if this can be designed
+ * more efficiently.
+ */
+static int filldir_union(void *buf, const char *name, int namlen,
+ loff_t offset, u64 ino, unsigned int d_type)
+{
+ struct rdcache_callback *cb = buf;
+ int err;
+
+ if (rdcache_find_entry(>rdstate->dirent_cache, name, namlen))
+ return 0;
+
+ err = cb->filldir(cb->buf, name, namlen, offset, ino, d_type);
+ if (err >= 0)
+ rdcache_add_entry(>rdstate->dirent_cache, name, namlen);
+ cb->error = err;
+
[RFC PATCH 3/4] Lookup changes to support union mount.
From: Bharata B Rao <[EMAIL PROTECTED]>
Subject: Lookup changes to support union mount.
Adds support for looking up dentries inside a union mount point.
This patch modifies the do_lookup() routine to look beyond the top layer for
union mount points/directories. Union mount versions of dcache and real lookup
routines are added to support this. The lookup routines are modified to build a
new union stack when looking up a common named directory in the union stack.
TODO: Check if lookup_hash() and friends also need to know about union mount.
Signed-off-by: Bharata B Rao <[EMAIL PROTECTED]>
---
fs/dcache.c| 53 ++
fs/namei.c | 137 +++--
include/linux/dcache.h |1
3 files changed, 187 insertions(+), 4 deletions(-)
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1312,6 +1312,59 @@ next:
return found;
}
+/*
+ * Looks for the given @name in dcache by walking through all the layers
+ * of the union stack, starting from the top.
+ * FIXME: If we don't find the dentry in a upper layer, we descend to the
+ * next layer. So there is a chance to miss this dentry in the top layer
+ * if this is the _first_ time lookup of the dentry in this layer. A real
+ * lookup might have fetched a valid dentry in this layer itself, while we
+ * chose to descend to the next lower layer. One solution is not have this
+ * function itself, do the toplevel lookup in dcache and if it fails proceed
+ * to real_lookup_union() directly.
+ */
+struct dentry *__d_lookup_union(struct nameidata *nd, struct qstr *name)
+{
+ struct dentry *dentry;
+ struct nameidata nd_tmp;
+ struct vfsmount *mnt = mntget(nd->mnt);
+ struct qstr this;
+ int err;
+
+ nd_tmp.mnt = nd->mnt;
+ nd_tmp.dentry = nd->dentry;
+
+ this.name = name->name;
+ this.len = name->len;
+ this.hash = name->hash;
+
+ do {
+ /* d_hash() is a repetition for the top layer. */
+ if (nd_tmp.dentry->d_op && nd_tmp.dentry->d_op->d_hash) {
+ err = nd_tmp.dentry->d_op->d_hash(nd_tmp.dentry, );
+ if (err < 0)
+ goto out;
+ }
+
+ dentry = __d_lookup(nd_tmp.dentry, );
+ if (dentry) {
+ if (dentry->d_inode) {
+ if (nd->mnt != nd_tmp.mnt) {
+ mntput(nd->mnt);
+ nd->mnt = mntget(nd_tmp.mnt);
+ }
+ mntput(mnt);
+ return dentry;
+ } else {
+ dput(dentry);
+ }
+ }
+ } while (next_union_mount(_tmp));
+out:
+ mntput(mnt);
+ return NULL;
+}
+
/**
* d_hash_and_lookup - hash the qstr then search for a dentry
* @dir: Directory to search in
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -515,6 +515,127 @@ static struct dentry * real_lookup(struc
return result;
}
+/*
+ * Walks down the parent's union stack looking for the given @name.
+ * Builds unions at subdirectory levels if needed.
+ */
+static struct dentry *real_lookup_union(struct nameidata *nd, struct qstr
*name)
+{
+ struct dentry *dentry, *topmost, *prev = NULL;
+ struct nameidata nd_tmp;
+ struct vfsmount *mnt_prev = NULL;
+ struct vfsmount *mnt = mntget(nd->mnt);
+
+ topmost = real_lookup(nd->dentry, name, nd);
+ if (IS_ERR(topmost))
+ goto out;
+
+ /* Found a vaild non-directory dentry in the topmost layer, return. */
+ if (topmost->d_inode && !S_ISDIR(topmost->d_inode->i_mode))
+ goto out;
+
+ nd_tmp.mnt = nd->mnt;
+ nd_tmp.dentry = nd->dentry;
+
+ /*
+* At this point we either have a negative dentry or a directory
+* as the topmost dentry. Continue to lookup in the bottom layers.
+*/
+ while (next_union_mount(_tmp)) {
+ dentry = real_lookup(nd_tmp.dentry, name, _tmp);
+ /*
+* If there is an error, return the dentry from
+* the topmost layer.
+*/
+ if (IS_ERR(dentry))
+ goto out;
+
+ /*
+* Found a negative dentry in this layer, release it and
+* continue with the next layer.
+*/
+ if (!dentry->d_inode) {
+ dput(dentry);
+ continue;
+ }
+
+ /*
+* If we find a vaild non-directory dentry in this layer, And
+* - if the topmost dentry is negative, return this.
+* - or if the topmost dentry is valid (dir), return topmost.
+*/
+ if (!S_ISDIR(dentry->d_inode->i_mode)) {
[RFC PATCH 2/4] Mount changes to support union mount.
From: Bharata B Rao <[EMAIL PROTECTED]>
Subject: Mount changes to support union mount.
Adds union mount support.
This patch adds a new mount type for union mount (MNT_UNION) and changes
the mount path to build a union stack during mount. The routines for
supporting the creation, traversal and destruction of union stacks are
also included here.
Signed-off-by: Bharata B Rao <[EMAIL PROTECTED]>
---
fs/namespace.c| 164 ++
include/linux/fs.h|1
include/linux/mount.h | 17 +
3 files changed, 172 insertions(+), 10 deletions(-)
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -35,6 +35,7 @@ __cacheline_aligned_in_smp DEFINE_SPINLO
static int event;
static struct list_head *mount_hashtable __read_mostly;
+static struct list_head *union_mount_hashtable;
static int hash_mask __read_mostly, hash_bits __read_mostly;
static struct kmem_cache *mnt_cache __read_mostly;
static struct rw_semaphore namespace_sem;
@@ -54,6 +55,89 @@ static inline unsigned long hash(struct
return tmp & hash_mask;
}
+/* Must be called with vfsmount_lock held */
+static struct union_mount *find_union_mount(struct vfsmount *mnt,
+ struct dentry *dentry)
+{
+ struct list_head *head;
+ struct union_mount *u;
+
+ if (!IS_MNT_UNION(mnt))
+ return NULL;
+
+ head = union_mount_hashtable + hash(mnt, dentry);
+ list_for_each_entry(u, head, hash)
+ if (u->src_mnt == mnt && u->src_dentry == dentry)
+ return u;
+ return NULL;
+}
+
+/*
+ * When propagating mount events to peer group, this is called under
+ * vfsmount_lock. Hence using GFP_ATOMIC for kmalloc here.
+ * TODO: Can we use a separate kmem cache for union_mount ?
+ */
+struct union_mount *alloc_union_mount(struct vfsmount *src_mnt,
+ struct dentry *src_dentry, struct vfsmount *dst_mnt,
+ struct dentry *dst_dentry)
+{
+ struct union_mount *u;
+ u = kmalloc(sizeof(struct union_mount), GFP_ATOMIC);
+ if (!u)
+ return u;
+ u->dst_mnt = mntget(dst_mnt);
+ u->dst_dentry = dget(dst_dentry);
+ u->src_mnt = src_mnt;
+ u->src_dentry = dget(src_dentry);
+ INIT_LIST_HEAD(>hash);
+ INIT_LIST_HEAD(>list);
+ return u;
+}
+
+/* Must be called with vfsmount_lock held */
+void attach_mnt_union(struct union_mount *u)
+{
+ if (!u)
+ return;
+
+ list_add_tail(>hash, union_mount_hashtable +
+ hash(u->src_mnt, u->src_dentry));
+ list_add_tail(>list, >src_mnt->mnt_union);
+}
+
+/*
+ * Finds the next (vfsmount, dentry) in the union stack. If found, returns
+ * it via @nd and returns true. Else doesn't modify @nd, but returns false.
+ */
+int next_union_mount(struct nameidata *nd)
+{
+ struct union_mount *u;
+
+ spin_lock(_lock);
+ u = find_union_mount(nd->mnt, nd->dentry);
+ spin_unlock(_lock);
+ if (u) {
+ nd->mnt = u->dst_mnt;
+ nd->dentry = u->dst_dentry;
+ return 1;
+ }
+ return 0;
+}
+
+/* Check if next element of the union stack exists. @nd isn't modified. */
+int next_union_mount_exists(struct vfsmount *mnt, struct dentry *dentry)
+{
+ struct union_mount *u;
+
+ spin_lock(_lock);
+ u = find_union_mount(mnt, dentry);
+ spin_unlock(_lock);
+ if (u)
+ return 1;
+ else
+ return 0;
+}
+
struct vfsmount *alloc_vfsmnt(const char *name)
{
struct vfsmount *mnt = kmem_cache_zalloc(mnt_cache, GFP_KERNEL);
@@ -67,6 +151,7 @@ struct vfsmount *alloc_vfsmnt(const char
INIT_LIST_HEAD(>mnt_share);
INIT_LIST_HEAD(>mnt_slave_list);
INIT_LIST_HEAD(>mnt_slave);
+ INIT_LIST_HEAD(>mnt_union);
if (name) {
int size = strlen(name) + 1;
char *newname = kmalloc(size, GFP_KERNEL);
@@ -173,18 +258,20 @@ void mnt_set_mountpoint(struct vfsmount
dentry->d_mounted++;
}
-static void attach_mnt(struct vfsmount *mnt, struct nameidata *nd)
+static void attach_mnt(struct vfsmount *mnt, struct nameidata *nd,
+ struct union_mount *u)
{
mnt_set_mountpoint(nd->mnt, nd->dentry, mnt);
list_add_tail(>mnt_hash, mount_hashtable +
hash(nd->mnt, nd->dentry));
list_add_tail(>mnt_child, >mnt->mnt_mounts);
+ attach_mnt_union(u);
}
/*
* the caller must hold vfsmount_lock
*/
-static void commit_tree(struct vfsmount *mnt)
+static void commit_tree(struct vfsmount *mnt, struct union_mount *u)
{
struct vfsmount *parent = mnt->mnt_parent;
struct vfsmount *m;
@@ -201,6 +288,7 @@ static void commit_tree(struct vfsmount
list_add_tail(>mnt_hash, mount_hashtable +
hash(parent, mnt->mnt_mountpoint));
[RFC PATCH 1/4] Union mount documentation.
From: Bharata B Rao <[EMAIL PROTECTED]>
Subject: Union mount documentation.
Adds union mount documentation.
Signed-off-by: Bharata B Rao <[EMAIL PROTECTED]>
---
Documentation/union-mounts.txt | 232 +
1 files changed, 232 insertions(+)
--- /dev/null
+++ b/Documentation/union-mounts.txt
@@ -0,0 +1,232 @@
+VFS BASED UNION MOUNT
+=
+
+1. What is Union Mount ?
+2. Recap
+3. The new approach
+4. Union stack: building and traversal
+5. Union stack: destroying
+6. Directory lising
+7. What works and what doesn't ?
+8. Usage
+9. References
+
+1. What is Union Mount ?
+
+Union mount allows mounting of two or more filesystems transparently on
+a single mount point. Contents (files or directories) of all the
+filesystems become visible at the mount point after a union mount. If
+there are files with the same name in multiple layers of the union, only
+the topmost files remain visible. Contents of common named directories are
+merged again to present a unified view at the subdirectory level.
+
+In this approach of filesystem namespace unification, the layering or
+stacking information of different components (filesystems) of the union
+mount are maintained at the VFS layer. Hence, this is referred to as VFS
+based union mount.
+
+2. Recap
+
+Jan Blunck had developed a version of VFS based union mount in 2003-4.
+This version was cleaned up and ported to later kernels. Early in year
+2007, two iterations of these patches were posted for review (Ref 1, Ref 2).
+But, this approach had a few shortcomings:
+
+- It wasn't designed to work with shared subtree additions to mount.
+- It didn't work well when same filesystem was mounted from different
+ namespaces, as it maintained the union stack at dentry level.
+- It made dget() sleep.
+- The union stack was built using dentries and this was too fragile. This
+ made the code complex and the locking ugly.
+
+3. The new approach
+---
+In this new approach, the way union stack is built and traversed has been
+changed. Instead of dentry-to-dentry links forming the stack between
+different layers, we now have (vfsmount, dentry) pairs as the building
+blocks of the union stack. Since this (vfsmount, dentry) combination is
+unique across all namespaces, we should be able to maintain the union stack
+sanely even if the filesystem is union mounted privately in different
+namespaces or if it appears under different mounts due to various types
+of bind mounts.
+
+4. Union stack: building and traversal
+--
+Union stack needs to be built from two places: during an explicit union
+mount (or mount propagation) and during the lookup of a directory that
+appears in more than one layer of the union.
+
+The link between two layers of union stack is maintained using the
+union_mount structure:
+
+struct union_mount {
+ /* vfsmount and dentry of this layer */
+ struct vfsmount *src_mnt;
+ struct dentry *src_dentry;
+
+ /* vfsmount and dentry of the next lower layer */
+ struct vfsmount *dst_mnt;
+ struct dentry *dst_dentry;
+
+ /*
+* This list_head hashes this union_mount based on this layer's
+* vfsmount and dentry. This is used to get to the next layer of
+* the stack (dst_mnt, dst_dentry) given the (src_mnt, src_dentry)
+* and is used for stack traversal.
+*/
+ struct list_head hash;
+
+ /*
+* All union_mounts under a vfsmount(src_mnt) are linked together
+* at mnt->mnt_union using this list_head. This is needed to destroy
+* all the union_mounts when the mnt goes away.
+*/
+ struct list_head list;
+};
+
+These union mount structures are stored in a hash table(union_mount_hashtable)
+which uses the same hash as used for mount_hashtable since both of them use
+(vfsmount, dentry) pairs to calculate the hash.
+
+During a new mount (or mount propagation), a new union_mount structure is
+created. A reference to the mountpoint's vfsmount and dentry is taken and
+stored in the union_mount (as dst_mnt, dst_dentry). And this union_mount
+is inserted in the union_mount_hashtable based on the hash generated by
+the mount root's vfsmount and dentry.
+
+Similar method is employed to create a union stack during first time lookup
+of a common named directory within a union mount point. But here, the top
+level directory's vfsmount and dentry are hashed to get to the lower level
+directory's vfsmount and dentry.
+
+The insertion, deletion and lookup of union_mounts in the
+union_mount_hashtable is protected by vfsmount_lock. While traversing the
+stack, we hold this spinlock only briefly during lookup time and release
+it as soon as we get the next union stack member. The top level of the
+stack holds a reference to the next level (via union_mount structure) and
+so on. Therefore, as long as we hold a reference to a union stack
[RFC PATCH 0/4] New approach to VFS based union mount
Hi, The earlier approach to VFS based union mounts posted here didn't work for all cases of mounts (specially bind mounts). Hence, I have worked on this new approach which is more generic and hopefully should work in most cases. This approach fundamentally changes the way union stacks are maintained. Details of the approach can be found in the accompanying documentation patch. Since this is still a work in progress, there are many loose ends. Apart from that, I have some questions about the design and implementation aspects, which I have raised in the documenation patch. It will be very helpful if people who are familiar with VFS and stackable filesystems could review this. This series (on 2622rc4mm2) has the following 4 patches: 1/4 - Union mount documentation. 2/4 - Mount changes to support union mount. 3/4 - Lookup changes to support union mount. 4/4 - Directory listing support for union mounted directories. Kindly review and send me your feedback. Regards, Bharata. - 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/
can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ Hello, on this vaio sz72b I can't suspend if usb-storage is loaded. Bisecting is becoming troublesome as different sets have slightly different problems. At one point (with the GREGKH usb stuff built) I had the kernel reporting it cannot stop the usb-storage thread so I guess that something later in the series made things worse (freezable workqueues?). Clues? -- mattia :wq! - 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] Chinese translation of Documentation/HOWTO
Hi, 2007/6/20, Li Yang-r58472 <[EMAIL PROTECTED]>: > -Original Message- > From: dave young [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 20, 2007 9:58 AM > To: WANG Cong > Cc: Li Yang-r58472; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; TripleX Chung; > Maggie Chen; Tejun Heo; Fengguang Wu; Chen Li-jun > Subject: Re: [PATCH] Chinese translation of Documentation/HOWTO > > Hi, > IMHO, it is not very suitable for translations merging into kernel. > > first, It's impossible to be 100% accurate. It can be accurate by meaning. And it can be improved. > second, two or more language need to be synced with english one, it's > a problem in the long run. This can be done through good maintenance. I don't think it's harder than maintaining the code in kernel source tree. Yes, but the documents updating are always late than the sources. In my personal opinion, Of course chinese translaton is a valuable work, But I don't like huge kernel source with tuns of translations, english only is always better choice. Anyway thanks for the work :) Regards dave - 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] Chinese translation of Documentation/HOWTO
> -Original Message- > From: dave young [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 20, 2007 9:58 AM > To: WANG Cong > Cc: Li Yang-r58472; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; TripleX Chung; > Maggie Chen; Tejun Heo; Fengguang Wu; Chen Li-jun > Subject: Re: [PATCH] Chinese translation of Documentation/HOWTO > > Hi, > IMHO, it is not very suitable for translations merging into kernel. > > first, It's impossible to be 100% accurate. It can be accurate by meaning. And it can be improved. > second, two or more language need to be synced with english one, it's > a problem in the long run. This can be done through good maintenance. I don't think it's harder than maintaining the code in kernel source tree. - Leo - 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] Chinese translation of Documentation/HOWTO
On Wed, Jun 20, 2007 at 12:14:59AM +0800, Li Yang-r58472 wrote: >Hi Wangcong, > >Thanks for your comments. Most of the comments are literal. I don't >believe all of them are necessary as language is a matter of personal >preference. :) I will consider your suggestions carefully and pick up >those which are really necessary. Yes. I just give you my comments and hope you can consider them carefully. Making the final decisions is still your work. ;) Thanks! WANG Cong - 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: Some thoughts on memory policies
On Wed, 20 Jun 2007, Paul Mundt wrote: > There's quite a bit of room for improving and extending the existing > code, and those options should likely be exhausted first. There is a confusing maze of special rules if one goes beyond the simple process address space case. There are no clean rules on how to combine memory policies. Refcounting / updating becomes a problem because policies are intended to be only updated from the process that set them up. Look at the gimmicks that Paul needed to do to update memory policies when a process is migrated and the vmas on the stack for shmem etc etc. - 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: Versioning file system
Trond Myklebust wrote: >> >> I assume NetApp flags the directory specially so that a POSIX directory >> read doesn't get it. I've seen that done elsewhere. > > No. The directory is quite visible with a standard 'ls -a'. Instead, > they simply mark it as a separate volume/filesystem: i.e. the fsid > differs when you call stat(). The whole thing ends up acting rather like > our bind mounts. > It means that you avoid all those nasty user issues where people try to > hard link to/from .snapshot directories, rename files across snapshot > boundaries, etc. > Last I used a Netapp, it was configurable, I believe; I seem to also vaguely remember that one could configure it so that it only was accessible as part of a mount string rather than as part of an already-mounted filesystem. Of course, this was a long time ago. -hpa - 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: Change in default vm_dirty_ratio
On Wed, 20 Jun 2007 00:24:34 -0400 Dave Jones <[EMAIL PROTECTED]> wrote: > On Mon, Jun 18, 2007 at 04:47:11PM -0700, Andrew Morton wrote: > > > Frankly, I find it very depressing that the kernel defaults matter. These > > things are trivially tunable and you'd think that after all these years, > > distro initscripts would be establishing the settings, based upon expected > > workload, amount of memory, number and bandwidth of attached devices, etc. > > "This is hard, lets make it someone else's problem" shouldn't ever be the > answer, Bovine droppings. Nobody has even tried. > especially if the end result is that we become even more > dependant on bits of userspace running before the system becomes useful. Cattle excreta. The kernel remains as it presently is. No less useful that it is now. > > Heck, there should even be userspace daemons which observe ongoing system > > behaviour and which adaptively tune these things to the most appropriate > > level. > > > > But nope, nothing. > > See the 'libtune' crack that people have been trying to get distros to > adopt for a long time. > If we need some form of adaptive behaviour, the kernel needs to be > doing this monitoring/adapting, not some userspace daemon that may > not get scheduled before its too late. Userspace has just as much info as the kernel has and there is no latency concern here. > If the kernel can't get the defaults right, what makes you think > userspace can do better ? Because userspace can implement more sophisticated algorithms and is more easily configured. For example, userspace can take a hotplug event for the just-added usb-storage device then go look up its IO characteristics in a database and then apply that to the confgured policy. If the device was not found, userspace can perform a test run to empirically measure that device's IO characteristics and then record them in the database. I don't think we'll be doing this in-kernel any time soon. (And to preempt lkml-games: this is just an _example_. There are others) >Just as the kernel can't get > "one size fits all" right, there's no silver bullet just by clicking > "this is a database server" button to have it configure random > sysctls etc. These things require thought and planning that > daemons will never get right in every case. And when they get > it wrong, the results can be worse than the stock defaults. > > libtune is the latest in a series of attempts to do this dynamic > runtime adjustment (hell, I even started such a project myself > back circa 2000 which thankfully never really took off). > It's a bad idea that just won't die. > So libtune is the only possible way of implementing any of this? If choosing the optimum settings cannot be done in userspace then it sure as heck cannot be done in-kernel. Anyway, this is all arse-about. What is the design? What algorithms do we need to implement to do this successfully? Answer me that, then we can decide upon these implementation details. - 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 7/12] acpi: fix another compile warning
On Tuesday 19 June 2007 23:51, Randy Dunlap wrote: > On Tue, 19 Jun 2007 20:49:34 -0700 Randy Dunlap wrote: > > > On Tue, 19 Jun 2007 23:38:02 -0400 Len Brown wrote: > > > > > On Tuesday 19 June 2007 18:50, Andreas Herrmann wrote: > > > > Avoid compile warning if !ACPI_BLACKLIST_YEAR > > > > > > > > CC drivers/acpi/blacklist.o > > > > drivers/acpi/blacklist.c:76:5: warning: "CONFIG_ACPI_BLACKLIST_YEAR" > > > > is not defined > > > > > > How were you able to produce a .config with CONFIG_ACPI_BLACKLIST_YEAR > > > not defined? > > > Can you send it to me? > > > > 'make randconfig' does that kind of thing. It doesn't enforce/follow > > "select" clauses. > > I should have also said: randconfig is good for detecting some > missing conditions/configs or missing header files, but if you find one > that is just plain Invalid (like some of these), just say so > and do whatever you want with the patch (IMHO of course). If randconfig ends up with impossible-for-a-user-to-generate configs, then it seems seriously broken. Perhaps it would make sense to run "make oldconfig" after "make randconfig" -- or better yet, have that built in? -Len - 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] remove usage of memmem from scripts/kallsyms.c
On Tuesday 19 June 2007, Satyam Sharma wrote: > On 6/19/07, Paulo Marques <[EMAIL PROTECTED]> wrote: > > The only in-kernel user of "memmem" is scripts/kallsyms.c and it only > > uses it to find tokens that are 2 bytes in size. It is trivial to > > replace it with a simple function that finds 2-byte tokens. > > > > This should help users from systems that don't have the memmem GNU > > extension available. > > So we could remove the "#define _GNU_SOURCE" at the top > of scripts/kallsyms.c too, presumably? If not (i.e. if there are > more GNUisms left in that file anyway), then I'm not sure if we > really gain by the change. yes, i believe this is true -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 12/12] acpi: select ACPI_EC for SONY_LAPTOP
On Wed, Jun 20, 2007 at 12:52:25AM +0200, Andreas Herrmann wrote: > Fix kernel build problem as SONY_LAPTOP depends on ACPI_EC. The same questions about ACPI_SYSTEM and ACPI_POWER surviving oldconfig hold here. See also http://lkml.org/lkml/2007/5/15/168 and following for a previous report. In any case, Len if you're going apply such fixes feel free to add my Acked-By on this one. > Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> > --- > drivers/misc/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index 0d6f369..463fa41 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -119,6 +119,7 @@ config MSI_LAPTOP > config SONY_LAPTOP > tristate "Sony Laptop Extras" > depends on X86 && ACPI > + select ACPI_EC > select BACKLIGHT_CLASS_DEVICE > ---help--- > This mini-driver drives the SNC and SPIC devices present in the ACPI > -- > 1.5.0.7 -- mattia :wq! - 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: Change in default vm_dirty_ratio
On Mon, Jun 18, 2007 at 04:47:11PM -0700, Andrew Morton wrote: > Frankly, I find it very depressing that the kernel defaults matter. These > things are trivially tunable and you'd think that after all these years, > distro initscripts would be establishing the settings, based upon expected > workload, amount of memory, number and bandwidth of attached devices, etc. "This is hard, lets make it someone else's problem" shouldn't ever be the answer, especially if the end result is that we become even more dependant on bits of userspace running before the system becomes useful. > Heck, there should even be userspace daemons which observe ongoing system > behaviour and which adaptively tune these things to the most appropriate > level. > > But nope, nothing. See the 'libtune' crack that people have been trying to get distros to adopt for a long time. If we need some form of adaptive behaviour, the kernel needs to be doing this monitoring/adapting, not some userspace daemon that may not get scheduled before its too late. If the kernel can't get the defaults right, what makes you think userspace can do better ?Just as the kernel can't get "one size fits all" right, there's no silver bullet just by clicking "this is a database server" button to have it configure random sysctls etc. These things require thought and planning that daemons will never get right in every case. And when they get it wrong, the results can be worse than the stock defaults. libtune is the latest in a series of attempts to do this dynamic runtime adjustment (hell, I even started such a project myself back circa 2000 which thankfully never really took off). It's a bad idea that just won't die. Dave -- http://www.codemonkey.org.uk - 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] add printk_ratelimit to atkbd_interrupt
On Tuesday 19 June 2007 21:17, Qi Yong wrote: > Add printk_ratelimit() to atkbd_interrupt(). I get "Spurious ACK" messages > flushing on my > screen. This patch helps to read the screen. > Will apply, thank you. Do you have any idea why you are getting spurios ACK messages? Do you have an application fiddling with keyboard port or do you have blink driver enabled? -- Dmitry - 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] Workaround change_page_attr() and global_flush_tlb() df_list inconsistency on i386
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote: > Looking more closely into the code to find the cause of the > change_page_addr()/global_flush_tlb() inconsistency, I see where the > problem could be: > > In arch/i386/mm/pageattr.c: > __change_page_attr adds the page to the df_list for deferred removal > when it is replaced by a large page (going back to the normal flags). > This list is walked by global_flush_tlb(); it calls flush_map() and > __free_page for each of these pages. > > flush_map() is the only call that ends up doing a clflush/wbinvd and > __flush_tlb_all() on every cpu. However, this is only done when there > are pages recombined in a large page. It never happens when we set the > page flags to something unusual in __change_page_attr(). > > The x86_64 implementation seems to work around this issue by doing a > flush_map() independently of the deferred_pages list. It will therefore > call __flush_tlb_all(), which should flush the TLB, but even there, I > wonder if it should call clflush on the pages that had their flags > modified by __change_page_attr() ? > > Some input about the best way to fix this (adding the modified pages to > the deferred list in __change_page_attr() or flushing all the TLBs, and > all caches, independently of the deferred pages list in > global_flush_tlb()) would be appreciated. If we add the pages that > simply had their flags modified to the df_list, would it be ok to issue > a __free_page on them ? > Workaround change_page_attr() and global_flush_tlb() df_list inconsistency on i386 global_flush_tlb() does not flush the tlb of pages that had their flags changed by change_page_attr(). It only deals with the pages that are set back to their normal flags. Waiting for comments about a cleaner fix, this one does the job. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> --- arch/i386/mm/pageattr.c |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6-lttng/arch/i386/mm/pageattr.c === --- linux-2.6-lttng.orig/arch/i386/mm/pageattr.c2007-06-19 15:34:14.0 -0400 +++ linux-2.6-lttng/arch/i386/mm/pageattr.c 2007-06-19 16:49:52.0 -0400 @@ -232,6 +232,8 @@ flush_map(page_address(pg)); __free_page(pg); } + /* Workaround change page attr list missing entries */ + flush_map(NULL); } #ifdef CONFIG_DEBUG_PAGEALLOC -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/19/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: it was the ability of the linux kernel to adapt to vastly different hardware (including embeded hardware) that made Linux what it is today. Which is why NetBSD is currently poised to take over the world... Dave - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/19/07, Al Boldi <[EMAIL PROTECTED]> wrote: Scott Preece wrote: > On 6/19/07, Al Boldi <[EMAIL PROTECTED]> wrote: > > Nicolas Mailhot wrote: > > > Tivo didn't make the Linux success. More Tivos can definitely undo it. > > > > I don't think so. > > > > First, it's not Linux that made success, but rather GNU that uses Linux > > as its kernel. And, believe it or not, when people say Linux, they > > really mean GNU. People could care less what kernel they were running, > > as long as the system is up and runs the procs that offer their > > services. > > --- > > Actually, for use in devices (like TiVos or cell phones), it is very > definitely the kernel that is of interest. Many such devices use > little or no GNU software (some manufacturers have consciously avoided > it because of the possibility of shifts like the GPLv3 changes). Sure, but was it Linux in embedded devices that made Linux what it is today, or was it GNU/Linux? It was Apache. Apache showed corporate users and small businesses desperate to cash in on the Interweb c. 1995-1998 that they could do it w/out paying some proprietary vendor and get better performance, security and support to boot (I reported a bug in Apache JServ in 1998 and a fix was released by the time I came back from lunch 1/2 hour later). Linux was a tool for UNIX sysadmins and admin wannabes to practice their UNIX chops at home - or a conveniently inexpensive platform on which to run Apache. Companies -- other than Linux distributors -- didn't bet their business on it. Apache's success greatly contributed to the corporate acceptance of Linux, IMHO. Dave - 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: Some thoughts on memory policies
On Mon, Jun 18, 2007 at 01:22:08PM -0700, Christoph Lameter wrote: > 1. Memory policies must be attachable to a variety of objects > > - System policies. The system policy is currently not > modifiable. It may be useful to be able to set this. > Small NUMA systems may want to run with interleave by default > For small systems there are a number of things that could be done for this. With the interleave map for system init dynamically created, we can make a reasonable guess about whether we want to use interleave as a default policy or not if the node map is considerably different from the online map (or the node_memory_map in -mm). If the system policy only makes sense as interleave or default, it might make sense simply to have a sysctl for this (the sysctl handler could rebalance the interleave map when switching to handle offline nodes coming online later, for example). > - Memory policies need to be attachable to types of pages. > F.e. executable pages of a threaded application are best > spread (or replicated) whereas the stack and the data may > best be allocated in a node local way. That would be nice, but one would also have to be able to restrict the range of nodes to replicate across when applications know their worst-case locality. Perhaps some of the cpuset work could be generalized for this? > 2. Memory policies need to support additional constraints > > - Restriction to a set of nodes. That is what we have today. > > - Restriction to a container or cpuset. Maybe restriction > to a set of containers? > Having memory policies per container or cpuset would be nice to have, but this seems like it would get pretty messy with nested cpusets that contain overlapping memory nodes? The other question is whether tasks residing under a cpuset with an established memory policy are allowed to mbind() outside of the cpuset policy constraints. Spreading of page and slab cache pages seem to already side-step constraints. > 7. Allocators must change > > Right now the policy is set by the process context which is bad because > one cannot specify a memory policy for an allocation. It must be possible > to pass a memory policy to the allocators and then get the memory > requested. > Some policy hints can already be determined from the gfpflags, perhaps it's worth expanding on this? If these sorts of things have to be handled by devices, one has to assume that the device may not always be running in the same configuration or system, so an explicit policy would simply cause more trouble. > I wish we could come up with some universal scheme that encompasses all > of the functionality we want and that makes memory more manageable > There's quite a bit of room for improving and extending the existing code, and those options should likely be exhausted first. - 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/
Please pull from 'for_linus' branch
Linus, Please pull from 'for_linus' branch at master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_linus To get a fix for 2.6.22 to the rheap allocator that was causing multiple instances of the UCC ethernet driver to fail because it was running out of memory due to wasting space for aligned requests. Thanks, Kumar. arch/powerpc/lib/rheap.c | 48 --- 1 file changed, 29 insertions(+), 19 deletions(-) commit 7c8545e98468c53809fc06788a3b9a34dff05240 Author: Li Yang <[EMAIL PROTECTED]> Date: Mon Jun 18 19:29:21 2007 +0800 [POWERPC] rheap - eliminates internal fragments caused by alignment The patch adds fragments caused by rh_alloc_align() back to free list, instead of allocating the whole chunk of memory. This will greatly improve memory utilization managed by rheap. It solves MURAM not enough problem with 3 UCCs enabled on MPC8323. Signed-off-by: Li Yang <[EMAIL PROTECTED]> Acked-by: Joakim Tjernlund <[EMAIL PROTECTED]> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> - 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 7/12] acpi: fix another compile warning
On Tue, 19 Jun 2007 20:49:34 -0700 Randy Dunlap wrote:
> On Tue, 19 Jun 2007 23:38:02 -0400 Len Brown wrote:
>
> > On Tuesday 19 June 2007 18:50, Andreas Herrmann wrote:
> > > Avoid compile warning if !ACPI_BLACKLIST_YEAR
> > >
> > > CC drivers/acpi/blacklist.o
> > > drivers/acpi/blacklist.c:76:5: warning: "CONFIG_ACPI_BLACKLIST_YEAR" is
> > > not defined
> >
> > How were you able to produce a .config with CONFIG_ACPI_BLACKLIST_YEAR not
> > defined?
> > Can you send it to me?
>
> 'make randconfig' does that kind of thing. It doesn't enforce/follow
> "select" clauses.
I should have also said: randconfig is good for detecting some
missing conditions/configs or missing header files, but if you find one
that is just plain Invalid (like some of these), just say so
and do whatever you want with the patch (IMHO of course).
> > thanks,
> > -Len
> >
> > > Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
> > > ---
> > > drivers/acpi/blacklist.c |2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
> > > index 3ec110c..ac96c47 100644
> > > --- a/drivers/acpi/blacklist.c
> > > +++ b/drivers/acpi/blacklist.c
> > > @@ -73,7 +73,7 @@ static struct acpi_blacklist_item acpi_blacklist[]
> > > __initdata = {
> > > {""}
> > > };
> > >
> > > -#if CONFIG_ACPI_BLACKLIST_YEAR
> > > +#if defined(CONFIG_ACPI_BLACKLIST_YEAR) &&
> > > CONFIG_ACPI_BLACKLIST_YEAR
> > >
> > > static int __init blacklist_by_year(void)
> > > {
> > -
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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 7/12] acpi: fix another compile warning
On Tue, 19 Jun 2007 23:38:02 -0400 Len Brown wrote:
> On Tuesday 19 June 2007 18:50, Andreas Herrmann wrote:
> > Avoid compile warning if !ACPI_BLACKLIST_YEAR
> >
> > CC drivers/acpi/blacklist.o
> > drivers/acpi/blacklist.c:76:5: warning: "CONFIG_ACPI_BLACKLIST_YEAR" is
> > not defined
>
> How were you able to produce a .config with CONFIG_ACPI_BLACKLIST_YEAR not
> defined?
> Can you send it to me?
'make randconfig' does that kind of thing. It doesn't enforce/follow
"select" clauses.
> thanks,
> -Len
>
> > Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
> > ---
> > drivers/acpi/blacklist.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
> > index 3ec110c..ac96c47 100644
> > --- a/drivers/acpi/blacklist.c
> > +++ b/drivers/acpi/blacklist.c
> > @@ -73,7 +73,7 @@ static struct acpi_blacklist_item acpi_blacklist[]
> > __initdata = {
> > {""}
> > };
> >
> > -#ifCONFIG_ACPI_BLACKLIST_YEAR
> > +#ifdefined(CONFIG_ACPI_BLACKLIST_YEAR) &&
> > CONFIG_ACPI_BLACKLIST_YEAR
> >
> > static int __init blacklist_by_year(void)
> > {
> -
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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: Fix signalfd interaction with thread-private signals
On Tue, 2007-06-19 at 19:15 -0700, Davide Libenzi wrote: > Ok, why instead don't we go for something like the attached patch? > We exclude sync signals from signalfd, but we don't limit signalfd to > shared signals. Ie, we should be able to fetch a signal sent with > sys_tkill() to threads different from "current", that otherwise we would > not be able to fetch. > Ben, sorry but my memory sucks ... the "notifier" thing was fine in that > case, no? I'm generally nervous about the idea of letting signalfd dequeue somebody else private signals... even if we filter out SEGV's and friends but I'll let Linus decide there. Regarding the notifier, it's dodgy in most cases I'd say but I suppose it should be allright to only worry about "current" and not the target task there. 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Wed, 20 Jun 2007, Al Boldi wrote: Scott Preece wrote: On 6/19/07, Al Boldi <[EMAIL PROTECTED]> wrote: Nicolas Mailhot wrote: Tivo didn't make the Linux success. More Tivos can definitely undo it. I don't think so. First, it's not Linux that made success, but rather GNU that uses Linux as its kernel. And, believe it or not, when people say Linux, they really mean GNU. People could care less what kernel they were running, as long as the system is up and runs the procs that offer their services. --- Actually, for use in devices (like TiVos or cell phones), it is very definitely the kernel that is of interest. Many such devices use little or no GNU software (some manufacturers have consciously avoided it because of the possibility of shifts like the GPLv3 changes). Sure, but was it Linux in embedded devices that made Linux what it is today, or was it GNU/Linux? if it was the GNU that made linux what it is today and the linux kernel mearly an oppurtunist then the GNU/Hurd, GNU/Solaris, GNU/BSD and for that matter GNU/Microsoft distributions should be steadily and quickly gaining marketshare oh, sorry, people barely know that they exist (including people convinced that the linux kernel is junk compared to Solaris) and they are little more than proof-that-it-can-be-done showpieces. it was the ability of the linux kernel to adapt to vastly different hardware (including embeded hardware) that made Linux what it is today. and I do mean 'Linux" not 'GNU/Linux' in the statement above. David Lang - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Tue, 19 Jun 2007, Alexandre Oliva wrote: On Jun 19, 2007, [EMAIL PROTECTED] wrote: if you also make the assumption that the company won't use propriatary software instead then I think you would get agreement. Ah, good point. When I posed the one of the two cases of the inicial scenario as "no tivoization", I meant Free Software without constraints. but the disagrement is over this exact assumption. you assume that these companies will use non-tivoized products if you make it hard to use the software covered by the GPL, most other people are saying that they disagree and the result would be fewer companies useing software covered by GPL instead. I understand that. And what I'm saying is that, even if fewer such companies use GPLed software, you may still be better off, out of additional contributions you'll get from customers of companies that switch from tivoization to unconstrained Free Software, because of the additional costs of the alternatives. And no, I can't prove it, but it's good that at least the argument is no longer completely disregarded while something else is disputed. Now that you guys at least understand what the argument is, you can figure out the solution by yourselves. good, if you are no longer going to claim that your opinion on this unprovable point is the Truth (not the capitol) hopefully you can accept that a lot of very smart people are convinced that you are wrong on this point and not just 'confused' David Lang - 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: [-RT] multiple streams have degraded performance
On Monday 18 June 2007 10:12:21 pm Vernon Mauery wrote:
> In looking at the performance characteristics of my network I found that
> 2.6.21.5-rt15 suffers from degraded thoughput with multiple threads. The
> test that I did this with is simply invoking 1, 2, 4, and 8 instances of
> netperf at a time and measuring the total throughput. I have two 4-way
> machines connected with 10GbE cards. I tested several kernels (some older
> and some newer) and found that the only thing in common was that with -RT
> kernels the performance went down with concurrent streams.
I just tested this using lo instead of the 10GbE adapter. I found similar
results. Since this makes it reproducible by just about anybody (maybe the
only factor now is the number of CPUs), I have attached the script that I
test things with.
So with the script run like ./stream_test 127.0.0.1 on 2.6.21 and
2.6.21.5-rt17 I got the following:
2.6.21
===
default: 1 streams: Send at 2790.3 Mb/s, Receive at 2790.3 Mb/s
default: 2 streams: Send at 4129.4 Mb/s, Receive at 4128.7 Mb/s
default: 4 streams: Send at 7949.6 Mb/s, Receive at 7735.5 Mb/s
default: 8 streams: Send at 7930.7 Mb/s, Receive at 7910.1 Mb/s
1Msock: 1 streams: Send at 2810.7 Mb/s, Receive at 2810.7 Mb/s
1Msock: 2 streams: Send at 4093.4 Mb/s, Receive at 4092.6 Mb/s
1Msock: 4 streams: Send at 7887.8 Mb/s, Receive at 7880.4 Mb/s
1Msock: 8 streams: Send at 8091.7 Mb/s, Receive at 8082.2 Mb/s
2.6.21.5-rt17
==
default: 1 streams: Send at 938.2 Mb/s, Receive at 938.2 Mb/s
default: 2 streams: Send at 1476.3 Mb/s, Receive at 1436.9 Mb/s
default: 4 streams: Send at 1489.8 Mb/s, Receive at 1145.0 Mb/s
default: 8 streams: Send at 1099.8 Mb/s, Receive at 1079.1 Mb/s
1Msock: 1 streams: Send at 921.4 Mb/s, Receive at 920.4 Mb/s
1Msock: 2 streams: Send at 1332.2 Mb/s, Receive at 1311.5 Mb/s
1Msock: 4 streams: Send at 1483.0 Mb/s, Receive at 1137.8 Mb/s
1Msock: 8 streams: Send at 1446.2 Mb/s, Receive at 1135.6 Mb/s
--Vernon
> While the test was showing the numbers for receiving as well as sending,
> the receiving numbers are not reliable because that machine was running a
> -RT kernel for these tests.
>
> I was just wondering if anyone had seen this problem before or would have
> any idea on where to start hunting for the solution.
>
> --Vernon
>
> The key for this is 'default' was invoked like:
> netperf -c -C -l 60 -H 10.2.2.4 -t UDP_STREAM -- -m 1472 -M 1472
> and '1Msock' was invoked like:
> netperf -c -C -l 60 -H 10.2.2.4 -t UDP_STREAM -- -m 1472 -M 1472 -s 1M -S
> 1M
>
> 2.6.21
> ==
> default: 1 streams: Send at 2844.2 Mb/s, Receive at 2840.1 Mb/s
> default: 2 streams: Send at 3927.9 Mb/s, Receive at 3603.9 Mb/s
> default: 4 streams: Send at 4197.4 Mb/s, Receive at 3776.3 Mb/s
> default: 8 streams: Send at 4223.9 Mb/s, Receive at 3848.9 Mb/s
> 1Msock: 1 streams: Send at 4232.3 Mb/s, Receive at 3914.4 Mb/s
> 1Msock: 2 streams: Send at 5428.8 Mb/s, Receive at 3853.2 Mb/s
> 1Msock: 4 streams: Send at 6202.1 Mb/s, Receive at 3774.8 Mb/s
> 1Msock: 8 streams: Send at 6225.1 Mb/s, Receive at 3754.7 Mb/s
>
> 2.6.21.5-rt15
> ===
> default: 1 streams: Send at 3091.6 Mb/s, Receive at 3048.1 Mb/s
> default: 2 streams: Send at 3768.8 Mb/s, Receive at 3714.2 Mb/s
> default: 4 streams: Send at 1873.6 Mb/s, Receive at 1825.9 Mb/s
> default: 8 streams: Send at 1806.5 Mb/s, Receive at 1792.7 Mb/s
> 1Msock: 1 streams: Send at 3680.4 Mb/s, Receive at 3255.6 Mb/s
> 1Msock: 2 streams: Send at 4129.8 Mb/s, Receive at 3991.5 Mb/s
> 1Msock: 4 streams: Send at 1862.1 Mb/s, Receive at 1787.1 Mb/s
> 1Msock: 8 streams: Send at 1790.2 Mb/s, Receive at 1556.8 Mb/s
#!/bin/sh
# File: stream_test
# Description: test network throughput with a varying number of streams
# Author: Vernon Mauery <[EMAIL PROTECTED]>
# Copyright: IBM Corporation (C) 2007
instances="1 2 4 8"
msg_size=
time=60
TEST=UDP_STREAM
sock_size=
function usage() {
echo "usage: $0 [-t|-u] [-c N] [-m N] [-s N] [-T N] [-x ...] "
echo " -t, -u run TCP or UDP tests respectively (default: UDP)"
echo " -c Nrun N concurrent instances (default \"1 2 4 8\")"
echo " -m Nset message size to N bytes (default 1472)"
echo " -s Nset socket buffer size (default 1M)"
echo " -T Nrun test for N seconds (default 60)"
echo " -x '...'pass extra ags to netperf (included after -- )"
echo " -h display this message"
}
while [ $# -gt 0 ]; do
case $1 in
-t)
TEST=TCP_STREAM
;;
-u)
TEST=UDP_STREAM
;;
-c)
shift
instances=$1
;;
-m)
shift
msg_size=$1
;;
-s)
shift
sock_size=$1
;;
-T)
shift
Re: [PATCH 7/12] acpi: fix another compile warning
On Tuesday 19 June 2007 18:50, Andreas Herrmann wrote:
> Avoid compile warning if !ACPI_BLACKLIST_YEAR
>
> CC drivers/acpi/blacklist.o
> drivers/acpi/blacklist.c:76:5: warning: "CONFIG_ACPI_BLACKLIST_YEAR" is not
> defined
How were you able to produce a .config with CONFIG_ACPI_BLACKLIST_YEAR not
defined?
Can you send it to me?
thanks,
-Len
> Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
> ---
> drivers/acpi/blacklist.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
> index 3ec110c..ac96c47 100644
> --- a/drivers/acpi/blacklist.c
> +++ b/drivers/acpi/blacklist.c
> @@ -73,7 +73,7 @@ static struct acpi_blacklist_item acpi_blacklist[]
> __initdata = {
> {""}
> };
>
> -#if CONFIG_ACPI_BLACKLIST_YEAR
> +#if defined(CONFIG_ACPI_BLACKLIST_YEAR) && CONFIG_ACPI_BLACKLIST_YEAR
>
> static int __init blacklist_by_year(void)
> {
-
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 5/12] acpi: fix compile error with ACPI && !ACPI_SYSTEM
On Tuesday 19 June 2007 18:49, Andreas Herrmann wrote:
> Fix build error if ACPI && !ACPI_SYSTEM as
> bus.c depended on event.c
How were you able to get ACPI & !ACPI_SYSTEM to survive "make oldconfig"?
-Len
> Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
> ---
> drivers/acpi/bus.c |2 +-
> drivers/acpi/event.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index e5084ec..b4a9ea5 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -281,7 +281,7 @@ static DEFINE_SPINLOCK(acpi_bus_event_lock);
> LIST_HEAD(acpi_bus_event_list);
> DECLARE_WAIT_QUEUE_HEAD(acpi_bus_event_queue);
>
> -extern int event_is_open;
> +int event_is_open = 0;
>
> int acpi_bus_generate_event(struct acpi_device *device, u8 type, int data)
> {
> diff --git a/drivers/acpi/event.c b/drivers/acpi/event.c
> index 3b23562..15886c1 100644
> --- a/drivers/acpi/event.c
> +++ b/drivers/acpi/event.c
> @@ -17,7 +17,7 @@ ACPI_MODULE_NAME("event");
>
> /* Global vars for handling event proc entry */
> static DEFINE_SPINLOCK(acpi_system_event_lock);
> -int event_is_open = 0;
> +extern int event_is_open;
> extern struct list_head acpi_bus_event_list;
> extern wait_queue_head_t acpi_bus_event_queue;
>
-
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 3/12] acpi: fix compile error with ACPI && !ACPI_POWER
On Tuesday 19 June 2007 18:48, Andreas Herrmann wrote: > Fix compile error with ACPI && !ACPI_POWER as bus.c > depends on power.c How were you able to set CONFIG_ACPI_POWER=n to cause this compile error? When I do that, "make oldconfig" forces it to =y. -Len > Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> > --- > drivers/acpi/Kconfig |4 > drivers/acpi/Makefile |2 +- > 2 files changed, 1 insertions(+), 5 deletions(-) > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > index 139f41f..9d6baab 100644 > --- a/drivers/acpi/Kconfig > +++ b/drivers/acpi/Kconfig > @@ -288,10 +288,6 @@ config ACPI_EC > the battery and thermal drivers. If you are compiling for a > mobile system, say Y. > > -config ACPI_POWER > - bool > - default y > - > config ACPI_SYSTEM > bool > default y > diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile > index d4336f1..9485cc3 100644 > --- a/drivers/acpi/Makefile > +++ b/drivers/acpi/Makefile > @@ -48,7 +48,7 @@ obj-$(CONFIG_ACPI_DOCK) += dock.o > obj-$(CONFIG_ACPI_BAY) += bay.o > obj-$(CONFIG_ACPI_VIDEO) += video.o > obj-y+= pci_root.o pci_link.o pci_irq.o > pci_bind.o > -obj-$(CONFIG_ACPI_POWER) += power.o > +obj-y+= power.o > obj-$(CONFIG_ACPI_PROCESSOR) += processor.o > obj-$(CONFIG_ACPI_CONTAINER) += container.o > obj-$(CONFIG_ACPI_THERMAL) += thermal.o - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/19/07, Jan Harkes <[EMAIL PROTECTED]> wrote: You keep referring to the four freedoms so I googled for them and found http://www.gnu.org/philosophy/free-sw.html So which of the freedoms did Tivo take away? * The freedom to run the program, for any purpose (freedom 0). * The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this. * The freedom to redistribute copies so you can help your neighbor (freedom 2). * The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this. It doesn't seem to me they took away freedoms 1, 2 or 3. They released the source to any free software components and we can study, modify, redistribute, improve and release our improvements for the benefit of the whole community. btw. freedom 3 seems to be just repeating what we already got from freedoms 1 and 2. So the only one we could differ in opinion about is freedom 0. I would say that they in no way are limiting my use of the Linux kernel (which is the part I mostly care about) I can run the program for any purpose I see fit. What if I want to run mythtv on my PC at home? Tivo has no control whether or not I can do so even when my kernel contains any of their modification or improvements, so I claim that I in fact retained freedom 0. Much as I hate to extend the life of this execrable thread, since I think Alexandre makes Sisyphus look like a hard-nosed pragmatist, it seems pretty clear that TiVO impinges "[my] freedom to run the program, for any purpose" if "any purpose" includes "make my TiVO do what I want," and likewise to "adapt it to [my] needs" -- freedoms 0 and part of 1. It is just disingenuous to argue otherwise. Dave - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Scott Preece wrote: > On 6/19/07, Al Boldi <[EMAIL PROTECTED]> wrote: > > Nicolas Mailhot wrote: > > > Tivo didn't make the Linux success. More Tivos can definitely undo it. > > > > I don't think so. > > > > First, it's not Linux that made success, but rather GNU that uses Linux > > as its kernel. And, believe it or not, when people say Linux, they > > really mean GNU. People could care less what kernel they were running, > > as long as the system is up and runs the procs that offer their > > services. > > --- > > Actually, for use in devices (like TiVos or cell phones), it is very > definitely the kernel that is of interest. Many such devices use > little or no GNU software (some manufacturers have consciously avoided > it because of the possibility of shifts like the GPLv3 changes). Sure, but was it Linux in embedded devices that made Linux what it is today, or was it GNU/Linux? 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: JIT emulator needs
On 6/19/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote: On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote: Right now, Linux isn't all that friendly to JIT emulators. Here are the problems and suggestions to improve the situation. There is an SE Linux execmem restriction that enforces W^X. Assuming you don't wish to just disable SE Linux, there are two ugly ways around the problem. You can mmap a file twice, or you can abuse SysV shared memory. The mmap method requires that you know of a filesystem mounted rw,exec where you can write a very large temporary file. This arbitrary filesystem, rather than swap space, will be the backing store. The SysV shared memory method requires an undocumented flag and is subject to some annoying size limits. Both methods create objects that will fail to be deleted if the program dies before marking the objects for deletion. If the policy forbidding self-modifying code lacks a method of exempting programs such as JIT interpreters (which I doubt) then it's a problem. I'm with Alan on this one. It does and it doesn't. There is not a reasonable way for a user to mark an app as needing full self-modifying ability. It's not like the executable stack, which can be set via the ELF note markings on the executable. (ELF note markings are ideal because they can not be used via a ret-to-libc attack) With admin privs, one can change SE Linux settings. Mark the executable, disable the protection system-wide, generate a completely new SE Linux policy, or just turn SE Linux off. Normally we don't expect/require admin privs to install an executable in one's own ~/bin directory. This is broken. It ought to be easier to get a JIT working well without enabling arbitrary mprotect. This would allow a JIT to partially benefit from the recent security enhancements. (think of all the buggy browser-based JIT things!) On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote: Processors often have annoying limits on the immediate values in instructions. An x86 or x86_64 JIT can go a bit faster if all allocations are kept to the low 2 GB of address space. There are also reasons for a 32bit-to-x86_64 JIT to chose a nearly arbitrary 2 GB region that lies above 4 GB. Other archs have other limits, such as 32 MB or 256 MB. This sort of logic might be appropriate for a sort of parametrized and specialized vma allocator setting the policy in /proc/ along with various sorts of limits. There are limits to such and at some point things will have to manually manage their own process address spaces in a platform-specific fashion. If kernel assistance here is rejected they may have to do so in all cases. I prefer ELF notes (for start-up allocations) and prctl, plus a mmap flag for per-allocation behavior. On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote: Additions to better support JIT emulators: a. sysctl to set IPC_RMID by default This is a bad idea. The standard semantics are needed for programs relying upon them. I didn't mean that the default default :-) setting would change. I meant that people could change the behavior from a boot script. Things that break are really foul and nasty anyway, probably with serious problems that ought to get fixed. On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote: c. open() flag to unlink a file before returning the fd You probably want a tmpfile(3) -like affair which never has a pathname to begin with. It could be useful for security purposes more generally. Yes, exactly. I think there are some possible optimizations available too, particularly with the cifs filesystem. On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote: d. mremap() flag to always keep the old mapping This sounds vaguely like another syscall, like mdup(). This is particularly meaningful in the context of anonymous memory, for which there is no method of replicating mappings within a single process address space. Yes, mdup() and probably mdup2(). It could be mremap flags or not. JIT emulators generally need a second mapping so that they can have both read/write and execute for the same physical memory. It is somewhat tolerable to have SE Linux enforce that the second mapping be randomized. (it helps security greatly, but slows the emulator by a tiny bit) On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote: e. mremap() flag to get a read/write mapping of a read/exec one f. mremap() flag to get a read/exec mapping of a read/write one Presumably to be used in conjunction with keeping the old mapping. A composite mdup()/mremap() and mprotect(), presumably saving a TLB flush or other sorts of overhead, may make some sort of sense here. Odds are it'll get rejected as the sequence of syscalls is a rather precise equivalent, though it would optimize things (as would other composite syscalls, e.g. ones combining fork() and execve() etc.). A few mremap flags ought to do the job I think. On Fri,
Re: [PATCH, RFD]: Unbreak no-mmu mmap
On Wed, 2007-06-20 at 12:00 +0900, Paul Mundt wrote: > On Fri, Jun 08, 2007 at 03:53:49PM +0200, Bernd Schmidt wrote: > > diff --git a/mm/nommu.c b/mm/nommu.c > > index 2b16b00..7480a95 100644 > > --- a/mm/nommu.c > > +++ b/mm/nommu.c > [snip] > > + /* > > +* Must always set the VM_SPLIT_PAGES flag for single-page allocations, > > +* to avoid trying to get the order of the compound page later on. > > +*/ > > + if (len == PAGE_SIZE) > > + vma->vm_flags |= VM_SPLIT_PAGES; > > + else if (flags & MAP_SPLIT_PAGES > > And now you've just broken every non-blackfin nommu platform, as you've > only defined MAP_SPLIT_PAGES in asm-blackfin/mman.h. > > > +#ifdef CONFIG_NP2 > > + || len < total_len > > +#endif > > And what is this? It only shows up in the blackfin defconfig. This is not > the place to be putting board-specific hacks. Yes, it is our own NP2 memory allocator option. I think Bernd will fix it. > > On Tue, Jun 19, 2007 at 07:26:19PM -0400, Robin Getz wrote: > > I'm assuming that since no one had any large objections, that this is OK, > > and > > we should send to Andrew to live in -mm for awhile? > > > No real objections to the approach, but it would be nice if these sorts > of things were test compiled for at least one platform that isn't yours, > so the obviously broken stuff is fixed before it's posted and someone > else has to find out about it later. Exactly, Could please do some simple test on your SH-NOMMU platform? And we are waiting for some feedback from other nommu arch maintainers. David and Grep could you please help on this? Maybe Robin got some m68k nommu by hand which can be used for testing, I only have Blackfin, -:)) Thanks, Paul. Regards, - Bryan > - > 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/ - 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, RFD]: Unbreak no-mmu mmap
On Fri, Jun 08, 2007 at 03:53:49PM +0200, Bernd Schmidt wrote: > diff --git a/mm/nommu.c b/mm/nommu.c > index 2b16b00..7480a95 100644 > --- a/mm/nommu.c > +++ b/mm/nommu.c [snip] > + /* > + * Must always set the VM_SPLIT_PAGES flag for single-page allocations, > + * to avoid trying to get the order of the compound page later on. > + */ > + if (len == PAGE_SIZE) > + vma->vm_flags |= VM_SPLIT_PAGES; > + else if (flags & MAP_SPLIT_PAGES And now you've just broken every non-blackfin nommu platform, as you've only defined MAP_SPLIT_PAGES in asm-blackfin/mman.h. > +#ifdef CONFIG_NP2 > + || len < total_len > +#endif And what is this? It only shows up in the blackfin defconfig. This is not the place to be putting board-specific hacks. On Tue, Jun 19, 2007 at 07:26:19PM -0400, Robin Getz wrote: > I'm assuming that since no one had any large objections, that this is OK, and > we should send to Andrew to live in -mm for awhile? > No real objections to the approach, but it would be nice if these sorts of things were test compiled for at least one platform that isn't yours, so the obviously broken stuff is fixed before it's posted and someone else has to find out about it later. - 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] Chinese translation of Documentation/HOWTO
On Tue, 2007-06-19 at 22:21 +0800, Li Yang wrote: > This is a Chinese translated version of Documentation/HOWTO. > Currently > Chinese involvement in Linux kernel is very low, especially comparing > to > its largest population base. Language could be the main obstacle. > Hope > this document will help more Chinese to contribute to Linux kernel. > Thanks a lot for your valuable work. If you need any help, please feel free to tell me. I will go though the Chinese version HOWTO and give you some feedback. Thanks again Best Regards, - Bryan Wu - 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: Versioning file system
On Jun 19, 2007, at 03:58:57, Bron Gondwana wrote: On Mon, Jun 18, 2007 at 11:10:42PM -0400, Kyle Moffett wrote: On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote: The question remains is where to implement versioning: directly in individual filesystems or in the vfs code so all filesystems can use it? Or not in the kernel at all. I've been doing versioning of the types I described for years with user space code and I don't remember feeling that I compromised in order not to involve the kernel. What I think would be particularly interesting in this domain is something similar in concept to GIT, except in a file-system: [...snip...] It can work, but there's one big pain at the file level: no mmap. IMHO it's actually not that bad. The "gitfs" would divide larger files up into manageable chunks (say 4MB) which could be quickly SHA-1ed. When a file is mmapped and partially modified, the SHA-1 would be marked as locally invalid, but since mmap() loses most consistency guarantees that's OK. A time or writeout based "commit" scheme might still freeze, SHA-1, and write-out the page at regular intervals without the program's knowledge, but since you only have to SHA-1 the relatively-small 4MB chunk (which is about to hit disk anyways), it's not a significant time penalty. Even if under memory pressure and swapping data out to disk you don't have to update the SHA-1 and create a new commit as long as you keep a reference to the object stored in the volume header somewhere and maintain the "SHA-1 out-of-date" bit. A program which carefully uses msync() would be fine, of course (with proper configuration) as that would create a new commit as appropriate. Since mmap() is poorly defined on network filesystems in the absence of msync(), I don't see that such behaviour would be a problem. And it certainly would be fine on local filesystems as there you can just stuff the "SHA-1 out-of-date" bit and a reference to the parent commit and path in the object itself. Then you just need to keep a useful reference to that object in a table somewhere in the volume and you're set. If you don't want to support mmap it can work reasonably happily, though you may want to keep your sha1 (or other digest) state as well as the final digest so you can cheaply calculate the digest for a small append without walking the entire file. You may also want to keep state checkpoints every so often along a big file so that truncates don't cost too much to recalculate. That may be worth it even if the file is divided into 4MB chunks (or other configurable value), but it would need benchmarking. Luckily in a userspace VFS that's only accessed via FTP and DAV we can support a limited set of operations (basically create, append, read, delete) You don't get that luxury for a general purpose filesystem, and that's the problem. There will always be particular usage patterns (especially something that mmaps or seeks and touches all over the place like a loopback mounted filesystem or a database file) that just dodn't work for file-level sha1s. I'd think that loopback-mounted filesystems wouldn't be that difficult 1) Set the SHA-1 block size appropriately to divide the big file into a bunch of little manageable files. Could conceivably be multi- layered like directories, depending on the size of the file. 2) Mark the file as exempt from normal commits (IE: without special syscalls or fsync/msync() on the file itself, it is never updated in the tree objects. 3) Set up the loopback device to call the gitfs commit code when it receives barriers or flushes from the parent filesystem. And database files aren't a big issue. I have yet to see a networked filesystem which you could stick a MySQL database on it from one node and expect to get useful/recent read results from other nodes. If you really wanted something like that for such a "gitfs", you could just add code to MySQL to create a gitfs commit every N transactions and not otherwise. The best part is: that would make online MySQL backups from another node trivial! Just pick any arbitrary appropriate commit object and mount that object, then "cp -a mysql_db_dir mysql_backup_dir". That's not to say it wouldn't have a performance penalty, but for some people the performance penalty might be worth it. Oh, and for those programs which want multi-master replication, this makes it ten times easier: 1) Put each master-server on a different gitfs branch 2) Write your program as gitfs aware. Make it create gitfs commits at appropriate times (so the data is accessible from other nodes). 3) Come up with a useful non-interactive database-file merge algorithm. Useful examples of different kinds of merge engines may be found in the git project. This should take $BASE_VERSION, $NEWVERSION1, $NEWVERSION2, and produce a $MERGEDVERSION. A good
Re: [PATCH, RFD]: Unbreak no-mmu mmap
On Tue, 2007-06-19 at 19:26 -0400, Robin Getz wrote: > On Fri 8 Jun 2007 09:53, Bernd Schmidt pondered: > > Here's a patch to move nommu mmap/munmap ever so slightly closer to mmu > > behaviour. The motivation for this is to be able to deselect uClibc's > > UCLIBC_UCLINUX_BROKEN_MUNMAP config option, which speeds up malloc a > > fair bit. I'm interested in comments whether this is a good direction > > to go. The patch is against Linus' tree as of a few minutes ago. > > I'm assuming that since no one had any large objections, that this is OK, and > we should send to Andrew to live in -mm for awhile? > > -Robin Yes, IMO it is fine for kernel and uclibc. Is there any comments from David and Greg? Thanks - Bryan - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/19/07, Al Boldi <[EMAIL PROTECTED]> wrote: Nicolas Mailhot wrote: > > Tivo didn't make the Linux success. More Tivos can definitely undo it. > I don't think so. First, it's not Linux that made success, but rather GNU that uses Linux as its kernel. And, believe it or not, when people say Linux, they really mean GNU. People could care less what kernel they were running, as long as the system is up and runs the procs that offer their services. --- Actually, for use in devices (like TiVos or cell phones), it is very definitely the kernel that is of interest. Many such devices use little or no GNU software (some manufacturers have consciously avoided it because of the possibility of shifts like the GPLv3 changes). scott - 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][Patch 2/3]integrity: IMA as an integrity service provider
On Mon, 18 Jun 2007, Mimi Zohar wrote:
> +/* what could we exclude
> + * - non-executable/non-library files ?
> + * - /proc /dev ?
> + * Only measure files opened for read-only or execute
> + */
> +static int skip_measurement(struct inode *inode, int mask)
> +{
> + if ((inode->i_sb->s_magic == PROC_SUPER_MAGIC) ||
> + (inode->i_sb->s_magic == SYSFS_MAGIC)) {
> + return 1; /*can't measure */
> + }
I'm pretty sure you should skip measurement for many more pseudo
filesystems than this.
- James
--
James Morris
<[EMAIL PROTECTED]>
-
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: Fix signalfd interaction with thread-private signals
On Wed, 20 Jun 2007, Benjamin Herrenschmidt wrote:
> On Tue, 2007-06-19 at 16:49 -0700, Davide Libenzi wrote:
>
> > Actually, I think signalfd is fine as is, with Ben's patch applied.
> > Signalfd should only fetch shared signals, not specific ones (in any
> > case).
>
> The only advantage of that additional patch is that it will allow any
> thread to fetch its own private signals via signalfd, regardless of what
> context is attached to the signalfd in the first place.
>
> Without the patch (with what's currently in Linus tree), a thread will
> only get its own private signals if it's also the thread that created
> the signalfd (and thus is attached to the signalfd "context").
>
> I don't mind either way, up to you guys to decide what semantics you
> want.
Ok, why instead don't we go for something like the attached patch?
We exclude sync signals from signalfd, but we don't limit signalfd to
shared signals. Ie, we should be able to fetch a signal sent with
sys_tkill() to threads different from "current", that otherwise we would
not be able to fetch.
Ben, sorry but my memory sucks ... the "notifier" thing was fine in that
case, no?
- Davide
---
fs/signalfd.c | 10 +-
kernel/signal.c |6 +-
2 files changed, 10 insertions(+), 6 deletions(-)
Index: linux-2.6.mod/fs/signalfd.c
===
--- linux-2.6.mod.orig/fs/signalfd.c2007-06-19 18:58:15.0 -0700
+++ linux-2.6.mod/fs/signalfd.c 2007-06-19 19:02:57.0 -0700
@@ -26,6 +26,14 @@
#include
#include
+/*
+ * Signals that a signalfd should never fetch.
+ */
+#define SIGNALFD_EXCLUDE_MASK (sigmask(SIGILL) | sigmask(SIGKILL) | \
+ sigmask(SIGSTOP) | sigmask(SIGTRAP) | \
+ sigmask(SIGFPE) | sigmask(SIGSEGV) | \
+ sigmask(SIGBUS))
+
struct signalfd_ctx {
struct list_head lnk;
wait_queue_head_t wqh;
@@ -320,7 +328,7 @@
if (sizemask != sizeof(sigset_t) ||
copy_from_user(, user_mask, sizeof(sigmask)))
return error = -EINVAL;
- sigdelsetmask(, sigmask(SIGKILL) | sigmask(SIGSTOP));
+ sigdelsetmask(, SIGNALFD_EXCLUDE_MASK);
signotset();
if (ufd == -1) {
Index: linux-2.6.mod/kernel/signal.c
===
--- linux-2.6.mod.orig/kernel/signal.c 2007-06-19 18:55:07.0 -0700
+++ linux-2.6.mod/kernel/signal.c 2007-06-19 18:58:43.0 -0700
@@ -365,11 +365,7 @@
{
int signr = 0;
- /* We only dequeue private signals from ourselves, we don't let
-* signalfd steal them
-*/
- if (tsk == current)
- signr = __dequeue_signal(>pending, mask, info);
+ signr = __dequeue_signal(>pending, mask, info);
if (!signr) {
signr = __dequeue_signal(>signal->shared_pending,
mask, info);
-
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: [rtc-linux] [PATCH 1/2] rtc: add rtc-m41txx driver
On Wed, 20 Jun 2007 00:28:28 +0200, Alessandro Zummo <[EMAIL PROTECTED]> wrote:
> I'd prefer if you change the name in rtc-m41t80 and add
> the names of the supported chips in the Kconfig entry.
OK, I will do. I thought M41ST94 also can be supported but that was
wrong. From datasheets, the driver can be used for M41T8[0123],
M41ST8[457] chips.
> > + unsigned char wbuf[1 + M41TXX_REG_YEAR + 1];
>
> would be easier to understand if you have some #defines
> with the sizes you require for the various buffers.
I will do.
> the proc interface will go away sooner or later, would be better to expose
> the battery status with a sysfs attribute.
I will do.
> > +++ b/include/linux/m41txx.h
> > @@ -0,0 +1,40 @@
> > +/*
> > + * Definitions for the ST M41TXX family of i2c rtc chips.
> > + *
> > + * Based on m41t00.h by Mark A. Greer <[EMAIL PROTECTED]>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
>
> Unless this include is required by other files, please place
> it in drivers/rtc calling it rtc-drivername.h
It is required by platform code to provide SQW setting. Also
M41TXX_DRV_NAME and M41TXX_I2C_ADDR might be useful to declare
i2c_board_info, which would be something like:
static struct m41txx_platform_data pdata = {
.sqw_freq = M41TXX_SQW_32KHZ,
};
static struct i2c_board_info binfo __initdata = {
I2C_BOARD_INFO(M41TXX_DRV_NAME, M41TXX_I2C_ADDR),
.type = "m41t80",
.platform_data = ,
};
return i2c_register_board_info(0, , 1);
> Other than the comments above, the driver
> seems fine to me.
Thank you for review.
---
Atsushi Nemoto
-
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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 19, 2007, "Josh Williams" <[EMAIL PROTECTED]> wrote: > On 6/18/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: >> Free Software is not about freedom of choice. That's an OSI slogan >> for "if you like, you can shoot your own foot, regardless of whether >> the shrapnel hurts people around you". >> http://www.fsfla.org/?q=en/node/139#1 > When it comes right down to it, the FSF is all about freedom, just > as long as it benefits them. How is "ensuring users have their freedoms respected" beneficial to the FSF, specifically? I can see how that's good for users (and FSF users software), how that's good for thriving Free Software development communities (in some of which the FSF participates), but it looks like you're aiming at more than that. Can you be more specific about the benefits the FSF collects out of this >> Free Software is about respect for the four freedoms. > Yes, there *are* four freedoms, and they are very good. However, > what happens when we have *only* these four freedoms? The FSF would > do anything within their power to impose their "religious" beliefs > upon the entire world, regardless of what's really good for us. Freedom is good for you, such that you can choose. > If we don't have the freedom of choice, You do. That's a consequence of the four freedoms. Without them, you end up without choice. It's not a core freedom for the FSF precisely because freedom of choice can be used to do common good as much as it can to hurt your neighbor. The four freedoms are all freedoms with which you can help yourself or your neighbor, never hurt anyone. You can choose not to help yourself or your neighbor, and then the world is no better off, but if you choose to help yourself or your neighbor, there's progress. Now, freedom of choice can be used against the common good. Choosing to shoot your own feet, on grounds that freedom of choice says you can, could still hurt your neighbors with the shrapnel. That's why freedom of choice is regarded as a secondary freedom. Which is not to say that it's undesirable, just that it's not fundamentally conducive of the common good. It is conducive of common good, as it turns out, in as much as it is a consequence of the other four freedoms. > Each person must be free to make *his*own* decisions of what's best > for him, As long as this doesn't hurt society. > If the FSF insists on defining freedom for us It doesn't. It only defines what Free Software means. Do you by any chance have a problem that OSI defines what "Open Source Software" means, even though it doesn't mean software whose sources are open? Why would you have a problem that the FSF defines what Free Software means, then? If there were other definitions of Free Software out there, it might make sense to qualify them, but there aren't, and coming up with one now that meant something different would be quite confusing. > Yes, I understand and appreciate the problems with proprietary software, but > that's not the _only_ issue that needs dealt with in this world. Sure. I don't think anyone could disagree with this. It just so happens that the Free Software Foundation is a foundation with a registered mission to work on this particular cause. Whether it's a good cause or not, whether it's the most important cause of all or not, can sure be debated among those who'd like to debate it (I don't :-) But if RMS, myself and so many others decided to devote our lives to this cause, and a lot of people agree it's good for society, many agree it's a good cause, even if not everyone likes our methods, who's to tell us we ought to work on some other cause? (FWIW, even if someone asked me, told me or insisted that I do it, I wouldn't go "ooh, they're *forcing* me to work on some other cause!", that would be silly :-) >> It was OSI that tried to create a definition that matched exactly >> the meaning of the Free Software definition under "more objective >> criteria". We already know they failed, since the Reciprocal >> Public License is accepted as an OSS license, but it's a non-Free >> Software license. There may be other examples. > How could an open source license not being a free software license be > considered a failure? Err, see above. It didn't achieve the stated goal. It's indeed difficult to define freedom. > Pardon me for saying so, but I don't think the OSS developers really > give a crap whether their software is considered to be "free" as > long as their goals are met. http://www.opensource.org/node/130 >> That said, since a number of people already understand the GPLv2 >> prohibits tivoization, your argument means that either the comment in >> the OSD is wrong, and GPLv2 already fails to match the OSD, or that >> GPLv3 complies with it in just the same way. > *what*?? That's the first I've heard of this. Nonsense. Ask Alan Cox, for example, he got legal advice about this. Maybe Harald Welte shares the same opinion, certainly backed by good legal
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Tue, Jun 19, 2007 at 06:20:24PM -0300, Alexandre Oliva wrote: > On Jun 19, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote: > > and which will most likely make GPLv3 software unusable for various > > applications ranging from medical equipment to financial transaction > > systems (and probably others) > > Not unusable, except perhaps for the one example about credit card > terminals presented so far. > > > is there to just make it a _bit_ more inconvenient for vendors to > > implement a tivo-like scheme? > > I'm not sure they find it to be "just a bit". > > Point is to keep Free Software Free freedoms, and ROM doesn't make it > non-Free, so this provision is a means to ensure the compliance with > the wishes of users who want their software to not be used in ways > that make it non-Free. You keep referring to the four freedoms so I googled for them and found http://www.gnu.org/philosophy/free-sw.html So which of the freedoms did Tivo take away? * The freedom to run the program, for any purpose (freedom 0). * The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this. * The freedom to redistribute copies so you can help your neighbor (freedom 2). * The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this. It doesn't seem to me they took away freedoms 1, 2 or 3. They released the source to any free software components and we can study, modify, redistribute, improve and release our improvements for the benefit of the whole community. btw. freedom 3 seems to be just repeating what we already got from freedoms 1 and 2. So the only one we could differ in opinion about is freedom 0. I would say that they in no way are limiting my use of the Linux kernel (which is the part I mostly care about) I can run the program for any purpose I see fit. What if I want to run mythtv on my PC at home? Tivo has no control whether or not I can do so even when my kernel contains any of their modification or improvements, so I claim that I in fact retained freedom 0. Your position (and I hope I will get this right), is that they should allow you to run the program for any purpose _on the hardware it is installed on_. Interpreted that way, the whole modification part doesn't even come into play, your freedom is taken away if you cannot even run your own software on top of the already installed kernel. This 'freedom 0' the way (I hope) you are interpreting it, could clearly never have been protected by the GPLv2 since it explicitly does not cover "Activities other than copying, distribution and modification" (GPLv2, term 0) However the GPLv3 does not seem to address this point either, the whole discussion in section 5 about user products and installation information completely misses the fact that none of the 'four freedoms' (which I assume formed the foundation for the license) is about allowing a user to install the program on some particular piece of hardware and that is exactly where I think all this anti-tivoization language is going wrong. It is clearly having a hard time pinning down the exact requirements for something that was not well defined in the first place. The real issue with Tivo isn't that they signed their kernel or their initrd, but that they do not allow you to use that kernel for any purpose, for instance run mythtv or a webserver on their unmodified kernel. Maybe the GPLv3 shouldn't try to talk about license keys or installation information and then heap on some exceptions for non-consumer devices or rom-based implementations and then some further legaleze patches to close the really obvious loopholes. Maybe it if it actually addressed the fact that you want to be able to use the distributed software for any purpose you see fit by allowing you to run your own applications on the kernel they distributed. I still believe they do allow me to use the program for any purpose as they can not limit my use of the Linux kernel whether or not my copy contains any of their contributions, so excuse my while I'll go enjoy some more of my freedom 0. Jan - 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: Problem with global_flush_tlb() on i386 in 2.6.22-rc4-mm2
* Anthony Liguori ([EMAIL PROTECTED]) wrote: > This is actually very conservative seeing as how disabling CR4.PGE > should be sufficient to flush global pages on modern processors. I > suspect you're getting preempted while it's running. > Sorry, I just realized that I rejected your preemption explanation without explaining why: 1 - In my "Text Section" lock code, which is the original place where I triggered the problem, I take a spinlock around these operations, which disables preemption. 2 - My sample module plays alone in its own data structures: there is only one thread accessing the data at a given time (because I do only one file open at a given time, which I control). Regards, Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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.22-rc5 regression
On 2007.06.20 09:15:21 +, Wang Zhenyu wrote:
>
> I think for i965 we could have following patch to fix this, we may
> fail if no IGD device got detected.
>
oops, missing 946G, what a name...
Signed-off-by: Wang Zhenyu <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index 0439ee9..145b4a1 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -1853,17 +1853,17 @@ static const struct intel_driver_description {
{ PCI_DEVICE_ID_INTEL_82945GM_HB, PCI_DEVICE_ID_INTEL_82945GME_IG, 0,
"945GME",
_845_driver, _915_driver },
{ PCI_DEVICE_ID_INTEL_82946GZ_HB, PCI_DEVICE_ID_INTEL_82946GZ_IG, 0,
"946GZ",
- _845_driver, _i965_driver },
+ NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_82965G_1_HB, PCI_DEVICE_ID_INTEL_82965G_1_IG, 0,
"965G",
- _845_driver, _i965_driver },
+ NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_82965Q_HB, PCI_DEVICE_ID_INTEL_82965Q_IG, 0,
"965Q",
- _845_driver, _i965_driver },
+ NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_82965G_HB, PCI_DEVICE_ID_INTEL_82965G_IG, 0,
"965G",
- _845_driver, _i965_driver },
+ NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_82965GM_HB, PCI_DEVICE_ID_INTEL_82965GM_IG, 1,
"965GM",
- _845_driver, _i965_driver },
+ NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_82965GM_HB, PCI_DEVICE_ID_INTEL_82965GME_IG, 0,
"965GME/GLE",
- _845_driver, _i965_driver },
+ NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_7505_0, 0, 0, "E7505", _7505_driver, NULL },
{ PCI_DEVICE_ID_INTEL_7205_0, 0, 0, "E7205", _7505_driver, NULL },
{ PCI_DEVICE_ID_INTEL_G33_HB, PCI_DEVICE_ID_INTEL_G33_IG, 0, "G33",
@@ -1917,6 +1917,7 @@ static int __devinit agp_intel_probe(struct pci_dev *pdev,
}
if (bridge->driver == NULL) {
+ /* The bridge has no AGP or no gfx device */
printk(KERN_WARNING PFX "Failed to find bridge device "
"(chip_id: %04x)\n",
intel_agp_chipsets[i].gmch_chip_id);
agp_put_bridge(bridge);
---
-
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/
Freezes on sata_uli hd
Hello everyone! I've got this problem from a while, and maybe this time I've nailed a portion of it; here goes: I'm running Gentoo Linux, latest stable gentoo-sources (2.6.20-r8). I'm having random freezes of the system, including no mouse or keyboard interaction (SysRq not working), all accompanied by a stable-on HD activity led; HD seems not to work though, and X activity remains frozen; the only alternative is to hard reset. Changed memory timing in bios, swapped memory, changed SMART, changed sata cables and ports; no avail. /var/log/messages shows no unusual activity, so there's not an oops or other significant message before freezing. This last time the system froze only for the libata part, leaving me keyboard mouse X and other HD activity stable; dmesg showed the following: ata1: SATA max UDMA/133 cmd 0xC2020100 ctl 0x0 bmdma 0x0 irq 35 ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 31/32) ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/133 sata_uli :00:12.1: version 1.0 ata2: SATA max UDMA/133 cmd 0xEC00 ctl 0xE082 bmdma 0xD880 irq 19 ata3: SATA max UDMA/133 cmd 0xE000 ctl 0xDC02 bmdma 0xD888 irq 19 scsi1 : sata_uli ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: ATA-7, max UDMA/133, 586114704 sectors: LBA48 NCQ (depth 0/32) ata2.00: ata2: dev 0 multi count 16 ata2.00: configured for UDMA/133 scsi2 : sata_uli ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd c8/00:40:0b:3a:e9/00:00:00:00:00/e6 tag 0 cdb 0x0 data 32768 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: port failed to respond (30 secs, Status 0xd0) ata2: soft resetting port ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: configured for UDMA/133 ata2: EH complete SCSI device sdb: 586114704 512-byte hdwr sectors (300091 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA I noticed NCQ is not enabled on that device, and trying to echo 31 to queue_depth initially gives permission denied; chmod root to rw, then echo 31 to queue_depth gives input/output error. I don't know if this is relevant to the total freezes, and haven't been able to find correspondence between ata devices and /dev/sdx ; if I can give you any more info, I'll be glad to. Meanwhile: lspci -v to the relevant devices: 00:12.1 IDE interface: ALi Corporation ULi 5289 SATA (rev 10) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: ASRock Incorporation Unknown device 5289 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 19 I/O ports at ec00 [size=8] I/O ports at e080 [size=4] I/O ports at e000 [size=8] I/O ports at dc00 [size=4] I/O ports at d880 [size=16] Thanks in advance, tommy signature.asc Description: This is a digitally signed message part.
[patch] add printk_ratelimit to atkbd_interrupt
Add printk_ratelimit() to atkbd_interrupt(). I get "Spurious ACK" messages flushing on my screen. This patch helps to read the screen. Signed-off-by: Qi Yong <[EMAIL PROTECTED]> -- diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c index be1fe46..13e6bd4 100644 --- a/drivers/input/keyboard/atkbd.c +++ b/drivers/input/keyboard/atkbd.c @@ -408,9 +408,10 @@ static irqreturn_t atkbd_interrupt(struct serio *serio, unsigned char data, goto out; case ATKBD_RET_ACK: case ATKBD_RET_NAK: - printk(KERN_WARNING "atkbd.c: Spurious %s on %s. " - "Some program might be trying access hardware directly.\n", - data == ATKBD_RET_ACK ? "ACK" : "NAK", serio->phys); + if (printk_ratelimit()) + printk(KERN_WARNING "atkbd.c: Spurious %s on %s. " + "Some program might be trying access hardware directly.\n", + data == ATKBD_RET_ACK ? "ACK" : "NAK", serio->phys); goto out; case ATKBD_RET_HANGEUL: case ATKBD_RET_HANJA: - 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: GIT Packages for Debian Etch
On Jun 19, 2007, at 19:37:51, Jeffrey Hundstad wrote: I'm just not going to let this go. Stable is synonymous with, well ummm, "stable." That means that I don't have 3000 changes a month, it's secure and the unexpected doesn't happen. It means I can write a lecture explaining how git works. ...do updates... then expect my lecture to still work the next day. It means writing local shell scripts and expecting them to work until the NEXT stable release without changes. It means knowing what things WILL break if and when I do go to the next version. Stable is a CHOICE not a punishment. With that said; Debian makes it easy to selectively install testing or unstable packages by adding "testing" or "unstable" to your sources.list and putting this in /etc/apt/apt.conf: APT::Default-Release "stable"; Then all apt-based programs will prefer stable packages everywhere possible. If you explicitly run "apt-get install somepackage/ testing", then it will install the testing version of that package and continue to auto-upgrade it as testing receives updates. Alternatively, you can "man apt_preferences" and tweak your "/etc/apt/ preferences" file to your heart's content. This includes things like "Forcibly downgrade packages to the 'local' version if found in my local deb repo", "Prefer stable over testing and unstable", etc. Cheers, Kyle Moffett - 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: Problem with global_flush_tlb() on i386 in 2.6.22-rc4-mm2
* Anthony Liguori ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers wrote:
> >Hi,
> >
> >Trying to test my "Text Edit Lock" patches, I ran into a problem related
> >to global_flush_tlb() not doing its job at updating the page flags when,
> >it seems, the page has been recently accessed. Therefore, it can only be
> >reproduced by doing a couple of iterations.
> >
> >This is clearly the memory write I am trying to do in the page of
> >which I just changed the attributes to RWX.
> >
> >If I remove the variable read before I change the flags, it starts
> >working correctly (as far as I have tested...).
> >
> >If I use my own my_local_tlb_flush() function (not SMP aware) instead of
> >global_flush_tlb(), it works correctly.
> >
>
> What is your my_local_tlb_flush() and are you calling with preemption
> disabled?
>
The implementation was below in the email. Full preemption was enabled.
> >I also tried just calling clflush on the modified page just after the
> >global_flush_tlb(), and the problem was still there.
> >
> >I therefore suspect that
> >
> >include/asm-i386/tlbflush.h:
> >#define __native_flush_tlb_global() \
> >do {\
> >unsigned int tmpreg, cr4, cr4_orig; \
> >\
> >__asm__ __volatile__( \
> >"movl %%cr4, %2; # turn off PGE \n"\
> >"movl %2, %1;\n"\
> >"andl %3, %1;\n"\
> >"movl %1, %%cr4; \n"\
> >"movl %%cr3, %0; \n"\
> >"movl %0, %%cr3; # flush TLB\n"\
> >"movl %2, %%cr4; # turn PGE back on \n"\
> >: "=" (tmpreg), "=" (cr4), "=" (cr4_orig) \
> >: "i" (~X86_CR4_PGE)\
> >: "memory");\
> >} while (0)
> >
> >is not doing its job correctly. The problem does not seem to be caused
> >by PARAVIRT, because it is still buggy even if I disable the PARAVIRT
> >config option.
>
> This is actually very conservative seeing as how disabling CR4.PGE
> should be sufficient to flush global pages on modern processors. I
> suspect you're getting preempted while it's running.
>
Thanks for the advice, but please have a look at my follow-up on the
issue, where I spotted the problem more precisely. It also affects
ioremap, which also uses global_flush_tlb(). I guess this bug is worth
being fixed quickly, even if it is just by applying my workaround (which
is _really_ conservative).
Regards,
Mathieu
> Regards,
>
> Anthony Liguori
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
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: Fix signalfd interaction with thread-private signals
On Tue, 2007-06-19 at 16:49 -0700, Davide Libenzi wrote: > Actually, I think signalfd is fine as is, with Ben's patch applied. > Signalfd should only fetch shared signals, not specific ones (in any > case). The only advantage of that additional patch is that it will allow any thread to fetch its own private signals via signalfd, regardless of what context is attached to the signalfd in the first place. Without the patch (with what's currently in Linus tree), a thread will only get its own private signals if it's also the thread that created the signalfd (and thus is attached to the signalfd "context"). I don't mind either way, up to you guys to decide what semantics you want. 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: [PATCH] relay-file-read-start-pos-fix.patch
Tom Zanussi wrote: > Hi, > > I haven't had a chance to test it myself yet, but it looks ok to me, > except for one problem noted below... Hi, Thank you so much! I'm preparing how it can reproduce. I'll send it as soon as possible. > Thanks for fixing it. > >> Signed-off-by: Masami Hiramatsu <[EMAIL PROTECTED]> >> >> --- >> kernel/relay.c |8 ++-- >> 1 file changed, 6 insertions(+), 2 deletions(-) >> >> Index: linux-2.6.22-rc4-mm2/kernel/relay.c >> === >> --- linux-2.6.22-rc4-mm2.orig/kernel/relay.c 2007-06-13 20:22:02.0 >> +0900 >> +++ linux-2.6.22-rc4-mm2/kernel/relay.c 2007-06-18 23:00:54.0 >> +0900 >> @@ -812,7 +812,10 @@ >> } >> >> buf->bytes_consumed += bytes_consumed; >> -read_subbuf = read_pos / buf->chan->subbuf_size; >> +if (!read_pos) >> +read_subbuf = buf->subbufs_consumed; > > I think this should be instead: > > + read_subbuf = buf->subbufs_consumed % n_subbufs; Yes, you are right. Thank you again. -- Masami HIRAMATSU Linux Technology Center Hitachi, Ltd., Systems Development Laboratory E-mail: [EMAIL PROTECTED] - 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: Problem with global_flush_tlb() on i386 in 2.6.22-rc4-mm2
Mathieu Desnoyers wrote: Hi, Trying to test my "Text Edit Lock" patches, I ran into a problem related to global_flush_tlb() not doing its job at updating the page flags when, it seems, the page has been recently accessed. Therefore, it can only be reproduced by doing a couple of iterations. I run on a Pentium 4 with the following characteristics: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz stepping: 1 cpu MHz : 3000.201 cache size : 1024 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pebs bts sync_rdtsc pni monitor ds_cpl cid xtpr bogomips: 6007.49 clflush size: 64 config : CONFIG_X86_INVLPG=y (complete .config at the end) CONFIG_PARAVIRT=y/n (notice that pge and clflush features are present) The kernel is configured in UP (I first saw the problem in SMT, but switched to UP and it is still there). I provide a really crude hackish test module that shows the problematic behavior below. Whenever I run the module using global_flush_tlb(), I get the following OOPS: [ 1112.512389] Init Attr RX [ 1112.521691] Init Attr RX end [ 1113.702965] Loop 0 [ 1113.709171] Attr RWX 621545 [ 1113.717662] Attr RX 621545 [ 1113.725869] Attr RWX 432917 [ 1113.734295] Attr RX 432917 [ 1113.742460] Attr RWX 973425 [ 1113.750885] Attr RX 973425 [ 1113.759048] Attr RWX 453890 [ 1113.767490] Attr RX 453890 [ 1113.775653] Attr RWX 1035918 [ 1113.784341] Attr RX 1035918 [ 1113.792764] Attr RWX 1038276 [ 1113.801449] Attr RX 1038276 [ 1113.809902] Attr RWX 71394 [ 1113.818067] Attr RX 71394 [ 1113.825970] Attr RWX 88253 [ 1113.834134] Attr RX 88253 [ 1113.842039] Attr RWX 108029 [ 1113.850505] Attr RX 108029 [ 1113.858670] Attr RWX 767772 [ 1113.867095] Attr RX 767772 [ 1113.875259] Attr RWX 251394 [ 1113.883694] Attr RX 251394 [ 1113.891859] Attr RWX 817582 [ 1113.900376] Attr RX 817582 [ 1113.908540] Attr RWX 577819 [ 1113.916965] Attr RX 577819 [ 1113.925127] Attr RWX 56979 [ 1113.933293] Attr RX 56979 [ 1113.941195] Attr RWX 72953 [ 1113.949361] Attr RX 72953 [ 1113.957265] Attr RWX 94222 [ 1113.965445] BUG: unable to handle kernel paging request at virtual address c3a1700e [ 1113.988291] printing eip: [ 1113.996340] f885e0a6 [ 1114.002835] *pde = 038c6163 [ 1114.011145] *pte = 03a17163 [ 1114.019455] Oops: 0003 [#1] [ 1114.027766] PREEMPT [ 1114.034268] LTT NESTING LEVEL : 0 [ 1114.044402] Modules linked in: test_rodata ltt_statedump ltt_control sky2 skge rtc snd_hda_intel [ 1114.070679] CPU:0 [ 1114.070680] EIP:0060:[]Not tainted VLI [ 1114.070681] EFLAGS: 00010282 (2.6.22-rc4-mm2-testssmp #129) [ 1114.110395] EIP is at my_open+0xa6/0x124 [test_rodata] [ 1114.125711] eax: c3a0 ebx: 0001700e ecx: c39e4000 edx: [ 1114.145953] esi: 36f1700e edi: f885e000 ebp: c39e5ebc esp: c39e5ea0 [ 1114.166195] ds: 007b es: 007b fs: gs: 0033 ss: 0068 [ 1114.183583] Process cat (pid: 4112, ti=c39e4000 task=c38ac1b0 task.ti=c39e4000) [ 1114.204862] Stack: f885e223 0001700e f000 c31d3480 f885e000 c39e5ed8 [ 1114.229843]c01a3c2a c39d2540 c368d4a8 c39d2540 c368d4a8 c39e5ef8 c016f5d9 [ 1114.254830]c1c0eec0 c378ccfc c39e5eec c39d2540 8000 c39e5f1c c39e5f0c c016f76b [ 1114.279814] Call Trace: [ 1114.287620] [] proc_reg_open+0x42/0x68 [ 1114.301655] [] __dentry_open+0xe6/0x1e2 [ 1114.315944] [] nameidata_to_filp+0x35/0x3f [ 1114.331008] [] do_filp_open+0x3b/0x43 [ 1114.344777] [] do_sys_open+0x43/0x116 [ 1114.358545] [] sys_open+0x1c/0x1e [ 1114.371274] [] syscall_call+0x7/0xb [ 1114.384524] [] 0xe410 [ 1114.395178] === [ 1114.405823] INFO: lockdep is turned off. [ 1114.417504] Code: 60 df 7c c0 b9 63 01 00 00 ba 01 00 00 00 e8 3f 7d 8b c7 0f ae f0 89 f6 e8 5c 80 8b c7 0f ae f0 89 f6 a1 88 eb 85 f8 0f b6 55 f0 <88> 14 03 0f ae f0 89 f6 89 d8 03 05 88 eb 85 f8 05 00 00 00 40 [ 1114.474329] EIP: [] my_open+0xa6/0x124 [test_rodata] SS:ESP 0068:c39e5ea0 [ 1114.497187] BUG: sleeping function called from invalid context at kernel/rwsem.c:20 [ 1114.520025] in_atomic():0, irqs_disabled():1 [ 1114.532744] INFO: lockdep is turned off. [ 1114.544427] irq event stamp: 1894 [ 1114.554293] hardirqs last enabled at (1893): [] _spin_unlock_irq+0x22/0x4e [ 1114.577666] hardirqs last disabled at (1894): [] _spin_lock_irqsave+0x25/0x61 [ 1114.601556] softirqs last enabled at (1886): [] __do_softirq+0xe1/0x184 [ 1114.624149] softirqs last disabled at (1875): [] do_softirq+0x72/0x77 [ 1114.645969] [] dump_trace+0x1d5/0x204 [ 1114.659737] [] show_trace_log_lvl+0x1a/0x30 [ 1114.675060] []
Re: 2.6.22-rc5 regression
On 2007.06.20 01:37:16 +, Carlo Wood wrote:
> The result of this patch is that the kernel starts to print
> "agpgart: Detected an Intel 965G Chipset." again with the usual
> disastrous results. Now, that doesn't mean that this patch is
> wrong - but it explains why the problem returns after this patch.
>
Yep, the device table patch doesn't change any function, so your problem
started from when 965G support patch has been in kernel.
Carlo, pls try a kernel param of "pci=nommconf" to see if that could
fix your hang. There might be a BIOS bug, as similar issue also happen
like https://bugzilla.novell.com/show_bug.cgi?id=228683
I think for i965 we could have following patch to fix this, we may
fail if no IGD device got detected.
Signed-off-by: Wang Zhenyu <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index 0439ee9..5a54a9c 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -1855,15 +1855,15 @@ static const struct intel_driver_description {
{ PCI_DEVICE_ID_INTEL_82946GZ_HB, PCI_DEVICE_ID_INTEL_82946GZ_IG, 0,
"946GZ",
_845_driver, _i965_driver },
{ PCI_DEVICE_ID_INTEL_82965G_1_HB, PCI_DEVICE_ID_INTEL_82965G_1_IG, 0,
"965G",
- _845_driver, _i965_driver },
+ NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_82965Q_HB, PCI_DEVICE_ID_INTEL_82965Q_IG, 0,
"965Q",
- _845_driver, _i965_driver },
+ NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_82965G_HB, PCI_DEVICE_ID_INTEL_82965G_IG, 0,
"965G",
- _845_driver, _i965_driver },
+ NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_82965GM_HB, PCI_DEVICE_ID_INTEL_82965GM_IG, 1,
"965GM",
- _845_driver, _i965_driver },
+ NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_82965GM_HB, PCI_DEVICE_ID_INTEL_82965GME_IG, 0,
"965GME/GLE",
- _845_driver, _i965_driver },
+ NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_7505_0, 0, 0, "E7505", _7505_driver, NULL },
{ PCI_DEVICE_ID_INTEL_7205_0, 0, 0, "E7205", _7505_driver, NULL },
{ PCI_DEVICE_ID_INTEL_G33_HB, PCI_DEVICE_ID_INTEL_G33_IG, 0, "G33",
@@ -1917,6 +1917,7 @@ static int __devinit agp_intel_probe(struct pci_dev *pdev,
}
if (bridge->driver == NULL) {
+ /* The bridge has no AGP or no gfx device */
printk(KERN_WARNING PFX "Failed to find bridge device "
"(chip_id: %04x)\n",
intel_agp_chipsets[i].gmch_chip_id);
agp_put_bridge(bridge);
---
-
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: [Intel IOMMU 06/10] Avoid memory allocation failures in dma map api calls
On Tue, 2007-06-19 at 16:34 -0700, Christoph Lameter wrote: > On Tue, 19 Jun 2007, Arjan van de Ven wrote: > > > > Otherwise you are locked into the use of GFP_ATOMIC. > > > > all callers pretty much are either in irq context or with spinlocks held. > > Good > > luck. it's also called primarily from the PCI DMA API which doesn't > > take a > > gfp_t argument in the first place... > > > > so I'm not seeing the point. > > Hmmm... From my superficial look at things it seems that one could avoid > GFP_ATOMIC at times. by changing ALL drivers. And then you realize the common scenario is that it's taken in irq context ;) > I do not know too much about the driver though but it > seems a bit restrictive to always do GFP_ATOMIC allocs. the only alternative to GFP_ATOMIC is GFP_NOIO which is... barely better. And then add that it can be used only sporadic... feel free to first change all the drivers.. once the callers of these functions have a gfp_t then I'm sure Anil will be happy to take one of those as well ;-) - 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/12] acpi: select ACPI_EC for THINKPAD_ACPI
On Wed, 20 Jun 2007, Andreas Herrmann wrote: > Fix kernel build problem: > > thinkpad_acpi.c:(.text+0x7486a): undefined reference to `ec_write' > > (as THINKPAD_ACPI depends on ACPI_EC) > > Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> > --- > drivers/misc/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index 2f2fbff..72774c9 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -139,6 +139,7 @@ config SONYPI_COMPAT > config THINKPAD_ACPI > tristate "ThinkPad ACPI Laptop Extras" > depends on X86 && ACPI > + select ACPI_EC > select BACKLIGHT_CLASS_DEVICE > select HWMON > ---help--- Acked-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 19, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > Company X has requirement for restriction Y > => License on product Z disallows restriction Y > => Product Z loses Company X and the exposure use in their product gives > => License on product Z is bad for the product > Understandable now? Well, considering that I've made this claim myself as part of my complete argument in a number of times I've presented it, yes, this is understandable and correct. This is indeed one of the cases. That said, very few companies have a scrict *requirement* for keeping the ability to modify the software on the customer's computer while denying this ability to the customer. So this case you're discussing is the least common case. It could nearly be dismissed, rather than being the dominating topic in the discussion, as it's been so far. > What I was stating is that are legal (and other reasons) why a > company might have to lock down their software in a process similar > to "Tivoization". Ok. Most of these can be addressed (with inconvenience) with ROM. Others are business reasons, and for these, the increased cost and inconvenience of the alternatives may shift them to an unlock situation. >> Therefore, this claim is false. > Only when you define a term as specifically as you have done > for "Tivoization". It's not my definition. This was from Wikipedia. > I should, perhaps, have used a different term - it would > then have been patently true. Depends on what the different term was. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 19, 2007, [EMAIL PROTECTED] wrote: > if you also make the assumption that the company won't use propriatary > software instead then I think you would get agreement. Ah, good point. When I posed the one of the two cases of the inicial scenario as "no tivoization", I meant Free Software without constraints. > but the disagrement is over this exact assumption. you assume that > these companies will use non-tivoized products if you make it hard > to use the software covered by the GPL, most other people are saying > that they disagree and the result would be fewer companies useing > software covered by GPL instead. I understand that. And what I'm saying is that, even if fewer such companies use GPLed software, you may still be better off, out of additional contributions you'll get from customers of companies that switch from tivoization to unconstrained Free Software, because of the additional costs of the alternatives. And no, I can't prove it, but it's good that at least the argument is no longer completely disregarded while something else is disputed. Now that you guys at least understand what the argument is, you can figure out the solution by yourselves. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.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: mea culpa on the meaning of Tivoization
On Jun 19, 2007, Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote: >> >> Let's just hope it never is, or that some influx of >> >> long-sighted comes in >> >> > Kernel programmers are short-sighted? What kind of arrogance is that? >> >> It's just stating the obvious. The upgrade path is a nightmare. > Well, maybe. Maybe this is a topic that needs further discussion. > But I don't find it very important as we're not in a situation where > we urgently need a new license. Agreed. It could have been discussed years ago, when the clarification on GPLv2-only came up, but it's still not urgent, and hopefully it never will be. It wouldn't be a bad idea to think about it, though. Just in case it's not clear, this is in no way related with GPLv3. It's just that GPLv3 discussions appear to get more people thinking about relicensing, and then the "impossibilities" of doing it come up. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.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: Versioning file system
On Tue, 2007-06-19 at 16:35 -0700, Bryan Henderson wrote: > >We don't need a new special character for every > >> new feature. We've got one, and it's flexible enough to do what you > want, > >> as proven by NetApp's extremely successful implementation. > > I don't know NetApp's implementation, but I assume it is more than just a > choice of special character. If you merely start the directory name with > a dot, you don't fool anyone but 'ls' and shell wildcard expansion. (And > for some enlightened people like me, you don't even fool ls, because we > use the --almost-all option to show the dot files by default, having been > burned too many times by invisible files). > > I assume NetApp flags the directory specially so that a POSIX directory > read doesn't get it. I've seen that done elsewhere. No. The directory is quite visible with a standard 'ls -a'. Instead, they simply mark it as a separate volume/filesystem: i.e. the fsid differs when you call stat(). The whole thing ends up acting rather like our bind mounts. It means that you avoid all those nasty user issues where people try to hard link to/from .snapshot directories, rename files across snapshot boundaries, etc. Trond - 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-lvm] 2.6.22-rc5 XFS fails after hibernate/resume
On Tue, Jun 19, 2007 at 10:24:23AM +0100, David Greaves wrote: > David Greaves wrote: > so I cd'ed out of /scratch and umounted. > > I then tried the xfs_check. > > haze:~# xfs_check /dev/video_vg/video_lv > ERROR: The filesystem has valuable metadata changes in a log which needs to > be replayed. Mount the filesystem to replay the log, and unmount it before > re-running xfs_check. If you are unable to mount the filesystem, then use > the xfs_repair -L option to destroy the log and attempt a repair. > Note that destroying the log may cause corruption -- please attempt a mount > of the filesystem before doing this. > haze:~# mount /scratch/ > haze:~# umount /scratch/ > haze:~# xfs_check /dev/video_vg/video_lv > > Message from [EMAIL PROTECTED] at Tue Jun 19 08:47:30 2007 ... > haze kernel: Bad page state in process 'xfs_db' I think we can safely say that your system is hosed at this point ;) > ugh. Try again > haze:~# xfs_check /dev/video_vg/video_lv > haze:~# zero output means no on-disk corruption was found. Everything is consistent on disk, so that seems to indicate something in memory has been crispy fried by the suspend/resume > Dave, I ran xfs_check -v... but I got bored when it reached 122M of bz2 > compressed output with no sign of stopping... still got it if it's any > use... No, not useful. It's a log of every operation it does and so is really only useful for debugging xfs-check problems ;) > I then rebooted and ran a repair which didn't show any damage. Not surprising as your first check showed no damage. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/18/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: ... derived from the Debian Free Software Guidelines, engineered to reflect the Free Software definition ... Yes, that's true, but it was modified in several key points. OSS and FS developers have a very similar approach to developing software, but our goals are different. So why does it come to a shock that the open source definition greatly resembles the four rights of free software? Err... Excuse me? Whole point for whom? Free Software is not about freedom of choice. That's an OSI slogan for "if you like, you can shoot your own foot, regardless of whether the shrapnel hurts people around you". http://www.fsfla.org/?q=en/node/139#1 And in Rms's opinion, a woman's freedom to make decisions about her own body are hers to choose, regardless of whether this means murdering an innocent child. (Do I see a conflict here?) When it comes right down to it, the FSF is all about freedom, just as long as it benefits them. They couldn't care less whether our society is productive. For them, the software is not top priority, as they have been very vocal about, and as Linus mentioned earlier in this thread. Free Software is about respect for the four freedoms. Yes, there *are* four freedoms, and they are very good. However, what happens when we have *only* these four freedoms? The FSF would do anything within their power to impose their "religious" beliefs upon the entire world, regardless of what's really good for us. If we don't have the freedom of choice, then are we really free? Each person must be free to make *his*own* decisions of what's best for him, even if it means one of his appliances is "tivoized". That's really *his* decision, isn't it? If the FSF insists on defining freedom for us (and very narrowly, at that), then perhaps we'd be better off without them. After all, isn't true freedom the right to choose whatever freedoms you want to practise? Yes, I understand and appreciate the problems with proprietary software, but that's not the _only_ issue that needs dealt with in this world. It's getting to the point where the FSF has become just as bad as Microsoft, yet in a different way. I don't think the FSF is at all concerned whether GPLv3 complies with the OSD. They couldn't care less. Are you serious? WOW! =O It was OSI that tried to create a definition that matched exactly the meaning of the Free Software definition under "more objective criteria". We already know they failed, since the Reciprocal Public License is accepted as an OSS license, but it's a non-Free Software license. There may be other examples. How could an open source license not being a free software license be considered a failure? Pardon me for saying so, but I don't think the OSS developers really give a crap whether their software is considered to be "free" as long as their goals are met. That said, since a number of people already understand the GPLv2 prohibits tivoization, your argument means that either the comment in the OSD is wrong, and GPLv2 already fails to match the OSD, or that GPLv3 complies with it in just the same way. *what*?? That's the first I've heard of this. Nonsense. If that were true, we wouldn't be having this debate, am I correct? -- It's common knowledge that most intruders come in through Windows. - 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/2] HFS+: custom dentry hash and comparison operations
The HFS+ filesystem is case-insensitive and does automatic unicode decomposition by default, but does not provide custom dentry operations. This can lead to multiple dentries being cached for lookups on a filename with varying case and/or character (de)composition. These patches add custom dentry hash and comparison operations for case-sensitive and/or automatically decomposing HFS+ filesystems. Unicode decomposition and case-folding are performed as required to ensure equivalent filenames are hashed to the same values and compare as equal. Tested on i386, x86_64 and PPC. See bug reports here for more information: http://bugzilla.kernel.org/show_bug.cgi?id=7240 http://bugs.gentoo.org/show_bug.cgi?id=178298 Cheers, Duane Griffin. -- "I never could learn to drink that blood and call it wine" - Bob Dylan - 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/2] HFS+: Refactor ASCII to unicode conversion routine for later reuse
Refactor existing HFS+ ASCII to unicode string conversion routine to
split out character conversion functionality. This will be reused by
the custom dentry hash and comparison routines. This approach avoids
unnecessary memory allocation compared to using the string conversion
routine directly in the new functions.
Signed-off-by: Duane Griffin <[EMAIL PROTECTED]>
---
--- linux-2.6.21.orig/fs/hfsplus/unicode.c
+++ linux-2.6.21/fs/hfsplus/unicode.c
@@ -239,58 +239,97 @@ out:
return res;
}
-int hfsplus_asc2uni(struct super_block *sb, struct hfsplus_unistr *ustr, const
char *astr, int len)
+/*
+ * Convert one or more ASCII characters into a single unicode character.
+ * Returns the number of ASCII characters corresponding to the unicode char.
+ */
+static
+int asc2uc(struct super_block *sb, const char *astr, int len, wchar_t *uc)
{
- struct nls_table *nls = HFSPLUS_SB(sb).nls;
- int size, off, decompose;
- wchar_t c;
- u16 outlen = 0;
+ int size = HFSPLUS_SB(sb).nls->char2uni(astr, len, uc);
+ if (size <= 0) {
+ *uc = '?';
+ size = 1;
+ }
+ switch (*uc) {
+ case 0x2400:
+ *uc = 0;
+ break;
+ case ':':
+ *uc = '/';
+ break;
+ }
+ return size;
+}
+
+struct decomposed_uc {
+ int size;
+ wchar_t str[3];
+};
+
+/* Decomposes a single unicode character. */
+static void decompose_uc(wchar_t uc, struct decomposed_uc *duc)
+{
+ int off, ii;
- decompose = !(HFSPLUS_SB(sb).flags & HFSPLUS_SB_NODECOMPOSE);
+ duc->size = 1;
+ duc->str[0] = uc;
+
+ off = hfsplus_decompose_table[(uc >> 12) & 0xf];
+ if (off == 0 || off == 0x)
+ return;
+
+ off = hfsplus_decompose_table[off + ((uc >> 8) & 0xf)];
+ if (!off)
+ return;
+
+ off = hfsplus_decompose_table[off + ((uc >> 4) & 0xf)];
+ if (!off)
+ return;
+
+ off = hfsplus_decompose_table[off + (uc & 0xf)];
+
+ duc->size = off & 3;
+ off /= 4;
+ for (ii = 0; ii < duc->size; ++ii)
+ duc->str[ii] = hfsplus_decompose_table[off++];
+}
+
+/*
+ * Convert a ASCII character(s) to a unicode character.
+ * The unicode character will be decomposed, if required.
+ * Returns the number of ASCII characters converted.
+ */
+static int asc2ucd(struct super_block *sb,
+ const char *astr, int len, struct decomposed_uc *duc)
+{
+ int size = asc2uc(sb, astr, len, duc->str);
+ bool decompose = !(HFSPLUS_SB(sb).flags & HFSPLUS_SB_NODECOMPOSE);
+
+ if (decompose && *duc->str >= 0xc0)
+ decompose_uc(*duc->str, duc);
+ else
+ duc->size = 1;
+
+ return size;
+}
+
+int hfsplus_asc2uni(struct super_block *sb,
+ struct hfsplus_unistr *ustr, const char *astr, int len)
+{
+ u16 outlen = 0;
+ struct decomposed_uc duc;
while (outlen < HFSPLUS_MAX_STRLEN && len > 0) {
- size = nls->char2uni(astr, len, );
- if (size <= 0) {
- c = '?';
- size = 1;
- }
+ int ii;
+ int size = asc2ucd(sb, astr, len, );
+ if (outlen + duc.size > HFSPLUS_MAX_STRLEN)
+ break;
+
astr += size;
len -= size;
- switch (c) {
- case 0x2400:
- c = 0;
- break;
- case ':':
- c = '/';
- break;
- }
- if (c >= 0xc0 && decompose) {
- off = hfsplus_decompose_table[(c >> 12) & 0xf];
- if (!off)
- goto done;
- if (off == 0x) {
- goto done;
- }
- off = hfsplus_decompose_table[off + ((c >> 8) & 0xf)];
- if (!off)
- goto done;
- off = hfsplus_decompose_table[off + ((c >> 4) & 0xf)];
- if (!off)
- goto done;
- off = hfsplus_decompose_table[off + (c & 0xf)];
- size = off & 3;
- if (!size)
- goto done;
- off /= 4;
- if (outlen + size > HFSPLUS_MAX_STRLEN)
- break;
- do {
- ustr->unicode[outlen++] =
cpu_to_be16(hfsplus_decompose_table[off++]);
- } while (--size > 0);
- continue;
- }
- done:
- ustr->unicode[outlen++] = cpu_to_be16(c);
+ for (ii = 0; ii < duc.size; ++ii)
+ ustr->unicode[outlen++]
[patch 2/2] HFS+: Add custom dentry hash and comparison operations
Add custom dentry hash and comparison operations for HFS+ filesystems
that are case-insensitive and/or do automatic unicode decomposition.
The new operations reuse the existing HFS+ ASCII to unicode conversion,
unicode decomposition and case folding functionality.
Signed-off-by: Duane Griffin <[EMAIL PROTECTED]>
---
--- linux-2.6.21.orig/fs/hfsplus/dir.c
+++ linux-2.6.21/fs/hfsplus/dir.c
@@ -36,6 +36,11 @@ static struct dentry *hfsplus_lookup(str
u16 type;
sb = dir->i_sb;
+
+ if (!(HFSPLUS_SB(sb).flags & HFSPLUS_SB_HFSX) ||
+ !(HFSPLUS_SB(sb).flags & HFSPLUS_SB_NODECOMPOSE))
+ dentry->d_op = _dentry_operations;
+
dentry->d_fsdata = NULL;
hfs_find_init(HFSPLUS_SB(sb).cat_tree, );
hfsplus_cat_build_key(sb, fd.search_key, dir->i_ino, >d_name);
--- linux-2.6.21.orig/fs/hfsplus/hfsplus_fs.h
+++ linux-2.6.21/fs/hfsplus/hfsplus_fs.h
@@ -321,6 +321,7 @@ void hfsplus_file_truncate(struct inode
/* inode.c */
extern const struct address_space_operations hfsplus_aops;
extern const struct address_space_operations hfsplus_btree_aops;
+extern struct dentry_operations hfsplus_dentry_operations;
void hfsplus_inode_read_fork(struct inode *, struct hfsplus_fork_raw *);
void hfsplus_inode_write_fork(struct inode *, struct hfsplus_fork_raw *);
@@ -353,6 +354,8 @@ int hfsplus_strcasecmp(const struct hfsp
int hfsplus_strcmp(const struct hfsplus_unistr *, const struct hfsplus_unistr
*);
int hfsplus_uni2asc(struct super_block *, const struct hfsplus_unistr *, char
*, int *);
int hfsplus_asc2uni(struct super_block *, struct hfsplus_unistr *, const char
*, int);
+int hfsplus_hash_dentry(struct dentry *dentry, struct qstr *str);
+int hfsplus_compare_dentry(struct dentry *dentry, struct qstr *s1, struct qstr
*s2);
/* wrapper.c */
int hfsplus_read_wrapper(struct super_block *);
--- linux-2.6.21.orig/fs/hfsplus/inode.c
+++ linux-2.6.21/fs/hfsplus/inode.c
@@ -130,6 +130,12 @@ const struct address_space_operations hf
.writepages = hfsplus_writepages,
};
+struct dentry_operations hfsplus_dentry_operations = {
+ .d_revalidate = NULL,
+ .d_hash = hfsplus_hash_dentry,
+ .d_compare= hfsplus_compare_dentry,
+};
+
static struct dentry *hfsplus_file_lookup(struct inode *dir, struct dentry
*dentry,
struct nameidata *nd)
{
--- linux-2.6.21.orig/fs/hfsplus/super.c
+++ linux-2.6.21/fs/hfsplus/super.c
@@ -396,6 +396,10 @@ static int hfsplus_fill_super(struct sup
} else
hfs_find_exit();
+ if (!(HFSPLUS_SB(sb).flags & HFSPLUS_SB_HFSX) ||
+ !(HFSPLUS_SB(sb).flags & HFSPLUS_SB_NODECOMPOSE))
+ sb->s_root->d_op = _dentry_operations;
+
if (sb->s_flags & MS_RDONLY)
goto out;
--- linux-2.6.21.orig/fs/hfsplus/unicode.c
+++ linux-2.6.21/fs/hfsplus/unicode.c
@@ -314,6 +314,22 @@ static int asc2ucd(struct super_block *s
return size;
}
+/*
+ * Convert a ASCII character(s) to a unicode character.
+ * The unicode character will be decomposed and/or case-folded, if required.
+ * Returns the number of ASCII characters converted.
+ */
+static int asc2ucdf(struct super_block *sb,
+ const char *astr, int len, struct decomposed_uc *duc)
+{
+ int ii;
+ int size = asc2ucd(sb, astr, len, duc);
+ bool fold = !(HFSPLUS_SB(sb).flags & HFSPLUS_SB_HFSX);
+ for (ii = 0; fold && ii <= duc->size; ++ii)
+ duc->str[ii] = case_fold(duc->str[ii]);
+ return size;
+}
+
int hfsplus_asc2uni(struct super_block *sb,
struct hfsplus_unistr *ustr, const char *astr, int len)
{
@@ -336,3 +352,89 @@ int hfsplus_asc2uni(struct super_block *
return -ENAMETOOLONG;
return 0;
}
+
+/*
+ * Hash a string to an integer as appropriate for the HFS+ filesystem.
+ * Composed unicode characters are decomposed and case-folding is performed
+ * if the appropriate bits are (un)set on the superblock.
+ */
+int hfsplus_hash_dentry(struct dentry *dentry, struct qstr *str)
+{
+ int len = str->len;
+ const char *astr = str->name;
+ struct decomposed_uc duc;
+ unsigned hash = init_name_hash();
+
+ while (len > 0) {
+ int ii;
+ int size = asc2ucdf(dentry->d_sb, astr, len, );
+ astr += size;
+ len -= size;
+ for (ii = 0; ii < duc.size; ++ii) {
+ if (duc.str[ii])
+ hash = partial_name_hash(duc.str[ii], hash);
+ }
+ }
+ str->hash = end_name_hash(hash);
+
+ return 0;
+}
+
+/*
+ * Compare strings with HFS+ filename ordering.
+ * Composed unicode characters are decomposed and case-folding is performed
+ * if the appropriate bits are (un)set on the superblock.
+ */
+int
+hfsplus_compare_dentry(struct dentry *dentry, struct qstr *s1, struct qstr *s2)
+{
+ int off1 = 0;
+ int off2 = 0;
Re: 2.6.22-rc5 regression
On Wed, 20 Jun 2007, Carlo Wood wrote: > On Mon, Jun 18, 2007 at 03:57:51PM -0700, Linus Torvalds wrote: > > > I'll redo the bisect with this new git. > > > > Thanks, > > Linus > > Well, I did a new 'git bisect' - and if you ask me - it is still broken. > > It's conclusion was this time: > > hikaru:/usr/src/kernel/git/linux-2.6>git bisect bad > 01da41b86f6e5f9a724e20a63f093d77e37d8056 is first bad commit > > parisc: make command_line[] static Heh. Yeah, at this point I think we can pretty much guarantee that your problem is one of two cases: - either a bit random, and depends on some timing thing, and one of the kernels you marked "good" wasn't really. It's not likely that you marked a good kernel bad, of course, since with a good kernel, everything should have always worked, but with a bad kernel and a bug that isn't entirely reproducible, you'd mark it "good" by mistake - because it just randomly didn't show the problem. OR - we actually have two different commits that introduce the problem for you, and it comes and goes, and the bisection doesn't work, because there isn't a clear "this side works, that other side does not" situation. For example, later on you say: > Personally I am convinced that the real problem is with > 985144db8f4cb7e56154b31bdf233d3550bf but if you look at your commit log, you have: > # bad: [25971f68d392f1816e21520e9e59648403b0bdad] [PARISC] fix section > # mismatch in ccio-dma > git-bisect bad 25971f68d392f1816e21520e9e59648403b0bdad Notice? You said that 25971f68d392f1816e21520e9e59648403b0bdad was bad, but that is *before_ the 985144db8f4cb7e56154b31bdf233d3550bf commit. Do a gitk 25971f68d3..985144 to see that part of the history. So maybe you didn't test that kernel properly? And maybe it really is random, and something has happened that just makes it happen more often? Also, some *really* nasty bugs end up being about bad initialization, and it turns out that what happens more is not which kernel you run, but what the *previous* kernel you ran is, because it left some device driver state that the bug doesn't clean up! Anyway, can you try that 25971f68d3 kernel one more time? You marked it bad, but if that kernel is bad, then the commit you are pointing to is *not* the culprit. Linus - 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: xfs freeze/umount problem
On Tue, Jun 19, 2007 at 09:10:08AM +0100, David Greaves wrote:
> David Chinner wrote:
> > FWIW, I'm on record stating that "sync" is not sufficient to quiesce an
> XFS
> > filesystem for a suspend/resume to work safely and have argued that the
> only
> > safe thing to do is freeze the filesystem before suspend and thaw it after
> > resume.
>
> Whilst testing a potential bug in another thread I accidentally found that
> unmounting a filesystem that I'd just frozen would hang.
>
> As the saying goes: "Well, duh!!"
It's the s_umount semaphore that is the problem here - freeze_bdev()
does a get_super() call which does a down_read(>s_umount) and
the corresponding up_read() call does not occur until the filesystem
is thawed.
So yes, your umount will hang until you thaw the fileystem.
As i just tried this, I can't unfreeze the filesystem because it's
been removed from /proc/mounts already and so xfs_freeze -u aborts:
budgie:~ # xfs_freeze -u /dev/sdb8
xfs_freeze: specified file ["/dev/sdb8"] is not on an XFS filesystem
budgie:~ #
> I could eventually run an unfreeze but the mount was still hung. This lead
> to an unclean shutdown.
So I couldn't reproduce the unclean shutdown.
> OK, it may not be bright but it seems like this shouldn't happen; umount
> should either unfreeze and work or fail ("Attempt to umount a frozen
> filesystem.") if the fs is frozen.
IMO, an unmount of a frozen fileystem should simply return EBUSY.
> Is this a kernel bug/misfeature or a (u)mount one?
Kernel bug. umount should know nothing about frozen filesystems...
Maybe something like th patch below needs to be done to prvent
the hang
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
Don't try to unmount a frozen filesystem as the unmount will hang
waiting on the s_umount semaphore held by the freeze and you may not
be able to unfreeze the filesystem to allow the umount to proceed.
Signed-Off-By: Dave Chinner <[EMAIL PROTECTED]>
---
fs/namespace.c |7 +++
1 file changed, 7 insertions(+)
Index: 2.6.x-xfs-new/fs/namespace.c
===
--- 2.6.x-xfs-new.orig/fs/namespace.c 2007-05-29 16:17:59.0 +1000
+++ 2.6.x-xfs-new/fs/namespace.c2007-06-20 09:57:21.310048007 +1000
@@ -545,6 +545,13 @@ static int do_umount(struct vfsmount *mn
int retval;
LIST_HEAD(umount_list);
+ /*
+* don't try to unmount frozen filesystems as we'll
+* hang on the s_umount held by the freeze a bit later.
+*/
+ if (sb->s_frozen != SB_UNFROZEN)
+ return -EBUSY;
+
retval = security_sb_umount(mnt, flags);
if (retval)
return retval;
-
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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Tue, 19 Jun 2007, Alexandre Oliva wrote: Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 On Jun 19, 2007, [EMAIL PROTECTED] wrote: if a company doesn't care about tivoizing then they won't do it, it takes time and money to tivoize some product and it will cause headaches for the company. their reasons for wanting to tivoize a product may be faulty, but they think that the reasons are valid or they wouldn't go to the effort. Absolutely right. And we'll get to that. Please just be patient. In fact, how much the company cares about tivoizing is completely irrelevant to that point. I shouldn't even have included it, but I did because I thought it would be useful as a boundary condition. So just disregard that. Is there agreement that, comparing tivoized and non-tivoized hardware, we get'd more contributions if the hardware is not tivoized, because users can scratch their own itches, than we would for tivoized hardware? if you also make the assumption that the company won't use propriatary software instead then I think you would get agreement. but the disagrement is over this exact assumption. you assume that these companies will use non-tivoized products if you make it hard to use the software covered by the GPL, most other people are saying that they disagree and the result would be fewer companies useing software covered by GPL instead. David Lang - 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: [Intel IOMMU 05/10] Intel IOMMU driver
On Tue, 19 Jun 2007, Keshavamurthy, Anil S wrote: > Memory allocated during driver init is very less and not much benefit > with the suggested changes I think. Please correct me If I am wrong. If its just a small amount of memory then the benefit will not be large. You are likely right. > The biggest benifit will be when we can figure out GPF_ flags > during runtime when DMA map api's are called. Right. - 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: [Intel IOMMU 05/10] Intel IOMMU driver
On Tue, Jun 19, 2007 at 04:32:23PM -0700, Christoph Lameter wrote:
> On Tue, 19 Jun 2007, Keshavamurthy, Anil S wrote:
>
> > +static inline void *alloc_pgtable_page(void)
> > +{
> > + return (void *)get_zeroed_page(GFP_ATOMIC);
> > +}
>
> Need to pass gfp_t parameter. Repeates a couple of times.
>
> > + addr &= (((u64)1) << addr_width) - 1;
> > + parent = domain->pgd;
> > +
> > + spin_lock_irqsave(>mapping_lock, flags);
> > + while (level > 0) {
> > + void *tmp_page;
> > +
> > + offset = address_level_offset(addr, level);
> > + pte = [offset];
> > + if (level == 1)
> > + break;
> > +
> > + if (!dma_pte_present(*pte)) {
> > + tmp_page = alloc_pgtable_page();
>
> Is it not possible here to drop the lock and do the alloc with GFP_KERNEL
> and deal with the resulting race? That is done in other parts of the
> kernel.
>
> > +/* iommu handling */
> > +static int iommu_alloc_root_entry(struct intel_iommu *iommu)
> > +{
> > + struct root_entry *root;
> > + unsigned long flags;
> > +
> > + root = (struct root_entry *)alloc_pgtable_page();
>
> This may be able to become a GFP_KERNEL alloc since interrupts are enabled
> at this point?
Memory allocated during driver init is very less and not much benefit
with the suggested changes I think. Please correct me If I am wrong.
The biggest benifit will be when we can figure out GPF_ flags
during runtime when DMA map api's are called.
-
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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Tuesday 19 June 2007 19:49:24 [EMAIL PROTECTED] wrote: > On Tue, 19 Jun 2007, Alexandre Oliva wrote: > > On Jun 19, 2007, [EMAIL PROTECTED] wrote: > >> remember, not all tivo models are locked down, > > > > Only the earliest that you can't find for sale any more, right? > > > >> as a result of watching the hacker groups I can safely say that the > >> lockdown has not blocked many users. it has slowed modification of the > >> hacks to new types of hardware, but not for very long. > > > > Well, then... What's the point *for* tivoization, again? To slow > > down the contributions? And that's good because...? > > no, the point is that while tivoization is not nessasarily the best thing > it's far better then the company useing propriatary code. > > delayed contributions are better then no contributions. > > David Lang This logic has been proven already. Apple used KHTML and KJS as the backend systems for Safari. While Safari was in development they held onto all their changes and modifications. When they released Safari, they contributed it all back, making both things better. Fact: KHTML and KJS are also the core of Apples "WebKit" and "WebCore" technologies - both KHTML and KJS are Open Source projects, making up a part of KDE. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Tue, 19 Jun 2007, Alexandre Oliva wrote: On Jun 19, 2007, [EMAIL PROTECTED] wrote: On Tue, 19 Jun 2007, Alexandre Oliva wrote: You're losing all that. based on the knowledge shown by these users you aren't loosing much. Remember, the sample is biased, the hackers who'd like to hack it are less likely to buy it, and some might be only making private changes to avoid legal hassles. And then, it doesn't have to be all that much. Since you're talking specifically about TiVo customers, how much has TiVo effectly contributed in terms of code? (It was pointed out before, I know, but it's important to keep this in perspective, lest people lose sight of what's at stake) they contributed all changes they made to GPL code, exactly as required. in addition they have provided the full build environments, not just listing the versions of the compilers, etc. remember, not all tivo models are locked down, Only the earliest that you can't find for sale any more, right? as a result of watching the hacker groups I can safely say that the lockdown has not blocked many users. it has slowed modification of the hacks to new types of hardware, but not for very long. Well, then... What's the point *for* tivoization, again? To slow down the contributions? And that's good because...? no, the point is that while tivoization is not nessasarily the best thing it's far better then the company useing propriatary code. delayed contributions are better then no contributions. David Lang - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 19, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: >> Right to control what software runs on the hardware is no different. >> For any hardware on which I can run the software, I'm a user there, >> and I'm entitled to the rights granted by the license. > Exactly. However, that right does not include the right to run the software > on any particular piece of hardware. I think that's correct, in general. But when I receive the software along with a particular piece of hardware, on which I'm to expected to run it, I'm also receiving all other freedoms that ought to be respected by whoever distributed the software to me, which means the distributor can't impose restrictions on my running modified versions of the program there (or anywhere else I can run the software, for that matter). > It includes the right to run the software on *ANY* hardware, so long > as one is authorized to choose what software runs on that hardware. That's correct, too, with the provision that the distributor cannot impose restrictions on running modified versions of the program. Not on any other hardware I can control, not on the hardware with which I received the software along with the freedoms to control it in as far as running the GPLed software goes. > You keep conflating things like access to the source code and the legal > right to modify that source code with the authorization right to install > that modified kernel on some particular piece of hardware. The GPL was never > about how such authorization decisions are made. That's correct. All it says is that you can't impose further restrictions. This means you can't use anything (source code deprivation, patents, copyright, authorization, nothing) to disrespect users' freedoms. Is this so hard to accept? There's nothing special about these authorization rights you're talking about that distinguish them from copyrights or patent rights or any other rights. The GPL says: don't use them against users' freedoms regarding the GPLed software. No excuses. > If I make you a user of my laptop, do I have to let you install a modified > kernel? Does interacting with your laptop over the network make me a user of your kernel? > What if I even let you access the kernel source, so I have > distributed it to you. You have distributed the source to me, I can modify it. But did you distribute the kernel binary installed on your computer to me? That's the one I'm (possibly) using per the above. Whether you also gave me sources is irrelevant, unless you gave them to me as part of your obligation of distributing the corresponding sources, in case we conclude you distributed the kernel binary installed on your computer to me when you granted me remote access to it. And then, GPLv3 makes it clear that, in the case of remote access, you're not conveying the binary to me, therefore the conditions for conveying do not apply. > The GPL was never, ever about such authorization decisions. They are > completely alien to both the wording and the spirit of the GPL. You can repeat that as much as you want, this won't change the fact that the GPL has never permitted you to use whatever rights you have to impose restrictions on users' freedoms as to GPLed software once you've (implicitly) accepted the conditions of the license. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.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: Fix signalfd interaction with thread-private signals
On Tue, 19 Jun 2007, Oleg Nesterov wrote:
> The commited "Fix signalfd interaction with thread-private signals"
> (commit caec4e8dc85e0644ec24aeb36285e1ba02da58cc) doesn't implement
> this.
>
> We can do something like
>
> int signalfd_dequeue_signal(struct task_struct *tsk, sigset_t *mask,
> siginfo_t *info)
> {
> if (tsk->tgid == current->tgid)
> tsk = current;
>
> return dequeue_signal(tsk, mask, info);
> }
>
> (still I can't understand why should we change signalfd).
Actually, I think signalfd is fine as is, with Ben's patch applied.
Signalfd should only fetch shared signals, not specific ones (in any
case).
- 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: 2.6.22-rc5 regression
On Wed, Jun 20, 2007 at 01:37:16AM +0200, Carlo Wood wrote: > Personally I am convinced that the real problem is with > 985144db8f4cb7e56154b31bdf233d3550bf > > [AGPGART] intel_agp: fix device probe > > This patch trys to fix device probe in two cases. First we should > correctly detect device if integrated graphics device is not enabled > or exists, like an add-in card is plugged. Second on some type of intel > GMCH, it might have multiple graphic chip models, like 945GME case, so > we should be sure the detect works through the whole table. > > Signed-off-by: Wang Zhenyu <[EMAIL PROTECTED]> > Signed-off-by: Dave Jones <[EMAIL PROTECTED]> > > > The result of this patch is that the kernel starts to print > "agpgart: Detected an Intel 965G Chipset." again with the usual > disastrous results. Now, that doesn't mean that this patch is > wrong - but it explains why the problem returns after this patch. Right, without this patch, probing was broken, so we never matched an agp driver to the chipset. The question remains though, why the initialisation of the chip is so broken. Dave -- http://www.codemonkey.org.uk - 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/
Problem with global_flush_tlb() on i386 in 2.6.22-rc4-mm2
Hi, Trying to test my "Text Edit Lock" patches, I ran into a problem related to global_flush_tlb() not doing its job at updating the page flags when, it seems, the page has been recently accessed. Therefore, it can only be reproduced by doing a couple of iterations. I run on a Pentium 4 with the following characteristics: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz stepping: 1 cpu MHz : 3000.201 cache size : 1024 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pebs bts sync_rdtsc pni monitor ds_cpl cid xtpr bogomips: 6007.49 clflush size: 64 config : CONFIG_X86_INVLPG=y (complete .config at the end) CONFIG_PARAVIRT=y/n (notice that pge and clflush features are present) The kernel is configured in UP (I first saw the problem in SMT, but switched to UP and it is still there). I provide a really crude hackish test module that shows the problematic behavior below. Whenever I run the module using global_flush_tlb(), I get the following OOPS: [ 1112.512389] Init Attr RX [ 1112.521691] Init Attr RX end [ 1113.702965] Loop 0 [ 1113.709171] Attr RWX 621545 [ 1113.717662] Attr RX 621545 [ 1113.725869] Attr RWX 432917 [ 1113.734295] Attr RX 432917 [ 1113.742460] Attr RWX 973425 [ 1113.750885] Attr RX 973425 [ 1113.759048] Attr RWX 453890 [ 1113.767490] Attr RX 453890 [ 1113.775653] Attr RWX 1035918 [ 1113.784341] Attr RX 1035918 [ 1113.792764] Attr RWX 1038276 [ 1113.801449] Attr RX 1038276 [ 1113.809902] Attr RWX 71394 [ 1113.818067] Attr RX 71394 [ 1113.825970] Attr RWX 88253 [ 1113.834134] Attr RX 88253 [ 1113.842039] Attr RWX 108029 [ 1113.850505] Attr RX 108029 [ 1113.858670] Attr RWX 767772 [ 1113.867095] Attr RX 767772 [ 1113.875259] Attr RWX 251394 [ 1113.883694] Attr RX 251394 [ 1113.891859] Attr RWX 817582 [ 1113.900376] Attr RX 817582 [ 1113.908540] Attr RWX 577819 [ 1113.916965] Attr RX 577819 [ 1113.925127] Attr RWX 56979 [ 1113.933293] Attr RX 56979 [ 1113.941195] Attr RWX 72953 [ 1113.949361] Attr RX 72953 [ 1113.957265] Attr RWX 94222 [ 1113.965445] BUG: unable to handle kernel paging request at virtual address c3a1700e [ 1113.988291] printing eip: [ 1113.996340] f885e0a6 [ 1114.002835] *pde = 038c6163 [ 1114.011145] *pte = 03a17163 [ 1114.019455] Oops: 0003 [#1] [ 1114.027766] PREEMPT [ 1114.034268] LTT NESTING LEVEL : 0 [ 1114.044402] Modules linked in: test_rodata ltt_statedump ltt_control sky2 skge rtc snd_hda_intel [ 1114.070679] CPU:0 [ 1114.070680] EIP:0060:[]Not tainted VLI [ 1114.070681] EFLAGS: 00010282 (2.6.22-rc4-mm2-testssmp #129) [ 1114.110395] EIP is at my_open+0xa6/0x124 [test_rodata] [ 1114.125711] eax: c3a0 ebx: 0001700e ecx: c39e4000 edx: [ 1114.145953] esi: 36f1700e edi: f885e000 ebp: c39e5ebc esp: c39e5ea0 [ 1114.166195] ds: 007b es: 007b fs: gs: 0033 ss: 0068 [ 1114.183583] Process cat (pid: 4112, ti=c39e4000 task=c38ac1b0 task.ti=c39e4000) [ 1114.204862] Stack: f885e223 0001700e f000 c31d3480 f885e000 c39e5ed8 [ 1114.229843]c01a3c2a c39d2540 c368d4a8 c39d2540 c368d4a8 c39e5ef8 c016f5d9 [ 1114.254830]c1c0eec0 c378ccfc c39e5eec c39d2540 8000 c39e5f1c c39e5f0c c016f76b [ 1114.279814] Call Trace: [ 1114.287620] [] proc_reg_open+0x42/0x68 [ 1114.301655] [] __dentry_open+0xe6/0x1e2 [ 1114.315944] [] nameidata_to_filp+0x35/0x3f [ 1114.331008] [] do_filp_open+0x3b/0x43 [ 1114.344777] [] do_sys_open+0x43/0x116 [ 1114.358545] [] sys_open+0x1c/0x1e [ 1114.371274] [] syscall_call+0x7/0xb [ 1114.384524] [] 0xe410 [ 1114.395178] === [ 1114.405823] INFO: lockdep is turned off. [ 1114.417504] Code: 60 df 7c c0 b9 63 01 00 00 ba 01 00 00 00 e8 3f 7d 8b c7 0f ae f0 89 f6 e8 5c 80 8b c7 0f ae f0 89 f6 a1 88 eb 85 f8 0f b6 55 f0 <88> 14 03 0f ae f0 89 f6 89 d8 03 05 88 eb 85 f8 05 00 00 00 40 [ 1114.474329] EIP: [] my_open+0xa6/0x124 [test_rodata] SS:ESP 0068:c39e5ea0 [ 1114.497187] BUG: sleeping function called from invalid context at kernel/rwsem.c:20 [ 1114.520025] in_atomic():0, irqs_disabled():1 [ 1114.532744] INFO: lockdep is turned off. [ 1114.544427] irq event stamp: 1894 [ 1114.554293] hardirqs last enabled at (1893): [] _spin_unlock_irq+0x22/0x4e [ 1114.577666] hardirqs last disabled at (1894): [] _spin_lock_irqsave+0x25/0x61 [ 1114.601556] softirqs last enabled at (1886): [] __do_softirq+0xe1/0x184 [ 1114.624149] softirqs last disabled at (1875): [] do_softirq+0x72/0x77 [ 1114.645969] [] dump_trace+0x1d5/0x204 [ 1114.659737] [] show_trace_log_lvl+0x1a/0x30 [ 1114.675060] [] show_trace+0x12/0x14 [ 1114.688308] []
Re: 2.6.22-rc5 regression
On Mon, Jun 18, 2007 at 03:57:51PM -0700, Linus Torvalds wrote: > > I'll redo the bisect with this new git. > > Thanks, > Linus Well, I did a new 'git bisect' - and if you ask me - it is still broken. It's conclusion was this time: hikaru:/usr/src/kernel/git/linux-2.6>git bisect bad 01da41b86f6e5f9a724e20a63f093d77e37d8056 is first bad commit commit 01da41b86f6e5f9a724e20a63f093d77e37d8056 Author: Alexey Dobriyan <[EMAIL PROTECTED]> Date: Sat Mar 3 01:13:35 2007 + parisc: make command_line[] static Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]> :04 04 eb42c17f2b8c686380fa540723d09e4b27127236 0a77f9c56f35076ae79f9f12a37769500c8f5ee9 M arch Here is the log: hikaru:/usr/src/kernel/git/linux-2.6>git bisect log git-bisect start # bad: [188e1f81ba31af1b65a2f3611df4c670b092bbac] Linux 2.6.22-rc5 git-bisect bad 188e1f81ba31af1b65a2f3611df4c670b092bbac # good: [99f9f3d49cbc7d944476f6fde53a77ec789ab2aa] Merge branch # 'for-linus' of # git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband git-bisect good 99f9f3d49cbc7d944476f6fde53a77ec789ab2aa # good: [9808901b6c63a1c850b072e624c228901a9eaf10] Blackfin serial # driver: ignore framing and parity errors git-bisect good 9808901b6c63a1c850b072e624c228901a9eaf10 # bad: [aba297927d1d558c7a94548135133bdf9172708a] Merge # master.kernel.org:/pub/scm/linux/kernel/git/kyle/parisc-2.6 git-bisect bad aba297927d1d558c7a94548135133bdf9172708a # good: [0127d6d5d925321650e7b92364420325689a03ef] Merge branch 'master' # of master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6 git-bisect good 0127d6d5d925321650e7b92364420325689a03ef # bad: [25971f68d392f1816e21520e9e59648403b0bdad] [PARISC] fix section # mismatch in ccio-dma git-bisect bad 25971f68d392f1816e21520e9e59648403b0bdad # bad: [7022672e4046fac4699aa5f8ff2a5213b7ec4ff9] [PARISC] spelling # fixes: arch/parisc/ git-bisect bad 7022672e4046fac4699aa5f8ff2a5213b7ec4ff9 # bad: [fd3eef10f5a55acdefbd3f53ca7618a35cb6231f] [PARISC] Wire up # kexec_load syscall git-bisect bad fd3eef10f5a55acdefbd3f53ca7618a35cb6231f # bad: [2c8307f63dd5caaf7ff8ad5118951e559a9ed5c8] parisc: sync compat # getdents git-bisect bad 2c8307f63dd5caaf7ff8ad5118951e559a9ed5c8 # bad: [01da41b86f6e5f9a724e20a63f093d77e37d8056] parisc: make # command_line[] static git-bisect bad 01da41b86f6e5f9a724e20a63f093d77e37d8056 Personally I am convinced that the real problem is with 985144db8f4cb7e56154b31bdf233d3550bf [AGPGART] intel_agp: fix device probe This patch trys to fix device probe in two cases. First we should correctly detect device if integrated graphics device is not enabled or exists, like an add-in card is plugged. Second on some type of intel GMCH, it might have multiple graphic chip models, like 945GME case, so we should be sure the detect works through the whole table. Signed-off-by: Wang Zhenyu <[EMAIL PROTECTED]> Signed-off-by: Dave Jones <[EMAIL PROTECTED]> The result of this patch is that the kernel starts to print "agpgart: Detected an Intel 965G Chipset." again with the usual disastrous results. Now, that doesn't mean that this patch is wrong - but it explains why the problem returns after this patch. -- Carlo Wood <[EMAIL PROTECTED]> - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 19, 2007, [EMAIL PROTECTED] wrote: > if a company doesn't care about tivoizing then they won't do it, it > takes time and money to tivoize some product and it will cause > headaches for the company. > their reasons for wanting to tivoize a product may be faulty, but they > think that the reasons are valid or they wouldn't go to the effort. Absolutely right. And we'll get to that. Please just be patient. In fact, how much the company cares about tivoizing is completely irrelevant to that point. I shouldn't even have included it, but I did because I thought it would be useful as a boundary condition. So just disregard that. Is there agreement that, comparing tivoized and non-tivoized hardware, we get'd more contributions if the hardware is not tivoized, because users can scratch their own itches, than we would for tivoized hardware? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.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: GIT Packages for Debian Etch
Christoph Lameter wrote: On Tue, 19 Jun 2007, Thomas Glanzmann wrote: The other choice that we developers usually make is to run either testing or unstable. "stable" is a synonym for obsolete ;-). I'm just not going to let this go. Stable is synonymous with, well ummm, "stable." That means that I don't have 3000 changes a month, it's secure and the unexpected doesn't happen. It means I can write a lecture explaining how git works. ...do updates... then expect my lecture to still work the next day. It means writing local shell scripts and expecting them to work until the NEXT stable release without changes. It means knowing what things WILL break if and when I do go to the next version. Stable is a CHOICE not a punishment. -- Jeffrey Hundstad PS. Running unstable on my laptop... and running stable on my servers. - 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: Versioning file system
>We don't need a new special character for every >> new feature. We've got one, and it's flexible enough to do what you want, >> as proven by NetApp's extremely successful implementation. I don't know NetApp's implementation, but I assume it is more than just a choice of special character. If you merely start the directory name with a dot, you don't fool anyone but 'ls' and shell wildcard expansion. (And for some enlightened people like me, you don't even fool ls, because we use the --almost-all option to show the dot files by default, having been burned too many times by invisible files). I assume NetApp flags the directory specially so that a POSIX directory read doesn't get it. I've seen that done elsewhere. The same thing, by the way, is possible with Jack's filename:version idea, and I assumed that's what he had in mind. Not that that makes it all OK. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - 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: [Intel IOMMU 05/10] Intel IOMMU driver
On Tue, 19 Jun 2007, Keshavamurthy, Anil S wrote:
> +static inline void *alloc_pgtable_page(void)
> +{
> + return (void *)get_zeroed_page(GFP_ATOMIC);
> +}
Need to pass gfp_t parameter. Repeates a couple of times.
> + addr &= (((u64)1) << addr_width) - 1;
> + parent = domain->pgd;
> +
> + spin_lock_irqsave(>mapping_lock, flags);
> + while (level > 0) {
> + void *tmp_page;
> +
> + offset = address_level_offset(addr, level);
> + pte = [offset];
> + if (level == 1)
> + break;
> +
> + if (!dma_pte_present(*pte)) {
> + tmp_page = alloc_pgtable_page();
Is it not possible here to drop the lock and do the alloc with GFP_KERNEL
and deal with the resulting race? That is done in other parts of the
kernel.
> +/* iommu handling */
> +static int iommu_alloc_root_entry(struct intel_iommu *iommu)
> +{
> + struct root_entry *root;
> + unsigned long flags;
> +
> + root = (struct root_entry *)alloc_pgtable_page();
This may be able to become a GFP_KERNEL alloc since interrupts are enabled
at this point?
> +int __init init_dmars(void)
> +{
> + struct dmar_drhd_unit *drhd;
> + struct dmar_rmrr_unit *rmrr;
> + struct pci_dev *pdev;
> + struct intel_iommu *iommu;
> + int ret, unit = 0;
> +
> + /*
> + * for each drhd
> + *allocate root
> + *initialize and program root entry to not present
> + * endfor
> + */
> + for_each_drhd_unit(drhd) {
> + if (drhd->ignored)
> + continue;
> + iommu = alloc_iommu(drhd);
GFP_KERNEL alloc possible?
> +{
> + int ret = 0;
> +
> + iommu_devinfo_cache = kmem_cache_create("iommu_devinfo",
> + sizeof(struct device_domain_info),
> + 0,
> + SLAB_HWCACHE_ALIGN,
> + NULL,
Replace by
iommu_devinfo_cache = KMEM_CACHE(iommu_devinfo, SLAB_HWCACHE_ALIGN)
> +static inline int iommu_iova_cache_init(void)
> +{
> + int ret = 0;
> +
> + iommu_iova_cache = kmem_cache_create("iommu_iova",
> + sizeof(struct iova),
> + 0,
> + SLAB_HWCACHE_ALIGN,
> + NULL,
> + NULL);
Ditto
-
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: [Intel IOMMU 06/10] Avoid memory allocation failures in dma map api calls
On Tue, 19 Jun 2007, Arjan van de Ven wrote: > > Otherwise you are locked into the use of GFP_ATOMIC. > > all callers pretty much are either in irq context or with spinlocks held. Good > luck. it's also called primarily from the PCI DMA API which doesn't take a > gfp_t argument in the first place... > > so I'm not seeing the point. Hmmm... From my superficial look at things it seems that one could avoid GFP_ATOMIC at times. I do not know too much about the driver though but it seems a bit restrictive to always do GFP_ATOMIC allocs. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 19, 2007, [EMAIL PROTECTED] wrote: > On Tue, 19 Jun 2007, Alexandre Oliva wrote: >> You're losing all that. > based on the knowledge shown by these users you aren't loosing much. Remember, the sample is biased, the hackers who'd like to hack it are less likely to buy it, and some might be only making private changes to avoid legal hassles. And then, it doesn't have to be all that much. Since you're talking specifically about TiVo customers, how much has TiVo effectly contributed in terms of code? (It was pointed out before, I know, but it's important to keep this in perspective, lest people lose sight of what's at stake) > remember, not all tivo models are locked down, Only the earliest that you can't find for sale any more, right? > as a result of watching the hacker groups I can safely say that the > lockdown has not blocked many users. it has slowed modification of the > hacks to new types of hardware, but not for very long. Well, then... What's the point *for* tivoization, again? To slow down the contributions? And that's good because...? > in the case of Tivo, there are many public boards that talk about > hacking tivos, and tivo employees login and contribute to them. Nice! Thanks for the info, this was very enlightening. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.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: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Saturday 16 June 2007 10:38:56 am Andrey Borzenkov wrote:
> it appears that quirk is not even applied because PnP tells us device is not
> active:
>
> [ 571.118483] pnp: PnP ACPI init
> [ 571.118611] ACPI: bus type pnp registered
> [ 571.158828] quirk_smc_enable: active = 0
> [ 571.182090] pnp: PnP ACPI: found 12 devices
Yup. That could probably be improved.
_CRS definitely reports SIR and FIR backwards from most platforms.
I can make the device talk by configuring it "by hand," e.g.,
# cd /sys/bus/pnp/devices/00:0a
# echo "set io 0x2e8-0x2ef io 0x100-0x107 irq 5 dma 1" > resources
# echo activate > resources
# ~/smsc
smsc_dump: 0x24 0xfe UART1 config
smsc_dump: 0x25 0xba SIR base (0x2e8)
smsc_dump: 0x28 0x45 UART IRQ
smsc_dump: 0x2b 0x20 FIR base (0x100)
smsc_dump: 0x2c 0x01 FIR DMA
smsc_dump: 0x0c 0x0e IRDA mode
smsc_dump: 0x07 0x50 powerdown mode
smsc_dump: 0x0a 0x40 toshiba mystery
# ~/inb 0x100 8 0x100
selecting bank 3 (fir at 0x100)
0x0100: 0x10 0xb8 0xf2 0x00 0x51 0x00 0x00 0x03
("smsc" and "inb" are little test programs (attached). "smsc" dumps
the SIO configuration, and "inb" dumps I/O ports. In this case,
I'm looking at the FIR ports, and the values there are what smsc-ircc2
expects.)
Seems like it should be simple to do the same thing automatically
in the driver or a quirk, but I haven't been able to get that to work.
I'll be out of the office most of the time from now until July 5, but
I'll get back to this when I return.
Bjorn
P.S. "reboot" doesn't seem to work on my box. I tried "reboot=b",
"reboot=c", "reboot=h", and none of them seems to work. Does it work
on yours?
/*
* Dump SMSC/LPC47N227 config, typically IRDA config
*/
#include
#include
#include
/**
Keys. They should work with every SMsC SIO
**/
#define SMSCSIO_CFGACCESSKEY 0x55
#define SMSCSIO_CFGEXITKEY 0xaa
/*
* Generic SIO Flat (!?) *
*/
/* Register 0x0d */
#define SMSCSIOFLAT_DEVICEID_REG0x0d
/* Register 0x0c */
#define SMSCSIOFLAT_UARTMODE0C_REG0x0c
#define SMSCSIOFLAT_UART2MODE_MASK 0x38
#define SMSCSIOFLAT_UART2MODE_VAL_COM 0x00
#define SMSCSIOFLAT_UART2MODE_VAL_IRDA 0x08
#define SMSCSIOFLAT_UART2MODE_VAL_ASKIR 0x10
/* Register 0x25 */
#define SMSCSIOFLAT_UART2BASEADDR_REG 0x25
/* Register 0x2b */
#define SMSCSIOFLAT_FIRBASEADDR_REG0x2b
/* Register 0x2c */
#define SMSCSIOFLAT_FIRDMASELECT_REG 0x2c
#define SMSCSIOFLAT_FIRDMASELECT_MASK 0x0f
/* Register 0x28 */
#define SMSCSIOFLAT_UARTIRQSELECT_REG 0x28
#define SMSCSIOFLAT_UART2IRQSELECT_MASK 0x0f
#define SMSCSIOFLAT_UART1IRQSELECT_MASK 0xf0
#define SMSCSIOFLAT_UARTIRQSELECT_VAL_NONE 0x00
/*
* LPC47N227 *
*/
#define LPC47N227_CFGACCESSKEY 0x55
#define LPC47N227_CFGEXITKEY 0xaa
/* Register 0x00 */
#define LPC47N227_FDCPOWERVALIDCONF_REG 0x00
#define LPC47N227_FDCPOWER_MASK 0x08
#define LPC47N227_VALID_MASK0x80
/* Register 0x02 */
#define LPC47N227_UART12POWER_REG0x02
#define LPC47N227_UART1POWERDOWN_MASK 0x08
#define LPC47N227_UART2POWERDOWN_MASK 0x80
/* Register 0x07 */
#define LPC47N227_APMBOOTDRIVE_REG0x07
#define LPC47N227_PARPORT2AUTOPWRDOWN_MASK 0x10 /* auto power down on if set */
#define LPC47N227_UART2AUTOPWRDOWN_MASK 0x20 /* auto power down on if set */
#define LPC47N227_UART1AUTOPWRDOWN_MASK 0x40 /* auto power down on if set */
/* Register 0x0c */
#define LPC47N227_UARTMODE0C_REG0x0c
#define LPC47N227_UART2MODE_MASK 0x38
#define LPC47N227_UART2MODE_VAL_COM 0x00
#define LPC47N227_UART2MODE_VAL_IRDA 0x08
#define LPC47N227_UART2MODE_VAL_ASKIR 0x10
/* Register 0x0d */
#define LPC47N227_DEVICEID_REG 0x0d
#define LPC47N227_DEVICEID_DEFVAL 0x5a
/* Register 0x0e */
#define LPC47N227_REVISIONID_REG0x0e
/* Register 0x25 */
#define LPC47N227_UART2BASEADDR_REG 0x25
/* Register 0x28 */
#define LPC47N227_UARTIRQSELECT_REG 0x28
#define LPC47N227_UART2IRQSELECT_MASK 0x0f
#define LPC47N227_UART1IRQSELECT_MASK 0xf0
#define LPC47N227_UARTIRQSELECT_VAL_NONE 0x00
/* Register 0x2b */
#define LPC47N227_FIRBASEADDR_REG0x2b
/* Register 0x2c */
#define LPC47N227_FIRDMASELECT_REG0x2c
#define LPC47N227_FIRDMASELECT_MASK 0x0f
#define LPC47N227_FIRDMASELECT_VAL_DMA1 0x01 /* 47n227 has three dma channels */
#define LPC47N227_FIRDMASELECT_VAL_DMA2 0x02
#define LPC47N227_FIRDMASELECT_VAL_DMA3 0x03
#define LPC47N227_FIRDMASELECT_VAL_NONE 0x0f
static inline unsigned int smsc_read(unsigned int port, unsigned int reg)
{
outb(reg, port);
return inb(port + 1);
}
static inline void smsc_write(unsigned int port, unsigned int reg, unsigned int
val)
{
outb(reg, port);
outb(val, port + 1);
}
static void smsc_dump(unsigned int iobase)
{
unsigned char val;
outb(LPC47N227_CFGACCESSKEY, iobase); // enter configuration state
Re: [Intel IOMMU 06/10] Avoid memory allocation failures in dma map api calls
Christoph Lameter wrote: On Tue, 19 Jun 2007, Keshavamurthy, Anil S wrote: So far in our test scenario, we were unable to create any memory allocation failure inside dma map api calls. All these functions should have gfp_t flags passed to them. why? Otherwise you are locked into the use of GFP_ATOMIC. all callers pretty much are either in irq context or with spinlocks held. Good luck. it's also called primarily from the PCI DMA API which doesn't take a gfp_t argument in the first place... so I'm not seeing the point. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Tuesday 19 June 2007 13:06:17 Alexandre Oliva wrote: > On Jun 19, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > On Tuesday 19 June 2007 04:04:52 Alexandre Oliva wrote: > >> On Jun 19, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > >> > On Tuesday 19 June 2007 02:44:32 Alexandre Oliva wrote: > >> >> GPLv3 forbids tivoization, therefore developer has requirement for > >> >> tivoization in the license, therefore GPLv3 forbidding tivoization > >> >> is bad. > >> > > >> > However, my argument is straight logic, nothing "circular" about it. > >> > :) Replacing "X" in my logic path above with "tivoization" and > >> > "license" with "GPLv3", as you've done, does produce a valid chain of > >> > logic. > >> > >> Yes. Isn't it funny though that tivoization became necessary as a > >> consequence of GPLv3 forbidding it? > > > > -ELOGIC > > I see. Try 'modprobe logic', it worked for me years ago ;-) :-D Try using real logic rather than the logic of your religion. > > It didn't become necessary as a result of the GPLv3 forbidding it. > > Which is why I said it was funny, because your inference chain stated > *exactly* (with an implied "for the developers") that it did. > > Do you understand what an inference chain is? A => B, as in A implies > B, which can also be read as A therefore B if A is known to hold. Okay, since you want it in a specific language rather than as a set of bullet points (which is what I used the => for) Company X has requirement for restriction Y => License on product Z disallows restriction Y => Product Z loses Company X and the exposure use in their product gives => License on product Z is bad for the product Understandable now? > > there could be any number of reasons why "tivoization" is needed by > > the manufacturer. > > This claim is false. > > Tivoization is when hardware manufacturer takes copyleft software and > blocks updates by the user of the hardware. By that definition you are correct. > No single law so far has shown an example that even resembled to > mandate copyleft software, and no contract could possibly establish a > condition like this. No argument here. What I was stating is that are legal (and other reasons) why a company might have to lock down their software in a process similar to "Tivoization". > Therefore, this claim is false. Only when you define a term as specifically as you have done for "Tivoization". I should, perhaps, have used a different term - it would then have been patently true. Though, at that point, you would likely have argued that it wasn't "tivoization" > > This whole bit was to point out that you were inferring circular > > logic where none existed. > > There *is* circular logic is in place. > > The initial premise of this fallacy is that anti-tivoization is bad > for the project. > > This is used to conclude that licenses with such provisions should be > rejected. > > This is then used to conclude that there are fewer developers who > would develop under such licenses. > > Which is then used to conclude that anti-tivozation is bad for the > project. Your view of the logic is, in this case, flawed. It's more along the lines of what I've detailed above. Now, please, go away. You aren't doing your "religion" any good. In fact, you are damaging it - repeatedly. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: [Intel IOMMU 06/10] Avoid memory allocation failures in dma map api calls
On Tue, 19 Jun 2007, Keshavamurthy, Anil S wrote: > So far in our test scenario, we were unable to create > any memory allocation failure inside dma map api calls. All these functions should have gfp_t flags passed to them. Otherwise you are locked into the use of GFP_ATOMIC. If this is a parameter then you may be able to use GFP_KERNEL in various places and you may develop the code to have less GFP_ATOMIC allocs in the future. - 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: Fix signalfd interaction with thread-private signals
On Tue, 2007-06-19 at 18:06 +0400, Oleg Nesterov wrote: > On 06/19, Benjamin Herrenschmidt wrote: > > > > On Tue, 2007-06-19 at 13:14 +0400, Oleg Nesterov wrote: > > > > > The commited "Fix signalfd interaction with thread-private signals" > > > (commit caec4e8dc85e0644ec24aeb36285e1ba02da58cc) doesn't implement > > > this. > > > > Indeed, if you want what Davide described, you need to also change > > signalfd side. The patch I did merely prevents another thread from > > dequeuing somebody else private signals. > > Yes I see, but why do we need this change? Yes, we can dequeue SIGSEGV > from another thread. Just don't do it if you have a handler for SIGSEGV? Well, for such synchronous signals, it's a fairly stupid idea, especially since you can't predict who will get it. Signals such as SEGV are forced-in, which means they are force-unblocked. Thus, you can't know for sure whome of signalfd or the target thread will get it first, depending on who catches the siglock first I suppose. In one case, you'll manage to steal it, in the other, you'll thread will be killed. 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: [PATCH, RFD]: Unbreak no-mmu mmap
On Fri 8 Jun 2007 09:53, Bernd Schmidt pondered: > Here's a patch to move nommu mmap/munmap ever so slightly closer to mmu > behaviour. The motivation for this is to be able to deselect uClibc's > UCLIBC_UCLINUX_BROKEN_MUNMAP config option, which speeds up malloc a > fair bit. I'm interested in comments whether this is a good direction > to go. The patch is against Linus' tree as of a few minutes ago. I'm assuming that since no one had any large objections, that this is OK, and we should send to Andrew to live in -mm for awhile? -Robin - 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: Fix signalfd interaction with thread-private signals
On Wed, 20 Jun 2007, Oleg Nesterov wrote: > Well, I think the kernel doesn't make any assumptions on that. It can't > guarantee the signal will be actually dequeued, to begin with. > > (That said, I probably missed something, in that case I'd like to be > educated. This is the real reason why I am making the noise :) What happens if a task gets a page fault that results in a SIGSEGV, and another task steals the SIGSEGV using a signalfd, before the faulted task has the chance to get into do_notify_resume() and notice it? ;) - 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: [patch 26/26] SLUB: Place kmem_cache_cpu structures in a NUMA aware way.
Some fixups to this patch:
Fix issues with per cpu kmem_cache_cpu arrays.
1. During cpu bootstrap we also need to bootstrap the per cpu array
for the cpu in SLUB.
kmem_cache_init is called while only a single cpu is marked online.
2. The size determination of the kmem_cache array is wrong for UP.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/slub.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
Index: linux-2.6.22-rc4-mm2/mm/slub.c
===
--- linux-2.6.22-rc4-mm2.orig/mm/slub.c 2007-06-19 15:38:22.0 -0700
+++ linux-2.6.22-rc4-mm2/mm/slub.c 2007-06-19 16:13:17.0 -0700
@@ -2016,21 +2016,28 @@ static int alloc_kmem_cache_cpus(struct
return 1;
}
+/*
+ * Initialize the per cpu array.
+ */
+static void init_alloc_cpu_cpu(int cpu)
+{
+ int i;
+
+ for (i = NR_KMEM_CACHE_CPU - 1; i >= 0; i--)
+ free_kmem_cache_cpu(_cpu(kmem_cache_cpu, cpu)[i], cpu);
+}
+
static void __init init_alloc_cpu(void)
{
int cpu;
- int i;
- for_each_online_cpu(cpu) {
- for (i = NR_KMEM_CACHE_CPU - 1; i >= 0; i--)
- free_kmem_cache_cpu(_cpu(kmem_cache_cpu, cpu)[i],
- cpu);
- }
+ for_each_online_cpu(cpu)
+ init_alloc_cpu_cpu(cpu);
}
#else
static inline void free_kmem_cache_cpus(struct kmem_cache *s) {}
-static inline void init_alloc_cpu(struct kmem_cache *s) {}
+static inline void init_alloc_cpu(void) {}
static inline int alloc_kmem_cache_cpus(struct kmem_cache *s, gfp_t flags)
{
@@ -3094,10 +3101,12 @@ void __init kmem_cache_init(void)
#ifdef CONFIG_SMP
register_cpu_notifier(_notifier);
-#endif
-
kmem_size = offsetof(struct kmem_cache, cpu_slab) +
nr_cpu_ids * sizeof(struct kmem_cache_cpu *);
+#else
+ kmem_size = sizeof(struct kmem_cache);
+#endif
+
printk(KERN_INFO "SLUB: Genslabs=%d, HWalign=%d, Order=%d-%d,"
" MinObjects=%d, CPUs=%d, Nodes=%d\n",
@@ -3244,6 +3253,7 @@ static int __cpuinit slab_cpuup_callback
switch (action) {
case CPU_UP_PREPARE:
case CPU_UP_PREPARE_FROZEN:
+ init_alloc_cpu_cpu(cpu);
down_read(_lock);
list_for_each_entry(s, _caches, list)
s->cpu_slab[cpu] = alloc_kmem_cache_cpu(cpu,
-
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: Versioning file system
Jan Harkes wrote: > > Still, anything that depends on increasing the length of file or path > names to refer to different versions will encounter problems for long > file names and deep paths because there is an upper limit on file and > path name lengths. > Then you have the Solaris variant -- rely on openat() flags to decend into another namespace. -hpa - 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 9/12] sound: fix compile error (wrong declaration of devinitdata)
Fix compile error:
CC sound/pci/ice1712/prodigy192.o
sound/pci/ice1712/prodigy192.c:708: error: ak4114_controls causes a section
type conflict
... but __initdata cannot be "const".
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
sound/pci/ice1712/prodigy192.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/pci/ice1712/prodigy192.c b/sound/pci/ice1712/prodigy192.c
index f03c02c..4bae730 100644
--- a/sound/pci/ice1712/prodigy192.c
+++ b/sound/pci/ice1712/prodigy192.c
@@ -705,7 +705,7 @@ static int ak4114_input_sw_put(struct snd_kcontrol
*kcontrol,
}
-static const struct snd_kcontrol_new ak4114_controls[] __devinitdata = {
+static struct snd_kcontrol_new ak4114_controls[] __devinitdata = {
{
.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
.name = "MIODIO IEC958 Capture Input",
--
1.5.0.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/
Re: Versioning file system
On Tue, Jun 19, 2007 at 03:13:33PM -0700, H. Peter Anvin wrote: > [EMAIL PROTECTED] wrote: > > > > the only trouble I ever had with the .snapshot approach is when tar or > > find would decend down into the .snapshot when I didn't really intend > > for it to do so. > > > > Netapp optionally made .snapshot not show up in readdir, which solved > that problem. > > I have a bigger issue with it starting with only one dot, which is > traditionally used for user configuration information. I think > ..snapshot would have been a better choice, and by extension leaving > double-dot filenames as filesystem namespace (I know that contradicts > POSIX, but the only namespace available in POSIX is /../ which is a > global namespace.) Still, anything that depends on increasing the length of file or path names to refer to different versions will encounter problems for long file names and deep paths because there is an upper limit on file and path name lengths. It may be possible to use namespaces where an application can change the view it (and it's children) will have on the storage by switching to a different namespace and tagging it with for instance a specific version or date we're interested in. Not sure if we actually pass namespace information down to the file systems yet though, last time I checked they were only visible for the VFS. Jan - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Nicolas Mailhot wrote: > > Tivo didn't make the Linux success. More Tivos can definitely undo it. > I don't think so. First, it's not Linux that made success, but rather GNU that uses Linux as its kernel. And, believe it or not, when people say Linux, they really mean GNU. People could care less what kernel they were running, as long as the system is up and runs the procs that offer their services. It was probably a strategic mistake for GNU to lock into Linux, instead of developing a system that would allow GNU to plug-and-play the Kernel. A mistake that could easily be rectified, given enough desire. Second, GPLv2 was/is probably instrumental to the success of GNU/Linux. That's because GPLv2 seems to be fair, which allows the largest possible community to form. Changing this fairness, driven by paranoia arguments, to hamper commercial entities to enter this community may possibly reduce the growth of this community. Interestingly, it's this same paranoia that drives kernel developer to renounce a "Stable Kernel API" for fear of exploitation by certain commercial entities. Which makes you kind of wonder, why they wouldn't move to GPLv3. Or does paranoia and paradox go hand in hand? 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/
[PATCH 10/12] SLOB: fix build error if SLOB && !NUMA
Fix build error: LD .tmp_vmlinux1 arch/x86_64/kernel/built-in.o: In function `__cpu_up': : undefined reference to `kmalloc_node' kernel/built-in.o: In function `build_sched_domains': sched.c:(.text+0x41e7): undefined reference to `kmalloc_node' sched.c:(.text+0x42b5): undefined reference to `kmalloc_node' kernel/built-in.o: In function `timer_cpu_notify': timer.c:(.init.text+0x1163): undefined reference to `kmalloc_node' mm/built-in.o: In function `mempool_create_node': : undefined reference to `kmalloc_node' mm/built-in.o:: more undefined references to `kmalloc_node' follow ... hmm, SLOB currently does not provide kmalloc_node() and friends. Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> --- init/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index a9e99f8..d4a68f6 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -576,7 +576,7 @@ config SLUB and has enhanced diagnostics. config SLOB - depends on EMBEDDED && !SPARSEMEM + depends on EMBEDDED && !SPARSEMEM && !NUMA bool "SLOB (Simple Allocator)" help SLOB replaces the SLAB allocator with a drastically simpler -- 1.5.0.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 6/12] acpi: fix compile warnings
Fix compile warnings:
drivers/acpi/bus.c: In function 'acpi_bus_get_power':
drivers/acpi/bus.c:162: warning: implicit declaration of function
'acpi_power_get_inferred_state'
drivers/acpi/bus.c: In function 'acpi_bus_set_power':
drivers/acpi/bus.c:232: warning: implicit declaration of function
'acpi_power_transition'
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index b4a9ea5..e01dca1 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -43,6 +43,8 @@ ACPI_MODULE_NAME("bus");
#ifdef CONFIG_X86
extern void __init acpi_pic_sci_set_trigger(unsigned int irq, u16 trigger);
#endif
+extern int acpi_power_get_inferred_state(struct acpi_device *);
+extern int acpi_power_transition(struct acpi_device *, int);
struct acpi_device *acpi_root;
struct proc_dir_entry *acpi_root_dir;
-
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 12/12] acpi: select ACPI_EC for SONY_LAPTOP
Fix kernel build problem as SONY_LAPTOP depends on ACPI_EC. Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> --- drivers/misc/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 0d6f369..463fa41 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -119,6 +119,7 @@ config MSI_LAPTOP config SONY_LAPTOP tristate "Sony Laptop Extras" depends on X86 && ACPI + select ACPI_EC select BACKLIGHT_CLASS_DEVICE ---help--- This mini-driver drives the SNC and SPIC devices present in the ACPI -- 1.5.0.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/
