All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Clear dirty bits etc on compound frees
@ 2003-11-26 20:13 Martin J. Bligh
  2003-11-26 20:20 ` Andrew Morton
  2003-12-01 19:40 ` Martin J. Bligh
  0 siblings, 2 replies; 5+ messages in thread
From: Martin J. Bligh @ 2003-11-26 20:13 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-mm mailing list, Guillaume Morin

Guillaume noticed this on s390 whilst writing a driver that used
compound pages. Seems correct to me, I've tested it on i386 as
well. The patch just makes us call free_pages_check for each element
of a compound page.

diff -purN -X /home/mbligh/.diff.exclude virgin/mm/page_alloc.c clear_dirty/mm/page_alloc.c
--- virgin/mm/page_alloc.c	2003-10-14 15:50:36.000000000 -0700
+++ clear_dirty/mm/page_alloc.c	2003-11-26 10:36:04.000000000 -0800
@@ -267,8 +267,11 @@ free_pages_bulk(struct zone *zone, int c
 void __free_pages_ok(struct page *page, unsigned int order)
 {
 	LIST_HEAD(list);
+	int i;
 
 	mod_page_state(pgfree, 1 << order);
+	for (i = 0 ; i < (1 << order) ; ++i)
+		free_pages_check(__FUNCTION__, page + i);
 	free_pages_check(__FUNCTION__, page);
 	list_add(&page->list, &list);
 	kernel_map_pages(page, 1<<order, 0);



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Clear dirty bits etc on compound frees
  2003-11-26 20:13 [PATCH] Clear dirty bits etc on compound frees Martin J. Bligh
@ 2003-11-26 20:20 ` Andrew Morton
  2003-12-01  3:02   ` Guillaume Morin
  2003-12-01 19:40 ` Martin J. Bligh
  1 sibling, 1 reply; 5+ messages in thread
From: Andrew Morton @ 2003-11-26 20:20 UTC (permalink / raw)
  To: Martin J. Bligh; +Cc: linux-mm, guillaume

"Martin J. Bligh" <mbligh@aracnet.com> wrote:
>
> Guillaume noticed this on s390 whilst writing a driver that used
> compound pages. Seems correct to me, I've tested it on i386 as
> well. The patch just makes us call free_pages_check for each element
> of a compound page.
> 
> diff -purN -X /home/mbligh/.diff.exclude virgin/mm/page_alloc.c clear_dirty/mm/page_alloc.c
> --- virgin/mm/page_alloc.c	2003-10-14 15:50:36.000000000 -0700
> +++ clear_dirty/mm/page_alloc.c	2003-11-26 10:36:04.000000000 -0800
> @@ -267,8 +267,11 @@ free_pages_bulk(struct zone *zone, int c
>  void __free_pages_ok(struct page *page, unsigned int order)
>  {
>  	LIST_HEAD(list);
> +	int i;
>  
>  	mod_page_state(pgfree, 1 << order);
> +	for (i = 0 ; i < (1 << order) ; ++i)
> +		free_pages_check(__FUNCTION__, page + i);

hmm.  How did the dirty bit get itself set?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Clear dirty bits etc on compound frees
  2003-11-26 20:20 ` Andrew Morton
@ 2003-12-01  3:02   ` Guillaume Morin
  0 siblings, 0 replies; 5+ messages in thread
From: Guillaume Morin @ 2003-12-01  3:02 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Martin J. Bligh, linux-mm

Dans un message du 26 Nov a 12:20, Andrew Morton ecrivait :
> hmm.  How did the dirty bit get itself set?

Pages in the cluster are mmaped via the nopage method as decribed in
Linux Device Drivers : http://www.xml.com/ldd/chapter/book/ch13.html#t2
in section "Remapping RAM". When the userspace program writes on a page,
it gets the dirty bit.

-- 
Guillaume Morin <guillaume@morinfr.org>

   I'm unclean, a libertine, every time you vent your spleen, I seem to lose
    the power of speech, you're slipping slowly from my reach, you grow me
        like an evergreen, you've never seen me lonely at all. (Placebo)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Clear dirty bits etc on compound frees
  2003-11-26 20:13 [PATCH] Clear dirty bits etc on compound frees Martin J. Bligh
  2003-11-26 20:20 ` Andrew Morton
@ 2003-12-01 19:40 ` Martin J. Bligh
  2003-12-02  9:55   ` Arjan van de Ven
  1 sibling, 1 reply; 5+ messages in thread
From: Martin J. Bligh @ 2003-12-01 19:40 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-mm mailing list, Guillaume Morin

> Guillaume noticed this on s390 whilst writing a driver that used
> compound pages. Seems correct to me, I've tested it on i386 as
> well. The patch just makes us call free_pages_check for each element
> of a compound page.
> 
> diff -purN -X /home/mbligh/.diff.exclude virgin/mm/page_alloc.c clear_dirty/mm/page_alloc.c
> --- virgin/mm/page_alloc.c	2003-10-14 15:50:36.000000000 -0700
> +++ clear_dirty/mm/page_alloc.c	2003-11-26 10:36:04.000000000 -0800
> @@ -267,8 +267,11 @@ free_pages_bulk(struct zone *zone, int c
>  void __free_pages_ok(struct page *page, unsigned int order)
>  {
>  	LIST_HEAD(list);
> +	int i;
>  
>  	mod_page_state(pgfree, 1 << order);
> +	for (i = 0 ; i < (1 << order) ; ++i)
> +		free_pages_check(__FUNCTION__, page + i);
>  	free_pages_check(__FUNCTION__, page);
>  	list_add(&page->list, &list);
>  	kernel_map_pages(page, 1<<order, 0);

Gah. Guillaume pointed out that in editing his patch, I left the old 
free pages check in as well. <beats head repeatedly against wall>. Sorry.

I think you can reproduce this without the driver he's playing with
by mmap'ing /dev/mem, and writing into any clustered page group (that
a driver might have created or whatever).

diff -purN -X /home/mbligh/.diff.exclude virgin/mm/page_alloc.c clear_dirty/mm/page_alloc.c
--- virgin/mm/page_alloc.c	2003-10-14 15:50:36.000000000 -0700
+++ clear_dirty/mm/page_alloc.c	2003-12-01 11:34:09.000000000 -0800
@@ -267,9 +267,11 @@ free_pages_bulk(struct zone *zone, int c
 void __free_pages_ok(struct page *page, unsigned int order)
 {
 	LIST_HEAD(list);
+	int i;
 
 	mod_page_state(pgfree, 1 << order);
-	free_pages_check(__FUNCTION__, page);
+	for (i = 0 ; i < (1 << order) ; ++i)
+		free_pages_check(__FUNCTION__, page + i);
 	list_add(&page->list, &list);
 	kernel_map_pages(page, 1<<order, 0);
 	free_pages_bulk(page_zone(page), 1, &list, order);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Clear dirty bits etc on compound frees
  2003-12-01 19:40 ` Martin J. Bligh
@ 2003-12-02  9:55   ` Arjan van de Ven
  0 siblings, 0 replies; 5+ messages in thread
From: Arjan van de Ven @ 2003-12-02  9:55 UTC (permalink / raw)
  To: Martin J. Bligh; +Cc: Andrew Morton, linux-mm mailing list, Guillaume Morin

[-- Attachment #1: Type: text/plain, Size: 282 bytes --]


> I think you can reproduce this without the driver he's playing with
> by mmap'ing /dev/mem, and writing into any clustered page group (that
> a driver might have created or whatever).

that is an offence the program author should be shot for and then
chastized and ... ;)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-12-02  9:55 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-11-26 20:13 [PATCH] Clear dirty bits etc on compound frees Martin J. Bligh
2003-11-26 20:20 ` Andrew Morton
2003-12-01  3:02   ` Guillaume Morin
2003-12-01 19:40 ` Martin J. Bligh
2003-12-02  9:55   ` Arjan van de Ven

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.