All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tiger Yang <tiger.yang@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 0/2] ocfs2: two bug fixes about xattr and inline-data
Date: Mon, 09 Mar 2009 18:36:19 +0800	[thread overview]
Message-ID: <49B4F123.8070204@oracle.com> (raw)
In-Reply-To: <49B4C41B.1060708@oracle.com>

Hi, all,

Finally, Tristan and I found the reason why he could not reproduce bug2.
It's very interesting.

He runs the command "dd if=/dev/zero of=testfile bs=1 count=3641" which 
can not hit the bug2. But I found "dd if=/dev/zero of=testfile bs=3641 
count=1" will hit the bug2.

I trace the source code in ocfs2_try_to_write_inline_data(). Those two 
commands run the different way in kernel. In first situation, the codes 
going into "handle inodes which already have inline data 1st", then 
fault at ocfs2_size_fits_inline_data(), then go 
ocfs2_conver_inline_data_to_extents(). In second situation, It passed 
the wrong check about inline data size: ocfs2_max_inline_data(), then 
cause the fault.

As we discussed, Tristan will add the new command into his test script. 
Meanwhile he will reserve the old one because it cover more codes.

thanks,
tiger

Tiger Yang wrote:
> Hi,
> 
> I think Tristan's test script could catch these two bugs against 
> mainline. He didn't run his test script in mainline yet.
> 
> bug1:
> Just create a file in a directory which has default ACLs.
> 
> bug2:
> 1. touch a file in a file system which blocksize large than 512.
> 2. set xattr in it.
> 3. write i_size > (MAX_INLINE_SIZE - 256).
> then you can find the inline data overwrite the xattr in inode.
> 
> thanks,
> tiger
> 
> Tao Ma wrote:
>> Hi Tiger,
>>     so could you please describe how to reproduce these 2 bugs step by 
>> step? It would be easy for tristan to code them down and add them to the 
>> test case. And also we all can see whether we can reproduce them in our 
>> own env.
>>
>> Regards,
>> Tao
>>
>> tristan.ye wrote:
>>> On Sun, 2009-03-08 at 23:47 -0700, Joel Becker wrote:
>>>> On Mon, Mar 09, 2009 at 02:35:36PM +0800, Tiger Yang wrote:
>>>>> I found these two bugs in latest mainline kernel not other branch.
>>>>     The bugs should still be in cacheme - cacheme doesn't change
>>>> the inline data code.
>>> Fairly strange, I've already done the tests on cacheme branch, no such
>>> bugs happened to me...
>>>
>>> Tristan
>>>
>>>> Joel
>>>>
> 
> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel at oss.oracle.com
> http://oss.oracle.com/mailman/listinfo/ocfs2-devel

  reply	other threads:[~2009-03-09 10:36 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-04  3:18 [Ocfs2-devel] [PATCH 0/2] ocfs2: two bug fixes about xattr and inline-data Tiger Yang
2009-03-04  3:21 ` [Ocfs2-devel] [PATCH 1/2] ocfs2: reserve xattr block for directory inode in mknod Tiger Yang
2009-03-05  1:37   ` Joel Becker
2009-03-04  3:21 ` [Ocfs2-devel] [PATCH 2/2] ocfs2: fix check condition of max inline data Tiger Yang
2009-03-04  3:43   ` Tao Ma
2009-03-04  5:47     ` Tiger Yang
2009-03-04  5:49       ` Tao Ma
2009-03-05  1:44         ` Joel Becker
2009-03-05  2:36 ` [Ocfs2-devel] [PATCH 0/2] ocfs2: two bug fixes about xattr and inline-data Joel Becker
2009-03-09  4:17   ` tristan.ye
2009-03-09  4:57     ` Tao Ma
2009-03-09  5:04       ` tristan.ye
2009-03-09  5:42         ` Tao Ma
2009-03-09  6:14           ` tristan.ye
2009-03-09  6:35             ` Tiger Yang
2009-03-09  6:47               ` Joel Becker
2009-03-09  6:54                 ` tristan.ye
2009-03-09  7:02                   ` Tao Ma
2009-03-09  7:24                     ` Tiger Yang
2009-03-09 10:36                       ` Tiger Yang [this message]
2009-03-09 10:39                         ` Wengang Wang
2009-03-09 10:48                           ` Tao Ma
2009-03-09 10:57                         ` tristan.ye
2009-03-09  6:28   ` tristan.ye

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=49B4F123.8070204@oracle.com \
    --to=tiger.yang@oracle.com \
    --cc=ocfs2-devel@oss.oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.