From: Ruoxin Jiang <rj2394@columbia.edu>
To: Satoru Takeuchi <satoru.takeuchi@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Btrfs Issues
Date: Mon, 25 Sep 2017 15:01:57 -0400 [thread overview]
Message-ID: <CAFzqJcZKMMnAJKuGjE=XX13TrvrvhuOtf8coaCVLPNMbsVL4hA@mail.gmail.com> (raw)
In-Reply-To: <87377kaehb.wl-satoru.takeuchi@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2472 bytes --]
Hi Satoru,
I'm so sorry for the late reply! I rewrote the test programs to invoke
syscalls in the conventional way and added a few comments. Please find
attached the revised report.
As to your questions on "mmap", you are totally right that the first
mmap in the original 1/min.cpp is irrelevant. The original program was
automatically generated from a fuzzer I used and I hope the revised
ones to be much more understandable.
Thanks,
Amy
On Sun, Sep 17, 2017 at 11:10 PM, Satoru Takeuchi
<satoru.takeuchi@gmail.com> wrote:
> At Wed, 13 Sep 2017 11:53:35 -0400,
> Ruoxin Jiang wrote:
>>
>> [1 <text/plain; UTF-8 (7bit)>]
>> Hello,
>>
>> We are researchers from Columbia University, New York. As part of our
>> current research we have found some semantic discrepancies between
>> btrfs and other popular filesystems.
>>
>> We have attached two cases. The first one involves an invalid O_DIRECT
>> write() that fails back to buffered write instead of failing with
>> error EINVAL. In directory 2, we discovered that btrfs calculates
>> write_bytes in __btrfs_buffered_write differently from that in
>> generic_perform_writes in fs/mmap.c. This can cause inconsistent
>> behavior between btrfs and other filesystems when program invokes the
>> same writev/write() syscall.
>>
>> In each directory, you will find a Readme.md describing the issue and
>> pointing to the code that may cause the problem. For your convenience,
>> we also included test programs (min.cpp) and instructions in Readme to
>> help reproduce the issues.
>>
>> We would appreciate very much if you could confirm the two cases at
>> your conveniences.
>
> I took a look at your test programs, btrfs_issues/{1,2}/min.cpp. It looks
> very hard to read since you call syscalls in odd ways and all flags are
> hardcoded as literal hexadecimal numbers. Could rewrite these program
> to improve readability?
>
> In addition, I have two questions about btrfs_issues/1/min.cpp.
>
> 1. Why you set 'filename' as the 1st argument of mmap()?
> 2. What's the purpose of mmap() call? I guess mmap() is not related to issue 1.
>
> Thanks,
> Satoru
>
>>
>> Thanks,
>> Amy
>> [2 btrfs_issues.tar.gz <application/x-gzip (base64)>]
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ruoxin(Amy) Jiang
Columbia University, M.S. Computer Science
347-277-5455
[-- Attachment #2: btrfs_issues_revised.tar.gz --]
[-- Type: application/x-gzip, Size: 1801 bytes --]
prev parent reply other threads:[~2017-09-25 19:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-13 15:53 Btrfs Issues Ruoxin Jiang
2017-09-18 3:10 ` Satoru Takeuchi
2017-09-25 19:01 ` Ruoxin Jiang [this message]
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 \
--in-reply-to='CAFzqJcZKMMnAJKuGjE=XX13TrvrvhuOtf8coaCVLPNMbsVL4hA@mail.gmail.com' \
--to=rj2394@columbia.edu \
--cc=linux-btrfs@vger.kernel.org \
--cc=satoru.takeuchi@gmail.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).