Re: GPL vs non-GPL device drivers
On Wednesday February 14, [EMAIL PROTECTED] wrote: > You don't get it do you. Our source code is meaningless to the Open > Source community at large. It is only useful to our tiny set of > competitors that have nothing to do with Linux. The Embedded space is > very specific. We are only _using_ Linux. Just as we could have used > VxWorks or OSE. Using our source code would not benefit anybody but > our competitors. It would also benefit your *customers*. And you might find that providing such benefits increases the number of your customers. NeilBrown - 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: GPL vs non-GPL device drivers
On 2/15/07, Neil Brown <[EMAIL PROTECTED]> wrote: [..] then it is less clear what people believe Another area where it is less clear what people believe is if you are distributing the module separately to the kernel, but, as I understand it, vj says he is not. But of course the person who's opinion really counts is the judge. The judge's opinion only counts if you actually get to court and manage to put up a legal defense. So you need to get legal advice. Or, ya know, you could take the moral/ethical advice that you're being a worm and stop now. Trent - 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 6/6] automatic tuning applied to some kernel components
Nadia Derbey <[EMAIL PROTECTED]> writes: > But, what do you do with Oracle that's asking maxfiles to be set to 0x1, > while the default value might be enough for a system that's not running > Oracle. > I'm afraid that giving boot time values to the max_* tunables we will loose > all > the benefits from /proc (or /sys): it is impossible to anticipate what an OS > will be used for. So allowing such things to be changed without having to > reboot > the machine is in my mind quite a powerful feature we should keep taking > adavntage of. I'm not saying remove user spaces' ability to set the denial-of-service limits. I'm saying if they need to be frequently changed we need to update the default so they are higher by default. There really is no cost in moving those values up and down it is just an arbitrary integer used in comparisons. But if we can make a good guess that still catches runaway programs before they kill the machine but also allows more programs to work out of the box we are in better shape. Eric - 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: GPL vs non-GPL device drivers
On Wednesday February 14, [EMAIL PROTECTED] wrote: > On 2/14/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: > > We seem to have different definitions of open and closed. > > Open = 3rd party Linux drivers can be loaded. Closed = No third party > Linux drivers can be loaded. Loading a driver is not at issue. Anyone may load a driver. The issue is when you *distribute* a driver. If that driver is a derived work or the Linux kernel, then you may only distribute it under the terms of the GPLv2, which essentially means that you make the source code available - under the GPLv2 - to everyone you give the driver to. How do you know if the driver is a derived work? Well, if it uses POSIX syscalls only, it isn't. (You can write USB drivers in user-space which do this). If it uses symbols exported with EXPORT_SYMBOL_GPL, then the author of the code which provides those symbols thinks that the driver is a derived work. If it uses EXPORT_SYMBOL symbols, then it is less clear what people believe, though there are certainly some who believe it will still be a derived work. But of course the person who's opinion really counts is the judge. So you need to get legal advice. NeilBrown - 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: GPL vs non-GPL device drivers
Ben Nizette wrote: v j wrote: This is in reference to the following thread: http://lkml.org/lkml/2006/12/14/63 I am not sure if this is ever addressed in LKML, but linux is _very_ popular in the embedded space. We (an embedded vendor) chose Linux 3 years back because of its lack of royalty model, robustness and availability of infinite number of open-source tools. [...] However we have a worrying trend here. If at some point it becomes illegal to load our modules into the linux kernel, then it is unacceptable to us. We would have been better off choosing VxWorks or OSE 3 years ago when we made an OS choice. The fact that Linux is becoming more and more closed is very very alarming. Question to the world here: Distros make, as a matter of course, a series of modifications to the Linux Kernel so that their modules or features work. What stops VJ making a patchset which effectively s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g 's the kernel source then distributing that under the GPL? He then supplies his un-GPL'd modules to the world which just happen to only run on the modified kernel. I've read the GPL of course (IANAL though) and I can't see what this violates except the /spirit/ of the license. Don't get me wrong, I'm strongly against anyone doing what I just mentioned, I believe it to be immoral taking someone's GPL'd code and mangling it in such a way. I speak as an embedded developer myself whose company decided that running our code under Linux and distributing our code under the GPL was far preferable to running closed-source software on a closed-source platform. The best bet would be to read up on lots of past discussions related to exactly these kinds of questions, then ask your Lawyer. Rhetorical question: what stops me from taking somebody's copyrighted work, stripping the copyrights or falsely claiming to have a license to redistribute it, then selling it? -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Wed, 2007-02-14 at 21:16 -0800, v j wrote: > This is in reference to the following thread: > > http://lkml.org/lkml/2006/12/14/63 > > I am not sure if this is ever addressed in LKML, but linux is _very_ > popular in the embedded space. We (an embedded vendor) chose Linux 3 > years back because of its lack of royalty model, robustness and > availability of infinite number of open-source tools. I think you have a bit of a misunderstanding... Linux is not royalty free. Just the royalty is not in the form of cash, but in the form of having to give your improvements back to the open source world. (this is paraphrasing the intent of the GPL basically, you can argue for hours if drivers are separate or improvements, and I'm not interested in that debate, it has been debated to death before and only lawyers will in the end be able to settle that on a case by case basis). If your mindset is "how much can I take take take without giving back back back" then personally I think you're sort of acting like a parasite in this context - 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: GPL vs non-GPL device drivers
On Wed, Feb 14, 2007 at 10:46:13PM -0800, v j wrote: > You don't get it do you. Our source code is meaningless to the Open > Source community at large. Linux supports entire _architectures_ of which there are single figures of people using it. What makes your hardware special ? > We are only _using_ Linux. If you're adding kernel modules, you're more than using Linux, you're developing _for_ linux. You're just choosing to keep the fruits of those labors to yourself. > Just as we could have used VxWorks or OSE. You could. But would you have had access to thousands of worldwide contributors making your code better? This is what you've missed out on with your current stance. > Using our source code would not benefit anybody but > our competitors. This excuse has been given time and time again, and repeatedly been proven false. And as soon as one of your competitors makes their drivers open, guess which one gets 1000+ free developers working on their code ? > Sure we could make our drivers open-source. This is a > decision that is made FIRST when evaluating an OS. If we we were > required to make our drivers/HW open, we would just not have chosen > Linux. It is as simple as that. Please, revisit the 1990s. Read the cathedral and the bazaar.[1] Listen to MC Hammer. Realise the funky horror. Then when you're ready to revisit us with some points that haven't already been dismissed please post again. Until then, you're offering nothing new. Dave [1] Jesus, I'm recommending ESR texts, I must be desperate. -- 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/
[patch 3/3] mm: fix PageUptodate memorder
After running SetPageUptodate, preceeding stores to the page contents to
actually bring it uptodate may not be ordered with the store to set the page
uptodate.
Therefore, another CPU which checks PageUptodate is true, then reads the
page contents can get stale data.
Fix this by ensuring SetPageUptodate is always called with the page locked
(except in the case of a new page that cannot be visible to other CPUs), and
requiring PageUptodate be checked only when the page is locked.
To facilitate lockless checks, SetPageUptodate contains an smp_wmb to order
preceeding stores before the store to page flags, and a new PageUptodate_NoLock
is introduced, which issues a smp_rmb after the page flags are loaded for the
test.
DMA memory barrier is not required, because the driver / IO subsystem must
bring that into order before telling the core kernel that the read has
completed.
One thing I like about it is that it unifies the anonymous page handling
with the rest of the page management, by marking anon pages as uptodate
when they _are_ uptodate, rather than when our implementation requires
that they be marked as such. Doing this let me get rid of the smp_wmb's
in the page copying functions which, specially added for anonymous pages
for a closely related issue, didn't quite match file backed page handling.
Convert core code to use PageUptodate_NoLock. Filesystems are unaffected
thanks to the change to read_cache_page.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Acked-by: Martin Schwidefsky <[EMAIL PROTECTED]>
fs/splice.c|4 +--
include/linux/highmem.h|4 ---
include/linux/page-flags.h | 57 +
mm/filemap.c | 20 +++
mm/hugetlb.c |2 +
mm/memory.c|9 +++
mm/page_io.c |2 -
mm/swap_state.c|2 -
8 files changed, 74 insertions(+), 26 deletions(-)
Index: linux-2.6/include/linux/highmem.h
===
--- linux-2.6.orig/include/linux/highmem.h
+++ linux-2.6/include/linux/highmem.h
@@ -57,8 +57,6 @@ static inline void clear_user_highpage(s
void *addr = kmap_atomic(page, KM_USER0);
clear_user_page(addr, vaddr, page);
kunmap_atomic(addr, KM_USER0);
- /* Make sure this page is cleared on other CPU's too before using it */
- smp_wmb();
}
#ifndef __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE
@@ -108,8 +106,6 @@ static inline void copy_user_highpage(st
copy_user_page(vto, vfrom, vaddr, to);
kunmap_atomic(vfrom, KM_USER0);
kunmap_atomic(vto, KM_USER1);
- /* Make sure this page is cleared on other CPU's too before using it */
- smp_wmb();
}
#endif
Index: linux-2.6/include/linux/page-flags.h
===
--- linux-2.6.orig/include/linux/page-flags.h
+++ linux-2.6/include/linux/page-flags.h
@@ -126,16 +126,65 @@
#define ClearPageReferenced(page) clear_bit(PG_referenced, &(page)->flags)
#define TestClearPageReferenced(page) test_and_clear_bit(PG_referenced,
&(page)->flags)
-#define PageUptodate(page) test_bit(PG_uptodate, &(page)->flags)
-#ifdef CONFIG_S390
+static inline int PageUptodate(struct page *page)
+{
+ WARN_ON(!PageLocked(page));
+ return test_bit(PG_uptodate, &(page)->flags);
+}
+
+/*
+ * PageUptodate to be used when not holding the page lock.
+ */
+static inline int PageUptodate_NoLock(struct page *page)
+{
+ int ret = test_bit(PG_uptodate, &(page)->flags);
+
+ /*
+* Must ensure that the data we read out of the page is loaded
+* _after_ we've loaded page->flags and found that it is uptodate.
+* See SetPageUptodate() for the other side of the story.
+*/
+ if (ret)
+ smp_rmb();
+
+ return ret;
+}
+
static inline void SetPageUptodate(struct page *page)
{
+ WARN_ON(!PageLocked(page));
+#ifdef CONFIG_S390
if (!test_and_set_bit(PG_uptodate, &page->flags))
page_test_and_clear_dirty(page);
-}
#else
-#define SetPageUptodate(page) set_bit(PG_uptodate, &(page)->flags)
+ /*
+* Memory barrier must be issued before setting the PG_uptodate bit,
+* so all previous writes that served to bring the page uptodate are
+* visible before PageUptodate becomes true.
+*
+* S390 is guaranteed to have a barrier in the test_and_set operation
+* (see Documentation/atomic_ops.txt).
+*
+* This memory barrier should not need to provide ordering against
+* DMA writes into the page, because the IO completion should really
+* be doing that.
+*/
+ smp_wmb();
+ set_bit(PG_uptodate, &(page)->flags);
#endif
+}
+
+static inline void SetNewPageUptodate(struct page *page)
+{
+ /*
+* S390 sets page dirty bit on IO operations, which is why it is
+*
[PATCH] fix mempolicy's check on a system with memory-less-node take4
please ack if O.K.
-Kame
--
bind_zonelist() can create zero-length zonelist if there is a
memory-less-node. This patch checks the length of zonelist.
If length is 0, returns -EINVAL.
Changelog: v3 -> v4:
- changes a name of a temporal void* variable as "error_code"
Changelog: v2 -> v3
- removed ambiguous void *pointer usage.
- fixed warnings...misuse of PTR_ERR.
Changelog: v1 -> v2
- avoid extra pgdat scanningit is not necessary.
tested on ia64/NUMA with memory-less-node.
Signed-Off-By: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
Index: linux-2.6.20/mm/mempolicy.c
===
--- linux-2.6.20.orig/mm/mempolicy.c2007-02-13 15:14:13.0 +0900
+++ linux-2.6.20/mm/mempolicy.c 2007-02-15 16:11:17.0 +0900
@@ -144,7 +144,7 @@
max++; /* space for zlcache_ptr (see mmzone.h) */
zl = kmalloc(sizeof(struct zone *) * max, GFP_KERNEL);
if (!zl)
- return NULL;
+ return ERR_PTR(-ENOMEM);
zl->zlcache_ptr = NULL;
num = 0;
/* First put in the highest zones from all nodes, then all the next
@@ -162,6 +162,10 @@
break;
k--;
}
+ if (num == 0) {
+ kfree(zl);
+ return ERR_PTR(-EINVAL);
+ }
zl->zones[num] = NULL;
return zl;
}
@@ -193,9 +197,10 @@
break;
case MPOL_BIND:
policy->v.zonelist = bind_zonelist(nodes);
- if (policy->v.zonelist == NULL) {
+ if (IS_ERR(policy->v.zonelist)) {
+ void *error_code = policy->v.zonelist;
kmem_cache_free(policy_cache, policy);
- return ERR_PTR(-ENOMEM);
+ return error_code;
}
break;
}
@@ -1667,7 +1672,7 @@
* then zonelist_policy() will "FALL THROUGH" to MPOL_DEFAULT.
*/
- if (zonelist) {
+ if (!IS_ERR(zonelist)) {
/* Good - got mem - substitute new zonelist */
kfree(pol->v.zonelist);
pol->v.zonelist = zonelist;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 2/3] fs: buffer don't PageUptodate without page locked
__block_write_full_page is calling SetPageUptodate without the page locked.
This is unusual, but not incorrect, as PG_writeback is still set.
However the next patch will require that SetPageUptodate always be called
with the page locked. Simply don't bother setting the page uptodate in this
case (it is unusual that the write path does such a thing anyway). Instead
just leave it to the read side to bring the page uptodate when it notices
that all buffers are uptodate.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
fs/buffer.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
Index: linux-2.6/fs/buffer.c
===
--- linux-2.6.orig/fs/buffer.c
+++ linux-2.6/fs/buffer.c
@@ -1698,17 +1698,8 @@ done:
* clean. Someone wrote them back by hand with
* ll_rw_block/submit_bh. A rare case.
*/
- int uptodate = 1;
- do {
- if (!buffer_uptodate(bh)) {
- uptodate = 0;
- break;
- }
- bh = bh->b_this_page;
- } while (bh != head);
- if (uptodate)
- SetPageUptodate(page);
end_page_writeback(page);
+
/*
* The page and buffer_heads can be released at any time from
* here on.
-
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: GPL vs non-GPL device drivers
On Wednesday February 14, [EMAIL PROTECTED] wrote: > I am well aware of what Greg KHs position is, in fact he is the reason > I started the whole rant. This is only a plea to the "higher > authorities". Linus, please save Linux! Linus is not in any position to do anything. The die is cast. You should speak to a lawyer. The key issue is this: Does combining your work with Linux create a derived work. If it does not, you have nothing to worry about. If it does, then maybe you should worry. If someone who owns copyright in part of the Linux kernel that you are using, decides that they think you have created a derived work, then they might bring this to your attention and ask you to abide by the conditions in the license under which you obtained the Linux kernel. If no suitable resolution can be found, they might take you to court for using their protected work without a valid license (The GPL becomes void if you breach it's requirements). And then the judge might or might not find against you. But it is very hard to know in advance how the judge will decide in a particular case. Hence the best advice is to speak to a lawyer, They have the best chance of advising your how to minimise your risk. I hope that makes the situation clear enough. NeilBrown - 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/3] mm: make read_cache_page synchronous
Ensure pages are uptodate after returning from read_cache_page, which allows
us to cut out most of the filesystem-internal PageUptodate calls.
I didn't have a great look down the call chains, but this appears to fixes 7
possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in ecryptfs,
1 in jffs2, and a possible cleared data overwritten with readpage in block2mtd.
All depending on whether the filler is async and/or can return with a !uptodate
page.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
drivers/mtd/devices/block2mtd.c |3 --
fs/afs/dir.c|3 --
fs/afs/mntpt.c | 11 +++-
fs/cramfs/inode.c |3 +-
fs/ecryptfs/mmap.c | 11
fs/ext2/dir.c |3 --
fs/freevxfs/vxfs_subr.c |3 --
fs/minix/dir.c |1
fs/namei.c | 12 -
fs/nfs/dir.c|5
fs/nfs/symlink.c|6
fs/ntfs/aops.h |3 --
fs/ntfs/attrib.c| 18 +-
fs/ntfs/file.c |3 --
fs/ntfs/super.c | 30 +++-
fs/ocfs2/symlink.c |7 -
fs/partitions/check.c |3 --
fs/reiserfs/xattr.c |4 ---
fs/sysv/dir.c | 10
fs/ufs/dir.c|6
fs/ufs/util.c |6 +---
include/linux/pagemap.h | 11
mm/filemap.c| 49 +++-
mm/swapfile.c |3 --
24 files changed, 70 insertions(+), 144 deletions(-)
Index: linux-2.6/fs/afs/dir.c
===
--- linux-2.6.orig/fs/afs/dir.c
+++ linux-2.6/fs/afs/dir.c
@@ -187,10 +187,7 @@ static struct page *afs_dir_get_page(str
page = read_mapping_page(dir->i_mapping, index, NULL);
if (!IS_ERR(page)) {
- wait_on_page_locked(page);
kmap(page);
- if (!PageUptodate(page))
- goto fail;
if (!PageChecked(page))
afs_dir_check_page(dir, page);
if (PageError(page))
Index: linux-2.6/fs/afs/mntpt.c
===
--- linux-2.6.orig/fs/afs/mntpt.c
+++ linux-2.6/fs/afs/mntpt.c
@@ -77,13 +77,11 @@ int afs_mntpt_check_symlink(struct afs_v
}
ret = -EIO;
- wait_on_page_locked(page);
- buf = kmap(page);
- if (!PageUptodate(page))
- goto out_free;
if (PageError(page))
goto out_free;
+ buf = kmap(page);
+
/* examine the symlink's contents */
size = vnode->status.size;
_debug("symlink to %*.*s", size, (int) size, buf);
@@ -100,8 +98,8 @@ int afs_mntpt_check_symlink(struct afs_v
ret = 0;
- out_free:
kunmap(page);
+ out_free:
page_cache_release(page);
out:
_leave(" = %d", ret);
@@ -184,8 +182,7 @@ static struct vfsmount *afs_mntpt_do_aut
}
ret = -EIO;
- wait_on_page_locked(page);
- if (!PageUptodate(page) || PageError(page))
+ if (PageError(page))
goto error;
buf = kmap(page);
Index: linux-2.6/fs/cramfs/inode.c
===
--- linux-2.6.orig/fs/cramfs/inode.c
+++ linux-2.6/fs/cramfs/inode.c
@@ -180,7 +180,8 @@ static void *cramfs_read(struct super_bl
struct page *page = NULL;
if (blocknr + i < devsize) {
- page = read_mapping_page(mapping, blocknr + i, NULL);
+ page = read_mapping_page_async(mapping, blocknr + i,
+ NULL);
/* synchronous error? */
if (IS_ERR(page))
page = NULL;
Index: linux-2.6/fs/ext2/dir.c
===
--- linux-2.6.orig/fs/ext2/dir.c
+++ linux-2.6/fs/ext2/dir.c
@@ -161,10 +161,7 @@ static struct page * ext2_get_page(struc
struct address_space *mapping = dir->i_mapping;
struct page *page = read_mapping_page(mapping, n, NULL);
if (!IS_ERR(page)) {
- wait_on_page_locked(page);
kmap(page);
- if (!PageUptodate(page))
- goto fail;
if (!PageChecked(page))
ext2_check_page(page);
if (PageError(page))
Index: linux-2.6/fs/freevxfs/vxfs_subr.c
===
--- linux-2.6.orig/fs/freevxfs/vxfs_subr.c
+++ linux-2.6/fs/freevxfs/vxfs_subr.c
@@ -74,10 +74,7 @@ vxfs_get_page(struct address_space *mapp
pp = read_mapping_page(ma
[patch 0/3] 2.6.20 fix for PageUptodate memorder problem (try 4)
Various little cleanups and commenting fixes. Fixed up the patchset so each one, incrementally, should give a properly compiling and running kernel. I'd still like Hugh to ack the anon/swap changes when he can find the time. It would be desirable to get at least one ack as to the overall problem and design of the fix (Martin's ack is just for the s390 changes at this stage). Meanwhile, can it go into -mm for wider testing, if it isn't too much trouble? Thanks, Nick -- SuSE Labs - 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: GPL vs non-GPL device drivers
On 2/14/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: At least one of us is confused about that an embedded User is. It seems to me that you are an embedded developer, not User. I doubt that most Embedded Users care what their OS is, or even know what an OS is. I am not sure what the difference is. We are trying to use Linux to support our application. It may be that Linux has a bug, or our application. When it is Linux, that has the problem, I have tried to inform the community of that. > Not everybody has to be a contributor. The reason Linux is popular is > because of its openness. Take that away and see where it goes. We seem to have different definitions of open and closed. Open = 3rd party Linux drivers can be loaded. Closed = No third party Linux drivers can be loaded. - 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: GPL vs non-GPL device drivers
On Wed, Feb 14, 2007 at 10:27:10PM -0800, v j wrote: > Not everybody has to be a contributor. The reason Linux is popular is > because of its openness. Take that away and see where it goes. please expand on this openness. Especially wrt your add-ons. 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 02/05] Linux Kernel Markers, architecture independant code.
On Sun, 11 Feb 2007 15:03:24 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Linux Kernel Markers, architecture independant code.
>
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
>
> ...
>
> +
> +#ifndef MARK
> +#define MARK GEN_MARK
> +#define MARK_ENABLE_TYPE GEN_MARK_ENABLE_TYPE
> +#define MARK_ENABLE_IMMEDIATE_OFFSET GEN_MARK_ENABLE_IMMEDIATE_OFFSET
> +#endif
Also perhaps this nastiness can go away once each architecture has
asm/marker.h?
> +#ifdef MARK_POLYMORPHIC
What's this? Is it commented somewhere? (It should be...)
> +static int marker_set_ins_enable(void *address, char enable)
> +{
> +#ifdef CONFIG_X86_32
> + return arch_marker_set_ins_enable(address, enable);
> +#else
> + char newi[MARK_ENABLE_IMMEDIATE_OFFSET+1];
> + int size = MARK_ENABLE_IMMEDIATE_OFFSET+sizeof(MARK_ENABLE_TYPE);
> +
> + memcpy(newi, address, size);
> + MARK_ENABLE(&newi[0]) = enable;
> + memcpy(address, newi, size);
> + flush_icache_range((unsigned long)address, size);
> + return 0;
> +#endif //CONFIG_X86_32
> +}
eww. Can we put a suitable arch_marker_set_ins_enable() into each arch's
marker.h?
> +#else
> +static int marker_set_ins_enable(void *address, char enable)
> +{
> + return -EPERM;
> +}
> +#endif //MARK_POLYMORPHIC
> +
>
> ...
>
-
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 07/10] local_t : powerpc extension
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Sun, 11 Feb 2007 14:18:12 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]>
> wrote:
>
> > local_t : powerpc extension
>
> This diff contains changes which are also present in "[PATCH 07/10]
> atomic.h : Add atomic64 cmpxchg, xchg and add_unless to powerpc", resulting
> in rather a mess.
>
> I dropped the duplicated hunks from the later patch rather than this one,
> but I haven't tried to compile the result yet.
>
Yes, sorry about that : the atomic.h diff has been duplicated in both
the local and atomic changes.
The change to system.h for local.h is to add the xchg_local and
cmpxchg_local, while the change for atomic.h is to simply remove the
#include from system.h.
Here is a proper local.h diff, if it happens to become necessary, but
simply removing the duplicated asm-powerpc/system.h hunks will be ok.
Thanks,
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
--- a/include/asm-powerpc/local.h
+++ b/include/asm-powerpc/local.h
@@ -1 +1,342 @@
-#include
+#ifndef _ARCH_POWERPC_LOCAL_H
+#define _ARCH_POWERPC_LOCAL_H
+
+#include
+#include
+
+typedef struct
+{
+ atomic_long_t a;
+} local_t;
+
+#define LOCAL_INIT(i) { ATOMIC_LONG_INIT(i) }
+
+#define local_read(l) atomic_long_read(&(l)->a)
+#define local_set(l,i) atomic_long_set(&(l)->a, (i))
+
+#define local_add(i,l) atomic_long_add((i),(&(l)->a))
+#define local_sub(i,l) atomic_long_sub((i),(&(l)->a))
+#define local_inc(l) atomic_long_inc(&(l)->a)
+#define local_dec(l) atomic_long_dec(&(l)->a)
+
+#ifndef __powerpc64__
+
+static __inline__ int local_add_return(int a, local_t *l)
+{
+ int t;
+
+ __asm__ __volatile__(
+"1:lwarx %0,0,%2 # local_add_return\n\
+ add %0,%1,%0\n"
+ PPC405_ERR77(0,%2)
+" stwcx. %0,0,%2 \n\
+ bne-1b"
+ : "=&r" (t)
+ : "r" (a), "r" (&(l->a.counter))
+ : "cc", "memory");
+
+ return t;
+}
+
+#define local_add_negative(a, l) (local_add_return((a), (l)) < 0)
+
+static __inline__ int local_sub_return(int a, local_t *l)
+{
+ int t;
+
+ __asm__ __volatile__(
+"1:lwarx %0,0,%2 # local_sub_return\n\
+ subf%0,%1,%0\n"
+ PPC405_ERR77(0,%2)
+" stwcx. %0,0,%2 \n\
+ bne-1b"
+ : "=&r" (t)
+ : "r" (a), "r" (&(l->a.counter))
+ : "cc", "memory");
+
+ return t;
+}
+
+static __inline__ int local_inc_return(local_t *l)
+{
+ int t;
+
+ __asm__ __volatile__(
+"1:lwarx %0,0,%1 # local_inc_return\n\
+ addic %0,%0,1\n"
+ PPC405_ERR77(0,%1)
+" stwcx. %0,0,%1 \n\
+ bne-1b"
+ : "=&r" (t)
+ : "r" (&(l->a.counter))
+ : "cc", "memory");
+
+ return t;
+}
+
+/*
+ * local_inc_and_test - increment and test
+ * @l: pointer of type local_t
+ *
+ * Atomically increments @l by 1
+ * and returns true if the result is zero, or false for all
+ * other cases.
+ */
+#define local_inc_and_test(l) (local_inc_return(l) == 0)
+
+static __inline__ int local_dec_return(local_t *l)
+{
+ int t;
+
+ __asm__ __volatile__(
+"1:lwarx %0,0,%1 # local_dec_return\n\
+ addic %0,%0,-1\n"
+ PPC405_ERR77(0,%1)
+" stwcx. %0,0,%1\n\
+ bne-1b"
+ : "=&r" (t)
+ : "r" (&(l->a.counter))
+ : "cc", "memory");
+
+ return t;
+}
+
+#define local_cmpxchg(l, o, n) \
+ (cmpxchg_local(&((l)->a.counter), (o), (n)))
+#define local_xchg(l, n) (xchg_local(&((l)->a.counter), (n)))
+
+/**
+ * local_add_unless - add unless the number is a given value
+ * @l: pointer of type local_t
+ * @a: the amount to add to v...
+ * @u: ...unless v is equal to u.
+ *
+ * Atomically adds @a to @l, so long as it was not @u.
+ * Returns non-zero if @l was not @u, and zero otherwise.
+ */
+static __inline__ int local_add_unless(local_t *l, int a, int u)
+{
+ int t;
+
+ __asm__ __volatile__ (
+"1:lwarx %0,0,%1 # local_add_unless\n\
+ cmpw0,%0,%3 \n\
+ beq-2f \n\
+ add %0,%2,%0 \n"
+ PPC405_ERR77(0,%2)
+" stwcx. %0,0,%1 \n\
+ bne-1b \n"
+" subf%0,%2,%0 \n\
+2:"
+ : "=&r" (t)
+ : "r" (&(l->a.counter)), "r" (a), "r" (u)
+ : "cc", "memory");
+
+ return t != u;
+}
+
+#define local_inc_not_zero(l) local_add_unless((l), 1, 0)
+
+#define local_sub_and_test(a, l) (local_sub_return((a), (l)) == 0)
+#define local_dec_and_test(l) (local_dec_return((l)) == 0)
+
+/*
+ * Atomically test *l and decrement if it is greater than 0.
+ * The function returns the old value of *l minus 1.
+ */
+static __inline__ int local_dec_if_positive(local_t *l)
+{
+ int t;
+
+ __asm__ __volatile__(
+"1:lwarx %0,0,%1 # local_dec_if_positive\n\
+ cmpwi %0,1\n\
+ addi%0,%0,-1\n\
+ blt-2f\n"
+ PPC405_ERR77(0,%1)
+" stwcx. %0,0,%1\n\
+ bne-1b"
+ "\n\
+2:": "=&b" (t)
+
Re: GPL vs non-GPL device drivers
On 2/15/07, v j <[EMAIL PROTECTED]> wrote: I am well aware of what Greg KHs position is, in fact he is the reason I started the whole rant. This is only a plea to the "higher authorities". Linus, please save Linux! Oh boy. Guess what? $ head -3 Documentation/ABI/testing/sysfs-class What: /sys/class/ Date: Febuary 2006 Contact:Greg Kroah-Hartman <[EMAIL PROTECTED]> Yeah, that's right. Trent - 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 05/05] Linux Kernel Markers, non optimized architectures
On Sun, 11 Feb 2007 15:03:27 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > Linux Kernel Markers, non optimized architectures > > This patch also includes marker code for non optimized architectures. I think once we've done this we can nuke CONFIG_MARKERS_ENABLE_OPTIMIZATION? (Please, let it be true). - 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: GPL vs non-GPL device drivers
On Wed, 14 Feb 2007 22:27:10 -0800 v j wrote: > On 2/14/07, Dave Jones <[EMAIL PROTECTED]> wrote: > > On Wed, Feb 14, 2007 at 09:16:28PM -0800, v j wrote: > > > > Welcome to three months ago. > > Here in the future, this was deemed a non-issue. > > However this does highlight another problem. > > End-users who take linux for use in embedded systems (especially) > > tend to live in their own little world rarely contributing anything > > back to upstream, popping up occasionally when months after decisions > > have been made on things. Remind me again why we should care about > > your out of tree binary only modules ? > > You are right. I have not contributed anything to Linux. Except one > small patch to the MTD code. However, I don't think that is the point > here. I am perfectly willing to live with the way Linux is today. I am > telling you as a user that if Linux continues on the current path it > will become less and less attractive to Embedded Users. At least one of us is confused about that an embedded User is. It seems to me that you are an embedded developer, not User. I doubt that most Embedded Users care what their OS is, or even know what an OS is. > Not everybody has to be a contributor. The reason Linux is popular is > because of its openness. Take that away and see where it goes. We seem to have different definitions of open and closed. --- ~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 00/05] Linux Kernel Markers - kernel 2.6.20
On Sun, 11 Feb 2007 15:03:22 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > You will find, in the following posts, the latest revision of the Linux Kernel > Markers. And what can I do with these markers? And once I've done it, are there any userspace applications I can use to get the data out in human-usable form? It seems to me that these patches aren't sequenced correctly - the kernel won't build at each step of the patch sequence. Maybe I'm mistaken in that. We prefer it this way so that people don't hit wont-compile points when doing bisection searches. - 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: GPL vs non-GPL device drivers
I am well aware of what Greg KHs position is, in fact he is the reason I started the whole rant. This is only a plea to the "higher authorities". Linus, please save Linux! vj On 2/14/07, Trent Waddington <[EMAIL PROTECTED]> wrote: On 2/15/07, v j <[EMAIL PROTECTED]> wrote: > If adding closed drivers to Linux is illegal, I am perfectly fine with > that. Just say so. I am not at a dead-end yet, until you make that > statement. Once you make that statement, then all bets are off. I am > betting that most companies will not even consider Linux as an > alternative in the embedded space if this were the case. Greg KH has already made that statement. http://www.kroah.com/log/linux/ols_2006_keynote.html half way down, "Closed source Linux kernel modules are illegal". As was said, welcome to 6 months ago. Trent - 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 6/6] automatic tuning applied to some kernel components
Eric W. Biederman wrote: Nadia Derbey <[EMAIL PROTECTED]> writes: So, should I understand from this that automatic tuning and the AKT framework itself would make sense, given that I find the rigth tunables it should be applied to? Sort of. The concept of things tuning themselves automatically makes a lot of sense. I'm not at all certain about tunables being exported just to be hidden again. Ideally you don't even want the fact that these things are varying visible to the user. So I think that if you can find a good example that cannot be solved better another way, you can build a case for your framework. Currently I am doubt you can find such a case. Actually, dont' know if you had the opportunity to read all the patches, but there are 2 other tunables AKT is proposed to be applied to: . max_threads, the tunable limit on nr_threads . max_files, the tunable limit on nr_files At a quick glance max_threads and max_files appear even more to be DOS limits and not tunables and even less applicable to needing any tuning at all. My gut feel is at worst these values may need a little better boot time defaults but otherwise they the should be good. But, what do you do with Oracle that's asking maxfiles to be set to 0x1, while the default value might be enough for a system that's not running Oracle. I'm afraid that giving boot time values to the max_* tunables we will loose all the benefits from /proc (or /sys): it is impossible to anticipate what an OS will be used for. So allowing such things to be changed without having to reboot the machine is in my mind quite a powerful feature we should keep taking adavntage of. Regards, Nadia - 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: GPL vs non-GPL device drivers
On 2/15/07, v j <[EMAIL PROTECTED]> wrote: If adding closed drivers to Linux is illegal, I am perfectly fine with that. Just say so. I am not at a dead-end yet, until you make that statement. Once you make that statement, then all bets are off. I am betting that most companies will not even consider Linux as an alternative in the embedded space if this were the case. Greg KH has already made that statement. http://www.kroah.com/log/linux/ols_2006_keynote.html half way down, "Closed source Linux kernel modules are illegal". As was said, welcome to 6 months ago. Trent - 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: GPL vs non-GPL device drivers
On 2/15/07, v j <[EMAIL PROTECTED]> wrote: You don't get it do you. I think everyone on the list was thinking the same thing about you. We are only _using_ Linux. Yes, I think we all can see that. Using our source code would not benefit anybody but our competitors. Without knowing what your drivers are, I can't argue about this. Maybe someday, embedded devices will move into the 21st century and I'll be able to get a DVD player, microwave oven or home security system that is user programmable, but I doubt your company will make it. Trent - 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 07/10] local_t : powerpc extension
On Sun, 11 Feb 2007 14:18:12 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > local_t : powerpc extension This diff contains changes which are also present in "[PATCH 07/10] atomic.h : Add atomic64 cmpxchg, xchg and add_unless to powerpc", resulting in rather a mess. I dropped the duplicated hunks from the later patch rather than this one, but I haven't tried to compile the result yet. - 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: GPL vs non-GPL device drivers
On 2/14/07, Neil Brown <[EMAIL PROTECTED]> wrote: > Not everybody has to be a contributor. The reason Linux is popular is > because of its openness. Take that away and see where it goes. So tell us? where does it go? You seem to have the experience already. You took an open linux, added some closed drivers and so made it closed. So you yourself (or your company) have taken that (the openness) away - where did the result go? I'm guessing it went into a dead-end or you wouldn't be here talking to us now. If adding closed drivers to Linux is illegal, I am perfectly fine with that. Just say so. I am not at a dead-end yet, until you make that statement. Once you make that statement, then all bets are off. I am betting that most companies will not even consider Linux as an alternative in the embedded space if this were the case. - 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: GPL vs non-GPL device drivers
On Thursday 15 February 2007, Neil Brown wrote: >On Wednesday February 14, [EMAIL PROTECTED] wrote: >> However we have a worrying trend here. If at some point it becomes >> illegal to load our modules into the linux kernel, then it is >> unacceptable to us. We would have been better off choosing VxWorks or >> OSE 3 years ago when we made an OS choice. The fact that Linux is >> becoming more and more closed is very very alarming. > >Might I suggest that you give very serious consideration to >open-sourcing your drivers? There are benefits and well as costs, and >many have found that the benefits substantially out weigh the costs. > >NeilBrown Speaking as one who has not contributed back to the kernel other than an occasional bug report as I'm getting too old to code alongside these wizards, please let me say: That's an admirable bit of advice Neil, but I have serious doubts it will fall on a fertile mind. From vj's tone here, its obvious that he thinks its fine to leech his income stream from code that is free. And giving one teeny little patch for some utility back seems to make him think he has paid the bill. Methinks he has not paid the bill in kind because its an ongoing rental. Now, if he _were_ to contribute his top secret drivers into the kernel tree, how are we to convince vj that it is in his best interest in the long run to do so? After all, the many eyeballs theory will guarantee that his codebase will not go untouched because bugs he doesn't even know exist will be noticed and fixed, and routine speedups of 2x are entirely possible too. He will in the long run get back faster, more stable code which can't do anything but enhance the value of his hardware, both in how well it runs, but in the public's perception too, simply because it IS in the kernel tree and therefore very well reviewed. And that vj, is an advertising point of no little value. But, I suspect by now he has pulled the batteries out of his hearing aid so he doesn't have to listen to any more of this blasphemous talk. Sad... -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved. - 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: GPL vs non-GPL device drivers
You don't get it do you. Our source code is meaningless to the Open Source community at large. It is only useful to our tiny set of competitors that have nothing to do with Linux. The Embedded space is very specific. We are only _using_ Linux. Just as we could have used VxWorks or OSE. Using our source code would not benefit anybody but our competitors. Sure we could make our drivers open-source. This is a decision that is made FIRST when evaluating an OS. If we we were required to make our drivers/HW open, we would just not have chosen Linux. It is as simple as that. On 2/14/07, Trent Waddington <[EMAIL PROTECTED]> wrote: On 2/15/07, v j <[EMAIL PROTECTED]> wrote: > This has nothing to do with politics. I am not a Linux contributor. Here-in lies the problem. I am one of the few people willing to state openly that I wish those who can, would use their legal claims to stop people like you from writing proprietary drivers. Although you (or your company) clearly has the ability to contribute to Linux, you have chosen not to. Instead, you just leach off those that do. As such, I believe you and your ilk are ethically deplorable and the fact that you would come here to try to point out to the contributors that they are going to lose people like you if they don't stop "threatening" your drivers not only baffles me, it sickens me. At least with NVIDIA and ATI they're not actually profiting from the existence of Linux, but you're actually selling the stuff and you don't even consider the very reasonable proposition of sharing your source code in return. It's not like they're asking for money.. man, this is the Linux project, they don't even ask for copyright assignment or allegiance to an ideology.. Do the right thing, cough up your source code, get it integrated into the tree and let the community do what it does so well. Trent - 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: GPL vs non-GPL device drivers
On Wednesday February 14, [EMAIL PROTECTED] wrote: > You are right. I have not contributed anything to Linux. Except one > small patch to the MTD code. However, I don't think that is the point > here. I am perfectly willing to live with the way Linux is today. I am > telling you as a user that if Linux continues on the current path it > will become less and less attractive to Embedded Users. Every user should be free to choose which OS to use, Embedded users included. You are free to look elsewhere. While having lots of users is good for Linux, it is not a short-term goal. Openness/freedom plus quality are the short-term goals. Lots of users (aka world domination) is the long term goal that we believe will follow. > > Not everybody has to be a contributor. The reason Linux is popular is > because of its openness. Take that away and see where it goes. So tell us? where does it go? You seem to have the experience already. You took an open linux, added some closed drivers and so made it closed. So you yourself (or your company) have taken that (the openness) away - where did the result go? I'm guessing it went into a dead-end or you wouldn't be here talking to us now. NeilBrown - 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 1/1] Fabric7 VIOC driver source code
On Wed, 07 Feb 2007 13:07:40 -0800 Sriram Chidambaram <[EMAIL PROTECTED]> wrote: > This patch provides the Fabric7 VIOC driver source code. > This git mbox patch is built against > git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git > > The patch can be pulled from >ftp://ftp.fabric7.com/VIOC/Fabric7-VIOC-driver-patch.FEB-07-2007 For people wondering what this is, the documentation file is below. I'll pull this driver into my queue so that it doesn't get lost and to give people an opportunity to review it more easily. From a quick peek, I'd expect some changes to be needed: stylistic things, plus some suspicious looking PCI-poking in vioc_irq.c. But I didn't look at it at all closely. The driver needed a bit of help to make it compile on ia64 (I haven't tried any other architectures). If it's simply not possible that this device will ever be present on any non-x86 machines then perhaps we should restrict it to those architectures at kernel configuration time. But then, all the changes I made were good ones.. Overview A Virtual Input-Output Controller (VIOC) is a PCI device that provides 10Gbps of I/O bandwidth that can be shared by up to 16 virtual network interfaces (VNICs). VIOC hardware supports several features such as large frames, checksum offload, gathered send, MSI/MSI-X, bandwidth control, interrupt mitigation, etc. VNICs are provisioned to a host partition via an out-of-band interface from the System Controller -- typically before the partition boots, although they can be dynamically added or removed from a running partition as well. Each provisioned VNIC appears as an Ethernet netdevice to the host OS, and maintains its own transmit ring in DMA memory. VNICs are configured to share up to 4 of total 16 receive rings and 1 of total 16 receive-completion rings in DMA memory. VIOC hardware classifies packets into receive rings based on size, allowing more efficient use of DMA buffer memory. The default, and recommended, configuration uses groups of 'receive sets' (rxsets), each with 3 receive rings, a receive completion ring, and a VIOC Rx interrupt. The driver gives each rxset a NAPI poll handler associated with a phantom (invisible) netdevice, for concurrency. VNICs are assigned to rxsets using a simple modulus. VIOC provides 4 interrupts in INTx mode: 2 for Rx, 1 for Tx, and 1 for out-of-band messages from the System Controller and errors. VIOC also provides 19 MSI-X interrupts: 16 for Rx, 1 for Tx, 1 for out-of-band messages from the System Controller, and 1 for error signalling from the hardware. The VIOC driver makes a determination whether MSI-X functionality is supported and initializes interrupts accordingly. [Note: The Linux kernel disables MSI-X for VIOCs on modules with AMD 8131, even if the device is on the HT link.] Module loadable parameters == - poll_weight (default 8) - the number of received packets will be processed during one call into the NAPI poll handler. - rx_intr_timeout (default 1) - hardware rx interrupt mitigation timer, in units of 5us. - rx_intr_pkt_cnt (default 64) - hardware rx interrupt mitigation counter, in units of packets. - tx_pkts_per_irq (default 64) - hardware tx interrupt mitigation counter, in units of packets. - tx_pkts_per_bell (default 1) - the number of packets to enqueue on a transmit ring before issuing a doorbell to hardware. Performance Tuning == You may want to use the following sysctl settings to improve performance. [NOTE: To be re-checked] # set in /etc/sysctl.conf net.ipv4.tcp_timestamps = 0 net.ipv4.tcp_sack = 0 net.ipv4.tcp_rmem = 1000 1000 1000 net.ipv4.tcp_wmem = 1000 1000 1000 net.ipv4.tcp_mem = 1000 1000 1000 net.core.rmem_max = 5242879 net.core.wmem_max = 5242879 net.core.rmem_default = 5242879 net.core.wmem_default = 5242879 net.core.optmem_max = 5242879 net.core.netdev_max_backlog = 10 Out-of-band Communications with System Controller = System operators can use the out-of-band facility to allow for remote shutdown or reboot of the host partition. Upon receiving such a command, the VIOC driver executes "/sbin/reboot" or "/sbin/shutdown" via the usermodehelper() call. This same communications facility is used for dynamic VNIC provisioning (plug in and out). The VIOC driver also registers a callback with register_reboot_notifier(). When the callback is executed, the driver records the shutdown event and reason in a VIOC register to notify the System Controller. - 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: GPL vs non-GPL device drivers
On 2/15/07, v j <[EMAIL PROTECTED]> wrote: This has nothing to do with politics. I am not a Linux contributor. Here-in lies the problem. I am one of the few people willing to state openly that I wish those who can, would use their legal claims to stop people like you from writing proprietary drivers. Although you (or your company) clearly has the ability to contribute to Linux, you have chosen not to. Instead, you just leach off those that do. As such, I believe you and your ilk are ethically deplorable and the fact that you would come here to try to point out to the contributors that they are going to lose people like you if they don't stop "threatening" your drivers not only baffles me, it sickens me. At least with NVIDIA and ATI they're not actually profiting from the existence of Linux, but you're actually selling the stuff and you don't even consider the very reasonable proposition of sharing your source code in return. It's not like they're asking for money.. man, this is the Linux project, they don't even ask for copyright assignment or allegiance to an ideology.. Do the right thing, cough up your source code, get it integrated into the tree and let the community do what it does so well. Trent - 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(Experimental) 0/4] Freezer based Cpu-hotplug
On Wed, Feb 14, 2007 at 10:43:35PM +0100, Rafael J. Wysocki wrote: > Hi, > > On Wednesday, 14 February 2007 15:40, Gautham R Shenoy wrote: > > Hello Everybody, > > > > This is an experiment towards process_freezer based implementation > > of cpu-hotplug. This is mainly based on ideas of Andrew Morton, > > Ingo Molnar and Paul Mckenney featured in the discussion > > http://lkml.org/lkml/2007/1/31/323. > > > > This is an absolute bare-minimal implementation to check the feasibility > > of using process freezer for cpu-hotplug. > > > > The patchset comprises of four patches. > > o PATCH 1/4: Core implementation of freezer-based-hotplug. > > o PATCH 2/4: Revert changes to workqueue to make it work with the > > freezer-cpu-hotplug. > > o PATCH 3/4: Eliminate hotcpu subsystem mutexes from sched and slab. > > o PATCH 4/4: Eliminate lock_cpu_hotplug from the kernel. > > I think two things are missing: > > 1) We should make sure there are not PF_NOFREEZE tasks running when a CPU > is removed (when one is added probably too). For this purpose we can add a > parameter to freeze_processes() that will tell it to ignore PF_NOFREEZE, but > at the same time we'll have to change all kernel threads that set PF_NOFREEZE > to call try_to_freeze() anyway. I can do that, but it will take me a couple > of > days. Why should we make sure that PF_NOFREEZE tasks are also frozen for cpu hotplug? Instead, we can create an infrastructure which allows threads to specify for the scenarios they would want to be excempted from freeze. Something like what Paul has suggested in http://lkml.org/lkml/2007/1/31/323. That way, threads which have nothing to do with the online_cpu_map or with handling of cpu-hotplug events can mark themselves to be exempted from being frozen for cpu hotplug. Once this is achieved, it's all about classifying the threads into according to their NO_FREEZE needs :) > > 2) We have to change the PM code to stop using CPU hotplug for disabling > nonboot CPUs. ;-) Just wondering, how hard is that ? thanks gautham. -- Gautham R Shenoy Linux Technology Center IBM India. "Freedom comes with a price tag of responsibility, which is still a bargain, because Freedom is priceless!" - 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/
irqdesc porting help
Im trying to port some drivers between 2.6.14 and 2.6.19 I find that irqdesc has changed completely. how do i port the drivers between 2.6.14 and 2.6.19? is there a porting guide available to port the drivers which use irqdesc?. my drivers use variables triggered, ... which dont exist in 2.6.19 irqdesc strcuture. Could anyone help me on this. Regards, Jo - 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: [LIBATA BUG] sr.c: TEST_UNIT_READY error
On 2/13/07, Conke Hu <[EMAIL PROTECTED]> wrote:
On 2/2/07, Conke Hu <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-02-07 at 07:40 -0500, Jeff Garzik wrote:
> > Conke Hu wrote:
> > > Hi,
> > >TEST_UNIT_READY in get_capabilities (drivers/scsi/sr.c line 743, or
> > > see below) always returns error.
> > >
> > > code begin -
> > > retries = 0;
> > > do {
> > > memset((void *)cmd, 0, MAX_COMMAND_SIZE);
> > > cmd[0] = TEST_UNIT_READY;
> > >
> > > the_result = scsi_execute_req (cd->device, cmd, DMA_NONE, NULL,
> > >0, &sshdr, SR_TIMEOUT,
> > >MAX_RETRIES);
> > >
> > > retries++;
> > > } while (retries < 5 &&
> > > (!scsi_status_is_good(the_result) ||
> > > (scsi_sense_valid(&sshdr) &&
> > >sshdr.sense_key == UNIT_ATTENTION)));
> > > code end -
> > >
> > > I debugged all kernel versions from 2.6.17 to 2.6.20 on several AMD
> > > and other vendor's PATA/IDE controllers, and I get the_result==0x802
> > > and retries==5; on silicon image 3132, i get the_result=0x2eb.
> > > Does 0x802 mean ((DRIVER_SENSE << 24) | SAM_STAT_CHECK_CONDITION)?
> > > what's wrong?
> >
> > What does the sense data returned in the sense buffer say is wrong?
> >
> > Jeff
>
> I dump scsi_sense_hdr as follows:
> sshdr.response_code = 0x70
> sshdr.sense_key = 0x2
> sshdr.asc = 0x3a
> sshdr.ascq = 0x1
> sshdr.additional_length = 0x0
>
> the sense_key is 0x2 (NOT_READY), but the expected UNIT_ATTENTION :(
but "NOT" the expected UNIT_ATTENTION.
>
> BTW, I am sorry for a mistake, Sil3132 also returns 0x802, not 0x2eb
> as I said in the first mail. In a word, all cases return "the_result" as
> 0x802.
>
the bytes 0 ~ 13 in sense buffer are:
70 00 02 00 00 00 00 0a 00 00 00 00 3a
other bytes are all 0x00;
in fact this issue can be reproduced in any libata driver, either sata or pata.
Conke
[resend]
any suggestion ?
-
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: GPL vs non-GPL device drivers
On 2/14/07, Dave Jones <[EMAIL PROTECTED]> wrote: On Wed, Feb 14, 2007 at 09:16:28PM -0800, v j wrote: Welcome to three months ago. Here in the future, this was deemed a non-issue. However this does highlight another problem. End-users who take linux for use in embedded systems (especially) tend to live in their own little world rarely contributing anything back to upstream, popping up occasionally when months after decisions have been made on things. Remind me again why we should care about your out of tree binary only modules ? You are right. I have not contributed anything to Linux. Except one small patch to the MTD code. However, I don't think that is the point here. I am perfectly willing to live with the way Linux is today. I am telling you as a user that if Linux continues on the current path it will become less and less attractive to Embedded Users. Not everybody has to be a contributor. The reason Linux is popular is because of its openness. Take that away and see where it goes. - 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 000/196] V4L/DVB updates
Linus, Please pull 'master' from: git://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git master Basically, this series adds support for a bunch of newer cards and newer drivers, do some relevant cleanups on cx88 (improving source code readability and reducing binary code size), adds FM radio support on pvrusb2 and do several other fixes and improvements. A more detailed log: - Add support for the ASUS P7131 remote control - Add the Composite over S-Video input on the Asus P7131 Dual - Update cx2341x documentation. - Update cx2341x documentation. - Removed unimplemented cx2341x API commands - Improve cx2341x documentation - Saa7134: add support for the Encore ENL-TV - Updated cardlist to reflect the newly added saa7134 board - DIB3000MC and NOVA T USB2 #2 - Cablestar2 support - DVB: Remove unneeded void * casts in ttpci/av7110 - Remove some unused code from kernel mainstream - Add support for more Encore TV cards - DVB: fix compile error - Make usbvision_rvfree() static - MAINTAINERS: tag pvrusb2 list as subscribers-only - Pvrusb2-hdw kfree cleanup - Cpia module_put cleanup - Tvmixer module_put cleanup - Cleanup: switch to using msecs_to_jiffies() on bttv - Improves some USBVision info messages - Bt8xx: add support for Ultraview DVB-T Lite - SN9C102 driver updates - ZC0301 driver updates. - ET61X251 driver updates. - Fix authorship references - Budget-ci: add support for the Technotrend 1500 bundled remote - Fix OOPS on some waitqueue conditions - Some fixes at stream waitqueue on vivi - Pvrusb2: Enable radio mode round #1 - Pvrusb2: Enable radio mode round #2 - Pvrusb2: Fix for min/max control value checking - Pvrusb2: Implement multiple minor device number handling - Pvrusb2: Implement stream claim checking function - Pvrusb2: Implement /dev/radioX - Pvrusb2: Use enumeration for minor number get / store code - Pvrusb2: Use separate enumeration for get/store of minor number - Pvrusb2: Make units uniform when tracking tuning frequency - Pvrusb2: video standard broadcast fix for radio mode - Pvrusb2: Allow overriding vbi and radio device minor numbers - Pvrusb2: Fix heap corruption introduced by radio mods - Pvrusb2: Fix tuner frequency calculation - Pvrusb2: Fix tuning calculation when in radio mode - Pvrusb2: v4l2 API implementation frequency tweaks - Pvrusb2: Enable radio mode for 24xxx devices - Pvrusb2: Newer frequency range checking - Pvrusb2: Better radio versus tv frequency handling - Pvrusb2: Remove stream claiming hack from /dev/radio - Pvrusb2: Change default volume to something sane - Pvrusb2: cosmetic comment tweak - Pvrusb2: Fix cut/paste bug in auto_mode_switch control - Pvrusb2: Stream configuration cleanups - Pvrusb2: bug fix involving switch into radio mode - Pvrusb2: Be smarter about mode restoration - Cpia.c: buffer overflow - Bttv cropping support - Pvrusb2: It's safe to kfree() a null pointer - Pvrusb2: Use kzalloc instead of kmalloc+memset pairs - Pvrusb2: Allow streaming from /dev/radioX - Pvrusb2: VIDIOC_G_TUNER cleanup - Pvrusb2: Slight debug printing efficiency fixup - Pvrusb2: Remove automodeswitch control - Pvrusb2: Stop hardcoding frequency ranges - Pvrusb2: trace print added - Pvrusb2: Fix missing break statement on VIDIOC_S_TUNER - Pvrusb2: Fix sizeof() calculation foul-up - Pvrusb2: Minor dead code / comment cleanups - Pvrusb2: V4L EXT_CTRLS fixup - Pvrusb2: A patch to use ARRAY_SIZE macro when appropriate - Pvrusb2: Use kzalloc in place of kmalloc/memset pairs - Pvrusb2: Use ARRAY_SIZE wherever possible - Pvrusb2: Emit VIDIOC_S_TUNER correctly - Pvrusb2: Introduce fake audio input selection - Pvrusb2: Allow VIDIOC_S_FMT with -1 for resolution values - Convert cx8800 driver to video_ioctl2 handler - Added support for V4L2_STD_NTSC_443 - Uncommented NTSC/443 video standard - Make cx88-blackbird to work again - Renamed video_mux to cx88_video_mux - make videodev to auto-generate standards - Fix vidioc_g_tuner handling - Moved several stuff that were at cx88-video to cx88-blackbird.c - Reorder some ioctl handlers - Do some cleanups at cx88-blackbird - Use cx88_set_freq() on cx88-blackbird.c - Remove_cx88_ioctl - Convert cx88-blackbird to use video_ioctl2 - Keep the previous tvnorm default for cx88 and cx88-blackbird - Saa7134: add support for Terratec Cinergy HT PCI - Adds video output routing - Cx88: Add support for svideo/composite input of the Terratec Cinergy 1400 DVB-T - Remove some warnings when compiling on x86_64 - Fix: VIDIOC_G_TUNER were returning an endless number of tuners - Various cx2341x documentation updates/fixes. - Proper vendor/device ID for the CinergyT2 input device - Dvb-usb: Initial support for MSI Mega Sky 580 based on Uli m9206 - Dvb-usb: rena
Re: GPL vs non-GPL device drivers
v j wrote: This is in reference to the following thread: http://lkml.org/lkml/2006/12/14/63 I am not sure if this is ever addressed in LKML, but linux is _very_ popular in the embedded space. We (an embedded vendor) chose Linux 3 years back because of its lack of royalty model, robustness and availability of infinite number of open-source tools. [...] However we have a worrying trend here. If at some point it becomes illegal to load our modules into the linux kernel, then it is unacceptable to us. We would have been better off choosing VxWorks or OSE 3 years ago when we made an OS choice. The fact that Linux is becoming more and more closed is very very alarming. Question to the world here: Distros make, as a matter of course, a series of modifications to the Linux Kernel so that their modules or features work. What stops VJ making a patchset which effectively s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g 's the kernel source then distributing that under the GPL? He then supplies his un-GPL'd modules to the world which just happen to only run on the modified kernel. I've read the GPL of course (IANAL though) and I can't see what this violates except the /spirit/ of the license. Don't get me wrong, I'm strongly against anyone doing what I just mentioned, I believe it to be immoral taking someone's GPL'd code and mangling it in such a way. I speak as an embedded developer myself whose company decided that running our code under Linux and distributing our code under the GPL was far preferable to running closed-source software on a closed-source platform. I'll finish off to VJ: If you want to be alarmed, go ahead and switch to VxWorks, the Linux community will live on. It might have a smaller user-base in embedded-land but that's the nature of the beast. A large user-base doesn't mean much to something like linux unless it comes with a large, open-source-minded developer-base. --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 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 10:14:53PM -0800, Andreas Gruenbacher wrote: > On Wednesday 14 February 2007 21:45, Dave Jones wrote: > > well, the situation for external modules is no worse than usual. > > They still work, they just aren't signed. Which from a distributor point > > of view, is actually a nice thing, as they stick out like a sore thumb > > in oops reports with (U) markers :) > > I agree, that's really what should happen. We solve this by marking modules > as > supported, partner supported, or unsupported, but in an "insecure" way, so > partners and users could try to fake the support status of a module and/or > remove status flags from Oopses, and cryptography wouldn't save us. We could > try to sign Oopses which I guess you guys are doing. This whole issue hasn't > been a serious problem in the past though, and we generally try to trust > users not to play games on us. For the most part it works out. I've had users file oopses where they've editted out Tainted: P, and left in nvidia(U) for example :-) 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: GPL vs non-GPL device drivers
On 2/14/07, v j <[EMAIL PROTECTED]> wrote: This has nothing to do with politics. I am not a Linux contributor. I realize that people who have contributed to the Linux Kernel have very valid points. It is their sweat and blood. They have a right to protect what they have worked on. I am purely commenting from a user perspective. If Linux becomes closed to external drivers, then it will have repercussions in the embedded space. I can say for certain that a company evaluating OSes and realizing that their drivers will have to be open-source will almost certainly go for the alternative. On 2/14/07, Trent Waddington <[EMAIL PROTECTED]> wrote: > On 2/15/07, v j <[EMAIL PROTECTED]> wrote: > > The drivers which we have written over the last three years are suddenly > > under threat. > > [..] > > The fact that Linux is becoming more and more closed is very very alarming. > > Sigh. Someone remind me of the rules against "politics" on the list > before I get into why vj should play nice with the other children. > > Trent > - 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: GPL vs non-GPL device drivers
On Wednesday February 14, [EMAIL PROTECTED] wrote: > > However we have a worrying trend here. If at some point it becomes > illegal to load our modules into the linux kernel, then it is > unacceptable to us. We would have been better off choosing VxWorks or > OSE 3 years ago when we made an OS choice. The fact that Linux is > becoming more and more closed is very very alarming. Might I suggest that you give very serious consideration to open-sourcing your drivers? There are benefits and well as costs, and many have found that the benefits substantially out weigh the costs. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wednesday 14 February 2007 21:45, Dave Jones wrote: > well, the situation for external modules is no worse than usual. > They still work, they just aren't signed. Which from a distributor point > of view, is actually a nice thing, as they stick out like a sore thumb > in oops reports with (U) markers :) I agree, that's really what should happen. We solve this by marking modules as supported, partner supported, or unsupported, but in an "insecure" way, so partners and users could try to fake the support status of a module and/or remove status flags from Oopses, and cryptography wouldn't save us. We could try to sign Oopses which I guess you guys are doing. This whole issue hasn't been a serious problem in the past though, and we generally try to trust users not to play games on us. In the end, it all seems to boils down to a difference in philosophy. Thanks, Andreas - 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: GPL vs non-GPL device drivers
On Wed, Feb 14, 2007 at 09:16:28PM -0800, v j wrote: > This is in reference to the following thread: > > http://lkml.org/lkml/2006/12/14/63 > > I am not sure if this is ever addressed in LKML, but linux is _very_ > popular in the embedded space. We (an embedded vendor) chose Linux 3 > years back because of its lack of royalty model, robustness and > availability of infinite number of open-source tools. Welcome to three months ago. Here in the future, this was deemed a non-issue. However this does highlight another problem. End-users who take linux for use in embedded systems (especially) tend to live in their own little world rarely contributing anything back to upstream, popping up occasionally when months after decisions have been made on things. Remind me again why we should care about your out of tree binary only modules ? > The drivers which > we have written over the last three years are suddenly under threat. Were they part of the kernel tree, people might care enough to a) fix them so that they work and b) care enough that they _keep working_ even if people changing APIs etc don't have the necessary hardware. This isn't the 1990s any more, we shouldn't need to explain how all this works. > However we have a worrying trend here. If at some point it becomes > illegal to load our modules into the linux kernel, then it is > unacceptable to us. We would have been better off choosing VxWorks or > OSE 3 years ago when we made an OS choice. The fact that Linux is > becoming more and more closed is very very alarming. The question is "do you care about giving back" or are you intending to leech of Linux and just complain when it changes in ways that don't mesh with your plans? 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: [uml-devel] x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be accepted
On Thu, 15 Feb 2007 04:43:41 +0100 Blaisorblade <[EMAIL PROTECTED]> wrote:
> > I sent an equivalent patch in earlier today:
> Doh! Interesting this timing...
>
> > Index: linux-2.6/arch/x86_64/ia32/ptrace32.c
> > ===
> > --- linux-2.6.orig/arch/x86_64/ia32/ptrace32.c
> > +++ linux-2.6/arch/x86_64/ia32/ptrace32.c
> > @@ -239,6 +239,8 @@ asmlinkage long sys32_ptrace(long reques
> > __u32 val;
> >
> > switch (request) {
> > + case PTRACE_OLDSETOPTIONS:
> > + request = PTRACE_SETOPTIONS;
> > case PTRACE_TRACEME:
> > case PTRACE_ATTACH:
> > case PTRACE_KILL:
> >
> > I change the request so that PTRACE_OLDSETOPTIONS doesn't need to
> > propogate any further. However, it is present in include/asm-x86_64,
> > so I guess that counts as being part of the x86_64 ABI. That being
> > the case, I guess my patch can be dropped in favor of this one.
>
> It is handled in ptrace_request, unless there are include problems. I'm going
> to reboot and test mine for any remaining problem.
Whatever happens, please ensure that the final fix makes it into -stable
as well. Jeff's version of this patch wasn't cc'ed to [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: 2.6.20 mmc: problem with highspeed SD card
Eugene Ilkov wrote: > I have I/O errors with Transcend SD highspeed card 2GB/150x when it's > mounted in r/w mode (cardreader on sharp sl-c1000) > It works well if I reverse mmcv4 patch commited to 2.6.19-git2 > (http://lkml.org/lkml/2006/10/4/27) That patch is not the same as you are referencing in the rest of your mail. > I'm not experienced in mmc, but I figured out that problem is > somewhere in mmc_read_switch_caps() and when i change cmd.arg value > from 0x80F1 to 0x00F1 it works fine too > What argument should have SD_SWITCH opcode? > The argument is correct, so I'm guessing that your controller might be a bit flaky and not handle the new timing. Can you enable MMC_DEBUG and send over the dmesg? Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.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: GPL vs non-GPL device drivers
On 2/15/07, v j <[EMAIL PROTECTED]> wrote: The drivers which we have written over the last three years are suddenly under threat. [..] The fact that Linux is becoming more and more closed is very very alarming. Sigh. Someone remind me of the rules against "politics" on the list before I get into why vj should play nice with the other children. Trent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 09:35:40PM -0800, Andreas Gruenbacher wrote: > On Wednesday 14 February 2007 20:13, Dave Jones wrote: > > I've not investigated it, but I hear rumours that suse has something > > similar. > > Actually, no. We don't belive that module signing adds significant value, ok, then I was misinformed. > and it also doesn't work well with external modules. well, the situation for external modules is no worse than usual. They still work, they just aren't signed. Which from a distributor point of view, is actually a nice thing, as they stick out like a sore thumb in oops reports with (U) markers :) > (The external modules we really care about are GPL ones; it gives us a way > to update drivers without pushing out entirely new kernels.) external modules still compile, and run just fine. The signed modules code doesn't prevent loading of them unless the user decides to do so with a special boot option (which is no different really than say, reducing the cap-bound sysctl to prevent module loading). 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: GPL vs non-GPL device drivers
No its not. It wasn't common knowledge 3 years ago when we chose Linux as an embedded platform. If it indeed is common knowledge that loadable modules in Linux have to be open-source then it is very probable that we wouldn't have chosen Linux as the platform of choice. If this indeed is the case and is common knowledge, then I predict that Linux will soon drop in popularity as the OS of choice in embedded systems. On 2/14/07, Lee Revell <[EMAIL PROTECTED]> wrote: Um... it's been common knowledge for years that the legal status of non-GPL kernel modules is an open issue. Specifically, whether a device driver written for the Linux kernel is a derived work of the kernel. Sounds like you didn't do your homework 3 years ago. Why did you assume that linking a non-GPL module into the GPL Linux kernel was legal? You have read the GPL right? Lee On 2/15/07, v j <[EMAIL PROTECTED]> wrote: > This is in reference to the following thread: > > http://lkml.org/lkml/2006/12/14/63 > > I am not sure if this is ever addressed in LKML, but linux is _very_ > popular in the embedded space. We (an embedded vendor) chose Linux 3 > years back because of its lack of royalty model, robustness and > availability of infinite number of open-source tools. > > We recently decided to move to Linux 2.6 for our next product, mainly > because Linux has worked so well for us in the past, and we would like > to move up to keep up with the latest and greatest. > > However in moving to 2.6, we noticed a number of alarming things. > Porting drivers over from devfs to udev, though easy raised a number > of alarming issues. Driver's no longer could dynamically allocate > their MAJOR/MINOR numbers. Doing so would mean they would have to use > sysfs. However it seems that sysfs (and the class_ interface) is only > available to GPL modules. This is very concerning. The drivers which > we have written over the last three years are suddenly under threat. > We don't mind statically assigning MAJOR/MINOR numbers to our drivers. > We can do this and modify our user space applications too. > > However we have a worrying trend here. If at some point it becomes > illegal to load our modules into the linux kernel, then it is > unacceptable to us. We would have been better off choosing VxWorks or > OSE 3 years ago when we made an OS choice. The fact that Linux is > becoming more and more closed is very very alarming. > > vj. > - > 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 0/6] MODSIGN: Kernel module signing
On Wednesday 14 February 2007 20:13, Dave Jones wrote: > I've not investigated it, but I hear rumours that suse has something > similar. Actually, no. We don't belive that module signing adds significant value, and it also doesn't work well with external modules. (The external modules we really care about are GPL ones; it gives us a way to update drivers without pushing out entirely new kernels.) Cheers, Andreas - 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] aio: fix kernel bug when page is temporally busy
> Please, tell us what problem this is fixing so that we can look into
> alternative solutions.
This patch fixes a kernel panic "Kernel BUG at fs/aio.c:509"
http://marc.theaimsgroup.com/?l=linux-kernel&m=117031052517746&w=2
First of all it was found that the kernel panic happens after
IO error reporting. But later it was found that the actual
reason is not in real IO error but in a busy page.
EIO is returned if page has unstable state while IO completion
result is processing.
If aio_run_iocb() as well as in do_sync_read/write() get EIO result
it is considered as IO is finished and IO control block
could be free; result is reported to caller.
I suppose that aio_run_iocb() as well as in do_sync_read/write()
should have a chance to differ real EIO and EIO which is actually
means EAGAYN. That functions test for EIOCBRETRY meaning EAGAYN purpose.
do_sync_read/write() retries IO as well as aio:
for (;;) {
ret = filp->f_op->aio_read(&kiocb, &iov, 1,
kiocb.ki_pos);
if (ret != -EIOCBRETRY)
break;
wait_on_retry_sync_kiocb(&kiocb);
}
By the way EIOCBRETRY is never actually set in the kernel. So what is
the
purpose of previous lines?
More details about EIO returning:
aio_complete: res=-5 iocb=81002b38f080 ki_users=2
[] invalidate_inode_pages2_range+0x236/0x26b
[] ext3_direct_IO+0x16c/0x19e
[] ext3_get_block+0x0/0xe2
[] generic_file_direct_IO+0xb9/0xcf
[] generic_file_direct_write+0x67/0x10e
[] __generic_file_aio_write_nolock+0x2d6/0x3fe
[] __switch_to+0x26f/0x27e
[] thread_return+0x0/0xd8
[] generic_file_aio_write+0x67/0xc7
[] ext3_file_write+0x0/0x8f
[] ext3_file_write+0x16/0x8f
[] ext3_file_write+0x0/0x8f
[] aio_rw_vect_retry+0x72/0x14f
[] aio_run_iocb+0xe6/0x187
[] io_submit_one+0x296/0x2e3
[] sys_io_submit+0x9b/0x108
[] default_wake_function+0x0/0xe
[] system_call+0x7e/0x83
Call Trace:
[] aio_complete+0x5c/0x18c
[] finished_one_bio+0xac/0xf3
[] dio_bio_complete+0x95/0xaa
[] dio_bio_end_aio+0x20/0x25
[] __end_that_request_first+0x10e/0x3fd
[] scsi_end_request+0x27/0xc9
[] scsi_io_completion+0xf0/0x2c5
[] ahd_done+0x537/0x580
[] sd_rw_intr+0x182/0x1ad
[] blk_done_softirq+0x5c/0x6a
[] __do_softirq+0x55/0xc3
[] ack_apic_level+0x37/0x4b
[] call_softirq+0x1c/0x28
[] do_softirq+0x2c/0x7d
[] do_IRQ+0xa8/0xc8
[] mwait_idle+0x0/0x20
[] ret_from_intr+0x0/0xa
[] mwait_idle_with_hints+0x44/0x45
[] mwait_idle+0xc/0x20
[] cpu_idle+0x8b/0xb0
[] start_secondary+0x462/0x471
-Original Message-
From: Andrew Morton [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 15, 2007 6:31 AM
To: Ananiev, Leonid I
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] aio: fix kernel bug when page is temporally busy
On Wed, 14 Feb 2007 20:51:33 +0300 "Ananiev, Leonid I"
<[EMAIL PROTECTED]> wrote:
> Fix kernel bug when IO page is temporally busy:
> invalidate_inode_pages2_range() returns EIOCBRETRY but not EIO.
> invalidate_inode_pages2() returns EIO as earlier.
>
> Signed-off-by: Leonid Ananiev <[EMAIL PROTECTED]>
> ---
> --- linux-2.6.20/mm/truncate.c 2007-02-04 10:44:54.0 -0800
> +++ linux-2.6.20p/mm/truncate.c 2007-02-08 22:56:52.0 -0800
> @@ -366,7 +366,7 @@ static int do_launder_page(struct addres
> * Any pages which are found to be mapped into pagetables are
unmapped prior to
> * invalidation.
> *
> - * Returns -EIO if any pages could not be invalidated.
> + * Returns -EIOCBRETRY if any pages could not be invalidated.
> */
> int invalidate_inode_pages2_range(struct address_space *mapping,
> pgoff_t start, pgoff_t end)
> @@ -423,7 +423,7 @@ int invalidate_inode_pages2_range(struct
> }
> ret = do_launder_page(mapping, page);
> if (ret == 0 &&
!invalidate_complete_page2(mapping, page))
> - ret = -EIO;
> + ret = -EIOCBRETRY;
> unlock_page(page);
> }
> pagevec_release(&pvec);
> @@ -444,6 +444,7 @@ EXPORT_SYMBOL_GPL(invalidate_inode_pages
> */
> int invalidate_inode_pages2(struct address_space *mapping)
> {
> - return invalidate_inode_pages2_range(mapping, 0, -1);
> + int ret = invalidate_inode_pages2_range(mapping, 0, -1);
> + return (ret < 0)?-EIO:ret;
> }
> EXPORT_SYMBOL_GPL(invalidate_inode_pages2);
If someone later uses invalidate_inode_pages2_range() elsewhere, they're
going to need to know to convert -EIOCBRETRY into -EIO, if they weren't
called by aio. Or something.
Please, tell us what problem this is fixing so that we can look into
alternative solutions.
For example, one acceptable-but-ugly solution might be to do:
static inline int invalidate_inode_pages2_range(struct address_space
*mapping,
pgoff_t start, pgoff_t end)
{
return __invalidate_inode_pages2_range(mapping, start, end, 0);
}
static inline int invalidate
Re: [ANNOUNCE] GIT 1.5.0
Jakub Narebski <[EMAIL PROTECTED]> wrote: > Junio C Hamano wrote: > > > - git-blame learned a new option, --incremental, that tells it > > to output the blames as they are assigned. A sample script > > to use it is also included as contrib/blameview. > > And there are example GUI blameview (Perk GTK2), and example Emacs module > for incremental git-blame, both in contib/ area. Not to mention the incremental blame viewer built into git-gui: git gui blame HEAD foo.c -- Shawn. - 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/
GPL vs non-GPL device drivers
This is in reference to the following thread: http://lkml.org/lkml/2006/12/14/63 I am not sure if this is ever addressed in LKML, but linux is _very_ popular in the embedded space. We (an embedded vendor) chose Linux 3 years back because of its lack of royalty model, robustness and availability of infinite number of open-source tools. We recently decided to move to Linux 2.6 for our next product, mainly because Linux has worked so well for us in the past, and we would like to move up to keep up with the latest and greatest. However in moving to 2.6, we noticed a number of alarming things. Porting drivers over from devfs to udev, though easy raised a number of alarming issues. Driver's no longer could dynamically allocate their MAJOR/MINOR numbers. Doing so would mean they would have to use sysfs. However it seems that sysfs (and the class_ interface) is only available to GPL modules. This is very concerning. The drivers which we have written over the last three years are suddenly under threat. We don't mind statically assigning MAJOR/MINOR numbers to our drivers. We can do this and modify our user space applications too. However we have a worrying trend here. If at some point it becomes illegal to load our modules into the linux kernel, then it is unacceptable to us. We would have been better off choosing VxWorks or OSE 3 years ago when we made an OS choice. The fact that Linux is becoming more and more closed is very very alarming. vj. - 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] Optimize generic get_unaligned / put_unaligned implementations.
On Wed, 14 Feb 2007 21:42:26 + Ralf Baechle <[EMAIL PROTECTED]> wrote:
> Time for a little bit of dead horse flogging.
>
> On Mon, Mar 06, 2006 at 05:05:52PM -0800, Andrew Morton wrote:
>
> > > --- a/include/asm-generic/unaligned.h
> > > +++ b/include/asm-generic/unaligned.h
> > > @@ -78,7 +78,7 @@ static inline void __ustw(__u16 val, __u
> > >
> > > #define __get_unaligned(ptr, size) ({\
> > > const void *__gu_p = ptr; \
> > > - __typeof__(*(ptr)) val; \
> > > + __u64 val; \
> > > switch (size) { \
> > > case 1: \
> > > val = *(const __u8 *)__gu_p;\
> > > @@ -95,7 +95,7 @@ static inline void __ustw(__u16 val, __u
> > > default:\
> > > bad_unaligned_access_length(); \
> > > }; \
> > > - val;\
> > > + (__typeof__(*(ptr)))val;\
> > > })
> > >
> > > #define __put_unaligned(val, ptr, size) \
> >
> > I worry about what impact that change might have on code generation.
> > Hopefully none, if gcc is good enough.
> >
> > But I cannot think of a better fix.
>
> It does inflate the code but back then we agreed to go for Atsushi's patch
> because it was fairly obviously correct. This patch obviously is less
> obvious but generates fairly decent, works for arbitrary data types and
> cuts down the size of unaligned.h from 122 lines to 44 so it must be good.
>
> ...
>
> +#define get_unaligned(ptr) \
> +({ \
> + const struct { \
> + union { \
> + const int __un_foo[0]; \
> + const __typeof__(*(ptr)) __un; \
> + } __un __attribute__ ((packed));\
> + } * const __gu_p = (void *) (ptr); \
> + \
> + __gu_p->__un.__un; \
> })
Can someone please tell us how this magic works? (And it does appear to
work).
It seems to assuming that the compiler will assume that members of packed
structures can have arbitrary alignment, even if that alignment is obvious.
Which makes sense, but I'd like to see chapter-and-verse from the spec or
from the gcc docs so we can rely upon it working on all architectures and
compilers from now until ever more.
IOW: your changlogging sucks ;)
-
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/
sata_nv ADMA controller lockup investigation
While testing out some libata FUA changes I was working on, I was inadvertently able to reproduce the kind of NCQ command timeouts in sata_nv that a few people have reported. I since verified that the FUA stuff had nothing to do with it as it still happens even with FUA disabled. However I'm somewhat at a loss as to how to further debug this, so I'm posting my findings in the hope that somebody has some more ideas (or anyone at NVIDIA decides to come forth with a tip or two). The conditions in which I can reproduce this are with: ext3 filesystem mounted with -o barrier=1 Two instances of a program which truncates a file, then writes single bytes to it, fsyncing after each one. Simultaneously, repeatedly writing 100MB from /dev/zero to a file using dd. A command timeout usually happens within a few minutes. With my working copy loaded up with a ton of extra debugging, the exception report for one of these looks like this. My comments are indented. ata4: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000 status 0x400 cpb count 0x0 next cpb idx 0x0 This is just dumping all of the ADMA registers when the timeout happened. ata4: last intr at 1171511467:501179, status 0x1540 This shows the time of the last interrupt in seconds:microseconds and the ADMA status register contents at that time. ata4: cmd 61/08:00:40:36:75/00:00:0c:00:00/40 tag 0 at 1171511467:360525 done 1171511467:393064, stat before 0x400 after 0x400 ata4: cmd 61/40:00:80:a1:64/00:00:0a:00:00/40 tag 0 at 1171511467:393928 done 1171511467:394345, stat before 0x500 after 0x400 ata4: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 at 1171511467:394400 done 1171511467:425548, stat before 0x500 after 0x400 ata4: cmd 61/08:00:c0:a1:64/00:00:0a:00:00/40 tag 0 at 1171511467:425556 done 1171511467:425694, stat before 0x500 after 0x400 ata4: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 at 1171511467:425699 done 1171511467:433896, stat before 0x500 after 0x400 ata4: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 at 1171511467:433958 done 1171511467:433971, stat before 0x500 after 0x400 ata4: cmd 61/08:00:c8:a1:64/00:00:0a:00:00/40 tag 0 at 1171511467:433978 done 1171511467:434152, stat before 0x500 after 0x400 ata4: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 at 1171511467:434160 done 1171511467:442326, stat before 0x500 after 0x400 ata4: cmd 61/08:00:d0:a1:64/00:00:0a:00:00/40 tag 0 at 1171511467:442389 done 1171511467:442843, stat before 0x500 after 0x400 ata4: cmd 61/08:08:88:7e:75/00:00:0c:00:00/40 tag 1 at 1171511467:442395 done 1171511467:442846, stat before 0x400 after 0x400 ata4: cmd 61/e8:10:08:58:77/01:00:0c:00:00/40 tag 2 at 1171511467:442419 done 1171511467:445010, stat before 0x400 after 0x400 ata4: cmd 61/e8:18:f0:59:77/01:00:0c:00:00/40 tag 3 at 1171511467:442437 done 1171511467:447182, stat before 0x0 after 0x0 ata4: cmd 61/e8:20:d8:5b:77/01:00:0c:00:00/40 tag 4 at 1171511467:442455 done 1171511467:449343, stat before 0x0 after 0x0 ata4: cmd 61/e8:28:c0:5d:77/01:00:0c:00:00/40 tag 5 at 1171511467:442475 done 1171511467:451543, stat before 0x0 after 0x0 ata4: cmd 61/30:30:a8:5f:77/00:00:0c:00:00/40 tag 6 at 1171511467:442481 done 1171511467:451833, stat before 0x0 after 0x0 ata4: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 at 1171511467:451858 done 1171511467:492486, stat before 0x500 after 0x400 ata4: cmd 61/08:00:d8:a1:64/00:00:0a:00:00/40 tag 0 at 1171511467:492498 done 1171511467:492666, stat before 0x500 after 0x400 ata4: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 at 1171511467:492671 done 1171511467:500909, stat before 0x500 after 0x400 ata4: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 at 1171511467:501167 done 1171511467:501181, stat before 0x500 after 0x400 ata4: cmd 61/08:00:e0:a1:64/00:00:0a:00:00/40 tag 0 at 1171511467:501187 done 0:0, stat before 0x500 after 0x400 These lines show the last 20 commands issued, the contents of the taskfile, the tag, the time in sec:usec they were issued, the time in sec:usec they completed (0:0 for still incomplete), the ADMA status register contents before issuing the command, and the register contents after issuing the command. ata4: CPB 0: ctl_flags 0x1f, resp_flags 0x0 Contents of the outstanding CPB's flags, showing that the controller seems not to have touched it, released and done flags are clear. ata4: timeout waiting for ADMA IDLE, stat=0x400 ata4: timeout waiting for ADMA LEGACY, stat=0x400 As part of error handling we try to switch the controller back to legacy mode. We time out waiting for the controller to show IDLE, and then clear the GO bit, and then time out waiting for it to show the LEGACY state. Right after this we beat it over the head with NV_ADMA_CTL_CHANNEL_RESET which finally seems to restore its senses, until one of these happens again. ata4.00: exception Emask 0x0 SAct 0x1 SErr 0x0 acti
[PATCH 2/2] autofs4 - check for directory re-create in lookup
Hi Andrew,
This problem was identified and fixed some time ago by Jeff Moyer
but it fell through the cracks somehow.
It is possible that a user space application could remove and
re-create a directory during a request. To avoid returning a
failure from lookup incorrectly when our current dentry is
unhashed we need to check if another positive, hashed dentry
matching this one exists and if so return it instead of a fail.
Signed-off-by: Jeff Moyer <[EMAIL PROTECTED]>
Signed-off-by: Ian Kent <[EMAIL PROTECTED]>
Ian
---
--- linux-2.6.20/fs/autofs4/root.c.lookup-check-unhased 2007-02-12
13:49:46.0 +0900
+++ linux-2.6.20/fs/autofs4/root.c 2007-02-12 13:54:58.0 +0900
@@ -655,14 +655,29 @@ static struct dentry *autofs4_lookup(str
/*
* If this dentry is unhashed, then we shouldn't honour this
-* lookup even if the dentry is positive. Returning ENOENT here
-* doesn't do the right thing for all system calls, but it should
-* be OK for the operations we permit from an autofs.
+* lookup. Returning ENOENT here doesn't do the right thing
+* for all system calls, but it should be OK for the operations
+* we permit from an autofs.
*/
if (dentry->d_inode && d_unhashed(dentry)) {
+ /*
+* A user space application can (and has done in the past)
+* remove and re-create this directory during the callback.
+* This can leave us with an unhashed dentry, but a
+* successful mount! So we need to perform another
+* cached lookup in case the dentry now exists.
+*/
+ struct dentry *parent = dentry->d_parent;
+ struct dentry *new = d_lookup(parent, &dentry->d_name);
+ if (new != NULL)
+ dentry = new;
+ else
+ dentry = ERR_PTR(-ENOENT);
+
if (unhashed)
dput(unhashed);
- return ERR_PTR(-ENOENT);
+
+ return dentry;
}
if (unhashed)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/4] ipmi: add new IPMI nmi watchdog handling
On Thu, 15 Feb 2007 15:05:56 +1100 Paul Mackerras <[EMAIL PROTECTED]> wrote: > Andrew Morton writes: > > > This is all fairly unpleasant. > > > > What architecture is preventing us from using DIE_NMI_POST on all > > architectures which support ipmi? ia64? > > > > It would be better to simply require that all ipmi-using architectures > > implement notify_die(DIE_NMI_POST, ...). > > We're starting to see IPMI creeping on powerpc as well, and we don't > have an NMI. > Sure, but you could implement the registration function. I mean, you _would_ call the NMI callback if you could, right ;) As it stands, this change is pretty gruesome... - 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] autofs4 - fix another race between mount and expire
Hi Andrew,
Jeff Moyer has identified a race between mount and expire.
What happens is that during an expire the situation can arise
that a directory is removed and another lookup is done before
the expire issues a completion status to the kernel module.
In this case, since the the lookup gets a new dentry, it doesn't
know that there is an expire in progress and when it posts its
mount request, matches the existing expire request and waits
for its completion. ENOENT is then returned to user space
from lookup (as the dentry passed in is now unhashed) without
having performed the mount request.
The solution used here is to keep track of dentrys in this
unhashed state and reuse them, if possible, in order to
preserve the flags. Additionally, this infrastructure will
provide the framework for the reintroduction of caching
of mount fails removed earlier in development.
Signed-off-by: Ian Kent <[EMAIL PROTECTED]>
Acked-by: Jeff Moyer <[EMAIL PROTECTED]>
Ian
---
--- linux-2.6.20/fs/autofs4/autofs_i.h.lookup-expire-race 2007-02-05
03:44:54.0 +0900
+++ linux-2.6.20/fs/autofs4/autofs_i.h 2007-02-12 12:15:17.0 +0900
@@ -52,6 +52,8 @@ struct autofs_info {
int flags;
+ struct list_head rehash;
+
struct autofs_sb_info *sbi;
unsigned long last_used;
atomic_t count;
@@ -110,6 +112,8 @@ struct autofs_sb_info {
struct mutex wq_mutex;
spinlock_t fs_lock;
struct autofs_wait_queue *queues; /* Wait queue pointer */
+ spinlock_t rehash_lock;
+ struct list_head rehash_list;
};
static inline struct autofs_sb_info *autofs4_sbi(struct super_block *sb)
--- linux-2.6.20/fs/autofs4/root.c.lookup-expire-race 2007-02-05
03:44:54.0 +0900
+++ linux-2.6.20/fs/autofs4/root.c 2007-02-12 12:14:51.0 +0900
@@ -263,7 +263,7 @@ static int try_to_fill_dentry(struct den
*/
status = d_invalidate(dentry);
if (status != -EBUSY)
- return -ENOENT;
+ return -EAGAIN;
}
DPRINTK("dentry=%p %.*s ino=%p",
@@ -413,7 +413,16 @@ static int autofs4_revalidate(struct den
*/
status = try_to_fill_dentry(dentry, flags);
if (status == 0)
- return 1;
+ return 1;
+
+ /*
+* A status of EAGAIN here means that the dentry has gone
+* away while waiting for an expire to complete. If we are
+* racing with expire lookup will wait for it so this must
+* be a revalidate and we need to send it to lookup.
+*/
+ if (status == -EAGAIN)
+ return 0;
return status;
}
@@ -459,9 +468,18 @@ void autofs4_dentry_release(struct dentr
de->d_fsdata = NULL;
if (inf) {
+ struct autofs_sb_info *sbi = autofs4_sbi(de->d_sb);
+
inf->dentry = NULL;
inf->inode = NULL;
+ if (sbi) {
+ spin_lock(&sbi->rehash_lock);
+ if (!list_empty(&inf->rehash))
+ list_del(&inf->rehash);
+ spin_unlock(&sbi->rehash_lock);
+ }
+
autofs4_free_ino(inf);
}
}
@@ -478,10 +496,80 @@ static struct dentry_operations autofs4_
.d_release = autofs4_dentry_release,
};
+static struct dentry *autofs4_lookup_unhashed(struct autofs_sb_info *sbi,
struct dentry *parent, struct qstr *name)
+{
+ unsigned int len = name->len;
+ unsigned int hash = name->hash;
+ const unsigned char *str = name->name;
+ struct list_head *p, *head;
+
+ spin_lock(&dcache_lock);
+ spin_lock(&sbi->rehash_lock);
+ head = &sbi->rehash_list;
+ list_for_each(p, head) {
+ struct autofs_info *ino;
+ struct dentry *dentry;
+ struct qstr *qstr;
+
+ ino = list_entry(p, struct autofs_info, rehash);
+ dentry = ino->dentry;
+
+ spin_lock(&dentry->d_lock);
+
+ /* Bad luck, we've already been dentry_iput */
+ if (!dentry->d_inode)
+ goto next;
+
+ qstr = &dentry->d_name;
+
+ if (dentry->d_name.hash != hash)
+ goto next;
+ if (dentry->d_parent != parent)
+ goto next;
+
+ if (qstr->len != len)
+ goto next;
+ if (memcmp(qstr->name, str, len))
+ goto next;
+
+ if (d_unhashed(dentry)) {
+ struct autofs_info *ino = autofs4_dentry_ino(dentry);
+ struct inode *inode = dentry->d_inode;
+
+ list_del_init(&ino->rehash);
+
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, Feb 14, 2007 at 07:41:12PM -0800, Andrew Morton wrote: > 77 files changed, 9681 insertions(+), 10 deletions(-) > > just to be able to sign modules. > > Normally I'd collapse writhing in laughter, but.. > > > These patches have been in use by RHEL and Fedora kernels for years, and so > > have been thoroughly tested. > > so I guess there's an argument for merging them so we can send them back to > you guys. But there's also an argument to declare all this gunk a > vendor-only thing. How much pain would that cause? it needs rediffing pretty much every time the cryptoapi changes. On a good month that means once per point release, otherwise... One argument in its favour is aparently Red Hat isn't the only vendor with something like this. I've not investigated it, but I hear rumours that suse has something similar. Having everyone using the same code would be a win for obvious reasons. 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 4/4] ipmi: add new IPMI nmi watchdog handling
Andrew Morton writes: > This is all fairly unpleasant. > > What architecture is preventing us from using DIE_NMI_POST on all > architectures which support ipmi? ia64? > > It would be better to simply require that all ipmi-using architectures > implement notify_die(DIE_NMI_POST, ...). We're starting to see IPMI creeping on powerpc as well, and we don't have an NMI. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/4] ipmi: add new IPMI nmi watchdog handling
On Wed, 14 Feb 2007 14:12:57 -0600 Corey Minyard <[EMAIL PROTECTED]> wrote: > > Convert over to the new NMI handling for getting IPMI watchdog > timeouts via an NMI. This add config options to know if there > is the ability to receive NMIs and if it has an NMI post processing > call. Then it modifies the IPMI watchdog to take advantage of > this so that it can know if an NMI comes in. > > It also adds testing that the IPMI NMI watchdog works. > > Signed-off-by: Corey Minyard <[EMAIL PROTECTED]> > > Index: linux-2.6.19-rc6/arch/i386/Kconfig.debug > === > --- linux-2.6.19-rc6.orig/arch/i386/Kconfig.debug > +++ linux-2.6.19-rc6/arch/i386/Kconfig.debug > @@ -4,6 +4,10 @@ config TRACE_IRQFLAGS_SUPPORT > bool > default y > > +config HAVE_STANDARD_NOTIFY_DIE > + bool > + default y > + This is all fairly unpleasant. What architecture is preventing us from using DIE_NMI_POST on all architectures which support ipmi? ia64? It would be better to simply require that all ipmi-using architectures implement notify_die(DIE_NMI_POST, ...). - 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] autofs4 - header file update
Hi Andrew,
The current header file definitions for autofs version 5 have
caused a couple of problems for application builds downstream.
This fixes the problem by separating the definitions.
Signed-off-by: Ian Kent <[EMAIL PROTECTED]>
Ian
---
--- linux-2.6.20/fs/autofs4/waitq.c.packet-union-redefine 2007-02-13
13:29:53.0 +0900
+++ linux-2.6.20/fs/autofs4/waitq.c 2007-02-13 13:29:59.0 +0900
@@ -84,7 +84,11 @@ static void autofs4_notify_daemon(struct
struct autofs_wait_queue *wq,
int type)
{
- union autofs_packet_union pkt;
+ union {
+ struct autofs_packet_hdr hdr;
+ union autofs_packet_union v4_pkt;
+ union autofs_v5_packet_union v5_pkt;
+ } pkt;
size_t pktsz;
DPRINTK("wait id = 0x%08lx, name = %.*s, type=%d",
@@ -98,7 +102,7 @@ static void autofs4_notify_daemon(struct
/* Kernel protocol v4 missing and expire packets */
case autofs_ptype_missing:
{
- struct autofs_packet_missing *mp = &pkt.missing;
+ struct autofs_packet_missing *mp = &pkt.v4_pkt.missing;
pktsz = sizeof(*mp);
@@ -110,7 +114,7 @@ static void autofs4_notify_daemon(struct
}
case autofs_ptype_expire_multi:
{
- struct autofs_packet_expire_multi *ep = &pkt.expire_multi;
+ struct autofs_packet_expire_multi *ep =
&pkt.v4_pkt.expire_multi;
pktsz = sizeof(*ep);
@@ -129,7 +133,7 @@ static void autofs4_notify_daemon(struct
case autofs_ptype_missing_direct:
case autofs_ptype_expire_direct:
{
- struct autofs_v5_packet *packet = &pkt.v5_packet;
+ struct autofs_v5_packet *packet = &pkt.v5_pkt.v5_packet;
pktsz = sizeof(*packet);
--- linux-2.6.20/include/linux/auto_fs4.h.packet-union-redefine 2007-02-13
13:23:20.0 +0900
+++ linux-2.6.20/include/linux/auto_fs4.h 2007-02-13 13:26:35.0
+0900
@@ -59,6 +59,13 @@ struct autofs_packet_expire_multi {
char name[NAME_MAX+1];
};
+union autofs_packet_union {
+ struct autofs_packet_hdr hdr;
+ struct autofs_packet_missing missing;
+ struct autofs_packet_expire expire;
+ struct autofs_packet_expire_multi expire_multi;
+};
+
/* autofs v5 common packet struct */
struct autofs_v5_packet {
struct autofs_packet_hdr hdr;
@@ -78,12 +85,13 @@ typedef struct autofs_v5_packet autofs_p
typedef struct autofs_v5_packet autofs_packet_missing_direct_t;
typedef struct autofs_v5_packet autofs_packet_expire_direct_t;
-union autofs_packet_union {
+union autofs_v5_packet_union {
struct autofs_packet_hdr hdr;
- struct autofs_packet_missing missing;
- struct autofs_packet_expire expire;
- struct autofs_packet_expire_multi expire_multi;
struct autofs_v5_packet v5_packet;
+ autofs_packet_missing_indirect_t missing_indirect;
+ autofs_packet_expire_indirect_t expire_indirect;
+ autofs_packet_missing_direct_t missing_direct;
+ autofs_packet_expire_direct_t expire_direct;
};
#define AUTOFS_IOC_EXPIRE_MULTI_IOW(0x93,0x66,int)
-
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: [uml-devel] x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be accepted
On Thursday 15 February 2007 03:54, Jeff Dike wrote:
> On Thu, Feb 15, 2007 at 03:34:23AM +0100, Paolo 'Blaisorblade' Giarrusso
wrote:
> > Index: linux-2.6.git/arch/x86_64/ia32/ptrace32.c
> > ===
> > --- linux-2.6.git.orig/arch/x86_64/ia32/ptrace32.c
> > +++ linux-2.6.git/arch/x86_64/ia32/ptrace32.c
> > @@ -246,6 +246,7 @@ asmlinkage long sys32_ptrace(long reques
> > case PTRACE_SINGLESTEP:
> > case PTRACE_DETACH:
> > case PTRACE_SYSCALL:
> > + case PTRACE_OLDSETOPTIONS:
> > case PTRACE_SETOPTIONS:
> > case PTRACE_SET_THREAD_AREA:
> > case PTRACE_GET_THREAD_AREA:
>
> I sent an equivalent patch in earlier today:
Doh! Interesting this timing...
> Index: linux-2.6/arch/x86_64/ia32/ptrace32.c
> ===
> --- linux-2.6.orig/arch/x86_64/ia32/ptrace32.c
> +++ linux-2.6/arch/x86_64/ia32/ptrace32.c
> @@ -239,6 +239,8 @@ asmlinkage long sys32_ptrace(long reques
> __u32 val;
>
> switch (request) {
> + case PTRACE_OLDSETOPTIONS:
> + request = PTRACE_SETOPTIONS;
> case PTRACE_TRACEME:
> case PTRACE_ATTACH:
> case PTRACE_KILL:
>
> I change the request so that PTRACE_OLDSETOPTIONS doesn't need to
> propogate any further. However, it is present in include/asm-x86_64,
> so I guess that counts as being part of the x86_64 ABI. That being
> the case, I guess my patch can be dropped in favor of this one.
It is handled in ptrace_request, unless there are include problems. I'm going
to reboot and test mine for any remaining problem.
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] MODSIGN: Kernel module signing
On Wed, 14 Feb 2007 19:09:38 + David Howells <[EMAIL PROTECTED]> wrote: > These patches provide a GPG-based kernel module signing facility. Their use > is > not fully automated within the confines of the kernel build process because it > needs provision of keys from outside of the kernel before the kernel can be > compiled. > > The patches are: > > (1) A cut-down MPI library derived from GPG with error handling added. > > (2) Permit hash algorithms to hash kernel data defined by a virtual address > and a length rather than trying to use scattergather lists (which require > struct page pointers to be determined). > > (3) Add extra information to the per-arch ELF headers to more fully describe > the format of the ELF metadata. > > (4) Add module verification capabilities, including ELF metadata > verification. > > (5) Add a generic DSA signature checker. Given a SHA1 hash of the data to be > verified and a binary blob holding a GPG signature stream, this verifies > the signature using a built-in ring of public keys. > > (6) Add a module signature checker that applies signature checking to modules > on module load, checking the signature against the ring of public keys > compiled into the kernel. Grand total: 77 files changed, 9681 insertions(+), 10 deletions(-) just to be able to sign modules. Normally I'd collapse writhing in laughter, but.. > These patches have been in use by RHEL and Fedora kernels for years, and so > have been thoroughly tested. so I guess there's an argument for merging them so we can send them back to you guys. But there's also an argument to declare all this gunk a vendor-only thing. How much pain would that cause? - 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] aio: fix kernel bug when page is temporally busy
On Wed, 14 Feb 2007 20:51:33 +0300 "Ananiev, Leonid I" <[EMAIL PROTECTED]>
wrote:
> Fix kernel bug when IO page is temporally busy:
> invalidate_inode_pages2_range() returns EIOCBRETRY but not EIO.
> invalidate_inode_pages2() returns EIO as earlier.
>
> Signed-off-by: Leonid Ananiev <[EMAIL PROTECTED]>
> ---
> --- linux-2.6.20/mm/truncate.c 2007-02-04 10:44:54.0 -0800
> +++ linux-2.6.20p/mm/truncate.c 2007-02-08 22:56:52.0 -0800
> @@ -366,7 +366,7 @@ static int do_launder_page(struct addres
> * Any pages which are found to be mapped into pagetables are unmapped prior
> to
> * invalidation.
> *
> - * Returns -EIO if any pages could not be invalidated.
> + * Returns -EIOCBRETRY if any pages could not be invalidated.
> */
> int invalidate_inode_pages2_range(struct address_space *mapping,
> pgoff_t start, pgoff_t end)
> @@ -423,7 +423,7 @@ int invalidate_inode_pages2_range(struct
> }
> ret = do_launder_page(mapping, page);
> if (ret == 0 && !invalidate_complete_page2(mapping,
> page))
> - ret = -EIO;
> + ret = -EIOCBRETRY;
> unlock_page(page);
> }
> pagevec_release(&pvec);
> @@ -444,6 +444,7 @@ EXPORT_SYMBOL_GPL(invalidate_inode_pages
> */
> int invalidate_inode_pages2(struct address_space *mapping)
> {
> - return invalidate_inode_pages2_range(mapping, 0, -1);
> + int ret = invalidate_inode_pages2_range(mapping, 0, -1);
> + return (ret < 0)?-EIO:ret;
> }
> EXPORT_SYMBOL_GPL(invalidate_inode_pages2);
If someone later uses invalidate_inode_pages2_range() elsewhere, they're
going to need to know to convert -EIOCBRETRY into -EIO, if they weren't
called by aio. Or something.
Please, tell us what problem this is fixing so that we can look into
alternative solutions.
For example, one acceptable-but-ugly solution might be to do:
static inline int invalidate_inode_pages2_range(struct address_space *mapping,
pgoff_t start, pgoff_t end)
{
return __invalidate_inode_pages2_range(mapping, start, end, 0);
}
static inline int invalidate_inode_pages2_range_for_aio(struct address_space
*mapping,
pgoff_t start, pgoff_t end)
{
return __invalidate_inode_pages2_range(mapping, start, end, 1);
}
and to then use invalidate_inode_pages2_range_for_aio() from the
appropriate callsite.
But without a complete description of the bug which this is fixing, it's
hard to say how practical such an approach would be.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix d_path for lazy unmounts
On Wednesday 14 February 2007 14:57, Andreas Gruenbacher wrote:
> [1] Always make disconnected paths relative:
>
> From all these choices, I actually like [1] best, together with hiding
> unreachable mount points in /proc/$pid/mounts and /proc/$pid/mountstats:
> there is no real point in pretending that unreachable paths are reachable;
> whichever process uses these paths is just as much in error when trying
> from the pwd as when trying from the chroot.
So here is how this could be implemented. See the lengthy explanations in the
patch headers, too.
d_path-lazy-unmounts.diff
- Now fails sys_getcwd() with -ENOENT in case the path computed
doesn't lead to the chroot.
- No longer reports empty paths, but report '.' in that case
instead.
- Incorporates Neil's other minor feedback.
no-unreachable-paths.diff
Hide unreachable mount points in /proc/mounts and /proc/$PID/mountstats.
In particular, this includes the rootfs mount for all processes that
are not chroot()ed in that mount.
Andreas
Fix __d_path() for lazy unmounts and make it unambiguous
First, when d_path() hits a lazily unmounted mount point, it tries to
prepend the name of the lazily unmounted dentry to the path name. It
gets this wrong, and also overwrites the slash that separates the name
from the following pathname component.
Second, it isn't always possible to tell from the __d_path result
whether the specified root and rootmnt (i.e., the chroot) was reached:
lazy unmounts of bind mounts will produce a path that does start with a
non-slash so we can tell from that, but other lazy unmounts will produce
a path that starts with a slash, just like "ordinary" paths.
Third, sys_getcwd() shouldn't return disconnected paths. The patch
checks for that, and makes it fail with -ENOENT in that case.
The attached patch cleans up __d_path() to fix the bug with overlapping
pathname components. It also adds a @fail_deleted argument, which allows
to get rid of some of the mess in sys_getcwd(). We make sure that paths
will only start with a slash if the path leads all the way up to the
root. If the resulting path would otherwise be empty, we return "."
instead so that some users of seq_path for files in /proc won't break.
The @fail_deleted argument allows sys_getcwd() to be simplified.
Grabbing the dcache_lock can be moved into __d_path().
The @fail_deleted argument could be added to d_path() as well: this would
allow callers to recognize deleted files without having to resort to the
ambiguous check for the " (deleted)" string at the end of the pathnames.
This is not currently done, but it might be worthwhile.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Reviewed-by: NeilBrown <[EMAIL PROTECTED]>
Index: b/fs/dcache.c
===
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1732,52 +1732,51 @@ shouldnt_be_hashed:
}
/**
- * d_path - return the path of a dentry
+ * __d_path - return the path of a dentry
* @dentry: dentry to report
* @vfsmnt: vfsmnt to which the dentry belongs
* @root: root dentry
* @rootmnt: vfsmnt to which the root dentry belongs
* @buffer: buffer to return value in
* @buflen: buffer length
+ * @fail_deleted: what to return for deleted files
*
- * Convert a dentry into an ASCII path name. If the entry has been deleted
+ * Convert a dentry into an ASCII path name. If the entry has been deleted,
+ * then if @fail_deleted is true, ERR_PTR(-ENOENT) is returned. Otherwise,
* the string " (deleted)" is appended. Note that this is ambiguous.
*
- * Returns the buffer or an error code if the path was too long.
+ * If @dentry is not connected to @root, the path returned will be relative
+ * (i.e., it will not start with a slash).
*
- * "buflen" should be positive. Caller holds the dcache_lock.
+ * Returns the buffer or an error code.
*/
-static char * __d_path( struct dentry *dentry, struct vfsmount *vfsmnt,
- struct dentry *root, struct vfsmount *rootmnt,
- char *buffer, int buflen)
-{
- char * end = buffer+buflen;
- char * retval;
- int namelen;
+static char *__d_path(struct dentry *dentry, struct vfsmount *vfsmnt,
+ struct dentry *root, struct vfsmount *rootmnt,
+ char *buffer, int buflen, int fail_deleted)
+{
+ int namelen, is_slash;
+
+ if (buflen < 2)
+ return ERR_PTR(-ENAMETOOLONG);
+ buffer += --buflen;
+ *buffer = '\0';
- *--end = '\0';
- buflen--;
+ spin_lock(&dcache_lock);
if (!IS_ROOT(dentry) && d_unhashed(dentry)) {
- buflen -= 10;
- end -= 10;
- if (buflen < 0)
+ if (fail_deleted) {
+ buffer = ERR_PTR(-ENOENT);
+ goto out;
+ }
+ if (buflen < 10)
goto Elong;
- memcpy(end, " (deleted)", 10);
+ buflen -= 10;
+ buffer -= 10;
+ memcpy(buffer, " (deleted)", 10);
}
-
- if (buflen < 1)
- goto Elong;
- /* Get '/' right */
- retval = end-1;
- *retval = '/';
-
- for (;;) {
+ while (dentry != root || vfsmnt != rootmnt) {
struct dentry * parent;
Re: x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be accepted
On Thu, Feb 15, 2007 at 03:34:23AM +0100, Paolo 'Blaisorblade' Giarrusso wrote:
> Index: linux-2.6.git/arch/x86_64/ia32/ptrace32.c
> ===
> --- linux-2.6.git.orig/arch/x86_64/ia32/ptrace32.c
> +++ linux-2.6.git/arch/x86_64/ia32/ptrace32.c
> @@ -246,6 +246,7 @@ asmlinkage long sys32_ptrace(long reques
> case PTRACE_SINGLESTEP:
> case PTRACE_DETACH:
> case PTRACE_SYSCALL:
> + case PTRACE_OLDSETOPTIONS:
> case PTRACE_SETOPTIONS:
> case PTRACE_SET_THREAD_AREA:
> case PTRACE_GET_THREAD_AREA:
>
I sent an equivalent patch in earlier today:
Index: linux-2.6/arch/x86_64/ia32/ptrace32.c
===
--- linux-2.6.orig/arch/x86_64/ia32/ptrace32.c
+++ linux-2.6/arch/x86_64/ia32/ptrace32.c
@@ -239,6 +239,8 @@ asmlinkage long sys32_ptrace(long reques
__u32 val;
switch (request) {
+ case PTRACE_OLDSETOPTIONS:
+ request = PTRACE_SETOPTIONS;
case PTRACE_TRACEME:
case PTRACE_ATTACH:
case PTRACE_KILL:
I change the request so that PTRACE_OLDSETOPTIONS doesn't need to
propogate any further. However, it is present in include/asm-x86_64,
so I guess that counts as being part of the x86_64 ABI. That being
the case, I guess my patch can be dropped in favor of this one.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 05/11] syslets: core code
But the whole point is that the notion of a "register" is wrong in
the
first place. [...]
forget about it then. The thing we "register" is dead-simple:
struct async_head_user {
struct syslet_uatom __user **completion_ring;
unsigned long ring_size_bytes;
unsigned long max_nr_threads;
};
this can be passed in to sys_async_exec() as a second pointer, and the
kernel can put the expected-completion pointer (and the user ring idx
pointer) into its struct atom. It's just a few instructions, and
only in
the cachemiss case.
that would make completions arbitrarily split-up-able. No registration
whatsoever. A waiter could specify which ring's events it is
interested
in. A 'ring' could be a single-entry thing as well, for a single
instance of pending IO.
I like this, too. (Not surprisingly, having outlined something like
it in a mail in one of the previous threads :)).
I'll bring up the POSIX AIO "list" IO case. It wants to issue a
group of IOs and sleep until they all return. Being able to cheaply
instantiate a ring implicitly with the submission of the IO calls in
the list will make implementing this almost too easy. It'd obviously
just wait for that list's ring to drain.
I hope. There might be complications around the edges (waiting for
multiple list IOs to drain?), but it seems like this would be on the
right track.
I might be alone in caring about having a less ridiculous POSIX AIO
interface in glibc, though, I'll admit. It seems like it'd be a
pretty sad missed opportunity if we rolled a fantastic general AIO
interface and left glibc to still screw around with it's own manual
threading :/.
- z
-
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 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support
I'm finally back from my travel and conference hiatus.. you guys have been busy! :) On Feb 13, 2007, at 6:20 AM, Ingo Molnar wrote: I'm pleased to announce the first release of the "Syslet" kernel feature and kernel subsystem, which provides generic asynchrous system call support: http://redhat.com/~mingo/syslet-patches/ In general, I really like the look of this. I think I'm convinced that your strong preference to do this with full kernel threads (1:1 task_struct -> thread_info/stack relationship) is the right thing to do. The fibrils fell on the side of risking bugs by sharing task_structs amongst stacks executing kernel paths. This, correct me if I'm wrong, falls on the side of risking behavioural quirks stemming from task_struct references that we happen to have not enabled sharing of yet. I have strong hopes that we won't actually *care* about the behavioural differences we get from having individual task structs (which share the important things!) between syscall handlers. The *only* seemingly significant case I've managed to find, the IO scheduler priority and context fields, is easy enough to fix up. Jens and I have been talking about that. It's been bugging him for other reasons. So, thanks, nice work. I'm going to focus on finding out if its feasible for The Database to use this instead of the current iocb mechanics. I'm optimistic. Syslets are small, simple, lightweight programs (consisting of system-calls, 'atoms') I will admit, though, that I'm not at all convinced that we need this. Adding a system call for addition (just addition? how far do we go?!) sure feels like a warning sign to me that we're heading down a slippery slope. I would rather we started with an obviously minimal syscall which just takes an array of calls and args and executes them unconditionally. But its existance doesn't stop the use case I care about. So it's hard to get *too* worked up about it. Comments, suggestions, reports are welcome! For what it's worth, it looks like 'x86-optimized-copy_uatom.patch' got some hunks that should have been in 'x86-optimized- sys_umem_add.patch'. - z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix d_path for lazy unmounts
On Sunday 04 February 2007 16:15, Neil Brown wrote: > The behaviour in the face of a lazy unmount should be clarified in > this comment. Done. > If sys_getcwd is called on a directory that is no longer > connected to the root, it isn't clear to me that it should return > without an error. > Without your patch it can return garbage which is clearly wrong. > With you patch it will return a relative path name, which is also > wrong (it isn't a valid path that leads to the current working directory). Right, it should return -ENOENT instead in that case. Fixed as well. > I would suggest that 'fail_deleted' be (e.g.) changed to > 'fail_condition' where two conditions are defined > #define DPATH_FAIL_DELETED 1 > #define DPATH_FAIL_DISCONNECTED 2 The much cleaner interface is to check if the path returned starts with a slash. If it doesn't, we know the path is bad as far as sys_getcwd() is concerned. We will construct the partial path in __d_path before figuring out that the path is disconnected, so no performance penalty, either. > In reality, you are comparing "buflen < namelen+1" but spelling it as > "buflen <= namelen". I would prefer the full spelling with least room > for confusion. I'm fine either way. > Maybe: > > + buflen -= namelen + 1; > > + buffer -= namelen + 1; > > + memcpy(buffer+1, dentry->d_name.name, namelen); > > + *buffer = '/'; That's better, yes. Thanks, Andreas - 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 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> I'm pretty certain we explicitly drop the weird GNU note that >> is automatically generated by gcc and specifies something informational. >> > But that's something else again, since it appears as a PT_GNU_STACK phdr. Not that. It's more like abi version or gcc version or something like. At least there used to be one of those notes in every .o file and compiled program. >> I don't think anything we are doing is wrong but ld gets confused easily >> in the corner cases. I'm modestly surprised we didn't have to mark our >> .note.xxx scions as ".section .note.xxx @note" or whatever the proper >> gas syntax is. > > I did try that, and it didn't make a difference. The manual says that > the output section type follows the input section type, so I agree its a > bit surprising we ever get a SHT_NOTE out of it without the @note stuff. Right. So the surprise is that SHT_NOTE got set. There are some defaults based on the section name somewhere that appear to have done the right thing. My best hunch really is that ld treated the .note sections normally and just mist the handling of the magic SHT_NOTE type. Which is why I'm not to worried. Eric - 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/
x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be accepted
Also PTRACE_OLDSETOPTIONS should be accepted, as done by kernel/ptrace.c and forced by binary compatibility. UML/32bit breaks because of this - since it is wise enough to use PTRACE_OLDSETOPTIONS to be binary compatible with 2.4 host kernels. Until 2.6.17 (commit f0f2d6536e3515b5b1b7ae97dc8f176860c8c2ce) we had: default: return sys_ptrace(request, pid, addr, data); Instead here we have: case PTRACE_GET_THREAD_AREA: case ...: return sys_ptrace(request, pid, addr, data); default: return -EINVAL; This change was a style change - when a case is added, it must be explicitly tested this way. In this case, not enough testing was done. Cc: Andi Kleen <[EMAIL PROTECTED]> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> Index: linux-2.6.git/arch/x86_64/ia32/ptrace32.c === --- linux-2.6.git.orig/arch/x86_64/ia32/ptrace32.c +++ linux-2.6.git/arch/x86_64/ia32/ptrace32.c @@ -246,6 +246,7 @@ asmlinkage long sys32_ptrace(long reques case PTRACE_SINGLESTEP: case PTRACE_DETACH: case PTRACE_SYSCALL: + case PTRACE_OLDSETOPTIONS: case PTRACE_SETOPTIONS: case PTRACE_SET_THREAD_AREA: case PTRACE_GET_THREAD_AREA: - 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/
Two unclear places in lockdep-design.txt
Hello, Ingo! Many thanks for the lockdep validator! It has helped me immensely. However, lockdep-design.txt has been pretty hard to read for me. It would be great if you find an opportunity to clarify two things in the documentation. 1) What is a lock dependency? What does "L1 -> L2" mean? Does it mean that L1 should be first or second to be acquired? 2) What is "ever held with hardirqs enabled"? Does it mean that the lock was used in the code where hardirqs were enabled, or that it _also_ didn't disable hardirqs by itself (e.g. by spin_lock_irq)? I suspect the later is the case. I wish I could submit a patch for the documentation, but I still don't understand much of the theory. Still, I was able to interpret the error messages in a way that allows me to fix the locking issues in some drivers. -- Regards, Pavel Roskin - 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 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
Eric W. Biederman wrote: > I'm pretty certain we explicitly drop the weird GNU note that > is automatically generated by gcc and specifies something informational. > But that's something else again, since it appears as a PT_GNU_STACK phdr. > I don't think anything we are doing is wrong but ld gets confused easily > in the corner cases. I'm modestly surprised we didn't have to mark our > .note.xxx scions as ".section .note.xxx @note" or whatever the proper > gas syntax is. I did try that, and it didn't make a difference. The manual says that the output section type follows the input section type, so I agree its a bit surprising we ever get a SHT_NOTE out of it without the @note stuff. J - 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 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> Reasonable and it's probably worth letting the binutils developer know. >> I do agree that it is weird. It might be that something in binutils >> doesn't like us dropping some of the notes. >> > > What do you mean by "dropping some of the notes"? I think the only > notes (at least in this case) are the Xen ones, and they're all included. I'm pretty certain we explicitly drop the weird GNU note that is automatically generated by gcc and specifies something informational. Basically into .note we include *(.note.*) but not *(.note). I don't think anything we are doing is wrong but ld gets confused easily in the corner cases. I'm modestly surprised we didn't have to mark our .note.xxx scions as ".section .note.xxx @note" or whatever the proper gas syntax is. Eric - 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/6] atl1: bump version number
From: Jay Cliburn <[EMAIL PROTECTED]> Bump the version number. Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]> --- drivers/net/atl1/atl1_main.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c index 09f3375..6567348 100644 --- a/drivers/net/atl1/atl1_main.c +++ b/drivers/net/atl1/atl1_main.c @@ -82,7 +82,7 @@ #include "atl1.h" -#define DRIVER_VERSION "2.0.6" +#define DRIVER_VERSION "2.0.7" char atl1_driver_name[] = "atl1"; static const char atl1_driver_string[] = "Attansic L1 Ethernet Network Driver"; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] atl1: add L1 device id to pci_ids, then use it
From: Chris Snook <[EMAIL PROTECTED]>
Add device id for the Attansic L1 chip to pci_ids.h, then use it.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
drivers/net/atl1/atl1_main.c |2 +-
include/linux/pci_ids.h |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index abce97e..09f3375 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -99,7 +99,7 @@ MODULE_VERSION(DRIVER_VERSION);
* atl1_pci_tbl - PCI Device ID Table
*/
static const struct pci_device_id atl1_pci_tbl[] = {
- {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, 0x1048)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATTANSIC_L1)},
/* required last entry */
{0,}
};
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 68a7be9..bd21933 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2067,6 +2067,7 @@
#define PCI_DEVICE_ID_TDI_EHCI 0x0101
#define PCI_VENDOR_ID_ATTANSIC 0x1969
+#define PCI_DEVICE_ID_ATTANSIC_L1 0x1048
#define PCI_VENDOR_ID_JMICRON 0x197B
#define PCI_DEVICE_ID_JMICRON_JMB360 0x2360
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] atl1: remove unused define
From: Chris Snook <[EMAIL PROTECTED]> Remove unused define from atl1_main.c. Signed-off-by: Chris Snook <[EMAIL PROTECTED]> Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]> --- drivers/net/atl1/atl1_main.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c index 6655640..abce97e 100644 --- a/drivers/net/atl1/atl1_main.c +++ b/drivers/net/atl1/atl1_main.c @@ -82,7 +82,6 @@ #include "atl1.h" -#define RUN_REALTIME 0 #define DRIVER_VERSION "2.0.6" char atl1_driver_name[] = "atl1"; - 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/6] scsi: megaraid_sas - update version and author info
Update version and author information. Signed-off-by: Sumant Patro <[EMAIL PROTECTED]> --- drivers/scsi/megaraid/megaraid_sas.c |8 +--- drivers/scsi/megaraid/megaraid_sas.h |6 +++--- 2 files changed, 8 insertions(+), 6 deletions(-) diff -uprN linux-feb13-new-p5/drivers/scsi/megaraid/megaraid_sas.c linux-feb13-new-p6/drivers/scsi/megaraid/megaraid_sas.c --- linux-feb13-new-p5/drivers/scsi/megaraid/megaraid_sas.c 2007-02-14 05:19:30.0 -0800 +++ linux-feb13-new-p6/drivers/scsi/megaraid/megaraid_sas.c 2007-02-14 05:19:44.0 -0800 @@ -10,11 +10,13 @@ *2 of the License, or (at your option) any later version. * * FILE: megaraid_sas.c - * Version : v00.00.03.05 + * Version : v00.00.03.10-rc1 * * Authors: - * Sreenivas Bagalkote <[EMAIL PROTECTED]> - * Sumant Patro<[EMAIL PROTECTED]> + * (email-id : [EMAIL PROTECTED]) + * Sreenivas Bagalkote + * Sumant Patro + * Bo Yang * * List of supported controllers * diff -uprN linux-feb13-new-p5/drivers/scsi/megaraid/megaraid_sas.h linux-feb13-new-p6/drivers/scsi/megaraid/megaraid_sas.h --- linux-feb13-new-p5/drivers/scsi/megaraid/megaraid_sas.h 2007-02-14 04:36:46.0 -0800 +++ linux-feb13-new-p6/drivers/scsi/megaraid/megaraid_sas.h 2007-02-14 05:04:45.0 -0800 @@ -18,9 +18,9 @@ /* * MegaRAID SAS Driver meta data */ -#define MEGASAS_VERSION"00.00.03.05" -#define MEGASAS_RELDATE"Oct 02, 2006" -#define MEGASAS_EXT_VERSION"Mon Oct 02 11:21:32 PDT 2006" +#define MEGASAS_VERSION"00.00.03.10-rc1" +#define MEGASAS_RELDATE"Feb 14, 2007" +#define MEGASAS_EXT_VERSION"Wed Feb 14 10:14:25 PST 2007" /* * Device IDs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] atl1: read MAC address from register
From: Jay Cliburn <[EMAIL PROTECTED]>
On some Asus motherboards containing the L1 NIC, the MAC address is
written by the BIOS directly to the MAC register during POST, and is
not stored in eeprom. If we don't succeed in fetching the MAC address
from eeprom or spi, try reading it directly from the MAC register.
Suggested by Xiong Huang.
And do some cleanup while we've got the hood up...
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
---
drivers/net/atl1/atl1_hw.c | 35 ---
1 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/drivers/net/atl1/atl1_hw.c b/drivers/net/atl1/atl1_hw.c
index e28707a..314dbaa 100644
--- a/drivers/net/atl1/atl1_hw.c
+++ b/drivers/net/atl1/atl1_hw.c
@@ -243,14 +243,8 @@ static int atl1_get_permanent_address(struct atl1_hw *hw)
i += 4;
}
-/*
- * The following 2 lines are the Attansic originals. Saving for posterity.
- * *(u32 *) & eth_addr[2] = LONGSWAP(addr[0]);
- * *(u16 *) & eth_addr[0] = SHORTSWAP(*(u16 *) & addr[1]);
- */
- *(u32 *) & eth_addr[2] = swab32(addr[0]);
- *(u16 *) & eth_addr[0] = swab16(*(u16 *) & addr[1]);
-
+ *(u32 *) ð_addr[2] = swab32(addr[0]);
+ *(u16 *) ð_addr[0] = swab16(*(u16 *) &addr[1]);
if (is_valid_ether_addr(eth_addr)) {
memcpy(hw->perm_mac_addr, eth_addr, ETH_ALEN);
return 0;
@@ -281,17 +275,28 @@ static int atl1_get_permanent_address(struct atl1_hw *hw)
i += 4;
}
-/*
- * The following 2 lines are the Attansic originals. Saving for posterity.
- * *(u32 *) & eth_addr[2] = LONGSWAP(addr[0]);
- * *(u16 *) & eth_addr[0] = SHORTSWAP(*(u16 *) & addr[1]);
- */
- *(u32 *) & eth_addr[2] = swab32(addr[0]);
- *(u16 *) & eth_addr[0] = swab16(*(u16 *) & addr[1]);
+ *(u32 *) ð_addr[2] = swab32(addr[0]);
+ *(u16 *) ð_addr[0] = swab16(*(u16 *) &addr[1]);
if (is_valid_ether_addr(eth_addr)) {
memcpy(hw->perm_mac_addr, eth_addr, ETH_ALEN);
return 0;
}
+
+ /*
+* On some motherboards, the MAC address is written by the
+* BIOS directly to the MAC register during POST, and is
+* not stored in eeprom. If all else thus far has failed
+* to fetch the permanent MAC address, try reading it directly.
+*/
+ addr[0] = ioread32(hw->hw_addr + REG_MAC_STA_ADDR);
+ addr[1] = ioread16(hw->hw_addr + (REG_MAC_STA_ADDR + 4));
+ *(u32 *) ð_addr[2] = swab32(addr[0]);
+ *(u16 *) ð_addr[0] = swab16(*(u16 *) &addr[1]);
+ if (is_valid_ether_addr(eth_addr)) {
+ memcpy(hw->perm_mac_addr, eth_addr, ETH_ALEN);
+ return 0;
+ }
+
return 1;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] atl1: fix bad ioread address
From: Al Viro <[EMAIL PROTECTED]> An ioread32 statement reads the wrong address. Fix it. Signed-off-by: Al Viro <[EMAIL PROTECTED]> Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]> Signed-off-by: Chris Snook <[EMAIL PROTECTED]> --- drivers/net/atl1/atl1_hw.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/atl1/atl1_hw.c b/drivers/net/atl1/atl1_hw.c index 08b2d78..e28707a 100644 --- a/drivers/net/atl1/atl1_hw.c +++ b/drivers/net/atl1/atl1_hw.c @@ -357,7 +357,7 @@ void atl1_hash_set(struct atl1_hw *hw, u32 hash_value) */ hash_reg = (hash_value >> 31) & 0x1; hash_bit = (hash_value >> 26) & 0x1F; - mta = ioread32((hw + REG_RX_HASH_TABLE) + (hash_reg << 2)); + mta = ioread32((hw->hw_addr + REG_RX_HASH_TABLE) + (hash_reg << 2)); mta |= (1 << hash_bit); iowrite32(mta, (hw->hw_addr + REG_RX_HASH_TABLE) + (hash_reg << 2)); } - 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/6] atl1: drop NET_PCI from Kconfig
From: Jay Cliburn <[EMAIL PROTECTED]> The atl1 driver doesn't need NET_PCI. Remove it from Kconfig. Noticed by Chad Sprouse. Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]> Signed-off-by: Chris Snook <[EMAIL PROTECTED]> --- drivers/net/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 0bb3c1e..1b624b4 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2350,7 +2350,7 @@ config QLA3XXX config ATL1 tristate "Attansic L1 Gigabit Ethernet support (EXPERIMENTAL)" - depends on NET_PCI && PCI && EXPERIMENTAL + depends on PCI && EXPERIMENTAL select CRC32 select MII help - 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/6] atl1: bugfix, cleanup, enhancement
Jeff, Please accept the following patchset for the atl1 network device driver. * Drop unnecessary NET_PCI config * Fix incorrect hash table address * Read MAC address from register * Remove unused define * Add Attansic L1 device id to pci_ids * Bump version number This patchset contains changes to the following files. drivers/net/Kconfig |2 +- drivers/net/atl1/atl1_hw.c | 37 + drivers/net/atl1/atl1_main.c |5 ++--- include/linux/pci_ids.h |1 + 4 files changed, 25 insertions(+), 20 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] scsi: megaraid_sas - return sync cache call with success
FW does not support SYNCHRONIZE_CACHE cmd. FW flush cache on its own.
So, we just return success from the megasas_queue_command.
Signed-off-by: Sumant Patro <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 12
1 files changed, 12 insertions(+)
diff -uprN linux-feb13-new-p4/drivers/scsi/megaraid/megaraid_sas.c
linux-feb13-new-p5/drivers/scsi/megaraid/megaraid_sas.c
--- linux-feb13-new-p4/drivers/scsi/megaraid/megaraid_sas.c 2007-02-14
04:34:31.0 -0800
+++ linux-feb13-new-p5/drivers/scsi/megaraid/megaraid_sas.c 2007-02-14
05:19:30.0 -0800
@@ -857,6 +857,18 @@ megasas_queue_command(struct scsi_cmnd *
goto out_done;
}
+ switch (scmd->cmnd[0]) {
+ case SYNCHRONIZE_CACHE:
+ /*
+* FW takes care of flush cache on its own
+* No need to send it down
+*/
+ scmd->result = DID_OK << 16;
+ goto out_done;
+ default:
+ break;
+ }
+
/* Check if we can accept cmds */
if (instance->is_busy) {
sec = (jiffies - instance->last_time) / HZ;
-
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 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support
On Wed, 14 Feb 2007, Jeremy Fitzhardinge wrote: > Davide Libenzi wrote: > >> Would this work? > >> > > > > Hopefully the API will simplify enough so that emulation will becomes > > easier. > > > > The big question in my mind is how all this stuff interacts with > signals. Can a blocked syscall atom be interrupted by a signal? If so, > what thread does it get delivered to? How does sigprocmask affect this > (is it atomic with respect to blocking atoms)? Signal context is another thing that we need to transfer to the return-to-userspace task, in case we switch. Async threads inherit that from the "main" task once they're created, but from there to the sys_async_exec syscall, userspace might have changed the signal context, and re-emerging with a different one is not an option ;) We should setup service-threds signal context, so that we can cancel them, but the implementation should be hidden to userspace (that will use sys_async_cancel - or whatever name - to do that). - 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/
[PATCH 4/6] scsi: megaraid_sas - replace pci_alloc_consitent with dma_alloc_coherent in ioctl path
Replaced pci_alloc_consistent with dma_alloc_coherent from the ioctl path.
This is to avoid situations where ioctl fails for lack of memory
(when system under heavy stress).
Signed-off-by: Sumant Patro <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff -uprN linux-feb13-new-p3/drivers/scsi/megaraid/megaraid_sas.c
linux-feb13-new-p4/drivers/scsi/megaraid/megaraid_sas.c
--- linux-feb13-new-p3/drivers/scsi/megaraid/megaraid_sas.c 2007-02-13
11:45:38.0 -0800
+++ linux-feb13-new-p4/drivers/scsi/megaraid/megaraid_sas.c 2007-02-14
04:34:31.0 -0800
@@ -2738,9 +2738,9 @@ megasas_mgmt_fw_ioctl(struct megasas_ins
* For each user buffer, create a mirror buffer and copy in
*/
for (i = 0; i < ioc->sge_count; i++) {
- kbuff_arr[i] = pci_alloc_consistent(instance->pdev,
+ kbuff_arr[i] = dma_alloc_coherent(&instance->pdev->dev,
ioc->sgl[i].iov_len,
- &buf_handle);
+ &buf_handle, GFP_KERNEL);
if (!kbuff_arr[i]) {
printk(KERN_DEBUG "megasas: Failed to alloc "
"kernel SGL buffer for IOCTL \n");
@@ -2767,8 +2767,8 @@ megasas_mgmt_fw_ioctl(struct megasas_ins
}
if (ioc->sense_len) {
- sense = pci_alloc_consistent(instance->pdev, ioc->sense_len,
-&sense_handle);
+ sense = dma_alloc_coherent(&instance->pdev->dev, ioc->sense_len,
+&sense_handle, GFP_KERNEL);
if (!sense) {
error = -ENOMEM;
goto out;
@@ -2827,12 +2827,12 @@ megasas_mgmt_fw_ioctl(struct megasas_ins
out:
if (sense) {
- pci_free_consistent(instance->pdev, ioc->sense_len,
+ dma_free_coherent(&instance->pdev->dev, ioc->sense_len,
sense, sense_handle);
}
for (i = 0; i < ioc->sge_count && kbuff_arr[i]; i++) {
- pci_free_consistent(instance->pdev,
+ dma_free_coherent(&instance->pdev->dev,
kern_sge32[i].length,
kbuff_arr[i], kern_sge32[i].phys_addr);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] scsi: megaraid_sas - throttle io if FW is busy
Checks added in megasas_queue_command to know if FW is able to process
commands within the timeout period. If number of retries is 2 or more,
the driver stops sending cmd to FW. IO is resumed when pending cmd count
reduces to 16 or 10 seconds has elapsed from the time cmds were last
sent to FW.
Signed-off-by: Sumant Patro <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 27 +
drivers/scsi/megaraid/megaraid_sas.h |3 ++
2 files changed, 30 insertions(+)
diff -uprN linux-feb13-new-p2/drivers/scsi/megaraid/megaraid_sas.c
linux-feb13-new-p3/drivers/scsi/megaraid/megaraid_sas.c
--- linux-feb13-new-p2/drivers/scsi/megaraid/megaraid_sas.c 2007-02-13
11:34:58.0 -0800
+++ linux-feb13-new-p3/drivers/scsi/megaraid/megaraid_sas.c 2007-02-13
11:45:38.0 -0800
@@ -839,6 +839,7 @@ megasas_queue_command(struct scsi_cmnd *
u32 frame_count;
struct megasas_cmd *cmd;
struct megasas_instance *instance;
+ unsigned long sec;
instance = (struct megasas_instance *)
scmd->device->host->hostdata;
@@ -856,6 +857,23 @@ megasas_queue_command(struct scsi_cmnd *
goto out_done;
}
+ /* Check if we can accept cmds */
+ if (instance->is_busy) {
+ sec = (jiffies - instance->last_time) / HZ;
+ if (sec < 10)
+ return SCSI_MLQUEUE_HOST_BUSY;
+ else {
+ instance->is_busy = 0;
+ instance->last_time = 0;
+ }
+ }
+
+ if (scmd->retries > 1) {
+ /* FW is busy */
+ instance->is_busy = 1;
+ instance->last_time = jiffies;
+ }
+
cmd = megasas_get_cmd(instance);
if (!cmd)
return SCSI_MLQUEUE_HOST_BUSY;
@@ -1200,6 +1218,7 @@ megasas_complete_cmd(struct megasas_inst
{
int exception = 0;
struct megasas_header *hdr = &cmd->frame->hdr;
+ int outstanding;
if (cmd->scmd) {
cmd->scmd->SCp.ptr = (char *)0;
@@ -1313,6 +1332,12 @@ megasas_complete_cmd(struct megasas_inst
hdr->cmd);
break;
}
+
+ if (instance->is_busy) {
+ outstanding = atomic_read(&instance->fw_outstanding);
+ if (outstanding < 17)
+ instance->is_busy = 0;
+ }
}
/**
@@ -2384,6 +2409,8 @@ megasas_probe_one(struct pci_dev *pdev,
instance->init_id = MEGASAS_DEFAULT_INIT_ID;
megasas_dbg_lvl = 0;
+ instance->is_busy = 0;
+ instance->last_time = 0;
/*
* Initialize MFI Firmware
diff -uprN linux-feb13-new-p2/drivers/scsi/megaraid/megaraid_sas.h
linux-feb13-new-p3/drivers/scsi/megaraid/megaraid_sas.h
--- linux-feb13-new-p2/drivers/scsi/megaraid/megaraid_sas.h 2007-02-13
07:22:40.0 -0800
+++ linux-feb13-new-p3/drivers/scsi/megaraid/megaraid_sas.h 2007-02-13
11:37:09.0 -0800
@@ -1102,6 +1102,9 @@ struct megasas_instance {
atomic_t fw_outstanding;
u32 hw_crit_error;
+ u8 is_busy;
+ unsigned long last_time;
+
struct megasas_instance_template *instancet;
struct tasklet_struct isr_tasklet;
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] GIT 1.5.0
Junio C Hamano wrote: > - git-blame learned a new option, --incremental, that tells it > to output the blames as they are assigned. A sample script > to use it is also included as contrib/blameview. And there are example GUI blameview (Perk GTK2), and example Emacs module for incremental git-blame, both in contib/ area. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
Eric W. Biederman wrote: > Reasonable and it's probably worth letting the binutils developer know. > I do agree that it is weird. It might be that something in binutils > doesn't like us dropping some of the notes. > What do you mean by "dropping some of the notes"? I think the only notes (at least in this case) are the Xen ones, and they're all included. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] scsi: megaraid_sas - added bios_param in scsi_host_template
Added bios_param in scsi_host_template to return disk geometry.
Signed-off-by: Sumant Patro <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 45 +
1 files changed, 45 insertions(+)
Resubmitting with following changes : ulong -> unsigned long, removed
type-casting
in size comparison of > 1Gb
diff -uprN linux-feb13-new-p1/drivers/scsi/megaraid/megaraid_sas.c
linux-feb13-new-p2/drivers/scsi/megaraid/megaraid_sas.c
--- linux-feb13-new-p1/drivers/scsi/megaraid/megaraid_sas.c 2007-02-13
07:18:39.0 -0800
+++ linux-feb13-new-p2/drivers/scsi/megaraid/megaraid_sas.c 2007-02-13
11:34:58.0 -0800
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1015,6 +1016,49 @@ static int megasas_reset_bus_host(struct
}
/**
+ * megasas_bios_param - Returns disk geometry for a disk
+ * @sdev: device handle
+ * @bdev: block device
+ * @capacity: drive capacity
+ * @geom: geometry parameters
+ */
+static int
+megasas_bios_param(struct scsi_device *sdev, struct block_device *bdev,
+sector_t capacity, int geom[])
+{
+ int heads;
+ int sectors;
+ sector_t cylinders;
+ unsigned long tmp;
+ /* Default heads (64) & sectors (32) */
+ heads = 64;
+ sectors = 32;
+
+ tmp = heads * sectors;
+ cylinders = capacity;
+
+ sector_div(cylinders, tmp);
+
+ /*
+* Handle extended translation size for logical drives > 1Gb
+*/
+
+ if (capacity >= 0x20) {
+ heads = 255;
+ sectors = 63;
+ tmp = heads*sectors;
+ cylinders = capacity;
+ sector_div(cylinders, tmp);
+ }
+
+ geom[0] = heads;
+ geom[1] = sectors;
+ geom[2] = cylinders;
+
+ return 0;
+}
+
+/**
* megasas_service_aen - Processes an event notification
* @instance: Adapter soft state
* @cmd: AEN command completed by the ISR
@@ -1054,6 +1098,7 @@ static struct scsi_host_template megasas
.eh_device_reset_handler = megasas_reset_device,
.eh_bus_reset_handler = megasas_reset_bus_host,
.eh_host_reset_handler = megasas_reset_bus_host,
+ .bios_param = megasas_bios_param,
.use_clustering = ENABLE_CLUSTERING,
};
-
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/6] scsi: megaraid_sas - donot process cmds if hw_crit_error is set
Checks if hw_crit_error is set. If it is set, we donot process commands. Checks added in megasas_queue_command and command completion routines. Signed-off-by: Sumant Patro <[EMAIL PROTECTED]> --- drivers/scsi/megaraid/megaraid_sas.c | 13 - 1 files changed, 12 insertions(+), 1 deletion(-) diff -uprN linux-feb13-orig/drivers/scsi/megaraid/megaraid_sas.c linux-feb13-new-p1/drivers/scsi/megaraid/megaraid_sas.c --- linux-feb13-orig/drivers/scsi/megaraid/megaraid_sas.c 2007-02-13 06:44:46.0 -0800 +++ linux-feb13-new-p1/drivers/scsi/megaraid/megaraid_sas.c 2007-02-13 07:18:39.0 -0800 @@ -841,6 +841,11 @@ megasas_queue_command(struct scsi_cmnd * instance = (struct megasas_instance *) scmd->device->host->hostdata; + + /* Don't process if we have already declared adapter dead */ + if (instance->hw_crit_error) + return SCSI_MLQUEUE_HOST_BUSY; + scmd->scsi_done = done; scmd->result = 0; @@ -1282,11 +1287,13 @@ megasas_deplete_reply_queue(struct megas if(instance->instancet->clear_intr(instance->reg_set)) return IRQ_NONE; + if (instance->hw_crit_error) + goto out_done; /* * Schedule the tasklet for cmd completion */ tasklet_schedule(&instance->isr_tasklet); - +out_done: return IRQ_HANDLED; } @@ -1741,6 +1748,10 @@ static void megasas_complete_cmd_dpc(uns struct megasas_cmd *cmd; struct megasas_instance *instance = (struct megasas_instance *)instance_addr; + /* If we have already declared adapter dead, donot complete cmds */ + if (instance->hw_crit_error) + return; + producer = *instance->producer; consumer = *instance->consumer; - 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 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> Ok. If that is all this may be a difference that makes no difference. >> binutils has a bad habit of looking at sections (which are fully >> optional) instead of segments on ET_EXEC and ET_DYN objects. Only >> ET_REL objects (.o files) are required to have sections. >> > > The Xen domain loader will have to be changed to deal with that, which > isn't too much of a problem. Ok. Please fix the Xen domain loader to not look at sections. It is a bug for any kind of executable loader to look at anything other then segments. > My main concern is the randomness of it, and whether it will fail in > some more harmful way on other versions of binutils. Reasonable and it's probably worth letting the binutils developer know. I do agree that it is weird. It might be that something in binutils doesn't like us dropping some of the notes. >> So I recommend for testing write a 100 line program that includes >> elf.h and reads out the note segment. If all is well we can split >> this code out. >> > > The Xen readnotes utility is essentially that. I'll hack it. Sounds good. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2/2] fs: fix nobh data leak
nobh_prepare_write leaks data similarly to how simple_prepare_write did. Fix
by not marking the page uptodate until nobh_commit_write time. Again, this
could break weird use-cases, but none appear to exist in the tree.
We can safely remove the set_page_dirty, because as the comment says,
nobh_commit_write does set_page_dirty. If a filesystem wants to allocate
backing store for a page dirtied via mmap, page_mkwrite is the suggested
approach.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/fs/buffer.c
===
--- linux-2.6.orig/fs/buffer.c
+++ linux-2.6/fs/buffer.c
@@ -2245,7 +2245,6 @@ int nobh_prepare_write(struct page *page
int i;
int ret = 0;
int is_mapped_to_disk = 1;
- int dirtied_it = 0;
if (PageMappedToDisk(page))
return 0;
@@ -2282,14 +2281,10 @@ int nobh_prepare_write(struct page *page
continue;
if (buffer_new(&map_bh) || !buffer_mapped(&map_bh)) {
kaddr = kmap_atomic(page, KM_USER0);
- if (block_start < from) {
+ if (block_start < from)
memset(kaddr+block_start, 0, from-block_start);
- dirtied_it = 1;
- }
- if (block_end > to) {
+ if (block_end > to)
memset(kaddr + to, 0, block_end - to);
- dirtied_it = 1;
- }
flush_dcache_page(page);
kunmap_atomic(kaddr, KM_USER0);
continue;
@@ -2344,17 +2339,6 @@ int nobh_prepare_write(struct page *page
if (is_mapped_to_disk)
SetPageMappedToDisk(page);
- SetPageUptodate(page);
-
- /*
-* Setting the page dirty here isn't necessary for the prepare_write
-* function - commit_write will do that. But if/when this function is
-* used within the pagefault handler to ensure that all mmapped pages
-* have backing space in the filesystem, we will need to dirty the page
-* if its contents were altered.
-*/
- if (dirtied_it)
- set_page_dirty(page);
return 0;
@@ -2384,6 +2368,7 @@ int nobh_commit_write(struct file *file,
struct inode *inode = page->mapping->host;
loff_t pos = ((loff_t)page->index << PAGE_CACHE_SHIFT) + to;
+ SetPageUptodate(page);
set_page_dirty(page);
if (pos > inode->i_size) {
i_size_write(inode, pos);
-
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 06/11] syslets: core, documentation
On 2/14/07, Benjamin LaHaise <[EMAIL PROTECTED]> wrote: My opinion of this whole thread is that it implies that our thread creation and/or context switch is too slow. If that is the case, improve those elements first. At least some of those optimizations have to be done in hardware on x86, while on other platforms are probably unnecessary. Not necessarily too slow, but too opaque in terms of system-wide impact and global flow control. Here are the four practical use cases that I have seen come up in this discussion: 1) Databases that want to parallelize I/O storms, with an emphasis on getting results that are already cache-hot immediately (not least so they don't get evicted by other I/O results); there is also room to push some of the I/O clustering and sequencing logic down into the kernel. 2) Static-content-intensive network servers, with an emphasis on servicing those requests that can be serviced promptly (to avoid a ballooning connection backlog) and avoiding duplication of I/O effort when many clients suddenly want the same cold content; the real win may be in "smart prefetch" initiated from outside the network server proper. 3) Network information gathering GUIs, which want to harvest as much information as possible for immediate display and then switch to an event-based delivery mechanism for tardy responses; these need throttling of concurrent requests (ideally, in-kernel traffic shaping by request group and destination class) and efficient cancellation of no-longer-interesting requests. 4) Document search facilities, which need all of the above (big surprise there) as well as a rich diagnostic toolset, including a practical snooping and profiling facility to guide tuning for application responsiveness. Even if threads were so cheap that you could just fire off one per I/O request, they're a poor solution to the host of flow control issues raised in these use cases. A sequential thread of execution per I/O request may be the friendliest mental model for the individual delayed I/Os, but the global traffic shaping and scheduling is a data structure problem. The right question to be asking is, what are the operations that need to be supported on the system-wide pool of pending AIOs, and on what data structure can they be implemented efficiently? For instance, can we provide an RCU priority queue implementation (perhaps based on splay trees) so that userspace can scan a coherent read-only snapshot of the structure and select candidates for cancellation, etc., without interfering with kernel completions? Or is it more important to have a three-sided query operation (characteristic of priority search trees), or perhaps a lower amortized cost bulk delete? Once you've thought through the data structure manipulation, you'll know what AIO submission / cancellation / reprioritization interfaces are practical. Then you can work on a programming model for application-level "I/O completions" that is library-friendly and allows a "fast path" optimization for the fraction of requests that can be served synchronously. Then and only then does it make sense to code-bum the asynchronous path. Not that it isn't interesting to think in advance about what stack space completions will run in and which bits of the task struct needn't be in a coherent condition; but that's probably not going to guide you to the design that meets the application needs. I know I'm teaching my grandmother to suck eggs here. But there are application programmers high up the code stack whose code makes implicit use of asynchronous I/O continuations. In addition to the GUI example I blathered about a few days ago, I have in mind Narrative Javascript's "blocking operator" and Twisted Python's Deferred. Those folks would be well served by an async I/O interface to the kernel which mates well to their language's closure/continuation facilities. If it's usable from C, that's nice too. :-) Cheers, - Michael - 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] fs: fix libfs data leak
simple_prepare_write leaks uninitialised kernel data. This happens because the
it leaves an uninitialised "hole" over the part of the page that the write is
expected to go to. This is fine, but it then marks the page uptodate, which
means a concurrent read can come in and copy the uninitialised memory into
userspace before it written to.
Fix it by simply marking it uptodate in simple_commit_write instead, after
the hole has been filled in. This could theoretically break an fs that uses
simple_prepare_write and not simple_commit_write, and that relies on the
incorrect simple_prepare_write behaviour. Luckily, none of those exists in the
tree.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/fs/libfs.c
===
--- linux-2.6.orig/fs/libfs.c
+++ linux-2.6/fs/libfs.c
@@ -335,17 +335,18 @@ int simple_prepare_write(struct file *fi
flush_dcache_page(page);
kunmap_atomic(kaddr, KM_USER0);
}
- SetPageUptodate(page);
}
return 0;
}
int simple_commit_write(struct file *file, struct page *page,
- unsigned offset, unsigned to)
+ unsigned from, unsigned to)
{
struct inode *inode = page->mapping->host;
loff_t pos = ((loff_t)page->index << PAGE_CACHE_SHIFT) + to;
+ if (!PageUptodate(page))
+ SetPageUptodate(page);
/*
* No need to use i_size_read() here, the i_size
* cannot change under us because we hold the i_mutex.
Index: linux-2.6/Documentation/filesystems/vfs.txt
===
--- linux-2.6.orig/Documentation/filesystems/vfs.txt
+++ linux-2.6/Documentation/filesystems/vfs.txt
@@ -617,6 +617,11 @@ struct address_space_operations {
In this case the prepare_write will be retried one the lock is
regained.
+ Note: the page _must not_ be marked uptodate in this function
+ (or anywhere else) unless it actually is uptodate right now. As
+ soon as a page is marked uptodate, it is possible for a concurrent
+ read(2) to copy it to userspace.
+
commit_write: If prepare_write succeeds, new data will be copied
into the page and then commit_write will be called. It will
typically update the size of the file (if appropriate) and
-
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 05/11] syslets: core code
On Wed, 14 Feb 2007, Davide Libenzi wrote:
> On Wed, 14 Feb 2007, Ingo Molnar wrote:
>
> > yeah, that's another key thing. I do plan to provide a sys_upcall()
> > syscall as well which calls a 5-parameter user-space function with a
> > special stack. (it's like a lightweight signal/event handler, without
> > any of the signal handler legacies and overhead - it's like a reverse
> > system call - a "user call". Obviously pure userspace would never use
> > sys_upcall(), unless as an act of sheer masochism.)
>
> That is exactly what I described as clets. Instead of having complex jump
> and condition interpreters on the kernel (on top of new syscalls to
> modify/increment userspace variables), you just code it in C and you pass
> the clet pointer to the kernel.
> The upcall will setup a frame, execute the clet (where jump/conditions and
> userspace variable changes happen in machine code - gcc is pretty good in
> taking care of that for us) on its return, come back through a
> sys_async_return, and go back to userspace.
So, for example, this is the setup code for the current API (and that's a
really simple one - immagine going wacko with loops and userspace varaible
changes):
static struct req *alloc_req(void)
{
/*
* Constants can be picked up by syslets via static variables:
*/
static long O_RDONLY_var = O_RDONLY;
static long FILE_BUF_SIZE_var = FILE_BUF_SIZE;
struct req *req;
if (freelist) {
req = freelist;
freelist = freelist->next_free;
req->next_free = NULL;
return req;
}
req = calloc(1, sizeof(struct req));
/*
* This is the first atom in the syslet, it opens the file:
*
* req->fd = open(req->filename, O_RDONLY);
*
* It is linked to the next read() atom.
*/
req->filename_p = req->filename;
init_atom(req, &req->open_file, __NR_sys_open,
&req->filename_p, &O_RDONLY_var, NULL, NULL, NULL, NULL,
&req->fd, SYSLET_STOP_ON_NEGATIVE, &req->read_file);
/*
* This second read() atom is linked back to itself, it skips to
* the next one on stop:
*/
req->file_buf_ptr = req->file_buf;
init_atom(req, &req->read_file, __NR_sys_read,
&req->fd, &req->file_buf_ptr, &FILE_BUF_SIZE_var,
NULL, NULL, NULL, NULL,
SYSLET_STOP_ON_NON_POSITIVE | SYSLET_SKIP_TO_NEXT_ON_STOP,
&req->read_file);
/*
* This close() atom has NULL as next, this finishes the syslet:
*/
init_atom(req, &req->close_file, __NR_sys_close,
&req->fd, NULL, NULL, NULL, NULL, NULL, NULL, 0, NULL);
return req;
}
Here's how your clet would look like:
static long main_sync_loop(ctx *c)
{
int fd;
char file_buf[FILE_BUF_SIZE+1];
if ((fd = open(c->filename, O_RDONLY)) == -1)
return -1;
while (read(fd, file_buf, FILE_BUF_SIZE) > 0)
;
close(fd);
return 0;
}
Kinda easier to code isn't it? And the cost of the upcall to schedule the
clet is widely amortized by the multple syscalls you're going to do inside
your clet.
- 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/
USB ehci problems with USRP, -71 EPROTO
Hey all,
I am having troubles connecting and interfacing to a device called a
USRP via USB which is used with GNU Radio. At one time, the setup
worked perfectly fine with no errors. Then i tried to give a regular
user permission to the USB device and everything went downhill.
Now, whenever I plugin the device sometimes I sometimes get the error:
usb 1-7: device descriptor read/all, error -71
Whenever I don't get the error, I try to proceed normally to uploading a
new image to the USRP and I get the following error from gnuradio:
write_internal_ram failed: error sending control message: Protocol error
This generates the following dmesg errors:
usb 1-7: usbfs: USBDEVFS_CONTROL failed cmd python rqt 64 rq 160 len 3
ret -71
usb 1-7: usbfs: USBDEVFS_CONTROL failed cmd python rqt 64 rq 160 len 5
ret -71
usb 1-7: usbfs: USBDEVFS_CONTROL failed cmd python rqt 64 rq 160 len 8
ret -71
usb 1-7: usbfs: USBDEVFS_CONTROL failed cmd python rqt 64 rq 160 len 3
ret -71
Another set of errors produced by gnuradio are these:
usrp_open_interface:usb_set_alt_interface: failed
could not set alt intf 0/0: Protocol error
open_nth_cmd_interface: open_cmd_interface failed
-
I was able to plug the USRP into another machine with GNU Radio and
successfully flash new firmware to it 100% successfully several times.
I cannot get a single firmware on using my machine and the USRP.
Heres what else I've tried:
- un-installing and re-installing GNU Radio
- switching USB ports on the machine
- switching USB cables
- rebuilding the kernel
- installing a newer version of udev
- using a different USRP on my machine (doesn't work)
I'm not sure what else to try... heres what I did between when it worked
and broke, trying to set the USB permissions properly:
-
I tried udev first, and created /etc/udev/rules.d/60-usrp.rules:
# USRP without loaded firmware (FX2)
BUS=="usb", SYSFS{idVendor}=="fffe", SYSFS{idProduct}=="0002",
SYSFS{bcdDevice}=="0002", GROUP="usrp", RUN+="/usr/local/bin/usrper
load_standard_bits"
BUS=="usb", SYSFS{idVendor}=="fffe", SYSFS{idProduct}=="0002",
SYSFS{bcdDevice}=="0004", GROUP="usrp", RUN+="/usr/local/bin/usrper
load_standard_bits"
# USRP with loaded firmware
BUS=="usb", SYSFS{idVendor}=="fffe", SYSFS{idProduct}=="0002",
SYSFS{bcdDevice}=="0102", GROUP="usrp"
BUS=="usb", SYSFS{idVendor}=="fffe", SYSFS{idProduct}=="0002",
SYSFS{bcdDevice}=="0104", GROUP="usrp"
-
So the other method was with hotplug, and i made /etc/hotplug/usb/usrp:
#!/bin/sh
chown root:usb "$DEVICE"
chmod ug+rw "$DEVICE"
and usrp.usermap:
usrp0x0003 0xfffe 0x0002 00 00 0 0 0 0
-
I would greatly appreciate any help and suggestions.
Thanks!
George
-
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/7] containers (V7): Add generic multi-subsystem API to containers
On 2/13/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote: Well, we already bump up reference count in fork() w/o grabbing those mutexes don't we? Also if rmdir() sees container->count to be zero, then it means no task is attached to the container. How will then a function like bc_file_charge() bump up the reference count to such a container (presuming it wanted to do so w/o manage/callback mutexes -and- that the container pointer in bc_file_charge is derived from some task in that container). I think it is safe to bump up container->count in bc_file_charge w/o grabbing manage/callback mutexes. Right, I was never suggesting that we take either of those mutexes for this operation. The spin lock in css_get() was an attempt to avoid that. But I think you're right that it was too heavyweight, and can be avoided with atomic operations. See my other email to Pavel. Are you talking about (un)bind of subsystem to/from hierararchies that have non-zero containers in them? That sounds very icky. Anyway that doesnt seem to be supported in current patches. The bind/unbind from active hierarchies is supported in the user-space API, and it's implemented for hierarchies that have no child containers. Hence it's important, at least conceptually, for the reference count to be held by the subsystem state rather than the container. Implementing a full bind/unbind for arbitrary subsystems and hierarchies will indeed be a lot of work, which is why I'm not trying to do it at this point. Paul - 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.20-git8 fails compile -- net/built-in.o __ipv6_addr_type
David Miller wrote: From: Pete Clements <[EMAIL PROTECTED]> Date: Mon, 12 Feb 2007 20:10:13 -0500 (EST) 2.6.20-git8 fails compile: CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 net/built-in.o: In function `svc_udp_recvfrom': svcsock.c:(.text+0x61be4): undefined reference to `__ipv6_addr_type' make: *** [.tmp_vmlinux1] Error 1 Chuck, you will need to somehow make CONFIG_SUNRPC "depend" upon IPV6 so that if IPV6 is modular SUNRPC can only be built modular. Otherwise the symbols won't resolve correctly. Everybody hits this problem when they add ipv6 support to something. :-) Interestingly, doing a build with ALLYESCONFIG, ALLMODCONFIG, and ALLNOCONFIG doesn't catch this type of error. I just did a copy+paste and that brought in ipv6_addr_type. So I'm not convinced it's really needed here. David, can you take a look at the code in svcsock.c right around the ipv6_addr_type() call and let me know if we can avoid that call outright? begin:vcard fn:Chuck Lever n:Lever;Chuck org:Oracle Corporation;Corporate Architecture Linux Projects Group email;internet:chuck dot lever at nospam oracle dot com title:Principal Member of Staff tel;work:+1 248 614 5091 x-mozilla-html:FALSE version:2.1 end:vcard
Re: [patch 05/11] syslets: core code
On Wed, 14 Feb 2007, Ingo Molnar wrote: > yeah, that's another key thing. I do plan to provide a sys_upcall() > syscall as well which calls a 5-parameter user-space function with a > special stack. (it's like a lightweight signal/event handler, without > any of the signal handler legacies and overhead - it's like a reverse > system call - a "user call". Obviously pure userspace would never use > sys_upcall(), unless as an act of sheer masochism.) That is exactly what I described as clets. Instead of having complex jump and condition interpreters on the kernel (on top of new syscalls to modify/increment userspace variables), you just code it in C and you pass the clet pointer to the kernel. The upcall will setup a frame, execute the clet (where jump/conditions and userspace variable changes happen in machine code - gcc is pretty good in taking care of that for us) on its return, come back through a sys_async_return, and go back to userspace. - 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 2.6.21-rc1 4/5] ehca: replace yield() by wait_for_completion()
I agree with Christoph -- the use of wait_for_completion() in a loop makes no sense. When you send a new copy of this patch without whitespace damage, please fix that up too... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
