On 2019/1/24 20:57, zhengliang wrote:
>
> The following race could lead to data block override node segment by mistake.
>
> Task A|Task B | Task C|Task D
> === | |== | =
> open file |
On 2019/2/12 10:33, Jaegeuk Kim wrote:
> If we met this once, let fsck.f2fs clear this only.
> Note that, this addresses all the subtle fault injection test.
>
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/checkpoint.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git
On 2019/2/12 2:45, Dan Carpenter wrote:
> We put an upper bound on ->write_io_size_bits but we don't have a lower
> bound.
Oh, lower bound, I think there are more cases didn't consider that,
let me check it.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Chao Yu
Thanks,
On 2019/2/5 0:59, Jaegeuk Kim wrote:
> On 02/02, Chao Yu wrote:
>> On 2019-1-29 7:47, Jaegeuk Kim wrote:
>>> After quota_off, we'll get some dirty blocks. If put_super don't have a
>>> chance
>>> to flush them by checkpoint, it causes NULL pointer exception in end_io
>>> after
>>>
On 2019/2/5 0:55, Jaegeuk Kim wrote:
> On 02/01, Chao Yu wrote:
>> On 2019-1-29 7:47, Jaegeuk Kim wrote:
>>> This mode returns mount() quickly with EAGAIN. We can trigger this by
>>> shutdown(F2FS_GOING_DOWN_NEED_FSCK).
>>
>> Is the purpose of this patch making mount failed more quickly due to
On 2019/2/4 16:06, Sahitya Tummala wrote:
> Fix below warning coming because of using mutex lock in atomic context.
>
> BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:98
> in_atomic(): 1, irqs_disabled(): 0, pid: 585, name: sh
> Preemption disabled at:
On Tue, Feb 12, 2019 at 12:24:33PM -0500, Theodore Y. Ts'o wrote:
>
> > > > The existing file hashes included in the measurement list and the
> > > > audit log, are currently being used for remote attestation, forensics
> > > > and security analytics.
> >
> > Again, the context for this comment
On Tue, Feb 12, 2019 at 08:06:52AM -0500, Mimi Zohar wrote:
> Yes, I understand that your primary goal hasn't changed. Linus was
> suggesting "the interface be made idempotent" to support "filesystems
> that don't actually have any long-term storage model for the merkle
> tree. IOW, you could do
On Tue, Feb 12, 2019 at 09:44:39AM -0500, Mimi Zohar wrote:
> Ted, one of the problems with IMA is that the file hash/signature
> verification is at file open. It isn't aware when files are brought
> in from cache. Does fs-verity re-verify blocks as they're restored
> from cache? For some use
> At that point, the merkle tree thing ends up fairly equivalent to
the
> > IMA "measurement" thing, with the exception that the filesystem *may*
> > optimize it to be long-term. Hmm?
>
> Well, except that it's just a less efficient way of doing IMA
> "measurement" (if the file system doesn't
Hi Ted,
The context for my comments/questions was Linus' suggestions, which
you've removed.
On Tue, 2019-02-12 at 00:31 -0500, Theodore Y. Ts'o wrote:
> On Sun, Feb 10, 2019 at 09:06:55AM -0500, Mimi Zohar wrote:
> > For which files will the Merkle tree be created? Is this for all
> > files on
On Sun, Feb 10, 2019 at 09:06:55AM -0500, Mimi Zohar wrote:
> For which files will the Merkle tree be created? Is this for all
> files on a per file system basis? Or is there some sort of "flag" or
> policy? The original design was based on an ioctl enabling/disabling
> a flag. In this new
12 matches
Mail list logo
