From owner-freebsd-bugs@FreeBSD.ORG Mon Nov 22 16:10:16 2010 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BB521065786 for ; Mon, 22 Nov 2010 16:10:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 50EB58FC19 for ; Mon, 22 Nov 2010 16:10:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oAMGAExo068189 for ; Mon, 22 Nov 2010 16:10:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oAMGAEWe068188; Mon, 22 Nov 2010 16:10:14 GMT (envelope-from gnats) Resent-Date: Mon, 22 Nov 2010 16:10:14 GMT Resent-Message-Id: <201011221610.oAMGAEWe068188@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Salvatore Sanfilippo Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FA75106567A for ; Mon, 22 Nov 2010 16:06:41 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (unknown [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 0ECB98FC15 for ; Mon, 22 Nov 2010 16:06:41 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id oAMG6e2Z073533 for ; Mon, 22 Nov 2010 16:06:40 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id oAMG6ejA073532; Mon, 22 Nov 2010 16:06:40 GMT (envelope-from nobody) Message-Id: <201011221606.oAMG6ejA073532@red.freebsd.org> Date: Mon, 22 Nov 2010 16:06:40 GMT From: Salvatore Sanfilippo To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: misc/152485: /dev/null seek offset is not reported correctly X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 16:10:16 -0000 >Number: 152485 >Category: misc >Synopsis: /dev/null seek offset is not reported correctly >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Nov 22 16:10:13 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Salvatore Sanfilippo >Release: FreeBSD 8 >Organization: VMware >Environment: unfortunately I don't have access to the system where the bug was reported / verified >Description: The bug was discovered as a result of a bug in Redis data base Virtual Memory implementation when running on FreeBSD. Opening /dev/null using the libc standard I/O functions and writing against it more than 4096 bytes (one memory page) will result in the seek reported by ftell() to be modulo 4096 (that is, an incorrect value). Even if /dev/null is not a standard file it should behave correctly and should be able to retain the current seek for the open file in a reliable way. I can't cite standard but I've the feeling the current behavior is not ok, and it's worth fixing even just because other *BSD kernels and Linux will instead behave in the obvious least-surprising way. >How-To-Repeat: #include int main(argc, argv) { FILE *fp = fopen("/dev/null","w+"); rewind(fp); int i, len; for (i=1;i<80000;i++) { fwrite("t", 1, 1, fp); len = ftello(fp); if (len != i) { printf("Fail on pos: %d, expected to be %d\n", len, i); return 1; } } printf("Pos is: %d\n", len); fclose(fp); return 0; } >Fix: The /dev/null implementation in FreeBSD appears to be optimized for speed, it allocates a single page of memory and reads from it, writes are completely discarded. Apparently there is no handling of the offset. But since I've almost zero clues about the FreeBSD char device API I don't know how a correct implementation should look like. >Release-Note: >Audit-Trail: >Unformatted: