Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1351039 > unrolled thread
| Started by | David Miller <davem@davemloft.net> |
|---|---|
| First post | 2016-03-06 05:10 +0100 |
| Last post | 2016-03-07 23:40 +0100 |
| Articles | 13 on this page of 53 — 6 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) David Miller <davem@davemloft.net> - 2016-03-06 05:10 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 16:10 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Rob Gardner <rob.gardner@oracle.com> - 2016-03-07 16:40 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 16:50 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Andy Lutomirski <luto@amacapital.net> - 2016-03-07 16:50 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 17:10 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Dave Hansen <dave.hansen@linux.intel.com> - 2016-03-07 18:50 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Andy Lutomirski <luto@amacapital.net> - 2016-03-07 19:00 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Dave Hansen <dave.hansen@linux.intel.com> - 2016-03-07 19:20 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 19:50 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Andy Lutomirski <luto@amacapital.net> - 2016-03-07 20:00 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) David Miller <davem@davemloft.net> - 2016-03-07 20:30 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 20:50 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Dave Hansen <dave.hansen@linux.intel.com> - 2016-03-07 23:50 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Rob Gardner <rob.gardner@oracle.com> - 2016-03-08 02:40 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 22:10 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) David Miller <davem@davemloft.net> - 2016-03-08 21:00 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-08 21:20 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) David Miller <davem@davemloft.net> - 2016-03-08 21:30 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-08 22:10 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) David Miller <davem@davemloft.net> - 2016-03-07 17:50 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 19:00 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) David Miller <davem@davemloft.net> - 2016-03-07 18:00 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Andy Lutomirski <luto@amacapital.net> - 2016-03-07 19:10 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 19:30 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Andy Lutomirski <luto@amacapital.net> - 2016-03-07 20:00 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) David Miller <davem@davemloft.net> - 2016-03-07 20:30 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 20:50 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Andy Lutomirski <luto@amacapital.net> - 2016-03-07 21:00 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 21:50 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) David Miller <davem@davemloft.net> - 2016-03-07 22:00 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Andy Lutomirski <luto@amacapital.net> - 2016-03-07 22:10 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 22:20 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) James Morris <james.l.morris@oracle.com> - 2016-03-08 00:40 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) James Morris <james.l.morris@oracle.com> - 2016-03-08 01:00 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) James Morris <james.l.morris@oracle.com> - 2016-03-08 10:40 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 19:10 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Rob Gardner <rob.gardner@oracle.com> - 2016-03-07 19:20 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 19:30 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) David Miller <davem@davemloft.net> - 2016-03-07 20:20 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 22:40 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) David Miller <davem@davemloft.net> - 2016-03-07 22:40 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Rob Gardner <rob.gardner@oracle.com> - 2016-03-08 00:20 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) David Miller <davem@davemloft.net> - 2016-03-08 05:20 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Rob Gardner <rob.gardner@oracle.com> - 2016-03-08 00:20 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-08 00:30 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-08 01:30 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) David Miller <davem@davemloft.net> - 2016-03-08 05:30 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Rob Gardner <rob.gardner@oracle.com> - 2016-03-08 00:40 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) David Miller <davem@davemloft.net> - 2016-03-07 20:10 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 22:30 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) David Miller <davem@davemloft.net> - 2016-03-07 22:40 +0100
Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 23:40 +0100
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Khalid Aziz <khalid.aziz@oracle.com> |
|---|---|
| Date | 2016-03-07 22:40 +0100 |
| Message-ID | <rab2F-8kT-13@gated-at.bofh.it> |
| In reply to | #1351899 |
On 03/07/2016 12:16 PM, David Miller wrote: > From: Khalid Aziz <khalid.aziz@oracle.com> > Date: Mon, 7 Mar 2016 11:24:54 -0700 > >> Tags can be cleared by user by setting tag to 0. Tags are >> automatically cleared by the hardware when the mapping for a virtual >> address is removed from TSB (which is why swappable pages are a >> problem), so kernel does not have to do it as part of clean up. > > You might be able to crib some bits for the Tag in the swp_entry_t, it's > 64-bit and you can therefore steal bits from the offset field. > > That way you'll have the ADI tag in the page tables, ready to re-install > at swapin time. > That is a possibility but limited in scope. An address range covered by a single TTE can have large number of tags. Version tags are set on cacheline. In extreme case, one could set a tag for each set of 64-bytes in a page. Also tags are set completely in userspace and no transition occurs to kernel space, so kernel has no idea of what tags have been set. I have not found a way to query the MMU on tags. I will think some more about it. Thanks, Khalid
[toc] | [prev] | [next] | [standalone]
| From | David Miller <davem@davemloft.net> |
|---|---|
| Date | 2016-03-07 22:40 +0100 |
| Message-ID | <rab2G-8kT-15@gated-at.bofh.it> |
| In reply to | #1352004 |
From: Khalid Aziz <khalid.aziz@oracle.com> Date: Mon, 7 Mar 2016 14:33:56 -0700 > On 03/07/2016 12:16 PM, David Miller wrote: >> From: Khalid Aziz <khalid.aziz@oracle.com> >> Date: Mon, 7 Mar 2016 11:24:54 -0700 >> >>> Tags can be cleared by user by setting tag to 0. Tags are >>> automatically cleared by the hardware when the mapping for a virtual >>> address is removed from TSB (which is why swappable pages are a >>> problem), so kernel does not have to do it as part of clean up. >> >> You might be able to crib some bits for the Tag in the swp_entry_t, >> it's >> 64-bit and you can therefore steal bits from the offset field. >> >> That way you'll have the ADI tag in the page tables, ready to >> re-install >> at swapin time. >> > > That is a possibility but limited in scope. An address range covered > by a single TTE can have large number of tags. Version tags are set on > cacheline. In extreme case, one could set a tag for each set of > 64-bytes in a page. Also tags are set completely in userspace and no > transition occurs to kernel space, so kernel has no idea of what tags > have been set. I have not found a way to query the MMU on tags. > > I will think some more about it. That would mean that ADI is impossible to use for swappable memory. ... If that's true I'm extremely disappointed that they devoted so much silicon and engineering to this feature yet didn't take that one critical step to make it generally useful. :( We could have a way to do this via the kernel, wherein the user has a contract with us. Basically we have a call to pass the Tags (what granularity to use for this is a design point, pages, cache lines, etc.) into the kernel and the user agrees not to change them behind the kernel's back. In return the kernel agrees to restore the tags upon swapin. So we could support something for swappable pages, it would just be more work.
[toc] | [prev] | [next] | [standalone]
| From | Rob Gardner <rob.gardner@oracle.com> |
|---|---|
| Date | 2016-03-08 00:20 +0100 |
| Message-ID | <racBt-YH-43@gated-at.bofh.it> |
| In reply to | #1352005 |
On 03/07/2016 01:38 PM, David Miller wrote: > From: Khalid Aziz <khalid.aziz@oracle.com> > Date: Mon, 7 Mar 2016 14:33:56 -0700 > >> On 03/07/2016 12:16 PM, David Miller wrote: >>> From: Khalid Aziz <khalid.aziz@oracle.com> >>> Date: Mon, 7 Mar 2016 11:24:54 -0700 >>> >>>> Tags can be cleared by user by setting tag to 0. Tags are >>>> automatically cleared by the hardware when the mapping for a virtual >>>> address is removed from TSB (which is why swappable pages are a >>>> problem), so kernel does not have to do it as part of clean up. >>> You might be able to crib some bits for the Tag in the swp_entry_t, >>> it's >>> 64-bit and you can therefore steal bits from the offset field. >>> >>> That way you'll have the ADI tag in the page tables, ready to >>> re-install >>> at swapin time. >>> >> That is a possibility but limited in scope. An address range covered >> by a single TTE can have large number of tags. Version tags are set on >> cacheline. In extreme case, one could set a tag for each set of >> 64-bytes in a page. Also tags are set completely in userspace and no >> transition occurs to kernel space, so kernel has no idea of what tags >> have been set. I have not found a way to query the MMU on tags. >> >> I will think some more about it. > That would mean that ADI is impossible to use for swappable memory. > > ... > > If that's true I'm extremely disappointed that they devoted so much > silicon and engineering to this feature yet didn't take that one > critical step to make it generally useful. :( You can easily read ADI tags with a simple ldxa #ASI_MCD_PRIMARY instruction. Rob
[toc] | [prev] | [next] | [standalone]
| From | David Miller <davem@davemloft.net> |
|---|---|
| Date | 2016-03-08 05:20 +0100 |
| Message-ID | <rahhL-4cv-11@gated-at.bofh.it> |
| In reply to | #1352138 |
From: Rob Gardner <rob.gardner@oracle.com> Date: Mon, 7 Mar 2016 15:13:31 -0800 > You can easily read ADI tags with a simple ldxa #ASI_MCD_PRIMARY > instruction. Awesome!
[toc] | [prev] | [next] | [standalone]
| From | Rob Gardner <rob.gardner@oracle.com> |
|---|---|
| Date | 2016-03-08 00:20 +0100 |
| Message-ID | <racBs-YH-1@gated-at.bofh.it> |
| In reply to | #1352004 |
On 03/07/2016 01:33 PM, Khalid Aziz wrote: > > That is a possibility but limited in scope. An address range covered > by a single TTE can have large number of tags. Version tags are set on > cacheline. In extreme case, one could set a tag for each set of > 64-bytes in a page. Also tags are set completely in userspace and no > transition occurs to kernel space, so kernel has no idea of what tags > have been set. ... > I have not found a way to query the MMU on tags. > To query the tag for a cache line, you just read it back with ldxa and ASI_MCD_PRIMARY (ie, asi 0x90), basically the same way you stored the tag in the first place. Rob
[toc] | [prev] | [next] | [standalone]
| From | Khalid Aziz <khalid.aziz@oracle.com> |
|---|---|
| Date | 2016-03-08 00:30 +0100 |
| Message-ID | <racLa-13y-47@gated-at.bofh.it> |
| In reply to | #1352120 |
On 03/07/2016 04:12 PM, Rob Gardner wrote: > On 03/07/2016 01:33 PM, Khalid Aziz wrote: >> >> That is a possibility but limited in scope. An address range covered >> by a single TTE can have large number of tags. Version tags are set on >> cacheline. In extreme case, one could set a tag for each set of >> 64-bytes in a page. Also tags are set completely in userspace and no >> transition occurs to kernel space, so kernel has no idea of what tags >> have been set. > > ... >> I have not found a way to query the MMU on tags. >> > > To query the tag for a cache line, you just read it back with ldxa and > ASI_MCD_PRIMARY (ie, asi 0x90), basically the same way you stored the > tag in the first place. > Thanks, Rob. I just saw it while reading through the manual. -- Khalid
[toc] | [prev] | [next] | [standalone]
| From | Khalid Aziz <khalid.aziz@oracle.com> |
|---|---|
| Date | 2016-03-08 01:30 +0100 |
| Message-ID | <radHf-1Il-57@gated-at.bofh.it> |
| In reply to | #1351899 |
On 03/07/2016 12:16 PM, David Miller wrote: > From: Khalid Aziz <khalid.aziz@oracle.com> > Date: Mon, 7 Mar 2016 11:24:54 -0700 > >> Tags can be cleared by user by setting tag to 0. Tags are >> automatically cleared by the hardware when the mapping for a virtual >> address is removed from TSB (which is why swappable pages are a >> problem), so kernel does not have to do it as part of clean up. > > You might be able to crib some bits for the Tag in the swp_entry_t, it's > 64-bit and you can therefore steal bits from the offset field. > > That way you'll have the ADI tag in the page tables, ready to re-install > at swapin time. > Hi Dave, Can we enable ADI support for swappable pages in a subsequent update after the core functionality is stable on mlock'd pages? Thanks, Khalid
[toc] | [prev] | [next] | [standalone]
| From | David Miller <davem@davemloft.net> |
|---|---|
| Date | 2016-03-08 05:30 +0100 |
| Message-ID | <rahrs-4gU-17@gated-at.bofh.it> |
| In reply to | #1352419 |
From: Khalid Aziz <khalid.aziz@oracle.com> Date: Mon, 7 Mar 2016 17:21:05 -0700 > Can we enable ADI support for swappable pages in a subsequent update > after the core functionality is stable on mlock'd pages? I already said no.
[toc] | [prev] | [next] | [standalone]
| From | Rob Gardner <rob.gardner@oracle.com> |
|---|---|
| Date | 2016-03-08 00:40 +0100 |
| Message-ID | <racUP-18J-63@gated-at.bofh.it> |
| In reply to | #1351862 |
On 03/07/2016 10:24 AM, Khalid Aziz wrote: > > Tags can be cleared by user by setting tag to 0. Tags are > automatically cleared by the hardware when the mapping for a virtual > address is removed from TSB (which is why swappable pages are a > problem), so kernel does not have to do it as part of clean up. > I don't understand this. The hardware isn't involved when a mapping for a virtual address is removed from the TSB, so how could it automatically clear tags? Rob
[toc] | [prev] | [next] | [standalone]
| From | David Miller <davem@davemloft.net> |
|---|---|
| Date | 2016-03-07 20:10 +0100 |
| Message-ID | <ra8Hw-6WP-5@gated-at.bofh.it> |
| In reply to | #1351849 |
From: Khalid Aziz <khalid.aziz@oracle.com> Date: Mon, 7 Mar 2016 11:04:38 -0700 > On 03/07/2016 09:56 AM, David Miller wrote: >> From: Khalid Aziz <khalid.aziz@oracle.com> >> Date: Mon, 7 Mar 2016 08:07:53 -0700 >> >>> PR_GET_SPARC_ADICAPS >> >> Put this into a new ELF auxiliary vector entry via ARCH_DLINFO. >> >> So now all that's left is supposedly the TAG stuff, please explain >> that to me so I can direct you to the correct existing interface to >> provide that as well. >> >> Really, try to avoid prtctl, it's poorly typed and almost worse than >> ioctl(). >> > > The two remaining operations I am looking at are: > > 1. Is PSTATE.mcde bit set for the process? PR_SET_SPARC_ADI provides > this in its return value in the patch I sent. Unnecessary. If any ADI mappings exist then mcde is set, otherwise it is clear. This is internal state and the application has no need to every set nor query it. It is implicit from the mprotect() calls the user makes to enable ADI regions. > 2. Is TTE.mcd set for a given virtual address? PR_GET_SPARC_ADI_STATUS > provides this function in the patch I sent. Again, implied by the mprotect() calls.
[toc] | [prev] | [next] | [standalone]
| From | Khalid Aziz <khalid.aziz@oracle.com> |
|---|---|
| Date | 2016-03-07 22:30 +0100 |
| Message-ID | <raaT0-8gx-3@gated-at.bofh.it> |
| In reply to | #1351892 |
On 03/07/2016 12:09 PM, David Miller wrote: > From: Khalid Aziz <khalid.aziz@oracle.com> > Date: Mon, 7 Mar 2016 11:04:38 -0700 > >> On 03/07/2016 09:56 AM, David Miller wrote: >>> From: Khalid Aziz <khalid.aziz@oracle.com> >>> Date: Mon, 7 Mar 2016 08:07:53 -0700 >>> >>>> PR_GET_SPARC_ADICAPS >>> >>> Put this into a new ELF auxiliary vector entry via ARCH_DLINFO. >>> >>> So now all that's left is supposedly the TAG stuff, please explain >>> that to me so I can direct you to the correct existing interface to >>> provide that as well. >>> >>> Really, try to avoid prtctl, it's poorly typed and almost worse than >>> ioctl(). >>> >> >> The two remaining operations I am looking at are: >> >> 1. Is PSTATE.mcde bit set for the process? PR_SET_SPARC_ADI provides >> this in its return value in the patch I sent. > > Unnecessary. If any ADI mappings exist then mcde is set, otherwise it is > clear. This is internal state and the application has no need to every > set nor query it. > > It is implicit from the mprotect() calls the user makes to enable ADI > regions. > >> 2. Is TTE.mcd set for a given virtual address? PR_GET_SPARC_ADI_STATUS >> provides this function in the patch I sent. > > Again, implied by the mprotect() calls. > Hi Dave, I agree with your point of view. PSTATE.mcde and TTE.mcd are set in response to request from userspace. If userspace asked for them to be set, they already know but it was the database guys that asked for these two functions and they are the primary customers for the ADI feature. I am not crazy about this idea since this extends the mprotect API even further but would you consider using the return value from mprotect to indicate if PSTATE.mcde or TTE.mcd were already set on the given address? Thanks, Khalid
[toc] | [prev] | [next] | [standalone]
| From | David Miller <davem@davemloft.net> |
|---|---|
| Date | 2016-03-07 22:40 +0100 |
| Message-ID | <rab2F-8kT-5@gated-at.bofh.it> |
| In reply to | #1351997 |
From: Khalid Aziz <khalid.aziz@oracle.com> Date: Mon, 7 Mar 2016 14:27:09 -0700 > I agree with your point of view. PSTATE.mcde and TTE.mcd are set in > response to request from userspace. If userspace asked for them to be > set, they already know but it was the database guys that asked for > these two functions and they are the primary customers for the ADI > feature. I am not crazy about this idea since this extends the > mprotect API even further but would you consider using the return > value from mprotect to indicate if PSTATE.mcde or TTE.mcd were already > set on the given address? Well, that's the idea. If the mprotect using MAP_ADI or whatever succeeds, then ADI is enabled. Users can thus also pass MAP_ADI as a flag to mmap() to get ADI protection from the very beginning.
[toc] | [prev] | [next] | [standalone]
| From | Khalid Aziz <khalid.aziz@oracle.com> |
|---|---|
| Date | 2016-03-07 23:40 +0100 |
| Message-ID | <rabYK-uQ-19@gated-at.bofh.it> |
| In reply to | #1352000 |
On 03/07/2016 02:34 PM, David Miller wrote: > From: Khalid Aziz <khalid.aziz@oracle.com> > Date: Mon, 7 Mar 2016 14:27:09 -0700 > >> I agree with your point of view. PSTATE.mcde and TTE.mcd are set in >> response to request from userspace. If userspace asked for them to be >> set, they already know but it was the database guys that asked for >> these two functions and they are the primary customers for the ADI >> feature. I am not crazy about this idea since this extends the >> mprotect API even further but would you consider using the return >> value from mprotect to indicate if PSTATE.mcde or TTE.mcd were already >> set on the given address? > > Well, that's the idea. > > If the mprotect using MAP_ADI or whatever succeeds, then ADI is > enabled. > > Users can thus also pass MAP_ADI as a flag to mmap() to get ADI > protection from the very beginning. > MAP_ADI has been sitting in my backlog for some time. Looks like you just raised its priority ;) -- Khalid
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | linux.kernel
csiph-web