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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 19 Oct 2017 12:08:51 -0700
From:   Jaegeuk Kim <jaegeuk@...nel.org>
To:     Chao Yu <yuchao0@...wei.com>
Cc:     Chao Yu <chao@...nel.org>, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: return error number for quota_write

On 10/18, Chao Yu wrote:
> On 2017/10/18 2:17, Jaegeuk Kim wrote:
> > On 10/17, Chao Yu wrote:
> >>
> >>
> >> On 2017/10/17 7:04, Jaegeuk Kim wrote:
> >>> On 10/16, Chao Yu wrote:
> >>>> Hi Jaegeuk,
> >>>>
> >>>> On 2017/10/13 7:15, Jaegeuk Kim wrote:
> >>>>> This patch returns an error number to quota_write in order for quota to handle
> >>>>> it correctly.
> >>>>
> >>>> We should return error number like __generic_file_write_iter, right? it
> >>>> needs to return written bytes if we have written one page or more, otherwise
> >>>> return error number feedbacked from write_begin.
> >>>>
> >>>> So how about reverting 4f31d26b0c17 ("f2fs: return wrong error number on
> >>>> f2fs_quota_write")?
> >>>
> >>> I thought like that, but realized the code change is somewhat different between
> >>> them.
> >>
> >> Hmm... main structure of codes here is copied from other file systems, is there
> >> the same problem in *_quota_write of other file systems?
> >>
> >> BTW, it looks making below judgment condition being useless.
> >>
> >> 	if (len == towrite)
> >> 		return 0;
> > 
> > We need this to avoid needless inode updates. :P
> 
> For err = 0 and len == towrite case, it more likes a bug of quota that passing
> 0 in @len.
> 
> :(, Oh, still didn't get that why there is difference in between reverting and
> this fixing. Can you please explain more about this?

Ah, right. Let me just revert the original patch. :)

Thanks,

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ