On 2018/4/17 4:16, Jaegeuk Kim wrote: > On 04/13, Chao Yu wrote: >> On 2018/4/13 12:05, Jaegeuk Kim wrote: >>> On 04/13, Chao Yu wrote: >>>> On 2018/4/13 9:04, Jaegeuk Kim wrote: >>>>> On 04/10, Chao Yu wrote: >>>>>> Hi Jaegeuk, >>>>>> >>>>>> On 2018/4/8 16:13, Chao Yu wrote: >>>>>>> f2fs doesn't allow abuse on atomic write class interface, so except >>>>>>> limiting in-mem pages' total memory usage capacity, we need to limit >>>>>>> start-commit time as well, otherwise we may run into infinite loop >>>>>>> during foreground GC because target blocks in victim segment are >>>>>>> belong to atomic opened file for long time. >>>>>>> >>>>>>> Now, we will check the condition with f2fs_balance_fs_bg in >>>>>>> background threads, once if user doesn't commit data exceeding 30 >>>>>>> seconds, we will drop all cached data, so I expect it can keep our >>>>>>> system running safely to prevent Dos attack. >>>>>> >>>>>> Is it worth to add this patch to avoid abuse on atomic write interface >>>>>> by user? >>>>> >>>>> Hmm, hope to see a real problem first in this case. >>>> >>>> I think this can be a more critical security leak instead of a potential >>>> issue >>>> which we can wait for someone reporting that can be too late. >>>> >>>> For example, user can simply write a huge file whose data spread in all >>>> f2fs >>>> segments, once user open that file as atomic, foreground GC will suffer >>>> deadloop, causing denying any further service of f2fs. >>> >>> How can you guarantee it won't happen within 30sec? If you want to avoid >>> that, >> >> Now the value is smaller than generic hang task threshold in order to avoid >> foreground GC helding gc_mutex too long, we can tune that parameter? >> >>> you have to take a look at foreground gc. >> >> What do you mean? let GC moves blocks of atomic write opened file? > > I thought that we first need to detect when foreground GC is stuck by such the > huge number of atomic writes. Then, we need to do something like dropping all > the atomic writes.
Yup, that will be reasonable. :) Thanks, > >> >> Thanks, >> >>> >>>> >>>> Thanks, >>>> >>>>> >>>>>> Thanks, >>>>> >>>>> . >>>>> >>> >>> . >>> > > . >
