Bug#503821: Backtrace with CONFIG_DEBUG_VM=y - Debian

This is a discussion on Bug#503821: Backtrace with CONFIG_DEBUG_VM=y - Debian ; The backtrace is a little different with CONFIG_DEBUG_VM=y, hopefully catching the issue nearer the source... [ 67.128123] ------------[ cut here ]------------ [ 67.129159] kernel BUG at include/linux/mm.h:296! [ 67.130294] invalid opcode: 0000 [1] SMP [ 67.131459] CPU 0 [ 67.132082] ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: Bug#503821: Backtrace with CONFIG_DEBUG_VM=y

  1. Bug#503821: Backtrace with CONFIG_DEBUG_VM=y

    The backtrace is a little different with CONFIG_DEBUG_VM=y, hopefully
    catching the issue nearer the source...

    [ 67.128123] ------------[ cut here ]------------
    [ 67.129159] kernel BUG at include/linux/mm.h:296!
    [ 67.130294] invalid opcode: 0000 [1] SMP
    [ 67.131459] CPU 0
    [ 67.132082] Pid: 794, comm: rsyslogd Not tainted 2.6.26-1-xen-amd64 #2
    [ 67.132082] RIP: e030:[] [] do_wp_page+0x2cf/0x7db
    [ 67.132082] RSP: e02b:ffff8800074b7d38 EFLAGS: 00010246
    [ 67.132082] RAX: 0000000000000000 RBX: ffff88000119c248 RCX: 000000000000018e
    [ 67.132082] RDX: ffff880001005710 RSI: 00007fffb93bd6a0 RDI: ffff8800076607c8
    [ 67.132082] RBP: ffff88000119c248 R08: ffff8800075c0e48 R09: ffff88000119c248
    [ 67.132082] R10: 0000000000007ff0 R11: 7fffffffffffffff R12: ffff880001005710
    [ 67.132082] R13: 00007fffb93bd6a0 R14: ffff8800076f1b00 R15: ffff8800076607c8
    [ 67.132082] FS: 00007f03b13b36e0(0000) GS:ffffffff80459000(0000) knlGS:0000000000000000
    [ 67.132082] CS: e033 DS: 0000 ES: 0000
    [ 67.132082] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 67.132082] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [ 67.132082] Process rsyslogd (pid: 794, threadinfo ffff8800074b6000, task ffff880007ed66c0)
    [ 67.132082] Stack: ffff880007ed7988 ffff8800075c0e48 ffff8800075c1de8 ffff880001229f00
    [ 67.132082] 0000000000000000 ffff88000119c248 ffff8800075c1de8 0000000000000002
    [ 67.132082] 000000000018e900 00007fffb93bd6a0 ffff8800076f1b60 ffffffff8026d4fa
    [ 67.132082] Call Trace:
    [ 67.132082] [] ? handle_mm_fault+0xbcb/0xc49
    [ 67.132082] [] ? do_page_fault+0xb73/0xf50
    [ 67.132082] [] ? send_signal+0x1bf/0x1db
    [ 67.132082] [] ? error_exit+0x0/0x69
    [ 67.132082] [] ? copy_user_generic_string+0x2d/0x40
    [ 67.132082] [] ? sys_select+0x123/0x183
    [ 67.132082] [] ? system_call+0x68/0x6d
    [ 67.132082] [] ? system_call+0x0/0x6d
    [ 67.132082]
    [ 67.132082]
    [ 67.132082] Code: bd 08 00 00 00 e8 45 19 fb ff e9 a4 04 00 00 49 8b 04 24 4c 89 e2 25 00 40 00 00 48 85 c0 74 05 49 8b 54 24 10 83 7a 08 00 75 04 <0f> 0b eb fe 90 ff 42 08 fe 45 00 0f b7 55 00 38 f2 0f 95 c0 84

    --
    Ian Campbell

    You can tell how far we have to go, when FORTRAN is the language of
    supercomputers.
    -- Steven Feiner

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEABECAAYFAkkPc5YACgkQM0+0qS9rzVkEwgCgjspPkPBbWD WRRjL/rFIvwBxy
    1gUAn2kqpRkI9ZJrp1Lo4VcyEAQUMcOg
    =lcBS
    -----END PGP SIGNATURE-----


  2. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    If I revert features/all/xen/workaround-pte-file.patch (i.e. use
    _PAGE_PSE for _PAGE_PROTNONE) then the crash when running the test
    program turns into a simple OOM, which I think is acceptable given the
    nature of the test program.

    However I assume the workaround is there for a specific purpose, what
    was it?
    --
    Ian Campbell

    You may be sure that when a man begins to call himself a "realist," he
    is preparing to do something he is secretly ashamed of doing.
    -- Sydney Harris

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEABECAAYFAkkQCBcACgkQM0+0qS9rzVnBPQCfYUlml1zRQb vdoTkZI3WpGRPw
    yzwAoNDIX5em0DK7kjqPdSL0NHAZHTpo
    =V8vO
    -----END PGP SIGNATURE-----


  3. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    On Tue, Nov 04, 2008 at 08:30:16AM +0000, Ian Campbell wrote:
    > However I assume the workaround is there for a specific purpose, what
    > was it?


    A crash in mprotect.

    | #include
    | #include
    | #include
    |
    | const int size = 4096;
    |
    | int main()
    | {
    | char *buf = mmap(0, size * 4, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
    | mprotect(buf, size, PROT_NONE);
    | mprotect(buf, size, PROT_READ);
    | printf("%d\n", buf[0]);
    | }

    Bastian

    --
    Earth -- mother of the most beautiful women in the universe.
    -- Apollo, "Who Mourns for Adonais?" stardate 3468.1



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    On Tue, 2008-11-04 at 09:49 +0100, Bastian Blank wrote:
    > On Tue, Nov 04, 2008 at 08:30:16AM +0000, Ian Campbell wrote:
    > > However I assume the workaround is there for a specific purpose, what
    > > was it?

    >
    > A crash in mprotect.


    Thanks.

    --
    Ian Campbell

    Today is a good day for information-gathering. Read someone else's mail file.




    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    On Tue, Nov 04, 2008 at 09:49:19AM +0100, Bastian Blank wrote:
    > On Tue, Nov 04, 2008 at 08:30:16AM +0000, Ian Campbell wrote:
    > > However I assume the workaround is there for a specific purpose, what
    > > was it?

    > A crash in mprotect.


    Maybe its the best to remove the workaround and instead cripple mprotect
    to not allow PROT_NONE for now. And then hope that this can't be
    triggered by mmap with PROT_NONE.

    Bastian

    --
    Those who hate and fight must stop themselves -- otherwise it is not stopped.
    -- Spock, "Day of the Dove", stardate unknown



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  6. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    On Tue, 2008-11-04 at 14:02 +0100, Bastian Blank wrote:
    > On Tue, Nov 04, 2008 at 09:49:19AM +0100, Bastian Blank wrote:
    > > On Tue, Nov 04, 2008 at 08:30:16AM +0000, Ian Campbell wrote:
    > > > However I assume the workaround is there for a specific purpose, what
    > > > was it?

    > > A crash in mprotect.

    >
    > Maybe its the best to remove the workaround and instead cripple mprotect
    > to not allow PROT_NONE for now. And then hope that this can't be
    > triggered by mmap with PROT_NONE.


    I was thinking of going down the path of removing the workaround then
    fixing mprotect, so your suggestion would be a consistant first step I
    think.

    Ian.
    --
    Ian Campbell

    Take what you can use and let the rest go by.
    -- Ken Kesey

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEABECAAYFAkkQW5kACgkQM0+0qS9rzVnRrQCg6CZ5LRsytB oK753pP2yLpEFm
    7GsAoKX5Lhmt9ckC/iC7E0yD4B5m/B3K
    =Z32w
    -----END PGP SIGNATURE-----


  7. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    On Tue, Nov 04, 2008 at 02:26:33PM +0000, Ian Campbell wrote:
    > On Tue, 2008-11-04 at 14:02 +0100, Bastian Blank wrote:
    > > Maybe its the best to remove the workaround and instead cripple mprotect
    > > to not allow PROT_NONE for now. And then hope that this can't be
    > > triggered by mmap with PROT_NONE.

    > I was thinking of going down the path of removing the workaround then
    > fixing mprotect, so your suggestion would be a consistant first step I
    > think.


    Unchecked patch attached. It disallows changes from and to PROT_NONE.

    Bastian

    --
    It is a human characteristic to love little animals, especially if
    they're attractive in some way.
    -- McCoy, "The Trouble with Tribbles", stardate 4525.6

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iEYEARECAAYFAkkQe7MACgkQnw66O/MvCNFKxgCgiheSGfT23/3GlozDXogoslQh
    gK8An0YcQCgcu1LtVFsltkZRoqJsqxg+
    =G2oM
    -----END PGP SIGNATURE-----


  8. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    On Tue, 2008-11-04 at 17:43 +0100, Bastian Blank wrote:
    > On Tue, Nov 04, 2008 at 02:26:33PM +0000, Ian Campbell wrote:
    > > On Tue, 2008-11-04 at 14:02 +0100, Bastian Blank wrote:
    > > > Maybe its the best to remove the workaround and instead cripple mprotect
    > > > to not allow PROT_NONE for now. And then hope that this can't be
    > > > triggered by mmap with PROT_NONE.

    > > I was thinking of going down the path of removing the workaround then
    > > fixing mprotect, so your suggestion would be a consistant first step I
    > > think.

    >
    > Unchecked patch attached. It disallows changes from and to PROT_NONE.


    It boots but I cannot login, it hangs after MOTD.

    I added some debug and I see an aweful lot of transitions to prot ==
    0x0, seemingly for every process... I think this login has hung although
    I don't get a debug message from it:

    43.350538] login S ffffffff8037fea0 0 1087 1
    [ 43.350538] ffff880007de7b78 0000000000000286 ffff880007de7ab0 0000000000000000
    [ 43.350538] ffff880007d1b810 ffffffff803d4460 ffff880007d1ba48 0000000007802b50
    [ 43.350538] 00000000000480fd ffffffff80292c42 0000000000000000 00000000000480fd
    [ 43.350538] Call Trace:
    [ 43.350538] [] __find_get_block_slow+0xec/0xf8
    [ 43.350538] [] do_get_write_access+0x39e/0x3e9
    [ 43.350538] [] schedule_timeout+0x1e/0xad
    [ 43.350538] [] __getblk+0x1d/0x230
    [ 43.350538] [] prepare_to_wait_exclusive+0x15/0x5e
    [ 43.350538] [] unix_wait_for_peer+0xb0/0xcc
    [ 43.350538] [] autoremove_wake_function+0x0/0x2e
    [ 43.350538] [] memcpy_fromiovec+0x36/0x66
    [ 43.350538] [] unix_dgram_sendmsg+0x3b7/0x4e4
    [ 43.350538] [] sock_sendmsg+0xcb/0xe3
    [ 43.350538] [] autoremove_wake_function+0x0/0x2e
    [ 43.350538] [] mntput_no_expire+0x20/0x15d
    [ 43.350538] [] unix_find_other+0x112/0x1e8
    [ 43.350538] [] do_path_lookup+0x14c/0x170
    [ 43.350538] [] mntput_no_expire+0x20/0x15d
    [ 43.350538] [] sockfd_lookup_light+0x1a/0x52
    [ 43.350538] [] sys_sendto+0xf3/0x127
    [ 43.350538] [] unix_dgram_connect+0x14d/0x182
    [ 43.350538] [] sys_connect+0x6c/0x9c
    [ 43.350538] [] system_call+0x68/0x6d
    [ 43.350538] [] system_call+0x0/0x6d

    Ian.
    --
    Ian Campbell

    True to our past we work with an inherited, observed, and accepted vision of
    personal futility, and of the beauty of the world.
    -- David Mamet

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEABECAAYFAkkQnrUACgkQM0+0qS9rzVkcDwCeItF1eA1sdX cKPVwjHNgosz6L
    BLkAn1TicxKbY7fKdQFdJhlZLh++tVhk
    =QS8d
    -----END PGP SIGNATURE-----


  9. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    * Bastian Blank:

    > Unchecked patch attached. It disallows changes from and to PROT_NONE.


    Huh? Doesn't this break the user-space ABI?



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  10. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    On Wed, Nov 05, 2008 at 07:06:58AM +0000, Ian Campbell wrote:
    > This patch makes mprotect work by (very skankily) hacking out large page
    > support which is unsupported on top of Xen anyway (I think so, currently
    > anyway). I think I took out PAT as collaterol damage too. A cleaned up
    > version without the pat damage might be an acceptable fix for the
    > mprotect issue.


    Xen have to support large pages, they are used over and over.

    > My suspicion is that one of the -xen.c or mach-xen/asm/ files has gotten
    > out of sync with a fix to its native partner since _PAGE_PSE is used for
    > PROTNONE on native too so they must get round it somehow. I'll have a
    > scrobble through and see if I can see it.


    Would make sense.

    What happens if you use "nopat" to disable the usage of PAT? The only
    way to generate huge pages from userspace is to use hugetlbfs, which is
    disabled.

    Bastian



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  11. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    On Wed, Nov 05, 2008 at 10:13:46AM +0000, Ian Campbell wrote:
    > Perhaps some of those entries are just stale stack data. sys_mprotect
    > won't have been called from do_page_fault for example.


    Hrm. Yes. mm/fault.c and mm/fault-xen.c have some weird differences.

    Bastian

    --
    If there are self-made purgatories, then we all have to live in them.
    -- Spock, "This Side of Paradise", stardate 3417.7



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  12. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    On Wed, 2008-11-05 at 10:59 +0100, Bastian Blank wrote:
    > On Tue, Nov 04, 2008 at 09:49:19AM +0100, Bastian Blank wrote:
    > > On Tue, Nov 04, 2008 at 08:30:16AM +0000, Ian Campbell wrote:
    > > > However I assume the workaround is there for a specific purpose, what
    > > > was it?

    > > A crash in mprotect.

    >
    > I took another look into the original crash.
    >
    > | BUG: unable to handle kernel paging request at cefb81c0
    > | IP: [] handle_mm_fault+0x4d6/0xe78
    > | *pdpt = 00000000a8072027 *pde = 00000000b62fd067 *pte = 80000000a8f19061
    > | Oops: 0003 [#1] SMP
    > | Modules linked in: ipv6 ext3 jbd mbcache thermal_sys
    > |
    > | Pid: 1093, comm: test Not tainted (2.6.26-1-xen-686 #1)
    > | EIP: 0061:[] EFLAGS: 00010282 CPU: 0
    > | EIP is at handle_mm_fault+0x4d6/0xe78
    > | EAX: aa1210e5 EBX: b7e38000 ECX: 80000000 EDX: 80000000
    > | ESI: 00000000 EDI: cefb81c0 EBP: c13c070c ESP: cfccdea8
    > | DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
    > | Process test (pid: 1093, ti=cfccc000 task=cfcb8da0 task.ti=cfccc000)
    > [...]
    > | Call Trace:
    > | [] xen_tlb_flush_mask+0x28/0x39
    > | [] mprotect_fixup+0x6d3/0x735
    > | [] do_page_fault+0x684/0xbd6
    > | [] sys_mprotect+0x17a/0x1df
    > | [] sys_mprotect+0x1cc/0x1df
    > | [] do_page_fault+0x0/0xbd6
    > | [] error_code+0x35/0x3c
    > | =======================
    > [...]
    > | EIP: [] handle_mm_fault+0x4d6/0xe78 SS:ESP 0069:cfccdea8
    > | ---[ end trace a379c90432c095a5 ]---
    >
    > Why would Xen inject a page fault into a tlb flush? The tlb flushs in
    > the paravirt implementation looks completely different.


    Perhaps some of those entries are just stale stack data. sys_mprotect
    won't have been called from do_page_fault for example.

    Ian.

    >

    --
    Ian Campbell
    Current Noise: Fudge Tunnel - Sunshine Of Your Love

    If you go out of your mind, do it quietly, so as not to disturb those
    around you.




    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  13. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    On Tue, Nov 04, 2008 at 09:49:19AM +0100, Bastian Blank wrote:
    > On Tue, Nov 04, 2008 at 08:30:16AM +0000, Ian Campbell wrote:
    > > However I assume the workaround is there for a specific purpose, what
    > > was it?

    > A crash in mprotect.


    I took another look into the original crash.

    | BUG: unable to handle kernel paging request at cefb81c0
    | IP: [] handle_mm_fault+0x4d6/0xe78
    | *pdpt = 00000000a8072027 *pde = 00000000b62fd067 *pte = 80000000a8f19061
    | Oops: 0003 [#1] SMP
    | Modules linked in: ipv6 ext3 jbd mbcache thermal_sys
    |
    | Pid: 1093, comm: test Not tainted (2.6.26-1-xen-686 #1)
    | EIP: 0061:[] EFLAGS: 00010282 CPU: 0
    | EIP is at handle_mm_fault+0x4d6/0xe78
    | EAX: aa1210e5 EBX: b7e38000 ECX: 80000000 EDX: 80000000
    | ESI: 00000000 EDI: cefb81c0 EBP: c13c070c ESP: cfccdea8
    | DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
    | Process test (pid: 1093, ti=cfccc000 task=cfcb8da0 task.ti=cfccc000)
    [...]
    | Call Trace:
    | [] xen_tlb_flush_mask+0x28/0x39
    | [] mprotect_fixup+0x6d3/0x735
    | [] do_page_fault+0x684/0xbd6
    | [] sys_mprotect+0x17a/0x1df
    | [] sys_mprotect+0x1cc/0x1df
    | [] do_page_fault+0x0/0xbd6
    | [] error_code+0x35/0x3c
    | =======================
    [...]
    | EIP: [] handle_mm_fault+0x4d6/0xe78 SS:ESP 0069:cfccdea8
    | ---[ end trace a379c90432c095a5 ]---

    Why would Xen inject a page fault into a tlb flush? The tlb flushs in
    the paravirt implementation looks completely different.

    Bastian

    --
    Wait! You have not been prepared!
    -- Mr. Atoz, "Tomorrow is Yesterday", stardate 3113.2



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  14. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    On Wed, 2008-11-05 at 10:05 +0000, Ian Campbell wrote:
    >
    > > What happens if you use "nopat" to disable the usage of PAT?

    >
    > CONFIG_X86_PAT is disabled anyway so it makes no difference.


    Although it does turn out that PAT is implicated...

    The key turned out to be the difference in _PAGE_CACHE_MASK between the
    asm and mach-xen/asm versions of pgtable.h.
    -#define _PAGE_CACHE_MASK (_PAGE_PCD | _PAGE_PWT)
    [...]
    +#define _PAGE_CACHE_MASK (_PAGE_PCD | _PAGE_PWT | _PAGE_PAT)

    Native sets up PAT such that only the PCD and PWD bits are used for the
    cache modes the kernel is interested in (WC, WC, UC, UC-) and the PAT
    bit is unused. On Xen PAT is controlled by the hypervisor and has a
    static setting which uses the PAT bit for WC.

    PAT PCD PWT NATIVE XEN BIOS INIT
    0 0 0 WB WB WB WB
    0 0 1 WC WT WT WT
    0 1 0 UC- UC- UC- UC-
    0 1 1 UC UC - UC
    1 0 0 - WC WB WB
    1 0 1 - WP WT WT
    1 1 0 - - UC- UC-
    1 1 1 - - - UC-
    (INIT is the processors initial state and BIOS is apparently commonly
    set by the BIOS)

    The kernel uses WB and UC/UC- and conditionally uses WC IFF PAT is
    compiled in (CONFIG_X86_PAT) and enabled (pat_wc_enabled).

    Now it seems that on native the masking and checking etc of PROTNONE
    pages works fine because _PAGE_CACHE_MASK does not include _PAGE_PAT
    (which == _PAGE_PSE used by PROTNONE). Xen broke this by adding that bit
    to the mask which presumably leads to confusion on some paths and then
    to the observed mprotect crash...

    Since we disable CONFIG_X86_PAT it is much simpler to revert the change
    to _PAGE_CACHE_MASK than to figure out where the confusion occurs. The
    attached patch is bigger than this trivial change since I #undefined
    _PAGE_CACHE_{WT,WC,WP} to be sure they were unused and had to #ifdef
    their use. WT and WP are completely unused anyway and WC is always gated
    on pat_wc_enabled and hence would have been compiled out.

    With this both the mprotect and the swap death test cases work (or
    correctly OOM in the swap case).

    Obviously workaround-pte-file.patch should be dropped too. I never got
    to the bottom of why the workaround caused the swap issue. I'll hand
    wave it as "incorrect masking" somewhere ;-)

    Shall I commit?

    Ian.

    Index: sid-xen/include/asm-x86/mach-xen/asm/pgtable.h
    ================================================== =================
    --- sid-xen.orig/include/asm-x86/mach-xen/asm/pgtable.h 2008-11-05 09:47:42.000000000 +0000
    +++ sid-xen/include/asm-x86/mach-xen/asm/pgtable.h 2008-11-05 12:32:00.000000000 +0000
    @@ -67,18 +67,20 @@
    _PAGE_DIRTY | __kernel_page_user)

    /* Set of bits not changed in pte_modify */
    -#define _PAGE_CHG_MASK (PTE_MASK | _PAGE_CACHE_MASK | _PAGE_IO | \
    +#define _PAGE_CHG_MASK (PTE_MASK | _PAGE_PCD | _PAGE_PWT | _PAGE_IO | \
    _PAGE_ACCESSED | _PAGE_DIRTY)

    /*
    * PAT settings are part of the hypervisor interface, which sets the
    * MSR to 0x050100070406 (i.e. WB, WT, UC-, UC, WC, WP [, UC, UC]).
    */
    -#define _PAGE_CACHE_MASK (_PAGE_PCD | _PAGE_PWT | _PAGE_PAT)
    +#define _PAGE_CACHE_MASK (_PAGE_PCD | _PAGE_PWT)
    #define _PAGE_CACHE_WB (0)
    +#ifdef CONFIG_X86_PAT
    #define _PAGE_CACHE_WT (_PAGE_PWT)
    #define _PAGE_CACHE_WC (_PAGE_PAT)
    #define _PAGE_CACHE_WP (_PAGE_PAT | _PAGE_PWT)
    +#endif
    #define _PAGE_CACHE_UC_MINUS (_PAGE_PCD)
    #define _PAGE_CACHE_UC (_PAGE_PCD | _PAGE_PWT)

    Index: sid-xen/arch/x86/Kconfig
    ================================================== =================
    --- sid-xen.orig/arch/x86/Kconfig 2008-11-05 12:26:55.000000000 +0000
    +++ sid-xen/arch/x86/Kconfig 2008-11-05 12:27:02.000000000 +0000
    @@ -1141,6 +1141,7 @@
    bool
    prompt "x86 PAT support"
    depends on MTRR
    + depends on !XEN
    help
    Use PAT attributes to setup page level cache control.

    Index: sid-xen/arch/x86/mm/ioremap-xen.c
    ================================================== =================
    --- sid-xen.orig/arch/x86/mm/ioremap-xen.c 2008-11-05 12:37:53.000000000 +0000
    +++ sid-xen/arch/x86/mm/ioremap-xen.c 2008-11-05 12:43:06.000000000 +0000
    @@ -255,9 +255,11 @@
    default:
    err = _set_memory_uc(vaddr, nrpages);
    break;
    +#ifdef CONFIG_X86_PAT
    case _PAGE_CACHE_WC:
    err = _set_memory_wc(vaddr, nrpages);
    break;
    +#endif
    case _PAGE_CACHE_WB:
    err = _set_memory_wb(vaddr, nrpages);
    break;
    @@ -340,11 +342,17 @@
    * - request is uc-, return cannot be write-combine
    * - request is write-combine, return cannot be write-back
    */
    - if ((prot_val == _PAGE_CACHE_UC_MINUS &&
    + if (
    +#ifdef CONFIG_X86_PAT
    + (prot_val == _PAGE_CACHE_UC_MINUS &&
    (new_prot_val == _PAGE_CACHE_WB ||
    new_prot_val == _PAGE_CACHE_WC)) ||
    (prot_val == _PAGE_CACHE_WC &&
    - new_prot_val == _PAGE_CACHE_WB)) {
    + new_prot_val == _PAGE_CACHE_WB)
    +#else
    + (prot_val == _PAGE_CACHE_UC_MINUS && new_prot_val == _PAGE_CACHE_WB)
    +#endif
    + ) {
    pr_debug(
    "ioremap error for 0x%llx-0x%llx, requested 0x%lx, got 0x%lx\n",
    (unsigned long long)phys_addr,
    @@ -364,9 +372,11 @@
    case _PAGE_CACHE_UC_MINUS:
    prot = PAGE_KERNEL_UC_MINUS;
    break;
    +#ifdef CONFIG_X86_PAT
    case _PAGE_CACHE_WC:
    prot = PAGE_KERNEL_WC;
    break;
    +#endif
    case _PAGE_CACHE_WB:
    prot = PAGE_KERNEL;
    break;
    @@ -445,10 +455,12 @@
    */
    void __iomem *ioremap_wc(unsigned long phys_addr, unsigned long size)
    {
    +#ifdef CONFIG_X86_PAT
    if (pat_wc_enabled)
    return __ioremap_caller(phys_addr, size, _PAGE_CACHE_WC,
    __builtin_return_address(0));
    else
    +#endif
    return ioremap_nocache(phys_addr, size);
    }
    EXPORT_SYMBOL(ioremap_wc);
    Index: sid-xen/arch/x86/mm/pageattr-xen.c
    ================================================== =================
    --- sid-xen.orig/arch/x86/mm/pageattr-xen.c 2008-11-05 12:30:56.000000000 +0000
    +++ sid-xen/arch/x86/mm/pageattr-xen.c 2008-11-05 12:34:37.000000000 +0000
    @@ -817,14 +817,17 @@
    }
    EXPORT_SYMBOL(set_memory_uc);

    +#ifdef CONFIG_X86_PAT
    int _set_memory_wc(unsigned long addr, int numpages)
    {
    return change_page_attr_set(addr, numpages,
    __pgprot(_PAGE_CACHE_WC));
    }
    +#endif

    int set_memory_wc(unsigned long addr, int numpages)
    {
    +#ifdef CONFIG_X86_PAT
    if (!pat_wc_enabled)
    return set_memory_uc(addr, numpages);

    @@ -833,6 +836,9 @@
    return -EINVAL;

    return _set_memory_wc(addr, numpages);
    +#else
    + return set_memory_uc(addr, numpages);
    +#endif
    }
    EXPORT_SYMBOL(set_memory_wc);

    Index: sid-xen/arch/x86/mm/pat-xen.c
    ================================================== =================
    --- sid-xen.orig/arch/x86/mm/pat-xen.c 2008-11-05 12:35:28.000000000 +0000
    +++ sid-xen/arch/x86/mm/pat-xen.c 2008-11-05 12:37:44.000000000 +0000
    @@ -116,9 +116,11 @@
    case _PAGE_CACHE_UC: return "uncached";
    case _PAGE_CACHE_UC_MINUS: return "uncached-minus";
    case _PAGE_CACHE_WB: return "write-back";
    +#ifdef CONFIG_X86_PAT
    case _PAGE_CACHE_WC: return "write-combining";
    case _PAGE_CACHE_WP: return "write-protected";
    case _PAGE_CACHE_WT: return "write-through";
    +#endif
    default: return "broken";
    }
    }
    @@ -157,6 +159,7 @@
    * The intersection is based on "Effective Memory Type" tables in IA-32
    * SDM vol 3a
    */
    +#ifdef CONFIG_X86_PAT
    static int pat_x_mtrr_type(u64 start, u64 end, unsigned long prot,
    unsigned long *ret_prot)
    {
    @@ -199,6 +202,7 @@

    return 0;
    }
    +#endif

    /*
    * req_type typically has one of the:
    @@ -218,6 +222,7 @@
    int reserve_memtype(u64 start, u64 end, unsigned long req_type,
    unsigned long *ret_type)
    {
    +#ifdef CONFIG_X86_PAT
    struct memtype *new_entry = NULL;
    struct memtype *parse;
    unsigned long actual_type;
    @@ -431,6 +436,17 @@

    spin_unlock(&memtype_lock);
    return err;
    +#else
    + /* This is identical to page table setting without PAT */
    + if (ret_type) {
    + if (req_type == -1) {
    + *ret_type = _PAGE_CACHE_WB;
    + } else {
    + *ret_type = req_type;
    + }
    + }
    + return 0;
    +#endif
    }

    int free_memtype(u64 start, u64 end)


    --
    Ian Campbell
    Current Noise: Kreator - Dying Race Apocalypse

    According to Kentucky state law, every person must take a bath at least
    once a year.




    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  15. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    On Wed, Nov 05, 2008 at 01:10:30PM +0000, Ian Campbell wrote:
    > On Wed, 2008-11-05 at 10:05 +0000, Ian Campbell wrote:
    > > > What happens if you use "nopat" to disable the usage of PAT?

    > > CONFIG_X86_PAT is disabled anyway so it makes no difference.

    > Although it does turn out that PAT is implicated...


    Ah.

    > /* Set of bits not changed in pte_modify */
    > -#define _PAGE_CHG_MASK (PTE_MASK | _PAGE_CACHE_MASK | _PAGE_IO | \
    > +#define _PAGE_CHG_MASK (PTE_MASK | _PAGE_PCD | _PAGE_PWT | _PAGE_IO | \
    > _PAGE_ACCESSED | _PAGE_DIRTY)


    This is the direct expansion, why?

    > +#else
    > + /* This is identical to page table setting without PAT */
    > + if (ret_type) {
    > + if (req_type == -1) {
    > + *ret_type = _PAGE_CACHE_WB;
    > + } else {
    > + *ret_type = req_type;
    > + }
    > + }
    > + return 0;
    > +#endif


    Code duplication. Better force pat_wc_enabled to 0 and let the compiler
    do this instead of forcing the knowledge into the preprocessor.

    I would also make several parts dependant on _PAGE_CACHE_WC instead of
    X86_PAT.

    Bastian

    --
    Killing is wrong.
    -- Losira, "That Which Survives", stardate unknown



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  16. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    On Wed, Nov 05, 2008 at 02:50:32PM +0100, Bastian Blank wrote:
    > On Wed, Nov 05, 2008 at 01:10:30PM +0000, Ian Campbell wrote:
    > > On Wed, 2008-11-05 at 10:05 +0000, Ian Campbell wrote:
    > > > > What happens if you use "nopat" to disable the usage of PAT?
    > > > CONFIG_X86_PAT is disabled anyway so it makes no difference.

    > > Although it does turn out that PAT is implicated...

    > Ah.


    Shorter patch. Tries to use the compiler instead of the preprocessor.

    Bastian

    --
    Change is the essential process of all existence.
    -- Spock, "Let That Be Your Last Battlefield", stardate 5730.2


  17. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    On Wed, 2008-11-05 at 14:50 +0100, Bastian Blank wrote:
    > On Wed, Nov 05, 2008 at 01:10:30PM +0000, Ian Campbell wrote:
    > > On Wed, 2008-11-05 at 10:05 +0000, Ian Campbell wrote:
    > > > > What happens if you use "nopat" to disable the usage of PAT?
    > > > CONFIG_X86_PAT is disabled anyway so it makes no difference.

    > > Although it does turn out that PAT is implicated...

    >
    > Ah.
    >
    > > /* Set of bits not changed in pte_modify */
    > > -#define _PAGE_CHG_MASK (PTE_MASK | _PAGE_CACHE_MASK | _PAGE_IO | \
    > > +#define _PAGE_CHG_MASK (PTE_MASK | _PAGE_PCD | _PAGE_PWT | _PAGE_IO | \
    > > _PAGE_ACCESSED | _PAGE_DIRTY)

    >
    > This is the direct expansion, why?


    Just because the native version uses the expanded version and I was
    playing with it earlier. I decided to keep it since the difference
    seemed unnecessary.

    > > +#else
    > > + /* This is identical to page table setting without PAT */
    > > + if (ret_type) {
    > > + if (req_type == -1) {
    > > + *ret_type = _PAGE_CACHE_WB;
    > > + } else {
    > > + *ret_type = req_type;
    > > + }
    > > + }
    > > + return 0;
    > > +#endif

    >
    > Code duplication. Better force pat_wc_enabled to 0 and let the compiler
    > do this instead of forcing the knowledge into the preprocessor.


    pat_wc_enable is already const int = 0, I just did it via the
    preprocessor to prove that _PAGE_CACHE_WC was unused at build time,
    about 90% of the patch is only because of that. I could drop everything
    apart from the _PAGE_CACHE_MASK and the Kconfig change and the fix would
    still be valid. I just felt that making the code completely unavailable
    was safer in case something sneaks in since it will be a build failure.

    In this case I could have simply ifdef'd the main function body, I've
    made that change.

    > I would also make several parts dependant on _PAGE_CACHE_WC instead of
    > X86_PAT.


    OK.

    Fresh patch attached. I'll test the proper Debian config rather than my
    cut down one now.

    If I remove workaround-pte-file.patch is the correct way to do that to
    remove the reference from debian/patches/series/7-extra or to add a "-"
    type reference to 10-extra?

    Ian.

    Index: sid-xen/include/asm-x86/mach-xen/asm/pgtable.h
    ================================================== =================
    --- sid-xen.orig/include/asm-x86/mach-xen/asm/pgtable.h 2008-11-05 13:07:33.000000000 +0000
    +++ sid-xen/include/asm-x86/mach-xen/asm/pgtable.h 2008-11-05 14:08:15.000000000 +0000
    @@ -67,18 +67,20 @@
    _PAGE_DIRTY | __kernel_page_user)

    /* Set of bits not changed in pte_modify */
    -#define _PAGE_CHG_MASK (PTE_MASK | _PAGE_CACHE_MASK | _PAGE_IO | \
    +#define _PAGE_CHG_MASK (PTE_MASK | _PAGE_PCD | _PAGE_PWT | _PAGE_IO | \
    _PAGE_ACCESSED | _PAGE_DIRTY)

    /*
    * PAT settings are part of the hypervisor interface, which sets the
    * MSR to 0x050100070406 (i.e. WB, WT, UC-, UC, WC, WP [, UC, UC]).
    */
    -#define _PAGE_CACHE_MASK (_PAGE_PCD | _PAGE_PWT | _PAGE_PAT)
    +#define _PAGE_CACHE_MASK (_PAGE_PCD | _PAGE_PWT)
    #define _PAGE_CACHE_WB (0)
    +#ifdef CONFIG_X86_PAT
    #define _PAGE_CACHE_WT (_PAGE_PWT)
    #define _PAGE_CACHE_WC (_PAGE_PAT)
    #define _PAGE_CACHE_WP (_PAGE_PAT | _PAGE_PWT)
    +#endif
    #define _PAGE_CACHE_UC_MINUS (_PAGE_PCD)
    #define _PAGE_CACHE_UC (_PAGE_PCD | _PAGE_PWT)

    Index: sid-xen/arch/x86/Kconfig
    ================================================== =================
    --- sid-xen.orig/arch/x86/Kconfig 2008-11-05 13:07:33.000000000 +0000
    +++ sid-xen/arch/x86/Kconfig 2008-11-05 14:08:15.000000000 +0000
    @@ -1141,6 +1141,7 @@
    bool
    prompt "x86 PAT support"
    depends on MTRR
    + depends on !XEN
    help
    Use PAT attributes to setup page level cache control.

    Index: sid-xen/arch/x86/mm/ioremap-xen.c
    ================================================== =================
    --- sid-xen.orig/arch/x86/mm/ioremap-xen.c 2008-11-05 13:07:33.000000000 +0000
    +++ sid-xen/arch/x86/mm/ioremap-xen.c 2008-11-05 14:08:15.000000000 +0000
    @@ -255,9 +255,11 @@
    default:
    err = _set_memory_uc(vaddr, nrpages);
    break;
    +#ifdef _PAGE_CACHE_WC
    case _PAGE_CACHE_WC:
    err = _set_memory_wc(vaddr, nrpages);
    break;
    +#endif
    case _PAGE_CACHE_WB:
    err = _set_memory_wb(vaddr, nrpages);
    break;
    @@ -340,11 +342,17 @@
    * - request is uc-, return cannot be write-combine
    * - request is write-combine, return cannot be write-back
    */
    - if ((prot_val == _PAGE_CACHE_UC_MINUS &&
    + if (
    +#ifdef _PAGE_CACHE_WC
    + (prot_val == _PAGE_CACHE_UC_MINUS &&
    (new_prot_val == _PAGE_CACHE_WB ||
    new_prot_val == _PAGE_CACHE_WC)) ||
    (prot_val == _PAGE_CACHE_WC &&
    - new_prot_val == _PAGE_CACHE_WB)) {
    + new_prot_val == _PAGE_CACHE_WB)
    +#else
    + (prot_val == _PAGE_CACHE_UC_MINUS && new_prot_val == _PAGE_CACHE_WB)
    +#endif
    + ) {
    pr_debug(
    "ioremap error for 0x%llx-0x%llx, requested 0x%lx, got 0x%lx\n",
    (unsigned long long)phys_addr,
    @@ -364,9 +372,11 @@
    case _PAGE_CACHE_UC_MINUS:
    prot = PAGE_KERNEL_UC_MINUS;
    break;
    +#ifdef _PAGE_CACHE_WC
    case _PAGE_CACHE_WC:
    prot = PAGE_KERNEL_WC;
    break;
    +#endif
    case _PAGE_CACHE_WB:
    prot = PAGE_KERNEL;
    break;
    @@ -445,10 +455,12 @@
    */
    void __iomem *ioremap_wc(unsigned long phys_addr, unsigned long size)
    {
    +#ifdef CONFIG_X86_PAT
    if (pat_wc_enabled)
    return __ioremap_caller(phys_addr, size, _PAGE_CACHE_WC,
    __builtin_return_address(0));
    else
    +#endif
    return ioremap_nocache(phys_addr, size);
    }
    EXPORT_SYMBOL(ioremap_wc);
    Index: sid-xen/arch/x86/mm/pageattr-xen.c
    ================================================== =================
    --- sid-xen.orig/arch/x86/mm/pageattr-xen.c 2008-11-05 13:07:33.000000000 +0000
    +++ sid-xen/arch/x86/mm/pageattr-xen.c 2008-11-05 14:08:15.000000000 +0000
    @@ -817,14 +817,17 @@
    }
    EXPORT_SYMBOL(set_memory_uc);

    +#ifdef CONFIG_X86_PAT
    int _set_memory_wc(unsigned long addr, int numpages)
    {
    return change_page_attr_set(addr, numpages,
    __pgprot(_PAGE_CACHE_WC));
    }
    +#endif

    int set_memory_wc(unsigned long addr, int numpages)
    {
    +#ifdef CONFIG_X86_PAT
    if (!pat_wc_enabled)
    return set_memory_uc(addr, numpages);

    @@ -833,6 +836,9 @@
    return -EINVAL;

    return _set_memory_wc(addr, numpages);
    +#else
    + return set_memory_uc(addr, numpages);
    +#endif
    }
    EXPORT_SYMBOL(set_memory_wc);

    Index: sid-xen/arch/x86/mm/pat-xen.c
    ================================================== =================
    --- sid-xen.orig/arch/x86/mm/pat-xen.c 2008-11-05 13:07:33.000000000 +0000
    +++ sid-xen/arch/x86/mm/pat-xen.c 2008-11-05 14:09:30.000000000 +0000
    @@ -116,9 +116,15 @@
    case _PAGE_CACHE_UC: return "uncached";
    case _PAGE_CACHE_UC_MINUS: return "uncached-minus";
    case _PAGE_CACHE_WB: return "write-back";
    +#ifdef _PAGE_CACHE_WC
    case _PAGE_CACHE_WC: return "write-combining";
    +#endif
    +#ifdef _PAGE_CACHE_WP
    case _PAGE_CACHE_WP: return "write-protected";
    +#endif
    +#ifdef _PAGE_CACHE_WT
    case _PAGE_CACHE_WT: return "write-through";
    +#endif
    default: return "broken";
    }
    }
    @@ -157,6 +163,7 @@
    * The intersection is based on "Effective Memory Type" tables in IA-32
    * SDM vol 3a
    */
    +#ifdef CONFIG_X86_PAT
    static int pat_x_mtrr_type(u64 start, u64 end, unsigned long prot,
    unsigned long *ret_prot)
    {
    @@ -199,6 +206,7 @@

    return 0;
    }
    +#endif

    /*
    * req_type typically has one of the:
    @@ -218,10 +226,12 @@
    int reserve_memtype(u64 start, u64 end, unsigned long req_type,
    unsigned long *ret_type)
    {
    +#ifdef CONFIG_X86_PAT
    struct memtype *new_entry = NULL;
    struct memtype *parse;
    unsigned long actual_type;
    int err = 0;
    +#endif

    /* Only track when pat_wc_enabled */
    if (!pat_wc_enabled) {
    @@ -236,6 +246,7 @@
    return 0;
    }

    +#ifdef CONFIG_X86_PAT
    /* Low ISA region is always mapped WB in page table. No need to track */
    if (start >= ISA_START_ADDRESS && (end - 1) <= ISA_END_ADDRESS) {
    if (ret_type)
    @@ -431,6 +442,7 @@

    spin_unlock(&memtype_lock);
    return err;
    +#endif
    }

    int free_memtype(u64 start, u64 end)

    --
    Ian Campbell

    Licensed and bonded.




    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  18. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    On Wed, Nov 05, 2008 at 03:15:38PM +0100, Bastian Blank wrote:
    > On Wed, Nov 05, 2008 at 02:50:32PM +0100, Bastian Blank wrote:
    > > On Wed, Nov 05, 2008 at 01:10:30PM +0000, Ian Campbell wrote:
    > > > On Wed, 2008-11-05 at 10:05 +0000, Ian Campbell wrote:
    > > > > > What happens if you use "nopat" to disable the usage of PAT?
    > > > > CONFIG_X86_PAT is disabled anyway so it makes no difference.
    > > > Although it does turn out that PAT is implicated...

    > > Ah.

    > Shorter patch. Tries to use the compiler instead of the preprocessor.


    Even shorter.

    Bastian

    --
    No more blah, blah, blah!
    -- Kirk, "Miri", stardate 2713.6

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iEYEARECAAYFAkkRq5UACgkQnw66O/MvCNGLKgCdGkEfVKbvGVXqEpE0PsmStjMV
    K0MAnjNAe9hkCWoeUVv/dkpMbLymJ3ZC
    =kf/x
    -----END PGP SIGNATURE-----


  19. Bug#503821: Purpose of features/all/xen/workaround-pte-file.patch?

    On Wed, 2008-11-05 at 15:20 +0100, Bastian Blank wrote:
    > On Wed, Nov 05, 2008 at 03:15:38PM +0100, Bastian Blank wrote:
    > > On Wed, Nov 05, 2008 at 02:50:32PM +0100, Bastian Blank wrote:
    > > > On Wed, Nov 05, 2008 at 01:10:30PM +0000, Ian Campbell wrote:
    > > > > On Wed, 2008-11-05 at 10:05 +0000, Ian Campbell wrote:
    > > > > > > What happens if you use "nopat" to disable the usage of PAT?
    > > > > > CONFIG_X86_PAT is disabled anyway so it makes no difference.
    > > > > Although it does turn out that PAT is implicated...
    > > > Ah.

    > > Shorter patch. Tries to use the compiler instead of the preprocessor.

    >
    > Even shorter.


    I think the minimum is attached, but this wouldn't give a build failure
    if a usage snuck in.

    I'm happy with any of the variants.

    --
    Ian Campbell

    Eat drink and be merry, for tomorrow they may make it illegal.


+ Reply to Thread