On Fri, 2013-10-11 at 16:49 +1100, Ryan Mallon wrote:
> It doesn't matter what the value of kptr_restrict happens to be, the
> code is still broken. So, with your patch, values 0 and 2 of
> kptr_restrict will print a seemingly correct value, but when
> kptr_restrict is 1 then it will print 'pK-err
On 11/10/13 16:38, Joe Perches wrote:
> On Fri, 2013-10-11 at 16:31 +1100, Ryan Mallon wrote:
>> On 11/10/13 16:25, Joe Perches wrote:
>>> Printing kernel pointers via %pK has a minor defect when
>>> kptr_restrict is set to 2: the pointer may be emitted
>>> as "pK-error" instead of all 0's when in
On Fri, 2013-10-11 at 16:31 +1100, Ryan Mallon wrote:
> On 11/10/13 16:25, Joe Perches wrote:
> > Printing kernel pointers via %pK has a minor defect when
> > kptr_restrict is set to 2: the pointer may be emitted
> > as "pK-error" instead of all 0's when in an interrupt.
>
> NAK. This is not a de
On 11/10/13 16:25, Joe Perches wrote:
> Printing kernel pointers via %pK has a minor defect when
> kptr_restrict is set to 2: the pointer may be emitted
> as "pK-error" instead of all 0's when in an interrupt.
NAK. This is not a defect, as I explained earlier. It is really a defect
that it _doesn
Printing kernel pointers via %pK has a minor defect when
kptr_restrict is set to 2: the pointer may be emitted
as "pK-error" instead of all 0's when in an interrupt.
Fix this defect, neaten the code, and correct the sysctl
documentation.
Add missing documentation for 2 other uses: %pNF and %pV.
5 matches
Mail list logo