Hello,
On Tue, August 23, 2011 20:04, Al Viro wrote:
> On Tue, Aug 23, 2011 at 06:33:17PM +0100, Al Viro wrote:
>> * SYSCALL is not terminally broken wrt restarts. My apologies for
>> misreading what was going on.
>> * SYSENTER with Linus' patch does work just fine wrt restarts + ptrace
Am 23.08.2011 19:07, schrieb Al Viro:
On Tue, Aug 23, 2011 at 06:58:18PM +0200, Richard Weinberger wrote:
What about this hack/solution?
While booting UML can check whether the host's vDSO contains
a SYSCALL instruction.
If so, UML will not make the host's vDSO available to it's
processes...
On 08/23/2011 02:10 PM, Borislav Petkov wrote:
> On Tue, Aug 23, 2011 at 05:06:03PM -0400, H. Peter Anvin wrote:
>> On 08/23/2011 01:56 PM, Borislav Petkov wrote:
>>>
>>> But no, I don't think the difference has disappeared - to the contrary,
>>> AFAICT, the intention is for SYSCALL to be the faste
On 08/23/2011 02:10 PM, Borislav Petkov wrote:
> On Tue, Aug 23, 2011 at 05:06:03PM -0400, H. Peter Anvin wrote:
>> On 08/23/2011 01:56 PM, Borislav Petkov wrote:
>>>
>>> But no, I don't think the difference has disappeared - to the contrary,
>>> AFAICT, the intention is for SYSCALL to be the faste
On 08/23/2011 02:20 PM, Linus Torvalds wrote:
> On Tue, Aug 23, 2011 at 2:08 PM, H. Peter Anvin wrote:
>>
>> Again, can we steal one of the padding fields to use for that state
>> variable? We have two 16-bit padding fields; one for cs and one for ss.
>
> We can steal them for passing the inform
On Tue, Aug 23, 2011 at 05:06:03PM -0400, H. Peter Anvin wrote:
> On 08/23/2011 01:56 PM, Borislav Petkov wrote:
> >
> > But no, I don't think the difference has disappeared - to the contrary,
> > AFAICT, the intention is for SYSCALL to be the fastest way to do
> > syscalls on x86 due to diminishe
On Tue, Aug 23, 2011 at 03:15:58PM -0400, H. Peter Anvin wrote:
> Right, but if you had said the difference had disappeared on current AMD
> silicon it would be much less of an issue. That's why I wanted to find
> that bit out from you.
Yeah, I dug this out in the APM, btw.
But no, I don't think
On Tue, Aug 23, 2011 at 2:08 PM, H. Peter Anvin wrote:
>
> Again, can we steal one of the padding fields to use for that state
> variable? We have two 16-bit padding fields; one for cs and one for ss.
We can steal them for passing the information to the user, but no, I
don't think we can use the
On Tue, Aug 23, 2011 at 12:43:28PM -0700, Linus Torvalds wrote:
> On Tue, Aug 23, 2011 at 12:41 PM, Al Viro wrote:
> >
> > And it's not cheap - doing that on each syscall will be unpleasant...
> > Frankly, I'd rather stopped telling the uml userland about vdso in such
> > setups. ?And anything tha
On 08/23/2011 10:33 AM, Linus Torvalds wrote:
>
> It would be *nice* if we did the swizzling automatically at setregs()
> time too, but we simply don't have enough information in the kernel to
> do that. Again, exactly because pt_regs doesn't have a "state"
> variable, when user-space does the SET
On 08/23/2011 01:56 PM, Borislav Petkov wrote:
>
> But no, I don't think the difference has disappeared - to the contrary,
> AFAICT, the intention is for SYSCALL to be the fastest way to do
> syscalls on x86 due to diminished number of segment checks etc. INT80
> is legacy, slower, etc. I believe
On Tue, Aug 23, 2011 at 12:41 PM, Al Viro wrote:
>
> And it's not cheap - doing that on each syscall will be unpleasant...
> Frankly, I'd rather stopped telling the uml userland about vdso in such
> setups. And anything that plays with SYSCALL outside of vdso...
> we already have a "don't run it
On Tue, Aug 23, 2011 at 12:24:22PM -0700, Linus Torvalds wrote:
> On Tue, Aug 23, 2011 at 12:18 PM, H. Peter Anvin wrote:
> >
> > We could drop that information in a metaregister. ?It's not backward
> > compatible, but at least it will be obvious when that information is
> > available and not.
>
On 08/23/2011 12:24 PM, Linus Torvalds wrote:
> On Tue, Aug 23, 2011 at 12:18 PM, H. Peter Anvin wrote:
>>
>> We could drop that information in a metaregister. It's not backward
>> compatible, but at least it will be obvious when that information is
>> available and not.
>
> Well, seriously, UML
On Tue, Aug 23, 2011 at 12:18 PM, H. Peter Anvin wrote:
>
> We could drop that information in a metaregister. It's not backward
> compatible, but at least it will be obvious when that information is
> available and not.
Well, seriously, UML already looks at the word at "ip-2" for other
reasons.
On 08/23/2011 09:48 AM, Al Viro wrote:
>
> Um... How would it know which syscall variant had that been, to start
> with? For int 0x80 it would need to use registers as-is. For SYSENTER
> it also could use them as-is - ebp will differ from what we put there
> when entering the sucker, but not cr
On 08/23/2011 09:22 AM, Borislav Petkov wrote:
> On Tue, Aug 23, 2011 at 12:11:43PM -0400, Andrew Lutomirski wrote:
>> In any case, this seems insanely overcomplicated. I'd be less afraid
>> of something like my approach (which, I think, makes all of the
>> SYSCALL weirdness pretty much transparen
On Tue, Aug 23, 2011 at 12:11:43PM -0400, Andrew Lutomirski wrote:
> In any case, this seems insanely overcomplicated. I'd be less afraid
> of something like my approach (which, I think, makes all of the
> SYSCALL weirdness pretty much transparent to ptrace users) or of just
> removing SYSCALL ent
On Tue, Aug 23, 2011 at 06:33:17PM +0100, Al Viro wrote:
> * SYSCALL is not terminally broken wrt restarts. My apologies for
> misreading what was going on.
> * SYSENTER with Linus' patch does work just fine wrt restarts + ptrace
> * SYSCALL is losing ptrace-made changes to argum
On Tue, Aug 23, 2011 at 9:48 AM, Al Viro wrote:
>
> Um... How would it know which syscall variant had that been, to start
> with?
Just read the instruction, for chissake.
UML *already* does that, to see if it's "int80" or "sysenter" ('is_syscall()').
Now, I do agree that if we had designed the
On Tue, Aug 23, 2011 at 09:20:12AM -0700, Linus Torvalds wrote:
> It's EMULATING A SYSTEM CALL. That original "getregs" value is not
> some "user space state". It's the *system call* state that you got
> after the system call trapped. Setting it back is an insane operation,
> but it would happen t
Am 23.08.2011 19:07, schrieb Al Viro:
> On Tue, Aug 23, 2011 at 06:58:18PM +0200, Richard Weinberger wrote:
>
>> What about this hack/solution?
>> While booting UML can check whether the host's vDSO contains
>> a SYSCALL instruction.
>> If so, UML will not make the host's vDSO available to it's
>>
On Tue, Aug 23, 2011 at 06:58:18PM +0200, Richard Weinberger wrote:
> What about this hack/solution?
> While booting UML can check whether the host's vDSO contains
> a SYSCALL instruction.
> If so, UML will not make the host's vDSO available to it's
> processes...
Note that this is *only* for 32b
Am 23.08.2011 18:53, schrieb Al Viro:
> On Tue, Aug 23, 2011 at 09:29:29AM -0700, Linus Torvalds wrote:
>
>> Oh yes.
>>
>> System call performance is *important*. And x86 is *important*.
>>
>> UML? In comparison, not that important.
>>
>> So quite frankly, if this is purely an UML issue (and unless
On Tue, Aug 23, 2011 at 09:29:29AM -0700, Linus Torvalds wrote:
> Oh yes.
>
> System call performance is *important*. And x86 is *important*.
>
> UML? In comparison, not that important.
>
> So quite frankly, if this is purely an UML issue (and unless we're
> missing something else, that's what
On Tue, Aug 23, 2011 at 09:03:04AM -0700, Linus Torvalds wrote:
> Suggested fixes:
>
> - instead of blindly doing SETREGS, just write the result registers
> individually like you suggested
Not enough. There is also a PITA with signal handlers. There we can't
avoid modifying ebp on the way out
On Tue, Aug 23, 2011 at 04:26:08PM +0200, Borislav Petkov wrote:
> On Tue, Aug 23, 2011 at 02:15:31AM -0400, Al Viro wrote:
> > Almost, but not quite. What happens is:
> > * process hits syscall insn
> > * it's stopped and tracer (guest kernel) does GETREGS
> > + looks at the registers (mapped
On Tue, Aug 23, 2011 at 9:22 AM, Borislav Petkov wrote:
>
> I don't think that removing SYSCALL from 32-bit code just so that UML
> trapped syscalls work is something we'd like since SYSCALL is much
> cheaper than INT $0x80:
Oh yes.
System call performance is *important*. And x86 is *important*.
On Tue, Aug 23, 2011 at 9:11 AM, Andrew Lutomirski wrote:
>
> Egads. Does this mean that doing GETREGS and then doing SETREGS later
> on with the *exact same values* is considered incorrect?
No. If it does it with exactly the same values, it's perfectly ok. But
it isn't. It's changing some of th
On Tue, Aug 23, 2011 at 02:15:31AM -0400, Al Viro wrote:
> Almost, but not quite. What happens is:
> * process hits syscall insn
> * it's stopped and tracer (guest kernel) does GETREGS
> + looks at the registers (mapped to the normal layout)
> + decides to call sys_brk()
> + noti
On Tue, Aug 23, 2011 at 12:03 PM, Linus Torvalds
wrote:
> On Mon, Aug 22, 2011 at 11:15 PM, Al Viro wrote:
>>
>> * it does SETREGS, setting eax to return value, eip to original return
>> address of syscall insn... and ebp to what it had in regs.bp. I.e. the
>> damn arg6 value.
>
> Ok, I think th
On Mon, Aug 22, 2011 at 11:15 PM, Al Viro wrote:
>
> * it does SETREGS, setting eax to return value, eip to original return
> address of syscall insn... and ebp to what it had in regs.bp. I.e. the
> damn arg6 value.
Ok, I think that exhaustively explains that
(a) our system call restart has al
On Tue, Aug 23, 2011 at 03:17:18AM +0100, Al Viro wrote:
> I have a very strong suspicion that I know what will turn out to be involved
> into that - the page eviction done by sys_brk(). Note that dirtying this
> sucker is really necessary - without *s = 0 it won't segfault at all. With
> it we
On 08/22/2011 01:03 AM, H. Peter Anvin wrote:
> On 08/21/2011 09:26 PM, Al Viro wrote:
>> On Sun, Aug 21, 2011 at 09:11:54PM -0700, H. Peter Anvin wrote:
lack of point - the *only* CPU where it would matter would be K6-2, IIRC,
and (again, IIRC) it had some differences in SYSCALL semantic
On Mon, Aug 22, 2011 at 06:59:48PM -0700, Linus Torvalds wrote:
> And the system call restart should actually work fine too, because at
> syscall entry we save %ebp *both* in the slot for ebp and ecx when we
> enter the first time. So the second time, we'll re-load the third
> argument from ebp ag
On Tue, Aug 23, 2011 at 02:13:12AM +0100, Al Viro wrote:
> *UGH*. OK,
> 1) I'm an idiot; int_ret_from_sys_call does *not* usually step on
> rbp (it's callee-saved). So normally ebp is left as is on the way out,
> which is why we don't see stuff getting buggered left, right and center.
>
On Mon, Aug 22, 2011 at 6:13 PM, Al Viro wrote:
>
> *UGH*. OK,
> 1) I'm an idiot; int_ret_from_sys_call does *not* usually step on
> rbp (it's callee-saved). So normally ebp is left as is on the way out,
> which is why we don't see stuff getting buggered left, right and center.
Check.
A
On 08/22/2011 06:16 PM, Andrew Lutomirski wrote:
>
> I suspect that very few things care whether syscall arguments get
> clobbered. The only way it would matter is if gcc reuses the argument
> in the ecx slot after an inlined syscall later in the same function.
> Any code that does that is alrea
On Aug 22, 2011 9:01 PM, "Al Viro" wrote:
>
> On Mon, Aug 22, 2011 at 05:22:07PM -0700, Linus Torvalds wrote:
>
> > You guys seem to positively _want_ to make this a bigger issue than it
> > is. As far as I can tell, nobody has ever even noticed this problem
> > before, and we already have a trivi
On Tue, Aug 23, 2011 at 02:01:46AM +0100, Al Viro wrote:
> now, what is going to happen to %ebp if we go through IRET path, for any
> reason? From my reading it appears that right after that IRET we'll have
> ebp containing arg6. I.e. what we'd pushed on stack. Now, popl %ebp
> will bring the s
On Mon, Aug 22, 2011 at 05:22:07PM -0700, Linus Torvalds wrote:
> You guys seem to positively _want_ to make this a bigger issue than it
> is. As far as I can tell, nobody has ever even noticed this problem
> before, and we already have a trivial fix ("don't do it then") for the
> case Al actually
On Mon, Aug 22, 2011 at 5:07 PM, H. Peter Anvin wrote:
>
> Checking for SYSCALL in the vdso is cheap... the only problem is if
> someone thinks that they can copy it out of the vdso and run it, having
> special-cased SYSENTER already, but not SYSCALL. The recent experience
> shows that that is ap
On 08/22/2011 05:03 PM, Al Viro wrote:
> On Mon, Aug 22, 2011 at 04:27:51PM -0700, Linus Torvalds wrote:
>
>> So I think the "let's fix the vdso case for sysenter" + "let's remove
>> the 32-bit syscall vdso" is the right solution. If somebody has
>> hardcoded syscall instructions, or generates the
On Tue, Aug 23, 2011 at 01:03:14AM +0100, Al Viro wrote:
> On Mon, Aug 22, 2011 at 04:27:51PM -0700, Linus Torvalds wrote:
>
> > So I think the "let's fix the vdso case for sysenter" + "let's remove
> > the 32-bit syscall vdso" is the right solution. If somebody has
> > hardcoded syscall instructi
On Mon, Aug 22, 2011 at 04:27:51PM -0700, Linus Torvalds wrote:
> So I think the "let's fix the vdso case for sysenter" + "let's remove
> the 32-bit syscall vdso" is the right solution. If somebody has
> hardcoded syscall instructions, or generates them dynamically with
> some JIT, that's their pr
On 08/22/2011 04:27 PM, Linus Torvalds wrote:
> On Mon, Aug 22, 2011 at 3:04 PM, H. Peter Anvin wrote:
>>
>> However, we could just issue a SIGILL or SIGSEGV at this point; the same
>> way we would if we got an #UD or #GP fault; SIGILL/#UD would be
>> consistent with Intel CPUs here.
>
> Consider
On Mon, Aug 22, 2011 at 3:04 PM, H. Peter Anvin wrote:
>
> However, we could just issue a SIGILL or SIGSEGV at this point; the same
> way we would if we got an #UD or #GP fault; SIGILL/#UD would be
> consistent with Intel CPUs here.
Considering that this is not a remotely new issue, and that it h
On 08/22/2011 02:52 PM, Andrew Lutomirski wrote:
>
> Even if it's ok, we still have to do *something* in the cstar entry
> point -- I don't think there's any way to turn SYSCALL in
> compatibility mode but leave it enabled in long mode. So if we're
> planning on killing off SYSCALL from outside t
On Mon, Aug 22, 2011 at 4:11 PM, H. Peter Anvin wrote:
> On 08/22/2011 01:05 PM, Linus Torvalds wrote:
>> On Mon, Aug 22, 2011 at 8:13 AM, Al Viro wrote:
>>>
>>> In __kernel_vsyscall() the problem is possible to deal with; there we
>>> control
>>> the code around that sucker. It's SYSCALL in 32
On 08/22/2011 01:05 PM, Linus Torvalds wrote:
> On Mon, Aug 22, 2011 at 8:13 AM, Al Viro wrote:
>>
>> In __kernel_vsyscall() the problem is possible to deal with; there we control
>> the code around that sucker. It's SYSCALL in 32bit binary outside of
>> vdso32 that causes real PITA...
>
> I jus
On Mon, Aug 22, 2011 at 8:13 AM, Al Viro wrote:
>
> In __kernel_vsyscall() the problem is possible to deal with; there we control
> the code around that sucker. It's SYSCALL in 32bit binary outside of
> vdso32 that causes real PITA...
I just checked. 'syscall' (at least on x86-64) is definitely
On Mon, Aug 22, 2011 at 09:34:27AM -0400, Andrew Lutomirski wrote:
> On Mon, Aug 22, 2011 at 5:53 AM, Ingo Molnar wrote:
> >
> > * H. Peter Anvin wrote:
> >
> >> Borislav,
> >>
> >> We're tracking down an issue with the way system call arguments are
> >> handled on 32 bits. We have a solution fo
On Mon, Aug 22, 2011 at 04:40:51PM +0200, Borislav Petkov wrote:
> Just to make sure I'm grokking this correctly - we want to use int $0x80
> only for the SYSCALL variant in __kernel_vsyscall, right? Not for all
> 32-bit syscalls on a 64-bit kernel.
Um... The problem is, syscall restart with SYS
On Mon, Aug 22, 2011 at 5:53 AM, Ingo Molnar wrote:
>
> * H. Peter Anvin wrote:
>
>> Borislav,
>>
>> We're tracking down an issue with the way system call arguments are
>> handled on 32 bits. We have a solution for SYSENTER but not
>> SYSCALL; fixing SYSCALL "properly" appears to be very difficu
* H. Peter Anvin wrote:
> Borislav,
>
> We're tracking down an issue with the way system call arguments are
> handled on 32 bits. We have a solution for SYSENTER but not
> SYSCALL; fixing SYSCALL "properly" appears to be very difficult at
> best.
>
> So the question is: how much overhead w
On 08/21/2011 09:26 PM, Al Viro wrote:
> On Sun, Aug 21, 2011 at 09:11:54PM -0700, H. Peter Anvin wrote:
>>> lack of point - the *only* CPU where it would matter would be K6-2, IIRC,
>>> and (again, IIRC) it had some differences in SYSCALL semantics compared to
>>> K7 (which supports SYSENTER as we
On Sun, Aug 21, 2011 at 09:11:54PM -0700, H. Peter Anvin wrote:
> > lack of point - the *only* CPU where it would matter would be K6-2, IIRC,
> > and (again, IIRC) it had some differences in SYSCALL semantics compared to
> > K7 (which supports SYSENTER as well). Bugger if I remember what those
> >
On 08/21/2011 09:07 PM, Al Viro wrote:
> On Sun, Aug 21, 2011 at 06:41:16PM -0700, Linus Torvalds wrote:
>> On Sun, Aug 21, 2011 at 6:16 PM, Al Viro wrote:
>>>
>>> Is that ability a part of userland ABI or are we declaring that hopelessly
>>> wrong and require to go through the function in vdso32?
On Sun, Aug 21, 2011 at 06:41:16PM -0700, Linus Torvalds wrote:
> On Sun, Aug 21, 2011 at 6:16 PM, Al Viro wrote:
> >
> > Is that ability a part of userland ABI or are we declaring that hopelessly
> > wrong and require to go through the function in vdso32? ?Linus?
>
> If people are using syscall
Borislav,
We're tracking down an issue with the way system call arguments are
handled on 32 bits. We have a solution for SYSENTER but not SYSCALL;
fixing SYSCALL "properly" appears to be very difficult at best.
So the question is: how much overhead would it be to simply fall back to
int $0x80 or
On 08/21/2011 07:26 PM, Andrew Lutomirski wrote:
>
> Which still leaves the question of how to fix it. Restarting via an
> int 0x80-based helper might be the only option that leaves everything
> fully functional.
>
The issue is that we don't represent the entire state ... we represent
only one
On Sun, Aug 21, 2011 at 10:07 PM, Al Viro wrote:
> On Sun, Aug 21, 2011 at 10:01:40PM -0400, Andrew Lutomirski wrote:
>
>> 3. We're worried that pt_regs-using compat syscalls might want the
>> regs to appear to match the actual arguments (why?)
>
> run strace and you'll see why.
>
I'm talking ab
On Sun, Aug 21, 2011 at 10:01:40PM -0400, Andrew Lutomirski wrote:
> 3. We're worried that pt_regs-using compat syscalls might want the
> regs to appear to match the actual arguments (why?)
run strace and you'll see why.
> 4. ptrace expects the "registers" when SYSCALL happens to match the
> i
On Sun, Aug 21, 2011 at 9:48 PM, H. Peter Anvin wrote:
> On 08/21/2011 06:41 PM, Linus Torvalds wrote:
>> If people are using syscall directly, we're pretty much stuck. No
>> amount of "that's hopelessly wrong" will ever matter. We don't break
>> existing binaries.
>>
>> That said, I'd *hope* that
On 08/21/2011 06:41 PM, Linus Torvalds wrote:
> If people are using syscall directly, we're pretty much stuck. No
> amount of "that's hopelessly wrong" will ever matter. We don't break
> existing binaries.
>
> That said, I'd *hope* that everybody uses the vdso32, simply because
> user programs are
On Sun, Aug 21, 2011 at 6:16 PM, Al Viro wrote:
>
> Is that ability a part of userland ABI or are we declaring that hopelessly
> wrong and require to go through the function in vdso32? Linus?
If people are using syscall directly, we're pretty much stuck. No
amount of "that's hopelessly wrong" wi
On 08/21/2011 06:09 PM, Linus Torvalds wrote:
>
> Indeed. Just add an "int 0x80" instruction to the vsyscall thing, and
> you'd be done.
>
> In fact, just replace the
>
> jmp .Lenter_kernel
>
> with
>
> int 0x80
>
> and you'd be pretty much all done, no?
>
> (Ok, that's probably a huge o
On Sun, Aug 21, 2011 at 06:09:00PM -0700, Linus Torvalds wrote:
> On Sun, Aug 21, 2011 at 5:44 PM, Andrew Lutomirski wrote:
> >
> > Which suggests an easy-ish fix: if sysenter is used or if syscall is
> > entered from the EIP is is supposed to be entered from, then just
> > change ip in the argume
On Sun, Aug 21, 2011 at 08:44:12PM -0400, Andrew Lutomirski wrote:
> This is, IMO, gross -- if the values in pt_regs matched what they were
> when sysenter / syscall was issued, then we'd be fine -- we could
> restart the syscall and everything would work. Apparently ptrace
> users have a problem
On Sun, Aug 21, 2011 at 5:44 PM, Andrew Lutomirski wrote:
>
> Which suggests an easy-ish fix: if sysenter is used or if syscall is
> entered from the EIP is is supposed to be entered from, then just
> change ip in the argument save to point to the int 0x80 instruction.
Indeed. Just add an "int 0x
On Sun, Aug 21, 2011 at 12:41 PM, Al Viro wrote:
> On Sun, Aug 21, 2011 at 03:43:52PM +0100, Al Viro wrote:
>
>> We do not lie to ptrace and iret. At all. We do just what you have
>> described. And fuck up when restart returns us to the SYSCALL / SYSENTER
>> instruction again, which expects the
On Sun, Aug 21, 2011 at 03:43:52PM +0100, Al Viro wrote:
> We do not lie to ptrace and iret. At all. We do just what you have
> described. And fuck up when restart returns us to the SYSCALL / SYSENTER
> instruction again, which expects the different calling conventions,
> so the values arranged
On Sun, Aug 21, 2011 at 09:37:18AM -0400, Andrew Lutomirski wrote:
> Gack. Is this a holdover from the 32-bit code that shares the
> argument save area with the parameters passed on the C stack? If so,
> we could just set up the argument save area honestly and pass the real
> parameters in regis
On Sun, Aug 21, 2011 at 07:24:35AM -0400, Andrew Lutomirski wrote:
> I don't see the point of all this hackery at all. sysenter/sysexit
> indeed screws up some registers, but we can return on the iret path in
> the case of restart.
We *do* return on iret path in case of restart, TYVM.
> So why
On Sun, Aug 21, 2011 at 7:24 AM, Andrew Lutomirski wrote:
> On Sun, Aug 21, 2011 at 4:42 AM, Al Viro wrote:
>> On Sun, Aug 21, 2011 at 07:34:43AM +0100, Al Viro wrote:
>>> Suppose we have a traced process. foo6() is called and the thing it
>>> stopped before the sys_foo6() is reached kernel-side
On Sun, Aug 21, 2011 at 4:42 AM, Al Viro wrote:
> On Sun, Aug 21, 2011 at 07:34:43AM +0100, Al Viro wrote:
>> Suppose we have a traced process. foo6() is called and the thing it
>> stopped before the sys_foo6() is reached kernel-side. The sixth argument
>> is on stack, ebp is set to user esp. S
76 matches
Mail list logo
