From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82690 invoked by alias); 8 Jun 2016 20:15:30 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 82612 invoked by uid 89); 8 Jun 2016 20:15:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=gurus, spare, persuade, Nobody X-HELO: mailbackend.panix.com X-Gm-Message-State: ALyK8tJnj1MqJinil1W7b6Okf2OTkAHVvxMGWI7fFZC6cVUkiuKumvQ8rctP4HiBAKGZhVWLv+ksM+g0RBmYeg== X-Received: by 10.28.27.81 with SMTP id b78mr6567188wmb.19.1465416911161; Wed, 08 Jun 2016 13:15:11 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <5756D873.1000701@linaro.org> References: <1459175641-12520-1-git-send-email-adhemerval.zanella@linaro.org> <1459175641-12520-3-git-send-email-adhemerval.zanella@linaro.org> <5756D873.1000701@linaro.org> From: Zack Weinberg Date: Wed, 08 Jun 2016 20:15:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919) To: Adhemerval Zanella Cc: GNU C Library , Florian Weimer , Joseph Myers Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-06/txt/msg00276.txt.bz2 On Tue, Jun 7, 2016 at 10:21 AM, Adhemerval Zanella wrote: > On 07/06/2016 10:31, Zack Weinberg wrote: >> >> send/recv(m)msg are kernel primitives, and the fundamental basis of my >> objection is that I think the C library should always faithfully expose >> all the true kernel interfaces, *even if they are in some way wrong*. >> This conformance violation should be addressed by the kernel first, and >> only then should the C library follow suit. That means that neither >> this patch, nor the follow-up patch tackling cmsgbuf, should be applied >> at all. If either has already been applied, they should be backed out. > > I strongly disagree with this definition, the C library is still an > abstraction on underlying kernel and GLIBC should and follows POSIX > standards even when it deviates from the kernel primitives. The same > idea of standard is what drove the various fixes on both math library > conformance and various primitives (quick_exit is an example). You are going to have a very hard time persuading me to change my position, and this ain't gonna do it. This is circular logic. "We should follow POSIX because we should follow POSIX." I would consider a real (not made up for the purpose, and ideally, already existing) program that is broken by not having these types be as POSIX specifies to be a *valid argument* for changing the types, but even that might not be a *persuasive* argument for changing the types, especially since Florian has pointed out actual breakage from changing them. (Frankly, I think Florian's report of actual breakage should be the last word on the subject - back the patch out already, and let us never speak of this again.) What would persuade you to accept *my* position on this issue? (I'm cc:ing some of the usual standards-compliance gurus. I'm slightly more likely to be convinced by someone who is not advocating for their own patch.) > And it is also why some from community view explicit exposing some > Linux primitives (such as gettid) to be a controversial subject. As soon as I get some spare time (probably not in the 2.24 time frame) I am going to post a patch that makes glibc expose every single one of the Linux primitives that we don't already expose, because that's what I think we should do. But that's a tangent from this discussion. ... >> Earlier, I said that I didn't like copying cmsgbuf because it wasn't >> possible to be sure that no cmsg opcodes cared (now or in the future) >> about the address of the buffer, and Adhemerval said (effectively) that >> such an opcode would not make sense. That's not true. Imagine, if you >> will, a cmsg that expects the ancillary buffer to be overlaid on a >> shared memory area, and rewrites the *non*-ancillary buffer to reflect >> the location of that memory area in the receiver. > > Again, I see to no problem in this scenario: the function prototype states > a constant cmsghdr and it will not change its state. Even if the ancillary > buffer might change, it is up to application to synchronize its access > and call sendmsg in a flow where the data is a consistent state. I personally > see that calling a syscall with a buffer in racy condition does not make > sense. You clearly still don't get it. It's not about the buffer being in a racy condition. It's that the *address might be part of the message.* "Nobody should do that" is NOT a valid objection, because this is an arbitrarily extensible interface. Let me try again with another example. Imagine that there exists a SCM_CREATE_SHMEM ancillary message whose effect is to *convert that chunk of the ancillary buffer into a shared memory area*. The kernel will remap the data portion of the cmsg into the receiver, and supply the receiver with the address at which it was mapped. (You might be about to object that it doesn't make sense to embed the desired shared memory area in the cmsg, but, again, that is not a valid objection. This is an arbitrarily extensible interface. People can, will, and *have* done arbitrarily bizarre things with it.) Copying the ancillary buffer, *in and of itself*, would break this message. So would applying any small size limit to the length of an ancillary buffer. And come to think of it, this hypothetical cmsg would also justify the kernel's insisting to continue to use size_t for both cmsg_len and msg_controllen. zw