search for: alloc_fd

...dea [<ffffffff802c560e>] path_walk+0x69/0xd4 [<ffffffff802c58a7>] do_path_lookup+0x187/0x1df [<ffffffff802bc094>] ? get_empty_filp+0xfc/0x188 [<ffffffff802c59bd>] path_lookup_open+0x5a/0x9b [<ffffffff802c6588>] do_filp_open+0xb6/0x899 [<ffffffff802cf62e>] ? alloc_fd+0x3a/0x12e [<ffffffff802cf711>] ? alloc_fd+0x11d/0x12e [<ffffffff802b92aa>] do_sys_open+0x53/0xd3 [<ffffffff802b9353>] sys_open+0x1b/0x1d [<ffffffff8020baeb>] system_call_fastpath+0x16/0x1b Device => Id: 253,2 Uuid: 8A77044F9D98416FAB240B44B1843EDA Gen: 0x7622C...

...fs2_mknod+0x236/0xc42 [ocfs2] [<ffffffffa0308854>] ocfs2_create+0x83/0xd9 [ocfs2] [<ffffffff8028f601>] vfs_create+0xd0/0xfe [<ffffffff8029179e>] do_filp_open+0x22b/0x806 [<ffffffff80468376>] _spin_unlock+0x17/0x20 [<ffffffff80299edf>] alloc_fd+0x106/0x117 [<ffffffff802857f6>] do_sys_open+0x48/0xcc [<ffffffff8020be5b>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff other info that might help us debug this: 3 locks held by cp/3919: #0: (&sb->s_type->i_mutex_key#13...

...strncpy_from_user+0x31/0x40 Mar 27 10:54:08 cvk-7 kernel: [ 361.374755] [<ffffffff81182c0a>] ? do_getname+0x10a/0x180 Mar 27 10:54:08 cvk-7 kernel: [ 361.374759] [<ffffffff8165c46e>] ? _raw_spin_lock+0xe/0x20 Mar 27 10:54:08 cvk-7 kernel: [ 361.374764] [<ffffffff81194b67>] ? alloc_fd+0xf7/0x150 Mar 27 10:54:08 cvk-7 kernel: [ 361.374769] [<ffffffff81176f6d>] do_sys_open+0xed/0x220 Mar 27 10:54:08 cvk-7 kernel: [ 361.374773] [<ffffffff81179175>] ? fput+0x25/0x30 Mar 27 10:54:08 cvk-7 kernel: [ 361.374776] [<ffffffff811770e1>] sys_openat+0x11/0x20 Mar 27 1...

...ffffffff8100fec9>] ? sched_clock+0x9/0xd [ 2161.175941] [<ffffffff81071d71>] ? sched_clock_local+0x12/0x75 [ 2161.182033] [<ffffffff8112e510>] do_filp_open+0x3d/0x89 [ 2161.187301] [<ffffffff8146945f>] ? _raw_spin_unlock+0x2b/0x2f [ 2161.192937] [<ffffffff81139104>] ? alloc_fd+0x181/0x193 [ 2161.198541] [<ffffffff81121548>] do_sys_open+0x74/0x106 [ 2161.204058] [<ffffffff811215fa>] sys_open+0x20/0x22 [ 2161.209488] [<ffffffff8146fec2>] system_call_fastpath+0x16/0x1b [ 2161.215279] INFO: lockdep is turned off. [ 2161.219841] Kernel panic - not syncing...

From: "Xiaowei.Hu" <xiaowei.hu at oracle.com> ocfs2_block_group_alloc_discontig() disables chain relink by setting ac->ac_allow_chain_relink = 0 because it grabs clusters from multiple cluster groups. It doesn't keep the credits for all chain relink,but ocfs2_claim_suballoc_bits overrides this in this call trace:

I''ve been working on running down intermittent ENOSPC issues. I can only seem to replicate ENOSPC errors when running zlib compression. However, I have been seeing similar ENOSPC errors to a lesser extent when playing with the LZ4HC patches. I apologize for not following up on this sooner, but I had drifted away from using zlib, and didn''t notice there was still an issue. My

...hangel kernel: [<ffffffff81122f64>] nameidata_to_filp+0x54/0x70 Aug 30 20:33:06 archangel kernel: [<ffffffff811311f0>] do_last+0x480/0x740 Aug 30 20:33:06 archangel kernel: [<ffffffff8113169d>] do_filp_open+0x1ed/0x680 Aug 30 20:33:06 archangel kernel: [<ffffffff8113cc74>] ? alloc_fd+0xf4/0x150 Aug 30 20:33:06 archangel kernel: [<ffffffff81122fe4>] do_sys_open+0x64/0x130 Aug 30 20:33:06 archangel kernel: [<ffffffff811230cb>] sys_open+0x1b/0x20 Aug 30 20:33:06 archangel kernel: [<ffffffff81009e82>] system_call_fastpath+0x16/0x1b Aug 30 20:33:08 archangel upsmo...

In fixing how we deal with bad inodes, we had a regression in the orphan cleanup code, since it expects to get a bad inode back. So fix it to deal with getting -ESTALE back by deleting the orphan item manually and moving on. Thanks, Reported-by: Simon Kirby <sim@hostway.ca> Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/inode.c | 36

...rom_release+0x16c/0x19f [ 288.525671] [<c03b0907>] ? kobject_put+0x37/0x3c [ 288.525680] [<c029069b>] ? __slab_alloc+0x9a/0x425 [ 288.525689] [<c0290af8>] ? kmem_cache_alloc+0x57/0xd9 [ 288.525697] [<c029cebb>] ? getname+0x1b/0xb9 [ 288.525706] [<c02a4787>] ? alloc_fd+0x53/0xb8 [ 288.525715] [<c0292c7d>] do_sys_open+0x48/0xdf [ 288.525724] [<c0292d56>] sys_open+0x1e/0x26 [ 288.525733] [<c0202984>] sysenter_do_call+0x12/0x22 [ 288.525739] ---[ end trace 1946ff4265fe09ba ]--- [ 288.525759] ------------[ cut here ]------------ [ 288.52604...

We need an smb_mb() before waitqueue_active to avoid missing wakeups. Before Mitch was hitting a deadlock between the ordered flushers and the transaction commit because the ordered flushers were waiting for more refs and were never woken up, so those smp_mb()''s are the most important. Everything else I added for correctness sake and to avoid getting bitten by this again somewhere else.

[This email is either empty or too large to be displayed at this time]

I was using my computer normally when suddenly my btrfs volume became read-only. This is on Chris'' for-linus branch (latest commit cb77fcd88) Here''s the relevant excerpt from dmesg [ 50.877500] r8169 0000:01:00.0: eth1: link up [ 50.880296] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 60.959215] eth1: no IPv6 routers present [ 1904.463247] atkbd serio0: Unknown key

Hello, Sometimes the backend of PVFB knows that it doesn''t need permanent refresh, when the window is minimized for instance (no refresh at all), or the administration tools know that the window is thumnailed, and so a slow refresh rate is fine. Also, some users may want to tune the refresh rate according to the smoothness they would like, balanced with the CPU time that requires.

Changes from v3: - mini-os configuration files moved into stubdom/ - mini-os extra console support now a config option - Fewer #ifdefs - grant table setup uses hypercall bounce - Xenstore stub domain syslog support re-enabled Changes from v2: - configuration support added to mini-os build system - add mini-os support for conditionally compiling frontends, xenbus -