Re: [PATCH 1/3] Introducing cpuidle: core cpuidle infrastructure
> The only differentiator that I can think of would be latency, but that seems > to be a) covered in a different tunable, and b) probably wouldn't affect > most people enough where it matters. > and for latency the kernel already has a policy thing that tracks the maximum latency allowed if we need to give the user a knob to shoot himself into the foot with that one should probably be exported instead (although I'm still convinced it's a mistake since our beloved userspace WILL abuse it in the most unimaginable ways) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [IA64] swiotlb abstraction (e.g. for Xen)
On Tue, 2007-02-13 at 07:27 +, Jan Beulich wrote: > >>> Christoph Hellwig <[EMAIL PROTECTED]> 12.02.07 18:12 >>> > >On Mon, Feb 12, 2007 at 07:30:55AM +, Jan Beulich wrote: > >> > >> As the topic says - the goal is to support Xen. But yes, I was afraid > >> someone would > >> claim this make the code look ugly. And no, I currently don't have ideas > >> to address > >> any of your comments without breaking functionality on Xen... > > > >We don't have Xen merged, and it doesn't look like we're going to get it > >soon. Also the code is only for dom0 which will take even longer. > >At this point I'm pretty sure the code is cleaner, simpler and easier to > >maintain if you just split out a xendom0swiotlb instead of messing up > >the existing code. > > We have such a file, and the purpose of the patch was to get rid of it. but the result is butt-ugly... please don't do that... that code is.. interesting enough already without all the junk added to it -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.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: [patches] [PATCH 2.6.21 review I] [4/25] x86: kernel-mode faults pollute current->thead
>Yup. How does this patch look to you? We set error_code and trap_no >for userspace faults and kernel faults which call die(). We don't set >them for kernelspace faults which are fixed up. Actually, after a second round of thinking I believe there's still more to do - your second patch missed fixing i386's do_trap() similarly to x86-64's and, vice versa, x86-64's do_general_protection() similarly to i386's. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Coding style RFC: convert "for (i=0;i
In article <[EMAIL PROTECTED]> (at Mon, 12 Feb 2007 15:47:50 -0800), Joe Perches <[EMAIL PROTECTED]> says: > Now that most of the sizeof(array)/sizeof(array[0]) > conversions have been done (there are about 800 done > and about another 130 left), perhaps it could be > useful to change the code to use a define similar > to the list_for_each > > #define list_for_each(pos, head) \ > for (pos = (head)->next; prefetch(pos->next), pos != (head); \ > pos = pos->next) > > perhaps > > #define array_for_each(index, array) \ > for ((index) = 0; (index) < ARRAY_SIZE((array)); (index)++) I dislike this; it is overkill. list_for_each etc. are for list_head etc., of structures. On the other hand, arrays are not. It is very, very obvious how to access its members. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dvb shared datastructure bug?
Hi,
while working on the last pieces of the file_ops constantification, DVB
is the small village in France that is holding the Romans at bay... but
I think I found the final flaw in it now:
*pdvbdev = dvbdev = kmalloc(sizeof(struct dvb_device), GFP_KERNEL);
if (!dvbdev) {
mutex_unlock(_register_lock);
return -ENOMEM;
}
memcpy(dvbdev, template, sizeof(struct dvb_device));
dvbdev->type = type;
dvbdev->id = id;
dvbdev->adapter = adap;
dvbdev->priv = priv;
dvbdev->fops->owner = adap->module;
this is the place in DVB that is writing to a struct file_operations.
But as with almost all such cases in the kernel, this one is buggy:
While the code nicely copies a template dvbdev, that template only has a
pointer to a *shared* fops struct, the copy doesn't help that. So this
code is overwriting the fops owner field for ALL active devices, not
just the ones the copy of the template is for
I'm lost in the maze of this part of DVB (it seems to have some magic
potion to resist me) but I was hoping some of the local citizens could
take a look at this buglet...
Greetings,
Arjan van de Ven
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via
http://www.linuxfirmwarekit.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] VM: invalidate_inode_pages2_range() shouldn't fail on page dirty...
From: Trond Myklebust <[EMAIL PROTECTED]> invalidate_inode_pages2() should not try to fix races between direct_IO and mmap(). It should only be trying to clear out pages that were dirty before the direct_IO write (see generic_file_direct_IO()). Skipping dirty pages should therefore not result in an error. Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]> --- mm/truncate.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/mm/truncate.c b/mm/truncate.c index 0f4b6d1..c3ff820 100644 --- a/mm/truncate.c +++ b/mm/truncate.c @@ -318,6 +318,8 @@ EXPORT_SYMBOL(invalidate_mapping_pages); * invalidation guarantees, and cannot afford to leave pages behind because * shrink_list() has a temp ref on them, or because they're transiently sitting * in the lru_cache_add() pagevecs. + * Note: this function just skips pages that are dirty without flagging + * an error. */ static int invalidate_complete_page2(struct address_space *mapping, struct page *page) @@ -330,7 +332,7 @@ invalidate_complete_page2(struct address write_lock_irq(>tree_lock); if (PageDirty(page)) - goto failed; + goto dirty; BUG_ON(PagePrivate(page)); __remove_from_page_cache(page); @@ -338,9 +340,9 @@ invalidate_complete_page2(struct address ClearPageUptodate(page); page_cache_release(page); /* pagecache ref */ return 1; -failed: +dirty: write_unlock_irq(>tree_lock); - return 0; + return 1; } static int do_launder_page(struct address_space *mapping, struct page *page) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Coding style RFC: convert "for (i=0;i
Joe Perches wrote: On Tue, 2007-02-13 at 15:19 +1100, Nick Piggin wrote: #define array_for_each(element, array) \ for (int __idx = 0; __idx < ARRAY_SIZE((array)); \ __idx++, (element) = &(array[__idx])) If you really wanted to introduce your loop, then please call it array_for_each_idx, or something to distinguish it. perhaps: #define array_for_each(element, array) \ for ((element) = (array); \ (element) < ((array) + ARRAY_SIZE((array))); \ (element)++) If you're going for consistency, then shouldn't this be array_for_each_entry()? #define array_for_each_index(index, array) \ for ((index) = 0; (index) < ARRAY_SIZE((array)); (index)++) -- 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/
[PATCH 1/2] VM: invalidate_inode_pages2_range() should not exit early
From: Trond Myklebust <[EMAIL PROTECTED]>
Fix invalidate_inode_pages2_range() so that it does not immediately exit
just because a single page in the specified range could not be removed.
Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
---
mm/truncate.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/truncate.c b/mm/truncate.c
index ebf3fcb..0f4b6d1 100644
--- a/mm/truncate.c
+++ b/mm/truncate.c
@@ -375,10 +375,10 @@ int invalidate_inode_pages2_range(struct
pagevec_init(, 0);
next = start;
- while (next <= end && !ret && !wrapped &&
+ while (next <= end && !wrapped &&
pagevec_lookup(, mapping, next,
min(end - next, (pgoff_t)PAGEVEC_SIZE - 1) + 1)) {
- for (i = 0; !ret && i < pagevec_count(); i++) {
+ for (i = 0; i < pagevec_count(); i++) {
struct page *page = pvec.pages[i];
pgoff_t page_index;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT] NFS client updates for 2.6.20
Hi Linus, Please pull from the repository at git pull git://git.linux-nfs.org/pub/linux/nfs-2.6.git This will update the following files through the appended changesets. Cheers, Trond fs/lockd/clntproc.c|9 +- fs/lockd/svclock.c |4 - fs/nfs/client.c| 18 +++- fs/nfs/dir.c | 37 +++- fs/nfs/direct.c|8 +- fs/nfs/getroot.c | 11 +- fs/nfs/inode.c | 50 +++ fs/nfs/internal.h |4 - fs/nfs/nfs3proc.c | 24 - fs/nfs/nfs4_fs.h |2 fs/nfs/nfs4namespace.c | 16 ++-- fs/nfs/nfs4proc.c | 60 ++--- fs/nfs/nfs4xdr.c |2 fs/nfs/proc.c | 30 --- fs/nfs/read.c | 109 +--- fs/nfs/super.c |2 fs/nfs/write.c | 91 include/linux/nfs_fs.h | 17 ++-- include/linux/nfs_xdr.h|1 include/linux/sunrpc/clnt.h|2 include/linux/sunrpc/sched.h |2 net/sunrpc/auth.c | 25 +++--- net/sunrpc/auth_gss/auth_gss.c | 52 ++- net/sunrpc/auth_gss/gss_krb5_crypto.c | 10 +- net/sunrpc/auth_gss/gss_krb5_mech.c|3 - net/sunrpc/auth_gss/gss_krb5_seal.c|2 net/sunrpc/auth_gss/gss_krb5_seqnum.c |2 net/sunrpc/auth_gss/gss_krb5_unseal.c |2 net/sunrpc/auth_gss/gss_krb5_wrap.c|4 - net/sunrpc/auth_gss/gss_mech_switch.c |6 + net/sunrpc/auth_gss/gss_spkm3_mech.c |9 +- net/sunrpc/auth_gss/gss_spkm3_seal.c | 14 ++- net/sunrpc/auth_gss/gss_spkm3_token.c | 14 ++- net/sunrpc/auth_gss/gss_spkm3_unseal.c |9 +- net/sunrpc/auth_gss/svcauth_gss.c | 11 +- net/sunrpc/auth_unix.c |9 +- net/sunrpc/cache.c |3 - net/sunrpc/clnt.c | 145 +--- net/sunrpc/pmap_clnt.c | 26 +++--- net/sunrpc/rpc_pipe.c |2 net/sunrpc/sched.c | 78 + net/sunrpc/stats.c |6 + net/sunrpc/svc.c |6 + net/sunrpc/xprt.c | 67 +-- net/sunrpc/xprtsock.c | 107 +--- 45 files changed, 476 insertions(+), 635 deletions(-) commit 43d78ef2ba5bec26d0315859e8324bfc0be23766 Author: Chuck Lever <[EMAIL PROTECTED]> Date: Tue Feb 6 18:26:11 2007 -0500 NFS: disconnect before retrying NFSv4 requests over TCP RFC3530 section 3.1.1 states an NFSv4 client MUST NOT send a request twice on the same connection unless it is the NULL procedure. Section 3.1.1 suggests that the client should disconnect and reconnect if it wants to retry a request. Implement this by adding an rpc_clnt flag that an ULP can use to specify that the underlying transport should be disconnected on a major timeout. The NFSv4 client asserts this new flag, and requests no retries after a minor retransmit timeout. Note that disconnecting on a retransmit is in general not safe to do if the RPC client does not reuse the TCP port number when reconnecting. See http://bugzilla.linux-nfs.org/show_bug.cgi?id=6 Signed-off-by: Chuck Lever <[EMAIL PROTECTED]> Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]> commit a301b14087ea1d63dbec0173a13d416cd7a9 Author: Trond Myklebust <[EMAIL PROTECTED]> Date: Tue Feb 6 11:07:15 2007 -0800 NFS: Don't use ClearPageUptodate() when writeback fails ClearPageUptodate() will just cause races here. What we really want to do is to invalidate the page cache. Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]> commit b0c4fddca2bc3967381b728732a8850de35e1b20 Author: Trond Myklebust <[EMAIL PROTECTED]> Date: Mon Feb 5 14:44:22 2007 -0800 NFS: Cleanup - avoid rereading 'jiffies' more than once in the same routine Micro-optimisations for nfs_fhget() and nfs_wcc_update_inode(). Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]> commit 3e7d950a528454ad749a264feef3c8bad3faa108 Author: Trond Myklebust <[EMAIL PROTECTED]> Date: Mon Feb 5 14:26:28 2007 -0800 NFS: Fix a wraparound issue with nfsi->cache_change_attribute Fix wraparound issue with nfsi->cache_change_attribute. If it is found to lie in the future, then update it to lie in the past. Patch based on a suggestion by Neil Brown. ..and minor micro-optimisation: avoid reading 'jiffies' more than once in nfs_update_inode(). Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]> commit
Re: /proc/acpi/ac_adapter/AC is missing after latest ACPI merge
On Tuesday 13 February 2007 07:23:15 Len Brown wrote: > On Monday 12 February 2007 13:45, Ismail Dönmez wrote: > > Hi all, > > > > After latest ACPI merge /proc/acpi/ac_adapter/AC has gone fishing : > > > > [~]> ls -al /proc/acpi/ac_adapter/ > > dr-xr-xr-x 2 root root 0 Şub 12 20:44 ADP1 > > > > [~]> ls -al /proc/acpi/ac_adapter/ADP1 > > -r--r--r-- 1 root root 0 Şub 12 20:44 state > > > > This at least breaks HAL which thinks AC is always plugged in, is this > > change intentional? > > no change intended here. > > grep CONFIG_ACPI_AC .config > > lsmod |grep ac [~/GIT/linux-2.6]> grep CONFIG_ACPI_AC .config CONFIG_ACPI_AC=y [~/GIT/linux-2.6]> lsmod|grep ac af_packet 19976 2 cpufreq_userspace 3732 0 But it looks like older kernels had only /proc/acpi/ac_adapter/ADP1 and it worked fine with HAL, maybe something in sysfs changed? Also for some reason hal-addon-acpi doesn't seem to start at all, which might be the problem. Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Coding style RFC: convert "for (i=0;i
On Mon, Feb 12, 2007 at 03:47:50PM -0800, Joe Perches wrote: > Now that most of the sizeof(array)/sizeof(array[0]) conversions have > been done (there are about 800 done and about another 130 left), > perhaps it could be useful to change the code to use a define > similar to the list_for_each > > #define list_for_each(pos, head) \ > for (pos = (head)->next; prefetch(pos->next), pos != (head); \ > pos = pos->next) > > perhaps > > #define array_for_each(index, array) \ > for ((index) = 0; (index) < ARRAY_SIZE((array)); (index)++) Could we please stop "improving" the C language? it has served us fine so far. Cheers, Muli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: AHCI - remove probing of ata2
Hello Tejun, I've tested your patch yesterday, but no luck, I can't find any difference in the resulting boot log. Please find attached an archive containing : - dmesg.2.6.20-rc7 : full dmesg with stock kernel - dmesg.patch : full dmesg with your patch included. I've also added a lspci -vvv, a cat /proc/interrupts and a cat /proc/ioports in case this could help. Also, please note that libata is complaining : ATA: abnormal status 0x7F on port 0x177 and later : ATA: abnormal status 0x7F on port 0x9807 I don't know if this is important or not. Sorry for the bad news, Regards, Paul Paul Rolland, rol(at)as2917.net ex-AS2917 Network administrator and Peering Coordinator -- Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Paul Rolland > Sent: Monday, February 12, 2007 12:19 PM > To: 'Tejun Heo' > Cc: 'Alan'; 'Robert Hancock'; 'Linux Kernel Mailing List' > Subject: RE: AHCI - remove probing of ata2 > > Hello Tejun, > > > You have a Maxtor connected to that port, right? That's caused by > > Waoh, you are using crystal ball ? :) You are right, this is a Maxtor > disk, 250 MB. If you want more details about this disk, I can send you > a complete details. > > > firmware bug. Future kernels will consider that condition as > > protocol > > violation and blacklist the drive such that NCQ is not used > on it. I > > think it can be dangerous on rare corner/error cases but > there hasn't > > been any actual report of problems caused by that, so no need > > to worry > > about it too much. If it bothers you, you can turn NCQ off > > using sysfs > > node. Take a look at FAQ section of http://linux-ata.org > > I'm just slightly worried about that, and because all this libata > stuff is quite "new", I prefer to report everything I can > see, considering > that I can test patches on this machine if people need me to do so. > So, consider this machine as some kind of playground if you have > some code you want someone to test. > > > Slightly OT, but it's generally a good idea to use LABELs to access > > filesystems. With so many ports and EH dynamics including > > hotplug, it's > > much more difficult to keep device names persistent and > remember them. > > Yes, that's what I should do, but I've never really like that stuff ;( > > > > So, 2.6.20-rc7 results are : > > > - ata2 probing still very long and delaying boot a lot, > > > > That's sil4726's config device acting weird. When reset as > a normal > > device (not PMP device), sil4726 acts as a normal ATA > device which is > > used to configure how the chip behaves. Unfortunately, the > emulation > > seems to contain some flaws and cause lots of delays as > you've seen. > > I'm attaching a patch to clear TF before IDENTIFY which > fixes similar > > IDENTIFY failures on buggy ATAPI devices. > > OK, will try this tonite (I'm sorry, this is my home comp., > and I'm at the > office right now - will tell you tomorrow). > > > > - Jmicron PATA still not working, and doesn't even detect > > the DVD-ROM on > > >the port. > > > > This problem is likely to be fixed by clearing TF before IDENTIFY. > > > > So, please test the attached patch and report the result. > > Will do, and will test more if you more that are to be tested ! > > BTW, maybe OT, but what about setting a list of people willing to test > patches together with their configurations so that they can be send > patches related to their hardware ? That could be useful to > people developing > drivers... > > Regards, > 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/ > data.tar.bz2 Description: Binary data
Re: Coding style RFC: convert "for (i=0;i
On Tue, 2007-02-13 at 15:19 +1100, Nick Piggin wrote: > >> #define array_for_each(element, array) \ > >>for (int __idx = 0; __idx < ARRAY_SIZE((array)); \ > >>__idx++, (element) = &(array[__idx])) > If you really wanted to introduce your loop, then please call it > array_for_each_idx, or something to distinguish it. perhaps: #define array_for_each(element, array) \ for ((element) = (array); \ (element) < ((array) + ARRAY_SIZE((array))); \ (element)++) #define array_for_each_index(index, array) \ for ((index) = 0; (index) < ARRAY_SIZE((array)); (index)++) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/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, , SR_TIMEOUT,
> >MAX_RETRIES);
> >
> > retries++;
> > } while (retries < 5 &&
> > (!scsi_status_is_good(the_result) ||
> > (scsi_sense_valid() &&
> >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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [IA64] swiotlb abstraction (e.g. for Xen)
>>> Christoph Hellwig <[EMAIL PROTECTED]> 12.02.07 18:12 >>> >On Mon, Feb 12, 2007 at 07:30:55AM +, Jan Beulich wrote: >> >> As the topic says - the goal is to support Xen. But yes, I was afraid >> someone would >> claim this make the code look ugly. And no, I currently don't have ideas to >> address >> any of your comments without breaking functionality on Xen... > >We don't have Xen merged, and it doesn't look like we're going to get it >soon. Also the code is only for dom0 which will take even longer. >At this point I'm pretty sure the code is cleaner, simpler and easier to >maintain if you just split out a xendom0swiotlb instead of messing up >the existing code. We have such a file, and the purpose of the patch was to get rid of it. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] (2nd try) add epoll compat code to kernel/compat.c ...
On Tue, 13 Feb 2007, Stephen Rothwell wrote:
> A better way here might be to have each 64 bit architecture define
> compat_epoll_event in its asm/compat.h and then you can just use:
>
> if (copy_from_user(, event, sizeof(user)))
> return -EFAULT;
> kernel = compat_alloc_user_space(sizeof(struct epoll_event));
> err |= __put_user(user.events, >events);
> err |= __put_user(user.data, >data);
>
> And you shouldn't need the compat routine if
> offsetof(struct compat_epoll_event, data) == offsetof(struct epoll_event,
> data).
That is *definitely* better, because at that point you can make them also
define a NEED_COMPAT_EPOLL_{CTL,WAIT}, and that code can be excluded
altogether if not needed. I simply wanted to reduce work for arch
maintainers, but I'm all for something like the above.
> OK, I have thought about this some more and I *think* the only
> architecture that needs compat_sys_epoll_ctl or compat_sys_epoll_wait is
> ia64 where the 64 bit version of struct epoll_event is different from the
> 32 bit version. On x86_64, the struct is explictly packed (so it is the
> same as the 32 bit version) and on all the other 64 bit architectures the
> alignment of the u64 is the same as the equivalent 32 bit version.
>
> Since ia64 already has its own version of these two, we only have to
> worry about epoll_pwait and then the struct epoll_event is only a problem
> for ia64.
>
> Am I right? (I have cc'd linux-arch for guidance.)
ARM-OABI also defines them, dunno why. Rmk?
- 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] fix atl1 braino
Spot the bug... Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- 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/
[RFC] [PATCH] more support for memory-less-node.
In my last posintg, mempolicy-fix-for-memory-less-node patch, there was a
discussion 'what do you consider definition of "node" as...?
I found there is no consensus. But I want to go ahead.
Before posing patch again, I'd like to discuss more.
-Kame
In my understanding, a "node" is a block of cpu, memory, devices.
and there could be cpu-only-node, memory-only-node, device-only-node...
There will be discussion. IMHO, to represent hardware configuration
as it is, this definition is very natural and flexible.
(And because my work is memory-hotplug, this definition fits me.)
"Don't support such crazy configuraton" is one of opinions.
I hear x86_64 doesn't support it and defines node as a block of memory,
It remaps cpus on memory-less-nodes to other nodes.
I know ia64 allows memory-less-node. (I don't know about ppc.)
It works well on my box (and HP's box).
If there is memory-less-node, codes which checks all nodes which have memory
should check NODE_DATA(nid)->present_pages.
But following is a bit heavy operation.
x
for_each_online_node(nid)
if (!node_present_pages(nid))
continue;
x
This patch adds a new node mask "node_memory_online_map" for nodes
which have memory.
for_each_node_mask(nid, node_memory_online_map) walks all memory-ready-nodes.
This mask is updated at node-hotplug ops.
Signed-Off-By: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
Index: linux-2.6.20/include/linux/nodemask.h
===
--- linux-2.6.20.orig/include/linux/nodemask.h 2007-02-07 17:25:54.0
+0900
+++ linux-2.6.20/include/linux/nodemask.h 2007-02-13 15:31:33.0
+0900
@@ -344,6 +344,8 @@
extern nodemask_t node_online_map;
extern nodemask_t node_possible_map;
+/* online nodes which have memory */
+extern nodemask_t node_memory_online_map;
#if MAX_NUMNODES > 1
#define num_online_nodes() nodes_weight(node_online_map)
Index: linux-2.6.20/mm/page_alloc.c
===
--- linux-2.6.20.orig/mm/page_alloc.c 2007-02-07 17:25:54.0 +0900
+++ linux-2.6.20/mm/page_alloc.c2007-02-13 15:54:04.0 +0900
@@ -54,6 +54,9 @@
EXPORT_SYMBOL(node_online_map);
nodemask_t node_possible_map __read_mostly = NODE_MASK_ALL;
EXPORT_SYMBOL(node_possible_map);
+nodemask_t node_memory_online_map __read_mostly = { { [0] = 1UL } };
+EXPORT_SYMBOL(node_memory_online_map);
+
unsigned long totalram_pages __read_mostly;
unsigned long totalreserve_pages __read_mostly;
long nr_swap_pages;
@@ -1805,6 +1808,16 @@
}
}
+static void __meminit fixup_memory_online_nodes(void)
+{
+ int nid;
+ nodes_clear(node_memory_online_map);
+ for_each_online_node(nid) {
+ if (node_present_pages(nid))
+ node_set(nid, node_memory_online_map);
+ }
+}
+
#else /* CONFIG_NUMA */
static void __meminit build_zonelists(pg_data_t *pgdat)
@@ -1851,6 +1864,10 @@
pgdat->node_zonelists[i].zlcache_ptr = NULL;
}
+static void fixup_memory_online_nodes(void)
+{
+ return;
+}
#endif /* CONFIG_NUMA */
/* return values int just for stop_machine_run() */
@@ -1862,6 +1879,7 @@
build_zonelists(NODE_DATA(nid));
build_zonelist_cache(NODE_DATA(nid));
}
+ fixup_memory_online_nodes();
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/9] Remove the TSC synchronization on SMP machines
On Mon, 2007-02-12 at 16:34 -0800, Christoph Lameter wrote: > On Fri, 2 Feb 2007, Andi Kleen wrote: > > > I've threatened to just disable RDTSC for ring 3 before, but it'll likely > > never happen because too many programs use it. > > Those programs are aware that they are fiddling around with low level > material but with this patchset we are going to have a non > monotonic time subsystem? no quite the opposite. gettimeofday() currently is NOT monotonic unfortunately. With this patchseries it actually has a better chance of becoming that... -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.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: [PATCH x86 for review II] [13/39] i386: CONFIG_PHYSICAL_ALIGN limited to 4M?
On 02/12/2007 08:38 AM, Andi Kleen wrote: From: Rene Herman <[EMAIL PROTECTED]> [ ... ] --- linux.orig/arch/i386/Kconfig +++ linux/arch/i386/Kconfig @@ -843,7 +843,7 @@ config RELOCATABLE config PHYSICAL_ALIGN hex "Alignment value to which kernel should be aligned" default "0x10" - range 0x2000 0x40 + range 0x2000 0x100 help This value puts the alignment restrictions on physical address where kernel is loaded and run from. Kernel is compiled for an Okay I guess, but in reply to this, Vivek Goyal pointed out a patch of his restoring CONFIG_PHYSICAL_START that was already in -mm instead since it seems Xen also wanted it. That does also match what I wanted it for better: http://lkml.org/lkml/2007/1/2/376 Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 v4] Fix rmmod/read/write races in /proc entries
On Sun, 11 Feb 2007 23:23:30 +0300 Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> [PATCH v4] Fix rmmod/read/write races in /proc entries
This:
static ssize_t
proc_file_write(struct file *file, const char __user *buffer,
size_t count, loff_t *ppos)
{
struct inode *inode = file->f_path.dentry->d_inode;
struct proc_dir_entry * dp;
ssize_t rv = -EIO;
dp = PDE(inode);
if (!dp->write_proc)
goto out;
spin_lock(>pde_unload_lock);
if (!dp->proc_fops)
/*
* remove_proc_entry() marked PDE as "going away".
* No new writers allowed.
*/
goto out_unlock;
versus
spin_lock(>pde_unload_lock);
/*
* Stop accepting new readers/writers. If you're dynamically
* allocating ->proc_fops, save a pointer somewhere.
*/
de->proc_fops = NULL;
/* Wait until all existing readers/writers are done. */
if (de->pde_users > 0) {
struct completion c;
init_completion();
if (!de->pde_unload_completion)
de->pde_unload_completion =
spin_unlock(>pde_unload_lock);
spin_unlock(_subdir_lock);
wait_for_completion(de->pde_unload_completion);
spin_lock(_subdir_lock);
goto continue_removing;
}
spin_unlock(>pde_unload_lock);
...
What prevents proc_file_write() from looking up and playing with this de in
?
Also... lockdep wants this:
--- a/fs/proc/generic.c~fix-rmmod-read-write-races-in-proc-entries-fix
+++ a/fs/proc/generic.c
@@ -790,9 +790,8 @@ void remove_proc_entry(const char *name,
de->proc_fops = NULL;
/* Wait until all existing readers/writers are done. */
if (de->pde_users > 0) {
- struct completion c;
+ DECLARE_COMPLETION_ONSTACK(c);
- init_completion();
if (!de->pde_unload_completion)
de->pde_unload_completion =
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 mm] cfag12864b: fix crash when built-in and no parport present
On 2/13/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Sat, 10 Feb 2007 20:51:23 +0100 Miguel Ojeda <[EMAIL PROTECTED]>
wrote:
> Andrew, Daniel who reported the crash has tested this patch and says that
it works fine avoiding it, so you can merge.
>
>
drivers-add-lcd-support-fix-crash-when-built-in-and-no-parport-present.patch
> Signed-off-by: Miguel Ojeda Sandonis <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/auxdisplay/cfag12864b.c
b/drivers/auxdisplay/cfag12864b.c
> index 889583d..cb44cb4 100644
> --- a/drivers/auxdisplay/cfag12864b.c
> +++ b/drivers/auxdisplay/cfag12864b.c
> @@ -312,6 +312,17 @@ EXPORT_SYMBOL_GPL(cfag12864b_disable);
> EXPORT_SYMBOL_GPL(cfag12864b_isenabled);
>
> /*
> + * Is the module inited?
> + */
> +
> +static unsigned char cfag12864b_inited;
> +unsigned char cfag12864b_isinited(void)
> +{
> + return cfag12864b_inited;
> +}
> +EXPORT_SYMBOL_GPL(cfag12864b_isinited);
> +
> +/*
> * Module Init & Exit
> */
>
> @@ -319,6 +330,13 @@ static int __init cfag12864b_init(void)
> {
>int ret = -EINVAL;
>
> + /* ks0108_init() must be called first */
> + if (!ks0108_isinited()) {
> + printk(KERN_ERR CFAG12864B_NAME ": ERROR: "
> + "ks0108 is not initialized\n");
> + goto none;
> + }
> +
>if (PAGE_SIZE < CFAG12864B_SIZE) {
>printk(KERN_ERR CFAG12864B_NAME ": ERROR: "
>"page size (%i) < cfag12864b size (%i)\n",
> @@ -354,6 +372,7 @@ static int __init cfag12864b_init(void)
>cfag12864b_clear();
>cfag12864b_on();
>
> + cfag12864b_inited = 1;
>return 0;
>
> cachealloced:
> diff --git a/drivers/auxdisplay/cfag12864bfb.c
b/drivers/auxdisplay/cfag12864bfb.c
> index 94765e7..66fafbb 100644
> --- a/drivers/auxdisplay/cfag12864bfb.c
> +++ b/drivers/auxdisplay/cfag12864bfb.c
> @@ -137,7 +137,14 @@ static struct platform_device *cfag12864
>
> static int __init cfag12864bfb_init(void)
> {
> - int ret;
> + int ret = -EINVAL;
> +
> + /* cfag12864b_init() must be called first */
> + if (!cfag12864b_isinited()) {
> + printk(KERN_ERR CFAG12864BFB_NAME ": ERROR: "
> + "cfag12864b is not initialized\n");
> + goto none;
> + }
>
>if (cfag12864b_enable()) {
>printk(KERN_ERR CFAG12864BFB_NAME ": ERROR: "
> @@ -162,6 +169,7 @@ static int __init cfag12864bfb_init(void
>}
>}
>
> +none:
>return ret;
> }
>
> diff --git a/drivers/auxdisplay/ks0108.c b/drivers/auxdisplay/ks0108.c
> index a637575..e6c3646 100644
> --- a/drivers/auxdisplay/ks0108.c
> +++ b/drivers/auxdisplay/ks0108.c
> @@ -111,6 +111,17 @@ EXPORT_SYMBOL_GPL(ks0108_address);
> EXPORT_SYMBOL_GPL(ks0108_page);
>
> /*
> + * Is the module inited?
> + */
> +
> +static unsigned char ks0108_inited;
> +unsigned char ks0108_isinited(void)
> +{
> + return ks0108_inited;
> +}
> +EXPORT_SYMBOL_GPL(ks0108_isinited);
> +
> +/*
> * Module Init & Exit
> */
>
> @@ -142,6 +153,7 @@ static int __init ks0108_init(void)
>goto registered;
>}
>
> + ks0108_inited = 1;
>return 0;
>
> registered:
> diff --git a/include/linux/cfag12864b.h b/include/linux/cfag12864b.h
> index 0bc45e6..1605dd8 100644
> --- a/include/linux/cfag12864b.h
> +++ b/include/linux/cfag12864b.h
> @@ -73,5 +73,10 @@ extern void cfag12864b_disable(void);
> */
> extern unsigned char cfag12864b_isenabled(void);
>
> +/*
> + * Is the module inited?
> + */
> +extern unsigned char cfag12864b_isinited(void);
> +
> #endif /* _CFAG12864B_H_ */
>
> diff --git a/include/linux/ks0108.h b/include/linux/ks0108.h
> index 8047d4b..a2c54ac 100644
> --- a/include/linux/ks0108.h
> +++ b/include/linux/ks0108.h
> @@ -43,4 +43,7 @@ extern void ks0108_address(unsigned char
> /* Set the controller's current page (0..7) */
> extern void ks0108_page(unsigned char page);
>
> +/* Is the module inited? */
> +extern unsigned char ks0108_isinited(void);
> +
> #endif /* _KS0108_H_ */
This looks hacky.
Your patch didn't include a description of the bug (please always include
such a description) so I'm not sure what's going on here. But I'm
Indeed, sorry. The patch is about "crash on CONFIG_CFAG12864B=y in
2.6.20-rc3-mm1" ( http://lkml.org/lkml/2007/1/7/118 ).
suspecting that module dependencies and appropriate choice of initcall
levels is the right way to fix whatever bug this is.
The problem comes when ks0108/cfag12864b are built-in and any parallel
port is present. ks0108_init() is called first, as it should be, but
fails to load (as there is no parallel port to use).
After that, cfag12864b_init() gets called, without knowing anything
about ks0108 failed, and calls ks0108_writecontrol(), which
dereferences an uninitialized pointer.
Init order is OK, I think. The problem is how to stop
cfag12864b_init() being called if ks0108 failed to load. modprobe does
it for us, but, how when built-in?
As anybody suggested another solution, I send that patch.
Regards,
Miguel
--
Miguel Ojeda
Re: [PATCH] knfsd: Stop NFSD writes from being broken into lots of little writes to filesystem.
NeilBrown wrote: Another nfsd patch for 2.6.21... ### Comments for Changeset When NFSD receives a write request, the data is typically in a number of 1448 byte segments and writev is used to collect them together. Unfortunately, generic_file_buffered_write passes these to the filesystem one at a time, so an e.g. 32K over-write becomes a series of partial-page writes to each page, causing the filesystem to have to pre-read those pages - wasted effort. generic_file_buffered_write handles one segment of the vector at a time as it has to pre-fault in each segment to avoid deadlocks. When writing from kernel-space (and nfsd does) this is not an issue, so generic_file_buffered_write does not need to break and iovec from nfsd into little pieces. This patch avoids the splitting when get_fs is KERNEL_DS as it is from NFSd. This issue was introduced by commit 6527c2bdf1f833cc18e8f42bd97973d583e4aa83 Cc: Nick Piggin <[EMAIL PROTECTED]> FWIW, you can put Acked-by: me there if you'd like. Thanks, Nick -- 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: [patch] mm: NUMA replicated pagecache
On Tue, Feb 13, 2007 at 07:09:24AM +0100, Nick Piggin wrote: > Hi, > > Just tinkering around with this and got something working, so I'll see > if anyone else wants to try it. (patch against 2.6.20) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] mm: NUMA replicated pagecache
Hi,
Just tinkering around with this and got something working, so I'll see
if anyone else wants to try it.
Not proposing for inclusion, but I'd be interested in comments or results.
Thanks,
Nick
--
Page-based NUMA pagecache replication.
This is a scheme for page replication replicates read-only pagecache pages
opportunistically, at pagecache lookup time (at points where we know the
page is being looked up for read only).
The page will be replicated if it resides on a different node to what the
requesting CPU is on. Also, the original page must meet some conditions:
it must be clean, uptodate, not under writeback, and not have an elevated
refcount or filesystem private data. However it is allowed to be mapped
into pagetables.
Replication is done at the pagecache level, where a replicated pagecache
(inode,offset) key will have its radix-tree entry specially tagged, and its
radix-tree page will be replaced with a descriptor. Most importantly, this
descriptor has another radix-tree which is keyed by node.
Writes into pagetables are caught by having a filemap_mkwrite function,
which collapses the replication before proceeding. After collapsing the
replication, all process page tables are unmapped, so that any processes
mapping discarded pages will refault in the correct one.
/proc/vmstat has nr_repl_pages, which is the number of _additional_ pages
replicated, beyond the first.
Status:
At the moment, this is just a fun hack I made up while my internet was
down yesterday from storms on the weekend. It is *very* unoptimised, especially
because I did not want to modify the radix-tree at all, and I didn't want to
add another page flag. I also wanted to put in a lot of debug checks to start
with. So not meant for conclusion yet, but it might be interesting to some
people to test.
Also, some of my replication interfaces and locking are a little bit awkward,
which should be cleaned up and optimised.
At the moment the code is a bit ugly, but it won't take much to make it a
completely standalone ~400 line module with just a handful of hooks into
the core mm. So if anyone really wants it, it could be quite realistic to
get into an includable form.
At some point I did take a look at Dave Hansen's page replication patch for
ideas, but didn't get far because he was doing a per-inode scheme and I was
doing per-page. No judgments on which approach is better, but I feel this
per-page patch is quite neat.
Issues:
- Not commented. I want to change the interfaces around anyway.
- Breaks filesystems that use filemap_nopage, but don't call filemap_mkwrite
(eg. XFS). Fix is trivial for most cases.
- Haven't tested NUMA yet (only tested via a hack to do per-CPU replication)
- Would like to be able to control replication via userspace, and maybe
even internally to the kernel.
- Ideally, reclaim might reclaim replicated pages preferentially, however
I aim to be _minimally_ intrusive.
- Would like to replicate PagePrivate, but filesystem may dirty page via
buffers. Any solutions? (currently should mount with 'nobh').
- Would be nice to transfer master on reclaim. This should be quite easy,
must transfer relevant flags, and only if !PagePrivate (which reclaim
takes care of).
- Replication on elevated mapcount could be racy because we don't lock
page over fault handler (but I want to, for other reasons).
- PG_replicated flag for optimisations (eg. reclaim, unreplicate range)
- optimise gang operations better (eg. PG_replicated)
- Must optimise radix-tree manipulations far far better, and handle failures
of radix-tree operations (most memory failures will be solved by replacing
element rather than delete+insert).
- Should go nicely with lockless pagecache, but haven't merged them yet.
include/linux/fs.h |1
include/linux/mm.h |1
include/linux/mm_types.h |8
include/linux/mmzone.h |1
include/linux/radix-tree.h |2
init/main.c|1
mm/filemap.c | 373 ++---
mm/internal.h |4
mm/vmscan.c| 12 +
mm/vmstat.c|1
10 files changed, 346 insertions(+), 58 deletions(-)
Index: linux-2.6/include/linux/mm_types.h
===
--- linux-2.6.orig/include/linux/mm_types.h
+++ linux-2.6/include/linux/mm_types.h
@@ -5,6 +5,8 @@
#include
#include
#include
+#include
+#include
struct address_space;
@@ -64,4 +66,10 @@ struct page {
#endif /* WANT_PAGE_VIRTUAL */
};
+struct pcache_desc {
+ struct page *master;
+ nodemask_t nodes_present;
+ struct radix_tree_root page_tree;
+};
+
#endif /* _LINUX_MM_TYPES_H */
Index: linux-2.6/include/linux/fs.h
===
--- linux-2.6.orig/include/linux/fs.h
+++ linux-2.6/include/linux/fs.h
@@ -490,6 +490,7 @@ struct block_device {
*/
#define PAGECACHE_TAG_DIRTY0
[PATCH] knfsd: Stop NFSD writes from being broken into lots of little writes to filesystem.
Another nfsd patch for 2.6.21...
### Comments for Changeset
When NFSD receives a write request, the data is typically in a number
of 1448 byte segments and writev is used to collect them together.
Unfortunately, generic_file_buffered_write passes these to the filesystem
one at a time, so an e.g. 32K over-write becomes a series of partial-page
writes to each page, causing the filesystem to have to pre-read those
pages - wasted effort.
generic_file_buffered_write handles one segment of the vector at a
time as it has to pre-fault in each segment to avoid deadlocks. When
writing from kernel-space (and nfsd does) this is not an issue, so
generic_file_buffered_write does not need to break and iovec from nfsd
into little pieces.
This patch avoids the splitting when get_fs is KERNEL_DS as it is
from NFSd.
This issue was introduced by commit 6527c2bdf1f833cc18e8f42bd97973d583e4aa83
Cc: Nick Piggin <[EMAIL PROTECTED]>
Cc: Norman Weathers <[EMAIL PROTECTED]>
Cc: Vladimir V. Saveliev <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./mm/filemap.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff .prev/mm/filemap.c ./mm/filemap.c
--- .prev/mm/filemap.c 2007-02-13 16:53:19.0 +1100
+++ ./mm/filemap.c 2007-02-13 16:52:51.0 +1100
@@ -2160,21 +2160,27 @@ generic_file_buffered_write(struct kiocb
/* Limit the size of the copy to the caller's write size */
bytes = min(bytes, count);
- /*
-* Limit the size of the copy to that of the current segment,
-* because fault_in_pages_readable() doesn't know how to walk
-* segments.
+ /* We only need to worry about prefaulting when writes are from
+* user-space. NFSd uses vfs_writev with several non-aligned
+* segments in the vector, and limiting to one segment a time is
+* a noticeable performance for re-write
*/
- bytes = min(bytes, cur_iov->iov_len - iov_base);
-
- /*
-* Bring in the user page that we will copy from _first_.
-* Otherwise there's a nasty deadlock on copying from the
-* same page as we're writing to, without it being marked
-* up-to-date.
-*/
- fault_in_pages_readable(buf, bytes);
+ if (!segment_eq(get_fs(), KERNEL_DS)) {
+ /*
+* Limit the size of the copy to that of the current
+* segment, because fault_in_pages_readable() doesn't
+* know how to walk segments.
+*/
+ bytes = min(bytes, cur_iov->iov_len - iov_base);
+ /*
+* Bring in the user page that we will copy from
+* _first_. Otherwise there's a nasty deadlock on
+* copying from the same page as we're writing to,
+* without it being marked up-to-date.
+*/
+ fault_in_pages_readable(buf, bytes);
+ }
page = __grab_cache_page(mapping,index,_page,_pvec);
if (!page) {
status = -ENOMEM;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: /proc/acpi/ac_adapter/AC is missing after latest ACPI merge
On Monday 12 February 2007 13:45, Ismail Dönmez wrote: > Hi all, > > After latest ACPI merge /proc/acpi/ac_adapter/AC has gone fishing : > > [~]> ls -al /proc/acpi/ac_adapter/ > dr-xr-xr-x 2 root root 0 Şub 12 20:44 ADP1 > > [~]> ls -al /proc/acpi/ac_adapter/ADP1 > -r--r--r-- 1 root root 0 Şub 12 20:44 state > > This at least breaks HAL which thinks AC is always plugged in, is this change > intentional? Could you please clarify what is incorrect - ADP1 name ...? Why does HAL think so? Thanks. Vladimir. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/3] 2.6.20 fix for PageUptodate memorder problem (try 3)
On Sat, Feb 10, 2007 at 11:44:55PM +0100, Martin Schwidefsky wrote: > On Sat, 2007-02-10 at 03:31 +0100, Nick Piggin wrote: > > SetNewPageUptodate does not do the S390 page_test_and_clear_dirty, so > > I'd like to make sure that's OK. > > An I/O operation on s390 will set the dirty bit for a page. That is the Oh, OK. > reason to have SetPageUptodate clear the per page dirty bit when the > page is made uptodate the first time. Otherwise we end up writing each > page back to its backing device at least once. If SetNewPageUptodate is > used on new anonymous pages exclusively I don't see a problem in > omitting the page_test_clear_dirty. Thanks for the confirmation. I'll obviously have to resend a new patchset because I made a silly paper-bag bug with this one. May I say that the s390 specific part of the change is acked-by: you? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc5 1/1] MM: enhance Linux swap subsystem
You can apply my previous patch on 2.6.20 by changing
-#define VM_PURE_PRIVATE0x0400 /* Is the vma is only belonging
to a mm,
to
+#define VM_PURE_PRIVATE0x0800 /* Is the vma is only belonging
to a mm,
New revision is based on 2.6.20 with my previous patch, major changelogs are
1) pte_unmap pairs on shrink_pvma_scan_ptes and pps_swapoff_scan_ptes.
2) Now, kppsd can be woke up by kswapd.
3) New global variable accelerate_kppsd is appended to accelerate the
reclamation process when a memory inode is low.
Signed-off-by: Yunfeng Zhang <[EMAIL PROTECTED]>
Index: linux-2.6.19/Documentation/vm_pps.txt
===
--- linux-2.6.19.orig/Documentation/vm_pps.txt 2007-02-12
12:45:07.0 +0800
+++ linux-2.6.19/Documentation/vm_pps.txt 2007-02-12 15:30:16.490797672
+0800
@@ -143,23 +143,32 @@
2) mm/memory.c do_wp_page, handle_pte_fault::unmapped_pte, do_anonymous_page,
do_swap_page (page-fault)
3) mm/memory.c get_user_pages (sometimes core need share PrivatePage with us)
+4) mm/vmscan.c balance_pgdat (kswapd/x can do stage 5 of its node pages,
+ while kppsd can do stage 1-4)
+5) mm/vmscan.c kppsd (new core daemon -- kppsd, see below)
There isn't new lock order defined in pps, that is, it's compliable to Linux
-lock order.
+lock order. Locks in shrink_private_vma copied from shrink_list of 2.6.16.29
+(my initial version).
// }])>
// Others about pps <([{
A new kernel thread -- kppsd is introduced in mm/vmscan.c, its task is to
-execute the stages of pps periodically, note an appropriate timeout ticks is
-necessary so we can give application a chance to re-map back its PrivatePage
-from UnmappedPTE to PTE, that is, show their conglomeration affinity.
-
-kppsd can be controlled by new fields -- scan_control::may_reclaim/reclaim_node
-may_reclaim = 1 means starting reclamation (stage 5). reclaim_node = (node
-number) is used when a memory node is low. Caller should set them to wakeup_sc,
-then wake up kppsd (vmscan.c:balance_pgdat). Note, if kppsd is started due to
-timeout, it doesn't do stage 5 at all (vmscan.c:kppsd). Other alive legacy
-fields are gfp_mask, may_writepage and may_swap.
+execute the stage 1 - 4 of pps periodically, note an appropriate timeout ticks
+(current 2 seconds) is necessary so we can give application a chance to re-map
+back its PrivatePage from UnmappedPTE to PTE, that is, show their
+conglomeration affinity.
+
+shrink_private_vma can be controlled by new fields -- may_reclaim, reclaim_node
+and is_kppsd of scan_control. may_reclaim = 1 means starting reclamation
+(stage 5). reclaim_node = (node number, -1 means all memory inode) is used when
+a memory node is low. Caller (kswapd/x), typically, set reclaim_node to start
+shrink_private_vma (vmscan.c:balance_pgdat). Note, only to kppsd is_kppsd = 1.
+Other alive legacy fields to pps are gfp_mask, may_writepage and may_swap.
+
+When a memory inode is low, kswapd/x can wake up kppsd by increasing global
+variable accelerate_kppsd (balance_pgdat), which accelerate stage 1 - 4, and
+call shrink_private_vma to do stage 5.
PPS statistic data is appended to /proc/meminfo entry, its prototype is in
include/linux/mm.h.
Index: linux-2.6.19/mm/swapfile.c
===
--- linux-2.6.19.orig/mm/swapfile.c 2007-02-12 12:45:07.0 +0800
+++ linux-2.6.19/mm/swapfile.c 2007-02-12 12:45:21.0 +0800
@@ -569,6 +569,7 @@
}
}
} while (pte++, addr += PAGE_SIZE, addr != end);
+ pte_unmap(pte);
return 0;
}
Index: linux-2.6.19/mm/vmscan.c
===
--- linux-2.6.19.orig/mm/vmscan.c 2007-02-12 12:45:07.0 +0800
+++ linux-2.6.19/mm/vmscan.c2007-02-12 15:48:59.217292888 +0800
@@ -70,6 +70,7 @@
/* pps control command. See Documentation/vm_pps.txt. */
int may_reclaim;
int reclaim_node;
+ int is_kppsd;
};
/*
@@ -1101,9 +1102,9 @@
return ret;
}
-// pps fields.
+// pps fields, see Documentation/vm_pps.txt.
static wait_queue_head_t kppsd_wait;
-static struct scan_control wakeup_sc;
+static int accelerate_kppsd = 0;
struct pps_info pps_info = {
.total = ATOMIC_INIT(0),
.pte_count = ATOMIC_INIT(0), // stage 1 and 2.
@@ -1118,24 +1119,22 @@
struct page* pages[MAX_SERIES_LENGTH];
int series_length;
int series_stage;
-} series;
+};
-static int get_series_stage(pte_t* pte, int index)
+static int get_series_stage(struct series_t* series, pte_t* pte, int index)
{
- series.orig_ptes[index] = *pte;
- series.ptes[index] = pte;
- if (pte_present(series.orig_ptes[index])) {
- struct page* page =
pfn_to_page(pte_pfn(series.orig_ptes[index]));
- series.pages[index] = page;
+ series->orig_ptes[index] = *pte;
+
Re: [PATCH 1/7] containers (V7): Generic container system abstracted from cpusets code
On Mon, Feb 12, 2007 at 11:46:20AM -0800, Paul Menage wrote: > On further reflection, this probably would be safe after all. Since we > don't call put_container_group() in attach_task() until after > synchronize_rcu() completes, that implies that a container_group_get() > from the RCU section would have already completed. So we should be > fine. Right. Which make me wonder why we need task_lock() at all ..I can understand the need for a lock like that if we are reading/updating multiple words in task_struct under the lock. In this case, it is used to read/write just one pointer, isnt it? I think it can be eliminated all-together with the use of RCU. -- Regards, vatsa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Experimental driver for Ricoh Bay1Controller SD Card readers
Sascha Sommer wrote: > I still consider this driver experimental, but without documentation this is > probably not going to change anytime soon. > The question is now what I should do with the driver? > Is it worth to be included in the kernel? If yes where and against what > kernelversion should I send the patch? > > That's up to you. The most important thing for any part of the kernel is that it must have a maintainer. So if you are ready to keep the driver up to date and handle the support requests that show, then you should really submit it. Patches should always be sent against the current version of the kernel (i.e. git HEAD). Usually the latest packaged release will also do. (Note that I haven't had time to review your latest version of the driver) 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: [PATCH mm] cfag12864b: fix crash when built-in and no parport present
On Sat, 10 Feb 2007 20:51:23 +0100 Miguel Ojeda <[EMAIL PROTECTED]> wrote:
> Andrew, Daniel who reported the crash has tested this patch and says that it
> works fine avoiding it, so you can merge.
>
> drivers-add-lcd-support-fix-crash-when-built-in-and-no-parport-present.patch
> Signed-off-by: Miguel Ojeda Sandonis <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/auxdisplay/cfag12864b.c b/drivers/auxdisplay/cfag12864b.c
> index 889583d..cb44cb4 100644
> --- a/drivers/auxdisplay/cfag12864b.c
> +++ b/drivers/auxdisplay/cfag12864b.c
> @@ -312,6 +312,17 @@ EXPORT_SYMBOL_GPL(cfag12864b_disable);
> EXPORT_SYMBOL_GPL(cfag12864b_isenabled);
>
> /*
> + * Is the module inited?
> + */
> +
> +static unsigned char cfag12864b_inited;
> +unsigned char cfag12864b_isinited(void)
> +{
> + return cfag12864b_inited;
> +}
> +EXPORT_SYMBOL_GPL(cfag12864b_isinited);
> +
> +/*
> * Module Init & Exit
> */
>
> @@ -319,6 +330,13 @@ static int __init cfag12864b_init(void)
> {
> int ret = -EINVAL;
>
> + /* ks0108_init() must be called first */
> + if (!ks0108_isinited()) {
> + printk(KERN_ERR CFAG12864B_NAME ": ERROR: "
> + "ks0108 is not initialized\n");
> + goto none;
> + }
> +
> if (PAGE_SIZE < CFAG12864B_SIZE) {
> printk(KERN_ERR CFAG12864B_NAME ": ERROR: "
> "page size (%i) < cfag12864b size (%i)\n",
> @@ -354,6 +372,7 @@ static int __init cfag12864b_init(void)
> cfag12864b_clear();
> cfag12864b_on();
>
> + cfag12864b_inited = 1;
> return 0;
>
> cachealloced:
> diff --git a/drivers/auxdisplay/cfag12864bfb.c
> b/drivers/auxdisplay/cfag12864bfb.c
> index 94765e7..66fafbb 100644
> --- a/drivers/auxdisplay/cfag12864bfb.c
> +++ b/drivers/auxdisplay/cfag12864bfb.c
> @@ -137,7 +137,14 @@ static struct platform_device *cfag12864
>
> static int __init cfag12864bfb_init(void)
> {
> - int ret;
> + int ret = -EINVAL;
> +
> + /* cfag12864b_init() must be called first */
> + if (!cfag12864b_isinited()) {
> + printk(KERN_ERR CFAG12864BFB_NAME ": ERROR: "
> + "cfag12864b is not initialized\n");
> + goto none;
> + }
>
> if (cfag12864b_enable()) {
> printk(KERN_ERR CFAG12864BFB_NAME ": ERROR: "
> @@ -162,6 +169,7 @@ static int __init cfag12864bfb_init(void
> }
> }
>
> +none:
> return ret;
> }
>
> diff --git a/drivers/auxdisplay/ks0108.c b/drivers/auxdisplay/ks0108.c
> index a637575..e6c3646 100644
> --- a/drivers/auxdisplay/ks0108.c
> +++ b/drivers/auxdisplay/ks0108.c
> @@ -111,6 +111,17 @@ EXPORT_SYMBOL_GPL(ks0108_address);
> EXPORT_SYMBOL_GPL(ks0108_page);
>
> /*
> + * Is the module inited?
> + */
> +
> +static unsigned char ks0108_inited;
> +unsigned char ks0108_isinited(void)
> +{
> + return ks0108_inited;
> +}
> +EXPORT_SYMBOL_GPL(ks0108_isinited);
> +
> +/*
> * Module Init & Exit
> */
>
> @@ -142,6 +153,7 @@ static int __init ks0108_init(void)
> goto registered;
> }
>
> + ks0108_inited = 1;
> return 0;
>
> registered:
> diff --git a/include/linux/cfag12864b.h b/include/linux/cfag12864b.h
> index 0bc45e6..1605dd8 100644
> --- a/include/linux/cfag12864b.h
> +++ b/include/linux/cfag12864b.h
> @@ -73,5 +73,10 @@ extern void cfag12864b_disable(void);
> */
> extern unsigned char cfag12864b_isenabled(void);
>
> +/*
> + * Is the module inited?
> + */
> +extern unsigned char cfag12864b_isinited(void);
> +
> #endif /* _CFAG12864B_H_ */
>
> diff --git a/include/linux/ks0108.h b/include/linux/ks0108.h
> index 8047d4b..a2c54ac 100644
> --- a/include/linux/ks0108.h
> +++ b/include/linux/ks0108.h
> @@ -43,4 +43,7 @@ extern void ks0108_address(unsigned char
> /* Set the controller's current page (0..7) */
> extern void ks0108_page(unsigned char page);
>
> +/* Is the module inited? */
> +extern unsigned char ks0108_isinited(void);
> +
> #endif /* _KS0108_H_ */
This looks hacky.
Your patch didn't include a description of the bug (please always include
such a description) so I'm not sure what's going on here. But I'm
suspecting that module dependencies and appropriate choice of initcall
levels is the right way to fix whatever bug this is.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: /proc/acpi/ac_adapter/AC is missing after latest ACPI merge
On Monday 12 February 2007 13:45, Ismail Dönmez wrote: > Hi all, > > After latest ACPI merge /proc/acpi/ac_adapter/AC has gone fishing : > > [~]> ls -al /proc/acpi/ac_adapter/ > dr-xr-xr-x 2 root root 0 Şub 12 20:44 ADP1 > > [~]> ls -al /proc/acpi/ac_adapter/ADP1 > -r--r--r-- 1 root root 0 Şub 12 20:44 state > > This at least breaks HAL which thinks AC is always plugged in, is this change > intentional? no change intended here. grep CONFIG_ACPI_AC .config lsmod |grep ac cheers, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [take35 0/10] kevent: Generic event handling mechanism.
On Mon, Feb 12, 2007 at 09:13:35AM -0800, Andrew Morton ([EMAIL PROTECTED]) wrote: > > On Mon, 12 Feb 2007 13:35:10 +0300 Evgeniy Polyakov <[EMAIL PROTECTED]> > > wrote: > > Andrew, do you consider kevent for inclusion or declining? > > I haven't had time to think about it in the past month or two, sorry. > > However we might as well get it back in there for review-and-test - please > send a new patchset once 2.6.21-rc1 is released and copy me on it? Ok, I will. You are always in copy for kevent patchsets. -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 12/22] elevate write count files are open()ed
On Fri, 09 Feb 2007 14:53:37 -0800 Dave Hansen <[EMAIL PROTECTED]> wrote:
> diff -puN fs/file_table.c~14-24-tricky-elevate-write-count-files-are-open-ed
> fs/file_table.c
> --- lxc/fs/file_table.c~14-24-tricky-elevate-write-count-files-are-open-ed
> 2007-02-09 14:26:54.0 -0800
> +++ lxc-dave/fs/file_table.c 2007-02-09 14:26:54.0 -0800
> @@ -209,8 +209,11 @@ void fastcall __fput(struct file *file)
> if (unlikely(S_ISCHR(inode->i_mode) && inode->i_cdev != NULL))
> cdev_put(inode->i_cdev);
> fops_put(file->f_op);
> - if (file->f_mode & FMODE_WRITE)
> + if (file->f_mode & FMODE_WRITE) {
> put_write_access(inode);
> + if(!special_file(inode->i_mode))
> + mnt_drop_write(mnt);
> + }
> put_pid(file->f_owner.pid);
> put_user_ns(file->f_owner.user_ns);
> file_kill(file);
> diff -puN fs/namei.c~14-24-tricky-elevate-write-count-files-are-open-ed
> fs/namei.c
> --- lxc/fs/namei.c~14-24-tricky-elevate-write-count-files-are-open-ed
> 2007-02-09 14:26:54.0 -0800
> +++ lxc-dave/fs/namei.c 2007-02-09 14:26:54.0 -0800
> @@ -1548,8 +1548,17 @@ int may_open(struct nameidata *nd, int a
> return -EACCES;
>
> flag &= ~O_TRUNC;
> - } else if (IS_RDONLY(inode) && (flag & FMODE_WRITE))
> - return -EROFS;
> + } else if (flag & FMODE_WRITE) {
> + /*
> + * effectively: !special_file()
> + * balanced by __fput()
> + */
> + error = mnt_want_write(nd->mnt);
> + if (error)
> + return error;
> + if (IS_RDONLY(inode))
> + return -EROFS;
> + }
yipes. A new mount-wide spin_lock/unlock for each for-writing open() and
close().
Can we have a microbenchmark on this please?
Are you sure that fget_light() and fput_light() don't accidentally bypass this
new logic?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/7] cleanup: make disable_acpi() valid w/o CONFIG_ACPI
Applied.
thanks,
-Len
On Sunday 11 February 2007 22:39, Rusty Russell wrote:
> Len Brown <[EMAIL PROTECTED]> said:
> > Okay, but better to use disable_acpi()
> > indeed, since this would be the first code not already inside CONFIG_ACPI
> > to invoke disable_acpi(), we could define the inline as empty and you could
> > then scratch the #ifdef too.
>
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
>
> ===
> --- a/include/asm-i386/acpi.h
> +++ b/include/asm-i386/acpi.h
> @@ -127,6 +127,7 @@ extern int acpi_irq_balance_set(char *st
> #define acpi_ioapic 0
> static inline void acpi_noirq_set(void) { }
> static inline void acpi_disable_pci(void) { }
> +static inline void disable_acpi(void) { }
>
> #endif /* !CONFIG_ACPI */
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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: [take35 0/10] kevent: Generic event handling mechanism.
On Mon, Feb 12, 2007 at 06:59:17AM -0800, Ulrich Drepper ([EMAIL PROTECTED]) wrote: > Evgeniy Polyakov wrote: > > I think that mean that everybody is happy with APi, design and set of > > features. > > No comment means that I still have not been able to test anything since > regardless of what version I tried, it failed to build. I think if you would provide error message you saw, I fixed that in a couple of moments, doesn't it? I will send new patchset next week when rc1 will be out and your feedback is greatly appreciated. > -- > ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ > -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/3, resend] kbuild: correctly skip tilded backups in localversion files
[] > > The old code did the same thing, but with the "make" $(sort ..) function, > > which apparently removes duplicates. We should use "sort -u" here. > > Heh. Why one ever going to bloat $(srctree) to add more "dontdiff" and > such, where build is supporting dirty output? I mean, all by-hand modifications must be in the $(srctree) (let's get this term), $(objtree) is output *only*. Thus, i would propose to remove it from the path. Even dynamic SCM mechanism of adding local version doesn't use `localversion' files. > any reasons to have multiple files for localversion(s), in $(objtree) > also? Exept one, that somebody used to use it, mm-tree doesn't btw. I know it maybe another my "change it all" proposition, but i can't find nothing against `GNU $(wildcard ..)' and `unnecessarily complex "find"'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] (2nd try) add epoll compat code to kernel/compat.c ...
Hi Davide,
[Linux-arch readers can skip to the last few paragraphs ...]
Just a couple of nits to start:
On Sun, 11 Feb 2007 16:24:30 -0800 (PST) Davide Libenzi
wrote:
>
> diff -Nru linux-2.6.20/fs/eventpoll.c linux-2.6.20.mod/fs/eventpoll.c
> --- linux-2.6.20/fs/eventpoll.c 2007-02-04 10:44:54.0 -0800
> +++ linux-2.6.20.mod/fs/eventpoll.c 2007-02-11 15:26:07.0 -0800
The changes to this file are just white space. Don't include it with
this patch (if at all).
> diff -Nru linux-2.6.20/include/linux/compat.h
> linux-2.6.20.mod/include/linux/compat.h
> --- linux-2.6.20/include/linux/compat.h 2007-02-09 16:14:20.0
> -0800
> +++ linux-2.6.20.mod/include/linux/compat.h 2007-02-11 16:11:37.0
> -0800
> @@ -234,5 +234,35 @@
> compat_ulong_t maxnode, const compat_ulong_t __user *old_nodes,
> const compat_ulong_t __user *new_nodes);
>
> +/*
> + * epoll (fs/eventpoll.c) compat bits follow ...
> + */
> +struct epoll_event;
> +
> +struct compat_epoll_event {
> + u32 events;
> + u32 data[2];
> +};
> +
> +asmlinkage long compat_sys_epoll_ctl(int epfd, int op, int fd,
> + struct compat_epoll_event __user *event);
> +asmlinkage long compat_sys_epoll_wait(int epfd, struct compat_epoll_event
> __user *events,
> + int maxevents, int timeout);
> +/*
> + * Architectures that does not need "struct epoll_event" translation
should be "do"
> + * should wire compat_sys_epoll_pwait. The ones that needs "struct
> epoll_event"
^
should be "need"
Sorry for the grammar lesson.
> + * translation, should wire compat_sys_epoll_pwait2. An architecture needs
> + * "struct epoll_event" translation is alignof(u64) in 32 bits mode is 4, and
^^
should be "if" and we normally say "32 bit mode"
> + * alignof(u64) in 64 bits mode is 8.
"64 bit mode"
> +asmlinkage long compat_sys_epoll_pwait2(int epfd, struct compat_epoll_event
> __user *events,
Try to stay less than 80 columns wide.
> diff -Nru linux-2.6.20/kernel/compat.c linux-2.6.20.mod/kernel/compat.c
> --- linux-2.6.20/kernel/compat.c 2007-02-04 10:44:54.0 -0800
> +++ linux-2.6.20.mod/kernel/compat.c 2007-02-11 16:11:01.0 -0800
> +asmlinkage long compat_sys_epoll_ctl(int epfd, int op, int fd,
> + struct compat_epoll_event __user *event)
> +{
> + long err = 0;
> + struct compat_epoll_event user;
> + struct epoll_event __user *kernel = NULL;
> + union {
> + u64 q;
> + u32 d[2];
> + } mux;
> +
> + if (event) {
> + if (copy_from_user(, event, sizeof(user)))
> + return -EFAULT;
> + kernel = compat_alloc_user_space(sizeof(struct epoll_event));
> + err |= __put_user(user.events, >events);
> + mux.d[0] = user.data[0];
> + mux.d[1] = user.data[1];
> + err |= __put_user(mux.q, >data);
A better way here might be to have each 64 bit architecture define
compat_epoll_event in its asm/compat.h and then you can just use:
if (copy_from_user(, event, sizeof(user)))
return -EFAULT;
kernel = compat_alloc_user_space(sizeof(struct epoll_event));
err |= __put_user(user.events, >events);
err |= __put_user(user.data, >data);
And you shouldn't need the compat routine if
offsetof(struct compat_epoll_event, data) == offsetof(struct epoll_event, data).
> +asmlinkage long compat_sys_epoll_wait(int epfd, struct compat_epoll_event
> __user *events,
> + int maxevents, int timeout)
> +{
> + long i, ret, err = 0;
> + struct epoll_event __user *kbuf;
> + struct epoll_event ev;
> + union {
> + u64 q;
> + u32 d[2];
> + } mux;
> +
> + if (maxevents <= 0 || maxevents > (INT_MAX / sizeof(struct
> epoll_event)))
> + return -EINVAL;
> + kbuf = compat_alloc_user_space(sizeof(struct epoll_event) * maxevents);
> + ret = sys_epoll_wait(epfd, kbuf, maxevents, timeout);
> + for (i = 0; i < ret; i++) {
> + err |= __get_user(ev.events, [i].events);
> + err |= __get_user(ev.data, [i].data);
> + err |= put_user(ev.events, >events);
> + mux.q = ev.data;
> + err |= put_user(mux.d[0], >data[0]);
> + err |= put_user(mux.d[1], >data[1]);
> + events++;
> + }
Similarly here.
OK, I have thought about this some more and I *think* the only
architecture that needs compat_sys_epoll_ctl or compat_sys_epoll_wait is
ia64 where the 64 bit version of struct epoll_event is different from the
32 bit version. On x86_64, the struct is explictly packed (so it is the
same as the 32 bit version) and on all the
Re: 2.6.20-git8 fails compile -- net/built-in.o __ipv6_addr_type
From: Neil Brown <[EMAIL PROTECTED]> Date: Tue, 13 Feb 2007 13:52:26 +1100 > On Monday February 12, [EMAIL PROTECTED] wrote: > > Quoting YOSHIFUJIHideaki/=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= > > > In article <[EMAIL PROTECTED]> (at Mon, 12 Feb 2007 18:12:16 -0800), > > Andrew Morton <[EMAIL PROTECTED]> says: > > > > > > > > On Mon, 12 Feb 2007 20:10:13 -0500 (EST) Pete Clements <[EMAIL > > PROTECTED]> wrote: > > > > > 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 > > > > > > > Hmmm. > > > CONFIG_IPV6=m > combined with > > CONFIG_SUNRPC=y > > is a combination that isn't going to work at the moment > > Options? > > - Move __ipv6_addr_type to lib/ ?? > Might not work for modules. > - Disallow that combination in the .config. > .. a bit harsh. > - Only include IPv6 support in SUNRPC is a module or IPV6 is built-in > A bit of a kludge.. > > Chuck? Any ideas? Make the proper dependencies, so that SUNRPC is only possibly built modular is IPV6 is modular, that's the correct way to do this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
From: Andrew Morton <[EMAIL PROTECTED]> Date: Mon, 12 Feb 2007 18:12:16 -0800 > > On Mon, 12 Feb 2007 20:10:13 -0500 (EST) Pete Clements <[EMAIL PROTECTED]> > > wrote: > > 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 > > > > Please send the .config. Not necessary, the bug is obvious, see my other reply to this report. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
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. :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Why can't I build a running Kernel?
In addition This problem is not appear on another PC host with the same hardware(CPU,HD) except MEM is 2G. OS is origin RHEL4 without updates. Tony.Ho wrote: I have the same problem with 2.6.20. My host is dell PE850: pemtiumD 2.8G X1, MEM 1G X4, SATA 73G X1. albcamus wrote: 2007/2/9, Jiri Slaby <[EMAIL PROTECTED]>: Reg Clemens napsal(a): > Why can't I build a running Kernel? > I have in the past, but since some time in the 2.6.19 series, > I have got the following series of errors. > Same thing now with 2.6.20. > > I build with: > > make xconfig > > changing only the Processor type to Pentium4, > then I > > make bzImage > make modules > make modules_install > make install > > Fine everything builds, no errors. > I then try booting, and I get 4 or 5 lines and then > > Unable to access resume device (/dev/sda5) > mount: could not find filesystem '/dev/root' > < 4 more lines with setuproot and switchroot > > > and then > > Kernel panic - not syncing: Attempting to kill init! > > Sigh. > What has changed, what do I need to do to get this thing to boot? I have the same problem with 2.6.19 and later. The previous kernel with same .config works, but it's not true for 2.6.19 and 2.6.30. Re-enable sata/scsi/usb/whatever is your root behind stuff back again? What does your .config look like? regards, I selected everything about ATA to <*> or , and made initrd for the newly-built kernel, still unable to boot. The .config was attached, I have kdb-4.4 patched. Thanks and Regards, albcamus <[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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Coding style RFC: convert "for (i=0;i
Joe Perches wrote: On Tue, 2007-02-13 at 11:20 +1100, Ben Nizette wrote: #define array_for_each(element, array) \ for (int __idx = 0; __idx < ARRAY_SIZE((array)); \ __idx++, (element) = &(array[__idx])) This requires all interior loop code be changed. Ben is right though. Making this thing confusing to use is going to be worse than sticking with the very simple and unconfusing loops. If you really wanted to introduce your loop, then please call it array_for_each_idx, or something to distinguish 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: Why can't I build a running Kernel?
I have the same problem with 2.6.20. My host is dell PE850: pemtiumD 2.8G X1, MEM 1G X4, SATA 73G X1. albcamus wrote: 2007/2/9, Jiri Slaby <[EMAIL PROTECTED]>: Reg Clemens napsal(a): > Why can't I build a running Kernel? > I have in the past, but since some time in the 2.6.19 series, > I have got the following series of errors. > Same thing now with 2.6.20. > > I build with: > > make xconfig > > changing only the Processor type to Pentium4, > then I > > make bzImage > make modules > make modules_install > make install > > Fine everything builds, no errors. > I then try booting, and I get 4 or 5 lines and then > > Unable to access resume device (/dev/sda5) > mount: could not find filesystem '/dev/root' > < 4 more lines with setuproot and switchroot > > > and then > > Kernel panic - not syncing: Attempting to kill init! > > Sigh. > What has changed, what do I need to do to get this thing to boot? I have the same problem with 2.6.19 and later. The previous kernel with same .config works, but it's not true for 2.6.19 and 2.6.30. Re-enable sata/scsi/usb/whatever is your root behind stuff back again? What does your .config look like? regards, I selected everything about ATA to <*> or , and made initrd for the newly-built kernel, still unable to boot. The .config was attached, I have kdb-4.4 patched. Thanks and Regards, albcamus <[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-git8 fails compile -- net/built-in.o __ipv6_addr_type
Patched, compiles.
--
Pete Clements
Quoting YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=
>
> Ah, this is because of new ipv6 support in sunrpc code.
> Enable it if it is statically compiled.
>
> Alternatively, we could
> - export __ipv6_addr_type in new net/ipv6/addrconf_core.c
> or
> - introduce tiny inline for chcking if the address is link-local.
>
> Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
>
> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> index 63ae947..27dcb31 100644
> --- a/net/sunrpc/svcsock.c
> +++ b/net/sunrpc/svcsock.c
> @@ -107,12 +107,12 @@ static inline void svc_reclassify_socket
> sock_lock_init_class_and_name(sk, "slock-AF_INET-NFSD",
> _slock_key[0], "sk_lock-AF_INET-NFSD", _key[0]);
> break;
> -
> +#ifdef CONFIG_IPV6
> case AF_INET6:
> sock_lock_init_class_and_name(sk, "slock-AF_INET6-NFSD",
> _slock_key[1], "sk_lock-AF_INET6-NFSD", _key[1]);
> break;
> -
> +#endif
> default:
> BUG();
> }
> @@ -131,7 +131,7 @@ static char *__svc_print_addr(struct soc
> NIPQUAD(((struct sockaddr_in *) addr)->sin_addr),
> htons(((struct sockaddr_in *) addr)->sin_port));
> break;
> -#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> +#if defined(CONFIG_IPV6)
> case AF_INET6:
> snprintf(buf, len, "%x:%x:%x:%x:%x:%x:%x:%x, port=%u",
> NIP6(((struct sockaddr_in6 *) addr)->sin6_addr),
> @@ -449,7 +449,7 @@ svc_wake_up(struct svc_serv *serv)
>
> union svc_pktinfo_u {
> struct in_pktinfo pkti;
> -#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> +#if defined(CONFIG_IPV6)
> struct in6_pktinfo pkti6;
> #endif
> };
> @@ -467,7 +467,7 @@ static void svc_set_cmsg_data(struct svc
> cmh->cmsg_len = CMSG_LEN(sizeof(*pki));
> }
> break;
> -#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> +#if defined(CONFIG_IPV6)
> case AF_INET6: {
> struct in6_pktinfo *pki = CMSG_DATA(cmh);
>
> @@ -737,7 +737,7 @@ static void svc_udp_get_sender_address(s
> rqstp->rq_daddr.addr.s_addr = skb->nh.iph->daddr;
> }
> break;
> -#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> +#if defined(CONFIG_IPV6)
> case AF_INET6: {
> /* this is derived from net/ipv6/udp.c:udpv6_recvmesg */
> struct sockaddr_in6 *sin6 = svc_addr_in6(rqstp);
> @@ -977,7 +977,7 @@ static inline int svc_port_is_privileged
> case AF_INET:
> return ntohs(((struct sockaddr_in *)sin)->sin_port)
> < PROT_SOCK;
> -#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> +#if defined(CONFIG_IPV6)
> case AF_INET6:
> return ntohs(((struct sockaddr_in6 *)sin)->sin6_port)
> < PROT_SOCK;
> diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
> index 49cabff..877b52b 100644
> --- a/net/sunrpc/xprtsock.c
> +++ b/net/sunrpc/xprtsock.c
> @@ -1187,11 +1187,12 @@ static inline void xs_reclassify_socket(
> _slock_key[0], "sk_lock-AF_INET-NFS", _key[0]);
> break;
>
> +#ifdef CONFIG_IPV6
> case AF_INET6:
> sock_lock_init_class_and_name(sk, "slock-AF_INET6-NFS",
> _slock_key[1], "sk_lock-AF_INET6-NFS", _key[1]);
> break;
> -
> +#endif
> default:
> BUG();
> }
>
>
> --
> YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]>
> GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [q] kbuild for private asm-offsets (Re: [PATCH 6/10] lguest code: the little linux hypervisor.)
On Tue, Feb 13, 2007 at 10:41:36AM +1100, Rusty Russell wrote:
> Always happy to explain.
Thanks!
[]
> So, asm-offsets.c is the solution: it uses asm() statements to emit
> patterns in the assembler, with the compiler computing the actual
> numbers, eg:
>
> #define DEFINE(sym, val) \
(1) asm volatile("\n->" #sym " %0 " #val : : "i" (val))
> DEFINE(SIZEOF_FOOBAR, sizeof(foobar));
>
(2) Becomes in asm-offsets.s:
> ->SIZEOF_FOOBAR $10 sizeof(foobar) #
>
(3) This gets sed'd back into asm-offsets.h:
> #define SIZEOF_FOOBAR 10 /* SIZEOF_FOOBAR # */
>
> This can be included from .S files (which get passed through the
> pre-processor).
So, to make this parsing job clear once again, (1) is a pattern generator
of (2) for sed (this is not assembler), which is making final (3) then.
And this are actually C-for-asm offsets (asm-offsets.h is confusing to
me).
On Mon, Feb 12, 2007 at 10:41:28PM +0100, Sam Ravnborg wrote:
[]
> > I will glad to help providing solution maybe somewhat earlier (well, i'm
> > trying to understand whole building process, if that matters).
>
> Basically what is requested is to move the generic parts of asm-offsets
> generation from top-level Kbuild file to a generic file somewhere.
>
> Since this is not generic Kbuild functionality but more specific to the
> kernel it should not be part of Kbuild generic files.
> include/asm-generic/asm-offsets seems to be a fair place for it.
Too much "generic" were used. Anyways, simply thing is, that there must be:
-- hardware file(s) for Arch;
-- "private" software file(s), for paravirt and such.
On Mon, Feb 12, 2007 at 06:24:13PM +0100, Andi Kleen wrote:
[]
> The problem is trying to figure out what needs to be done to get
> multiple asm-offsets.h.
Proposition will follow.
Kind regards.
P.S.
While it was fun to run kinds of offtopic operation systems in
virtual machine back in 2000-2001. Now it isn't.
Mainly due to yet another zoo. May be this is good for quick adoption,
commercial benefit, etc. Yet thankfully to Rusty, general useful
infrastructure is available now. Kudos to everyone :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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
In article <[EMAIL PROTECTED]> (at Mon, 12 Feb 2007 21:35:59 -0500 (EST)), Pete
Clements <[EMAIL PROTECTED]> says:
> Quoting YOSHIFUJIHideaki/=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=
> > In article <[EMAIL PROTECTED]> (at Mon, 12 Feb 2007 18:12:16 -0800),
> Andrew Morton <[EMAIL PROTECTED]> says:
> >
> > > > On Mon, 12 Feb 2007 20:10:13 -0500 (EST) Pete Clements <[EMAIL
> PROTECTED]> wrote:
> > > > 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
> > > >
> > >
> > > Please send the .config.
> >
> > and, the gcc version...
> >
> > --yoshfuji
> > -
>
> git 7 compiled just fine.
Ah, this is because of new ipv6 support in sunrpc code.
Enable it if it is statically compiled.
Alternatively, we could
- export __ipv6_addr_type in new net/ipv6/addrconf_core.c
or
- introduce tiny inline for chcking if the address is link-local.
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 63ae947..27dcb31 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -107,12 +107,12 @@ static inline void svc_reclassify_socket
sock_lock_init_class_and_name(sk, "slock-AF_INET-NFSD",
_slock_key[0], "sk_lock-AF_INET-NFSD", _key[0]);
break;
-
+#ifdef CONFIG_IPV6
case AF_INET6:
sock_lock_init_class_and_name(sk, "slock-AF_INET6-NFSD",
_slock_key[1], "sk_lock-AF_INET6-NFSD", _key[1]);
break;
-
+#endif
default:
BUG();
}
@@ -131,7 +131,7 @@ static char *__svc_print_addr(struct soc
NIPQUAD(((struct sockaddr_in *) addr)->sin_addr),
htons(((struct sockaddr_in *) addr)->sin_port));
break;
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(CONFIG_IPV6)
case AF_INET6:
snprintf(buf, len, "%x:%x:%x:%x:%x:%x:%x:%x, port=%u",
NIP6(((struct sockaddr_in6 *) addr)->sin6_addr),
@@ -449,7 +449,7 @@ svc_wake_up(struct svc_serv *serv)
union svc_pktinfo_u {
struct in_pktinfo pkti;
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(CONFIG_IPV6)
struct in6_pktinfo pkti6;
#endif
};
@@ -467,7 +467,7 @@ static void svc_set_cmsg_data(struct svc
cmh->cmsg_len = CMSG_LEN(sizeof(*pki));
}
break;
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(CONFIG_IPV6)
case AF_INET6: {
struct in6_pktinfo *pki = CMSG_DATA(cmh);
@@ -737,7 +737,7 @@ static void svc_udp_get_sender_address(s
rqstp->rq_daddr.addr.s_addr = skb->nh.iph->daddr;
}
break;
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(CONFIG_IPV6)
case AF_INET6: {
/* this is derived from net/ipv6/udp.c:udpv6_recvmesg */
struct sockaddr_in6 *sin6 = svc_addr_in6(rqstp);
@@ -977,7 +977,7 @@ static inline int svc_port_is_privileged
case AF_INET:
return ntohs(((struct sockaddr_in *)sin)->sin_port)
< PROT_SOCK;
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(CONFIG_IPV6)
case AF_INET6:
return ntohs(((struct sockaddr_in6 *)sin)->sin6_port)
< PROT_SOCK;
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index 49cabff..877b52b 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -1187,11 +1187,12 @@ static inline void xs_reclassify_socket(
_slock_key[0], "sk_lock-AF_INET-NFS", _key[0]);
break;
+#ifdef CONFIG_IPV6
case AF_INET6:
sock_lock_init_class_and_name(sk, "slock-AF_INET6-NFS",
_slock_key[1], "sk_lock-AF_INET6-NFS", _key[1]);
break;
-
+#endif
default:
BUG();
}
--
YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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
On Monday February 12, [EMAIL PROTECTED] wrote: > Quoting YOSHIFUJIHideaki/=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= > > In article <[EMAIL PROTECTED]> (at Mon, 12 Feb 2007 18:12:16 -0800), > Andrew Morton <[EMAIL PROTECTED]> says: > > > > > > On Mon, 12 Feb 2007 20:10:13 -0500 (EST) Pete Clements <[EMAIL > PROTECTED]> wrote: > > > > 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 > > > > Hmmm. > CONFIG_IPV6=m combined with > CONFIG_SUNRPC=y is a combination that isn't going to work at the moment Options? - Move __ipv6_addr_type to lib/ ?? Might not work for modules. - Disallow that combination in the .config. .. a bit harsh. - Only include IPv6 support in SUNRPC is a module or IPV6 is built-in A bit of a kludge.. Chuck? Any ideas? 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: [RFC PATCH] QRCU fastpath optimization
On Mon, Feb 12, 2007 at 07:22:09AM +0100, Jens Axboe wrote:
> On Sun, Feb 11 2007, Paul E. McKenney wrote:
> > This patch optimizes the "quick" RCU update-side fastpath, so that in the
> > absence of readers, synchronize_qrcu() does four non-atomic comparisons
> > and three memory barriers, eliminating the need to acquire the global
> > lock in this case. Lightly tested. Algorithm has been validated for
> > the 3-reader-2-updater and 2-reader-3-updater cases -- 3-readers-3-updaters
> > case still to be done (I expect to get access to a large-memory machine
> > in the next few weeks -- need >>20GB).
> >
> > Not for inclusion. Patch is against Oleg's original patch, and likely
> > needs to be rediffed against Jen's patchstack. I will do this rediffing
> > later, first want an easy-to-test and easy-to-inpect version.
>
> I'd suggest just merging this optimization into the original QRCU patch.
> Once you are happy with the validation, I'll add it to the plug branch
> as well.
>
> Version against the plug branch below.
Thank you very much!!!
One way or another, I will get you something in a form friendly to your
patch stack.
Thanx, Paul
> diff --git a/kernel/srcu.c b/kernel/srcu.c
> index 53c6989..bfe347a 100644
> --- a/kernel/srcu.c
> +++ b/kernel/srcu.c
> @@ -324,28 +324,53 @@ void synchronize_qrcu(struct qrcu_struct *qp)
> {
> int idx;
>
> + smp_mb(); /* Force preceding change to happen before fastpath check. */
> +
> /*
> - * The following memory barrier is needed to ensure that
> - * any prior data-structure manipulation is seen by other
> - * CPUs to happen before picking up the value of
> - * qp->completed.
> + * Fastpath: If the two counters sum to "1" at a given point in
> + * time, there are no readers. However, it takes two separate
> + * loads to sample both counters, which won't occur simultaneously.
> + * So we might race with a counter switch, so that we might see
> + * ctr[0]==0, then the counter might switch, then we might see
> + * ctr[1]==1 (unbeknownst to us because there is a reader still
> + * there). So we do a read memory barrier and recheck. If the
> + * same race happens again, there must have been a second counter
> + * switch. This second counter switch could not have happened
> + * until all preceding readers finished, so if the condition
> + * is true both times, we may safely proceed.
> + *
> + * This relies critically on the atomic increment and atomic
> + * decrement being seen as executing in order.
>*/
> - smp_mb();
> +
> + if (atomic_read(>ctr[0]) + atomic_read(>ctr[1]) <= 1) {
> + smp_rmb(); /* Keep two checks independent. */
> + if (atomic_read(>ctr[0]) + atomic_read(>ctr[1]) <= 1)
> + goto out;
> + }
> +
> mutex_lock(>mutex);
>
> idx = qp->completed & 0x1;
> if (atomic_read(qp->ctr + idx) == 1)
> - goto out;
> + goto out_unlock;
>
> atomic_inc(qp->ctr + (idx ^ 0x1));
> - /* Reduce the likelihood that qrcu_read_lock() will loop */
> +
> + /*
> + * Prevent subsequent decrement from being seen before previous
> + * increment -- such an inversion could cause the fastpath
> + * above to falsely conclude that there were no readers. Also,
> + * reduce the likelihood that qrcu_read_lock() will loop.
> + */
> smp_mb__after_atomic_inc();
> qp->completed++;
>
> atomic_dec(qp->ctr + idx);
> __wait_event(qp->wq, !atomic_read(qp->ctr + idx));
> -out:
> +out_unlock:
> mutex_unlock(>mutex);
> +out:
> smp_mb();
> /*
>* The above smp_mb() is needed in the case that we
>
> --
> Jens Axboe
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: build error: allnoconfig fails on mincore/swapper_space
Andrew Morton wrote: On Mon, 12 Feb 2007 14:50:40 -0800 Randy Dunlap <[EMAIL PROTECTED]> wrote: 2.6.20-git8 on x86_64: LD init/built-in.o LD .tmp_vmlinux1 mm/built-in.o: In function `sys_mincore': (.text+0xe584): undefined reference to `swapper_space' make: *** [.tmp_vmlinux1] Error 1 oops. CONFIG_SWAP=n, I assume? Hmm, OK. Hugh can strip me of my bonus point now... Hugh, you can strip me of my bonus point now... How about your other suggestion to just remove the stats from lookup_swap_cache? (and should we also rename it to find_get_swap_page?) Thanks, Nick -- 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: Regress for 8139too in 2.6.20
Andrew Morton wrote: >> > > That's a bit surprising - the initcall levels don't affect modules. > Presumably something went wrong in core kernel which later caused yenta > and/or 8139too to fail. > > Have you tried diffing the before- and after-dmesgs to see if that particular > commit has caused any interesting differences? > > And are you able to test any other cardbus devices to see whether it's > specific to 8139too? No devices would work until I manually loaded yenta_socket. Before the change, the PCMCIA bridge was discovered earlier, and yenta_socket was automatically loaded. Now I need to add it to the list of modules to be loaded at bootup. With that change, everyting is OK. The diff between yenta as a module and yenta built is follows. Thanks, Larry --- --- /ide/dmesg_with_yenta_module2007-02-12 18:51:35.0 -0600 +++ /ide/dmesg_with_yenta_builtin 2007-02-12 16:25:24.0 -0600 @@ -1,4 +1,4 @@ -Linux version 2.6.20-default-g7096ede5-dirty ([EMAIL PROTECTED]) (gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)) #119 Mon Feb 12 18:40:07 CST 2007 +Linux version 2.6.20-default-g7096ede5 ([EMAIL PROTECTED]) (gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)) #116 Sun Feb 11 14:27:53 CST 2007 BIOS-provided physical RAM map: sanitize start sanitize end @@ -39,28 +39,28 @@ ACPI: FACS 07C0, 0040 ACPI: Disabling ACPI support Allocating PCI resources starting at 1000 (gap: 0800:f7fea400) -Detected 331.611 MHz processor. +Detected 331.592 MHz processor. Built 1 zonelists. Total pages: 32497 Kernel command line: root=/dev/hda3 vga=0x314 selinux=0resume=/dev/hda2 splash=silent showopts Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to d000 (01101000) Enabling fast FPU save and restore... done. Initializing CPU#0 -CPU 0 irqstacks, hard=c0421000 soft=c0422000 +CPU 0 irqstacks, hard=c0432000 soft=c0433000 PID hash table entries: 512 (order: 9, 2048 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) -Memory: 124256k/131008k available (2092k kernel code, 6220k reserved, 886k data, 200k init, 0k highmem) +Memory: 124188k/131008k available (2137k kernel code, 6288k reserved, 909k data, 200k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb6000 - 0xf000 ( 292 kB) vmalloc : 0xc880 - 0xfffb4000 ( 887 MB) lowmem : 0xc000 - 0xc7ff ( 127 MB) - .init : 0xc03ea000 - 0xc041c000 ( 200 kB) - .data : 0xc030b24b - 0xc03e8c48 ( 886 kB) - .text : 0xc010 - 0xc030b24b (2092 kB) + .init : 0xc03fb000 - 0xc042d000 ( 200 kB) + .data : 0xc031653b - 0xc03f9c48 ( 909 kB) + .text : 0xc010 - 0xc031653b (2137 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. -Calibrating delay using timer specific routine.. 664.03 BogoMIPS (lpj=1328067) +Calibrating delay using timer specific routine.. 664.05 BogoMIPS (lpj=1328111) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0183f9ff CPU: L1 I cache: 16K, L1 D cache: 16K @@ -104,8 +104,10 @@ MEM window: 1c00-1fff PCI: Found IRQ 9 for device :00:0a.0 PCI: Sharing IRQ 9 with :00:08.1 +PCI: Setting latency timer of device :00:0a.0 to 64 PCI: Assigned IRQ 9 for device :00:0a.1 PCI: Sharing IRQ 9 with :00:09.0 +PCI: Setting latency timer of device :00:0a.1 to 64 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 4, 81920 bytes) @@ -115,7 +117,7 @@ checking if image is initramfs... it is Freeing initrd memory: 1564k freed audit: initializing netlink socket (disabled) -audit(1171306196.744:1): initialized +audit(1171277305.752:1): initialized io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered @@ -138,25 +140,33 @@ FDC 0 is a post-1991 82077 RAMDISK driver initialized: 16 RAM disks of 64000K size 1024 blocksize loop: loaded (max 8 devices) +Yenta: CardBus bridge found at :00:0a.0 [104d:8042] +Yenta: ISA IRQ mask 0x0cb8, PCI irq 9 +Socket status: 3410 +Yenta: CardBus bridge found at :00:0a.1 [104d:8042] +Yenta: ISA IRQ mask 0x0cb8, PCI irq 9 +Socket status: 3820 PNP: No PS/2 controller found. Probing ports directly. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard as /class/input/input0 input: PC Speaker as /class/input/input1 +pccard: PCMCIA card inserted into slot 0 input: PS/2 Mouse as /class/input/input2 input: AlpsPS/2 ALPS GlidePoint as /class/input/input3 NET: Registered protocol family 1 Using IPI Shortcut mode Freeing unused
Re: 2.6.20-git8 fails compile -- net/built-in.o __ipv6_addr_type
Quoting YOSHIFUJIHideaki/=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= > In article <[EMAIL PROTECTED]> (at Mon, 12 Feb 2007 18:12:16 -0800), Andrew Morton <[EMAIL PROTECTED]> says: > > > > On Mon, 12 Feb 2007 20:10:13 -0500 (EST) Pete Clements <[EMAIL PROTECTED]> wrote: > > > 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 > > > > > > > Please send the .config. > > and, the gcc version... > > --yoshfuji > - git 7 compiled just fine. gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) Config: CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y CONFIG_DEFAULT_IOSCHED="anticipatory" CONFIG_SMP=y CONFIG_X86_PC=y CONFIG_MPENTIUMIII=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_NR_CPUS=2 CONFIG_PREEMPT_NONE=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_VM86=y CONFIG_HIGHMEM4G=y CONFIG_PAGE_OFFSET=0xC000 CONFIG_HIGHMEM=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_ZONE_DMA_FLAG=1 CONFIG_MTRR=y CONFIG_IRQBALANCE=y CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_PHYSICAL_START=0x10 CONFIG_PHYSICAL_ALIGN=0x10 CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_PM=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_ISA_DMA_API=y CONFIG_ISA=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_FIB_HASH=y CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" CONFIG_IPV6=m CONFIG_NETFILTER=y CONFIG_NF_CONNTRACK_ENABLED=m CONFIG_NF_CONNTRACK_SUPPORT=y CONFIG_NF_CONNTRACK=m CONFIG_NF_CT_ACCT=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_EVENTS=y CONFIG_NF_CT_PROTO_GRE=m CONFIG_NF_CT_PROTO_SCTP=m CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m CONFIG_NF_CONNTRACK_IRC=m CONFIG_NF_CONNTRACK_NETBIOS_NS=m CONFIG_NF_CONNTRACK_PPTP=m CONFIG_NF_CONNTRACK_SANE=m CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m CONFIG_NETFILTER_XTABLES=m CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_DSCP=m CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NFLOG=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m CONFIG_NETFILTER_XT_TARGET_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ESP=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_QUOTA=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_SCTP=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STATISTIC=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m CONFIG_NF_CONNTRACK_IPV4=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_IPRANGE=m
Re: Why can't I build a running Kernel?
2007/2/12, Jiri Slaby <[EMAIL PROTECTED]>: Config seems to be fine. Please post lspci -vvvxx Attached. and lines from your boot loader. title Fedora Core (2.6.20) root (hd0,1) kernel /vmlinuz-2.6.20 ro root=LABEL=/ vga=0x31B initrd /initrd-2.6.20.img And I have the SATA device /dev/sda3 labeled as '/'. regards, -- Thanks and regards, albcamus<[EMAIL PROTECTED]> lspci_vvvxx.output Description: Binary data
Re: [PATCH 5/8] lguest: trivial guest network driver
On Tue, 2007-02-13 at 02:55 +1100, Herbert Xu wrote:
> On Mon, Feb 12, 2007 at 02:52:01PM +1100, Rusty Russell wrote:
> >
> > +static void skb_to_dma(const struct sk_buff *skb, unsigned int len,
> > + struct lguest_dma *dma)
> > +{
> > + unsigned int i, seg;
> > +
> > + for (i = seg = 0; i < len; seg++, i += rest_of_page(skb->data + i)) {
>
> The length field from the skb covers the fragmented parts as well.
> So you don't want to use it as the boundary for the loop over the
> skb header data. As it is, if the skb has fragments, the first
> loop will try to read them off the header.
Good spotting! This function needs to be passed skb_headlen(skb),
rather than skb->len. Patch is below (I renamed the parameter as well,
for clarity).
It's fascinating why this "worked". Firstly, for inter-guest
communication, I am not calculating checksums, nor checking them.
Secondly, for guest->host, I turn off hw checksumming so the kernel
disables SG and this code is never executed. Thirdly, for virtbench's
inter-guest sendfile test does not check the data received is actually
correct. Finally, while we end up producing a packet which is larger
than skb->len of 1514, the DMA receive buffer for the other guest is
only 1514 bytes, so the result of the transfer is 1514 (==skb->len), so
no error reported by the driver.
==
lguest network driver fix: handle scatter-gather packets correctly
Thanks to Herbert Xu for noticing the bug: "len" here is skb_headlen(),
not skb->len. Renamed the function to clarify, too.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r ed6484d145a4 drivers/net/lguest_net.c
--- a/drivers/net/lguest_net.c Tue Feb 13 11:30:39 2007 +1100
+++ b/drivers/net/lguest_net.c Tue Feb 13 12:07:15 2007 +1100
@@ -59,14 +59,14 @@ static unsigned long peer_addr(struct lg
return info->peer_phys + 4 * peernum;
}
-static void skb_to_dma(const struct sk_buff *skb, unsigned int len,
+static void skb_to_dma(const struct sk_buff *skb, unsigned int headlen,
struct lguest_dma *dma)
{
unsigned int i, seg;
- for (i = seg = 0; i < len; seg++, i += rest_of_page(skb->data + i)) {
+ for (i = seg = 0; i < headlen; seg++, i += rest_of_page(skb->data+i)) {
dma->addr[seg] = virt_to_phys(skb->data + i);
- dma->len[seg] = min((unsigned)(len - i),
+ dma->len[seg] = min((unsigned)(headlen - i),
rest_of_page(skb->data + i));
}
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++, seg++) {
@@ -90,7 +90,7 @@ static void transfer_packet(struct net_d
struct lguestnet_info *info = dev->priv;
struct lguest_dma dma;
- skb_to_dma(skb, skb->len, );
+ skb_to_dma(skb, skb_headlen(skb), );
pr_debug("xfer length %04x (%u)\n", htons(skb->len), skb->len);
hcall(LHCALL_SEND_DMA, peer_addr(info,peernum), __pa(),0);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-git8 fails compile -- net/built-in.o __ipv6_addr_type
In article <[EMAIL PROTECTED]> (at Mon, 12 Feb 2007 18:12:16 -0800), Andrew Morton <[EMAIL PROTECTED]> says: > > On Mon, 12 Feb 2007 20:10:13 -0500 (EST) Pete Clements <[EMAIL PROTECTED]> > > wrote: > > 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 > > > > Please send the .config. and, the gcc version... --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
> On Mon, 12 Feb 2007 20:10:13 -0500 (EST) Pete Clements <[EMAIL PROTECTED]> > wrote: > 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 > Please send the .config. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [ckrm-tech] [PATCH 0/7] containers (V7): Generic Process Containers
On 2/12/07, Sam Vilain <[EMAIL PROTECTED]> wrote: Not every module, you just make them on sensible, planned groupings. The danger is that the "container" group becomes a fallback grouping for things when people can't be bothered thinking about it properly, and everything including the kitchen sink gets thrown in. Then later you find a real use case where you don't want them together, but it's too late because it's already a part of the official API. This paragraph seems to have a contradiction - first you say that modules should use "planned groupings", then you complain that modules using generic containers will find that they can't separate from other modules "because they're part of an official API". On the contrary - a module that's written over generic containers can be combined with other such modules in the same groupings, or used in different groupings, depending on what the user desires. This is discussed in some detail in Documentation/containers.txt in patch 3 of my patchset. My patchset doesn't try to make all modules use the same *grouping*, it tries to make them use the same *abstraction* (and hence share code), but allows them to easily use different groupings just by binding modules to different hierarchies. > As an example, the CPU accounting patch that in included in my patch > set as an illustration of a simple resource monitoring module is just > 250 lines, almost entirely in one file; if it also had to handle > associating tasks together into groups and presenting a filesystem > interface to the user it would be far larger and would have a much > bigger footprint on the kernel. > It's also less flexible. What if I want to do CPU accounting on some other boundaries than the "virtual server" a process is a part of? No problem - that's why there are multiple hierarchies available. You can mount the CPU accounting on one hierarchy, the virtual servers on a different hierarchy, and they have completely independent mappings from processes to containers - essentially parallel trees of containers. 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: SATA Drive No Longer Recognized In New 2.6.20 Kernel
Joseph Cosby wrote: Thanks. Now having enabled the new ATA config options, the vendor-id shows up in my modules pci list. But the hard drive still isn't detected by the kernel. Is there more that needs to be enabled for this to work? Please be more explicit about which options you enabled. And do you still have some of CONFIG_SCSI_* enabled? Some of those are needed too. so re-attach your .config file, or at least the ATA and SCSI parts of it. -- ~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 1/3] Introducing cpuidle: core cpuidle infrastructure
On Mon, Feb 12, 2007 at 10:39:25AM -0800, Venkatesh Pallipadi wrote: > > Introducing 'cpuidle', a new CPU power management infrastructure to manage > idle CPUs in a clean and efficient manner. > cpuidle separates out the drivers that can provide support for multiple types > of idle states and policy governors that decide on what idle state to use > at run time. > A cpuidle driver can support multiple idle states based on parameters like > varying power consumption, wakeup latency, etc (ACPI C-states for example). > A cpuidle governor can be usage model specific (laptop, server, > laptop on battery etc). > Main advantage of the infrastructure being, it allows independent development > of drivers and governors and allows for better CPU power management. > > A huge thanks to Adam Belay and Shaohua Li who were part of this mini-project > since its beginning and are greatly responsible for this patchset. interesting. Though I wonder about giving admins _more_ knobs to twiddle. It took cpufreq a long time to settle down in this area, and typically 'ondemand' was the answer in the end for 99.9% of people. I question the usefulness for the whole multiple governors interface, because in the case of cpuidle there shouldn't be any real trade-off between one algorithm and another afaics? So why can't we just have one, that just 'does the right thing' ? The only differentiator that I can think of would be latency, but that seems to be a) covered in a different tunable, and b) probably wouldn't affect most people enough where it matters. I'll do a proper code review later, but one thing stuck out like a sore thumb on a quick skim.. > +EXPORT_SYMBOL_GPL(current_driver); That's a horribly generic name for an exported global. current_cpuidle_driver maybe? -- 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/
2.6.20-git8 fails compile -- net/built-in.o __ipv6_addr_type
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 -- Pete Clements - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: BusLogic check_region patch
On Mon, Feb 12, 2007 at 04:27:04PM -0800, Michael Clay wrote: > This patch is meant to remove the calls to check_region, a now > deprecated function in order to get rid of compilation warning. This > was done by finding all calls to check_region and replacing them with > calls to request_region. check_region essentially was a wrapper around > request_region, and was checking if the request_region returned a > pointer or null. As a result, I simply inlined the process of checking > for null, eliminating the need to call the check_region wrapper. Yes, but what happens when half the request_region() calls succeed, and the other half fail? You cannot simply substitute check_region with request_region. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [ckrm-tech] [PATCH 0/7] containers (V7): Generic Process Containers
Paul Menage wrote: >> Ask yourself this - what do you need the container structure for so >> badly, that virtualising the individual resources does not provide for? >> > Primarily, that otherwise every module that wants to affect/monitor > behaviour of a group of associated processes has to implement its own > process grouping abstraction. > Not every module, you just make them on sensible, planned groupings. The danger is that the "container" group becomes a fallback grouping for things when people can't be bothered thinking about it properly, and everything including the kitchen sink gets thrown in. Then later you find a real use case where you don't want them together, but it's too late because it's already a part of the official API. > As an example, the CPU accounting patch that in included in my patch > set as an illustration of a simple resource monitoring module is just > 250 lines, almost entirely in one file; if it also had to handle > associating tasks together into groups and presenting a filesystem > interface to the user it would be far larger and would have a much > bigger footprint on the kernel. > It's also less flexible. What if I want to do CPU accounting on some other boundaries than the "virtual server" a process is a part of? > From the point of view of the virtual server containers, the advantage > is that you're integrated with a standard filesystem interface for > determining group membership. It does become simpler to combine > virtual servers and resource controllers, although I grant you that > you could juggle that from userspace without the additional kernel > support. > I'm not disagreeing it's a pragmatic shortcut that has been successful for a number of projects including vserver which I use every day. But it reduces "synergy" by excluding the people working with virtualisation in ways that don't fit its model. Yes, there should be a similarity in the way that you manage namespaces and it should be easy to develop new namespaces without constantly re-inventing the wheel. But why does that imply making binding decisions about the nature of how you can virtualise? IMHO those decisions should be made on a per-subsystem basis. Sam. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.20 Oopses in xfrm_audit_log
On Mon, 12 Feb 2007, David Miller wrote: > Thus, below is the patch I will use to fix this bug: > > 1) Calling xfrm_audit_log() with a NULL object is a BUG() > 2) Setting "result" based upon NULL'ness of the object makes no >sense, either set it to "1" in these cases or use an appropriate >error check. > > How does this look to others? Looks good to me. -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BusLogic check_region patch
This patch is meant to remove the calls to check_region, a now
deprecated function in order to get rid of compilation warning. This
was done by finding all calls to check_region and replacing them with
calls to request_region. check_region essentially was a wrapper around
request_region, and was checking if the request_region returned a
pointer or null. As a result, I simply inlined the process of checking
for null, eliminating the need to call the check_region wrapper.
--- drivers/scsi/BusLogic.c 2007-02-12 16:05:29.0 -0800
+++ /home/claym/sandbox/BusLogic.c 2007-02-12 16:11:23.0 -0800
@@ -579,17 +579,17 @@ static void __init BusLogic_InitializePr
/*
Append the list of standard BusLogic MultiMaster ISA I/O Addresses.
*/
- if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe330 : check_region(0x330,
BusLogic_MultiMasterAddressCount) == 0)
+ if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe330 : request_region(0x330,
BusLogic_MultiMasterAddressCount, "Buslogic") != NULL)
BusLogic_AppendProbeAddressISA(0x330);
- if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe334 : check_region(0x334,
BusLogic_MultiMasterAddressCount) == 0)
+ if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe334 : request_region(0x334,
BusLogic_MultiMasterAddressCount, "BusLogic") != NULL)
BusLogic_AppendProbeAddressISA(0x334);
- if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe230 : check_region(0x230,
BusLogic_MultiMasterAddressCount) == 0)
+ if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe230 : request_region(0x230,
BusLogic_MultiMasterAddressCount, "BusLogic") != NULL)
BusLogic_AppendProbeAddressISA(0x230);
- if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe234 : check_region(0x234,
BusLogic_MultiMasterAddressCount) == 0)
+ if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe234 : request_region(0x234,
BusLogic_MultiMasterAddressCount, "BusLogic") != NULL)
BusLogic_AppendProbeAddressISA(0x234);
- if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe130 : check_region(0x130,
BusLogic_MultiMasterAddressCount) == 0)
+ if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe130 : request_region(0x130,
BusLogic_MultiMasterAddressCount, "BusLogic") != NULL)
BusLogic_AppendProbeAddressISA(0x130);
- if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe134 : check_region(0x134,
BusLogic_MultiMasterAddressCount) == 0)
+ if (BusLogic_ProbeOptions.LimitedProbeISA ?
BusLogic_ProbeOptions.Probe134 : request_region(0x134,
BusLogic_MultiMasterAddressCount, "BusLogic") != NULL)
BusLogic_AppendProbeAddressISA(0x134);
}
@@ -795,7 +795,7 @@ static int __init BusLogic_InitializeMul
host adapters are probed.
*/
if (!BusLogic_ProbeOptions.NoProbeISA)
- if (PrimaryProbeInfo->IO_Address == 0 &&
(BusLogic_ProbeOptions.LimitedProbeISA ? BusLogic_ProbeOptions.Probe330 :
check_region(0x330, BusLogic_MultiMasterAddressCount) == 0)) {
+ if (PrimaryProbeInfo->IO_Address == 0 &&
(BusLogic_ProbeOptions.LimitedProbeISA ? BusLogic_ProbeOptions.Probe330 :
request_region(0x330, BusLogic_MultiMasterAddressCount,"BusLogic") != NULL)) {
PrimaryProbeInfo->HostAdapterType =
BusLogic_MultiMaster;
PrimaryProbeInfo->HostAdapterBusType = BusLogic_ISA_Bus;
PrimaryProbeInfo->IO_Address = 0x330;
@@ -805,15 +805,15 @@ static int __init BusLogic_InitializeMul
omitting the Primary I/O Address which has already been handled.
*/
if (!BusLogic_ProbeOptions.NoProbeISA) {
- if (!StandardAddressSeen[1] &&
(BusLogic_ProbeOptions.LimitedProbeISA ? BusLogic_ProbeOptions.Probe334 :
check_region(0x334, BusLogic_MultiMasterAddressCount) == 0))
+ if (!StandardAddressSeen[1] &&
(BusLogic_ProbeOptions.LimitedProbeISA ? BusLogic_ProbeOptions.Probe334 :
request_region(0x334, BusLogic_MultiMasterAddressCount, "BusLogic") != NULL))
BusLogic_AppendProbeAddressISA(0x334);
- if (!StandardAddressSeen[2] &&
(BusLogic_ProbeOptions.LimitedProbeISA ? BusLogic_ProbeOptions.Probe230 :
check_region(0x230, BusLogic_MultiMasterAddressCount) == 0))
+ if (!StandardAddressSeen[2] &&
(BusLogic_ProbeOptions.LimitedProbeISA ? BusLogic_ProbeOptions.Probe230 :
request_region(0x230, BusLogic_MultiMasterAddressCount, "BusLogic") != NULL))
BusLogic_AppendProbeAddressISA(0x230);
- if (!StandardAddressSeen[3] &&
(BusLogic_ProbeOptions.LimitedProbeISA ? BusLogic_ProbeOptions.Probe234 :
Re: [PATCH 1/2] Re: [autofs] Bad race condition in the new autofs protocol somewhere
On Mon, 2007-02-12 at 14:57 +0100, Olivier Galibert wrote: > On Mon, Feb 12, 2007 at 03:43:14PM +0900, Ian Kent wrote: > > On Thu, 2007-02-08 at 11:33 +0900, Ian Kent wrote: > > > On Wed, 2007-02-07 at 19:18 +0100, Olivier Galibert wrote: > > > > On Thu, Feb 08, 2007 at 03:07:41AM +0900, Ian Kent wrote: > > > > > It may be better to update to a later kernel so I don't have to port > > > > > the > > > > > patch to several different kernels. Is that possible? > > > > > > > > Sure, 2.6.20 or -git? > > > > > > 2.6.20 has all the patches I've proposed so far except for the one we're > > > working on so that would be best for me. > > > > > > Seems there may still be a problem with the patch so I'll let you know > > > what's happening as soon as I can. > > > > I think I'm just about done. > > > > Could you try using the two patches here against 2.6.20 please: > > The patch works beautifully, no more failures with my test rig, until > the point where the kernel crashes. Since the crashes happen without > the patch too, you're off the hook, but that means I can't deploy it > for harsher testing yet. > > No wonder Dave Jones is prudent about updating kernels in fc :-) Indeed. Which kernel can you use? I believe that 2200 had another problem so can you use an fc5 kernel later than that? Ian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Coding style RFC: convert "for (i=0;i
On Tue, 2007-02-13 at 11:20 +1100, Ben Nizette wrote: > #define array_for_each(element, array) \ > for (int __idx = 0; __idx < ARRAY_SIZE((array)); \ > __idx++, (element) = &(array[__idx])) This requires all interior loop code be changed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Recent and not-so problems with tifm_sd driver
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Alex Dubov wrote:
> > I removed that line altogether (it does not really needed as mmc host will
> > not be accessed
> > anymore). The problem is more elaborate. Here, the card fails,
> > mmc_host_remove is called
> without
> > sleep beforehand, and "after remove" message is printed immediately after
> > it. Only then,
> mmc_block
> > remembers to finish its business. If I leave the sleep in place,
> > mmc_block's stuff will get
> > scheduled before the mmc_remove_host and everything will be all right.
> > You may also notice that host is already powered off ("Setting ... power 0"
> > message) and still
> > mmc_block continues to make requests like nothing happened.
> >
>
> How did you do the "after remove" detection? Patch?
>
(Power message is printed by ios callback)
Here's my current (SVN) remove function:
static void tifm_sd_remove(struct tifm_dev *sock)
{
struct mmc_host *mmc = tifm_get_drvdata(sock);
struct tifm_sd *host = mmc_priv(mmc);
unsigned long flags;
tasklet_kill(>finish_tasklet);
spin_lock_irqsave(>lock, flags);
host->flags |= EJECT;
writel(0, sock->addr + SOCK_MMCSD_INT_ENABLE);
mmiowb();
if (host->req) {
writel(TIFM_FIFO_INT_SETALL,
sock->addr + SOCK_DMA_FIFO_INT_ENABLE_CLEAR);
writel(0, sock->addr + SOCK_DMA_FIFO_INT_ENABLE_SET);
host->req->cmd->error = MMC_ERR_TIMEOUT;
if (host->req->stop)
host->req->stop->error = MMC_ERR_TIMEOUT;
tasklet_schedule(>finish_tasklet);
}
spin_unlock_irqrestore(>lock, flags);
// temporary hack
msleep(1000);
mmc_remove_host(mmc);
dev_dbg(>dev, "after remove\n");
/* The meaning of the bit majority in this constant is unknown. */
writel(0xfff8 & readl(sock->addr + SOCK_CONTROL),
sock->addr + SOCK_CONTROL);
mmc_free_host(mmc);
}
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel
bargains.
http://farechase.yahoo.com/promo-generic-14795097
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: SATA Drive No Longer Recognized In New 2.6.20 Kernel
Joseph Cosby wrote: Hi, Until recently I was using the 2.6.18 kernel. I have a SATA hard drive that was detected by the kernel, using the PIIX driver. But after updating to 2.6.20, the hard drive is no longer detected by the kernel. I used make oldconfig to create the 2.6.20 config file, and I noticed a new option CONFIG_ATA. I did not use this, because as I understand it is not necessary and is experimental. Do I need to use this or is there something else in the new kernel that needs to be enabled for this driver? My 2.6.20 config file follows. The hard drive has vendor ID 8086 and device ID 27c0. It is listed in the modules.pcilist file of 2.6.18 but not 2.6.20. If anybody can share any advice please CC me in response. Yes, you do need CONFIG_ATA if you were using ata_piix before (and of course the PIIX driver also needs to be enabled). All of the libata drivers were moved from under the SCSI menu into a new ATA menu (in 2.6.19 I think). -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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 7/8] lguest: trivial guest block driver
On Tue, Feb 13 2007, Rusty Russell wrote: > On Mon, 2007-02-12 at 16:01 +0100, Jens Axboe wrote: > > On Mon, Feb 12 2007, Rusty Russell wrote: > > > Thanks Jens!! > > > > My pleasure, it's not often you get to make that big a performance > > improvement with just a little few lines of change :-) > > *cough* I deliberately leave these low hanging fruit in lguest to > encourage people to hack on it. Really. *cough* :-) > > I guess you'll take changes to make this driver queuing as well? It's > > pretty important for good guest io performance as well. > > The question is whether the guest or host should queue. If you have > multiple guests sharing a disk in the hose, I would think that the host > is better off queuing. And this would seem to be the common case. You want queuing in the host, since for queuing to make a performance difference it needs to be propagated all the way down to the device. But you can't get queuing at the host level if the guest device doesn't allow it, you'd be serializing anyway. Well for writes you can, but not synchronous requests. Basically allow as much to be sent to the host as possible. > On my todo list is: > 1) Implement write barriers, (-> fsync in the host) > 2) Make the host userspace program (lguest) async rather than blocking, > 3) Allow multiple outstanding requests. > > Then it should be useful for other hypervisors. I completely agree with your prioritized list. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [ckrm-tech] [PATCH 0/7] containers (V7): Generic Process Containers
On 2/12/07, Sam Vilain <[EMAIL PROTECTED]> wrote: Ask yourself this - what do you need the container structure for so badly, that virtualising the individual resources does not provide for? Primarily, that otherwise every module that wants to affect/monitor behaviour of a group of associated processes has to implement its own process grouping abstraction. As an example, the CPU accounting patch that in included in my patch set as an illustration of a simple resource monitoring module is just 250 lines, almost entirely in one file; if it also had to handle associating tasks together into groups and presenting a filesystem interface to the user it would be far larger and would have a much bigger footprint on the kernel. From the point of view of the virtual server containers, the advantage is that you're integrated with a standard filesystem interface for determining group membership. It does become simpler to combine virtual servers and resource controllers, although I grant you that you could juggle that from userspace without the additional kernel support. 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: SATA Drive No Longer Recognized In New 2.6.20 Kernel
On Mon, 12 Feb 2007 17:30:38 -0700 Joseph Cosby wrote: > Hi, > Until recently I was using the 2.6.18 kernel. I have a SATA hard drive > that was detected by the kernel, using the PIIX driver. But after > updating to 2.6.20, the hard drive is no longer detected by the kernel. > I used make oldconfig to create the 2.6.20 config file, and I noticed a > new option CONFIG_ATA. I did not use this, because as I understand it is > not necessary and is experimental. Do I need to use this or is there > something else in the new kernel that needs to be enabled for this > driver? Yes, you need CONFIG_ATA for SATA after 2.6.18. (prod) == production level code, not experimental (that only applies to the PATA drivers) > My 2.6.20 config file follows. > The hard drive has vendor ID 8086 and device ID 27c0. It is listed in the > modules.pcilist file of 2.6.18 but not 2.6.20. > > If anybody can share any advice please CC me in response. > > # > # Serial ATA (prod) and Parallel ATA (experimental) drivers > # > # CONFIG_ATA is not set --- ~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/
[PATCH] video4linux: Fix audio input for AverTv Go 007
from Damian Minkov
Fix audio input source for capturing(playing) audio on AverTv Go 007 cards.
Signed-off-by: Damian Minkov <[EMAIL PROTECTED]>
---
diff -upr a/linux/drivers/media/video/saa7134/saa7134-cards.c
b/linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c2007-02-13
02:17:55.0 +0200
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c2007-02-13
02:20:40.0 +0200
@@ -1544,12 +1544,12 @@ struct saa7134_board saa7134_boards[] =
},{
.name = name_comp1,
.vmux = 0,
-.amux = LINE2,
+.amux = LINE1,
.gpio = 0x02,
},{
.name = name_svideo,
.vmux = 6,
-.amux = LINE2,
+.amux = LINE1,
.gpio = 0x02,
}},
.radio = {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/9] Remove the TSC synchronization on SMP machines
On Fri, 2 Feb 2007, Andi Kleen wrote: > I've threatened to just disable RDTSC for ring 3 before, but it'll likely > never happen because too many programs use it. Those programs are aware that they are fiddling around with low level material but with this patchset we are going to have a non monotonic time subsystem? Programs expects gettimeofday() etc to be monotonic. Its going to a big surprise if that is not working anymore. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add an option for the VIA C7 which sets appropriate L1 cache
The VIA C7 is a 686 (with TSC) that supports MMX, SSE and SSE2, it also has a cache line length of 64 according to http://www.digit-life.com/articles2/cpu/rmma-via-c7.html. This patch sets gcc to -march=686 and selects the correct cache shift. This version adds it to include/asm-i386/module.h too so it will actually compile. Signed-off-by: Simon Arlott <[EMAIL PROTECTED]> --- arch/i386/Kconfig.cpu | 13 ++--- arch/i386/Makefile.cpu|1 + arch/i386/defconfig |1 + arch/um/defconfig |1 + include/asm-i386/module.h |2 ++ 5 files changed, 15 insertions(+), 3 deletions(-) diff --git a/arch/i386/Kconfig.cpu b/arch/i386/Kconfig.cpu index 2aecfba..194d8c2 100644 --- a/arch/i386/Kconfig.cpu +++ b/arch/i386/Kconfig.cpu @@ -43,6 +43,7 @@ config M386 - "Geode GX/LX" For AMD Geode GX and LX processors. - "CyrixIII/VIA C3" for VIA Cyrix III or VIA C3. - "VIA C3-2" for VIA C3-2 "Nehemiah" (model 9 and above). + - "VIA C7" for VIA C7. If you don't know what to do, choose "386". @@ -203,6 +204,12 @@ config MVIAC3_2 of SSE and tells gcc to treat the CPU as a 686. Note, this kernel will not boot on older (pre model 9) C3s. +config MVIAC7 + bool "VIA C7" + help + Select this for a VIA C7. Selecting this uses the correct cache + shift and tells gcc to treat the CPU as a 686. + endchoice config X86_GENERIC @@ -236,7 +243,7 @@ config X86_L1_CACHE_SHIFT default "7" if MPENTIUM4 || X86_GENERIC default "4" if X86_ELAN || M486 || M386 || MGEODEGX1 default "5" if MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCRUSOE || MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2 || MGEODE_LX - default "6" if MK7 || MK8 || MPENTIUMM || MCORE2 + default "6" if MK7 || MK8 || MPENTIUMM || MCORE2 || MVIAC7 config RWSEM_GENERIC_SPINLOCK bool @@ -302,7 +309,7 @@ config X86_ALIGNMENT_16 config X86_GOOD_APIC bool - depends on MK7 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || MK8 || MEFFICEON || MCORE2 + depends on MK7 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || MK8 || MEFFICEON || MCORE2 || MVIAC7 default y config X86_INTEL_USERCOPY @@ -327,5 +334,5 @@ config X86_OOSTORE config X86_TSC bool - depends on (MWINCHIP3D || MWINCHIP2 || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MGEODEGX1 || MGEODE_LX || MCORE2) && !X86_NUMAQ + depends on (MWINCHIP3D || MWINCHIP2 || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MVIAC7 || MGEODEGX1 || MGEODE_LX || MCORE2) && !X86_NUMAQ default y diff --git a/arch/i386/Makefile.cpu b/arch/i386/Makefile.cpu index a32c031..e0ada4e 100644 --- a/arch/i386/Makefile.cpu +++ b/arch/i386/Makefile.cpu @@ -32,6 +32,7 @@ cflags-$(CONFIG_MWINCHIP2)+= $(call cc- cflags-$(CONFIG_MWINCHIP3D)+= $(call cc-option,-march=winchip2,-march=i586) cflags-$(CONFIG_MCYRIXIII) += $(call cc-option,-march=c3,-march=i486) $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0 cflags-$(CONFIG_MVIAC3_2) += $(call cc-option,-march=c3-2,-march=i686) +cflags-$(CONFIG_MVIAC7)+= -march=i686 cflags-$(CONFIG_MCORE2)+= -march=i686 $(call cc-option,-mtune=core2,$(call cc-option,-mtune=generic,-mtune=i686)) # AMD Elan support diff --git a/arch/i386/defconfig b/arch/i386/defconfig index bb0c376..04001ab 100644 --- a/arch/i386/defconfig +++ b/arch/i386/defconfig @@ -137,6 +137,7 @@ # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set +# CONFIG_MVIAC7 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y diff --git a/arch/um/defconfig b/arch/um/defconfig index 780cc0a..f938fa8 100644 --- a/arch/um/defconfig +++ b/arch/um/defconfig @@ -41,6 +41,7 @@ # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set +# CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y diff --git a/include/asm-i386/module.h b/include/asm-i386/module.h index 02f8f54..7e5fda6 100644 --- a/include/asm-i386/module.h +++ b/include/asm-i386/module.h @@ -54,6 +54,8 @@ #elif defined CONFIG_MCYRIXIII #define MODULE_PROC_FAMILY "CYRIXIII " #elif defined CONFIG_MVIAC3_2 #define MODULE_PROC_FAMILY "VIAC3-2 " +#elif defined CONFIG_MVIAC7 +#define MODULE_PROC_FAMILY "VIAC7 " #elif defined CONFIG_MGEODEGX1 #define MODULE_PROC_FAMILY "GEODEGX1 " #elif defined CONFIG_MGEODE_LX -- 1.4.3.1 -- Simon Arlott signature.asc Description:
SATA Drive No Longer Recognized In New 2.6.20 Kernel
Hi, Until recently I was using the 2.6.18 kernel. I have a SATA hard drive that was detected by the kernel, using the PIIX driver. But after updating to 2.6.20, the hard drive is no longer detected by the kernel. I used make oldconfig to create the 2.6.20 config file, and I noticed a new option CONFIG_ATA. I did not use this, because as I understand it is not necessary and is experimental. Do I need to use this or is there something else in the new kernel that needs to be enabled for this driver? My 2.6.20 config file follows. The hard drive has vendor ID 8086 and device ID 27c0. It is listed in the modules.pcilist file of 2.6.18 but not 2.6.20. If anybody can share any advice please CC me in response. Thanks, Joseph # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20 # Fri Feb 9 11:19:48 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set # CONFIG_SWAP is not set CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set # CONFIG_KALLSYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y # CONFIG_ELF_CORE is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y # CONFIG_EPOLL is not set # CONFIG_SHMEM is not set CONFIG_SLAB=y # CONFIG_VM_EVENT_COUNTERS is not set CONFIG_RT_MUTEXES=y CONFIG_TINY_SHMEM=y CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y # CONFIG_IOSCHED_CFQ is not set # CONFIG_DEFAULT_AS is not set CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="deadline" # # Processor type and features # # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y # CONFIG_HPET_TIMER is not set CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # CONFIG_X86_MCE is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # CONFIG_EDD=m # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_3G_OPT is not set # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC000
Re: [PATCH 0/7] containers (V7): Generic Process Containers
Paul Menage wrote:
>> I know I'm a bit out of touch, but AIUI the NSProxy *is* the container.
>> We decided a long time ago that a container was basically just a set of
>> namespaces, which includes all of the subsystems you mention.
>>
> You may have done that, but the CKRM/ResGroups independently decided a
> long time ago that the fundamental unit was the resource class, and
> the OpenVZ folks decided that the fundamental unit was the
> BeanCounter, and the CPUSet folks decided that the fundamental unit
> was the CPUSet, etc ... :-)
>
There was a consensus that emerged that resulted in the nsproxy being
included in the kernel. That is why I used "we". What was included
varies greatly from the patch I put forward, as I mentioned.
You missed the point of what I was trying to say. Let me try again.
Originally I too thought that in order to begin on the path of
virtualisation merging we would just make a simple
container/vserver/whatever structure and hang everything off that.
I'll now say the same thing that was said before of my patch, that I
don't think that adding the containers structure inside the kernel adds
anything interesting or useful. In fact, I'd go further to say that
very thing you think is a useful abstraction is locking yourself into
inflexibility. This is what Eric recognised early on and eventually
brought me around to the idea of too.
So, we have the current implementation - individual subsystems are
virtualised, and it is the subsystems that you can see and work with.
You can group together your virtualisation decisions and call that a
container, great.
Ask yourself this - what do you need the container structure for so
badly, that virtualising the individual resources does not provide for?
You don't need it to copy the namespaces of another process ("enter")
and you don't need it for checkpoint/migration. What does it mean to
make a new container? You're making a "nothing" namespace for some
as-yet-unspecified grouping of tasks. That's a great idea for a set of
tightly integrated userland utilities to simplify the presentation to
the admin, but I don't see why you need to enshrine this in the kernel.
Certainly not for any of the other patches in your set as far as I can see.
> But there's a lot of common ground between these different approaches,
> and potential for synergy, so the point of this patch set is to
> provide a unification point for all of them, and a stepping stone for
> other new resource controllers and process control modules.
>
That precisely echos my sentiment on my submissions of some 12 months ago.
Sam.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: build error: allnoconfig fails on mincore/swapper_space
> oops. CONFIG_SWAP=n, I assume? Yes, sorry. Full config attached. Same breakage on "make allnoconfig" for ia64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/8] lguest: trivial guest block driver
On Mon, 2007-02-12 at 16:01 +0100, Jens Axboe wrote: > On Mon, Feb 12 2007, Rusty Russell wrote: > > Thanks Jens!! > > My pleasure, it's not often you get to make that big a performance > improvement with just a little few lines of change :-) *cough* I deliberately leave these low hanging fruit in lguest to encourage people to hack on it. Really. *cough* > I guess you'll take changes to make this driver queuing as well? It's > pretty important for good guest io performance as well. The question is whether the guest or host should queue. If you have multiple guests sharing a disk in the hose, I would think that the host is better off queuing. And this would seem to be the common case. On my todo list is: 1) Implement write barriers, (-> fsync in the host) 2) Make the host userspace program (lguest) async rather than blocking, 3) Allow multiple outstanding requests. Then it should be useful for other hypervisors. Cheers! Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 FUA revisited
Tejun Heo wrote: -Add a new port flag ATA_FLAG_NO_FUA to indicate that a controller can't handle FUA commands, and add that flag to sata_sil. Force FUA off on any drive connected to a controller with this bit set. There was some talk that sata_mv might have this problem, but I believe the conclusion was that it didn't. The only controllers that would are ones that actually try to interpret the ATA command codes and don't know about WRITE DMA FUA. I think it would be better to add ATA_FLAG_FUA instead of ATA_FLAG_NO_FUA. I'm not sure about that, it appears that the number of controllers that have problems is much lower than the number that don't, so this would just need to be added to almost every driver. Especially since the non-NCQ FUA which was problematic on SiI in the past isn't being switched on by default. -Change the fua module option to control FUA enable/disable to have a third value, "enable for NCQ-supporting drives only", which would become the new default. That case seems less likely to cause problems since FUA on NCQ is just another bit in the command whereas FUA on non-NCQ is an entirely different, potentially unsupported command. Not enabling FUA doesn't result in huge performance hit. I'm not sure whether we should go such far. Just supporting FUA on known good controllers sounds good enough to me. On the NCQ side, I think it's pretty safe to assume that all controllers will handle it. Obviously I've verified it with sata_nv (at least that it doesn't blow up obviously), and the other two NCQ drivers we have, ahci and sata_sil24 just feed raw FIS data into the controller so there should be no issue with not supporting it. Assuming that we leave FUA off by default for non-NCQ for the foreseeable future, is there really much concern here? Any comments? As an aside, I came across a comment that the Silicon Image Windows drivers for NCQ-supporting controllers have some blacklist entries for drives with broken NCQ in their .inf files. We only seem to have one in the libata NCQ blacklist, we may want to add some more of these. The ones in the current SiI3124 and 3132 drivers' .inf files for "DisableSataQueueing" appear to be: ModelFirmware Maxtor 7B250S0BANC1B70 HTS541060G9SA00MB3OC60D HTS541080G9SA00MB4OC60D HTS541010G9SA00MBZOC60D (the latter 3 being Hitachi Travelstar drives) Yeah, I don't think we need to be too careful about blacklisting NCQ considering the sorry state of many early NCQ firmwares. Please submit a patch. It would be nice if you add a comment why the drives are added for documentation. Will do shortly. Eric, do you have any info on the blacklisting of that Maxtor 7B250S0 drive? I would hope that Silicon Image would have a good reason for blacklisting that one.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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 2.6.21 review I] [11/25] x86: default to physical mode on hotplug CPU kernels
On Mon, Feb 12, 2007 at 04:10:44PM -0700, Eric W. Biederman wrote: > Basically as I commented in genapic_flat, that at least on hyperthreading > cpus the destination mask is not always honored, and so if you only > allow one hyperthread I have seen the irq show up on the other hyperthread. Which platform is this? I haven't heard this before. thanks, suresh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/3, resend] kbuild: correctly skip tilded backups in localversion files
On Mon, Feb 12, 2007 at 02:53:29PM -0800, Linus Torvalds wrote: Hallo. > On Mon, 12 Feb 2007, Tony Luck wrote: > > > > Git bisect fingers this patch (which is in Linus' tree as commit > > 76c329563c5b8663ef27eb1bd195885ab826cbd0) as the culprit > > for double adding the contents of the localversion file. E.g. > > > > $ echo -tiger-smp > localversion > > $ make prepare > > $ make kernelrelease > > 2.6.20-tiger-smp-tiger-smp > > Heh. It's because we search for the localversion files in both $objtree > and $srctree, and normally they are one and the same - so it finds the > same file twice. > > The old code did the same thing, but with the "make" $(sort ..) function, > which apparently removes duplicates. We should use "sort -u" here. Heh. Why one ever going to bloat $(srctree) to add more "dontdiff" and such, where build is supporting dirty output? While this is my mis-tesing, > Both the old code *and* the new code is just horribly complex. The old > code appears to suffer from GNU $(wildcard ..), the new code is almost as > ugly in doing an unnecessarily complex "find". any reasons to have multiple files for localversion(s), in $(objtree) also? Exept one, that somebody used to use it, mm-tree doesn't btw. As i opposed to Romans's "make" solution, because it wasn't obvious, i agree current has heavy `find', but what else you can propose? I think, it's not make's job after all. > Oh well. Thanks for testing! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Coding style RFC: convert "for (i=0;i
Joe Perches wrote: Now that most of the sizeof(array)/sizeof(array[0]) conversions have been done (there are about 800 done and about another 130 left), perhaps it could be useful to change the code to use a define similar to the list_for_each #define list_for_each(pos, head) \ for (pos = (head)->next; prefetch(pos->next), pos != (head); \ pos = pos->next) perhaps #define array_for_each(index, array) \ for ((index) = 0; (index) < ARRAY_SIZE((array)); (index)++) I like the idea, my only concern would be potential confusion. That is, the list_for_each macro sets pos to each list_head in turn where array_for_each just sets the index /in to/ the array. While I think the way you have is nicer, for compatibility between the two styles maybe something more like #define array_for_each(element, array) \ for (int __idx = 0; __idx < ARRAY_SIZE((array)); \ __idx++, (element) = &(array[__idx])) would help. Of course the other option is to name array_for_each something different to avoid comparisons with list_for_each. --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/
[GIT PULL] please pull infiniband.git
Linus, please pull from master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus This tree is also available from kernel.org mirrors at: git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-linus This will add the new cxgb3 RDMA driver for Chelsio T3 NICs, as well as IPoIB connected mode and various other smaller changes: Ahmed S. Darwish (1): IB/core: Use ARRAY_SIZE macro for mandatory_table Akinobu Mita (1): IB/ehca: Fix memleak on module unloading David Howells (1): IB/mthca: Work around gcc bug on sparc64 Michael S. Tsirkin (6): IPoIB: Connected mode experimental support IB/mthca: Fix reserved MTTs calculation on mem-free HCAs IB/mthca: Give reserved MTTs a separate cache line IB/mthca: Fix access to MTT and MPT tables on non-cache-coherent CPUs IB/mthca: Merge MR and FMR space on 64-bit systems IB/mthca: Always fill MTTs from CPU Roland Dreier (1): IB/mthca: Use correct structure size in call to memset() Sean Hefty (2): RDMA/cma: Increment port number after close to avoid re-use IB: Remove redundant "_wq" from workqueue names Steve Wise (1): RDMA/cxgb3: Add driver for Chelsio T3 RNIC drivers/infiniband/Kconfig |1 + drivers/infiniband/Makefile|1 + drivers/infiniband/core/addr.c |2 +- drivers/infiniband/core/cma.c | 68 +- drivers/infiniband/core/device.c |3 +- drivers/infiniband/hw/cxgb3/Kconfig| 27 + drivers/infiniband/hw/cxgb3/Makefile | 12 + drivers/infiniband/hw/cxgb3/cxio_dbg.c | 207 +++ drivers/infiniband/hw/cxgb3/cxio_hal.c | 1280 +++ drivers/infiniband/hw/cxgb3/cxio_hal.h | 201 +++ drivers/infiniband/hw/cxgb3/cxio_resource.c| 331 drivers/infiniband/hw/cxgb3/cxio_resource.h| 70 + drivers/infiniband/hw/cxgb3/cxio_wr.h | 685 drivers/infiniband/hw/cxgb3/iwch.c | 189 +++ drivers/infiniband/hw/cxgb3/iwch.h | 177 ++ drivers/infiniband/hw/cxgb3/iwch_cm.c | 2081 drivers/infiniband/hw/cxgb3/iwch_cm.h | 223 +++ drivers/infiniband/hw/cxgb3/iwch_cq.c | 225 +++ drivers/infiniband/hw/cxgb3/iwch_ev.c | 231 +++ drivers/infiniband/hw/cxgb3/iwch_mem.c | 172 ++ drivers/infiniband/hw/cxgb3/iwch_provider.c| 1203 ++ drivers/infiniband/hw/cxgb3/iwch_provider.h| 367 + drivers/infiniband/hw/cxgb3/iwch_qp.c | 1007 drivers/infiniband/hw/cxgb3/iwch_user.h| 67 + drivers/infiniband/hw/cxgb3/tcb.h | 632 +++ drivers/infiniband/hw/ehca/ehca_irq.c |2 + drivers/infiniband/hw/mthca/mthca_cmd.c|6 +- drivers/infiniband/hw/mthca/mthca_dev.h|2 + drivers/infiniband/hw/mthca/mthca_main.c | 40 +- drivers/infiniband/hw/mthca/mthca_memfree.c| 127 ++- drivers/infiniband/hw/mthca/mthca_memfree.h|9 +- drivers/infiniband/hw/mthca/mthca_mr.c | 110 ++- drivers/infiniband/hw/mthca/mthca_profile.c|2 +- drivers/infiniband/hw/mthca/mthca_provider.c | 14 +- drivers/infiniband/hw/mthca/mthca_provider.h |1 + drivers/infiniband/hw/mthca/mthca_qp.c |2 +- drivers/infiniband/hw/mthca/mthca_srq.c|9 +- drivers/infiniband/ulp/ipoib/Kconfig | 16 +- drivers/infiniband/ulp/ipoib/Makefile |1 + drivers/infiniband/ulp/ipoib/ipoib.h | 215 +++ drivers/infiniband/ulp/ipoib/ipoib_cm.c| 1237 ++ drivers/infiniband/ulp/ipoib/ipoib_ib.c| 29 +- drivers/infiniband/ulp/ipoib/ipoib_main.c | 63 +- drivers/infiniband/ulp/ipoib/ipoib_multicast.c |4 +- drivers/infiniband/ulp/ipoib/ipoib_verbs.c | 40 +- drivers/infiniband/ulp/ipoib/ipoib_vlan.c |2 + 46 files changed, 11279 insertions(+), 114 deletions(-) create mode 100644 drivers/infiniband/hw/cxgb3/Kconfig create mode 100644 drivers/infiniband/hw/cxgb3/Makefile create mode 100644 drivers/infiniband/hw/cxgb3/cxio_dbg.c create mode 100644 drivers/infiniband/hw/cxgb3/cxio_hal.c create mode 100644 drivers/infiniband/hw/cxgb3/cxio_hal.h create mode 100644 drivers/infiniband/hw/cxgb3/cxio_resource.c create mode 100644 drivers/infiniband/hw/cxgb3/cxio_resource.h create mode 100644 drivers/infiniband/hw/cxgb3/cxio_wr.h create mode 100644 drivers/infiniband/hw/cxgb3/iwch.c create mode 100644 drivers/infiniband/hw/cxgb3/iwch.h create mode 100644 drivers/infiniband/hw/cxgb3/iwch_cm.c create mode 100644 drivers/infiniband/hw/cxgb3/iwch_cm.h create mode 100644 drivers/infiniband/hw/cxgb3/iwch_cq.c create mode 100644 drivers/infiniband/hw/cxgb3/iwch_ev.c create mode 100644 drivers/infiniband/hw/cxgb3/iwch_mem.c create mode 100644 drivers/infiniband/hw/cxgb3/iwch_provider.c
Re: [PATCH 2.6.21 review I] [11/25] x86: default to physical mode on hotplug CPU kernels
On Mon, Feb 12, 2007 at 11:36:23PM +0100, Andi Kleen wrote: > True, that seems to be missing. > > I agree that the patch seems to consist mostly of renaming doesn't make > it any easier to read. > > And it's worrying that it doesn't handle the hotplug case at all. This patch is mostly a cleanup patch and doesn't have to do anything with hotplug. I think the change log comment about hotplug kernel is a leftover from an old patch. > But I'm tempted to drop this unless the hotplug mystery can be cleared > up. There was past information that logical is unsafe for hotplug. > > Ingo? Suresh? logical clustered mode has problems with cpu hotplug. ( http://marc.theaimsgroup.com/?l=linux-kernel=113261865814107=2 ) I think logical flat is fine. We should be fine in logical flat, as long as we are not using apic IPI shortcuts. thanks, suresh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Add an option for the VIA C7 which sets appropriate L1 cache
The VIA C7 is a 686 (with TSC) that supports MMX, SSE and SSE2, it also has a cache line length of 64 according to http://www.digit-life.com/articles2/cpu/rmma-via-c7.html. This patch sets gcc to -march=686 and selects the correct cache shift. Signed-off-by: Simon Arlott <[EMAIL PROTECTED]> --- arch/i386/Kconfig.cpu | 13 ++--- arch/i386/Makefile.cpu |1 + 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/arch/i386/Kconfig.cpu b/arch/i386/Kconfig.cpu index 2aecfba..194d8c2 100644 --- a/arch/i386/Kconfig.cpu +++ b/arch/i386/Kconfig.cpu @@ -43,6 +43,7 @@ config M386 - "Geode GX/LX" For AMD Geode GX and LX processors. - "CyrixIII/VIA C3" for VIA Cyrix III or VIA C3. - "VIA C3-2" for VIA C3-2 "Nehemiah" (model 9 and above). + - "VIA C7" for VIA C7. If you don't know what to do, choose "386". @@ -203,6 +204,12 @@ config MVIAC3_2 of SSE and tells gcc to treat the CPU as a 686. Note, this kernel will not boot on older (pre model 9) C3s. +config MVIAC7 + bool "VIA C7" + help + Select this for a VIA C7. Selecting this uses the correct cache + shift and tells gcc to treat the CPU as a 686. + endchoice config X86_GENERIC @@ -236,7 +243,7 @@ config X86_L1_CACHE_SHIFT default "7" if MPENTIUM4 || X86_GENERIC default "4" if X86_ELAN || M486 || M386 || MGEODEGX1 default "5" if MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCRUSOE || MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2 || MGEODE_LX - default "6" if MK7 || MK8 || MPENTIUMM || MCORE2 + default "6" if MK7 || MK8 || MPENTIUMM || MCORE2 || MVIAC7 config RWSEM_GENERIC_SPINLOCK bool @@ -302,7 +309,7 @@ config X86_ALIGNMENT_16 config X86_GOOD_APIC bool - depends on MK7 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || MK8 || MEFFICEON || MCORE2 + depends on MK7 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || MK8 || MEFFICEON || MCORE2 || MVIAC7 default y config X86_INTEL_USERCOPY @@ -327,5 +334,5 @@ config X86_OOSTORE config X86_TSC bool - depends on (MWINCHIP3D || MWINCHIP2 || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MGEODEGX1 || MGEODE_LX || MCORE2) && !X86_NUMAQ + depends on (MWINCHIP3D || MWINCHIP2 || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MVIAC7 || MGEODEGX1 || MGEODE_LX || MCORE2) && !X86_NUMAQ default y diff --git a/arch/i386/Makefile.cpu b/arch/i386/Makefile.cpu index a32c031..e0ada4e 100644 --- a/arch/i386/Makefile.cpu +++ b/arch/i386/Makefile.cpu @@ -32,6 +32,7 @@ cflags-$(CONFIG_MWINCHIP2)+= $(call cc- cflags-$(CONFIG_MWINCHIP3D)+= $(call cc-option,-march=winchip2,-march=i586) cflags-$(CONFIG_MCYRIXIII) += $(call cc-option,-march=c3,-march=i486) $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0 cflags-$(CONFIG_MVIAC3_2) += $(call cc-option,-march=c3-2,-march=i686) +cflags-$(CONFIG_MVIAC7)+= -march=i686 cflags-$(CONFIG_MCORE2)+= -march=i686 $(call cc-option,-mtune=core2,$(call cc-option,-mtune=generic,-mtune=i686)) # AMD Elan support -- 1.4.3.1 -- Simon Arlott signature.asc Description: OpenPGP digital signature
Re: 2.6.19.1: kernel BUG at mm/slab.c:2911!
On Tue, 30 Jan 2007, Martin MOKREJ wrote: > Hi, > is this a known issue? Should I bother to upgrade to 2.6.19.2 if it > contains the fix? > Thank you any help. It might be related to NFS. The machine in question is > NFSv3 client, > udp. And used for computations. The process which died is from torque cluster > management > package. > 000: 00 00 00 00 fe ff ff ff fe ff ff ff 3a 00 00 00 The beginning of the slab was overwritten. The first two words should have been list pointers. color offset is also invalid as is the pointer to the slab memory. Are you using cpu hotplug by chance? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Which CPU for VIA C7/Esther?
On Mon, Feb 12, 2007 at 11:46:46PM +, Simon Arlott wrote: > MVIAC3_2 doesn't enable X86_GOOD_APIC which is pretty irrelevant unless you have a dual C7. > , try M686 (Pentium-Pro) - but that won't enable MMX and SSE (via > -march=c3-2). If gcc generated SSE/MMX instructions that would be a bug. (hint: it doesn't). > These CPUs support SSE2 too... The SSE/SSE2/SSE3 etc support for userspace is unconditional. The context switch paths will save/restore the registers regardless of the CPU you've compiled your kernel for. The only SSE code in the kernel is the memcpy code (which wasn't that big a win when I last tried it on VIA due to their poor memory bandwidth), and the RAID code, which gets tested at runtime rather than compile time. > Also, for the C7 you'll want CRYPTO_DEV_PADLOCK_* (Hardware Crypto Devices, > Support for VIA PadLock ACE) and HW_RANDOM_VIA (VIA HW Random Number > Generator support). Yes. But these aren't dependant on any CPU config options. 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: [RFC][PATCH] PM: Document requirements for basic PM support in drivers
Hi.
On Tue, 2007-02-13 at 00:23 +0100, Rafael J. Wysocki wrote:
> Hi,
>
> Here's my attempt to document the requirements with respect to the basic PM
> support in drivers and the testing of that. Comments welcome.
>
> Greetings,
> Rafael
>
> ---
> Documentation/SubmittingDrivers | 10 ++
> Documentation/power/drivers-testing.txt | 119
>
> 2 files changed, 129 insertions(+)
>
> Index: linux-2.6.20-git4/Documentation/SubmittingDrivers
> ===
> --- linux-2.6.20-git4.orig/Documentation/SubmittingDrivers
> +++ linux-2.6.20-git4/Documentation/SubmittingDrivers
> @@ -87,6 +87,16 @@ Clarity: It helps if anyone can see how
> driver that intentionally obfuscates how the hardware works
> it will go in the bitbucket.
>
> +PM support: Since Linux is used on many portable and desktop systems, your
> + driver is likely to be used on such a system and therefore it
> + should support basic power management by implementing, if
> + necessary, the .suspend and .resume methods used during the
> + system-wide suspend and resume transitions. You should verify
> + that your driver correctly handles the suspend and resume, but
> + if you are unable to ensure that, please at least define the
> + .suspend method returning the -ENOSYS ("Function not
> + implemented") error.
> +
> Control: In general if there is active maintainance of a driver by
> the author then patches will be redirected to them unless
> they are totally obvious and without need of checking.
> Index: linux-2.6.20-git4/Documentation/power/drivers-testing.txt
> ===
> --- /dev/null
> +++ linux-2.6.20-git4/Documentation/power/drivers-testing.txt
> @@ -0,0 +1,119 @@
> +Testing suspend and resume support in drivers
> + (C) 2007 Rafael J. Wysocki <[EMAIL PROTECTED]>
> +
> +Unfortunately, to effectively test the support for the system-wide suspend
> and
> +resume transitions in a driver, it is necessary to suspend and resume a fully
> +functional system with this driver loaded. Moreover, that should be done
> many
> +times, preferably many times in a row, and separately for the suspend to disk
> +(STD) and the suspend to RAM (STR) transitions, because each of these cases
> +involves different ordering of operations and different interactions with the
> +machine's BIOS.
> +
> +Of course, for this purpose the test system has to be known to suspend and
> +resume without the driver being tested. Thus, if possible, you should first
> +resolve all suspend/resume-related problems in the test system before you
> start
> +testing the new driver.
> +
> +I. Preparing the test system
> +
> +1. To verify that the STD works, you can try to suspend in the "reboot" mode:
> +
> +# echo reboot > /sys/power/disk
> +# echo disk > /sys/power/state
> +
> +and the system should suspend, reboot, resume and get back to the command
> prompt
> +where you have started the transition. If that happens, the STD is most
> likely
> +to work correctly, but you can repeat the test a couple of times in a row for
> +confidence. You should also test the "platform" and "shutdown" modes of
I would say "you need to repeat the test at least a couple of times...",
perhaps adding something along the lines of "This is necessary because
some problems only show up on a second attempt at suspending and
resuming a driver. You can think of it as the driver coming back 'dazed
and confused' after the first cycle, and only being properly killed by
the second attempt."
> +suspend:
> +
> +# echo platform > /sys/power/disk
> +# echo disk > /sys/power/state
> +
> +or
> +
> +# echo shutdown > /sys/power/disk
> +# echo disk > /sys/power/state
> +
> +in which cases you will have to press the power button to make the system
> +resume. If that works, you are ready to test the STD with the new driver
> +loaded. Otherwise, you have to identify what is wrong.
> +
> +a) To verify if there are any drivers that cause problems you can run the STD
> +in the test mode:
> +
> +# echo test > /sys/power/disk
> +# echo disk > /sys/power/state
> +
> +in which case the system should freeze tasks, suspend devices, disable
> nonboot
> +CPUs (if any), wait for 5 seconds, enable nonboot CPUs, resume devices, thaw
> +tasks and return to your command prompt. If that fails, most likely there is
> +a driver that fails to either suspend or resume (in the latter case the
> system
> +may hang or be unstable after the test, so please take that into
> consideration).
> +To find this driver, you can carry out a binary search according to the
> rules:
> +- if the test fails, unload a half of the drivers currently loaded and repeat
> +(that would probably involve rebooting the system, so always note what
Re: [PATCH] drivers/isdn/gigaset: new M101 driver
Am 12.02.2007 19:47 schrieb Greg KH:
> +static void gigaset_device_release(struct device *dev)
> +{
> + //FIXME anything to do? cf. platform_device_release()
> +}
> The memory of the platform device itself needs to be freed here,
> otherwise, to do it earlier would cause race conditions and oopses.
I don't do it earlier. I do it later. My platform_device structure
is part of my driver's device state structure which is freed
explicitly later after the call to platform_device_unregister().
Is that bad?
> Look at how the other platform drivers do things.
They do things differently from each other as well as from mine.
block/floppy.c, for example, just has a call to complete() there.
Anyway, in the latest version of my driver, its platform_device
release function finally does something, too: it frees
dev->platform_data and pdev->resource just in case something
might have materialized there. I hope that's ok.
Regards,
Tilman
--
Tilman Schmidt E-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
signature.asc
Description: OpenPGP digital signature
Coding style RFC: convert "for (i=0;i
Now that most of the sizeof(array)/sizeof(array[0]) conversions have been done (there are about 800 done and about another 130 left), perhaps it could be useful to change the code to use a define similar to the list_for_each #define list_for_each(pos, head) \ for (pos = (head)->next; prefetch(pos->next), pos != (head); \ pos = pos->next) perhaps #define array_for_each(index, array) \ for ((index) = 0; (index) < ARRAY_SIZE((array)); (index)++) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 008 of 9] knfsd: nfsd4: acls: avoid unnecessary denies
From: J. Bruce Fields <[EMAIL PROTECTED]>
We're inserting deny's between some ACEs in order to enforce posix draft
acl semantics which prevent permissions from accumulating across entries
in an acl.
That's fine, but we're doing that by inserting a deny after *every* allow,
which is overkill. We shouldn't be adding them in places where they
actually make no difference.
Also replaced some helper functions for creating acl entries; I prefer
just assigning directly to the struct fields--it takes a few more lines,
but the field names provide some documentation that I think makes the
result easier understand.
Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./fs/nfsd/nfs4acl.c | 190 +++-
1 file changed, 145 insertions(+), 45 deletions(-)
diff .prev/fs/nfsd/nfs4acl.c ./fs/nfsd/nfs4acl.c
--- .prev/fs/nfsd/nfs4acl.c 2007-02-13 10:37:27.0 +1100
+++ ./fs/nfsd/nfs4acl.c 2007-02-13 10:38:09.0 +1100
@@ -89,12 +89,19 @@ mask_from_posix(unsigned short perm, uns
}
static u32
-deny_mask(u32 allow_mask, unsigned int flags)
+deny_mask_from_posix(unsigned short perm, u32 flags)
{
- u32 ret = ~allow_mask & ~NFS4_MASK_UNSUPP;
- if (!(flags & NFS4_ACL_DIR))
- ret &= ~NFS4_ACE_DELETE_CHILD;
- return ret;
+ u32 mask = 0;
+
+ if (perm & ACL_READ)
+ mask |= NFS4_READ_MODE;
+ if (perm & ACL_WRITE)
+ mask |= NFS4_WRITE_MODE;
+ if ((perm & ACL_WRITE) && (flags & NFS4_ACL_DIR))
+ mask |= NFS4_ACE_DELETE_CHILD;
+ if (perm & ACL_EXECUTE)
+ mask |= NFS4_EXECUTE_MODE;
+ return mask;
}
/* XXX: modify functions to return NFS errors; they're only ever
@@ -164,14 +171,51 @@ nfs4_acl_posix_to_nfsv4(struct posix_acl
return acl;
}
+struct posix_acl_summary {
+ unsigned short owner;
+ unsigned short users;
+ unsigned short group;
+ unsigned short groups;
+ unsigned short other;
+ unsigned short mask;
+};
+
static void
-nfs4_acl_add_pair(struct nfs4_acl *acl, int eflag, u32 mask, int whotype,
- uid_t owner, unsigned int flags)
+summarize_posix_acl(struct posix_acl *acl, struct posix_acl_summary *pas)
{
- nfs4_acl_add_ace(acl, NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE,
-eflag, mask, whotype, owner);
- nfs4_acl_add_ace(acl, NFS4_ACE_ACCESS_DENIED_ACE_TYPE,
- eflag, deny_mask(mask, flags), whotype, owner);
+ struct posix_acl_entry *pa, *pe;
+ pas->users = 0;
+ pas->groups = 0;
+ pas->mask = 07;
+
+ pe = acl->a_entries + acl->a_count;
+
+ FOREACH_ACL_ENTRY(pa, acl, pe) {
+ switch (pa->e_tag) {
+ case ACL_USER_OBJ:
+ pas->owner = pa->e_perm;
+ break;
+ case ACL_GROUP_OBJ:
+ pas->group = pa->e_perm;
+ break;
+ case ACL_USER:
+ pas->users |= pa->e_perm;
+ break;
+ case ACL_GROUP:
+ pas->groups |= pa->e_perm;
+ break;
+ case ACL_OTHER:
+ pas->other = pa->e_perm;
+ break;
+ case ACL_MASK:
+ pas->mask = pa->e_perm;
+ break;
+ }
+ }
+ /* We'll only care about effective permissions: */
+ pas->users &= pas->mask;
+ pas->group &= pas->mask;
+ pas->groups &= pas->mask;
}
/* We assume the acl has been verified with posix_acl_valid. */
@@ -179,30 +223,63 @@ static void
_posix_to_nfsv4_one(struct posix_acl *pacl, struct nfs4_acl *acl,
unsigned int flags)
{
- struct posix_acl_entry *pa, *pe, *group_owner_entry;
- u32 mask;
- unsigned short mask_mask;
+ struct posix_acl_entry *pa, *group_owner_entry;
+ struct nfs4_ace *ace;
+ struct posix_acl_summary pas;
+ unsigned short deny;
int eflag = ((flags & NFS4_ACL_TYPE_DEFAULT) ?
NFS4_INHERITANCE_FLAGS : 0);
BUG_ON(pacl->a_count < 3);
- pe = pacl->a_entries + pacl->a_count;
- pa = pe - 2; /* if mask entry exists, it's second from the last. */
- if (pa->e_tag == ACL_MASK)
- mask_mask = pa->e_perm;
- else
- mask_mask = S_IRWXO;
+ summarize_posix_acl(pacl, );
pa = pacl->a_entries;
- BUG_ON(pa->e_tag != ACL_USER_OBJ);
- mask = mask_from_posix(pa->e_perm, flags | NFS4_ACL_OWNER);
- nfs4_acl_add_pair(acl, eflag, mask,
Re: Which CPU for VIA C7/Esther?
On 12/02/07 20:16, Dave Jones wrote: > On Mon, Feb 12, 2007 at 02:14:41PM -0500, Kyle McMartin wrote: > > On Mon, Feb 12, 2007 at 06:37:38PM +0100, Mark de Vries wrote: > > > I've been googeling for about an hour now and can't find an answer to: > > > What type of CPU should I select when compiling a recent 2.6 kernel if I > > > have a VIA Esther CPU? > > > > > stepping: 9 > > > > config MVIAC3_2 > > bool "VIA C3-2 (Nehemiah)" > > help > > Select this for a VIA C3 "Nehemiah". Selecting this enables usage > > of SSE and tells gcc to treat the CPU as a 686. > > Note, this kernel will not boot on older (pre model 9) C3s. > > > > Is the one you want, I believe. > > The C7 doesn't seem to care much which you optimise it for. > Any of the 686 options should work just fine, but MVIAC3_2 is no > worse than any of the others. > MVIAC3_2 doesn't enable X86_GOOD_APIC, try M686 (Pentium-Pro) - but that won't enable MMX and SSE (via -march=c3-2). These CPUs support SSE2 too... there should probably be an option for C7 that passes 686/mmx/sse/sse2 to gcc. (The c3-2 option could even cause gcc to alter code for the C3-2 that's not necessary for the C7, but I've not checked what else gcc does with -march=c3-2). Also, for the C7 you'll want CRYPTO_DEV_PADLOCK_* (Hardware Crypto Devices, Support for VIA PadLock ACE) and HW_RANDOM_VIA (VIA HW Random Number Generator support). -- Simon Arlott signature.asc Description: OpenPGP digital signature
[PATCH 007 of 9] knfsd: nfsd4: acls: don't return explicit mask
From: J. Bruce Fields <[EMAIL PROTECTED]>
Return just the effective permissions, and forget about the mask. It isn't
worth the complexity.
WARNING: This breaks backwards compatibility with overly-picky nfsv4->posix acl
translation, as may has been included in some patched versions of libacl. To
our knowledge no such version was every distributed by anyone outside citi.
Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./fs/nfsd/nfs4acl.c | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff .prev/fs/nfsd/nfs4acl.c ./fs/nfsd/nfs4acl.c
--- .prev/fs/nfsd/nfs4acl.c 2007-02-13 10:23:49.0 +1100
+++ ./fs/nfsd/nfs4acl.c 2007-02-13 10:37:27.0 +1100
@@ -180,7 +180,8 @@ _posix_to_nfsv4_one(struct posix_acl *pa
unsigned int flags)
{
struct posix_acl_entry *pa, *pe, *group_owner_entry;
- u32 mask, mask_mask;
+ u32 mask;
+ unsigned short mask_mask;
int eflag = ((flags & NFS4_ACL_TYPE_DEFAULT) ?
NFS4_INHERITANCE_FLAGS : 0);
@@ -188,9 +189,9 @@ _posix_to_nfsv4_one(struct posix_acl *pa
pe = pacl->a_entries + pacl->a_count;
pa = pe - 2; /* if mask entry exists, it's second from the last. */
if (pa->e_tag == ACL_MASK)
- mask_mask = deny_mask(mask_from_posix(pa->e_perm, flags),
flags);
+ mask_mask = pa->e_perm;
else
- mask_mask = 0;
+ mask_mask = S_IRWXO;
pa = pacl->a_entries;
BUG_ON(pa->e_tag != ACL_USER_OBJ);
@@ -199,10 +200,7 @@ _posix_to_nfsv4_one(struct posix_acl *pa
pa++;
while (pa->e_tag == ACL_USER) {
- mask = mask_from_posix(pa->e_perm, flags);
- nfs4_acl_add_ace(acl, NFS4_ACE_ACCESS_DENIED_ACE_TYPE,
- eflag, mask_mask, NFS4_ACL_WHO_NAMED,
pa->e_id);
-
+ mask = mask_from_posix(pa->e_perm & mask_mask, flags);
nfs4_acl_add_pair(acl, eflag, mask,
NFS4_ACL_WHO_NAMED, pa->e_id, flags);
pa++;
@@ -213,24 +211,15 @@ _posix_to_nfsv4_one(struct posix_acl *pa
/* allow ACEs */
- if (pacl->a_count > 3) {
- BUG_ON(pa->e_tag != ACL_GROUP_OBJ);
- nfs4_acl_add_ace(acl, NFS4_ACE_ACCESS_DENIED_ACE_TYPE,
- NFS4_ACE_IDENTIFIER_GROUP | eflag, mask_mask,
- NFS4_ACL_WHO_GROUP, 0);
- }
group_owner_entry = pa;
- mask = mask_from_posix(pa->e_perm, flags);
+ mask = mask_from_posix(pa->e_perm & mask_mask, flags);
nfs4_acl_add_ace(acl, NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE,
NFS4_ACE_IDENTIFIER_GROUP | eflag, mask,
NFS4_ACL_WHO_GROUP, 0);
pa++;
while (pa->e_tag == ACL_GROUP) {
- mask = mask_from_posix(pa->e_perm, flags);
- nfs4_acl_add_ace(acl, NFS4_ACE_ACCESS_DENIED_ACE_TYPE,
- NFS4_ACE_IDENTIFIER_GROUP | eflag, mask_mask,
- NFS4_ACL_WHO_NAMED, pa->e_id);
+ mask = mask_from_posix(pa->e_perm & mask_mask, flags);
nfs4_acl_add_ace(acl, NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE,
NFS4_ACE_IDENTIFIER_GROUP | eflag, mask,
NFS4_ACL_WHO_NAMED, pa->e_id);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 009 of 9] knfsd: nfsd4: fix handling of directories without default ACLs
From: J. Bruce Fields <[EMAIL PROTECTED]>
When setting an ACL that lacks inheritable ACEs on a directory, we
should set a default ACL of zero length, not a default ACL with all bits
denied.
Signed-off-by: "J. Bruce Fields" <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./fs/nfsd/nfs4acl.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff .prev/fs/nfsd/nfs4acl.c ./fs/nfsd/nfs4acl.c
--- .prev/fs/nfsd/nfs4acl.c 2007-02-13 10:38:09.0 +1100
+++ ./fs/nfsd/nfs4acl.c 2007-02-13 10:38:26.0 +1100
@@ -416,6 +416,7 @@ struct posix_ace_state_array {
* calculated so far: */
struct posix_acl_state {
+ int empty;
struct posix_ace_state owner;
struct posix_ace_state group;
struct posix_ace_state other;
@@ -431,6 +432,7 @@ init_state(struct posix_acl_state *state
int alloc;
memset(state, 0, sizeof(struct posix_acl_state));
+ state->empty = 1;
/*
* In the worst case, each individual acl could be for a distinct
* named user or group, but we don't no which, so we allocate
@@ -498,6 +500,20 @@ posix_state_to_acl(struct posix_acl_stat
int nace;
int i, error = 0;
+ /*
+* ACLs with no ACEs are treated differently in the inheritable
+* and effective cases: when there are no inheritable ACEs, we
+* set a zero-length default posix acl:
+*/
+ if (state->empty && (flags & NFS4_ACL_TYPE_DEFAULT)) {
+ pacl = posix_acl_alloc(0, GFP_KERNEL);
+ return pacl ? pacl : ERR_PTR(-ENOMEM);
+ }
+ /*
+* When there are no effective ACEs, the following will end
+* up setting a 3-element effective posix ACL with all
+* permissions zero.
+*/
nace = 4 + state->users->n + state->groups->n;
pacl = posix_acl_alloc(nace, GFP_KERNEL);
if (!pacl)
@@ -613,6 +629,8 @@ static void process_one_v4_ace(struct po
u32 mask = ace->access_mask;
int i;
+ state->empty = 0;
+
switch (ace2type(ace)) {
case ACL_USER_OBJ:
if (ace->type == NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE) {
@@ -717,7 +735,8 @@ int nfs4_acl_nfsv4_to_posix(struct nfs4_
ret = PTR_ERR(*pacl);
goto out_dstate;
}
- *dpacl = posix_state_to_acl(_acl_state, flags);
+ *dpacl = posix_state_to_acl(_acl_state,
+ flags | NFS4_ACL_TYPE_DEFAULT);
if (IS_ERR(*dpacl)) {
ret = PTR_ERR(*dpacl);
posix_acl_release(*pacl);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 003 of 9] knfsd: nfsd4: simplify nfsv4->posix translation
From: J. Bruce Fields <[EMAIL PROTECTED]>
The code that splits an incoming nfsv4 ACL into inheritable and effective parts
can be combined with the the code that translates each to a posix acl,
resulting in simpler code that requires one less pass through the ACL.
Signed-off-by: "J. Bruce Fields" <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./fs/nfsd/nfs4acl.c | 133 ++--
1 file changed, 38 insertions(+), 95 deletions(-)
diff .prev/fs/nfsd/nfs4acl.c ./fs/nfsd/nfs4acl.c
--- .prev/fs/nfsd/nfs4acl.c 2007-02-13 10:01:42.0 +1100
+++ ./fs/nfsd/nfs4acl.c 2007-02-13 10:04:17.0 +1100
@@ -129,9 +129,7 @@ struct ace_container {
static short ace2type(struct nfs4_ace *);
static int _posix_to_nfsv4_one(struct posix_acl *, struct nfs4_acl *, unsigned
int);
-static struct posix_acl *_nfsv4_to_posix_one(struct nfs4_acl *, unsigned int);
int nfs4_acl_add_ace(struct nfs4_acl *, u32, u32, u32, int, uid_t);
-static int nfs4_acl_split(struct nfs4_acl *, struct nfs4_acl *);
struct nfs4_acl *
nfs4_acl_posix_to_nfsv4(struct posix_acl *pacl, struct posix_acl *dpacl,
@@ -344,46 +342,6 @@ sort_pacl(struct posix_acl *pacl)
return;
}
-int
-nfs4_acl_nfsv4_to_posix(struct nfs4_acl *acl, struct posix_acl **pacl,
- struct posix_acl **dpacl, unsigned int flags)
-{
- struct nfs4_acl *dacl;
- int error = -ENOMEM;
-
- *pacl = NULL;
- *dpacl = NULL;
-
- dacl = nfs4_acl_new();
- if (dacl == NULL)
- goto out;
-
- error = nfs4_acl_split(acl, dacl);
- if (error)
- goto out_acl;
-
- *pacl = _nfsv4_to_posix_one(acl, flags);
- if (IS_ERR(*pacl)) {
- error = PTR_ERR(*pacl);
- *pacl = NULL;
- goto out_acl;
- }
-
- *dpacl = _nfsv4_to_posix_one(dacl, flags);
- if (IS_ERR(*dpacl)) {
- error = PTR_ERR(*dpacl);
- *dpacl = NULL;
- }
-out_acl:
- if (error) {
- posix_acl_release(*pacl);
- *pacl = NULL;
- }
- nfs4_acl_free(dacl);
-out:
- return error;
-}
-
/*
* While processing the NFSv4 ACE, this maintains bitmasks representing
* which permission bits have been allowed and which denied to a given
@@ -668,76 +626,61 @@ static void process_one_v4_ace(struct po
}
}
-static struct posix_acl *
-_nfsv4_to_posix_one(struct nfs4_acl *n4acl, unsigned int flags)
+int nfs4_acl_nfsv4_to_posix(struct nfs4_acl *acl, struct posix_acl **pacl,
+ struct posix_acl **dpacl, unsigned int flags)
{
- struct posix_acl_state state;
- struct posix_acl *pacl;
+ struct posix_acl_state effective_acl_state, default_acl_state;
struct nfs4_ace *ace;
int ret;
- ret = init_state(, n4acl->naces);
+ ret = init_state(_acl_state, acl->naces);
if (ret)
- return ERR_PTR(ret);
-
- list_for_each_entry(ace, >ace_head, l_ace)
- process_one_v4_ace(, ace);
-
- pacl = posix_state_to_acl(, flags);
-
- free_state();
-
- if (!IS_ERR(pacl))
- sort_pacl(pacl);
- return pacl;
-}
-
-static int
-nfs4_acl_split(struct nfs4_acl *acl, struct nfs4_acl *dacl)
-{
- struct list_head *h, *n;
- struct nfs4_ace *ace;
- int error = 0;
-
- list_for_each_safe(h, n, >ace_head) {
- ace = list_entry(h, struct nfs4_ace, l_ace);
-
+ return ret;
+ ret = init_state(_acl_state, acl->naces);
+ if (ret)
+ goto out_estate;
+ ret = -EINVAL;
+ list_for_each_entry(ace, >ace_head, l_ace) {
if (ace->type != NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE &&
ace->type != NFS4_ACE_ACCESS_DENIED_ACE_TYPE)
- return -EINVAL;
-
+ goto out_dstate;
if (ace->flag & ~NFS4_SUPPORTED_FLAGS)
- return -EINVAL;
-
+ goto out_dstate;
if ((ace->flag & NFS4_INHERITANCE_FLAGS) == 0) {
- /* Leave this ace in the effective acl: */
+ process_one_v4_ace(_acl_state, ace);
continue;
}
+ if (!(flags & NFS4_ACL_DIR))
+ goto out_dstate;
/*
* Note that when only one of FILE_INHERIT or DIRECTORY_INHERIT
* is set, we're effectively turning on the other. That's OK,
* according to rfc 3530.
*/
- if (ace->flag & NFS4_ACE_INHERIT_ONLY_ACE) {
- /* Add this ace to the default acl and remove it
-* from the effective acl: */
- error = nfs4_acl_add_ace(dacl, ace->type, ace->flag,
- ace->access_mask,
[PATCH 004 of 9] knfsd: nfsd4: represent nfsv4 acl with array instead of linked list
From: J. Bruce Fields <[EMAIL PROTECTED]>
Simplify the memory management and code a bit by representing acls with an
array instead of a linked list.
Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./fs/nfsd/nfs4acl.c| 153 -
./fs/nfsd/nfs4xdr.c| 43 +---
./include/linux/nfs4.h |3
./include/linux/nfs4_acl.h |9 +-
4 files changed, 69 insertions(+), 139 deletions(-)
diff .prev/fs/nfsd/nfs4acl.c ./fs/nfsd/nfs4acl.c
--- .prev/fs/nfsd/nfs4acl.c 2007-02-13 10:04:17.0 +1100
+++ ./fs/nfsd/nfs4acl.c 2007-02-13 10:23:49.0 +1100
@@ -128,74 +128,58 @@ struct ace_container {
};
static short ace2type(struct nfs4_ace *);
-static int _posix_to_nfsv4_one(struct posix_acl *, struct nfs4_acl *, unsigned
int);
-int nfs4_acl_add_ace(struct nfs4_acl *, u32, u32, u32, int, uid_t);
+static void _posix_to_nfsv4_one(struct posix_acl *, struct nfs4_acl *,
+ unsigned int);
+void nfs4_acl_add_ace(struct nfs4_acl *, u32, u32, u32, int, uid_t);
struct nfs4_acl *
nfs4_acl_posix_to_nfsv4(struct posix_acl *pacl, struct posix_acl *dpacl,
unsigned int flags)
{
struct nfs4_acl *acl;
- int error = -EINVAL;
+ int size = 0;
- if ((pacl != NULL &&
- (posix_acl_valid(pacl) < 0 || pacl->a_count == 0)) ||
- (dpacl != NULL &&
- (posix_acl_valid(dpacl) < 0 || dpacl->a_count == 0)))
- goto out_err;
-
- acl = nfs4_acl_new();
- if (acl == NULL) {
- error = -ENOMEM;
- goto out_err;
- }
+ if (pacl) {
+ if (posix_acl_valid(pacl) < 0)
+ return ERR_PTR(-EINVAL);
+ size += 2*pacl->a_count;
+ }
+ if (dpacl) {
+ if (posix_acl_valid(dpacl) < 0)
+ return ERR_PTR(-EINVAL);
+ size += 2*dpacl->a_count;
+ }
+
+ /* Allocate for worst case: one (deny, allow) pair each: */
+ acl = nfs4_acl_new(size);
+ if (acl == NULL)
+ return ERR_PTR(-ENOMEM);
- if (pacl != NULL) {
- error = _posix_to_nfsv4_one(pacl, acl,
- flags & ~NFS4_ACL_TYPE_DEFAULT);
- if (error < 0)
- goto out_acl;
- }
+ if (pacl)
+ _posix_to_nfsv4_one(pacl, acl, flags & ~NFS4_ACL_TYPE_DEFAULT);
- if (dpacl != NULL) {
- error = _posix_to_nfsv4_one(dpacl, acl,
- flags | NFS4_ACL_TYPE_DEFAULT);
- if (error < 0)
- goto out_acl;
- }
-
- return acl;
-
-out_acl:
- nfs4_acl_free(acl);
-out_err:
- acl = ERR_PTR(error);
+ if (dpacl)
+ _posix_to_nfsv4_one(dpacl, acl, flags | NFS4_ACL_TYPE_DEFAULT);
return acl;
}
-static int
+static void
nfs4_acl_add_pair(struct nfs4_acl *acl, int eflag, u32 mask, int whotype,
uid_t owner, unsigned int flags)
{
- int error;
-
- error = nfs4_acl_add_ace(acl, NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE,
+ nfs4_acl_add_ace(acl, NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE,
eflag, mask, whotype, owner);
- if (error < 0)
- return error;
- error = nfs4_acl_add_ace(acl, NFS4_ACE_ACCESS_DENIED_ACE_TYPE,
+ nfs4_acl_add_ace(acl, NFS4_ACE_ACCESS_DENIED_ACE_TYPE,
eflag, deny_mask(mask, flags), whotype, owner);
- return error;
}
/* We assume the acl has been verified with posix_acl_valid. */
-static int
+static void
_posix_to_nfsv4_one(struct posix_acl *pacl, struct nfs4_acl *acl,
unsigned int flags)
{
struct posix_acl_entry *pa, *pe, *group_owner_entry;
- int error = -EINVAL;
u32 mask, mask_mask;
int eflag = ((flags & NFS4_ACL_TYPE_DEFAULT) ?
NFS4_INHERITANCE_FLAGS : 0);
@@ -211,23 +195,16 @@ _posix_to_nfsv4_one(struct posix_acl *pa
pa = pacl->a_entries;
BUG_ON(pa->e_tag != ACL_USER_OBJ);
mask = mask_from_posix(pa->e_perm, flags | NFS4_ACL_OWNER);
- error = nfs4_acl_add_pair(acl, eflag, mask, NFS4_ACL_WHO_OWNER, 0,
flags);
- if (error < 0)
- goto out;
+ nfs4_acl_add_pair(acl, eflag, mask, NFS4_ACL_WHO_OWNER, 0, flags);
pa++;
while (pa->e_tag == ACL_USER) {
mask = mask_from_posix(pa->e_perm, flags);
- error = nfs4_acl_add_ace(acl, NFS4_ACE_ACCESS_DENIED_ACE_TYPE,
+ nfs4_acl_add_ace(acl, NFS4_ACE_ACCESS_DENIED_ACE_TYPE,
eflag, mask_mask, NFS4_ACL_WHO_NAMED,
pa->e_id);
- if (error < 0)
-
[PATCH 006 of 9] knfsd: nfsd4: fix error return on unsupported acl
From: J. Bruce Fields <[EMAIL PROTECTED]> We should be returning ATTRNOTSUPP, not NOTSUPP, when acls are unsupported. Also fix a comment. Signed-off-by: "J. Bruce Fields" <[EMAIL PROTECTED]> Signed-off-by: Neil Brown <[EMAIL PROTECTED]> ### Diffstat output ./fs/nfsd/nfs4xdr.c |2 +- ./fs/nfsd/vfs.c |5 - 2 files changed, 5 insertions(+), 2 deletions(-) diff .prev/fs/nfsd/nfs4xdr.c ./fs/nfsd/nfs4xdr.c --- .prev/fs/nfsd/nfs4xdr.c 2007-02-13 10:36:40.0 +1100 +++ ./fs/nfsd/nfs4xdr.c 2007-02-13 10:37:00.0 +1100 @@ -253,7 +253,7 @@ nfsd4_decode_fattr(struct nfsd4_compound return status; /* -* According to spec, unsupported attributes return ERR_NOTSUPP; +* According to spec, unsupported attributes return ERR_ATTRNOTSUPP; * read-only attributes return ERR_INVAL. */ if ((bmval[0] & ~NFSD_SUPPORTED_ATTRS_WORD0) || (bmval[1] & ~NFSD_SUPPORTED_ATTRS_WORD1)) diff .prev/fs/nfsd/vfs.c ./fs/nfsd/vfs.c --- .prev/fs/nfsd/vfs.c 2007-02-13 09:50:24.0 +1100 +++ ./fs/nfsd/vfs.c 2007-02-13 10:37:00.0 +1100 @@ -466,7 +466,10 @@ out: posix_acl_release(dpacl); return (error); out_nfserr: - error = nfserrno(host_error); + if (host_error == -EOPNOTSUPP) + error = nfserr_attrnotsupp; + else + error = nfserrno(host_error); goto out; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 005 of 9] knfsd: nfsd4: fix memory leak on kmalloc failure in savemem
From: J. Bruce Fields <[EMAIL PROTECTED]>
The wrong pointer is being kfree'd in savemem() when defer_free
returns with an error.
Signed-off-by: Benny Halevy <[EMAIL PROTECTED]>
Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./fs/nfsd/nfs4xdr.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff .prev/fs/nfsd/nfs4xdr.c ./fs/nfsd/nfs4xdr.c
--- .prev/fs/nfsd/nfs4xdr.c 2007-02-13 10:23:49.0 +1100
+++ ./fs/nfsd/nfs4xdr.c 2007-02-13 10:36:40.0 +1100
@@ -199,18 +199,16 @@ defer_free(struct nfsd4_compoundargs *ar
static char *savemem(struct nfsd4_compoundargs *argp, __be32 *p, int nbytes)
{
- void *new = NULL;
if (p == argp->tmp) {
- new = kmalloc(nbytes, GFP_KERNEL);
- if (!new) return NULL;
- p = new;
+ p = kmalloc(nbytes, GFP_KERNEL);
+ if (!p) return NULL;
memcpy(p, argp->tmp, nbytes);
} else {
BUG_ON(p != argp->tmpp);
argp->tmpp = NULL;
}
if (defer_free(argp, kfree, p)) {
- kfree(new);
+ kfree(p);
return NULL;
} else
return (char *)p;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 002 of 9] knfsd: nfsd4: relax checking of ACL inheritance bits
From: J. Bruce Fields <[EMAIL PROTECTED]>
The rfc allows us to be more permissive about the ACL inheritance bits we
accept:
"If the server supports a single "inherit ACE" flag that applies to
both files and directories, the server may reject the request
(i.e., requiring the client to set both the file and directory
inheritance flags). The server may also accept the request and
silently turn on the ACE4_DIRECTORY_INHERIT_ACE flag."
Let's take the latter option--the ACL is a complex attribute that could be
rejected for a wide variety of reasons, and the protocol gives us little
ability to explain the reason for the rejection, so erroring out is a
user-unfriendly last resort.
Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./fs/nfsd/nfs4acl.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff .prev/fs/nfsd/nfs4acl.c ./fs/nfsd/nfs4acl.c
--- .prev/fs/nfsd/nfs4acl.c 2007-02-13 09:50:26.0 +1100
+++ ./fs/nfsd/nfs4acl.c 2007-02-13 10:01:42.0 +1100
@@ -61,9 +61,11 @@
/* flags used to simulate posix default ACLs */
#define NFS4_INHERITANCE_FLAGS (NFS4_ACE_FILE_INHERIT_ACE \
- | NFS4_ACE_DIRECTORY_INHERIT_ACE | NFS4_ACE_INHERIT_ONLY_ACE)
+ | NFS4_ACE_DIRECTORY_INHERIT_ACE)
-#define NFS4_SUPPORTED_FLAGS (NFS4_INHERITANCE_FLAGS |
NFS4_ACE_IDENTIFIER_GROUP)
+#define NFS4_SUPPORTED_FLAGS (NFS4_INHERITANCE_FLAGS \
+ | NFS4_ACE_INHERIT_ONLY_ACE \
+ | NFS4_ACE_IDENTIFIER_GROUP)
#define MASK_EQUAL(mask1, mask2) \
( ((mask1) & NFS4_ACE_MASK_ALL) == ((mask2) & NFS4_ACE_MASK_ALL) )
@@ -707,11 +709,16 @@ nfs4_acl_split(struct nfs4_acl *acl, str
if (ace->flag & ~NFS4_SUPPORTED_FLAGS)
return -EINVAL;
- switch (ace->flag & NFS4_INHERITANCE_FLAGS) {
- case 0:
+ if ((ace->flag & NFS4_INHERITANCE_FLAGS) == 0) {
/* Leave this ace in the effective acl: */
continue;
- case NFS4_INHERITANCE_FLAGS:
+ }
+ /*
+* Note that when only one of FILE_INHERIT or DIRECTORY_INHERIT
+* is set, we're effectively turning on the other. That's OK,
+* according to rfc 3530.
+*/
+ if (ace->flag & NFS4_ACE_INHERIT_ONLY_ACE) {
/* Add this ace to the default acl and remove it
* from the effective acl: */
error = nfs4_acl_add_ace(dacl, ace->type, ace->flag,
@@ -721,17 +728,13 @@ nfs4_acl_split(struct nfs4_acl *acl, str
list_del(h);
kfree(ace);
acl->naces--;
- break;
- case NFS4_INHERITANCE_FLAGS & ~NFS4_ACE_INHERIT_ONLY_ACE:
+ } else {
/* Add this ace to the default, but leave it in
* the effective acl as well: */
error = nfs4_acl_add_ace(dacl, ace->type, ace->flag,
ace->access_mask, ace->whotype, ace->who);
if (error)
return error;
- break;
- default:
- return -EINVAL;
}
}
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
