[PATCH 2/23] make atomic_read() and atomic_set() behavior consistent on alpha
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on alpha.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-alpha/atomic.h2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-alpha/atomic.h 2007-08-13 05:00:36.0
-0400
@@ -14,21 +14,35 @@
/*
- * Counter is volatile to make sure gcc doesn't try to be clever
- * and move things around on us. We need to use _exactly_ the address
- * the user gave us, not some alias that contains the same information.
+ * Make sure gcc doesn't try to be clever and move things around
+ * on us. We need to use _exactly_ the address the user gave us,
+ * not some alias that contains the same information.
*/
-typedef struct { volatile int counter; } atomic_t;
-typedef struct { volatile long counter; } atomic64_t;
+typedef struct { int counter; } atomic_t;
+typedef struct { long counter; } atomic64_t;
#define ATOMIC_INIT(i) ( (atomic_t) { (i) } )
#define ATOMIC64_INIT(i) ( (atomic64_t) { (i) } )
-#define atomic_read(v) ((v)->counter + 0)
-#define atomic64_read(v) ((v)->counter + 0)
+static __inline__ int atomic_read(atomic_t *v)
+{
+ return *(volatile int *)>counter + 0;
+}
+
+static __inline__ long atomic64_read(atomic64_t *v)
+{
+ return *(volatile long *)>counter + 0;
+}
-#define atomic_set(v,i)((v)->counter = (i))
-#define atomic64_set(v,i) ((v)->counter = (i))
+static __inline__ void atomic_set(atomic_t *v, int i)
+{
+ *(volatile int *)>counter = i;
+}
+
+static __inline__ void atomic64_set(atomic64_t *v, long i)
+{
+ *(volatile long *)>counter = i;
+}
/*
* To get proper branch prediction for the main line, we must branch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Distributed storage.
On Mon, Aug 13, 2007 at 03:12:33AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: > > This is not a very good solution, since it requires all users of the > > bios to know how to free it. > > No, only the specific ->endio needs to know that, which is set by the > bio owner, so this knowledge lies in exactly the right place. A small > handful of generic endios all with the same destructor are used nearly > everywhere. That is what I meant - there will be no way to just alloc a bio and put it, helpers for generic bio sets must be exported and each and every bi_end_io() must be changed to check reference counter and they must know how they were allocated. > > Right now it is hidden. > > And adds additional atomic check (although reading is quite fast) in > > the end_io. > > Actual endio happens once in the lifetime of the transfer, this read > will be entirely lost in the noise. Not always. Sometimes it is called multiple times, but all bi_end_io() callbacks I checked (I believe all in mainline tree) tests if bi_size is zero or not. Endio callback is of course quite rare and additional atomic reading will not kill the system, but why introduce another read? It is possible to provide a flag for endio callback that it is last, but it still requires to change every single callback - why do we want this? > > And for what purpose? To eat 8 bytes on 64bit platform? > > This will not reduce its size noticebly, so the same number of bios > > will be in the cache's page, so what is a gain? All this cleanups and > > logic complicatins should be performed only if after size shring > > increased number of bios can fit into cache's page, will it be done > > after such cleanups? > > Well, exactly, My point from the beginning was that the size of struct > bio is not even close to being a problem and adding a few bytes to it > in the interest of doing the cleanest fix to a core kernel bug is just > not a dominant issue. So, I'm a bit lost... You say it is too big and some parts can be removed or combined, and then that size does not matter. Last/not-last checks in the code is not clear design, so I do not see why it is needed at all if not for size shrinking. > I suppose that leaving out the word "bloated" and skipping straight to > the "doesn't matter" proof would have saved some bandwidth. :) Likely it will. -- 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: Block device throttling [Re: Distributed storage.]
On Monday 13 August 2007 01:14, Evgeniy Polyakov wrote: > > Oops, and there is also: > > > > 3) The bio throttle, which is supposed to prevent deadlock, can > > itself deadlock. Let me see if I can remember how it goes. > > > > * generic_make_request puts a bio in flight > > * the bio gets past the throttle and initiates network IO > > * net calls sk_alloc->alloc_pages->shrink_caches > > * shrink_caches submits a bio recursively to our block device > > * this bio blocks on the throttle > > * net may never get the memory it needs, and we are wedged > > If system is in such condition, it is already broken - throttle limit > must be lowered (next time) not to allow such situation. Agreed that the system is broken, however lowering the throttle limit gives no improvement in this case. This is not theoretical, but a testable, repeatable result. Instructions to reproduce should show up tomorrow. This bug is now solved in a kludgy way. Now, Peter's patch set offers a much cleaner way to fix this little problem, along with at least one other nasty that it already fixed. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [241/2many] MAINTAINERS - IDE/ATAPI CDROM DRIVER
On Sun, 12 Aug 2007 23:29:21 -0700 [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index d22e45a..b77decd 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2285,6 +2285,8 @@ P: Alan Cox > M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > S: Maintained > +F: Documentation/cdrom/ide-cd > +F: drivers/ide/ide-cd.* Acked-by: Alan Cox <[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/
why use memcpy when memmove is there?
Hi, All We were looking at "[kernel]/lib/string.c" (http://lxr.linux.no/source/lib/string.c#L500) memcpy copies a part of memory to some other location but It will not work for all cases of overlapping blocks.(if the start of destination block falls between the source block) while memove copes with overlapping areas. then why is memcpy present in the sources can't we simply do "#define memcpy memmove" in include/linux/string.h or am I missing something? Regards Sri Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6][RESEND] Emulex FC HBA driver: fix overflow of statically allocated array
NACK
The fix is contained in our 8.2.2 sources recently posted and pushed by James
as part of his last scsi fixes.
-- james s
Jesper Juhl wrote:
(previously send on 09-Aug-2007 20:47)
Hi,
The Coverity checker noticed that we may overrun a statically allocated
array in drivers/scsi/lpfc/lpfc_sli.c::lpfc_sli_hbqbuf_find().
The case is this; In 'struct lpfc_hba' we have
#define LPFC_MAX_HBQS 4
...
struct lpfc_hba {
...
struct hbq_s hbqs[LPFC_MAX_HBQS];
...
};
But then in lpfc_sli_hbqbuf_find() we have this code
hbqno = tag >> 16;
if (hbqno > LPFC_MAX_HBQS)
return NULL;
if 'hbqno' ends up as exactely 4, then we won't return, and then this
list_for_each_entry(d_buf, >hbqs[hbqno].hbq_buffer_list, list) {
will cause an overflow of the statically allocated array at index 4,
since the valid indices are only 0-3.
I propose this patch, that simply changes the 'hbqno > LPFC_MAX_HBQS'
into 'hbqno >= LPFC_MAX_HBQS' as a possible fix.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Acked-by: James Smart <[EMAIL PROTECTED]>
---
drivers/scsi/lpfc/lpfc_sli.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index ce5ff2b..e5337ad 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -675,7 +675,7 @@ lpfc_sli_hbqbuf_find(struct lpfc_hba *phba, uint32_t tag)
uint32_t hbqno;
hbqno = tag >> 16;
- if (hbqno > LPFC_MAX_HBQS)
+ if (hbqno >= LPFC_MAX_HBQS)
return NULL;
list_for_each_entry(d_buf, >hbqs[hbqno].hbq_buffer_list, list) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/23] make atomic_read() and atomic_set() behavior consistent across all architectures
By popular demand, I've redone the patchset to include volatile casts in atomic_set as well. I've also converted the macros to inline functions, to help catch type mismatches at compile time. This will do weird things on ia64 without Andreas Schwab's fix: http://lkml.org/lkml/2007/8/10/410 Notably absent is a patch for powerpc. I expect Segher Boessenkool's assembly implementation should suffice there: http://lkml.org/lkml/2007/8/10/470 Thanks to all who commented on previous incarnations. -- Chris Snook - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [428/2many] MAINTAINERS - SERIAL ATA (SATA) SUBSYSTEM:
> @@ -4077,6 +4077,7 @@ M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > T: git kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git > S: Supported > +F: drivers/ata/sata_* NAK sata_inic is Tejun and various others are also different - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/16] Permit filesystem local caching [try #3]
Casey Schaufler <[EMAIL PROTECTED]> wrote: > Sigh. So it's not only SELinux specific, but RedHat specific as well. *Blink*. How did you come to that conclusion? > > (3) The cache driver wants to access the files in the cache, but it's > > running in the security context of either the aforementioned random > > process, or one of FS-Cache's thread pool. > > I think that this is the point you should attack. Control the security > characteristics of the cache driver properly and you shouldn't need the > complexity that you're asking to introduce. How? The cache driver acts on behalf of someone else. That someone else has one security context, but the cache itself has to have a different context so that the cache can be shared. Furthermore, the cache driver doesn't have a security context per se. > > This security context, however, doesn't necessarily give it the > > rights to access what's in the cache, so the driver has to be > > permitted to act as a context appropriate to accessing the cache, > > without changing the overall security context of the random process > > (which would impact things trying to act on that process - kill() > > for example). > > Can you run the cache as an independent thread and send it messages > rather than trying to do things in the context of the calling process? > I know that that involves extra bookkeeppingg, but it's lots safer. It introduces more complexity, which I believe you were just arguing against above... It also incurs more kernel threads - which I really really want to avoid. I would rank the complexity and resource overhead of the act-as stuff in LSM (or at least in SELinux) as much less than what you're suggesting. As it stands, the FS-Cache layer has a pool of threads that CacheFiles makes use of, but this can't be bound to the security of a specific cache because there may be more than one cache of more than one cache driver type. > Yes, and the SELinux semantics for what label to give a file don't > help much, either. The problem with the "act_as" interfaces is that > I wouldn't expect them to be any more reliable than the old access() > system call, which never really gave you a helpful answer. I don't see how act_as compares to access(). > Ideally you want to be running in the right context to create the > new file so that no one can use it and then label it "correctly" > and make it available. That sounds like it'd be the complexity thing again... > > Part of the problem is that the VFS does not pass around the security > > context as which the VFS routines act, but rather gets them from the > > task_struct. > > That's by design. I suspect that's more by the fact that security wasn't particularly thought about when these interfaces were first written. As with everything in the kernel, it might be negotiable. > The cache driver is a unique case with an unusual function. It's pretty > obvious that the kernel architecture, the VFS architecture, LSM, SELinux, > NFS and pretty much everyone else has given no thought whatever to the > implications of their designs on file system cacheing. For all concerned, > I'll say "sorry 'bout that". Meaning you think I should just give up on this? How about I reduce the interface I'm proposing to two functions: (1) int security_act_as(struct task_struct *context) Temporarily make the current process act as the given task, including, for example, for SELinux, the security ID with which this task acts on things, and the security ID with which this task creates files. (2) int security_act_as_self(void); Restore the context as which we're asking. This would mean that the task's security context would have to be able to store acting security IDs for everything, but I don't think that's too much of a stretch resourcewise. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [154/2many] MAINTAINERS - DIGI INTL. EPCA DRIVER
On Sun, 12 Aug 2007 23:26:16 -0700 [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 36a7d25..edebf01 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1482,7 +1482,7 @@ L: linux-kernel@vger.kernel.org > S: Maintained > > DIGI INTL. EPCA DRIVER > -P: Digi International, Inc > +P: Digi International Inc The "," is correct and how they added themselves. Please don't hide other types of change in a large changeset without notice, thats not good NAK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [158/2many] MAINTAINERS - DMA GENERIC OFFLOAD ENGINE SUBSYSTEM
On Sun, 12 Aug 2007 23:26:26 -0700 [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 60bda8d..70e5070 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1544,6 +1544,9 @@ P: Dan Williams > M: [EMAIL PROTECTED] > L: linux-kernel@vger.kernel.org > S: Supported > +F: drivers/dma/ > +F: include/linux/dma* > +F: kernel/dma.c NAK - kernel/dma.c is for old style host ISA DMA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [70/2many] MAINTAINERS - ARPD SUPPORT
On Sun, 12 Aug 2007 23:23:36 -0700 [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 90c1b81..ac2226b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -697,6 +697,7 @@ ARPD SUPPORT > P: Jonathan Layes > L: [EMAIL PROTECTED] > S: Maintained > +F: net/ipv4/arp.c NAK arp.c is the netdev people, ARPD is a corner case bit of code within it, something your patterns don't actually cope with - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [132/2many] MAINTAINERS - COMPUTONE INTELLIPORT MULTIPORT CARD
On Sun, 12 Aug 2007 23:25:32 -0700 [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4898b55..594881d 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1277,6 +1277,9 @@ P: Michael H. Warfield > M: [EMAIL PROTECTED] > W: http://www.wittsend.com/computone.html > S: Maintained > +F: Documentation/computone.txt > +F: drivers/char/ip2/ > +F: drivers/serial/8250_pci.c NAK. drivers/serial/8250_pci.c is RMK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [48/2many] MAINTAINERS - ARM MFM AND FLOPPY DRIVERS
> diff --git a/MAINTAINERS b/MAINTAINERS > index 435bafd..ca4a132 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -457,6 +457,9 @@ ARM MFM AND FLOPPY DRIVERS > P: Ian Molton > M: [EMAIL PROTECTED] > S: Maintained > +F: arch/arm/lib/floppydma.S > +F: drivers/block/floppy.c NAK drivers/block/floppy isn't ARM - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [44/2many] MAINTAINERS - APM DRIVER
On Sun, 12 Aug 2007 23:22:46 -0700 [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 016f342..da9bc6d 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -428,6 +428,9 @@ M:[EMAIL PROTECTED] > L: [EMAIL PROTECTED] > W: http://www.canb.auug.org.au/~sfr/ > S: Supported > +F: arch/i386/boot/apm.c > +F: arch/i386/kernel/apm.c > +F: include/linux/apm_bios.h NAK - boot/apm.c seems to be maintained by H Peter Anvin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [206/2many] MAINTAINERS - GENERIC GPIO I2C DRIVER
On Sun, 12 Aug 2007 23:28:12 -0700 [EMAIL PROTECTED] wrote: > @@ -1967,6 +1967,8 @@ GENERIC GPIO I2C DRIVER > P: Haavard Skinnemoen > M: [EMAIL PROTECTED] > S: Supported > +F: Documentation/gpio.txt This document describes the generic GPIO interface which is used by the i2c-gpio driver as well as many others. I don't think it should be associated with this particular driver. Patches for Documentation/gpio.txt should probably be sent to linux-arch and David Brownell, who is the one who wrote it. > +F: drivers/i2c/busses/i2c-gpio.c F: include/linux/i2c-gpio.h The other patches I was Cc'ed on (77, 78, 81 and 82) all look good to me. Håvard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [22/2many] MAINTAINERS - ACPI
On Sun, 12 Aug 2007 23:22:05 -0700 [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 1162fb7..93a100b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -251,6 +251,9 @@ L:[EMAIL PROTECTED] > W: http://acpi.sourceforge.net/ > T: git kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git > S: Supported > +F: drivers/acpi/ > +F: drivers/ata/libata-acp* > +F: drivers/pnp/pnpacpi/ NAK - libata-acpi isthe libata team - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 of 5 ] /drivers/char/rio ioremap balancing/ returncode check
On Mon, 13 Aug 2007 00:05:30 -0400 "Scott Thompson" <[EMAIL PROTECTED]> wrote: > patchset against 2.6.23-rc2 and this set is an audit of > /drivers/char/a* > through drivers/char . > > this corrects missing ioremap return checks and balancing on > iounmap calls.. Your mail client has wrapped the patches. Please resend without wrapping - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [418/2many] MAINTAINERS - SCSI CDROM DRIVER
On Sun, Aug 12 2007, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index c08c8af..d7a1c74 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3981,6 +3981,7 @@ M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > W: http://www.kernel.dk > S: Maintained > +F: drivers/scsi/sr.* Not correct, it should be sr* And could you please just put these patches online somewhere, posting hundreds of them individually (and non threaded!) is pretty much pain :-) -- 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: Distributed storage.
On Monday 13 August 2007 03:22, Jens Axboe wrote: > I never compared the bio to struct page, I'd obviously agree that > shrinking struct page was a worthy goal and that it'd be ok to uglify > some code to do that. The same isn't true for struct bio. I thought I just said that. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/6] writeback: remove pages_skipped accounting in __block_write_full_page()
On Mon, Aug 13, 2007 at 11:03:21AM +1000, David Chinner wrote:
> > --- linux-2.6.23-rc2-mm2.orig/fs/buffer.c
> > +++ linux-2.6.23-rc2-mm2/fs/buffer.c
> > @@ -1713,7 +1713,6 @@ done:
> > * The page and buffer_heads can be released at any time from
> > * here on.
> > */
> > - wbc->pages_skipped++; /* We didn't write this page */
> > }
> > return err;
>
> H - I suspect XFS is going to need a similar fix as well. I'm moving
> house so I'm not going to get a chance to look at this for a week...
I guess as long as the skipped page no longer has dirty bit set both
as a page flag and a radix tree tag(i.e. has been put to io by someone
else), it is OK to not increase wbc->pages_skipped.
> On Sun, Aug 12, 2007 at 05:11:23PM +0800, Fengguang Wu wrote:
> > Miklos Szeredi <[EMAIL PROTECTED]> and me identified a writeback bug:
> > Basicly they are
> > - during the dd: ~16M
> > - after 30s: ~4M
> > - after 5s: ~4M
> > - after 5s: ~176M
> >
> > The box has 2G memory.
> >
> > Question 1:
> > How come the 5s delays? I run 4 tests in total, 2 of which have such 5s
> > delays.
>
> pdflush runs every five seconds, so that is indicative of the inode being
> written once for 1024 pages, and then delayed to the next pdflush run 5s
> later.
> perhaps the inodes aren't moving between the lists exactly the way you
> think they are...
Now I figured out the exact situation. When the scan of s_io finishes
with some small inodes, nr_to_write will be positive, fooling kupdate
to quit prematurely. But in fact the big dirty file is on s_more_io
waiting for more io... The attached patch fixes it.
Fengguang
===
Subject: writeback: introduce writeback_control.more_io to indicate more io
After making dirty a 100M file, the normal behavior is to
start the writeback for all data after 30s delays. But
sometimes the following happens instead:
- after 30s:~4M
- after 5s: ~4M
- after 5s: all remaining 92M
Some analyze shows that the internal io dispatch queues goes like this:
s_ios_more_io
-
1) 100M,1K 0
2) 1K 96M
3) 0 96M
1) initial state with a 100M file and a 1K file
2) 4M written, nr_to_write <= 0, so write more
3) 1K written, nr_to_write > 0, no more writes(BUG)
nr_to_write > 0 in 3) fools the upper layer to think that data have all been
written out. Bug the big dirty file is still sitting in s_more_io. We cannot
simply splice s_more_io back to s_io as soon as s_io becomes empty, and let the
loop in generic_sync_sb_inodes() continue: this may starve newly expired inodes
in s_dirty. It is also not an option to draw inodes from both s_more_io and
s_dirty, an let the loop go on: this might lead to live locks, and might also
starve other superblocks in sync time(well kupdate may still starve some
superblocks, that's another bug).
So we have to return when a full scan of s_io completes. So nr_to_write > 0 does
not necessarily mean that "all data are written". This patch introduces a flag
writeback_control.more_io to indicate this situation. With it the big dirty file
no longer has to wait for the next kupdate invocation 5s later.
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
fs/fs-writeback.c |2 ++
include/linux/writeback.h |1 +
mm/page-writeback.c |9 ++---
3 files changed, 9 insertions(+), 3 deletions(-)
--- linux-2.6.23-rc2-mm2.orig/fs/fs-writeback.c
+++ linux-2.6.23-rc2-mm2/fs/fs-writeback.c
@@ -560,6 +560,8 @@ int generic_sync_sb_inodes(struct super_
if (wbc->nr_to_write <= 0)
break;
}
+ if (!list_empty(>s_more_io))
+ wbc->more_io = 1;
spin_unlock(_lock);
return ret; /* Leave any unwritten inodes on s_io */
}
--- linux-2.6.23-rc2-mm2.orig/include/linux/writeback.h
+++ linux-2.6.23-rc2-mm2/include/linux/writeback.h
@@ -61,6 +61,7 @@ struct writeback_control {
unsigned for_reclaim:1; /* Invoked from the page allocator */
unsigned for_writepages:1; /* This is a writepages() call */
unsigned range_cyclic:1;/* range_start is cyclic */
+ unsigned more_io:1; /* more io to be dispatched */
void *fs_private; /* For use by ->writepages() */
};
--- linux-2.6.23-rc2-mm2.orig/mm/page-writeback.c
+++ linux-2.6.23-rc2-mm2/mm/page-writeback.c
@@ -382,6 +382,7 @@ static void background_writeout(unsigned
global_page_state(NR_UNSTABLE_NFS) < background_thresh
&& min_pages <= 0)
break;
+ wbc.more_io = 0;
wbc.encountered_congestion = 0;
wbc.nr_to_write = MAX_WRITEBACK_PAGES;
wbc.pages_skipped = 0;
@@ -389,8 +390,9 @@ static void
Re: Distributed storage.
On Mon, Aug 13 2007, Daniel Phillips wrote: > On Monday 13 August 2007 03:06, Jens Axboe wrote: > > On Mon, Aug 13 2007, Daniel Phillips wrote: > > > Of course not. Nothing I said stops endio from being called in the > > > usual way as well. For this to work, endio just needs to know that > > > one call means "end" and the other means "destroy", this is > > > trivial. > > > > Sorry Daniel, but your suggestions would do nothing more than uglify > > the code and design. > > Pretty much exactly what was said about shrinking struct page, ask Bill. > The difference was, shrinking struct page actually mattered whereas > shrinking struct bio does not, and neither does expanding it by a few > bytes. Lets back this up a bit - this whole thing began with you saying that struct bio was bloated already, which I said wasn't true. You then continued to hand wave your wave through various suggestions to trim the obvious fat from that structure, none of which were nice or feasible. I never compared the bio to struct page, I'd obviously agree that shrinking struct page was a worthy goal and that it'd be ok to uglify some code to do that. The same isn't true for struct bio. And we can expand struct bio if we have to, naturally. And I've done it before, which I wrote in the initial mail. I just don't want to do it casually, then it WILL be bloated all of a sudden. Your laissez faire attitude towards adding members to struct bio "oh I'll just add it and someone less lazy than me will fix it up in the future" makes me happy that you are not maintaining anything that I use. I'll stop replying to your mails until something interesting surfaces. I've already made my points clear about both the above and the throttling. And I'd advise you to let Evgeniy take this forward, he seems a lot more adept to actually getting CODE done and - at least from my current and past perspective - is someone you can actually have a fruitful conversation with. -- 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: Make checkpatch warn about pointless casting of kalloc returns.
jschopp wrote:
>> +# check for pointless casting of kmalloc return
>> +if ($rawline =~ /\*\)[ ]k[czm]alloc/) {
>
> It looks to me like this will catch
>
> foo = (char *) kmalloc(512);
>
> but not
>
> for = (char* )kmalloc(512);
>
> I haven't tried it but how about something like:
>
> if($rawline =~/\(.*\)\s*k[czm]alloc/){
>
> which if I got it right should match the typecast with any combination
> of spacing.
>
>> +WARN("No need to cast return value.\n");
>
> Could the warning be more descriptive? This describes what, but it
> should also describe why; after all if somebody made this error they may
> not know they why.
Yes there are a few problems with the match, plus it needs to be on the
processed line to avoid false matches in strings (however unlikely). I
ended up with the following:
if ($line =~ /\*\s*\)\s*k[czm]alloc\b/) {
WARN("unnecessary cast may hide bugs, see
http://c-faq.com/malloc/mallocnocast.html\n; . $herecurr);
}
Which just fits on the line :).
Thanks for the patch. Will be in 0.10 coming to an -mm near you soon.
-apw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regression from 2.6.23-rc2 to -rc3 BAT missing
Please check if the attached patch helps.
Thanks,
Alex.
Norbert Preining wrote:
> On Mon, 13 Aug 2007, Alexey Starikovskiy wrote:
>> Do you know if you have SBS or CM battery?
>> What driver do you use: sbs.ko or battery.ko?
>
> I am quite sure that it is a CM battery, not a SBS:
>
> CONFIG_ACPI_BATTERY=y
>
> did normal work, and CONFIG_ACPI_SBS=m but module not loaded. Same
> setting as always.
>
> I also loaded sbs.ko without any change.
>
> Best wishes
>
> Norbert
>
> ---
> Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of
> Technology
> Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
> gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5
> B094
> ---
> SCREMBY (n.)
> The dehydrated felt-tip pen attached by a string to the 'Don't Forget'
> board in the kitchen which has never worked in living memory but which
> no one can be bothered to throw away.
> --- Douglas Adams, The Meaning of Liff
>
ACPI: Battery: don't use acpi_extract_package()
From: Alexey Starikovskiy <[EMAIL PROTECTED]>
acpi_extract_package() creates more problems with memory management than
solves as helper for package handling.
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
drivers/acpi/battery.c | 309 +++-
1 files changed, 123 insertions(+), 186 deletions(-)
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index d7b499f..14bdfad 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -36,9 +36,6 @@
#define ACPI_BATTERY_VALUE_UNKNOWN 0x
-#define ACPI_BATTERY_FORMAT_BIF "N"
-#define ACPI_BATTERY_FORMAT_BST ""
-
#define ACPI_BATTERY_COMPONENT 0x0004
#define ACPI_BATTERY_CLASS "battery"
#define ACPI_BATTERY_DEVICE_NAME "Battery"
@@ -90,29 +87,6 @@ static struct acpi_driver acpi_battery_driver = {
},
};
-struct acpi_battery_state {
- acpi_integer state;
- acpi_integer present_rate;
- acpi_integer remaining_capacity;
- acpi_integer present_voltage;
-};
-
-struct acpi_battery_info {
- acpi_integer power_unit;
- acpi_integer design_capacity;
- acpi_integer last_full_capacity;
- acpi_integer battery_technology;
- acpi_integer design_voltage;
- acpi_integer design_capacity_warning;
- acpi_integer design_capacity_low;
- acpi_integer battery_capacity_granularity_1;
- acpi_integer battery_capacity_granularity_2;
- acpi_string model_number;
- acpi_string serial_number;
- acpi_string battery_type;
- acpi_string oem_info;
-};
-
enum acpi_battery_files {
ACPI_BATTERY_INFO = 0,
ACPI_BATTERY_STATE,
@@ -120,32 +94,42 @@ enum acpi_battery_files {
ACPI_BATTERY_NUMFILES,
};
-struct acpi_battery_flags {
- u8 battery_present_prev;
- u8 alarm_present;
- u8 init_update;
- u8 update[ACPI_BATTERY_NUMFILES];
- u8 power_unit;
-};
-
struct acpi_battery {
struct acpi_device *device;
- struct acpi_battery_flags flags;
- struct acpi_buffer bif_data;
- struct acpi_buffer bst_data;
struct mutex lock;
unsigned long alarm;
unsigned long update_time[ACPI_BATTERY_NUMFILES];
-
+ int state;
+ int present_rate;
+ int remaining_capacity;
+ int present_voltage;
+ int power_unit;
+ int design_capacity;
+ int last_full_capacity;
+ int technology;
+ int design_voltage;
+ int design_capacity_warning;
+ int design_capacity_low;
+ int capacity_granularity_1;
+ int capacity_granularity_2;
+ char model_number[32];
+ char serial_number[32];
+ char type[32];
+ char oem_info[32];
+ u8 present_prev;
+ u8 alarm_present;
+ u8 init_update;
+ u8 update[ACPI_BATTERY_NUMFILES];
};
inline int acpi_battery_present(struct acpi_battery *battery)
{
return battery->device->status.battery_present;
}
+
inline char *acpi_battery_power_units(struct acpi_battery *battery)
{
- if (battery->flags.power_unit)
+ if (battery->power_unit)
return ACPI_BATTERY_UNITS_AMPS;
else
return ACPI_BATTERY_UNITS_WATTS;
@@ -166,43 +150,63 @@ static void acpi_battery_check_result(struct acpi_battery *battery, int result)
return;
if (result) {
- battery->flags.init_update = 1;
+ battery->init_update = 1;
}
}
-static int acpi_battery_extract_package(struct acpi_battery *battery,
- union acpi_object *package,
- struct acpi_buffer *format,
- struct acpi_buffer *data,
- char *package_name)
-{
- acpi_status status = AE_OK;
- struct acpi_buffer data_null = { 0, NULL };
+struct acpi_offsets {
+ size_t offset; /* offset inside struct acpi_sbs_battery */
+ u8 mode; /* int or string? */
+};
- status = acpi_extract_package(package, format, _null);
- if (status != AE_BUFFER_OVERFLOW) {
- ACPI_EXCEPTION((AE_INFO, status, "Extracting size %s",
-package_name));
- return -ENODEV;
- }
+static struct acpi_offsets state_offsets[] = {
+ {offsetof(struct acpi_battery, state), 0},
+
Re: [PATCH] [121/2many] MAINTAINERS - CFG80211 and NL80211
On Sun, 2007-08-12 at 23:25 -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > +F: include/linux/nl80211.h > +F: include/net/cfg80211.h > +F: net/wireless/core.* > +F: net/wireless/sysfs.* > +F: net/wireless/radiotap.c I must've missed the original discussion surrounding this, are these supposed to be regular match patterns? Is there a tool reading it? With this and wireless extensions it'd probably be best to mark cfg80211 as "everything in net/wireless/ but net/wireless/wext*" if possible. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH] [261/2many] MAINTAINERS - IOC3 DRIVER
On Sun, Aug 12, 2007 at 11:30:06PM -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 6263958..207331c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2501,6 +2501,8 @@ P: Ralf Baechle > M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > S: Maintained > +F: drivers/net/ioc3-eth.c > +F: drivers/serial/ioc3_serial.c Although for the same multifunction device at this stage the IOC3 ethernet and ioc3_serial are totally separate, so I suggest to add a separate MAINTAINERS entry for ioc3_serial with Patrick Gefre <[EMAIL PROTECTED]> as the maintainer. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Distributed storage.
On Monday 13 August 2007 03:06, Jens Axboe wrote: > On Mon, Aug 13 2007, Daniel Phillips wrote: > > Of course not. Nothing I said stops endio from being called in the > > usual way as well. For this to work, endio just needs to know that > > one call means "end" and the other means "destroy", this is > > trivial. > > Sorry Daniel, but your suggestions would do nothing more than uglify > the code and design. Pretty much exactly what was said about shrinking struct page, ask Bill. The difference was, shrinking struct page actually mattered whereas shrinking struct bio does not, and neither does expanding it by a few bytes. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
drivers/net/tokenring/3c359.c
Hi,
Replacing kmalloc with kzalloc and cleaning up memset in
drivers/net/tokenring/3c359.c
Signed-off-by: Surya Prabhakar <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/tokenring/3c359.c b/drivers/net/tokenring/3c359.c
index 9f1b6ab..d36dd53 100644
--- a/drivers/net/tokenring/3c359.c
+++ b/drivers/net/tokenring/3c359.c
@@ -641,14 +641,14 @@ static int xl_open(struct net_device *dev)
* Now to set up the Rx and Tx buffer structures
*/
/* These MUST be on 8 byte boundaries */
- xl_priv->xl_tx_ring = kmalloc((sizeof(struct xl_tx_desc) *
XL_TX_RING_SIZE) + 7, GFP_DMA | GFP_KERNEL) ;
+ xl_priv->xl_tx_ring = kzalloc((sizeof(struct xl_tx_desc) *
XL_TX_RING_SIZE) + 7, GFP_DMA | GFP_KERNEL) ;
if (xl_priv->xl_tx_ring == NULL) {
printk(KERN_WARNING "%s: Not enough memory to allocate rx
buffers.\n",
dev->name);
free_irq(dev->irq,dev);
return -ENOMEM;
}
- xl_priv->xl_rx_ring = kmalloc((sizeof(struct xl_rx_desc) *
XL_RX_RING_SIZE) +7, GFP_DMA | GFP_KERNEL) ;
+ xl_priv->xl_rx_ring = kzalloc((sizeof(struct xl_rx_desc) *
XL_RX_RING_SIZE) +7, GFP_DMA | GFP_KERNEL) ;
if (xl_priv->xl_tx_ring == NULL) {
printk(KERN_WARNING "%s: Not enough memory to allocate rx
buffers.\n",
dev->name);
@@ -656,8 +656,6 @@ static int xl_open(struct net_device *dev)
kfree(xl_priv->xl_tx_ring);
return -ENOMEM;
}
- memset(xl_priv->xl_tx_ring,0,sizeof(struct xl_tx_desc) *
XL_TX_RING_SIZE) ;
- memset(xl_priv->xl_rx_ring,0,sizeof(struct xl_rx_desc) *
XL_RX_RING_SIZE) ;
/* Setup Rx Ring */
for (i=0 ; i < XL_RX_RING_SIZE ; i++) {
--
thanks
surya.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [i2c] [PATCH] [37/2many] MAINTAINERS - ALI1563 I2C DRIVER
On Sun, 12 Aug 2007 23:22:33 -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 3a586da..eeb1bf9 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -367,6 +367,7 @@ P:Rudolf Marek > M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > S: Maintained +F: Documentation/i2c/busses/i2c-ali1563 > +F: drivers/i2c/busses/i2c-ali1563.c > > ALPHA PORT > P: Richard Henderson -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Distributed storage.
On Monday 13 August 2007 02:18, Evgeniy Polyakov wrote: > On Mon, Aug 13, 2007 at 02:08:57AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: > > > But that idea fails as well, since reference counts and IO > > > completion are two completely seperate entities. So unless end IO > > > just happens to be the last user holding a reference to the bio, > > > you cannot free it. > > > > That is not a problem. When bio_put hits zero it calls ->endio > > instead of the destructor. The ->endio sees that the count is zero > > and destroys the bio. > > This is not a very good solution, since it requires all users of the > bios to know how to free it. No, only the specific ->endio needs to know that, which is set by the bio owner, so this knowledge lies in exactly the right place. A small handful of generic endios all with the same destructor are used nearly everywhere. > Right now it is hidden. > And adds additional atomic check (although reading is quite fast) in > the end_io. Actual endio happens once in the lifetime of the transfer, this read will be entirely lost in the noise. > And for what purpose? To eat 8 bytes on 64bit platform? > This will not reduce its size noticebly, so the same number of bios > will be in the cache's page, so what is a gain? All this cleanups and > logic complicatins should be performed only if after size shring > increased number of bios can fit into cache's page, will it be done > after such cleanups? Well, exactly, My point from the beginning was that the size of struct bio is not even close to being a problem and adding a few bytes to it in the interest of doing the cleanest fix to a core kernel bug is just not a dominant issue. I suppose that leaving out the word "bloated" and skipping straight to the "doesn't matter" proof would have saved some bandwidth. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression from 2.6.23-rc2 to -rc3 BAT missing
On Mon, 13 Aug 2007, Alexey Starikovskiy wrote: > Do you know if you have SBS or CM battery? > What driver do you use: sbs.ko or battery.ko? I am quite sure that it is a CM battery, not a SBS: CONFIG_ACPI_BATTERY=y did normal work, and CONFIG_ACPI_SBS=m but module not loaded. Same setting as always. I also loaded sbs.ko without any change. Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- SCREMBY (n.) The dehydrated felt-tip pen attached by a string to the 'Don't Forget' board in the kitchen which has never worked in living memory but which no one can be bothered to throw away. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression from 2.6.23-rc2 to -rc3 BAT missing
Hi Norbert, Do you know if you have SBS or CM battery? What driver do you use: sbs.ko or battery.ko? Regards, Alex. Norbert Preining wrote: > Hi all! > > Starting with 2.6.23-rc3 the battery from my laptop (Acer TM3012) is > missing for linux (but not physically): > > ACPI: AC Adapter [ACAD] (on-line) > ACPI: Battery Slot [BAT1] (battery absent) > > But it is definitely there and running, even when I unplug the AC power. > > Any patch I can use to change this? > > Best wishes > > Norbert > > --- > Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of > Technology > Debian Developer <[EMAIL PROTECTED]> Debian TeX Group > gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 > B094 > --- > GLOSSOP (n.) > A rouge blob of food. Glossops, which are generally streaming hot and > highly adhesive invariably fall off your spoon and on to the surface > of your host's highly polished antique-rosewood dining table. If this > has not, or may not have, been noticed by the company present, swanage > (q.v.) may be employed. > --- Douglas Adams, The Meaning of Liff > - > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[KJ] replacing kmalloc with kzalloc in drivers/net/sb1250-mac.c
Hi, Replacing kmalloc with kzalloc and cleaning up memset in drivers/net/sb1250-mac.c Signed-off-by: Surya Prabhakar <[EMAIL PROTECTED]> --- diff --git a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c index e7fdcf1..2dca5a7 100644 --- a/drivers/net/sb1250-mac.c +++ b/drivers/net/sb1250-mac.c @@ -760,7 +760,7 @@ static void sbdma_initctx(sbmacdma_t *d, d->sbdma_dscrtable_unaligned = d->sbdma_dscrtable = (sbdmadscr_t *) - kmalloc((d->sbdma_maxdescr+1)*sizeof(sbdmadscr_t), GFP_KERNEL); + kzalloc((d->sbdma_maxdescr+1)*sizeof(sbdmadscr_t), GFP_KERNEL); /* * The descriptor table must be aligned to at least 16 bytes or the @@ -769,8 +769,6 @@ static void sbdma_initctx(sbmacdma_t *d, d->sbdma_dscrtable = (sbdmadscr_t *) ALIGN((unsigned long)d->sbdma_dscrtable, sizeof(sbdmadscr_t)); - memset(d->sbdma_dscrtable,0,d->sbdma_maxdescr*sizeof(sbdmadscr_t)); - d->sbdma_dscrtable_end = d->sbdma_dscrtable + d->sbdma_maxdescr; d->sbdma_dscrtable_phys = virt_to_phys(d->sbdma_dscrtable); @@ -780,9 +778,7 @@ static void sbdma_initctx(sbmacdma_t *d, */ d->sbdma_ctxtable = (struct sk_buff **) - kmalloc(d->sbdma_maxdescr*sizeof(struct sk_buff *), GFP_KERNEL); - - memset(d->sbdma_ctxtable,0,d->sbdma_maxdescr*sizeof(struct sk_buff *)); + kzalloc(d->sbdma_maxdescr*sizeof(struct sk_buff *), GFP_KERNEL); #ifdef CONFIG_SBMAC_COALESCE /* -- thanks surya. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Distributed storage.
On Mon, Aug 13 2007, Daniel Phillips wrote: > On Monday 13 August 2007 02:13, Jens Axboe wrote: > > On Mon, Aug 13 2007, Daniel Phillips wrote: > > > On Monday 13 August 2007 00:45, Jens Axboe wrote: > > > > On Mon, Aug 13 2007, Jens Axboe wrote: > > > > > > You did not comment on the one about putting the bio > > > > > > destructor in the ->endio handler, which looks dead simple. > > > > > > The majority of cases just use the default endio handler and > > > > > > the default destructor. Of the remaining cases, where a > > > > > > specialized destructor is needed, typically a specialized > > > > > > endio handler is too, so combining is free. There are few if > > > > > > any cases where a new specialized endio handler would need to > > > > > > be written. > > > > > > > > > > We could do that without too much work, I agree. > > > > > > > > But that idea fails as well, since reference counts and IO > > > > completion are two completely seperate entities. So unless end IO > > > > just happens to be the last user holding a reference to the bio, > > > > you cannot free it. > > > > > > That is not a problem. When bio_put hits zero it calls ->endio > > > instead of the destructor. The ->endio sees that the count is zero > > > and destroys the bio. > > > > You can't be serious? You'd stall end io completion notification > > because someone holds a reference to a bio. > > Of course not. Nothing I said stops endio from being called in the > usual way as well. For this to work, endio just needs to know that one > call means "end" and the other means "destroy", this is trivial. Sorry Daniel, but your suggestions would do nothing more than uglify the code and design. -- 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: [PATCH] [231/2many] MAINTAINERS - I2C SUBSYSTEM
On Sun, 12 Aug 2007 23:29:02 -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 491a5a6..2c78350 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2199,6 +2199,9 @@ M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > T: quilt http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/ > S: Maintained > +F: Documentation/i2c/ > +F: drivers/i2c/ > +F: include/linux/i2c* As far as the i2c subsystem itself is concerned, the relevant header files are only: F: include/linux/i2c.h F: include/linux/i2c-dev.h F: include/linux/i2c-id.h All the other i2c*.h files are driver-specific. > > I2C-TINY-USB DRIVER > P: Till Harbaum -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[KJ] replacing kmalloc with kzalloc in drivers/mtd/devices/docprobe.c
Hi,
Replacing kmalloc with kzalloc and cleaning up memset in
drivers/mtd/devices/docprobe.c.
Signed-off-by: Surya Prabhakar <[EMAIL PROTECTED]>
---
diff --git a/drivers/mtd/devices/docprobe.c b/drivers/mtd/devices/docprobe.c
index 54aa759..53be397 100644
--- a/drivers/mtd/devices/docprobe.c
+++ b/drivers/mtd/devices/docprobe.c
@@ -254,7 +254,7 @@ static void __init DoC_Probe(unsigned long physadr)
return;
}
docfound = 1;
- mtd = kmalloc(sizeof(struct DiskOnChip) + sizeof(struct
mtd_info), GFP_KERNEL);
+ mtd = kzalloc(sizeof(struct DiskOnChip) + sizeof(struct
mtd_info), GFP_KERNEL);
if (!mtd) {
printk(KERN_WARNING "Cannot allocate memory for data
structures. Dropping.\n");
@@ -264,9 +264,6 @@ static void __init DoC_Probe(unsigned long physadr)
this = (struct DiskOnChip *)([1]);
- memset((char *)mtd,0, sizeof(struct mtd_info));
- memset((char *)this, 0, sizeof(struct DiskOnChip));
-
mtd->priv = this;
this->virtadr = docptr;
this->physadr = physadr;
--
thanks
surya.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUGFIX] NULL pointer dereference in __vm_enough_memory()
[WU Fengguang - Mon, Aug 13, 2007 at 08:23:42AM +0800]
| On Sun, Aug 12, 2007 at 08:21:43PM +0400, Cyrill Gorcunov wrote:
| > [Alan Cox - Sun, Aug 12, 2007 at 04:17:44PM +0100]
| > | Try this (it compiles but isnt tested). Its a weekend here, the sun is
| > | shining, the beach is a short walk, and I have more interesting things to
| > | do right now 8)
| > |
| > |
| [...]
| > | -int __vm_enough_memory(long pages, int cap_sys_admin)
| > | +int __vm_enough_memory(struct mm_struct *mm, long pages, int
cap_sys_admin)
| > | {
| > | unsigned long free, allowed;
| > |
| > | @@ -166,7 +166,7 @@
| > |
| > | /* Don't let a single process grow too big:
| > | leave 3% of the size of this process for other processes */
| > | - allowed -= current->mm->total_vm / 32;
| > | + allowed -= mm->total_vm / 32;
| >
| > So mm->total_vm is 0 for __bprm_mm_init case. Is that ok? Or I miss
| > something?
|
| Yeah, Alan adds mm to the interfaces and leaves us the question of
| "what mm to pass in when current->mm == NULL?" ;)
|
Well, as I see, it seems the Alan's patch is correct. We pass
newly created mm to security_vm_enough_memory_mm() and get no errors
here even for overcommit = 2. But my question was that mm->total_vm
= 0 for this case and that is probably valid too I think. What about
the thing you pointed about? Well I think security_vm_enough_memory
should never be called from kernel thread (we have secrurity_vm_enough_memory_mm
for this). But I will check it more closely. Dont get me wrong - I'm not
VMM expert and may do errors ;)
Cyrill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Distributed storage.
On Monday 13 August 2007 02:13, Jens Axboe wrote: > On Mon, Aug 13 2007, Daniel Phillips wrote: > > On Monday 13 August 2007 00:45, Jens Axboe wrote: > > > On Mon, Aug 13 2007, Jens Axboe wrote: > > > > > You did not comment on the one about putting the bio > > > > > destructor in the ->endio handler, which looks dead simple. > > > > > The majority of cases just use the default endio handler and > > > > > the default destructor. Of the remaining cases, where a > > > > > specialized destructor is needed, typically a specialized > > > > > endio handler is too, so combining is free. There are few if > > > > > any cases where a new specialized endio handler would need to > > > > > be written. > > > > > > > > We could do that without too much work, I agree. > > > > > > But that idea fails as well, since reference counts and IO > > > completion are two completely seperate entities. So unless end IO > > > just happens to be the last user holding a reference to the bio, > > > you cannot free it. > > > > That is not a problem. When bio_put hits zero it calls ->endio > > instead of the destructor. The ->endio sees that the count is zero > > and destroys the bio. > > You can't be serious? You'd stall end io completion notification > because someone holds a reference to a bio. Of course not. Nothing I said stops endio from being called in the usual way as well. For this to work, endio just needs to know that one call means "end" and the other means "destroy", this is trivial. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[KJ] replacing kmalloc with kzalloc in drivers/mtd/chips/jedec_probe.c
Hi,
Replacing kmalloc with kzalloc and cleaning up memset in
drivers/mtd/chips/jedec_probe.c.
Signed-off-by: Surya Prabhakar <[EMAIL PROTECTED]>
---
diff --git a/drivers/mtd/chips/jedec_probe.c b/drivers/mtd/chips/jedec_probe.c
index 58e561e..ba5fc39 100644
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -1853,14 +1853,12 @@ static int cfi_jedec_setup(struct cfi_private *p_cfi,
int index)
num_erase_regions = jedec_table[index].NumEraseRegions;
- p_cfi->cfiq = kmalloc(sizeof(struct cfi_ident) + num_erase_regions * 4,
GFP_KERNEL);
+ p_cfi->cfiq = kzalloc(sizeof(struct cfi_ident) + num_erase_regions * 4,
GFP_KERNEL);
if (!p_cfi->cfiq) {
//xx printk(KERN_WARNING "%s: kmalloc failed for CFI ident
structure\n", map->name);
return 0;
}
- memset(p_cfi->cfiq,0,sizeof(struct cfi_ident));
-
p_cfi->cfiq->P_ID = jedec_table[index].CmdSet;
p_cfi->cfiq->NumEraseRegions = jedec_table[index].NumEraseRegions;
p_cfi->cfiq->DevSize = jedec_table[index].DevSize;
--
thanks
surya.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/7] Modify lguest32 to make room for lguest64
Rusty Russell wrote: Yeah, after some more thought I've not applied most of this. We really don't want to move everything then move it back; I prefer Jes' more cautious approach of moving a little bit at a time. We really have three parts: (1) bits that are generic, (2) bits that should be generic but my implementation is naive, (3) bits that really are i386-specific. I have actually been using Steven's patchset to do my work, but in a way it's a tool. Moving things out of the way in bulk and see whats missing kinda helps for that :) Patches which move 2 to 1 are gratefully accepted: I realize a mass move is easier and this requires thought, but that's what we need. Since I can't build a module over two directories, that seems to destroy the idea of an i386/ subdir. Instead I've done a patch which renames the *clearly* i386-specific things to i386_, which at least works. I've pushed it into the repository http://lguest.ozlabs.org/patches/ That works - alternatively we could build two modules, lg and lg_ and just have lg pull in the arch one as well? I'm not really biased, but I think it will get messy later once we add ia64 and x86_64 to the directory. Cheers, Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[KJ] replacing kmalloc with kzalloc in drivers/mtd/chips/cfi_probe.c
Hi,
Replacing kmalloc with kzalloc and cleaning up memset in
arch/i386/kernel/io_apic.c
Signed-off-by: Surya Prabhakar <[EMAIL PROTECTED]>
---
diff --git a/drivers/mtd/chips/cfi_probe.c b/drivers/mtd/chips/cfi_probe.c
index 60e11a0..efb51f7 100644
--- a/drivers/mtd/chips/cfi_probe.c
+++ b/drivers/mtd/chips/cfi_probe.c
@@ -203,14 +203,12 @@ static int __xipram cfi_chip_setup(struct map_info *map,
if (!num_erase_regions)
return 0;
- cfi->cfiq = kmalloc(sizeof(struct cfi_ident) + num_erase_regions * 4,
GFP_KERNEL);
+ cfi->cfiq = kzalloc(sizeof(struct cfi_ident) + num_erase_regions * 4,
GFP_KERNEL);
if (!cfi->cfiq) {
printk(KERN_WARNING "%s: kmalloc failed for CFI ident
structure\n", map->name);
return 0;
}
- memset(cfi->cfiq,0,sizeof(struct cfi_ident));
-
cfi->cfi_mode = CFI_MODE_CFI;
/* Read the CFI info structure */
--
thanks
surya.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[KJ-resend]replacing kmalloc with kzalloc in drivers/mtd/chips/cfi_probe.c
Hi,
Replacing kmalloc with kzalloc and cleaning up memset in
drivers/mtd/chips/cfi_probe.c. Kindly ignore the previous similar patch.
Signed-off-by: Surya Prabhakar <[EMAIL PROTECTED]>
---
diff --git a/drivers/mtd/chips/cfi_probe.c b/drivers/mtd/chips/cfi_probe.c
index 60e11a0..efb51f7 100644
--- a/drivers/mtd/chips/cfi_probe.c
+++ b/drivers/mtd/chips/cfi_probe.c
@@ -203,14 +203,12 @@ static int __xipram cfi_chip_setup(struct map_info *map,
if (!num_erase_regions)
return 0;
- cfi->cfiq = kmalloc(sizeof(struct cfi_ident) + num_erase_regions * 4,
GFP_KERNEL);
+ cfi->cfiq = kzalloc(sizeof(struct cfi_ident) + num_erase_regions * 4,
GFP_KERNEL);
if (!cfi->cfiq) {
printk(KERN_WARNING "%s: kmalloc failed for CFI ident
structure\n", map->name);
return 0;
}
- memset(cfi->cfiq,0,sizeof(struct cfi_ident));
-
cfi->cfi_mode = CFI_MODE_CFI;
/* Read the CFI info structure */
thanks
surya.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
regression from 2.6.23-rc2 to -rc3 BAT missing
Hi all! Starting with 2.6.23-rc3 the battery from my laptop (Acer TM3012) is missing for linux (but not physically): ACPI: AC Adapter [ACAD] (on-line) ACPI: Battery Slot [BAT1] (battery absent) But it is definitely there and running, even when I unplug the AC power. Any patch I can use to change this? Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- GLOSSOP (n.) A rouge blob of food. Glossops, which are generally streaming hot and highly adhesive invariably fall off your spoon and on to the surface of your host's highly polished antique-rosewood dining table. If this has not, or may not have, been noticed by the company present, swanage (q.v.) may be employed. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [399/2many] MAINTAINERS - RAGE128 FRAMEBUFFER DISPLAY DRIVER
[EMAIL PROTECTED] writes: > @@ -3815,6 +3815,7 @@ P: Paul Mackerras > M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] (subscribers-only) > S: Maintained > +F: drivers/video/aty/aty* Actually, only drivers/video/aty/aty128fb.c for this entry. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [384/2many] MAINTAINERS - PPP PROTOCOL DRIVERS AND COMPRESSORS
[EMAIL PROTECTED] writes: > diff --git a/MAINTAINERS b/MAINTAINERS > index 62354a9..70667e6 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3679,6 +3679,7 @@ P: Paul Mackerras > M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > S: Maintained > +F: drivers/net/ppp_* Except for drivers/net/ppp_synctty.c. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [29/2many] MAINTAINERS - ADM1025 HARDWARE MONITOR DRIVER
Hi Joe, What a storm :( This should have been one single patch IMHO, or grouped by maintainer or subsystem or something. On Sun, 12 Aug 2007 23:22:18 -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry Can you please point me to where this new pattern was discussed? > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4faf1ce..91bc5cd 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -307,6 +307,7 @@ P:Jean Delvare > M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > S: Maintained +F: Documentation/hwmon/adm1025 > +F: drivers/hwmon/adm1025.c > > ADM1029 HARDWARE MONITOR DRIVER > P: Corentin Labbe Other patches I don't comment on, means I'm fine with them. -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [patch 01/11] dm-snap: Replace special round_down()
On Fri, Aug 10, Jan Blunck wrote:
> This patch removes the special round_down() to next power of 2 implementation
> used only at one place in the snapshot target. It is replaced by an equivalent
> 1 << fls() which might use an architecture specific implementation.
Err, ok this is the second fix for this patch. I hope it is the last. It
doesn't make any sense to have hash_size be defined as sector_t. Same goes for
max_buckets.
Regards,
Jan
--
Jan Blunck <[EMAIL PROTECTED]>
Subject: dm-snap: Replace special round_down()
This patch removes the special round_down() to next power of 2 implementation
used only at one place in the snapshot target. It is replaced by an equivalent
1 << fls() which might use an architecture specific implementation.
Signed-off-by: Jan Blunck <[EMAIL PROTECTED]>
---
drivers/md/dm-snap.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -333,21 +333,12 @@ static int calc_max_buckets(void)
}
/*
- * Rounds a number down to a power of 2.
- */
-static uint32_t round_down(uint32_t n)
-{
- while (n & (n - 1))
- n &= (n - 1);
- return n;
-}
-
-/*
* Allocate room for a suitable hash table.
*/
static int init_hash_tables(struct dm_snapshot *s)
{
- sector_t hash_size, cow_dev_size, origin_dev_size, max_buckets;
+ unsigned int hash_size, max_buckets;
+ sector_t cow_dev_size, origin_dev_size;
/*
* Calculate based on the size of the original volume or
@@ -361,7 +352,7 @@ static int init_hash_tables(struct dm_sn
hash_size = min(hash_size, max_buckets);
/* Round it down to a power of 2 */
- hash_size = round_down(hash_size);
+ hash_size = 1 << (fls(hash_size) - 1);
if (init_exception_table(>complete, hash_size))
return -ENOMEM;
cli/sti cleanup in drivers/net/cris/eth_v10.c
Hi,
Removed the cli/sti reference in eth_v10.c and updated it with
proper spinlock code.
Signed-off-by: Surya Prabhakar <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/cris/eth_v10.c b/drivers/net/cris/eth_v10.c
index 5bdf5ca..d1f7225 100644
--- a/drivers/net/cris/eth_v10.c
+++ b/drivers/net/cris/eth_v10.c
@@ -642,6 +642,7 @@ e100_set_mac_address(struct net_device *dev, void *p)
static int
e100_open(struct net_device *dev)
{
+ struct net_local *np = (struct net_local *)dev->priv;
unsigned long flags;
/* enable the MDIO output pin */
@@ -723,9 +724,7 @@ e100_open(struct net_device *dev)
SETS(network_tr_ctrl_shadow, R_NETWORK_TR_CTRL, crc, enable);
*R_NETWORK_TR_CTRL = network_tr_ctrl_shadow;
- save_flags(flags);
- cli();
-
+ spin_lock_irqsave(>lock, flags);
/* enable the irq's for ethernet DMA */
*R_IRQ_MASK2_SET =
@@ -757,7 +756,7 @@ e100_open(struct net_device *dev)
*R_DMA_CH0_FIRST = 0;
*R_DMA_CH0_DESCR = virt_to_phys(myLastTxDesc);
- restore_flags(flags);
+ spin_unlock_irqrestore(>lock, flags);
/* Probe for transceiver */
if (e100_probe_transceiver(dev))
--
thanks
surya.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 03/11] dm-snap: Remove dead queued_bios code
On Fri, Aug 10, Alasdair G Kergon wrote: > On Fri, Aug 10, 2007 at 10:02:07PM +0200, Jan Blunck wrote: > > This patch removes the unused queued_bios handling code. > > Well I'm going to leave this in for now (as one existing unfinished > patch series does build upon it). We can include its removal as part of > your following patch series that no doubt replaces the functionality > with something better. You mean the snapshot read tracking. Yes, I think I can fix this problem too. Regards, Jan -- Jan Blunck <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [187/2many] MAINTAINERS - EXT3 FILE SYSTEM
On Aug 13, 2007 02:59 -0600, Andreas Dilger wrote: > > EXT3 FILE SYSTEM > > You may as well have fs/jbd/* and include/linux/jbd.h for ext3. Ignore this, there is a separate section for that already... Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ext3: fix ext34_fill_super group description initialization
Dmitry Monakhov wrote: ->s_group_desc have to be zero filled because if sb_read() failed we jump to following error path. failed_mount2: for (i = 0; i < db_count; i++) brelse(sbi->s_group_desc[i]);<< Bad things may happen here But the db_count is updated in the failure path to point to the number of successful sb_read. -aneesh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ext3: fix ext34_fill_super group description initialization
On 13:09 Mon 13 Aug , Dmitry Monakhov wrote:
> ->s_group_desc have to be zero filled because if sb_read() failed
> we jump to following error path.
> failed_mount2:
> for (i = 0; i < db_count; i++)
> brelse(sbi->s_group_desc[i]);<< Bad things may happen here
OOPs i'm sorry. I've lost db_count changing after sb_read() error,
so error path is ok, and this patch is not needed.
>
> Signed-off-by: Dmitry Monakhov <[EMAIL PROTECTED]>
> ---
> fs/ext3/super.c |2 +-
> fs/ext4/super.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ext3/super.c b/fs/ext3/super.c
> index f8ac18f..208738e 100644
> --- a/fs/ext3/super.c
> +++ b/fs/ext3/super.c
> @@ -1718,7 +1718,7 @@ static int ext3_fill_super (struct super_block *sb,
> void *data, int silent)
> / EXT3_BLOCKS_PER_GROUP(sb)) + 1;
> db_count = (sbi->s_groups_count + EXT3_DESC_PER_BLOCK(sb) - 1) /
> EXT3_DESC_PER_BLOCK(sb);
> - sbi->s_group_desc = kmalloc(db_count * sizeof (struct buffer_head *),
> + sbi->s_group_desc = kzalloc(db_count * sizeof (struct buffer_head *),
> GFP_KERNEL);
> if (sbi->s_group_desc == NULL) {
> printk (KERN_ERR "EXT3-fs: not enough memory\n");
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 8f1d2f6..fefffc0 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -1830,7 +1830,7 @@ static int ext4_fill_super (struct super_block *sb,
> void *data, int silent)
> sbi->s_groups_count = blocks_count;
> db_count = (sbi->s_groups_count + EXT4_DESC_PER_BLOCK(sb) - 1) /
> EXT4_DESC_PER_BLOCK(sb);
> - sbi->s_group_desc = kmalloc(db_count * sizeof (struct buffer_head *),
> + sbi->s_group_desc = kzalloc(db_count * sizeof (struct buffer_head *),
> GFP_KERNEL);
> if (sbi->s_group_desc == NULL) {
> printk (KERN_ERR "EXT4-fs: not enough memory\n");
> --
> 1.5.2.2
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Original Toner Cartridge promotion
Dear All Customers, === Original Toner Cartridge promotion === HP toner: 1) C7115A = RM170; 2) C3906F = RM175; 3) Q2612A = RM 199; 4) Q5949A = RM 199; Samsung toner: 1) ML-1710 = RM 249; 2) ML-2010 = RM 239; Xerox toner: 1) 203A = RM 149; ** ADVANTAGES : Printer repairs & services available ** To REDUCE or SAVE more cost, please do not hesitate to contact us for more information. regards, Mr Ken Tel: 012-366 2818 IT CITY COMPUTER 46M, Jalan Wangsa 2/5, Taman Wangsa Permai, Kepong 52100. Kuala Lumpur. Tel: 03-6276 3561 Fax: 03-6272 9718 Email: [EMAIL PROTECTED] - pls refer to terms & conditions - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 05/11] dm-snap: remove SECTOR_SHIFT define
On Fri, Aug 10, Alasdair G Kergon wrote:
> On Fri, Aug 10, 2007 at 10:02:09PM +0200, Jan Blunck wrote:
> > Sector size on Linux is always 512 bytes. Don't even try to give the
> > impression this is changeable.
>
> If that's what worries you, add a comment next to the definition,
> perhaps?
That and that the code just looks more like the rest of the block layer
code. Only a few users (UFS, MSDOS, HFS, IDE) use a predefined
SECTOR_{SHIFT,SIZE}.
> It's there so you can easily locate all the places within dm that
> perform these conversions by using a simple search. Searching for '9'
> wouldn't be as easy. (I don't know about other people, but I find the
> code easier to read the way it is.)
Hmm, so I guess this is more about dis/like of how the code looks. Maybe we
should define a global SECTOR_{SIZE,SHIFT} into blkdev.h.
Regards,
Jan
--
Jan Blunck <[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: Distributed storage.
On Mon, Aug 13, 2007 at 02:08:57AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: > > But that idea fails as well, since reference counts and IO completion > > are two completely seperate entities. So unless end IO just happens > > to be the last user holding a reference to the bio, you cannot free > > it. > > That is not a problem. When bio_put hits zero it calls ->endio instead > of the destructor. The ->endio sees that the count is zero and > destroys the bio. This is not a very good solution, since it requires all users of the bios to know how to free it. Right now it is hidden. And adds additional atomic check (although reading is quite fast) in the end_io. And for what purpose? To eat 8 bytes on 64bit platform? This will not reduce its size noticebly, so the same number of bios will be in the cache's page, so what is a gain? All this cleanups and logic complicatins should be performed only if after size shring increased number of bios can fit into cache's page, will it be done after such cleanups? -- 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] [148/2many] MAINTAINERS - DCCP PROTOCOL
On 8/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 7f54480..c786066 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1434,6 +1434,8 @@ M:[EMAIL PROTECTED] > L: [EMAIL PROTECTED] > W: http://linux-net.osdl.org/index.php/DCCP > S: Maintained > +F: include/linux/dccp.h > +F: net/dccp/ > Provided this patch series goes in then we need to add this in as well as part of DCCP subsystem: F: include/linux/tfrc.h Once this is done, and series goes in then: Acked-by: Ian McDonald <[EMAIL PROTECTED]> -- Web1: http://wand.net.nz/~iam4/ Web2: http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [550/2many] MAINTAINERS - YEALINK PHONE DRIVER
On Sun, Aug 12, 2007 at 11:39:58PM -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 2773da9..351e6bf 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5206,6 +5206,8 @@ P: Henk Vergonet > M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > S: Maintained > +F: Documentation/input/yealink.txt > +F: drivers/input/misc/yealink.* You might want to add: +F: drivers/input/misc/map_to_7segment.h > > Z8530 DRIVER FOR AX.25 > P: Joerg Reuter Thanks, Henk Vergonet - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Distributed storage.
On Mon, Aug 13 2007, Daniel Phillips wrote: > On Monday 13 August 2007 00:45, Jens Axboe wrote: > > On Mon, Aug 13 2007, Jens Axboe wrote: > > > > You did not comment on the one about putting the bio destructor > > > > in the ->endio handler, which looks dead simple. The majority of > > > > cases just use the default endio handler and the default > > > > destructor. Of the remaining cases, where a specialized > > > > destructor is needed, typically a specialized endio handler is > > > > too, so combining is free. There are few if any cases where a > > > > new specialized endio handler would need to be written. > > > > > > We could do that without too much work, I agree. > > > > But that idea fails as well, since reference counts and IO completion > > are two completely seperate entities. So unless end IO just happens > > to be the last user holding a reference to the bio, you cannot free > > it. > > That is not a problem. When bio_put hits zero it calls ->endio instead > of the destructor. The ->endio sees that the count is zero and > destroys the bio. You can't be serious? You'd stall end io completion notification because someone holds a reference to a bio. Surely you jest. Needless to say, that will never go in. -- 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: Distributed storage.
On Mon, Aug 13 2007, Daniel Phillips wrote: > On Monday 13 August 2007 00:28, Jens Axboe wrote: > > On Sun, Aug 12 2007, Daniel Phillips wrote: > > > Right, that is done by bi_vcnt. I meant bi_max_vecs, which you can > > > derive efficiently from BIO_POOL_IDX() provided the bio was > > > allocated in the standard way. > > > > That would only be feasible, if we ruled that any bio in the system > > must originate from the standard pools. > > Not at all. > > > > This leaves a little bit of clean up to do for bios not allocated > > > from a standard pool. > > > > Please suggest how to do such a cleanup. > > Easy, use the BIO_POOL bits to know the bi_max_size, the same as for a > bio from the standard pool. Just put the power of two size in the bits > and map that number to the standard pool arrangement with a table > lookup. So reserve a bit that tells you how to interpret the (now) 3 remaining bits. Doesn't sound very pretty, does it? > > > On the other hand, vm writeout deadlock ranks smack dab at the top > > > of the list, so that is where the patching effort must go for the > > > forseeable future. Without bio throttling, the ddsnap load can go > > > to 24 MB for struct bio alone. That definitely moves the needle. > > > in short, we save 3,200 times more memory by putting decent > > > throttling in place than by saving an int in struct bio. > > > > Then fix the damn vm writeout. I always thought it was silly to > > depend on the block layer for any sort of throttling. If it's not a > > system wide problem, then throttle the io count in the > > make_request_fn handler of that problematic driver. > > It is a system wide problem. Every block device needs throttling, > otherwise queues expand without limit. Currently, block devices that > use the standard request library get a slipshod form of throttling for > free in the form of limiting in-flight request structs. Because the > amount of IO carried by a single request can vary by two orders of > magnitude, the system behavior of this approach is far from > predictable. Is it? Consider just 10 standard sata disks. The next kernel revision will have sg chaining support, so that allows 32MiB per request. Even if we disregard reads (not so interesting in this discussion) and just look at potentially pinned dirty data in a single queue, that number comes to 4GiB PER disk. Or 40GiB for 10 disks. Auch. So I still think that this throttling needs to happen elsewhere, you cannot rely the block layer throttling globally or for a single device. It just doesn't make sense. > > > You did not comment on the one about putting the bio destructor in > > > the ->endio handler, which looks dead simple. The majority of > > > cases just use the default endio handler and the default > > > destructor. Of the remaining cases, where a specialized destructor > > > is needed, typically a specialized endio handler is too, so > > > combining is free. There are few if any cases where a new > > > specialized endio handler would need to be written. > > > > We could do that without too much work, I agree. > > OK, we got one and another is close to cracking, enough of that. No we did not, I already failed this one in the next mail. > > > As far as code stability goes, current kernels are horribly > > > unstable in a variety of contexts because of memory deadlock and > > > slowdowns related to the attempt to fix the problem via dirty > > > memory limits. Accurate throttling of bio traffic is one of the > > > two key requirements to fix this instability, the other other is > > > accurate writeout path reserve management, which is only partially > > > addressed by BIO_POOL. > > > > Which, as written above and stated many times over the years on lkml, > > is not a block layer issue imho. > > Whoever stated that was wrong, but this should be no surprise. There > have been many wrong things said about this particular bug over the > years. The one thing that remains constant is, Linux continues to > deadlock under a variety of loads both with and without network > involvement, making it effectively useless as a storage platform. > > These deadlocks are first and foremost, block layer deficiencies. Even > the network becomes part of the problem only because it lies in the > block IO path. The block layer has NEVER guaranteed throttling, so it can - by definition - not be a block layer deficiency. -- 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/
[PATCH] ext3: fix ext34_fill_super group description initialization
->s_group_desc have to be zero filled because if sb_read() failed
we jump to following error path.
failed_mount2:
for (i = 0; i < db_count; i++)
brelse(sbi->s_group_desc[i]);<< Bad things may happen here
Signed-off-by: Dmitry Monakhov <[EMAIL PROTECTED]>
---
fs/ext3/super.c |2 +-
fs/ext4/super.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index f8ac18f..208738e 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -1718,7 +1718,7 @@ static int ext3_fill_super (struct super_block *sb, void
*data, int silent)
/ EXT3_BLOCKS_PER_GROUP(sb)) + 1;
db_count = (sbi->s_groups_count + EXT3_DESC_PER_BLOCK(sb) - 1) /
EXT3_DESC_PER_BLOCK(sb);
- sbi->s_group_desc = kmalloc(db_count * sizeof (struct buffer_head *),
+ sbi->s_group_desc = kzalloc(db_count * sizeof (struct buffer_head *),
GFP_KERNEL);
if (sbi->s_group_desc == NULL) {
printk (KERN_ERR "EXT3-fs: not enough memory\n");
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 8f1d2f6..fefffc0 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1830,7 +1830,7 @@ static int ext4_fill_super (struct super_block *sb, void
*data, int silent)
sbi->s_groups_count = blocks_count;
db_count = (sbi->s_groups_count + EXT4_DESC_PER_BLOCK(sb) - 1) /
EXT4_DESC_PER_BLOCK(sb);
- sbi->s_group_desc = kmalloc(db_count * sizeof (struct buffer_head *),
+ sbi->s_group_desc = kzalloc(db_count * sizeof (struct buffer_head *),
GFP_KERNEL);
if (sbi->s_group_desc == NULL) {
printk (KERN_ERR "EXT4-fs: not enough memory\n");
--
1.5.2.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/
Re: Distributed storage.
On Monday 13 August 2007 00:45, Jens Axboe wrote: > On Mon, Aug 13 2007, Jens Axboe wrote: > > > You did not comment on the one about putting the bio destructor > > > in the ->endio handler, which looks dead simple. The majority of > > > cases just use the default endio handler and the default > > > destructor. Of the remaining cases, where a specialized > > > destructor is needed, typically a specialized endio handler is > > > too, so combining is free. There are few if any cases where a > > > new specialized endio handler would need to be written. > > > > We could do that without too much work, I agree. > > But that idea fails as well, since reference counts and IO completion > are two completely seperate entities. So unless end IO just happens > to be the last user holding a reference to the bio, you cannot free > it. That is not a problem. When bio_put hits zero it calls ->endio instead of the destructor. The ->endio sees that the count is zero and destroys the bio. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])
On Aug 12 2007 20:21, [EMAIL PROTECTED] wrote: > > per the message below MD (or DM) would need to be modified to work > reasonably well with one of the disk components being over an > unreliable link (like a network link) Does not dm-multipath do something like that? > are the MD/DM maintainers interested in extending their code in this > direction? > or would they prefer to keep it simpler by being able to continue to assume > that the raid components are connected over a highly reliable connection? 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] [188/2many] MAINTAINERS - EXT4 FILE SYSTEM
On Aug 12, 2007 23:27 -0700, [EMAIL PROTECTED] wrote: > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 814168d..992a314 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1808,10 +1808,16 @@ F:fs/ext3/ > F: include/linux/ext3* > > EXT4 FILE SYSTEM > -P: Stephen Tweedie, Andrew Morton > -M: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] > +P: Stephen Tweedie > +M: [EMAIL PROTECTED] > +P: Andrew Morton > +M: [EMAIL PROTECTED] > +P: Andreas Dilger > +M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > S: Maintained > +F: fs/ext4/ > +F: include/linux/ext4* To be honest, Stephen and Andrew haven't been directly involved in the ext4 development. It probably makes more sense to have e.g. Eric Sandeen, Ted Ts'o, and MingMing Cao in their place. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [208/2many] MAINTAINERS - GFS2 FILE SYSTEM
Hi, On Sun, 2007-08-12 at 23:28 -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index d8063ee..b4183e7 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1992,6 +1992,9 @@ W: http://sources.redhat.com/cluster/ > T: git kernel.org:/pub/scm/linux/kernel/git/steve/gfs2-2.6-fixes.git > T: git kernel.org:/pub/scm/linux/kernel/git/steve/gfs2-2.6-nmw.git > S: Supported > +F: /Documentation/filesystems/gfs2.txt > +F: fs/gfs2/ > +F: include/linux/gfs2_ondisk.h This is missing: F: include/linux/lm_interface.h Steve. > > GIGASET ISDN DRIVERS > P: Hansjoerg Lipp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Distributed storage.
On Monday 13 August 2007 00:28, Jens Axboe wrote: > On Sun, Aug 12 2007, Daniel Phillips wrote: > > Right, that is done by bi_vcnt. I meant bi_max_vecs, which you can > > derive efficiently from BIO_POOL_IDX() provided the bio was > > allocated in the standard way. > > That would only be feasible, if we ruled that any bio in the system > must originate from the standard pools. Not at all. > > This leaves a little bit of clean up to do for bios not allocated > > from a standard pool. > > Please suggest how to do such a cleanup. Easy, use the BIO_POOL bits to know the bi_max_size, the same as for a bio from the standard pool. Just put the power of two size in the bits and map that number to the standard pool arrangement with a table lookup. > > On the other hand, vm writeout deadlock ranks smack dab at the top > > of the list, so that is where the patching effort must go for the > > forseeable future. Without bio throttling, the ddsnap load can go > > to 24 MB for struct bio alone. That definitely moves the needle. > > in short, we save 3,200 times more memory by putting decent > > throttling in place than by saving an int in struct bio. > > Then fix the damn vm writeout. I always thought it was silly to > depend on the block layer for any sort of throttling. If it's not a > system wide problem, then throttle the io count in the > make_request_fn handler of that problematic driver. It is a system wide problem. Every block device needs throttling, otherwise queues expand without limit. Currently, block devices that use the standard request library get a slipshod form of throttling for free in the form of limiting in-flight request structs. Because the amount of IO carried by a single request can vary by two orders of magnitude, the system behavior of this approach is far from predictable. > > You did not comment on the one about putting the bio destructor in > > the ->endio handler, which looks dead simple. The majority of > > cases just use the default endio handler and the default > > destructor. Of the remaining cases, where a specialized destructor > > is needed, typically a specialized endio handler is too, so > > combining is free. There are few if any cases where a new > > specialized endio handler would need to be written. > > We could do that without too much work, I agree. OK, we got one and another is close to cracking, enough of that. > > As far as code stability goes, current kernels are horribly > > unstable in a variety of contexts because of memory deadlock and > > slowdowns related to the attempt to fix the problem via dirty > > memory limits. Accurate throttling of bio traffic is one of the > > two key requirements to fix this instability, the other other is > > accurate writeout path reserve management, which is only partially > > addressed by BIO_POOL. > > Which, as written above and stated many times over the years on lkml, > is not a block layer issue imho. Whoever stated that was wrong, but this should be no surprise. There have been many wrong things said about this particular bug over the years. The one thing that remains constant is, Linux continues to deadlock under a variety of loads both with and without network involvement, making it effectively useless as a storage platform. These deadlocks are first and foremost, block layer deficiencies. Even the network becomes part of the problem only because it lies in the block IO path. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [187/2many] MAINTAINERS - EXT3 FILE SYSTEM
On Aug 12, 2007 23:27 -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 653b9a0..814168d 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1796,10 +1796,16 @@ F:fs/ext2/ > F: include/linux/ext2* > > EXT3 FILE SYSTEM > -P: Stephen Tweedie, Andrew Morton > -M: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] > +P: Stephen Tweedie > +M: [EMAIL PROTECTED] > +P: Andrew Morton > +M: [EMAIL PROTECTED] > +P: Andreas Dilger > +M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > S: Maintained > +F: fs/ext3/ > +F: include/linux/ext3* You may as well have fs/jbd/* and include/linux/jbd.h for ext3. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Original Toner Cartridge promotion
Dear All Customers, === Original Toner Cartridge promotion === HP toner: 1) C7115A = RM170; 2) C3906F = RM175; 3) Q2612A = RM 199; 4) Q5949A = RM 199; Samsung toner: 1) ML-1710 = RM 249; 2) ML-2010 = RM 239; Xerox toner: 1) 203A = RM 149; ** ADVANTAGES : Printer repairs & services available ** To REDUCE or SAVE more cost, please do not hesitate to contact us for more information. regards, Mr Ken Tel: 012-366 2818 IT CITY COMPUTER 46M, Jalan Wangsa 2/5, Taman Wangsa Permai, Kepong 52100. Kuala Lumpur. Tel: 03-6276 3561 Fax: 03-6272 9718 Email: [EMAIL PROTECTED] - pls refer to terms & conditions - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [467/2many] MAINTAINERS - SVGA HANDLING
Hello! > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index e0020d6..cde4be1 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4440,6 +4440,9 @@ P: Martin Mares > M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > S: Maintained > +F: Documentation/svga.txt OK. > +F: drivers/video/svgalib.c > +F: include/linux/svga.h These two are not a part of the video mode selection code, but arch/i386/boot/video.S is. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Got mole problems? Call Avogadro, 602-1023! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kvm-devel] [PATCH 0/2][KVM] guest time accounting
Laurent Vivier wrote: - perhaps the new fields should be guarded by a #ifdef CONFIG_HYPERVISOR (selected by CONFIG_KVM)? that way the (minor) additional overhead is only incurred if it can possibly be used. I imagine that our canine cousin will want to use this as well. There is also a CONFIG_VIRTUALIZATION and a CONFIG_VIRT_CPU_ACCOUNTING (from s390 and powerpc) Which one to use ? Are these options for using the kernel as a guest or host? I'd guess the former. I'm wondering if we can have a more accurate accounting: - For the moment we add all system time since the previous entering to the VCPU to the guest time (and I guess there is some real system time in it ???) - Perhaps we can sum nanoseconds spent in the VCPU and add it to cpustat when these ns are greater than 1 ms ? (I'm trying to make something in this way) I think that it's okay to use the same method as user/system time accounting. But Ingo the the right man to ask. -- error compiling committee.c: too many arguments to function - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 17/23] mm: count writeback pages per BDI
On Thu, 2007-08-09 at 12:27 -0700, Christoph Lameter wrote: > On Thu, 9 Aug 2007, Peter Zijlstra wrote: > > > Less conditionals. We already have a branch for mapping, why create > > another? > > Ah. Okay. This also avoids an interrupt enable disable since you can use > __ functions. Hmmm... Would be good if we could move the vmstat > NR_WRITEBACK update there too. Can a page without a mapping be under > writeback? (Direct I/O?) DIO still uses the mapping afaik (it needs to invalidate the page before and after the OP). But you could put the increment in both paths, and use the irq disable from the mapping branch - which should be the most frequent case anyway. signature.asc Description: This is a digitally signed message part
Re: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])
On Mon, 13 Aug 2007, David Greaves wrote: [EMAIL PROTECTED] wrote: per the message below MD (or DM) would need to be modified to work reasonably well with one of the disk components being over an unreliable link (like a network link) are the MD/DM maintainers interested in extending their code in this direction? or would they prefer to keep it simpler by being able to continue to assume that the raid components are connected over a highly reliable connection? if they are interested in adding (and maintaining) this functionality then there is a real possibility that NBD+MD/DM could eliminate the need for DRDB. however if they are not interested in adding all the code to deal with the network type issues, then the argument that DRDB should not be merged becouse you can do the same thing with MD/DM + NBD is invalid and can be dropped/ignored David Lang As a user I'd like to see md/nbd be extended to cope with unreliable links. I think md could be better in handling link exceptions. My unreliable memory recalls sporadic issues with hot-plug leaving md hanging and certain lower level errors (or even very high latency) causing unsatisfactory behaviour in what is supposed to be a fault 'tolerant' subsystem. Would this just be relevant to network devices or would it improve support for jostled usb and sata hot-plugging I wonder? good question, I suspect that some of the error handling would be similar (for devices that are unreachable not haning the system for example), but a lot of the rest would be different (do you really want to try to auto-resync to a drive that you _think_ just reappeared, what if it's a different drive? how can you be sure?) the error rate of a network is gong to be significantly higher then for USB or SATA drives (although I suppose iscsi would be limilar) David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 17/23] Add cmpxchg_local to s390
On Sun, Aug 12, 2007 at 10:54:51AM -0400, Mathieu Desnoyers wrote:
> Use the standard __cmpxchg for every type that can be updated atomically.
> Use the new generic cmpxchg_local (disables interrupt) for other types.
>
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> ---
> include/asm-s390/system.h | 34 ++
> 1 file changed, 34 insertions(+)
>
> Index: linux-2.6-lttng/include/asm-s390/system.h
> ===
> --- linux-2.6-lttng.orig/include/asm-s390/system.h2007-08-10
> 16:16:21.0 -0400
> +++ linux-2.6-lttng/include/asm-s390/system.h 2007-08-10 19:35:46.0
> -0400
> @@ -353,6 +353,40 @@ __cmpxchg(volatile void *ptr, unsigned l
>
> #include
>
> +#include
> +
> +static inline unsigned long __cmpxchg_local(volatile void *ptr,
> + unsigned long old,
> + unsigned long new, int size)
> +{
> + switch (size) {
> + case 1:
> + case 2:
> + case 4:
> +#ifdef __s390x__
> + case 8:
> +#endif
> + return __cmpxchg(ptr, old, new, size);
> + default:
> + return __cmpxchg_local_generic(ptr, old, new, size);
> + }
> +
> + return old;
> +}
> +
> +/*
> + * cmpxchg_local and cmpxchg64_local are atomic wrt current CPU. Always make
> + * them available.
> + */
> +#define cmpxchg_local(ptr,o,n)
> \
> + (__typeof__(*(ptr)))__cmpxchg_local((ptr), (unsigned long)(o), \
> + (unsigned long)(n), sizeof(*(ptr)))
> +#ifdef __s390x__
> +#define cmpxchg64_local(ptr,o,n) cmpxchg_local((ptr),(o),(n))
> +#else
> +#define cmpxchg64_local(ptr,o,n) __cmpxchg64_local_generic((ptr), (o), (n))
> +#endif
> +
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] [367/2many] MAINTAINERS - PC8736x GPIO DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches <[EMAIL PROTECTED]> diff --git a/MAINTAINERS b/MAINTAINERS index 2eb1a7c..c3bd8f8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3535,6 +3535,7 @@ PC8736x GPIO DRIVER P: Jim Cromie M: [EMAIL PROTECTED] S: Maintained +F: drivers/char/pc8736x_gpio.c PCI ERROR RECOVERY P: Linas Vepstas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[KJ] replacing kmalloc with kzalloc in io_apic.c
Hi,
Replacing kmalloc with kzalloc and cleaning up memset in
arch/i386/kernel/io_apic.c
Signed-off-by: Surya Prabhakar <[EMAIL PROTECTED]>
---
diff --git a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c
index 4b8a8da..1329615 100644
--- a/arch/i386/kernel/io_apic.c
+++ b/arch/i386/kernel/io_apic.c
@@ -690,14 +690,12 @@ static int __init balanced_irq_init(void)
physical_balance = 1;
for_each_online_cpu(i) {
- irq_cpu_data[i].irq_delta = kmalloc(sizeof(unsigned long) *
NR_IRQS, GFP_KERNEL);
- irq_cpu_data[i].last_irq = kmalloc(sizeof(unsigned long) *
NR_IRQS, GFP_KERNEL);
+ irq_cpu_data[i].irq_delta = kzalloc(sizeof(unsigned long) *
NR_IRQS, GFP_KERNEL);
+ irq_cpu_data[i].last_irq = kzalloc(sizeof(unsigned long) *
NR_IRQS, GFP_KERNEL);
if (irq_cpu_data[i].irq_delta == NULL ||
irq_cpu_data[i].last_irq == NULL) {
printk(KERN_ERR "balanced_irq_init: out of memory");
goto failed;
}
- memset(irq_cpu_data[i].irq_delta,0,sizeof(unsigned long) *
NR_IRQS);
- memset(irq_cpu_data[i].last_irq,0,sizeof(unsigned long) *
NR_IRQS);
}
printk(KERN_INFO "Starting balanced_irq\n");
thanks
surya.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Block device throttling [Re: Distributed storage.]
On Sun, Aug 12, 2007 at 10:36:23PM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: > (previous incomplete message sent accidentally) > > On Wednesday 08 August 2007 02:54, Evgeniy Polyakov wrote: > > On Tue, Aug 07, 2007 at 10:55:38PM +0200, Jens Axboe wrote: > > > > So, what did we decide? To bloat bio a bit (add a queue pointer) or > > to use physical device limits? The latter requires to replace all > > occurence of bio->bi_bdev = something_new with blk_set_bdev(bio, > > somthing_new), where queue limits will be appropriately charged. So > > far I'm testing second case, but I only changed DST for testing, can > > change all other users if needed though. > > Adding a queue pointer to struct bio and using physical device limits as > in your posted patch both suffer from the same problem: you release the > throttling on the previous queue when the bio moves to a new one, which > is a bug because memory consumption on the previous queue then becomes > unbounded, or limited only by the number of struct requests that can be > allocated. In other words, it reverts to the same situation we have > now as soon as the IO stack has more than one queue. (Just a shorter > version of my previous post.) No. Since all requests for virtual device end up in physical devices, which have limits, this mechanism works. Virtual device will essentially call either generic_make_request() for new physical device (and thus will sleep is limit is over), or will process bios directly, but in that case it will sleep in generic_make_request() for virutal device. > 1) One throttle count per submitted bio is too crude a measure. A bio > can carry as few as one page or as many as 256 pages. If you take only It does not matter - we can count bytes, pages, bio vectors or whatever we like, its just a matter of counter and can be changed without problem. > 2) Exposing the per-block device throttle limits via sysfs or similar is > really not a good long term solution for system administration. > Imagine our help text: "just keep trying smaller numbers until your > system deadlocks". We really need to figure this out internally and > get it correct. I can see putting in a temporary userspace interface > just for experimentation, to help determine what really is safe, and > what size the numbers should be to approach optimal throughput in a > fully loaded memory state. Well, we already have number of such 'supposed-to-be-automatic' variables exported to userspace, so this will not change a picture, frankly I do not care if there will or will not be any sysfs exported tunable, eventually we can remove it or do not create at all. -- 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/4] signalfd: fix interaction with posix-timers
On 08/12, Roland McGrath wrote: > > This only affects signalfd and so the core change seems ok vs status quo. > > I think it would be better overall not to have anyone like signalfd calling > dequeue_signal in its current form at all. (The function is too much an > internal piece of the core signals code. The SIGNAL_STOP_DEQUEUED code > applying for signalfd calls is probably another problem, for example.) I agree, the "tsk != current" case is not nice. We can forbid fetching signals from another thread group and remove it, this is very easy. Until then, we can't avoid it without the code duplication. But SIGNAL_STOP_DEQUEUED code should be OK, afaics. We only need it to make sure do_signal_stop() can't miss SIGNAL_STOP_CONTINUED/GROUP_EXIT. Can't we remove SIGNAL_STOP_DEQUEUED, btw? dequeue_signal: if (sig_kernel_stop(sig)) ->flags &= ~SIGNAL_STOP_CONTINUED; do_signal_stop: if (flags & (SIGNAL_STOP_CONTINUED | SIGNAL_GROUP_EXIT)) return 0; Possible? Oleg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/1] Block device throttling [Re: Distributed storage.]
Hi Daniel. On Sun, Aug 12, 2007 at 04:16:10PM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: > Your patch is close to the truth, but it needs to throttle at the top > (virtual) end of each block device stack instead of the bottom > (physical) end. It does head in the direction of eliminating your own > deadlock risk indeed, however there are block devices it does not > cover. I decided to limit physical devices just because any limit on top of virtual one is not correct. When system recharges bio from virtual device to physical, and the latter is full, virtual device will not accept any new blocks for that physical device, but can accept for another ones. That was created specially to allow fair use for network and physical storages. -- 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] [460/2many] MAINTAINERS - SRM (Alpha) environment access
On Sun, 2007-08-12 23:36:44 -0700, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index fa8fb1c..3c134fa 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4386,6 +4386,8 @@ P: Jan-Benedict Glaw > M: [EMAIL PROTECTED] > L: linux-kernel@vger.kernel.org > S: Maintained > +F: arch/alpha/kernel/*srm* > +F: arch/alpha/lib/srm* > > STARFIRE/DURALAN NETWORK DRIVER > P: Ion Badulescu NACK. I only care about arch/alpha/kernel/srm_env.c and don't know about all the others that match. So this should simply be: F: arch/alpha/kernel/srm_env.c MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481 Signature of: Ich hatte in letzter Zeit ein bißchen viel Realitycheck. the second : Langsam möchte ich mal wieder weiterträumen können. -- Maximilian Wilhelm (18. Mai 2006, #lug-owl.de) signature.asc Description: Digital signature
Re: Block device throttling [Re: Distributed storage.]
On Sun, Aug 12, 2007 at 11:44:00PM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: > On Sunday 12 August 2007 22:36, I wrote: > > Note! There are two more issues I forgot to mention earlier. > > Oops, and there is also: > > 3) The bio throttle, which is supposed to prevent deadlock, can itself > deadlock. Let me see if I can remember how it goes. > > * generic_make_request puts a bio in flight > * the bio gets past the throttle and initiates network IO > * net calls sk_alloc->alloc_pages->shrink_caches > * shrink_caches submits a bio recursively to our block device > * this bio blocks on the throttle > * net may never get the memory it needs, and we are wedged If system is in such condition, it is already broken - throttle limit must be lowered (next time) not to allow such situation. -- 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] [198/2many] MAINTAINERS - FIREWIRE SUBSYSTEM
On 8/13/2007 10:10 AM, Stefan Richter wrote: > [EMAIL PROTECTED] wrote: >> Add file pattern to MAINTAINER entry >> >> Signed-off-by: Joe Perches <[EMAIL PROTECTED]> >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 9aa822a..18dfe29 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -1895,12 +1895,15 @@ S: Maintained >> F: fs/* >> >> FIREWIRE SUBSYSTEM >> -P: Kristian Hoegsberg, Stefan Richter >> -M: [EMAIL PROTECTED], [EMAIL PROTECTED] >> +P: Kristian Hoegsberg >> +M: [EMAIL PROTECTED] >> +P: Stefan Richter >> +M: [EMAIL PROTECTED] >> L: [EMAIL PROTECTED] >> W: http://www.linux1394.org/ >> T: git kernel.org:/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git >> S: Maintained >> +F: drivers/ieee/1394/ > > Wrong path. > >> >> FIRMWARE LOADER (request_firmware) >> L: linux-kernel@vger.kernel.org > > > +F: drivers/firewire/ > +F: include/linux/firewire-*.h > PS: This is of course for FIREWIRE, not for FIRMWARE LOADER. -- Stefan Richter -=-=-=== =--- -==-= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [244/2many] MAINTAINERS - IEEE 1394 SUBSYSTEM
[EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 2063c0f..26c460a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2312,6 +2312,7 @@ L: [EMAIL PROTECTED] > W: http://www.linux1394.org/ > T: git kernel.org:/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git > S: Maintained > +F: drivers/ieee/1394/ Wrong path. +F: drivers/ieee1394/ > > IEEE 1394 RAW I/O DRIVER (raw1394) > P: Dan Dennedy -- Stefan Richter -=-=-=== =--- -==-= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kvm-devel] [PATCH 0/2][KVM] guest time accounting
Avi Kivity wrote: > Laurent Vivier wrote: >> The aim of these two patches is to measure the CPU time used by a virtual >> machine. All comments are welcome... I'm not sure it's the good way to >> do that. >> >> [PATCH 1/2] introduce a new field, "guest", in cpustat to store the >> time used by >> the CPU to run virtual CPU. Modify /proc/stat to display this new field. >> >> [PATCH 2/2] modify account_system_time() to add cputime to >> cpustat->guest if we >> are running a VCPU. We add this cputime to cpustat->user instead of >> cpustat->system because this part of KVM code is in fact user code >> although it >> is executed in the kernel. We duplicate VCPU time between guest and >> user to >> allow an unmodified "top(1)" to display correct value. A modified >> "top(1)" is >> able to display good cpu user time and cpu guest time by subtracting >> cpu guest >> time from cpu user time. >> > > [copying Ingo and Rusty] > > The patches look good. A couple of comments: > > - perhaps the new fields should be guarded by a #ifdef CONFIG_HYPERVISOR > (selected by CONFIG_KVM)? that way the (minor) additional overhead is > only incurred if it can possibly be used. I imagine that our canine > cousin will want to use this as well. There is also a CONFIG_VIRTUALIZATION and a CONFIG_VIRT_CPU_ACCOUNTING (from s390 and powerpc) Which one to use ? I'm wondering if we can have a more accurate accounting: - For the moment we add all system time since the previous entering to the VCPU to the guest time (and I guess there is some real system time in it ???) - Perhaps we can sum nanoseconds spent in the VCPU and add it to cpustat when these ns are greater than 1 ms ? (I'm trying to make something in this way) > - I think that there is per-task accounting of user time and system > time; that should be extended as well. it should be easy to do too... Laurent -- - [EMAIL PROTECTED] -- "Software is hard" - Donald Knuth signature.asc Description: OpenPGP digital signature
Re: [PATCH] [245/2many] MAINTAINERS - IEEE 1394 RAW I/O DRIVER (raw1394)
[EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> ACK. > > diff --git a/MAINTAINERS b/MAINTAINERS > index 26c460a..7889eb8 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2321,6 +2321,7 @@ P: Stefan Richter > M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > S: Maintained > +F: drivers/ieee1394/raw1394* > > IMS TWINTURBO FRAMEBUFFER DRIVER > P: Paul Mundt -- Stefan Richter -=-=-=== =--- -==-= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [198/2many] MAINTAINERS - FIREWIRE SUBSYSTEM
[EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9aa822a..18dfe29 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1895,12 +1895,15 @@ S:Maintained > F: fs/* > > FIREWIRE SUBSYSTEM > -P: Kristian Hoegsberg, Stefan Richter > -M: [EMAIL PROTECTED], [EMAIL PROTECTED] > +P: Kristian Hoegsberg > +M: [EMAIL PROTECTED] > +P: Stefan Richter > +M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > W: http://www.linux1394.org/ > T: git kernel.org:/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git > S: Maintained > +F: drivers/ieee/1394/ Wrong path. > > FIRMWARE LOADER (request_firmware) > L: linux-kernel@vger.kernel.org +F: drivers/firewire/ +F: include/linux/firewire-*.h -- Stefan Richter -=-=-=== =--- -==-= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])
[EMAIL PROTECTED] wrote: per the message below MD (or DM) would need to be modified to work reasonably well with one of the disk components being over an unreliable link (like a network link) are the MD/DM maintainers interested in extending their code in this direction? or would they prefer to keep it simpler by being able to continue to assume that the raid components are connected over a highly reliable connection? if they are interested in adding (and maintaining) this functionality then there is a real possibility that NBD+MD/DM could eliminate the need for DRDB. however if they are not interested in adding all the code to deal with the network type issues, then the argument that DRDB should not be merged becouse you can do the same thing with MD/DM + NBD is invalid and can be dropped/ignored David Lang As a user I'd like to see md/nbd be extended to cope with unreliable links. I think md could be better in handling link exceptions. My unreliable memory recalls sporadic issues with hot-plug leaving md hanging and certain lower level errors (or even very high latency) causing unsatisfactory behaviour in what is supposed to be a fault 'tolerant' subsystem. Would this just be relevant to network devices or would it improve support for jostled usb and sata hot-plugging I wonder? David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kvm-devel] [PATCH 0/2][KVM] guest time accounting
Laurent Vivier wrote: The aim of these two patches is to measure the CPU time used by a virtual machine. All comments are welcome... I'm not sure it's the good way to do that. [PATCH 1/2] introduce a new field, "guest", in cpustat to store the time used by the CPU to run virtual CPU. Modify /proc/stat to display this new field. [PATCH 2/2] modify account_system_time() to add cputime to cpustat->guest if we are running a VCPU. We add this cputime to cpustat->user instead of cpustat->system because this part of KVM code is in fact user code although it is executed in the kernel. We duplicate VCPU time between guest and user to allow an unmodified "top(1)" to display correct value. A modified "top(1)" is able to display good cpu user time and cpu guest time by subtracting cpu guest time from cpu user time. [copying Ingo and Rusty] The patches look good. A couple of comments: - perhaps the new fields should be guarded by a #ifdef CONFIG_HYPERVISOR (selected by CONFIG_KVM)? that way the (minor) additional overhead is only incurred if it can possibly be used. I imagine that our canine cousin will want to use this as well. - I think that there is per-task accounting of user time and system time; that should be extended as well. -- error compiling committee.c: too many arguments to function - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/2] spinlock: lockbreak cleanup
On Sat, Aug 11, 2007 at 02:07:43AM +0200, Andi Kleen wrote: > > Nick, > > These two patches make my P4 (single socket HT) test box not boot. I dropped > them for now. > > Some oopses Sorry, the trylock had a race where it would not work correctly :( Have fixed it now and will do more testing and resend to you. Thanks, Nick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [470/2many] MAINTAINERS - TCP LOW PRIORITY MODULE
On thank you very much, that is :) Regards, Edsion -Original Message- From: Joe Perches [mailto:[EMAIL PROTECTED] Sent: Monday, August 13, 2007 3:07 PM To: Edison Wong Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [PATCH] [470/2many] MAINTAINERS - TCP LOW PRIORITY MODULE On Mon, 2007-08-13 at 14:59 +0800, Edison Wong wrote: > Sorry that since Mike and I are both Chinese, the naming format is a bit > different from English style > > Hung Hing Lun (Chinese full name), Mike (English name) > Wong Hoi Sing (Chinese full name), Edison (English name) > > Regards, > Edison I believe commas will cause problems with some emailers. If you weren't allowed to use a comma, what would you choose to display your names? How about: Hung Hing Lun (Mike Hung) Wong Hoi Sing (Edison Wong) cheers, Joe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [95/2many] MAINTAINERS - BLOCK LAYER
On Mon, Aug 13 2007, Joe Perches wrote: > On Mon, 2007-08-13 at 09:28 +0200, Jens Axboe wrote: > > drivers/block/ is block device drivers, not the block layer. That mostly > > resides in block/, with some parts in fs/ as well. > > ok, Do you want to be cc'd on mods in fs/* > > F:block/ > F:fs/* Not really, I'm only interested in select files in under fs/ - as are most, I suspect. -- 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: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])
Paul Clements wrote: Well, if people would like to see a timeout option, I actually coded up a patch a couple of years ago to do just that, but I never got it into mainline because you can do almost as well by doing a check at user-level (I basically ping the nbd connection periodically and if it fails, I kill -9 the nbd-client). Yes please. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Distributed storage.
On Mon, Aug 13 2007, Jens Axboe wrote: > > You did not comment on the one about putting the bio destructor in > > the ->endio handler, which looks dead simple. The majority of cases > > just use the default endio handler and the default destructor. Of the > > remaining cases, where a specialized destructor is needed, typically a > > specialized endio handler is too, so combining is free. There are few > > if any cases where a new specialized endio handler would need to be > > written. > > We could do that without too much work, I agree. But that idea fails as well, since reference counts and IO completion are two completely seperate entities. So unless end IO just happens to be the last user holding a reference to the bio, you cannot free it. -- 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: ATA over ethernet swapping
On Thu, 2007-08-09 at 12:11 +0200, Pavel Machek wrote: > Hi! > > > I've been working on this for quite some time. And should post again > > soon. Please see the patches: > > > > http://programming.kicks-ass.net/kernel-patches/vm_deadlock/current/ > > > > For now it requires one uses SLUB, I hope that SLAB will go away (will > > save me the trouble of adding support) and I guess I ought to do SLOB > > some time (if that does stay). > > > > You'd need the first 22 patches of that series, and then call > > sk_set_memalloc(sk) on the proper socket, and do some fiddling with the > > reconnect logic. See nfs-swapfile.patch for examples. > > What do you use for testing? I set up ata over ethernet... swapping > over that should deadlock w/o your patches. > > But I'm able to compile kernel (-j 10) on 128MB machine, and I tried > cat /dev/zero | grep foo to exhaust memory... and could not reproduce > the deadlock. Should I pingflood? Tweak down ammount of atomic memory > avaialable to make deadlocks easier to reproduce? I usually test swap over NFS in the following manner, I setup a regular inet service on the machine (apache or a bunch of ncat sockets piping to files or something) and run a heavy workload on the machine (128M): 2*64M file backed thrashers and 2*64M anonymous thrashers. Then I start clients for the regular inet service, wait for a bit, and shut down the NFS server. This makes the machine grind to a halt, I then restart the NFS server, wait for it to reconnect and the client to come alive again. Without the last few swap-over-NFS patches this last bit - getting back out of that situation - never happens. The basic idea is to make connectivity to the machine where swap traffic goes very hard (pull a cable, cleanly shut down the server) and to keep other network traffic pounding the machine. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch][rfc] 2.6.23-rc1 mm: NUMA replicated pagecache
On Fri, Aug 10, 2007 at 05:08:18PM -0400, Lee Schermerhorn wrote: > On Wed, 2007-08-08 at 16:25 -0400, Lee Schermerhorn wrote: > > On Fri, 2007-07-27 at 10:42 +0200, Nick Piggin wrote: > > > Hi, > > > > > > Just got a bit of time to take another look at the replicated pagecache > > > patch. The nopage vs invalidate race and clear_page_dirty_for_io fixes > > > gives me more confidence in the locking now; the new ->fault API makes > > > MAP_SHARED write faults much more efficient; and a few bugs were found > > > and fixed. > > > > > > More stats were added: *repl* in /proc/vmstat. Survives some kbuilding > > > tests... > > > > > > > Sending this out to give Nick an update and to give the list a > > heads up on what I've found so far with the replication patch. > > > > I have rebased Nick's recent pagecache replication patch against > > 2.6.23-rc1-mm2, atop my memory policy and auto/lazy migration > > patch sets. These include: > > > > + shared policy > > + migrate-on-fault a.k.a. lazy migration > > + auto-migration - trigger lazy migration on inter-node task > >task migration > > + migration cache - pseudo-swap cache for parking unmapped > > anon pages awaiting migrate-on-fault > > > > I added a couple of patches to fix up the interaction of replication > > with migration [discussed more below] and a per cpuset control to > > enable/disable replication. The latter allowed me to boot successfully > > and to survive any bugs encountered by restricting the effects to > > tasks in the test cpuset with replication enabled. That was the > > theory, anyway :-). Mostly worked... > > After I sent out the last update, I ran a usex job mix overnight ~19.5 hours. > When I came in the next morning, the console window was full of soft lockups > on various cpus with varions stack traces. /var/log/messages showed 142, in > all. > > I've placed the soft lockup reports from /var/log/messages in the Replication > directory on free.linux: > > http://free.linux.hp.com/~lts/Patches/Replication. > > The lockups appeared in several places in the traces I looked at. Here's a > couple of examples: > > + unlink_file_vma() from free_pgtables() during task exit: > mapping->i_mmap_lock ??? > > + smp_call_function() from ia64_global_tlb_purge(). > Maybe the 'call_lock' in arch/ia64/kernel/smp.c ? > Traces show us getting to here in one of 2 ways: > > 1) try_to_unmap* during auto task migration [migrate_pages_unmap_only()...] > > 2) from zap_page_range() when __unreplicate_pcache() calls > unmap_mapping_range. > > + get_page_from_freelist -> zone_lru_lock? > > An interesting point: all of the soft lockup messages said that the cpu was > locked for 11s. Ring any bells? Hi Lee, Am sick with the flu for the past few days, so I haven't done much more work here, but I'll just add some (not very useful) comments The get_page_from_freelist hang is quite strange. It would be zone->lock, which shouldn't have too much contention... Replication may be putting more stress on some locks. It will cause more tlb flushing that can not be batched well, which could cause the call_lock to get hotter. Then i_mmap_lock is held over tlb flushing, so it will inherit the latency from call_lock. (If this is the case, we could potentially extend the tlb flushing API slightly to cope better with unmapping of pages from multiple mm's, but that comes way down the track when/if replication proves itself!). tlb flushing AFAIKS should not do the IPI unless it is deadling with a multithreaded mm... does usex use threads? > I should note that I was trying to unmap all mappings to the file backed pages > on internode task migration, instead of just the current task's pte's. > However, > I was only attempting this on pages with mapcount <= 4. So, I don't think I > was looping trying to unmap pages with mapcounts of several 10s--such as I see > on some page cache pages in my traces. Replication teardown would still have to unmap all... but that shouldn't particularly be any worse than, say, page reclaim (except I guess that it could occur more often). > Today, after rebasing to 23-rc2-mm2, I added a patch to unmap only the current > task's ptes for ALL !anon pages, regardless of mapcount. I've started the > test > again and will let it run over the weekend--or as long as it stays up, which > ever is shorter :-). Ah, so it does eventually die? Any hints of why? > > I put a tarball with the rebased series in the Replication directory linked > above, in case you're interested. I haven't added the patch description for > the new patch yet, but it's pretty simple. Maybe even correct. > > > > Unrelated to the lockups [I think]: > > I forgot to look before I rebooted, but earlier the previous evening, I > checked > the vmstats and at that point [~1.5 hours into the test] we had done ~4.88 > million > replications and ~4.8 million "zaps" [collapse of
Re: [PATCH] sysdev: remove global sysdev drivers list
On Sun, 12 Aug 2007 13:44:07 +0900,
Akinobu Mita <[EMAIL PROTECTED]> wrote:
> No one uses sysdev_drivers. Because no one calls sysdev_driver_register
> with NULL class.
>
> And it is difficult to imagine that someone want to implement a global
> sysdev driver which is called with all sys_device on any kind of
> sysdev_class.
>
> So this patch removes global sysdev_drivers list.
This makes sense, I guess, especially since it simplyfies the code.
Some minor comments below.
> @@ -182,10 +179,12 @@ int sysdev_driver_register(struct sysdev
> list_for_each_entry(dev, >kset.list, kobj.entry)
> drv->add(dev);
> }
> - } else
> - list_add_tail(>entry, _drivers);
> + } else {
> + err = -EINVAL;
> + WARN_ON(1);
Maybe print what went wrong here?
> + }
> mutex_unlock(_drivers_lock);
> - return 0;
> + return err;
> }
>
>
> @@ -206,6 +205,8 @@ void sysdev_driver_unregister(struct sys
> drv->remove(dev);
> }
> kset_put(>kset);
> + } else {
> + WARN_ON(1);
This one is redundant, since you already warned on register.
> }
> mutex_unlock(_drivers_lock);
> }
> @@ -320,12 +310,6 @@ void sysdev_shutdown(void)
> struct sysdev_driver * drv;
> pr_debug(" %s\n", kobject_name(>kobj));
>
> - /* Call global drivers first. */
> - list_for_each_entry(drv, _drivers, entry) {
> - if (drv->shutdown)
> - drv->shutdown(sysdev);
> - }
> -
> /* Call auxillary drivers next. */
This comment has become meaningless.
> list_for_each_entry(drv, >drivers, entry) {
> if (drv->shutdown)
> @@ -393,15 +371,6 @@ int sysdev_suspend(pm_message_t state)
> list_for_each_entry(sysdev, >kset.list, kobj.entry) {
> pr_debug(" %s\n", kobject_name(>kobj));
>
> - /* Call global drivers first. */
> - list_for_each_entry(drv, _drivers, entry) {
> - if (drv->suspend) {
> - ret = drv->suspend(sysdev, state);
> - if (ret)
> - goto gbl_driver;
> - }
> - }
> -
> /* Call auxillary drivers next. */
Dito here.
> list_for_each_entry(drv, >drivers, entry) {
> if (drv->suspend) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] [95/2many] MAINTAINERS - BLOCK LAYER
On Mon, 2007-08-13 at 09:28 +0200, Jens Axboe wrote: > drivers/block/ is block device drivers, not the block layer. That mostly > resides in block/, with some parts in fs/ as well. ok, Do you want to be cc'd on mods in fs/* F: block/ F: fs/* ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUGFIX] NULL pointer dereference in __vm_enough_memory()
On Sun, Aug 12, 2007 at 04:17:44PM +0100, Alan Cox wrote: > Try this (it compiles but isnt tested). Its a weekend here, the sun is > shining, the beach is a short walk, and I have more interesting things to > do right now 8) Have a nice day~~~ It works! > --- linux.vanilla-2.6.23rc1-mm1/mm/mmap.c 2007-07-26 15:02:58.0 > +0100 > +++ linux-2.6.23rc1-mm1/mm/mmap.c 2007-08-12 13:53:22.0 +0100 > @@ -2058,7 +2058,7 @@ > if (__vma && __vma->vm_start < vma->vm_end) > return -ENOMEM; > if ((vma->vm_flags & VM_ACCOUNT) && > - security_vm_enough_memory(vma_pages(vma))) > + security_vm_enough_memory_mm(mm, vma_pages(vma))) > return -ENOMEM; > vma_link(mm, vma, prev, rb_link, rb_parent); > return 0; Sorry, I overlooked this chunk in int insert_vm_struct(mm, vma), hehe. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 9/24] make atomic_read() behave consistently on ia64
On Mon, 13 Aug 2007, Chris Snook wrote:
> Paul Mackerras wrote:
> > Chris Snook writes:
> > > I'll do this for the whole patchset. Stay tuned for the resubmit.
> >
> > Could you incorporate Segher's patch to turn atomic_{read,set} into
> > asm on powerpc? Segher claims that using asm is really the only
> > reliable way to ensure that gcc does what we want, and he seems to
> > have a point.
> >
> > Paul.
>
> I haven't seen a patch yet. I'm going to resubmit with inline volatile-cast
> atomic[64]_[read|set] on all architectures as a reference point, and if anyone
> wants to go and implement some of them in assembly, that's between them and
> the relevant arch maintainers. I have no problem with (someone else) doing it
> in assembly. I just don't think it's necessary and won't let it hold up the
> effort to get consistent behavior on all architectures.
http://lkml.org/lkml/2007/8/10/470
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/4] posix-timers: fix creation race
On Sun, 2007-08-12 at 23:44 +0400, Oleg Nesterov wrote:
> > > --- t/kernel/posix-timers.c~2_CREATE 2007-08-12 17:59:17.0
> > > +0400
> > > +++ t/kernel/posix-timers.c 2007-08-12 18:11:33.0 +0400
> > > @@ -547,13 +547,12 @@ sys_timer_create(const clockid_t which_c
> > > new_timer->it_process = process;
> > > list_add(_timer->list,
> > >>signal->posix_timers);
> > > -
> > > spin_unlock_irqrestore(>sighand->siglock, flags);
> > > if (new_timer->it_sigev_notify ==
> > > (SIGEV_SIGNAL|SIGEV_THREAD_ID))
> > > get_task_struct(process);
> > > } else {
> > > -
> > > spin_unlock_irqrestore(>sighand->siglock, flags);
> > > process = NULL;
> > > }
> > > + spin_unlock_irqrestore(>sighand->siglock,
> > > flags);
>
> i'll resend this patch tomorrow. We can't do
> spin_unlock_irqrestore(>...)
> if we set process = NULL above.
Doh, half of my brain seems to be still on vacation.
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] x86_64 EFI runtime service support: document for EFI runtime services
Changelog between v3 of EFI x86_64 support patch and this version 1. Change 64bit parameter description to 8 bytes in zero-page.txt 2. Add document for EFI related boot options. --- This patch adds document for EFI x86_64 runtime services support. The boot parameters added are documented in Documentation/i386/zero-page.txt. The boot options added are documented in Documentation/x86_64/boot-options.txt. --- i386/zero-page.txt | 21 - x86_64/boot-options.txt | 10 +- 2 files changed, 25 insertions(+), 6 deletions(-) Signed-off-by: Chandramouli Narayanan <[EMAIL PROTECTED]> Signed-off-by: Huang Ying <[EMAIL PROTECTED]> Index: linux-2.6.23-rc2/Documentation/i386/zero-page.txt === --- linux-2.6.23-rc2.orig/Documentation/i386/zero-page.txt 2007-08-13 13:08:39.0 +0800 +++ linux-2.6.23-rc2/Documentation/i386/zero-page.txt 2007-08-13 13:08:53.0 +0800 @@ -31,11 +31,11 @@ 0xb0 - 0x13f Free. Add more parameters here if you really need them. 0x140- 0x1be EDID_INFO Video mode setup -0x1c4 unsigned long EFI system table pointer -0x1c8 unsigned long EFI memory descriptor size -0x1cc unsigned long EFI memory descriptor version -0x1d0 unsigned long EFI memory descriptor map pointer -0x1d4 unsigned long EFI memory descriptor map size +0x1c4 unsigned long EFI system table pointer* +0x1c8 unsigned long EFI memory descriptor size* +0x1cc unsigned long EFI memory descriptor version* +0x1d0 unsigned long EFI memory descriptor map pointer* +0x1d4 unsigned long EFI memory descriptor map size* 0x1e0 unsigned long ALT_MEM_K, alternative mem check, in Kb 0x1e4 unsigned long Scratch field for the kernel setup code 0x1e8 charnumber of entries in E820MAP (below) @@ -87,3 +87,14 @@ 0x2d0 - 0xd00 E820MAP 0xd00 - 0xeff EDDBUF (edd.S) for disk signature read sector 0xd00 - 0xeeb EDDBUF (edd.S) for edd data + +Changes for x86_64 implementation: +- +For alignment purposes, the following parameters are rearranged. + +0x1c0 4 bytes EFI Loader signature, ="EFIL" +0x1c4 unsigned long EFI memory descriptor size +0x1c8 unsigned long EFI memory descriptor version +0x1cc unsigned long EFI memory descriptor map size +0x1d0 8 bytes EFI memory descriptor map pointer +0x1d8 8 bytes EFI system table pointer Index: linux-2.6.23-rc2/Documentation/x86_64/boot-options.txt === --- linux-2.6.23-rc2.orig/Documentation/x86_64/boot-options.txt 2007-08-13 13:08:39.0 +0800 +++ linux-2.6.23-rc2/Documentation/x86_64/boot-options.txt 2007-08-13 13:08:53.0 +0800 @@ -110,12 +110,13 @@ Rebooting - reboot=b[ios] | t[riple] | k[bd] [, [w]arm | [c]old] + reboot=b[ios] | t[riple] | k[bd] | e[fi] [, [w]arm | [c]old] bios Use the CPU reboot vector for warm reset warm Don't set the cold reboot flag cold Set the cold reboot flag triple Force a triple fault (init) kbdUse the keyboard controller. cold reset (default) + efi Use efi reset_system runtime service. cold reset (default) Using warm reset will be much faster especially on big memory systems because the BIOS will not go through the memory check. @@ -300,4 +301,11 @@ newfallback: use new unwinder but fall back to old if it gets stuck (default) +EFI + + noefiDisable EFI support + + noefi_time Disable EFI time runtime service, programming CMOS + hardware directly + Miscellaneous - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] x86_64 EFI runtime service support: EFI basic runtime service support
Changelog between v3 of EFI x86_64 support patch and this version: 1. Remove E820_RUNTIME_CODE, the EFI memory map is used to deal with EFI runtime code area. 2. The method used to make EFI runtime code area executable is change: a. Before page allocation is usable, the PMD of direct mapping is changed temporarily before and after each EFI call. b. After page allocation is usable, change_page_attr_addr is used to change corresponding page attribute. 3. Use fixmap to map EFI memory mapped IO memory area to make kexec workable. 4. Add a kernel command line option "noefi" to make it possible to turn off EFI runtime services support. Changelog between v2 and v3: 1. The EFI callwrapper is re-implemented in assembler. --- This patch adds basic runtime services support for EFI x86_64 system. The main file of the patch is the addition of efi.c for x86_64. This file is modeled after the EFI IA32 avatar. EFI runtime services initialization are implemented in efi.c. Some x86_64 specifics are worth noting here. On x86_64, parameters passed to UEFI firmware services need to follow the UEFI calling convention. For this purpose, a set of functions named lin2win ( is the number of parameters) are implemented. EFI function calls are wrapped before calling the firmware service. Signed-off-by: Chandramouli Narayanan <[EMAIL PROTECTED]> Signed-off-by: Huang Ying <[EMAIL PROTECTED]> --- arch/x86_64/Kconfig | 13 arch/x86_64/kernel/Makefile |1 arch/x86_64/kernel/efi.c | 581 ++ arch/x86_64/kernel/efi_callwrap.S | 69 arch/x86_64/kernel/setup.c| 15 include/asm-x86_64/bootsetup.h|6 include/asm-x86_64/eficallwrap.h | 33 ++ include/asm-x86_64/efidef.h |6 include/asm-x86_64/fixmap.h |3 9 files changed, 726 insertions(+), 1 deletion(-) Index: linux-2.6.23-rc2/include/asm-x86_64/eficallwrap.h === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6.23-rc2/include/asm-x86_64/eficallwrap.h 2007-08-13 13:08:50.0 +0800 @@ -0,0 +1,33 @@ +/* + * Copyright (C) 2007 Intel Corp + * Bibo Mao <[EMAIL PROTECTED]> + * Huang Ying <[EMAIL PROTECTED]> + * + * Function calling ABI conversion from SYSV to Windows for x86_64 + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#ifndef __ASM_X86_64_EFICALLWRAP_H +#define __ASM_X86_64_EFICALLWRAP_H + +extern efi_status_t lin2win0(void *fp); +extern efi_status_t lin2win1(void *fp, u64 arg1); +extern efi_status_t lin2win2(void *fp, u64 arg1, u64 arg2); +extern efi_status_t lin2win3(void *fp, u64 arg1, u64 arg2, u64 arg3); +extern efi_status_t lin2win4(void *fp, u64 arg1, u64 arg2, u64 arg3, u64 arg4); +extern efi_status_t lin2win5(void *fp, u64 arg1, u64 arg2, u64 arg3, +u64 arg4, u64 arg5); +extern efi_status_t lin2win6(void *fp, u64 arg1, u64 arg2, u64 arg3, +u64 arg4, u64 arg5, u64 arg6); + +#endif Index: linux-2.6.23-rc2/arch/x86_64/kernel/efi.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6.23-rc2/arch/x86_64/kernel/efi.c 2007-08-13 13:08:50.0 +0800 @@ -0,0 +1,581 @@ +/* + * Extensible Firmware Interface + * + * Based on Extensible Firmware Interface Specification version 1.0 + * + * Copyright (C) 1999 VA Linux Systems + * Copyright (C) 1999 Walt Drummond <[EMAIL PROTECTED]> + * Copyright (C) 1999-2002 Hewlett-Packard Co. + * David Mosberger-Tang <[EMAIL PROTECTED]> + * Stephane Eranian <[EMAIL PROTECTED]> + * Copyright (C) 2005-2008 Intel Co. + * Fenghua Yu <[EMAIL PROTECTED]> + * Bibo Mao <[EMAIL PROTECTED]> + * Chandramouli Narayanan <[EMAIL PROTECTED]> + * + * Code to convert EFI to E820 map has been implemented in elilo bootloader + * based on a EFI patch by Edgar Hucek. Based on the E820 map, the page table + * is setup appropriately for EFI runtime code. + * - mouli 06/14/2007. + * + * All EFI Runtime Services are not implemented yet as EFI only + * supports physical mode addressing on SoftSDV. This is to be fixed + * in a future version. --drummond 1999-07-20 + * + * Implemented EFI runtime services and virtual mode calls. --davidm + * + * Goutham Rao: <[EMAIL PROTECTED]> + * Skip non-WB memory and ignore empty memory ranges. + */ + +#include +#include +#include +#include
