* Re: linux-next: manual merge of the mfd tree with the ux500-core tree
From: Paul Mundt @ 2010-12-20 4:23 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Samuel Ortiz, linux-next, linux-kernel, Sundar Iyer, Mark Brown,
Linus Walleij
In-Reply-To: <20101220152148.6fedee0d.sfr@canb.auug.org.au>
On Mon, Dec 20, 2010 at 03:21:48PM +1100, Stephen Rothwell wrote:
> The genirq core is being converted to pass struct irq_data to irq_chip
> operations rather than an IRQ number. Update the tc35892 driver to the
> new APIs.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Acked-by: Rabin Vincent <rabin.vincent@stericsson.com>
> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Sorry to hijack the thread..
> diff --git a/drivers/mfd/tc3589x.c b/drivers/mfd/tc3589x.c
> index 32291fe..dde2d858 100644
> --- a/drivers/mfd/tc3589x.c
> +++ b/drivers/mfd/tc3589x.c
> @@ -170,15 +170,15 @@ again:
> return IRQ_HANDLED;
> }
>
> -static void tc3589x_irq_dummy(unsigned int irq)
> +static void tc3589x_irq_dummy(struct irq_data *data)
> {
> /* No mask/unmask at this level */
> }
>
> static struct irq_chip tc3589x_irq_chip = {
> - .name = "tc3589x",
> - .mask = tc3589x_irq_dummy,
> - .unmask = tc3589x_irq_dummy,
> + .name = "tc3589x",
> + .irq_mask = tc3589x_irq_dummy,
> + .irq_unmask = tc3589x_irq_dummy,
> };
>
> static int tc3589x_irq_init(struct tc3589x *tc3589x)
Is there some reason you don't just kill this off and use dummy_irq_chip?
^ permalink raw reply
* linux-next: build warnings after merge of the mfd tree
From: Stephen Rothwell @ 2010-12-20 4:25 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: linux-next, linux-kernel, Andres Salomon
[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]
Hi Samuel,
After merging the mfd tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:
drivers/gpio/cs5535-gpio.c: In function 'cs5535_gpio_probe':
drivers/gpio/cs5535-gpio.c:269: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'resource_size_t'
drivers/gpio/cs5535-gpio.c:269: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'resource_size_t'
drivers/misc/cs5535-mfgpt.c: In function 'cs5535_mfgpt_probe':
drivers/misc/cs5535-mfgpt.c:320: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'resource_size_t'
drivers/misc/cs5535-mfgpt.c:320: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'resource_size_t'
Introduced by commits d8fefd6ff3a8444ab34f6eb6c7c1961f0ca0008a ("gpio:
Convert cs5535 from pci device to platform device") and
6a85d28cfca9663c0db297a04ca43777dc5bcaa6 ("misc: Convert cs5535-mfgpt
from pci device to platform device"). We have %pR for printing
resources ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: manual merge of the mfd tree with the ux500-core tree
From: Stephen Rothwell @ 2010-12-20 4:21 UTC (permalink / raw)
To: Samuel Ortiz
Cc: linux-next, linux-kernel, Sundar Iyer, Mark Brown, Linus Walleij
Hi Samuel,
Today's linux-next merge of the mfd tree got a conflict in
drivers/mfd/tc35892.c between commit
f4e8afdc7ab1b5a0962be02a9dd15d29a81f4c53 ("mfd/tc35892: rename tc35892
core driver to tc3589x") from the ux500-core tree and commit
9716d7717db1eb7b407e67e576a8ca515836d0da ("mfd: Convert tc35892 to new
irq_ APIs") from the mfd tree.
The former renamed the file modified by the latter. I have applied the
patch from the mfd tree to the new file drivers/mfd/tc3589x.c (see below).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date: Sun, 12 Dec 2010 12:26:09 +0000
Subject: [PATCH] mfd: Convert tc35892 to new irq_ APIs
The genirq core is being converted to pass struct irq_data to irq_chip
operations rather than an IRQ number. Update the tc35892 driver to the
new APIs.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Rabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
---
drivers/mfd/tc3589x.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/tc3589x.c b/drivers/mfd/tc3589x.c
index 32291fe..dde2d858 100644
--- a/drivers/mfd/tc3589x.c
+++ b/drivers/mfd/tc3589x.c
@@ -170,15 +170,15 @@ again:
return IRQ_HANDLED;
}
-static void tc3589x_irq_dummy(unsigned int irq)
+static void tc3589x_irq_dummy(struct irq_data *data)
{
/* No mask/unmask at this level */
}
static struct irq_chip tc3589x_irq_chip = {
- .name = "tc3589x",
- .mask = tc3589x_irq_dummy,
- .unmask = tc3589x_irq_dummy,
+ .name = "tc3589x",
+ .irq_mask = tc3589x_irq_dummy,
+ .irq_unmask = tc3589x_irq_dummy,
};
static int tc3589x_irq_init(struct tc3589x *tc3589x)
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] fs/ext4/super.c: Use printf extension %pV
From: Ted Ts'o @ 2010-12-20 3:44 UTC (permalink / raw)
To: Joe Perches; +Cc: Andreas Dilger, linux-ext4, linux-kernel
In-Reply-To: <1289325676.1823.78.camel@Joe-Laptop>
On Tue, Nov 09, 2010 at 10:01:16AM -0800, Joe Perches wrote:
> Using %pV reduces the number of printk calls and
> eliminates any possible message interleaving from
> other printk calls.
>
> In function __ext4_grp_locked_error also added
> KERN_CONT to some printks.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Thanks, added to the ext4 tree.
- Ted
^ permalink raw reply
* Re: [RFC 5/5] truncate: Remove unnecessary page release
From: Minchan Kim @ 2010-12-20 3:31 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Andrew Morton, linux-mm, LKML, Nick Piggin, Al Viro, Andi Kleen
In-Reply-To: <20101220120218.E56F.A69D9226@jp.fujitsu.com>
On Mon, Dec 20, 2010 at 12:03 PM, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
>> On Mon, Dec 20, 2010 at 11:32 AM, KOSAKI Motohiro
>> <kosaki.motohiro@jp.fujitsu.com> wrote:
>> >> On Mon, Dec 20, 2010 at 11:21 AM, KOSAKI Motohiro
>> >> <kosaki.motohiro@jp.fujitsu.com> wrote:
>> >> >> This patch series changes remove_from_page_cache's page ref counting
>> >> >> rule. page cache ref count is decreased in remove_from_page_cache.
>> >> >> So we don't need call again in caller context.
>> >> >>
>> >> >> Cc: Nick Piggin <npiggin@suse.de>
>> >> >> Cc: Al Viro <viro@zeniv.linux.org.uk>
>> >> >> Cc: linux-mm@kvack.org
>> >> >> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
>> >> >> ---
>> >> >> mm/truncate.c | 1 -
>> >> >> 1 files changed, 0 insertions(+), 1 deletions(-)
>> >> >>
>> >> >> diff --git a/mm/truncate.c b/mm/truncate.c
>> >> >> index 9ee5673..8decb93 100644
>> >> >> --- a/mm/truncate.c
>> >> >> +++ b/mm/truncate.c
>> >> >> @@ -114,7 +114,6 @@ truncate_complete_page(struct address_space *mapping, struct page *page)
>> >> >> * calls cleancache_put_page (and note page->mapping is now NULL)
>> >> >> */
>> >> >> cleancache_flush_page(mapping, page);
>> >> >> - page_cache_release(page); /* pagecache ref */
>> >> >> return 0;
>> >> >
>> >> > Do we _always_ have stable page reference here? IOW, I can assume
>> >>
>> >> I think so.
>> >> Because the page is locked so caller have to hold a ref to unlock it.
>> >
>> > Hmm...
>> >
>> > Perhaps, I'm missing something. But I think __memory_failure() only lock
>> > compaund_head page. not all. example.
>>
>> The page passed truncate_complete_page is only head page?
>> Is it possible to pass the page which isn't head of compound in
>> truncate_complete_page?
>
> I dunno, really. My five miniture grep found following logic. therefore I asked you.
>
>
>
> __memory_failure()
> {
> p = pfn_to_page(pfn);
> hpage = compound_head(p);
> (snip)
> res = -EBUSY;
> for (ps = error_states;; ps++) {
> if ((p->flags & ps->mask) == ps->res) {
> res = page_action(ps, p, pfn); // call truncate here
> break;
> }
> }
> out:
> unlock_page(hpage);
> }
>
>
AFAIK, We have to handle head page when we handle compound page.
Internal page handling logic about tail pages is hidden by compound
page internal.
So I think memory_failure also don't have a problem.
For needing double check, Cced Andi.
Thanks for the review, KOSAKI.
--
Kind regards,
Minchan Kim
^ permalink raw reply
* Re: [PATCH V2 37/49] fs/ext4: Use vzalloc
From: Ted Ts'o @ 2010-12-20 3:22 UTC (permalink / raw)
To: Joe Perches; +Cc: Andreas Dilger, Jiri Kosina, Ext4 Developers List, LKML
In-Reply-To: <1288941511.18440.63.camel@Joe-Laptop>
On Fri, Nov 05, 2010 at 12:18:31AM -0700, Joe Perches wrote:
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> differences from V1:
> Andreas Dilger requested a block be moved so that
> sbi->s_flex_groups isn't tested for NULL twice.
> Also coalesced a ext4_msg printk format.
Thanks, applied to the ext4 tree
- Ted
^ permalink raw reply
* Re: [RFC 5/5] truncate: Remove unnecessary page release
From: KOSAKI Motohiro @ 2010-12-20 3:03 UTC (permalink / raw)
To: Minchan Kim
Cc: kosaki.motohiro, Andrew Morton, linux-mm, LKML, Nick Piggin,
Al Viro
In-Reply-To: <AANLkTikOu6xUs3e_gEubidwSc_kQVuTKask+1WcCjzFs@mail.gmail.com>
> On Mon, Dec 20, 2010 at 11:32 AM, KOSAKI Motohiro
> <kosaki.motohiro@jp.fujitsu.com> wrote:
> >> On Mon, Dec 20, 2010 at 11:21 AM, KOSAKI Motohiro
> >> <kosaki.motohiro@jp.fujitsu.com> wrote:
> >> >> This patch series changes remove_from_page_cache's page ref counting
> >> >> rule. page cache ref count is decreased in remove_from_page_cache.
> >> >> So we don't need call again in caller context.
> >> >>
> >> >> Cc: Nick Piggin <npiggin@suse.de>
> >> >> Cc: Al Viro <viro@zeniv.linux.org.uk>
> >> >> Cc: linux-mm@kvack.org
> >> >> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
> >> >> ---
> >> >> mm/truncate.c | 1 -
> >> >> 1 files changed, 0 insertions(+), 1 deletions(-)
> >> >>
> >> >> diff --git a/mm/truncate.c b/mm/truncate.c
> >> >> index 9ee5673..8decb93 100644
> >> >> --- a/mm/truncate.c
> >> >> +++ b/mm/truncate.c
> >> >> @@ -114,7 +114,6 @@ truncate_complete_page(struct address_space *mapping, struct page *page)
> >> >> * calls cleancache_put_page (and note page->mapping is now NULL)
> >> >> */
> >> >> cleancache_flush_page(mapping, page);
> >> >> - page_cache_release(page); /* pagecache ref */
> >> >> return 0;
> >> >
> >> > Do we _always_ have stable page reference here? IOW, I can assume
> >>
> >> I think so.
> >> Because the page is locked so caller have to hold a ref to unlock it.
> >
> > Hmm...
> >
> > Perhaps, I'm missing something. But I think __memory_failure() only lock
> > compaund_head page. not all. example.
>
> The page passed truncate_complete_page is only head page?
> Is it possible to pass the page which isn't head of compound in
> truncate_complete_page?
I dunno, really. My five miniture grep found following logic. therefore I asked you.
__memory_failure()
{
p = pfn_to_page(pfn);
hpage = compound_head(p);
(snip)
res = -EBUSY;
for (ps = error_states;; ps++) {
if ((p->flags & ps->mask) == ps->res) {
res = page_action(ps, p, pfn); // call truncate here
break;
}
}
out:
unlock_page(hpage);
}
^ permalink raw reply
* Re: [RFC 5/5] truncate: Remove unnecessary page release
From: Minchan Kim @ 2010-12-20 2:58 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: KOSAKI Motohiro, Andrew Morton, linux-mm, LKML, Nick Piggin,
Al Viro
In-Reply-To: <20101220112733.064f2fe3.kamezawa.hiroyu@jp.fujitsu.com>
On Mon, Dec 20, 2010 at 11:27 AM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Mon, 20 Dec 2010 11:21:52 +0900 (JST)
> KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
>
>> > This patch series changes remove_from_page_cache's page ref counting
>> > rule. page cache ref count is decreased in remove_from_page_cache.
>> > So we don't need call again in caller context.
>> >
>> > Cc: Nick Piggin <npiggin@suse.de>
>> > Cc: Al Viro <viro@zeniv.linux.org.uk>
>> > Cc: linux-mm@kvack.org
>> > Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
>> > ---
>> > mm/truncate.c | 1 -
>> > 1 files changed, 0 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/mm/truncate.c b/mm/truncate.c
>> > index 9ee5673..8decb93 100644
>> > --- a/mm/truncate.c
>> > +++ b/mm/truncate.c
>> > @@ -114,7 +114,6 @@ truncate_complete_page(struct address_space *mapping, struct page *page)
>> > * calls cleancache_put_page (and note page->mapping is now NULL)
>> > */
>> > cleancache_flush_page(mapping, page);
>> > - page_cache_release(page); /* pagecache ref */
>> > return 0;
>>
>> Do we _always_ have stable page reference here? IOW, I can assume
>> cleancache_flush_page() doesn't cause NULL deref?
>>
> Hmm, my review was bad.
>
> I think cleancache_flush_page() here should eat (mapping, index) as argument
> rather than "page".
>
> BTW, I can't understand
> ==
> void __cleancache_flush_page(struct address_space *mapping, struct page *page)
> {
> /* careful... page->mapping is NULL sometimes when this is called */
> int pool_id = mapping->host->i_sb->cleancache_poolid;
> struct cleancache_filekey key = { .u.key = { 0 } };
> ==
>
> Why above is safe...
> I think (mapping,index) should be passed instead of page.
I don't think current code isn't safe.
void __cleancache_flush_page(struct address_space *mapping, struct page *page)
{
/* careful... page->mapping is NULL sometimes when this is called */
int pool_id = mapping->host->i_sb->cleancache_poolid;
struct cleancache_filekey key = { .u.key = { 0 } };
if (pool_id >= 0) {
VM_BUG_ON(!PageLocked(page));
it does check PageLocked. So caller should hold a page reference to
prevent freeing ramined PG_locked
If the caller doesn't hold a ref of page, I think it's BUG of caller.
In our case, caller calls truncate_complete_page have to make sure it, I think.
>
>
> -Kame
>
>
--
Kind regards,
Minchan Kim
^ permalink raw reply
* Re: [PATCH][RESEND] scripts: add no-warning option to the checkpatch script
From: Joe Perches @ 2010-12-20 2:52 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Linux Kernel, apw
In-Reply-To: <4D0DD027.4000507@gmail.com>
On Sun, 2010-12-19 at 10:28 +0100, Marco Stornelli wrote:
> From: Marco Stornelli <marco.stornelli@gmail.com>
> Add no-warning option to the checkpatch script.
> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
Hello Marco.
I don't have much of an opinion on this.
I don't actually use checkpatch much.
Why do you think it's useful?
It's Andy's code, I just contribute a few
possible additions here and there.
cheers, Joe
^ permalink raw reply
* Re: [RFC 5/5] truncate: Remove unnecessary page release
From: Minchan Kim @ 2010-12-20 2:49 UTC (permalink / raw)
To: KOSAKI Motohiro; +Cc: Andrew Morton, linux-mm, LKML, Nick Piggin, Al Viro
In-Reply-To: <20101220113239.E56C.A69D9226@jp.fujitsu.com>
On Mon, Dec 20, 2010 at 11:32 AM, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
>> On Mon, Dec 20, 2010 at 11:21 AM, KOSAKI Motohiro
>> <kosaki.motohiro@jp.fujitsu.com> wrote:
>> >> This patch series changes remove_from_page_cache's page ref counting
>> >> rule. page cache ref count is decreased in remove_from_page_cache.
>> >> So we don't need call again in caller context.
>> >>
>> >> Cc: Nick Piggin <npiggin@suse.de>
>> >> Cc: Al Viro <viro@zeniv.linux.org.uk>
>> >> Cc: linux-mm@kvack.org
>> >> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
>> >> ---
>> >> mm/truncate.c | 1 -
>> >> 1 files changed, 0 insertions(+), 1 deletions(-)
>> >>
>> >> diff --git a/mm/truncate.c b/mm/truncate.c
>> >> index 9ee5673..8decb93 100644
>> >> --- a/mm/truncate.c
>> >> +++ b/mm/truncate.c
>> >> @@ -114,7 +114,6 @@ truncate_complete_page(struct address_space *mapping, struct page *page)
>> >> * calls cleancache_put_page (and note page->mapping is now NULL)
>> >> */
>> >> cleancache_flush_page(mapping, page);
>> >> - page_cache_release(page); /* pagecache ref */
>> >> return 0;
>> >
>> > Do we _always_ have stable page reference here? IOW, I can assume
>>
>> I think so.
>> Because the page is locked so caller have to hold a ref to unlock it.
>
> Hmm...
>
> Perhaps, I'm missing something. But I think __memory_failure() only lock
> compaund_head page. not all. example.
The page passed truncate_complete_page is only head page?
Is it possible to pass the page which isn't head of compound in
truncate_complete_page?
>
>>
>> > cleancache_flush_page() doesn't cause NULL deref?
>
>
>
>
--
Kind regards,
Minchan Kim
^ permalink raw reply
* Re: [concept & "good taste" review] persistent store
From: Huang Ying @ 2010-12-20 2:47 UTC (permalink / raw)
To: Tony Luck
Cc: Borislav Petkov, Tony Luck, Linus Torvalds, H. Peter Anvin,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
tglx@linutronix.de, mingo@elte.hu, greg@kroah.com,
akpm@linux-foundation.org, David Miller, Alan Cox, Jim Keniston,
Kyungmin Park, Geert Uytterhoeven
In-Reply-To: <AANLkTi=9UZ5BYWo5xT=jh0upRP6PraH4S=t=tL49YRdr@mail.gmail.com>
On Mon, 2010-12-20 at 04:17 +0800, Tony Luck wrote:
> On Sun, Dec 19, 2010 at 1:17 AM, Borislav Petkov <bp@alien8.de> wrote:
> > Before we go and delve into priority-sorting the oopses in the pstore,
> > let me ask this: how big an actual persistent storage device are we
> > talking?
>
> I'm not sure how big the store is on my system ... the ACPI/ERST
> interface on this machine limits each entry to just under 8KB. But
> that isn't inherent to to ERST, both larger and smaller values would
> be an option. 8K seems quite useful for kmsg_dump purposes as
> it grabs a significant number of lines leading up to the oops/panic.
8KB is about 100-200 lines message, sometimes it may be not enough for
all necessary information. But in fact, we can use multiple ERST
records to save one kernel message dumping. So the real limitation is
just total storage capacity.
For journal (or transaction) semantics, I think the overall picture of
system can be as follow,
kernel ---> persistent storage ---> user space daemon ---> disk
1. kernel dump OOPS and PANIC message into persistent storage.
2. user space daemon poll persistent storage and erase the record after
saving it into disk.
So,
- for OOPS messages will not cause system panic, it will go to disk and
will not use up the persistent storage.
- for PANIC message, it will be saved into persistent storage only and
read out/saved to disk/erased after successfully rebooting. (Maybe need
the heuristic to overwrite the latest OOPS if storage is really tight).
The issues are:
- We need a user space daemon, via extending /sbin/syslogd?
- It is a little hard to implement "poll" support for a file system.
Best Regards,
Huang Ying
^ permalink raw reply
* Re: ext4: Take advantage of kmem_cache_zalloc() in ext4_init_io_end()
From: Ted Ts'o @ 2010-12-20 2:44 UTC (permalink / raw)
To: Jesper Juhl; +Cc: linux-ext4, linux-kernel, Andreas Dilger
In-Reply-To: <alpine.LNX.2.00.1012092257290.25880@swampdragon.chaosbits.net>
On Thu, Dec 09, 2010 at 12:17:34PM -0000, Jesper Juhl wrote:
> Take advantage of kmem_cache_zalloc(). Save a memset() call in
> ext4_init_io_end() and save a few bytes.
>
> Before:
> [jj@dragon linux-2.6]$ size fs/ext4/page-io.o
> text data bss dec hex filename
> 3016 0 624 3640 e38 fs/ext4/page-io.o
> After:
> [jj@dragon linux-2.6]$ size fs/ext4/page-io.o
> text data bss dec hex filename
> 3000 0 624 3624 e28 fs/ext4/page-io.o
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Thanks, added to the ext4 patch queue.
- Ted
^ permalink raw reply
* Re: [RFC 5/5] truncate: Remove unnecessary page release
From: KAMEZAWA Hiroyuki @ 2010-12-20 2:27 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Minchan Kim, Andrew Morton, linux-mm, LKML, Nick Piggin, Al Viro
In-Reply-To: <20101220112227.E566.A69D9226@jp.fujitsu.com>
On Mon, 20 Dec 2010 11:21:52 +0900 (JST)
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> > This patch series changes remove_from_page_cache's page ref counting
> > rule. page cache ref count is decreased in remove_from_page_cache.
> > So we don't need call again in caller context.
> >
> > Cc: Nick Piggin <npiggin@suse.de>
> > Cc: Al Viro <viro@zeniv.linux.org.uk>
> > Cc: linux-mm@kvack.org
> > Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
> > ---
> > mm/truncate.c | 1 -
> > 1 files changed, 0 insertions(+), 1 deletions(-)
> >
> > diff --git a/mm/truncate.c b/mm/truncate.c
> > index 9ee5673..8decb93 100644
> > --- a/mm/truncate.c
> > +++ b/mm/truncate.c
> > @@ -114,7 +114,6 @@ truncate_complete_page(struct address_space *mapping, struct page *page)
> > * calls cleancache_put_page (and note page->mapping is now NULL)
> > */
> > cleancache_flush_page(mapping, page);
> > - page_cache_release(page); /* pagecache ref */
> > return 0;
>
> Do we _always_ have stable page reference here? IOW, I can assume
> cleancache_flush_page() doesn't cause NULL deref?
>
Hmm, my review was bad.
I think cleancache_flush_page() here should eat (mapping, index) as argument
rather than "page".
BTW, I can't understand
==
void __cleancache_flush_page(struct address_space *mapping, struct page *page)
{
/* careful... page->mapping is NULL sometimes when this is called */
int pool_id = mapping->host->i_sb->cleancache_poolid;
struct cleancache_filekey key = { .u.key = { 0 } };
==
Why above is safe...
I think (mapping,index) should be passed instead of page.
-Kame
^ permalink raw reply
* Re: [RFC 5/5] truncate: Remove unnecessary page release
From: KOSAKI Motohiro @ 2010-12-20 2:32 UTC (permalink / raw)
To: Minchan Kim
Cc: kosaki.motohiro, Andrew Morton, linux-mm, LKML, Nick Piggin,
Al Viro
In-Reply-To: <AANLkTimaW7X6w2e=4SvynHQHO-Kv3wXGv4_NCKDsuYRR@mail.gmail.com>
> On Mon, Dec 20, 2010 at 11:21 AM, KOSAKI Motohiro
> <kosaki.motohiro@jp.fujitsu.com> wrote:
> >> This patch series changes remove_from_page_cache's page ref counting
> >> rule. page cache ref count is decreased in remove_from_page_cache.
> >> So we don't need call again in caller context.
> >>
> >> Cc: Nick Piggin <npiggin@suse.de>
> >> Cc: Al Viro <viro@zeniv.linux.org.uk>
> >> Cc: linux-mm@kvack.org
> >> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
> >> ---
> >> mm/truncate.c | 1 -
> >> 1 files changed, 0 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/mm/truncate.c b/mm/truncate.c
> >> index 9ee5673..8decb93 100644
> >> --- a/mm/truncate.c
> >> +++ b/mm/truncate.c
> >> @@ -114,7 +114,6 @@ truncate_complete_page(struct address_space *mapping, struct page *page)
> >> * calls cleancache_put_page (and note page->mapping is now NULL)
> >> */
> >> cleancache_flush_page(mapping, page);
> >> - page_cache_release(page); /* pagecache ref */
> >> return 0;
> >
> > Do we _always_ have stable page reference here? IOW, I can assume
>
> I think so.
> Because the page is locked so caller have to hold a ref to unlock it.
Hmm...
Perhaps, I'm missing something. But I think __memory_failure() only lock
compaund_head page. not all. example.
>
> > cleancache_flush_page() doesn't cause NULL deref?
^ permalink raw reply
* Re: [RFC 5/5] truncate: Remove unnecessary page release
From: Minchan Kim @ 2010-12-20 2:27 UTC (permalink / raw)
To: KOSAKI Motohiro; +Cc: Andrew Morton, linux-mm, LKML, Nick Piggin, Al Viro
In-Reply-To: <20101220112227.E566.A69D9226@jp.fujitsu.com>
On Mon, Dec 20, 2010 at 11:21 AM, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
>> This patch series changes remove_from_page_cache's page ref counting
>> rule. page cache ref count is decreased in remove_from_page_cache.
>> So we don't need call again in caller context.
>>
>> Cc: Nick Piggin <npiggin@suse.de>
>> Cc: Al Viro <viro@zeniv.linux.org.uk>
>> Cc: linux-mm@kvack.org
>> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
>> ---
>> mm/truncate.c | 1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/mm/truncate.c b/mm/truncate.c
>> index 9ee5673..8decb93 100644
>> --- a/mm/truncate.c
>> +++ b/mm/truncate.c
>> @@ -114,7 +114,6 @@ truncate_complete_page(struct address_space *mapping, struct page *page)
>> * calls cleancache_put_page (and note page->mapping is now NULL)
>> */
>> cleancache_flush_page(mapping, page);
>> - page_cache_release(page); /* pagecache ref */
>> return 0;
>
> Do we _always_ have stable page reference here? IOW, I can assume
I think so.
Because the page is locked so caller have to hold a ref to unlock it.
> cleancache_flush_page() doesn't cause NULL deref?
>
>
>
>
--
Kind regards,
Minchan Kim
^ permalink raw reply
* Re: [RFC 5/5] truncate: Remove unnecessary page release
From: KOSAKI Motohiro @ 2010-12-20 2:21 UTC (permalink / raw)
To: Minchan Kim
Cc: kosaki.motohiro, Andrew Morton, linux-mm, LKML, Nick Piggin,
Al Viro
In-Reply-To: <02ab98b3a1450f7a1c31edc48ccc57e887cee900.1292604746.git.minchan.kim@gmail.com>
> This patch series changes remove_from_page_cache's page ref counting
> rule. page cache ref count is decreased in remove_from_page_cache.
> So we don't need call again in caller context.
>
> Cc: Nick Piggin <npiggin@suse.de>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Cc: linux-mm@kvack.org
> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
> ---
> mm/truncate.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/mm/truncate.c b/mm/truncate.c
> index 9ee5673..8decb93 100644
> --- a/mm/truncate.c
> +++ b/mm/truncate.c
> @@ -114,7 +114,6 @@ truncate_complete_page(struct address_space *mapping, struct page *page)
> * calls cleancache_put_page (and note page->mapping is now NULL)
> */
> cleancache_flush_page(mapping, page);
> - page_cache_release(page); /* pagecache ref */
> return 0;
Do we _always_ have stable page reference here? IOW, I can assume
cleancache_flush_page() doesn't cause NULL deref?
^ permalink raw reply
* Re: [PATCH RFC tip/core/rcu 15/20] rcu: Keep gpnum and completed fields synchronized
From: Frederic Weisbecker @ 2010-12-20 2:14 UTC (permalink / raw)
To: Lai Jiangshan
Cc: Paul E. McKenney, linux-kernel, mingo, dipankar, akpm,
mathieu.desnoyers, josh, niv, tglx, peterz, rostedt,
Valdis.Kletnieks, dhowells, eric.dumazet, darren, Peter Zijlstra
In-Reply-To: <4D0EBBCF.2070305@cn.fujitsu.com>
On Mon, Dec 20, 2010 at 10:13:35AM +0800, Lai Jiangshan wrote:
> On 12/18/2010 04:54 AM, Paul E. McKenney wrote:
> > From: Frederic Weisbecker <fweisbec@gmail.com>
> >
> > When a CPU that was in an extended quiescent state wakes
> > up and catches up with grace periods that remote CPUs
> > completed on its behalf, we update the completed field
> > but not the gpnum that keeps a stale value of a backward
> > grace period ID.
> >
> > Later, note_new_gpnum() will interpret the shift between
> > the local CPU and the node grace period ID as some new grace
> > period to handle and will then start to hunt quiescent state.
> >
> > But if every grace periods have already been completed, this
> > interpretation becomes broken. And we'll be stuck in clusters
> > of spurious softirqs because rcu_report_qs_rdp() will make
> > this broken state run into infinite loop.
> >
> > The solution, as suggested by Lai Jiangshan, is to ensure that
> > the gpnum and completed fields are well synchronized when we catch
> > up with completed grace periods on their behalf by other cpus.
> > This way we won't start noting spurious new grace periods.
> >
> > Suggested-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> > Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Cc: Ingo Molnar <mingo@elte.hu>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Cc: Steven Rostedt <rostedt@goodmis.org
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > ---
> > kernel/rcutree.c | 9 +++++++++
> > 1 files changed, 9 insertions(+), 0 deletions(-)
> >
> > diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> > index 916f42b..8105271 100644
> > --- a/kernel/rcutree.c
> > +++ b/kernel/rcutree.c
> > @@ -680,6 +680,15 @@ __rcu_process_gp_end(struct rcu_state *rsp, struct rcu_node *rnp, struct rcu_dat
> > rdp->completed = rnp->completed;
> >
> > /*
> > + * If we were in an extended quiescent state, we may have
> > + * missed some grace periods that others CPUs took care on
> > + * our behalf. Catch up with this state to avoid noting
> > + * spurious new grace periods.
> > + */
> > + if (rdp->completed > rdp->gpnum)
> > + rdp->gpnum = rdp->completed;
>
> Need to use ULONG_CMP_LT(rdp->gpnum, rdp->completed) instead.
Paul fixed that in:
[PATCH RFC tip/core/rcu 16/20] rcu: fine-tune grace-period begin/end checks
^ permalink raw reply
* Re: [PATCH RFC tip/core/rcu 15/20] rcu: Keep gpnum and completed fields synchronized
From: Lai Jiangshan @ 2010-12-20 2:13 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, mingo, dipankar, akpm, mathieu.desnoyers, josh, niv,
tglx, peterz, rostedt, Valdis.Kletnieks, dhowells, eric.dumazet,
darren, Frederic Weisbecker, Peter Zijlstra
In-Reply-To: <1292619291-2468-15-git-send-email-paulmck@linux.vnet.ibm.com>
On 12/18/2010 04:54 AM, Paul E. McKenney wrote:
> From: Frederic Weisbecker <fweisbec@gmail.com>
>
> When a CPU that was in an extended quiescent state wakes
> up and catches up with grace periods that remote CPUs
> completed on its behalf, we update the completed field
> but not the gpnum that keeps a stale value of a backward
> grace period ID.
>
> Later, note_new_gpnum() will interpret the shift between
> the local CPU and the node grace period ID as some new grace
> period to handle and will then start to hunt quiescent state.
>
> But if every grace periods have already been completed, this
> interpretation becomes broken. And we'll be stuck in clusters
> of spurious softirqs because rcu_report_qs_rdp() will make
> this broken state run into infinite loop.
>
> The solution, as suggested by Lai Jiangshan, is to ensure that
> the gpnum and completed fields are well synchronized when we catch
> up with completed grace periods on their behalf by other cpus.
> This way we won't start noting spurious new grace periods.
>
> Suggested-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Steven Rostedt <rostedt@goodmis.org
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
> kernel/rcutree.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> index 916f42b..8105271 100644
> --- a/kernel/rcutree.c
> +++ b/kernel/rcutree.c
> @@ -680,6 +680,15 @@ __rcu_process_gp_end(struct rcu_state *rsp, struct rcu_node *rnp, struct rcu_dat
> rdp->completed = rnp->completed;
>
> /*
> + * If we were in an extended quiescent state, we may have
> + * missed some grace periods that others CPUs took care on
> + * our behalf. Catch up with this state to avoid noting
> + * spurious new grace periods.
> + */
> + if (rdp->completed > rdp->gpnum)
> + rdp->gpnum = rdp->completed;
Need to use ULONG_CMP_LT(rdp->gpnum, rdp->completed) instead.
> +
> + /*
> * If another CPU handled our extended quiescent states and
> * we have no more grace period to complete yet, then stop
> * chasing quiescent states.
^ permalink raw reply
* linux-next: manual merge of the pci tree with Linus' tree
From: Stephen Rothwell @ 2010-12-20 2:08 UTC (permalink / raw)
To: Jesse Barnes; +Cc: linux-next, linux-kernel, Bjorn Helgaas
[-- Attachment #1: Type: text/plain, Size: 425 bytes --]
Hi Jesse,
Today's linux-next merge of the pci tree got a conflicts in
arch/x86/kernel/resource.c arch/x86/pci/i386.c kernel/resource.c between
various commits from Linus' tree and similar commits from the pci tree.
I just used the versions from Linus' tree and assume that the pci tree
needs to be resynced.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 01/12] libiscsi: Convert to host_lock less w/ interrupts disabled internally
From: Matthew Wilcox @ 2010-12-20 2:07 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: linux-scsi, linux-kernel, James Bottomley, Jeff Garzik,
Christoph Hellwig, FUJITA Tomonori, Hannes Reinecke,
Mike Christie
In-Reply-To: <1292808126.20840.33.camel@haakon2.linux-iscsi.org>
On Sun, Dec 19, 2010 at 05:22:06PM -0800, Nicholas A. Bellinger wrote:
> Actually sorry, Mike Christie did already make a clarification on this
> subject here:
>
> http://marc.info/?l=linux-scsi&m=129010439421506&w=2
>
> I had originally thought the same that session->lock should be using
> some flavour of spin_lock_irq*() as well, but apparently this is not the
> case for libiscsi.
Right, so it seems. "the session lock is just locked in softirqs/timers"
means that it does need to be the _bh() version of spin_lock though.
I'm actually not sure ... is it safe to use the _bh versions in BH
context? I think it is because the preempt count is nested, unlike the
_irq variants of spinlocks.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* Re: [PATCH] toshiba_acpi: FULL TOS1900 device support
From: Azael Avalos @ 2010-12-20 2:03 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: platform-driver-x86, linux-kernel, Matthew Garrett
In-Reply-To: <20101215081046.GB11920@core.coreip.homeip.net>
Hi Dmitry,
Sorry for the late reply.
I'll resend the patch with the changes you suggested, however,
I'll change the description since this patch does not add _FULL_
support to TOS1900 devices.
I recently got a new laptop (Qosmio X505-Q898), which turns out
it had a TOS1900 device as well, however, none of the known
methods activate hotkeys on this model.
Searching in the DSDT, I found a WMI interface, so if someone
is interested in having a look on the DSDT let me know so I
can attach the file.
Saludos
Azael
--
-- El mundo apesta y vosotros apestais tambien --
^ permalink raw reply
* [PATCH RESEND] mfd: Add __devexit annotation for vx855_remove
From: Axel Lin @ 2010-12-20 2:02 UTC (permalink / raw)
To: linux-kernel; +Cc: Harald Welte, Samuel Ortiz
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Harald Welte <HaraldWelte@viatech.com>
---
hi Samuel,
Looks like this patch is missing.
It was posted at http://kerneltrap.org/mailarchive/linux-kernel/2010/10/25/4636759
with Harald's ack.
Axel
drivers/mfd/vx855.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/vx855.c b/drivers/mfd/vx855.c
index ebb0597..348052a 100644
--- a/drivers/mfd/vx855.c
+++ b/drivers/mfd/vx855.c
@@ -112,7 +112,7 @@ out:
return ret;
}
-static void vx855_remove(struct pci_dev *pdev)
+static void __devexit vx855_remove(struct pci_dev *pdev)
{
mfd_remove_devices(&pdev->dev);
pci_disable_device(pdev);
--
1.7.2
^ permalink raw reply related
* Re: [RFC 5/5] truncate: Remove unnecessary page release
From: KAMEZAWA Hiroyuki @ 2010-12-20 1:55 UTC (permalink / raw)
To: Minchan Kim; +Cc: Andrew Morton, linux-mm, LKML, Nick Piggin, Al Viro
In-Reply-To: <02ab98b3a1450f7a1c31edc48ccc57e887cee900.1292604746.git.minchan.kim@gmail.com>
On Sat, 18 Dec 2010 02:13:40 +0900
Minchan Kim <minchan.kim@gmail.com> wrote:
> This patch series changes remove_from_page_cache's page ref counting
> rule. page cache ref count is decreased in remove_from_page_cache.
> So we don't need call again in caller context.
>
> Cc: Nick Piggin <npiggin@suse.de>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Cc: linux-mm@kvack.org
> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
^ permalink raw reply
* Re: [RFC 4/5] swap: Remove unnecessary page release
From: KAMEZAWA Hiroyuki @ 2010-12-20 1:55 UTC (permalink / raw)
To: Minchan Kim; +Cc: Andrew Morton, linux-mm, LKML
In-Reply-To: <7b8f65cb0e08556bdb48c459cb1f72500f6aa61d.1292604746.git.minchan.kim@gmail.com>
On Sat, 18 Dec 2010 02:13:39 +0900
Minchan Kim <minchan.kim@gmail.com> wrote:
> This patch series changes remove_from_page_cache's page ref counting
> rule. page cache ref count is decreased in remove_from_page_cache.
> So we don't need call again in caller context.
>
> Cc:Hugh Dickins <hughd@google.com>
> Cc: linux-mm@kvack.org
> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
^ permalink raw reply
* Re: [RFC 3/5] tlbfs: Remove unnecessary page release
From: KAMEZAWA Hiroyuki @ 2010-12-20 1:54 UTC (permalink / raw)
To: Minchan Kim; +Cc: Andrew Morton, linux-mm, LKML, William Irwin
In-Reply-To: <08549e97645f7d6c2bcc5c760a24fde56dfed513.1292604745.git.minchan.kim@gmail.com>
On Sat, 18 Dec 2010 02:13:38 +0900
Minchan Kim <minchan.kim@gmail.com> wrote:
> This patch series changes remove_from_page_cache's page ref counting
> rule. page cache ref count is decreased in remove_from_page_cache.
> So we don't need call again in caller context.
>
> Cc: William Irwin <wli@holomorphy.com>
> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox