From: Bodo Stroesser <firstname.lastname@example.org> To: Bart Van Assche <email@example.com>, Christoph Hellwig <firstname.lastname@example.org> Cc: Joel Becker <email@example.com>, firstname.lastname@example.org, "Martin K . Petersen" <email@example.com>, Yanko Kaneti <firstname.lastname@example.org>, Brendan Higgins <email@example.com> Subject: Re: [PATCH 2/4] configfs: Fix writing at a non-zero offset Date: Mon, 26 Jul 2021 23:13:03 +0200 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On 26.07.21 18:26, Bart Van Assche wrote: > On 7/26/21 7:58 AM, Bodo Stroesser wrote: >> On 23.07.21 23:23, Bart Van Assche wrote: >> Let's say user writes 5 times to configfs file while keeping it open. >> On every write() call it writes 1 character only, e.g. first "A", then >> "B", ... >> >> The original code before the changes 5 times called flush_write_buffer >> for the >> strings "A\0", "B\0", ... (with the '\0' not included in the count >> parameter, >> so count is 1 always, which is the length of the last write). > > Isn't that behavior a severe violation of how POSIX specifies that the > write() system call should be implemented? Hmm. I'm not sure which detail should violate POSIX spec? Is there any definition how data should be flushed from buffer internally? (I'm by far not a POSIX expert!) I would rather say the new behavior, to call flush_write_buffer during the first write() for the data of that write, and then on the second write to call flush_write_buffer for the concatenated data of the first and the second write, could be a violation of POSIX, because the one times written data of the first write is flushed twice. I don't like the idea of breaking the "one write, one flush" principle that was implemented before. The old comment: "There is no easy way for us to know if userspace is only doing a partial write, so we don't support them. We expect the entire buffer to come on the first write." as I interpret it, makes clear that configfs code has to work according to that principle. (Or even block all but the first write, but that would even more break compatibility to old implementation.) Thank you, Bodo
next prev parent reply other threads:[~2021-07-26 21:13 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-23 21:23 [PATCH 0/4] Improve the configfs read and write iterators further Bart Van Assche 2021-07-23 21:23 ` [PATCH 1/4] configfs: Rework the overflow check in fill_write_buffer() Bart Van Assche 2021-07-23 21:23 ` [PATCH 2/4] configfs: Fix writing at a non-zero offset Bart Van Assche 2021-07-26 14:58 ` Bodo Stroesser 2021-07-26 16:26 ` Bart Van Assche 2021-07-26 21:13 ` Bodo Stroesser [this message] 2021-07-26 21:52 ` Bart Van Assche 2021-07-27 0:54 ` Bodo Stroesser 2021-07-27 3:17 ` Bart Van Assche 2021-07-27 7:27 ` Bodo Stroesser 2021-07-27 16:47 ` Bart Van Assche 2021-07-28 17:14 ` Bodo Stroesser 2021-07-28 17:55 ` Bart Van Assche 2021-07-23 21:23 ` [PATCH 3/4] kunit: Add support for suite initialization and cleanup Bart Van Assche 2021-07-27 21:26 ` Brendan Higgins 2021-07-29 3:33 ` Bart Van Assche 2021-07-23 21:23 ` [PATCH 4/4] configfs: Add unit tests Bart Van Assche
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 2/4] configfs: Fix writing at a non-zero offset' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).