<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <style type="text/css" style="display:none"></style> </head> <body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;"> <div>Hi,<span style="font-family:Calibri,sans-serif; font-size:14.6667px; background-color:rgb(255,255,255)">Hatayama</span><br> </div> <div><br> </div> <div>Since zram page not a existing page,so we can't use vtop find exactly physical address,so gcore have to make a little change for this.gcore patch i've already sent in previous mail<br> </div> <div><br> </div> <div>I've answered your question in the previous email about exactly kernel commit in aarch64 stack,please refer to below change<br> </div> <div>The latest two changes are attached,please review.<br> </div> <div><br> </div> <div><span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)">commit 34be98f4944f99076f049a6806fc5f5207a755d3</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)">Author: Ard Biesheuvel <ard.biesheuvel@linaro.org></span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)">Date: Thu Jul 20 17:15:45 2017 +0100</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> arm64: kernel: remove {THREAD,IRQ_STACK}_START_SP</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> For historical reasons, we leave the top 16 bytes of our task and IRQ</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> stacks unused, a practice used to ensure that the SP can always be</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> masked to find the base of the current stack (historically, where</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> thread_info could be found).</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> However, this is not necessary, as:</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> * When an exception is taken from a task stack, we decrement the SP by</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> S_FRAME_SIZE and stash the exception registers before we compare the</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> SP against the task stack. In such cases, the SP must be at least</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> S_FRAME_SIZE below the limit, and can be safely masked to determine</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> whether the task stack is in use.</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> * When transitioning to an IRQ stack, we'll place a dummy frame onto the</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> IRQ stack before enabling asynchronous exceptions, or executing code</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> we expect to trigger faults. Thus, if an exception is taken from the</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> IRQ stack, the SP must be at least 16 bytes below the limit.</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> * We no longer mask the SP to find the thread_info, which is now found</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> via sp_el0. Note that historically, the offset was critical to ensure</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> that cpu_switch_to() found the correct stack for new threads that</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> hadn't yet executed ret_from_fork().</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> Given that, this initial offset serves no purpose, and can be removed.</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> This brings us in-line with other architectures (e.g. x86) which do not</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> rely on this masking.</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org></span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> [Mark: rebase, kill THREAD_START_SP, commit msg additions]</span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> Signed-off-by: Mark Rutland <mark.rutland@arm.com></span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> Reviewed-by: Will Deacon <will.deacon@arm.com></span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> Tested-by: Laura Abbott <labbott@redhat.com></span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> Cc: Catalin Marinas <catalin.marinas@arm.com></span><br style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> <span style="color:rgb(33,33,33); font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif; font-size:13.3333px; background-color:rgb(255,255,255)"> Cc: James Morse <james.morse@arm.com></span><br> <br> </div> <p><br> </p> <div dir="ltr" style="color:rgb(33,33,33)"> <hr tabindex="-1" style="display:inline-block; width:98%"> <div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> d.hatayama@fujitsu.com <d.hatayama@fujitsu.com><br> <b>Sent:</b> Tuesday, April 14, 2020 20:16<br> <b>To:</b> 赵乾利; Dave Anderson<br> <b>Cc:</b> Discussion list for crash utility usage, maintenance and development<br> <b>Subject:</b> Re: 答复: [External Mail]Re: [Crash-utility] zram decompress support for gcore/crash-utility</font> <div> </div> </div> <div> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"> Zhao,</div> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"> <br> </div> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"> I don't find latest patch for gcore command, but looking at the commit</div> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"> b12bdd36cf7caad24957c0b8c030001321ab2df4 in crash utility,</div> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"> try_zram_decompress() is called after uvtop() in the final design,</div> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"> not uvtop() being replaced by readmem(UVADDR), which can more easilly be</div> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"> into the gcore <span style="color:rgb(0,0,0); font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt">source code. Please send a new patch based on the latest</span></div> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"> <span style="color:rgb(0,0,0); font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt">design. </span><span style="color:rgb(0,0,0); font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt">It's very helpful if you share test set for this ZRAM support work.</span></div> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"> <br> </div> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"> Also, for the other independent aarch64 patch, as I already requested,</div> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"> please tell me the kernel commit that <span style="color:rgb(0,0,0); font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt">made the corresponding change</span></div> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"> <span style="color:rgb(0,0,0); font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt">on Aaarch64 </span><span style="color:rgb(0,0,0); font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt">kernel statck data structure, which I </span><span style="color:rgb(0,0,0); font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt">need it to check whether your</span></div> <div style=""><font color="#000000" face="Calibri, Arial, Helvetica, sans-serif"><span style="font-size:12pt">patch is correct or not and to file it for </span>maintenance<span style="font-size:12pt"> purpose.</span></font></div> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"> <br> </div> <div id="appendonsend"></div> <hr tabindex="-1" style="display:inline-block; width:98%"> <div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>差出人:</b> 赵乾利 <zhaoqianli@xiaomi.com><br> <b>送信日時:</b> 2020年4月13日 22:41<br> <b>宛先:</b> Dave Anderson <anderson@redhat.com><br> <b>CC:</b> Hatayama, Daisuke/畑山大輔 <d.hatayama@fujitsu.com>; Discussion list for crash utility usage, maintenance and development <crash-utility@redhat.com><br> <b>件名:</b> Re: 答复: [External Mail]Re: [Crash-utility] zram decompress support for gcore/crash-utility</font> <div> </div> </div> <div class="BodyFragment"><font size="2"><span style="font-size:11pt"> <div class="PlainText">Hi, hatayama<br> <br> May I ask about how the patch of support the zram in gcore?support in crash is ready.<br> Is there anything else I can do for you?<br> <br> ________________________________________<br> From: Dave Anderson <anderson@redhat.com><br> Sent: Monday, April 13, 2020 20:17<br> To: 赵乾利<br> Cc: d hatayama; Discussion list for crash utility usage, maintenance and development<br> Subject: Re: 答复: [External Mail]Re: [Crash-utility] zram decompress support for gcore/crash-utility<br> <br> ----- Original Message -----<br> ><br> > Make the mistake cause by patch update....<br> > please re-check the new patch<br> <br> In the interest of expediency, I went ahead and made a few cosmetic changes to<br> the comments and error message strings, and queued the patch for crash-7.2.9:<br> <br> <a href="https://github.com/crash-utility/crash/commit/b12bdd36cf7caad24957c0b8c030001321ab2df4"> https://github.com/crash-utility/crash/commit/b12bdd36cf7caad24957c0b8c030001321ab2df4</a><br> <br> Thanks,<br> Dave<br> <br> <br> > ________________________________________<br> > From: Dave Anderson <anderson@redhat.com><br> > Sent: Friday, April 10, 2020 22:57<br> > To: 赵乾利<br> > Cc: d hatayama; Discussion list for crash utility usage, maintenance and<br> > development<br> > Subject: Re: 答复: [External Mail]Re: [Crash-utility] zram decompress support<br> > for gcore/crash-utility<br> ><br> > ----- Original Message -----<br> > > I got little problem to compile 32-bit on my x86-64 host..<br> > > 96 /usr/bin/ld: skipping incompatible<br> > > /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a when searching for -lgcc<br> > > 97 /usr/bin/ld: cannot find -lgcc<br> > > 98 /usr/bin/ld: skipping incompatible<br> > > /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so when searching for -lgcc_s<br> > > 99 /usr/bin/ld: cannot find -lgcc_s<br> > ><br> > > I think i have fixed the build warning,but failed rebuild in 32-bit since<br> > > above error,please help confirm,and move log to try_zram_decompress,please<br> > > check the attachment.<br> ><br> > The patch now compiles OK, but my first simple test shows that something<br> > is obviously wrong with the patch.<br> ><br> > Here are a set of user-space addresses that have been swapped out to disk:<br> ><br> > crash> set 1<br> > PID: 1<br> > COMMAND: "systemd"<br> > TASK: ffff92a13a1e8000 [THREAD_INFO: ffff92a13a260000]<br> > CPU: 2<br> > STATE: TASK_INTERRUPTIBLE<br> > crash> vm -p | grep SWAP<br> > 55d917fb5000 SWAP: /dev/dm-2 OFFSET: 55827<br> > 55d917fb7000 SWAP: /dev/dm-2 OFFSET: 55828<br> > 55d917fc2000 SWAP: /dev/dm-2 OFFSET: 121359<br> > 55d917fc6000 SWAP: /dev/dm-2 OFFSET: 88579<br> > 55d917fcb000 SWAP: /dev/dm-2 OFFSET: 88581<br> > 55d917fcc000 SWAP: /dev/dm-2 OFFSET: 88582<br> > 55d917fcd000 SWAP: /dev/dm-2 OFFSET: 88583<br> > 55d917fce000 SWAP: /dev/dm-2 OFFSET: 104963<br> > 55d917fcf000 SWAP: /dev/dm-2 OFFSET: 104964<br> > ...<br> ><br> > Obviously any read of the addresses above should fail, but each<br> > read returns successfully, and each read is screwing up the internal<br> > buffering scheme:<br> ><br> > crash> rd -u 55d917fb5000<br> > 55d917fb5000: 0000000000000000 ........<br> > WARNING: malloc/free mismatch (53/54)<br> > crash> rd -u 55d917fb7000<br> > 55d917fb7000: 0000000000000000 ........<br> > WARNING: malloc/free mismatch (53/55)<br> > crash> rd -u 55d917fc2000<br> > 55d917fc2000: 0000000000000000 ........<br> > WARNING: malloc/free mismatch (53/56)<br> > crash> rd -u 55d917fc6000<br> > 55d917fc6000: 0000000000000000 ........<br> > WARNING: malloc/free mismatch (53/57)<br> > crash><br> ><br> > Dave<br> ><br> ><br> > #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！<br> > This e-mail and its attachments contain confidential information from<br> > XIAOMI, which is intended only for the person or entity whose address is<br> > listed above. Any use of the information contained herein in any way<br> > (including, but not limited to, total or partial disclosure, reproduction,<br> > or dissemination) by persons other than the intended recipient(s) is<br> > prohibited. If you receive this e-mail in error, please notify the sender by<br> > phone or email immediately and delete it!******/#<br> ><br> <br> #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#<br> </div> </span></font></div> </div> </div> #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/# </body> </html>