From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29043 invoked by alias); 2 Oct 2010 05:41:05 -0000 Received: (qmail 27334 invoked by uid 48); 2 Oct 2010 05:40:43 -0000 Date: Sat, 02 Oct 2010 05:41:00 -0000 From: "mtk dot manpages at gmail dot com" To: glibc-bugs@sources.redhat.com Message-ID: <20101002054042.12083.mtk.manpages@gmail.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/12083] New: aio_init() treatment of aio_num argument looks buggy X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2010-10/txt/msg00010.txt.bz2 In sysdeps/pthread/aio_misc.c::__aio_init(), there are the following lines dealing with the aio_num field of the provided aioinit structure argument: if (pool == NULL) { optim.aio_threads = init->aio_threads < 1 ? 1 : init->aio_threads; optim.aio_num = (init->aio_num < ENTRIES_PER_ROW ? ENTRIES_PER_ROW : init->aio_num & ~ENTRIES_PER_ROW); } ENTRIES_PER_ROW is 32. This looks buggy. If init->aio_num is < 32, then the value 32 is used. That seems sensible. But if values greater than 32 are used, then the bit mask for 32 is ANDed out of the result, so that if, for example, init->aio_num is specified as 33, then the value 1 is assigned to optim.aio_num. Looking at the rest of the code, this doesn't appear to make sense. (The glibc info page provides no info on the intended behavior here.) -- Summary: aio_init() treatment of aio_num argument looks buggy Product: glibc Version: 2.12 Status: NEW Severity: normal Priority: P2 Component: libc AssignedTo: drepper dot fsp at gmail dot com ReportedBy: mtk dot manpages at gmail dot com CC: glibc-bugs at sources dot redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=12083 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.