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]
Message-Id: <200808201847.AA00213@capsicum.lab.ntt.co.jp>
Date:	Thu, 21 Aug 2008 03:47:06 +0900
From:	Ryusuke Konishi <konishi.ryusuke@....ntt.co.jp>
To:	"Pekka Enberg" <penberg@...helsinki.fi>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] nilfs2: continuous snapshotting file system

On Wed, Aug 20, 2008 at 11:22 AM, Pekka Enberg wrote:
>Hmm, this looks bit scary:
>
>> +/*
>> + * Low-level nilfs pages, page functions
>> + * Reviews should be made to adapt these to the common pagemap and buffer code.
>> + */
>> +static struct nilfs_pages {
>> +       spinlock_t              lru_lock;
>> +       struct list_head        active;
>> +       struct list_head        inactive;
>> +       unsigned long           nr_active;
>> +       unsigned long           nr_inactive;
>> +       struct rw_semaphore     shrink_sem;
>> +} nilfs_pages;
>> +
>> +/*
>> + * XXX per-cpu pagevecs may be able to reduce the overhead of list handlings
>> + *
>> + * static DEFINE_PER_CPU(struct pagevec, nilfs_lru_active) = { 0, };
>> + * static DEFINE_PER_CPU(struct pagevec, nilfs_lru_inactive) = { 0, };
>> + */
>> +
>> +void nilfs_pages_init(void)
>> +{
>> +       INIT_LIST_HEAD(&nilfs_pages.active);
>> +       INIT_LIST_HEAD(&nilfs_pages.inactive);
>> +       spin_lock_init(&nilfs_pages.lru_lock);
>> +       init_rwsem(&nilfs_pages.shrink_sem);
>> +       nilfs_pages.nr_active = 0;
>> +       nilfs_pages.nr_inactive = 0;
>> +}

Yeah, it's bothersome part.
I'd like to eliminate this peculiar code by using the standard mm/
functions or bd_inode, but still pending.

It's mainly used to maintain pages held by struct nilfs_btnode_cache,
which is a per-inode additional page cache used to store buffers of
B-tree.

Incidentally, for data blocks, mm/ page cache is used like other
file systems.

>(a) why does NILFS need this and (b) why aren't these patches against
>generic mm/*.c?

(a) I believe this is historical, but I will confirm the reason
    why filemap was not adopted.

(b) Because I think it should be eliminated rather than integrated 
    into mm/ at this point.

Thank you for comment.

Regards,
Ryusuke Konishi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ