linux-kernel - generic_file_buffered_write and O

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <5c49b0ed0612151443t3a6cad53u29575a3b9b0ac1fb@mail.gmail.com>
Date:	Fri, 15 Dec 2006 14:43:59 -0800
From:	"Nate Diller" <nate.diller@...il.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: generic_file_buffered_write and O_SYNC

So I'm trying to get an understanding of the interactions between the
various aio_read/aio_write paths, and I ran across this gem at the end
of generic_file_buffered_write:

        /*
         * For now, when the user asks for O_SYNC, we'll actually give O_DSYNC
         */
        if (likely(status >= 0)) {
                if (unlikely((file->f_flags & O_SYNC) || IS_SYNC(inode))) {
                        if (!a_ops->writepage || !is_sync_kiocb(iocb))
                                status = generic_osync_inode(inode, mapping,
                                                OSYNC_METADATA|OSYNC_DATA);
                }
        }

        /*
         * If we get here for O_DIRECT writes then we must have fallen through
         * to buffered writes (block instantiation inside i_size).  So we sync
         * the file data here, to try to honour O_DIRECT expectations.
         */
        if (unlikely(file->f_flags & O_DIRECT) && written)
                status = filemap_write_and_wait(mapping);

So if there's a writepage function AND we're doing async i/o, then
skip the writeout for O_SYNC files.  But always do writeout for dio,
synchronously.  Why do we check for the existence of ->writepage, but
not ->writepages?  Why do we ever skip writeback at all?

in addition to being poorly documented, this code looks to me like it
has a high likelyhood of being incorrect.  can anyone clarify?

thanks

NATE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/