linux-kernel - Re: Dirtiable inode bdi default != sb bdi btrfs

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: <20100929130056.GG3290@quack.suse.cz>
Date:	Wed, 29 Sep 2010 15:00:56 +0200
From:	Jan Kara <jack@...e.cz>
To:	Artem Bityutskiy <dedekind1@...il.com>
Cc:	Chris Mason <chris.mason@...cle.com>, Jan Kara <jack@...e.cz>,
	Cesar Eduardo Barros <cesarb@...arb.net>,
	Andrew Morton <akpm@...ux-foundation.org>, hch@....de,
	linux-kernel@...r.kernel.org, Jens Axboe <jaxboe@...ionio.com>,
	linux-btrfs@...r.kernel.org,
	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, stable@...nel.org,
	Jens Axboe <axboe@...nel.dk>,
	Michał Piotrowski <mkkp4x4@...il.com>,
	Chuck Ebbert <cebbert@...hat.com>,
	kernel@...ts.fedoraproject.org
Subject: Re: Dirtiable inode bdi default != sb bdi btrfs

On Tue 28-09-10 10:05:49, Artem Bityutskiy wrote:
> On Mon, 2010-09-27 at 18:54 -0400, Chris Mason wrote:
> > On Tue, Sep 28, 2010 at 12:25:48AM +0200, Jan Kara wrote:
> > > [Added CCs for similar ecryptfs warning]
> > > On Thu 23-09-10 12:38:49, Andrew Morton wrote:
> > > > > This started appearing for me on v2.6.36-rc5-49-gc79bd89; it did not 
> > > > > happen on v2.6.36-rc5-33-g1ce1e41, probably because it does not have 
> > > > > commit 692ebd17c2905313fff3c504c249c6a0faad16ec which introduces the 
> > > > > warning.
> > > > > [...]
> > > > > device fsid 44d595920ddedfa-3ece6b56e80f689e devid 1 transid 22342 
> > > > > /dev/mapper/vg_cesarbinspiro-lv_home
> > > > > SELinux: initialized (dev dm-3, type btrfs), uses xattr
> > > > > ------------[ cut here ]------------
> > > > > WARNING: at fs/fs-writeback.c:87 inode_to_bdi+0x62/0x6d()
> > > > > Hardware name: Inspiron N4010
> > > > > Dirtiable inode bdi default != sb bdi btrfs
> > > > > Modules linked in: ipv6 kvm_intel kvm uinput arc4 ecb 
> > > > > snd_hda_codec_intelhdmi snd_hda_codec_realtek iwlagn snd_hda_intel 
> > > > > iwlcore snd_hda_codec uvcvideo snd_hwdep mac80211 videodev snd_seq 
> > > > > snd_seq_device v4l1_compat snd_pcm atl1c v4l2_compat_ioctl32 btusb 
> > > > > cfg80211 snd_timer i2c_i801 bluetooth iTCO_wdt dell_wmi dell_laptop snd 
> > > > > pcspkr wmi dcdbas shpchp iTCO_vendor_support soundcore snd_page_alloc 
> > > > > rfkill joydev microcode btrfs zlib_deflate libcrc32c cryptd aes_x86_64 
> > > > > aes_generic xts gf128mul dm_crypt usb_storage i915 drm_kms_helper drm 
> > > > > i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan]
> > > > > Pid: 1073, comm: find Not tainted 2.6.36-rc5+ #8
> > > > > Call Trace:
> > > > >   [<ffffffff8104d0e4>] warn_slowpath_common+0x85/0x9d
> > > > >   [<ffffffff8104d19f>] warn_slowpath_fmt+0x46/0x48
> > > > >   [<ffffffff811308b7>] inode_to_bdi+0x62/0x6d
> > > > >   [<ffffffff81131b48>] __mark_inode_dirty+0xd0/0x177
> > > > >   [<ffffffff81127168>] touch_atime+0x107/0x12a
> > > > >   [<ffffffff81122384>] ? filldir+0x0/0xd0
> > > > >   [<ffffffff8112259b>] vfs_readdir+0x8d/0xb4
> > > > >   [<ffffffff8112270b>] sys_getdents+0x81/0xd1
> > > > >   [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
> > >   Thanks for the report. These bdi pointers are a mess. As Chris pointed
> > > out, btrfs forgets to properly initialize inode->i_mapping.backing_dev_info
> > > for directories and special inodes and thus these were previously attached
> > > to default_backing_dev_info which probably isn't what Chris would like to
> > > see.
> > 
> > There's no actual writeback for these, so it works fine for btrfs either
> > way.
> 
> Side note: every time inode is marked as dirty, we wake up a bdi thread
> or the default bdi thread. So if we have inodes which do not need
> write-back, we should never mark them as dirty.
  Are you sure? I think we wake up the thread only when it's the first
dirty inode for the bdi...
  And a side side note ;): It's harder not to dirty the inode than it seems.
E.g. btrfs (or similarly ext3) add the new inode data to the journal already
at inode dirty time but still they need to track that the transaction
carrying the inode is still uncommitted. Thus the inode *is* dirty in some
sense. Only it does not need any writeout to happen...

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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/