Re: [PATCH v2] Btrfs: fix NULL pointer dereference in log_dir_items

2018-04-05 Thread Greg KH 
On Thu, Apr 05, 2018 at 07:11:14PM +0200, David Sterba wrote:
> On Thu, Apr 05, 2018 at 04:42:34PM +, Sasha Levin wrote:
> > Hi.
> > 
> > [This is an automated email]
> > 
> > This commit has been processed by the -stable helper bot and determined
> > to be a high probability candidate for -stable trees. (score: 9.9156)
> > 
> > The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, 
> > v4.4.126, 
> > 
> > v4.15.15: Build OK!
> > v4.14.32: Build OK!
> > v4.9.92: Build OK!
> > v4.4.126: Build OK!
> > 
> > Please let us know if you'd like to have this patch included in a stable 
> > tree.
> 
> Yes, in this case we expect that the Fixes: tag will let the patch flow
> to stable after it gets applied to master.

Fixes: tags almost never cause that to happen, unless I am bored and go
digging for them.

Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly if you want a patch applied to the stable
tree.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fix NULL pointer exception in find_bio_stripe()

2018-02-16 Thread Greg KH 
On Fri, Feb 16, 2018 at 07:51:38PM +, Dmitriy Gorokh wrote:
> On detaching of a disk which is a part of a RAID6 filesystem, the following 
> kernel OOPS may happen:
> 
> [63122.680461] BTRFS error (device sdo): bdev /dev/sdo errs: wr 0, rd 0, 
> flush 1, corrupt 0, gen 0 
> [63122.719584] BTRFS warning (device sdo): lost page write due to IO error on 
> /dev/sdo 
> [63122.719587] BTRFS error (device sdo): bdev /dev/sdo errs: wr 1, rd 0, 
> flush 1, corrupt 0, gen 0 
> [63122.803516] BTRFS warning (device sdo): lost page write due to IO error on 
> /dev/sdo 
> [63122.803519] BTRFS error (device sdo): bdev /dev/sdo errs: wr 2, rd 0, 
> flush 1, corrupt 0, gen 0 
> [63122.863902] BTRFS critical (device sdo): fatal error on device /dev/sdo 
> [63122.935338] BUG: unable to handle kernel NULL pointer dereference at 
> 0080 
> [63122.946554] IP: fail_bio_stripe+0x58/0xa0 [btrfs] 
> [63122.958185] PGD 9ecda067 P4D 9ecda067 PUD b2b37067 PMD 0 
> [63122.971202] Oops:  [#1] SMP 
> [63122.990786] Modules linked in: libcrc32c dlm configfs cpufreq_userspace 
> cpufreq_powersave cpufreq_conservative softdog nfsd auth_rpcgss nfs_acl nfs 
> lockd grace fscache sunrpc bonding ipmi_devintf ipmi_msghandler joydev 
> snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd psmouse evdev parport_pc 
> soundcore serio_raw battery pcspkr video ac97_bus ac parport ohci_pci 
> ohci_hcd i2c_piix4 button crc32c_generic crc32c_intel btrfs xor 
> zstd_decompress zstd_compress xxhash raid6_pq dm_mod dax raid1 md_mod 
> hid_generic usbhid hid xhci_pci xhci_hcd ehci_pci ehci_hcd usbcore sg sd_mod 
> sr_mod cdrom ata_generic ahci libahci ata_piix libata e1000 scsi_mod [last 
> unloaded: scst] 
> [63123.006760] CPU: 0 PID: 3979 Comm: kworker/u8:9 Tainted: G W 
> 4.14.2-16-scst34x+ #8 
> [63123.007091] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
> VirtualBox 12/01/2006 
> [63123.007402] Workqueue: btrfs-worker btrfs_worker_helper [btrfs] 
> [63123.007595] task: 880036ea4040 task.stack: c90006384000 
> [63123.007796] RIP: 0010:fail_bio_stripe+0x58/0xa0 [btrfs] 
> [63123.007968] RSP: 0018:c90006387ad8 EFLAGS: 00010287 
> [63123.008140] RAX: 0002 RBX: 88004beaa0b8 RCX: 
> 8800b2bd5690 
> [63123.008359] RDX:  RSI: 88007bb43500 RDI: 
> 88004beaa000 
> [63123.008621] RBP: c90006387ae8 R08: 9910 R09: 
> 8800b2bd5600 
> [63123.008840] R10: 0004 R11: 0001 R12: 
> 88007bb43500 
> [63123.009059] R13: fffb R14: 880036fc5180 R15: 
> 0004 
> [63123.009278] FS: () GS:8800b700() 
> knlGS: 
> [63123.009564] CS: 0010 DS:  ES:  CR0: 80050033 
> [63123.009748] CR2: 0080 CR3: b0866000 CR4: 
> 000406f0 
> [63123.009969] Call Trace: 
> [63123.010085] raid_write_end_io+0x7e/0x80 [btrfs] 
> [63123.010251] bio_endio+0xa1/0x120 
> [63123.010378] generic_make_request+0x218/0x270 
> [63123.010921] submit_bio+0x66/0x130 
> [63123.011073] finish_rmw+0x3fc/0x5b0 [btrfs] 
> [63123.011245] full_stripe_write+0x96/0xc0 [btrfs] 
> [63123.011428] raid56_parity_write+0x117/0x170 [btrfs] 
> [63123.011604] btrfs_map_bio+0x2ec/0x320 [btrfs] 
> [63123.011759] ? ___cache_free+0x1c5/0x300 
> [63123.011909] __btrfs_submit_bio_done+0x26/0x50 [btrfs] 
> [63123.012087] run_one_async_done+0x9c/0xc0 [btrfs] 
> [63123.012257] normal_work_helper+0x19e/0x300 [btrfs] 
> [63123.012429] btrfs_worker_helper+0x12/0x20 [btrfs] 
> [63123.012656] process_one_work+0x14d/0x350 
> [63123.012888] worker_thread+0x4d/0x3a0 
> [63123.013026] ? _raw_spin_unlock_irqrestore+0x15/0x20 
> [63123.013192] kthread+0x109/0x140 
> [63123.013315] ? process_scheduled_works+0x40/0x40 
> [63123.013472] ? kthread_stop+0x110/0x110 
> [63123.013610] ret_from_fork+0x25/0x30 
> [63123.013741] Code: 7e 43 31 c0 48 63 d0 48 8d 14 52 49 8d 4c d1 60 48 8b 51 
> 08 49 39 d0 72 1f 4c 63 1b 4c 01 da 49 39 d0 73 14 48 8b 11 48 8b 52 68 <48> 
> 8b 8a 80 00 00 00 48 39 4e 08 74 14 83 c0 01 44 39 d0 75 c4 
> [63123.014469] RIP: fail_bio_stripe+0x58/0xa0 [btrfs] RSP: c90006387ad8 
> [63123.014678] CR2: 0080 
> [63123.016590] ---[ end trace a295ea7259c17880 ]— 
> 
> This is reproducible in a cycle, where a series of writes is followed by SCSI 
> device delete command. The test may take up to few minutes.
> 
> Fixes: commit 74d46992e0d9dee7f1f376de0d56d31614c8a17a ("block: replace 
> bi_bdev with a gendisk pointer and partitions index")
> ---
>  fs/btrfs/raid56.c | 1 +
>  1 file changed, 1 insertion(+)



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at

Re: please include 17024ad0a0fd ("Btrfs: fix early ENOSPC due to delalloc") to 4.12 stable

2017-08-04 Thread Greg KH 
On Fri, Aug 04, 2017 at 11:25:14PM +0300, Nikolay Borisov wrote:
> Hello,
> 
> I'd like to aforementioned patch to be applied to stable 4.9/4.12. The
> attached backport applies cleanly to both of them.

Thanks, I'll queue it up after this next release happens.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REVERT][v4.10][V2] btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl

2017-02-02 Thread Greg KH 
On Thu, Feb 02, 2017 at 02:58:16PM -0500, Joseph Salisbury wrote:
> On 02/02/2017 01:23 PM, Greg KH wrote:
> > On Thu, Feb 02, 2017 at 12:38:33PM -0500, Joseph Salisbury wrote:
> >> Hello,
> >>
> >> Please consider reverting commit
> >> 4c63c2454eff996c5e27991221106eb511f7db38 in the next v4.x.y release.
> > What release can I remove it from?
> >
> > It isn't in 4.4.y, and 4.9.y doesn't make much sense, unless it's
> > reverted in Linus's tree already?
> >
> > totally confused.
> >
> > greg k-h
> 
> Sorry, commit 4c63c2454eff996c5e27991221106eb511f7db38 was introduced in
> mainline in v4.7-rc1.  The request should be only for kernels newer than
> 4.7-rc1, so 4.9 and 4.10.
> 
> I assume it will come down to 4.9 once reverted in mainline. 

Let me know when it is reverted, and what that revert commit is please.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Subject: [REVERT][v4.x.y] btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl

2017-02-02 Thread Greg KH 
On Thu, Feb 02, 2017 at 12:38:33PM -0500, Joseph Salisbury wrote:
> Hello,
> 
> Please consider reverting commit
> 4c63c2454eff996c5e27991221106eb511f7db38 in the next v4.x.y release.

What release can I remove it from?

It isn't in 4.4.y, and 4.9.y doesn't make much sense, unless it's
reverted in Linus's tree already?

totally confused.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] [PATCH v4 00/26] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

2016-08-16 Thread Greg KH 
On Tue, Aug 16, 2016 at 11:18:52AM -0700, Deepa Dinamani wrote:
> Thank you for the suggestion.
> 
> > Who are you execting to pull this huge patch series?
> 
> The last pull request was addressed to Al as per Arnd's suggestion.
> I'm not completely sure who should it be addressed to.
> 
> > Why not just introduce the new api call, wait for that to be merged, and
> > then push the individual patches through the different subsystems?
> > After half of those get ignored, then provide a single set of patches
> > that can go through Andrew or my trees.
> 
> Arnd and I tried to do this a few ways.
> 
> We can try to introduce the api first like you suggest.
> 
> There are a few Acks already on the patches.
> And, patches 2-5 also need to be merged through some common tree like
> yours or Andrew's as you suggest.
> 
> So, if everyone is ok, I could do the following:
> 
> 1. Post patches 1-5 for rc-2.

-rc2 is already released, and we aren't adding new apis this late in the
release cycle, sorry.

> 2. Post all other patches to respective maintainers after rc-2
> 3. Then after patches get ignored or merged, post remaining as a
> series for you or Andrew to pick up.

The apis need to be aimed for 4.9-rc1, it's too late for 4.8, sorry.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] [PATCH v4 00/26] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

2016-08-15 Thread Greg KH 
On Sat, Aug 13, 2016 at 03:48:12PM -0700, Deepa Dinamani wrote:
> The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC 
> macros.
> The macros are not y2038 safe. There is no plan to transition them into being
> y2038 safe.
> ktime_get_* api's can be used in their place. And, these are y2038 safe.

Who are you execting to pull this huge patch series?

Why not just introduce the new api call, wait for that to be merged, and
then push the individual patches through the different subsystems?
After half of those get ignored, then provide a single set of patches
that can go through Andrew or my trees.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG at fs/btrfs/extent-tree.c:1833! [btrfs]

2015-12-09 Thread Greg KH 
On Wed, Dec 09, 2015 at 11:29:48PM +, Filipe Manana wrote:
> On Wed, Dec 9, 2015 at 11:05 PM, Gerald Hopf  
> wrote:
> >
> >>> kernel BUG at fs/btrfs/extent-tree.c:1833!
> >>
> >> We got this fixed in 4.4-rc1:
> >>
> >>
> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2c3cf7d5f6105bb957df125dfce61d4483b8742d
> >>
> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b06c4bf5c874a57254b197f53ddf588e7a24a2bf
> >>
> >> Patches were tagged for stable releases but weren't yet backported to
> >> 4.2 and 4.3 (the issue affects all 4.2 and 4.3 releases at the
> >> moment).
> >>
> >> cheers
> >
> > Could someone please backport this important fix and merge it into the
> > stable kernels?
> > Today Kernel 4.2.7 and 4.3.1 were finally released and as far as I can see
> > in the changelog no btrfs fixes were included in these updates.
> > => still can't do balance without crashing the system
> 
> It's up to the stable team (cc'ed) to do that. For some reason, all
> patches (at least btrfs ones) tagged for stable haven't been added to
> 4.3.x and 4.2.x at least for quite some time. Probably just a long
> queue and a busy maintainer or on vacations or something like that.

Yes a combination of those two things.  I'm digging myself out of the
stable queue, right now there are over 10 btrfs stable patches in the
queue that I haven't even touched yet, sorry.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Btrfs stable updates for 4.0

2015-06-25 Thread Greg KH 
On Thu, Jun 25, 2015 at 05:10:29PM +0200, David Sterba wrote:
 On Fri, Jun 19, 2015 at 01:31:31PM -0700, Greg KH wrote:
 5cc2b17e80cf5770f2e585c2d90fd8af1b901258 # 3.14+
  
  Does not build on 3.14+, sorry.  Please provide a backported version if
  you want to see it there.
 
 I'm sorry about the hassle with applying to older version. My main
 goal is to provide a set of patches for the latest stable series, and
 they get reviewed and tested properly. I try to look whether the patches
 are relvant for older versions but this takes extra time. I don't have
 particular interest in these so it's only best effort, but so far it
 hasn't met the 'best' premise. I'll try better next time.

That's fine, no need to work hard for any longterm kernel if you don't
want to, just letting you know that this patch didn't work there.  I
don't care if it doesn't make it if you don't :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Btrfs stable updates for 4.0

2015-06-19 Thread Greg KH 
On Thu, Jun 11, 2015 at 06:06:32PM +0200, David Sterba wrote:
 Hi,
 
 please queue the following patches to 4.0 stable. There are fixes for user
 visible bugs and one usability regression with RAID1 - single conversion
 during balance.
 
 One of the patches does not apply cleanly to 4.0.5, there's a minor conflict 
 in
 patch context (153c35b60c72de9fae06c8e2c8b2c47d79d4, the last one). A 
 reply
 to this mail is the adapted version or you can pull/cherry-pick from
 
   git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-stable-4.0
 
 Subjects:
   Btrfs: send, add missing check for dead clone root
   Btrfs: send, don't leave without decrementing clone root's send_progress
   btrfs: incorrect handling for fiemap_fill_next_extent return
   btrfs: cleanup orphans while looking up default subvolume
   Btrfs: fix range cloning when same inode used as source and destination
   Btrfs: fix uninit variable in clone ioctl
   Btrfs: fix regression in raid level conversion
 Commits:
   5cc2b17e80cf5770f2e585c2d90fd8af1b901258 # 3.14+

Does not build on 3.14+, sorry.  Please provide a backported version if
you want to see it there.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in

Re: Btrfs stable updates for 4.0

2015-06-19 Thread Greg KH 
On Thu, Jun 11, 2015 at 06:06:32PM +0200, David Sterba wrote:
 Hi,
 
 please queue the following patches to 4.0 stable. There are fixes for user
 visible bugs and one usability regression with RAID1 - single conversion
 during balance.
 
 One of the patches does not apply cleanly to 4.0.5, there's a minor conflict 
 in
 patch context (153c35b60c72de9fae06c8e2c8b2c47d79d4, the last one). A 
 reply
 to this mail is the adapted version or you can pull/cherry-pick from
 
   git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-stable-4.0
 
 Subjects:
   Btrfs: send, add missing check for dead clone root
   Btrfs: send, don't leave without decrementing clone root's send_progress
   btrfs: incorrect handling for fiemap_fill_next_extent return
   btrfs: cleanup orphans while looking up default subvolume
   Btrfs: fix range cloning when same inode used as source and destination
   Btrfs: fix uninit variable in clone ioctl
   Btrfs: fix regression in raid level conversion
 Commits:
   5cc2b17e80cf5770f2e585c2d90fd8af1b901258 # 3.14+
   2f1f465ae6da244099af55c066e5355abd8ff620 # 3.14+

Because 5cc2b17e80cf5770f2e585c2d90fd8af1b901258 breaks the build,
2f1f465ae6da244099af55c066e5355abd8ff620 does not apply to 3.14 either
:(
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in

Re: Please add 9c4f61f01d269815bb7c37be3ede59c5587747c6 to stable

2015-04-23 Thread Greg KH 
On Thu, Apr 23, 2015 at 02:16:40PM -0400, Rich Freeman wrote:
 On Mon, Apr 13, 2015 at 12:58 PM, Greg KH gre...@linuxfoundation.org wrote:
  On Mon, Apr 13, 2015 at 07:28:38PM +0500, Roman Mamedov wrote:
  On Thu, 2 Apr 2015 10:17:47 -0400
  Chris Mason c...@fb.com wrote:
 
   Hi stable friends,
  
   Can you please backport this one to 3.19.y.  It fixes a bug introduced
   by:
  
   381cf6587f8a8a8e981bc0c18859b51dc756, which was tagged for stable
   3.14+
  
   The symptoms of the bug are deadlocks during log reply after a crash.
   The patch wasn't intentionally fixing the deadlock, which is why we
   missed it when tagging fixes.
 
  Unfortunately still not fixed (no btrfs-related changes) in 3.14.38 and
  3.18.11 released today.
 
  I have a few hundred stable backports left to sort through, don't worry,
  this is still in the queue, it's not lost.
 
 It looks like this still isn't in 3.18.12, though it looks like it is in 
 3.19.5.

I don't manage 3.18-stable anymore, so there's nothing I can do here :)
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Please add 9c4f61f01d269815bb7c37be3ede59c5587747c6 to stable

2015-04-13 Thread Greg KH 
On Mon, Apr 13, 2015 at 07:28:38PM +0500, Roman Mamedov wrote:
 On Thu, 2 Apr 2015 10:17:47 -0400
 Chris Mason c...@fb.com wrote:
 
  Hi stable friends,
  
  Can you please backport this one to 3.19.y.  It fixes a bug introduced 
  by:
  
  381cf6587f8a8a8e981bc0c18859b51dc756, which was tagged for stable 
  3.14+
  
  The symptoms of the bug are deadlocks during log reply after a crash.  
  The patch wasn't intentionally fixing the deadlock, which is why we 
  missed it when tagging fixes.
 
 Unfortunately still not fixed (no btrfs-related changes) in 3.14.38 and
 3.18.11 released today.

I have a few hundred stable backports left to sort through, don't worry,
this is still in the queue, it's not lost.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1 V2] export symbol kobject_move()

2015-02-12 Thread Greg KH 
On Thu, Feb 12, 2015 at 10:53:14AM +0100, David Sterba wrote:
 Adding Greg to CC.
 
 On Thu, Feb 12, 2015 at 07:03:37AM +0800, Anand Jain wrote:
  drivers/cpufreq/cpufreq.c is already using this function. And now btrfs
  needs it as well. export symbol kobject_move().
  
  Signed-off-by: Anand Jain anand.j...@oracle.com
  ---
  v1-v2: Didn't notice there wasn't my signed-off, now added. Thanks Dave.
  
   lib/kobject.c | 1 +
   1 file changed, 1 insertion(+)
  
  diff --git a/lib/kobject.c b/lib/kobject.c
  index 58751bb..e055c06 100644
  --- a/lib/kobject.c
  +++ b/lib/kobject.c
  @@ -548,6 +548,7 @@ out:
  kfree(devpath);
  return error;
   }
  +EXPORT_SYMBOL_GPL(kobject_move);
 
 Looks ok to me. There's another user of this function in
 drivers/cpufreq/cpufreq.c, but apparenly not a module so the export was
 not needed.

Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs for stable (mostly 3.17)

2014-10-22 Thread Greg KH 
On Tue, Oct 21, 2014 at 03:19:09PM -0400, Chris Mason wrote:
 
 
 On Mon, Oct 20, 2014 at 6:12 PM, Greg KH gre...@linuxfoundation.org wrote:
 On Mon, Oct 20, 2014 at 01:22:22PM +0100, Filipe Manana wrote:
 
  May I suggest porting the following commit to 3.14 too?
 
 https://urldefense.proofpoint.com/v1/url?u=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id%3D766b5e5ae78dd04a93a275690a49e23d7dcb1f39k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=6%2FL0lzzDhu0Y1hL9xm%2BQyA%3D%3D%0Am=4HB2GrskctbPsSOzamEf9hTilGJUhvqoPLn0LWCzaTI%3D%0As=c55d2716c1968c22c220de980059a704c31aa637a7036e25909da9cc960bd0f4
 
  It fixes a data corruption issue for an incremental send. Particularly
  important, IMHO, as the corruption happens silently (no errors returned
  to user space nor any sort of warnings/errors in syslog, etc). It
  affects only 3.14, and the change applies cleanly on 3.14.22.
 
 Chris, any objection for me taking this?
 
 On vacation, sorry for the lag.  Please do take this one too.  Thanks
 Filipe.

Great, now applied.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs for stable (mostly 3.17)

2014-10-20 Thread Greg KH 
On Mon, Oct 20, 2014 at 01:22:22PM +0100, Filipe Manana wrote:
 
 
 On 10/20/2014 12:13 AM, Greg KH wrote:
  On Sun, Oct 19, 2014 at 09:55:11PM +0200, Greg KH wrote:
  On Sun, Oct 19, 2014 at 06:01:16AM -0400, Chris Mason wrote:
  Hi everyone,
 
  I've pulled out some of the btrfs commits from the merge window that
  we'd like to see in stable.  The full list of sha's from Linus is below,
  you can see 4 of them are only needed on 3.17
 
  2fad4e83e12591eb3bd213875b9edc2d18e93383
  0b4699dcb65c2cff793210b07f40b98c2d423a43 # v3.17
  12b894cb288d57292b01cf158177b6d5c89a6272
  78a017a2c92df9b571db0a55a016280f9019c65e
  4d1a40c66bed0b3fa43b9da5fbd5cbe332e4eccf
  e6c4efd87ab04e5ead363f24e6ac35ed3506d401 # v3.17
  f6acfd50110b335c7af636cf1fc8e55319cae5fc
  1d52c78afbbf80b58299e076a159617d6b42fe3c
  75bfb9aff45e44625260f52a5fd581b92ace3e62
  bbe9051441effce51c9a533d2c56440df64db2d7
  32be3a1ac6d09576c57063c6c350ca36eaebdbd3 # v3.17
  42383020beb1cfb05f5d330cc311931bc4917a97
  d37973082b453ba6b89ec07eb7b84305895d35e1 # v3.17
 
  I'm confused, the others not marked with a # v3.17 need to go on older
  kernels as well?
  
  I've picked up the ones that apply and build for the older stable
  kernels I maintain now, thanks for the list.
 
 May I suggest porting the following commit to 3.14 too?
 
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=766b5e5ae78dd04a93a275690a49e23d7dcb1f39
 
 It fixes a data corruption issue for an incremental send. Particularly
 important, IMHO, as the corruption happens silently (no errors returned
 to user space nor any sort of warnings/errors in syslog, etc). It
 affects only 3.14, and the change applies cleanly on 3.14.22.

Chris, any objection for me taking this?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs for stable (mostly 3.17)

2014-10-19 Thread Greg KH 
On Sun, Oct 19, 2014 at 06:01:16AM -0400, Chris Mason wrote:
 Hi everyone,
 
 I've pulled out some of the btrfs commits from the merge window that
 we'd like to see in stable.  The full list of sha's from Linus is below,
 you can see 4 of them are only needed on 3.17
 
 2fad4e83e12591eb3bd213875b9edc2d18e93383
 0b4699dcb65c2cff793210b07f40b98c2d423a43 # v3.17
 12b894cb288d57292b01cf158177b6d5c89a6272
 78a017a2c92df9b571db0a55a016280f9019c65e
 4d1a40c66bed0b3fa43b9da5fbd5cbe332e4eccf
 e6c4efd87ab04e5ead363f24e6ac35ed3506d401 # v3.17
 f6acfd50110b335c7af636cf1fc8e55319cae5fc
 1d52c78afbbf80b58299e076a159617d6b42fe3c
 75bfb9aff45e44625260f52a5fd581b92ace3e62
 bbe9051441effce51c9a533d2c56440df64db2d7
 32be3a1ac6d09576c57063c6c350ca36eaebdbd3 # v3.17
 42383020beb1cfb05f5d330cc311931bc4917a97
 d37973082b453ba6b89ec07eb7b84305895d35e1 # v3.17

I'm confused, the others not marked with a # v3.17 need to go on older
kernels as well?

 I've made a git branch (stable-3.17) with all of these cherry picked out:
 
 git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git 
 stable-3.17
 
 They all cherry pick cleanly, so the git tree is mostly for btrfs users
 who wanted a recent corruption fix.  Feel free to pull or feed the shas
 into your scripts.  The last one (d37973082b) was already tagged for
 stable, so you've probably got it already through the regular channels.
 It shouldn't need special ordering.

Ok, thanks, I'll just feed these sha1s to my scripts, it's easier that
way.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs for stable (mostly 3.17)

2014-10-19 Thread Greg KH 
On Sun, Oct 19, 2014 at 09:55:11PM +0200, Greg KH wrote:
 On Sun, Oct 19, 2014 at 06:01:16AM -0400, Chris Mason wrote:
  Hi everyone,
  
  I've pulled out some of the btrfs commits from the merge window that
  we'd like to see in stable.  The full list of sha's from Linus is below,
  you can see 4 of them are only needed on 3.17
  
  2fad4e83e12591eb3bd213875b9edc2d18e93383
  0b4699dcb65c2cff793210b07f40b98c2d423a43 # v3.17
  12b894cb288d57292b01cf158177b6d5c89a6272
  78a017a2c92df9b571db0a55a016280f9019c65e
  4d1a40c66bed0b3fa43b9da5fbd5cbe332e4eccf
  e6c4efd87ab04e5ead363f24e6ac35ed3506d401 # v3.17
  f6acfd50110b335c7af636cf1fc8e55319cae5fc
  1d52c78afbbf80b58299e076a159617d6b42fe3c
  75bfb9aff45e44625260f52a5fd581b92ace3e62
  bbe9051441effce51c9a533d2c56440df64db2d7
  32be3a1ac6d09576c57063c6c350ca36eaebdbd3 # v3.17
  42383020beb1cfb05f5d330cc311931bc4917a97
  d37973082b453ba6b89ec07eb7b84305895d35e1 # v3.17
 
 I'm confused, the others not marked with a # v3.17 need to go on older
 kernels as well?

I've picked up the ones that apply and build for the older stable
kernels I maintain now, thanks for the list.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Btrfs stable updates for 3.16.x (and others)

2014-09-04 Thread Greg KH 
On Thu, Sep 04, 2014 at 06:37:58PM +0200, David Sterba wrote:
 On Wed, Sep 03, 2014 at 02:32:09PM -0700, Greg KH wrote:
   6f7ff6d7832c6be13e8c95598884dbc40ad69fb7
  This doesn't apply to 3.10-stable :(
  
   ce62003f690dff38d3164a632ec69efa15c32cbf
  Neither did this.
 
 I'm sorry for the trouble. I tried to verify that the patches apply but
 must have missed that.

Care to provide backported patches?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Btrfs stable updates for 3.16.x (and others)

2014-09-03 Thread Greg KH 
On Tue, Aug 19, 2014 at 01:10:45PM +0200, David Sterba wrote:
 Hi stable team,
 
 please add the following patches to stable trees.
 
 Patch #3 applies to all currently live stables, a 7 years old bug. I've
 briefly reviewed all 3 patches against 3.10/12/14/16 (ie. 3.4 skips #1
 and #2).
 
 Subjects:
 Btrfs: read lock extent buffer while walking backrefs
 Btrfs: fix compressed write corruption on enospc
 Btrfs: fix csum tree corruption, duplicate and outdated checksums
 Commits:
 6f7ff6d7832c6be13e8c95598884dbc40ad69fb7

This doesn't apply to 3.10-stable :(

 ce62003f690dff38d3164a632ec69efa15c32cbf

Neither did this.

 27b9a8122ff71a8cadfbffb9c4f0694300464f3b

Was already marked for stable.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Btrfs stable updates for v3.16

2014-09-03 Thread Greg KH 
On Wed, Sep 03, 2014 at 04:50:47PM -0400, Chris Mason wrote:
 Hi everyone,
 
 For 3.16, please pull these into stable, I've cherry picked and tested
 them here.  For 3.15 and earlier there are a few conflicts, so I'll make
 a git tree with things to pull.
 
 8d875f95da43c6a8f18f77869f2ef26e9594fecc v3.15+
 38c1c2e44bacb37efd68b90b3f70386a8ee370ee v3.11+
 f6dc45c7a93a011dff6eb9b2ffda59c390c7705a v3.15+
 9e0af23764344f7f1b68e4eefbe7dc865018b63d v3.15+

Now applied to the trees I manage.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v3.10.y][v3.11.y][v3.12.y][v3.13.y][v3.14.y][PATCH 1/1][V2] ALSA: usb-audio: Prevent printk ratelimiting from spamming kernel log while DEBUG not defined

2014-07-07 Thread Greg KH 
On Sat, Jun 21, 2014 at 12:48:27PM -0700, Greg KH wrote:
 On Sat, Jun 21, 2014 at 01:05:53PM +0100, Ben Hutchings wrote:
  On Fri, 2014-06-20 at 14:21 -0400, Joseph Salisbury wrote:
  [...]
   I looked at this some more.   It seems like my v2 backport may be the
   most suitable for the releases mentioned in the subject line, but I'd
   like to get additional feedback.
   
   The lines added by commit a5065eb just get removed by commit b7a77235. 
   Also, if I apply commit a5065eb, it will also require a backport to pull
   in just a piece of code(Remove snd_printk() and add dev_dbg()) from
   another prior commit(0ba41d9).  No backport would be needed at all if I
   cherry-pick 0ba41d9, but that commit seems to have too may changes for a
   stable release.
  
  Keep the changes squashed together if you like, but do include both
  commit hashes and commit messages.
 
 No, I don't want to see squashed together patches, please keep them as
 close to the original patch as possible.  It saves time in the long run,
 trust me...

And since no one did this work for me, I had to do it myself...

{grumble}
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs

2014-02-04 Thread Greg KH 
On Mon, Feb 03, 2014 at 01:18:40PM -0500, Chris Mason wrote:
 On Mon 03 Feb 2014 12:54:05 PM EST, David Sterba wrote:
 On Thu, Jan 30, 2014 at 04:52:54PM -0500, Chris Mason wrote:
 Chris Mason (3) commits (+64/-32):
  Btrfs: setup inode location during btrfs_init_inode_locked (+9/-9)
  Btrfs: don't use ram_bytes for uncompressed inline items (+52/-22)
 
 The patches are CC: stable, but haven't gone through the mailinglist.
 Are they still going to be picked by stable?
 
 We do need both in -stable, I'll help with backports.

Very few of the patches you marked for -stable, actually would apply (or
build once applied.)  Can you please send a set of patches you want
applied?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Btrfs stable updates for 3.12

2013-12-18 Thread Greg KH 
On Wed, Dec 18, 2013 at 04:14:02PM +0100, David Sterba wrote:
 Hi,
 
 please queue the following patches to 3.12 stable. They fix a few
 crashes or lockups that were reported by users.
 
 The patch stop using vfs_read in send may seem big for stable, but without 
 it
 the send/receive ioctl hits the global open file limit sooner or later,
 depending on the ram size.
 
 Subjects:
 Btrfs: do a full search everytime in btrfs_search_old_slot
 Btrfs: reset intwrite on transaction abort
 Btrfs: fix memory leak of chunks' extent map
 Btrfs: fix hole check in log_one_extent [bug 1]
 Btrfs: fix incorrect inode acl reset
 Btrfs: stop using vfs_read in send
 Btrfs: take ordered root lock when removing ordered operations inode
 Btrfs: do not run snapshot-aware defragment on error
 Btrfs: fix a crash when running balance and defrag concurrently
 Btrfs: fix lockdep error in async commit
 Commits:
 d4b4087c43cc00a196c5be57fac41f41309f1d56
 e0228285a8cad70e4b7b4833cc650e36ecd8de89
 7d3d1744f8a7d62e4875bd69cc2192a939813880
 ed9e8af88e2551aaa6bf51d8063a2493e2d71597
 8185554d3eb09d23a805456b6fa98dcbb34aa518
 ed2590953bd06b892f0411fc94e19175d32f197a
 93858769172c4e3678917810e9d5de360eb991cc
 6f519564d7d978c00351d9ab6abac3deeac31621
 48ec47364b6d493f0a9cdc116977bf3f34e5c3ec
 b1a06a4b574996692b72b742bf6e6aa0c711a948
 
 all apply cleanly on top of 3.12.5.

all now applied, along with 4 of these that seem to be applicable to
3.10-stable.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Btrfs: relocate csums properly with prealloc extents

2013-11-25 Thread Greg KH 
On Mon, Nov 25, 2013 at 05:51:16PM +0100, David Sterba wrote:
 On Fri, Sep 27, 2013 at 09:37:00AM -0400, Josef Bacik wrote:
  A user reported a problem where they were getting csum errors when running a
  balance and running systemd's journal.  This is because systemd is awesome 
  and
  fallocate()'s its log space and writes into it.  Unfortunately we assume 
  that
  when we read in all the csums for an extent that they are sequential 
  starting at
  the bytenr we care about.  This obviously isn't the case for prealloc 
  extents,
  where we could have written to the middle of the prealloc extent only, which
  means the csum would be for the bytenr in the middle of our range and not 
  the
  front of our range.  Fix this by offsetting the new bytenr we are logging to
  based on the original bytenr the csum was for.  With this patch I no longer 
  see
  the csum errors I was seeing.  Thanks,
  
  Cc: sta...@vger.kernel.org
 
 The patch had the right CC but I don't see it in the mail's CC list (now
 added by me). I'm afraid that this never reached stable and explains why
 the patch did not end up in 3.12.1.

No, it made it to my list, I was waiting for 3.13-rc1 to come out with
this patch in it before I could queue it up.  Don't worry, it's not
lost.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handful of btrfs fixes for 3.11.x stable

2013-10-10 Thread Greg KH 
On Mon, Oct 07, 2013 at 04:34:43PM -0400, Josef Bacik wrote:
 On Sat, Oct 05, 2013 at 04:52:18PM -0700, Greg KH wrote:
  On Fri, Sep 20, 2013 at 09:53:02AM -0700, Greg KH wrote:
   On Fri, Sep 20, 2013 at 06:34:39PM +0200, David Sterba wrote:
Hi stable team,

please add the following commits to 3.11 tree, they fix user visible 
problems,
were tested and are now present in 3.12-rc1.

3d05ca371200b3366530621abf73769024581b79
b13a004528c3e5eb060a26eee795f5a0da7bfe9f
7ef67ffda91cc0c56f33937bfdf1d057b9ee96ca
ca6d07c1d74bf7ba3083bc31a9aeeaa1d0ad86aa
  
  These git commit ids don't match up to anything in Linus's tree, where
  did you get them from?
  
Josef Bacik (4):
  Btrfs: reset ret in record_one_backref
  Btrfs: change how we queue blocks for backref checking
  Btrfs: skip subvol entries when checking if we've created a dir 
already
  Btrfs: remove ourselves from the cluster list under lock
  
  I can dig through the tree to find these, but I'd prefer if you could
  provide the correct ids to verify I got them right.
  
  Also, what order do I apply them in?
 
 You can commit them in that order (top to bottom), here are their 
 corresponding
 commits
 
 50f1319cb5f7690e4d9de18d1a75ea89296d0e53
 b6c60c8018c4e9beb2f83fc82c09f9d033766571
 a05254143cd183b18002cbba7759a1e4629aa762
 b8d0c69b9469ffd33df30fee3e990f2d4aa68a09

All now applied, thanks.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handful of btrfs fixes for 3.11.x stable

2013-10-06 Thread Greg KH 
On Fri, Sep 20, 2013 at 09:53:02AM -0700, Greg KH wrote:
 On Fri, Sep 20, 2013 at 06:34:39PM +0200, David Sterba wrote:
  Hi stable team,
  
  please add the following commits to 3.11 tree, they fix user visible 
  problems,
  were tested and are now present in 3.12-rc1.
  
  3d05ca371200b3366530621abf73769024581b79
  b13a004528c3e5eb060a26eee795f5a0da7bfe9f
  7ef67ffda91cc0c56f33937bfdf1d057b9ee96ca
  ca6d07c1d74bf7ba3083bc31a9aeeaa1d0ad86aa

These git commit ids don't match up to anything in Linus's tree, where
did you get them from?

  Josef Bacik (4):
Btrfs: reset ret in record_one_backref
Btrfs: change how we queue blocks for backref checking
Btrfs: skip subvol entries when checking if we've created a dir already
Btrfs: remove ourselves from the cluster list under lock

I can dig through the tree to find these, but I'd prefer if you could
provide the correct ids to verify I got them right.

Also, what order do I apply them in?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handful of btrfs fixes for 3.11.x stable

2013-10-01 Thread Greg KH 
On Tue, Oct 01, 2013 at 07:03:44PM +0200, David Sterba wrote:
 Hi Greg,
 
 On Fri, Sep 20, 2013 at 09:53:02AM -0700, Greg KH wrote:
  Thanks for this, I'll queue them up soon.
 
 3.11.3 has been just released and the btrfs fixes are not there nor in
 the stable-queue git repo. There's a fix for a crash that affects
 a number of users. Please queue the patches or let me know what's needed
 to get them to stable tree.

Chris implied that he was going to add them to a tree and then send them
on to me.  So I was waiting.

If this isn't the case, I'll be glad to queue them up for the next round
of kernels.

Chris, any opinions?  Either way is fine for me, it's your call.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handful of btrfs fixes for 3.11.x stable

2013-10-01 Thread Greg KH 
On Wed, Oct 02, 2013 at 01:15:19AM +, Chris Mason wrote:
 Sorry,
 
 I misunderstood and thought you had already queued them.  Both are fine with 
 me.

Ok, no worries, I'll pick them up in the next few days and add them to
the next stable releases.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handful of btrfs fixes for 3.11.x stable

2013-09-20 Thread Greg KH 
On Fri, Sep 20, 2013 at 06:34:39PM +0200, David Sterba wrote:
 Hi stable team,
 
 please add the following commits to 3.11 tree, they fix user visible problems,
 were tested and are now present in 3.12-rc1.
 
 3d05ca371200b3366530621abf73769024581b79
 b13a004528c3e5eb060a26eee795f5a0da7bfe9f
 7ef67ffda91cc0c56f33937bfdf1d057b9ee96ca
 ca6d07c1d74bf7ba3083bc31a9aeeaa1d0ad86aa
 
 Josef Bacik (4):
   Btrfs: reset ret in record_one_backref
   Btrfs: change how we queue blocks for backref checking
   Btrfs: skip subvol entries when checking if we've created a dir already
   Btrfs: remove ourselves from the cluster list under lock

Thanks for this, I'll queue them up soon.  Are any of these applicable
for 3.10 as well?

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] btrfs: don't stop searching after encountering the wrong item

2013-05-06 Thread Greg KH 
On Mon, May 06, 2013 at 07:40:18PM +0200, Gabriel de Perthuis wrote:
 The search ioctl skips items that are too large for a result buffer, but
 inline items of a certain size occuring before any search result is
 found would trigger an overflow and stop the search entirely.
 
 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=57641
 
 Signed-off-by: Gabriel de Perthuis g2p.code+bt...@gmail.com
 ---
  fs/btrfs/ioctl.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

formletter

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.

/formletter
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Btrfs: merge inode_list in __merge_refs

2012-11-08 Thread Greg KH 
On Thu, Nov 08, 2012 at 10:35:19PM +0100, Alexander Block wrote:
 
 Used wrong CC for stable list. Corrected now.

formletter

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.

/formletter
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v4+ hot_track 13/19] debugfs: introduce one function

2012-10-29 Thread Greg KH 
On Mon, Oct 29, 2012 at 12:30:55PM +0800, zwu.ker...@gmail.com wrote:
 From: Zhi Yong Wu wu...@linux.vnet.ibm.com
 
   The debugfs function is used to get expected dentry.

Huh?  Why do you need this?  Why haven't you added documentation for the
function saying what it does?

confused,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v4+ hot_track 13/19] debugfs: introduce one function

2012-10-29 Thread Greg KH 
On Tue, Oct 30, 2012 at 06:25:50AM +0800, Zhi Yong Wu wrote:
 On Tue, Oct 30, 2012 at 2:11 AM, Greg KH gre...@linuxfoundation.org wrote:
  On Mon, Oct 29, 2012 at 12:30:55PM +0800, zwu.ker...@gmail.com wrote:
  From: Zhi Yong Wu wu...@linux.vnet.ibm.com
 
The debugfs function is used to get expected dentry.
 
  Huh?  Why do you need this?  Why haven't you added documentation for the
 It is used to determine if one sysfs directory has been created. OK, i
 will add some doc, thanks for your suggestion.

You didn't answer the why part here.  How come you think you need
this?  Can't you just save off the dentry you created somewhere so you
don't need to look it up again?

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v4+ hot_track 13/19] debugfs: introduce one function

2012-10-29 Thread Greg KH 
On Tue, Oct 30, 2012 at 06:45:19AM +0800, Zhi Yong Wu wrote:
 On Tue, Oct 30, 2012 at 6:34 AM, Greg KH gre...@linuxfoundation.org wrote:
  On Tue, Oct 30, 2012 at 06:25:50AM +0800, Zhi Yong Wu wrote:
  On Tue, Oct 30, 2012 at 2:11 AM, Greg KH gre...@linuxfoundation.org 
  wrote:
   On Mon, Oct 29, 2012 at 12:30:55PM +0800, zwu.ker...@gmail.com wrote:
   From: Zhi Yong Wu wu...@linux.vnet.ibm.com
  
 The debugfs function is used to get expected dentry.
  
   Huh?  Why do you need this?  Why haven't you added documentation for the
  It is used to determine if one sysfs directory has been created. OK, i
  will add some doc, thanks for your suggestion.
 
  You didn't answer the why part here.  How come you think you need
 ah, Let me say its scenario at first. If we do two mount ops as below:
 1.) mount -o loop,hot_track image1 /data1
 2.) mount -o loop,hot_track image2 /data2
 
 The mount -o hot_track operation will automatically create one sysfs
 directory /sys/kernel/debug/hot_track. To prevent this dir being
 created again when 2.) is done, we need to know if it has existed at
 first. In my patch, i at first get its dentry by this new function,
 then determine if its d_inode field is NULL, if no, it means that this
 sysfs dir has existed.
 This is the reason that i want to add one new function.

Why not do like the rest of the kernel does and just have a:
static dentry *hot_track_root;
and use that as your root debugfs directory dentry:

if (!hot_track_root) {
/* Create root directory */
hot_track_root = debugfs_create(...);
}

No need to look anything up :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Btrfs: fix regression in scrub path resolving

2012-04-13 Thread Greg KH 
On Fri, Apr 13, 2012 at 04:58:15PM +0200, Jan Schmidt wrote:
 commit 7a3ae2f8c8c8432e65467b7fc84d5deab04061a0 upstream.
 
 In commit 4692cf58 (Linux 3.3) we introduced new backref walking code for
 btrfs. This assumes we're searching live roots, which requires a transaction
 context. While scrubbing, however, we must not join a transaction because
 this could deadlock with the commit path:
 
 Can be exploited by corrupting data in btrfs (e.g. btrfs-corrupt-block) and
 then starting a scrub job (btrfs scrub). This will find the corrupt block
 and resolve the file paths affected. If that happens while btrfs is about to
 commit its transaction, a deadlock occurs: The scrub process prevents the
 commit from completing, while the path resolving code joins a transaction
 which blocks until the current transaction completes.
 
 Additionally, what scrub really wants to do is resolving a logical address
 in the commit root it's currently checking. This patch adds support for
 logical to path resolving on commit roots and makes scrub use that.
 
 Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
 Signed-off-by: Chris Mason chris.ma...@oracle.com
 ---
 
 I know, it's quite big for a stable patch. Anyway, it fixes a 3.3 regression
 and should therefore be included in the next 3.3-stable release. Tested on
 top of Linux 3.3.1.

I'll include it if Chris gives his ack for it.

Chris?

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: build warninga in Linus' tree

2011-06-03 Thread Greg KH 
On Fri, Jun 03, 2011 at 01:10:49PM +0200, David Sterba wrote:
 On Wed, Jun 01, 2011 at 10:16:48AM -0500, Mitch Harder wrote:
  I've been playing around with resurrecting the basic sysfs
  capabilities that had been previously incorporated into btrfs.
  
  As it stands right now, it was relatively easy to re-implement sysfs
  as it was originally.  However, that implementation of sysfs wasn't
  populated with much information (only total_blocks, blocks_used, and
  blocksize).
 
 Goffredo Baroncelli (CCed) posted a patch to enhance sysfs interface:
 
 https://patchwork.kernel.org/patch/308902/
 (http://www.spinics.net/lists/linux-btrfs/msg06777.html)
 
  I also had to reverse a small portion of code that was in the last
  clean-up.
 
 Restoring the code should not be a problem, the cleanup was too eager
 and I think a sysfs inteface would be good, not only for debugging
 purposes or tuning.
 
  If a CONFIG_BTRFS_DEBUG type configuration flag is ever introduced, it
  would be interesting to resurrect btrfs' sysfs capabilities.
 
 Hearing about CONFIG_BTRFS_DEBUG again, seems worth to add it.

For debugging stuff, please use debugfs instead of sysfs, as that is
what it is there for.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [stable] Dirtiable inode bdi default != sb bdi btrfs

2010-09-26 Thread Greg KH 
On Fri, Sep 24, 2010 at 08:39:41PM +0200, Jens Axboe wrote:
 On 2010-09-23 22:53, Greg KH wrote:
  On Thu, Sep 23, 2010 at 09:40:14PM +0200, Jens Axboe wrote:
  On 2010-09-23 21:38, Andrew Morton wrote:
 
  (Cc sta...@kernel.org)
 
  On Wed, 22 Sep 2010 21:54:30 -0300
  Cesar Eduardo Barros ces...@cesarb.net 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:
[8104d0e4] warn_slowpath_common+0x85/0x9d
[8104d19f] warn_slowpath_fmt+0x46/0x48
[811308b7] inode_to_bdi+0x62/0x6d
[81131b48] __mark_inode_dirty+0xd0/0x177
[81127168] touch_atime+0x107/0x12a
[81122384] ? filldir+0x0/0xd0
[8112259b] vfs_readdir+0x8d/0xb4
[8112270b] sys_getdents+0x81/0xd1
[81009c72] system_call_fastpath+0x16/0x1b
 
  Thanks.  692ebd17c2905313fff3c504c249c6a0faad16ec had a cc:stable in
  the changelog.  I'd suggest it not be merged into -stable until this
  regression is sorted out!
 
  It was just added, I'm discussing this with Chris on irc as I type this.
  But yes, lets not replace a regression with a new regression :-). So
  Greg, please hold off on these for a little while.
  
  Ok, so which ones should I take out of the -stable tree?  Just this one:
  692ebd17c2905313fff3c504c249c6a0faad16ec
  or it and something else?
 
 You can keep 1/2, just hold off on the one labeled:
 
 bdi: Fix warnings in __mark_inode_dirty for /dev/zero and friends
 
 for now. I'm off to Japan in the morning, perhaps Jan can comment
 if he's available.

Ok, now dropped, thanks.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [stable] Dirtiable inode bdi default != sb bdi btrfs

2010-09-23 Thread Greg KH 
On Thu, Sep 23, 2010 at 09:40:14PM +0200, Jens Axboe wrote:
 On 2010-09-23 21:38, Andrew Morton wrote:
  
  (Cc sta...@kernel.org)
  
  On Wed, 22 Sep 2010 21:54:30 -0300
  Cesar Eduardo Barros ces...@cesarb.net 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:
[8104d0e4] warn_slowpath_common+0x85/0x9d
[8104d19f] warn_slowpath_fmt+0x46/0x48
[811308b7] inode_to_bdi+0x62/0x6d
[81131b48] __mark_inode_dirty+0xd0/0x177
[81127168] touch_atime+0x107/0x12a
[81122384] ? filldir+0x0/0xd0
[8112259b] vfs_readdir+0x8d/0xb4
[8112270b] sys_getdents+0x81/0xd1
[81009c72] system_call_fastpath+0x16/0x1b
  
  Thanks.  692ebd17c2905313fff3c504c249c6a0faad16ec had a cc:stable in
  the changelog.  I'd suggest it not be merged into -stable until this
  regression is sorted out!
 
 It was just added, I'm discussing this with Chris on irc as I type this.
 But yes, lets not replace a regression with a new regression :-). So
 Greg, please hold off on these for a little while.

Ok, so which ones should I take out of the -stable tree?  Just this one:
692ebd17c2905313fff3c504c249c6a0faad16ec
or it and something else?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[063/111] Btrfs, fix memory leaks in error paths

2010-08-11 Thread Greg KH 
2.6.32-stable review patch.  If anyone has any objections, please let us know.

--

From: Jiri Slaby jsl...@suse.cz

commit 2423fdfb96e3f9ff3baeb6c4c78d74145547891d upstream.

Stanse found 2 memory leaks in relocate_block_group and
__btrfs_map_block. cluster and multi are not freed/assigned on all
paths. Fix that.

Signed-off-by: Jiri Slaby jsl...@suse.cz
Cc: linux-btrfs@vger.kernel.org
Signed-off-by: Chris Mason chris.ma...@oracle.com
Acked-by: Jeff Mahoney je...@suse.com
Signed-off-by: Greg Kroah-Hartman gre...@suse.de


---
 fs/btrfs/relocation.c |4 +++-
 fs/btrfs/volumes.c|4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -3281,8 +3281,10 @@ static noinline_for_stack int relocate_b
return -ENOMEM;
 
path = btrfs_alloc_path();
-   if (!path)
+   if (!path) {
+   kfree(cluster);
return -ENOMEM;
+   }
 
rc-extents_found = 0;
rc-extents_skipped = 0;
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2649,8 +2649,10 @@ again:
em = lookup_extent_mapping(em_tree, logical, *length);
read_unlock(em_tree-lock);
 
-   if (!em  unplug_page)
+   if (!em  unplug_page) {
+   kfree(multi);
return 0;
+   }
 
if (!em) {
printk(KERN_CRIT unable to find logical %llu len %llu\n,


--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 01/51] fiemap: fix problem with setting FIEMAP_EXTENT_LAST

2009-05-14 Thread Greg KH 
2.6.29-stable review patch.  If anyone has any objections, please let us know.

--

From: Josef Bacik jba...@redhat.com

commit df3935ffd6166fdd00702cf548fb5bb55737758b upstream.

Fix a problem where the generic block based fiemap stuff would not
properly set FIEMAP_EXTENT_LAST on the last extent.  I've reworked things
to keep track if we go past the EOF, and mark the last extent properly.
The problem was reported by and tested by Eric Sandeen.

Tested-by: Eric Sandeen sand...@redhat.com
Signed-off-by: Josef Bacik jba...@redhat.com
Cc: linux-e...@vger.kernel.org
Cc: xfs-mast...@oss.sgi.com
Cc: linux-btrfs@vger.kernel.org
Cc: Steven Whitehouse swhit...@redhat.com
Cc: Mark Fasheh mfas...@suse.com
Cc: Joel Becker joel.bec...@oracle.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Greg Kroah-Hartman gre...@suse.de

---
 fs/ioctl.c |   75 -
 1 file changed, 55 insertions(+), 20 deletions(-)

--- a/fs/ioctl.c
+++ b/fs/ioctl.c
@@ -258,7 +258,7 @@ int __generic_block_fiemap(struct inode 
long long length = 0, map_len = 0;
u64 logical = 0, phys = 0, size = 0;
u32 flags = FIEMAP_EXTENT_MERGED;
-   int ret = 0;
+   int ret = 0, past_eof = 0, whole_file = 0;
 
if ((ret = fiemap_check_flags(fieinfo, FIEMAP_FLAG_SYNC)))
return ret;
@@ -266,6 +266,9 @@ int __generic_block_fiemap(struct inode 
start_blk = logical_to_blk(inode, start);
 
length = (long long)min_t(u64, len, i_size_read(inode));
+   if (length  len)
+   whole_file = 1;
+
map_len = length;
 
do {
@@ -282,11 +285,26 @@ int __generic_block_fiemap(struct inode 
 
/* HOLE */
if (!buffer_mapped(tmp)) {
+   length -= blk_to_logical(inode, 1);
+   start_blk++;
+
+   /*
+* we want to handle the case where there is an
+* allocated block at the front of the file, and then
+* nothing but holes up to the end of the file properly,
+* to make sure that extent at the front gets properly
+* marked with FIEMAP_EXTENT_LAST
+*/
+   if (!past_eof 
+   blk_to_logical(inode, start_blk) =
+   blk_to_logical(inode, 0)+i_size_read(inode))
+   past_eof = 1;
+
/*
 * first hole after going past the EOF, this is our
 * last extent
 */
-   if (length = 0) {
+   if (past_eof  size) {
flags = FIEMAP_EXTENT_MERGED|FIEMAP_EXTENT_LAST;
ret = fiemap_fill_next_extent(fieinfo, logical,
  phys, size,
@@ -294,15 +312,37 @@ int __generic_block_fiemap(struct inode 
break;
}
 
-   length -= blk_to_logical(inode, 1);
-
/* if we have holes up to/past EOF then we're done */
-   if (length = 0)
+   if (length = 0 || past_eof)
break;
-
-   start_blk++;
} else {
-   if (length = 0  size) {
+   /*
+* we have gone over the length of what we wanted to
+* map, and it wasn't the entire file, so add the extent
+* we got last time and exit.
+*
+* This is for the case where say we want to map all the
+* way up to the second to the last block in a file, but
+* the last block is a hole, making the second to last
+* block FIEMAP_EXTENT_LAST.  In this case we want to
+* see if there is a hole after the second to last block
+* so we can mark it properly.  If we found data after
+* we exceeded the length we were requesting, then we
+* are good to go, just add the extent to the fieinfo
+* and break
+*/
+   if (length = 0  !whole_file) {
+   ret = fiemap_fill_next_extent(fieinfo, logical,
+ phys, size,
+ flags);
+   break;
+   }
+
+   /*
+* if size != 0