[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6030.1316484637@turing-police.cc.vt.edu>
Date: Mon, 19 Sep 2011 22:10:37 -0400
From: Valdis.Kletnieks@...edu
To: Tim Chen <tim.c.chen@...ux.intel.com>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
David Miller <davem@...emloft.net>, zheng.z.yan@...el.com,
yanzheng@...n.com, netdev@...r.kernel.org, sfr@...b.auug.org.au,
jirislaby@...il.com, sedat.dilek@...il.com, alex.shi@...el.com
Subject: Re: [PATCH v2 net-next] af_unix: dont send SCM_CREDENTIALS by default
On Mon, 19 Sep 2011 14:39:58 PDT, Tim Chen said:
> Do we have to worry about the case where peer socket changes its flag
> to SOCK_PASSCRED while packets are in flight? If there isn't such
> pathological use case, the patch looks fine to me.
I wouldn't think so - if you're sending a packet, and retroactively trying to
change the flag and expect it to work, your program is too ugly to live. After
all, if the scheduler had cut off your timeslice and scheduledthe receiving
process before you set the flag, that packet would be delivered and done with
anyhow, and no amount of wishing will set that flag on an already-delivered
packet.
What *is* worth checking is that we DTRT if a process/thread is doing a send on
one CPU, and another process/thread with a shared file descriptor for that
socket is diddling the flag. But if we just define it as "atomic op to change
the flag and other observers get whatever value their CPU sees at that
instant", I'm OK with that too.. ;)
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists