Re: [PATCH] raid5-cache: add crc32c Kconfig dependency

On Wed, Nov 04 2015, Arnd Bergmann wrote: > The recent change of the raid5-cache code to use crc32c instead > of crc32 causes link errors when CONFIG_LIBCRC32C is disabled: > > drivers/built-in.o: In function crc32c' > core.c:(.text+0x1c6060): undefined reference to `crc32c' > > This adds an

Re: [PATCH] md/raid5: remove redundant check in stripe_add_to_batch_list()

On Mon, Nov 02 2015, Roman Gushchin wrote: > The stripe_add_to_batch_list() function is called only if > stripe_can_batch() returned true, so there is no need for double check. > > Signed-off-by: Roman Gushchin > Cc: Neil Brown > Cc: linux-r...@vger.kernel.org > --- >

Re: [PATCH] md/raid5: remove redundant check in stripe_add_to_batch_list()

On Mon, Nov 02 2015, Roman Gushchin wrote: > The stripe_add_to_batch_list() function is called only if > stripe_can_batch() returned true, so there is no need for double check. > > Signed-off-by: Roman Gushchin <kl...@yandex-team.ru> > Cc: Neil Brown <ne...

Re: [PATCH] raid5-cache: add crc32c Kconfig dependency

On Wed, Nov 04 2015, Arnd Bergmann wrote: > The recent change of the raid5-cache code to use crc32c instead > of crc32 causes link errors when CONFIG_LIBCRC32C is disabled: > > drivers/built-in.o: In function crc32c' > core.c:(.text+0x1c6060): undefined reference to `crc32c' > > This adds an

Re: [PATCH/RFC] make btrfs subvol mounts appear in /proc/mounts

On Tue, Nov 03 2015, Chris Mason wrote: > On Mon, Nov 02, 2015 at 03:50:12PM -0500, J. Bruce Fields wrote: >> On Wed, Oct 28, 2015 at 07:25:10AM +0900, Neil Brown wrote: >> > >> > If you create a subvolume in btrfs and access it (by name) without >> > mounti

Re: [PATCH/RFC] make btrfs subvol mounts appear in /proc/mounts

On Tue, Nov 03 2015, Chris Mason wrote: > On Mon, Nov 02, 2015 at 03:50:12PM -0500, J. Bruce Fields wrote: >> On Wed, Oct 28, 2015 at 07:25:10AM +0900, Neil Brown wrote: >> > >> > If you create a subvolume in btrfs and access it (by name) without >> > mounti

Re: [PATCH 1/3] power, vfs: move away from PF_KTHREAD freezing in favor of fs freezing

On Sat, Oct 31 2015, Oliver Neukum wrote: > On Fri, 2015-10-30 at 14:47 +0100, Jiri Kosina wrote: >> Basically the main argument why kthread freezer is not needed boils >> down to >> this: the only facility that is needed during suspend: "no persistent >> fs >> changes are allowed from now on". >

[GIT PULL REQUEST] md updates for 4.4

The following changes since commit 25cb62b76430a91cc6195f902e61c2cb84ade622: Linux 4.3-rc5 (2015-10-11 11:09:45 -0700) are available in the git repository at: git://neil.brown.name/md tags/md/4.4 for you to fetch changes up to 339421def582abb14c2217aa8c8f28bb2e299174: MD: when RAID

Re: [PATCH 1/3] power, vfs: move away from PF_KTHREAD freezing in favor of fs freezing

On Sat, Oct 31 2015, Oliver Neukum wrote: > On Fri, 2015-10-30 at 14:47 +0100, Jiri Kosina wrote: >> Basically the main argument why kthread freezer is not needed boils >> down to >> this: the only facility that is needed during suspend: "no persistent >> fs >> changes are allowed from now on". >

[GIT PULL REQUEST] md updates for 4.4

The following changes since commit 25cb62b76430a91cc6195f902e61c2cb84ade622: Linux 4.3-rc5 (2015-10-11 11:09:45 -0700) are available in the git repository at: git://neil.brown.name/md tags/md/4.4 for you to fetch changes up to 339421def582abb14c2217aa8c8f28bb2e299174: MD: when RAID

[GIT PULL REQUEST] last minute bug fixes for md.

they just keep coming in :-( The following changes since commit 8bce6d35b308d73cdb2ee273c95d711a55be688c: md/raid10: fix the 'new' raid10 layout to work correctly. (2015-10-24 16:24:25 +1100) are available in the git repository at: git://neil.brown.name/md tags/md/4.3-rc7-fixes for you

Re: [PATCH] md/raid5: fix locking in handle_stripe_clean_event()

On Sat, Oct 31 2015, Shaohua Li wrote: > On Fri, Oct 30, 2015 at 05:02:47PM +0300, Roman Gushchin wrote: >> > Isn't the 4.1 fix just: >> > >> > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c >> > index e5befa356dbe..6e4350a78257 100644 >> > --- a/drivers/md/raid5.c >> > +++

Re: [PATCH] md/raid5: fix locking in handle_stripe_clean_event()

On Sat, Oct 31 2015, Shaohua Li wrote: > On Fri, Oct 30, 2015 at 05:02:47PM +0300, Roman Gushchin wrote: >> > Isn't the 4.1 fix just: >> > >> > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c >> > index e5befa356dbe..6e4350a78257 100644 >> > --- a/drivers/md/raid5.c >> > +++

[GIT PULL REQUEST] last minute bug fixes for md.

they just keep coming in :-( The following changes since commit 8bce6d35b308d73cdb2ee273c95d711a55be688c: md/raid10: fix the 'new' raid10 layout to work correctly. (2015-10-24 16:24:25 +1100) are available in the git repository at: git://neil.brown.name/md tags/md/4.3-rc7-fixes for you

Re: [PATCH] md/raid5: fix locking in handle_stripe_clean_event()

On Fri, Oct 30 2015, Roman Gushchin wrote: > 29.10.2015, 03:35, "Neil Brown" : >> On Wed, Oct 28 2015, Roman Gushchin wrote: >> >>>  After commit 566c09c53455 ("raid5: relieve lock contention in >>> get_active_stripe()") >>

Re: [PATCH] md/raid5: fix locking in handle_stripe_clean_event()

On Fri, Oct 30 2015, Roman Gushchin wrote: > 29.10.2015, 03:35, "Neil Brown" <ne...@suse.de>: >> On Wed, Oct 28 2015, Roman Gushchin wrote: >> >>>  After commit 566c09c53455 ("raid5: relieve lock contention in >>> get_active_stripe()") &

Re: [PATCH] md/raid5: fix locking in handle_stripe_clean_event()

to reproduce this behavior on raid6 over 6 ssd disks. > The devices_handle_discard_safely option should be set to enable trim > support. The following script was used: > > for i in `seq 1 32`; do > dd if=/dev/zero of=large$i bs=10M count=100 & > done > > Signed-off-by: Roman Gushchin &g

Re: [PATCH] md/raid5: fix locking in handle_stripe_clean_event()

to reproduce this behavior on raid6 over 6 ssd disks. > The devices_handle_discard_safely option should be set to enable trim > support. The following script was used: > > for i in `seq 1 32`; do > dd if=/dev/zero of=large$i bs=10M count=100 & > done > > Signed-off-by: Roman Gush

Re: [PATCHv2] Documentation: add new description of path-name lookup.

On Wed, Oct 28 2015, J. Bruce Fields wrote: > On Mon, Oct 26, 2015 at 03:35:54PM +0900, Neil Brown wrote: >> From c38784b876a181eda9a5687e618749157dc96a0e Mon Sep 17 00:00:00 2001 >> From: NeilBrown >> Date: Sat, 25 Jul 2015 10:24:41 +1000 >> Subject: [PATCH] Documen

[PATCH/RFC] make btrfs subvol mounts appear in /proc/mounts

If you create a subvolume in btrfs and access it (by name) without mounting it, then the subvolume looks like a separate mount to some extent, returning a different st_dev to stat(), but it doesn't look like a separate mount in that it isn't listed in /proc/mounts. This inconsistency can confuse

[PATCH/RFC] make btrfs subvol mounts appear in /proc/mounts

If you create a subvolume in btrfs and access it (by name) without mounting it, then the subvolume looks like a separate mount to some extent, returning a different st_dev to stat(), but it doesn't look like a separate mount in that it isn't listed in /proc/mounts. This inconsistency can confuse

Re: [PATCHv2] Documentation: add new description of path-name lookup.

On Wed, Oct 28 2015, J. Bruce Fields wrote: > On Mon, Oct 26, 2015 at 03:35:54PM +0900, Neil Brown wrote: >> From c38784b876a181eda9a5687e618749157dc96a0e Mon Sep 17 00:00:00 2001 >> From: NeilBrown <n...@brown.name> >> Date: Sat, 25 Jul 2015 10:24:41 +1000 >> Su

[PATCHv2] Documentation: add new description of path-name lookup.

https://lwn.net/Articles/650786/> A walk among the symlinks + +Written by Neil Brown with help from Al Viro and Jon Corbet. + +Introduction + + +The most obvious aspect of pathname lookup, which very little +exploration is needed to discover, is that it is complex. There are +many ru

[PATCHv2] Documentation: add new description of path-name lookup.

/Articles/649729/> RCU-walk: faster pathname lookup in Linux +- <https://lwn.net/Articles/650786/> A walk among the symlinks + +Written by Neil Brown with help from Al Viro and Jon Corbet. + +Introduction + + +The most obvious aspect of pathname lookup, which very littl

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

Kristen Accardi writes: > On Oct 22, 2015 7:04 PM, "Neil Brown" wrote: >> >> Darren Hart writes: >> >> > >> > Is there a good description of what is expected of a TAB member? How > much time >> > is involved? What makes a great TAB m

Re: nfs race condition

Nicolas Parpandet writes: > Hello, > > I did some more investigations, (wireshark) > > The unlink of /tmp/crontab.vYPoHR/crontab is tranlated into a rename > nfs call ? (.nfs file) That happens if the file is still open. > > NFS 670 V3 READDIRPLUS Reply (Call In 731) crontab .. . > NFS

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

Darren Hart writes: > > Is there a good description of what is expected of a TAB member? How much time > is involved? What makes a great TAB member? > > I've found: http://www.linuxfoundation.org/programs/advisory-councils/tab > > I've read the charter and scanned some of the minutes, but I'd

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

Darren Hart writes: > > Is there a good description of what is expected of a TAB member? How much time > is involved? What makes a great TAB member? > > I've found: http://www.linuxfoundation.org/programs/advisory-councils/tab > > I've read the charter and scanned some of the minutes, but I'd

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

Darren Hart writes: > > Is there a good description of what is expected of a TAB member? How much time > is involved? What makes a great TAB member? > > I've found: http://www.linuxfoundation.org/programs/advisory-councils/tab > > I've read the charter and scanned some of

Re: nfs race condition

Nicolas Parpandet writes: > Hello, > > I did some more investigations, (wireshark) > > The unlink of /tmp/crontab.vYPoHR/crontab is tranlated into a rename > nfs call ? (.nfs file) That happens if the file is still open. > > NFS 670 V3 READDIRPLUS Reply (Call In 731)

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

Darren Hart writes: > > Is there a good description of what is expected of a TAB member? How much time > is involved? What makes a great TAB member? > > I've found: http://www.linuxfoundation.org/programs/advisory-councils/tab > > I've read the charter and scanned some of

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

Kristen Accardi <kacca...@gmail.com> writes: > On Oct 22, 2015 7:04 PM, "Neil Brown" <ne...@suse.com> wrote: >> >> Darren Hart <dvh...@infradead.org> writes: >> >> > >> > Is there a good description of what is expected of a T

Re: Possible bug in DM-RAID.

Added dm-devel, which is probably the more appropriate list for dm things. NeilBrown Austin S Hemmelgarn writes: > I think I've stumbled upon a bug in DM-RAID. The primary symptom is that when > creating a new DM-RAID based device (using either LVM or dmsetup) in a RAID1 > configuration, it

Re: Possible bug in DM-RAID.

Added dm-devel, which is probably the more appropriate list for dm things. NeilBrown Austin S Hemmelgarn writes: > I think I've stumbled upon a bug in DM-RAID. The primary symptom is that when > creating a new DM-RAID based device (using either LVM or dmsetup) in a

Re: [RFC PATCH 0/3] pwm: omap: Add PWM support using dual-mode timers

Neil Armstrong writes: > This patch is based on an earlier patch by NeilBrown which is based on > a older patch from Grant Erickson which provided PWM devices using > the 'legacy' interface. > > The pwm driver was renamed to not be confused with the OMAP4 PWM dedicated > hardware and was cleaned

Re: [RFC PATCH 0/3] pwm: omap: Add PWM support using dual-mode timers

Neil Armstrong writes: > This patch is based on an earlier patch by NeilBrown which is based on > a older patch from Grant Erickson which provided PWM devices using > the 'legacy' interface. > > The pwm driver was renamed to not be confused with the OMAP4 PWM dedicated >

Re: [PATCH v2] sunrpc: fix waitqueue_active without memory barrier in sunrpc

"J. Bruce Fields" writes: > On Thu, Oct 15, 2015 at 11:44:20AM +, Kosuke Tatsukawa wrote: >> Tatsukawa Kosuke wrote: >> > J. Bruce Fields wrote: >> >> Thanks for the detailed investigation. >> >> >> >> I think it would be worth adding a comment if that might help someone >> >> having to

Re: [PATCH v2] sunrpc: fix waitqueue_active without memory barrier in sunrpc

"J. Bruce Fields" writes: > On Thu, Oct 15, 2015 at 11:44:20AM +, Kosuke Tatsukawa wrote: >> Tatsukawa Kosuke wrote: >> > J. Bruce Fields wrote: >> >> Thanks for the detailed investigation. >> >> >> >> I think it would be worth adding a comment if that might help

Re: [PATCH] md: fix 32-bit build warning

Arnd Bergmann writes: > On Monday 12 October 2015 15:59:27 Neil Brown wrote: >> > diff --git a/drivers/md/md.c b/drivers/md/md.c >> > index 7fff1e6884d6..e13f72a3b561 100644 >> > --- a/drivers/md/md.c >> > +++ b/drivers/md/md.c >> > @@ -8987,9 +898

Re: [PATCH] md: fix 32-bit build warning

Arnd Bergmann <a...@arndb.de> writes: > On Monday 12 October 2015 15:59:27 Neil Brown wrote: >> > diff --git a/drivers/md/md.c b/drivers/md/md.c >> > index 7fff1e6884d6..e13f72a3b561 100644 >> > --- a/drivers/md/md.c >> > +++ b/drivers/m

Re: [PATCH] md: fix 32-bit build warning

Arnd Bergmann writes: > On 32-bit architectures, the md code produces this warning when CONFIG_LDAF > is set: > > drivers/md/md.c: In function 'check_sb_changes': > drivers/md/md.c:8990:10: warning: format '%lu' expects argument of type 'long > unsigned int', but argument 4 has type 'sector_t

Re: [PATCH] md: fix 32-bit build warning

Arnd Bergmann writes: > On 32-bit architectures, the md code produces this warning when CONFIG_LDAF > is set: > > drivers/md/md.c: In function 'check_sb_changes': > drivers/md/md.c:8990:10: warning: format '%lu' expects argument of type 'long > unsigned int', but argument 4 has

[GIT PULL REQUEST] md bugfix

The following changes since commit da6fb7a9e5bd6f04f7e15070f630bdf1ea502841: md/bitmap: don't pass -1 to bitmap_storage_alloc. (2015-10-02 17:24:13 +1000) are available in the git repository at: git://neil.brown.name/md tags/md/4.3-rc4-fix for you to fetch changes up to

[GIT PULL REQUEST] md bugfix

The following changes since commit da6fb7a9e5bd6f04f7e15070f630bdf1ea502841: md/bitmap: don't pass -1 to bitmap_storage_alloc. (2015-10-02 17:24:13 +1000) are available in the git repository at: git://neil.brown.name/md tags/md/4.3-rc4-fix for you to fetch changes up to

Re: [PATCH v2] sunrpc: fix waitqueue_active without memory barrier in sunrpc

Kosuke Tatsukawa writes: > There are several places in net/sunrpc/svcsock.c which calls > waitqueue_active() without calling a memory barrier. Add a memory > barrier just as in wq_has_sleeper(). > > I found this issue when I was looking through the linux source code > for places calling

Re: [PATCH] crash in md-raid1 and md-raid10 due to incorrect list manipulation

Mikulas Patocka writes: > The commit 55ce74d4bfe1b936264c637f39a152d1e5ac (md/raid1: ensure > device failure recorded before write request returns) is causing crash in > the LVM2 testsuite test shell/lvchange-raid.sh. For me the crash is 100% > reproducible. > > The reason for the crash

Re: [PATCH] crash in md-raid1 and md-raid10 due to incorrect list manipulation

Mikulas Patocka writes: > The commit 55ce74d4bfe1b936264c637f39a152d1e5ac (md/raid1: ensure > device failure recorded before write request returns) is causing crash in > the LVM2 testsuite test shell/lvchange-raid.sh. For me the crash is 100% > reproducible. > > The

Re: [PATCH v2] sunrpc: fix waitqueue_active without memory barrier in sunrpc

Kosuke Tatsukawa writes: > There are several places in net/sunrpc/svcsock.c which calls > waitqueue_active() without calling a memory barrier. Add a memory > barrier just as in wq_has_sleeper(). > > I found this issue when I was looking through the linux source code > for

[GIT PULL REQUEST] md fixes for 4.3

Hi Linus, a few md bug fixes. Thanks, NeilBrown The following changes since commit bcee19f424a0d8c26ecf2607b73c690802658b29: Merge branch 'for-4.3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup (2015-09-21 18:26:54 -0700) are available in the git repository at:

[GIT PULL REQUEST] md fixes for 4.3

Hi Linus, a few md bug fixes. Thanks, NeilBrown The following changes since commit bcee19f424a0d8c26ecf2607b73c690802658b29: Merge branch 'for-4.3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup (2015-09-21 18:26:54 -0700) are available in the git repository at:

Re: [PATCH 10/13] twl4030_charger: add software controlled linear charging mode.

Pavel Machek writes: > On Thu 2015-07-30 10:11:24, NeilBrown wrote: >> >> Add a 'continuous' option for usb charging which enables >> the "linear" charging mode of the twl4030. >> >> Linear charging does a good job with not-so-reliable power sources. >> Auto mode does not work well as it

Re: [PATCH 10/13] twl4030_charger: add software controlled linear charging mode.

Pavel Machek writes: > On Thu 2015-07-30 10:11:24, NeilBrown wrote: >> >> Add a 'continuous' option for usb charging which enables >> the "linear" charging mode of the twl4030. >> >> Linear charging does a good job with not-so-reliable power sources. >> Auto mode does not work

Re: [PATCH 1/3] BTRFS: support NFSv2 export

David Sterba writes: > On Fri, May 08, 2015 at 10:16:23AM +1000, NeilBrown wrote: >> The "fh_len" passed to ->fh_to_* is not guaranteed to be that same as >> that returned by encode_fh - it may be larger. >> >> With NFSv2, the filehandle is fixed length, so it may appear longer >> than expected

Re: defects for uses of abs(u64) (was: Re: Regression: can't apply frequency offsets above 1000ppm)

Joe Perches writes: > On Fri, 2015-09-04 at 18:00 -0700, John Stultz wrote: >> On Fri, Sep 4, 2015 at 5:57 PM, John Stultz wrote: >> > On Thu, Sep 3, 2015 at 4:26 AM, Miroslav Lichvar >> > wrote: >> >> On Wed, Sep 02, 2015 at 04:16:00PM -0700, John Stultz wrote: >> >>> On Tue, Sep 1, 2015 at

Re: defects for uses of abs(u64) (was: Re: Regression: can't apply frequency offsets above 1000ppm)

Joe Perches writes: > On Fri, 2015-09-04 at 18:00 -0700, John Stultz wrote: >> On Fri, Sep 4, 2015 at 5:57 PM, John Stultz wrote: >> > On Thu, Sep 3, 2015 at 4:26 AM, Miroslav Lichvar >> > wrote: >> >> On Wed, Sep 02, 2015 at

Re: [PATCH 1/3] BTRFS: support NFSv2 export

David Sterba writes: > On Fri, May 08, 2015 at 10:16:23AM +1000, NeilBrown wrote: >> The "fh_len" passed to ->fh_to_* is not guaranteed to be that same as >> that returned by encode_fh - it may be larger. >> >> With NFSv2, the filehandle is fixed length, so it may appear longer

Re: [PATCH 17/39] md: drop null test before destroy functions

Julia Lawall writes: > Remove unneeded NULL test. > > The semantic patch that makes this change is as follows: > (http://coccinelle.lip6.fr/) > > // > @@ expression x; @@ > -if (x != NULL) > \(kmem_cache_destroy\|mempool_destroy\|dma_pool_destroy\)(x); > // > > Signed-off-by: Julia Lawall >

Re: [PATCH 17/39] md: drop null test before destroy functions

Julia Lawall writes: > Remove unneeded NULL test. > > The semantic patch that makes this change is as follows: > (http://coccinelle.lip6.fr/) > > // > @@ expression x; @@ > -if (x != NULL) > \(kmem_cache_destroy\|mempool_destroy\|dma_pool_destroy\)(x); > // > >

[GIT PULL REQUEST] md updates for 4.3

Please pull these updates. I've already merged with the 'block' tree to resolve a few simple conflicts. Thanks, NeilBrown The following changes since commit 1081230b748de8f03f37f80c53dfa89feda9b8de: Merge branch 'for-4.3/core' of git://git.kernel.dk/linux-block (2015-09-02 13:10:25 -0700)

[GIT PULL REQUEST] md updates for 4.3

Please pull these updates. I've already merged with the 'block' tree to resolve a few simple conflicts. Thanks, NeilBrown The following changes since commit 1081230b748de8f03f37f80c53dfa89feda9b8de: Merge branch 'for-4.3/core' of git://git.kernel.dk/linux-block (2015-09-02 13:10:25 -0700)

Re: [PATCH 03/13] twl4030_charger: correctly handle -EPROBE_DEFER from devm_usb_get_phy_by_node

Kevin Hilman writes: > ping... this boot failure has now landed in mainline sorry, I'm on leave at the moment and travelling so I'm unlikely to be able to look at this properly. I should be able to examine this issue before the end of the month but cannot promise sooner than that (though it is

Re: [PATCH 03/13] twl4030_charger: correctly handle -EPROBE_DEFER from devm_usb_get_phy_by_node

Kevin Hilman writes: > ping... this boot failure has now landed in mainline sorry, I'm on leave at the moment and travelling so I'm unlikely to be able to look at this properly. I should be able to examine this issue before the end of the month but cannot promise sooner

Re: clustered MD

On Wed, 10 Jun 2015 16:07:44 -0500 David Teigland wrote: > On Thu, Jun 11, 2015 at 06:31:31AM +1000, Neil Brown wrote: > > What is your interest in this? I'm always happy for open discussion and > > varied input, but it would help to know to what extent you are a stake > &g

Re: clustered MD

On Wed, 10 Jun 2015 10:01:51 -0500 David Teigland wrote: > Isn't this process what staging is for? No it isn't. Staging is useful for code drops. i.e. multiple other developers want to collaborate to improve some code that the maintainer doesn't want to accept. So it goes into staging, "the

Re: clustered MD

On Wed, 10 Jun 2015 10:01:51 -0500 David Teigland teigl...@redhat.com wrote: Isn't this process what staging is for? No it isn't. Staging is useful for code drops. i.e. multiple other developers want to collaborate to improve some code that the maintainer doesn't want to accept. So it goes

Re: clustered MD

On Wed, 10 Jun 2015 16:07:44 -0500 David Teigland teigl...@redhat.com wrote: On Thu, Jun 11, 2015 at 06:31:31AM +1000, Neil Brown wrote: What is your interest in this? I'm always happy for open discussion and varied input, but it would help to know to what extent you are a stake holder

Re: [PATCH v2 6/8] drivers/md/md.c: Use strreplace

On Tue, 9 Jun 2015 01:26:54 +0200 Rasmus Villemoes wrote: > There's no point in starting over when we meet a '/'. This also > eliminates a stack variable and a little .text. > > Signed-off-by: Rasmus Villemoes > --- > v2: no changes. > > drivers/md/md.c | 4 +--- > 1 file changed, 1

Re: [PATCH v2 6/8] drivers/md/md.c: Use strreplace

On Tue, 9 Jun 2015 01:26:54 +0200 Rasmus Villemoes li...@rasmusvillemoes.dk wrote: There's no point in starting over when we meet a '/'. This also eliminates a stack variable and a little .text. Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk --- v2: no changes.

Re: [PATCH 00/28] Swap over NFS -v16

On Saturday February 23, [EMAIL PROTECTED] wrote: > On Wed, 20 Feb 2008 15:46:10 +0100 Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > Another posting of the full swap over NFS series. > > Well I looked. There's rather a lot of it and I wouldn't pretend to > understand it. But pretending is

Re: [PATCH 00/28] Swap over NFS -v16

On Saturday February 23, [EMAIL PROTECTED] wrote: On Wed, 20 Feb 2008 15:46:10 +0100 Peter Zijlstra [EMAIL PROTECTED] wrote: Another posting of the full swap over NFS series. Well I looked. There's rather a lot of it and I wouldn't pretend to understand it. But pretending is fun :-)

Re: [dm-devel] Re: [PATCH] Implement barrier support for single device DM devices

On Tuesday February 19, [EMAIL PROTECTED] wrote: > On Mon, Feb 18, 2008 at 04:24:27PM +0300, Michael Tokarev wrote: > > First, I still don't understand why in God's sake barriers are "working" > > while regular cache flushes are not. Almost no consumer-grade hard drive > > supports write

Re: [dm-devel] Re: [PATCH] Implement barrier support for single device DM devices

On Monday February 18, [EMAIL PROTECTED] wrote: > > > I'll put it even more strongly. My experience is that disabling write > cache plus disabling barriers is often much faster than enabling both > barriers and write cache enabled, when doing metadata intensive > operations, as long as you have

Re: [dm-devel] Re: [PATCH] Implement barrier support for single device DM devices

On Monday February 18, [EMAIL PROTECTED] wrote: I'll put it even more strongly. My experience is that disabling write cache plus disabling barriers is often much faster than enabling both barriers and write cache enabled, when doing metadata intensive operations, as long as you have a

Re: [dm-devel] Re: [PATCH] Implement barrier support for single device DM devices

On Tuesday February 19, [EMAIL PROTECTED] wrote: On Mon, Feb 18, 2008 at 04:24:27PM +0300, Michael Tokarev wrote: First, I still don't understand why in God's sake barriers are working while regular cache flushes are not. Almost no consumer-grade hard drive supports write barriers, but

Re: [2.6 patch] fs/drop_caches.c: make 2 functions static

On Monday February 18, [EMAIL PROTECTED] wrote: > On Sun, 17 Feb 2008 10:17:46 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > This patch makes the following needlessly global functions static: > > - drop_pagecache() > > - drop_slab() > > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> ..

Re: [2.6 patch] fs/drop_caches.c: make 2 functions static

On Monday February 18, [EMAIL PROTECTED] wrote: On Sun, 17 Feb 2008 10:17:46 +0200 Adrian Bunk [EMAIL PROTECTED] wrote: This patch makes the following needlessly global functions static: - drop_pagecache() - drop_slab() Signed-off-by: Adrian Bunk [EMAIL PROTECTED] .. This was

Re: [PATCH] Documentation/patch-tags, one more time

On Sunday February 17, [EMAIL PROTECTED] wrote: > Neil responding to Linus: > > > "From:" is not a tag. It's a special marker at the *top* > > > > You may be right, but when I email patches to akpm > > Linus wasn't saying you don't need a 'From:' line in this case (as the > *top* line of patches

Re: [PATCH] Documentation/patch-tags, one more time

On Friday February 8, [EMAIL PROTECTED] wrote: > > > On Fri, 8 Feb 2008, Jonathan Corbet wrote: > > + > > +These tags are: > > + > > +From: The original author of the patch. This tag will ensure > > + that credit is properly given when somebody other than the > > +

Re: [PATCH] Documentation/patch-tags, one more time

On Friday February 8, [EMAIL PROTECTED] wrote: On Fri, 8 Feb 2008, Jonathan Corbet wrote: + +These tags are: + +From: The original author of the patch. This tag will ensure + that credit is properly given when somebody other than the + original

Re: [PATCH] Documentation/patch-tags, one more time

On Sunday February 17, [EMAIL PROTECTED] wrote: Neil responding to Linus: From: is not a tag. It's a special marker at the *top* You may be right, but when I email patches to akpm Linus wasn't saying you don't need a 'From:' line in this case (as the *top* line of patches you didn't

[PATCH] ext3 can fail badly when device stops accepting BIO_RW_BARRIER requests.

used, as in the following patch. Thanks, NeilBrown Signed-off-by: Neil Brown <[EMAIL PROTECTED]> diff .prev/fs/jbd/commit.c ./fs/jbd/commit.c --- .prev/fs/jbd/commit.c 2008-02-07 10:01:57.0 +1100 +++ ./fs/jbd/commit.c 2008-02-07 10:04:58.0 +1100 @@ -131,6 +131

[PATCH] ext3 can fail badly when device stops accepting BIO_RW_BARRIER requests.

Signed-off-by: Neil Brown [EMAIL PROTECTED] diff .prev/fs/jbd/commit.c ./fs/jbd/commit.c --- .prev/fs/jbd/commit.c 2008-02-07 10:01:57.0 +1100 +++ ./fs/jbd/commit.c 2008-02-07 10:04:58.0 +1100 @@ -131,6 +131,8 @@ static int journal_write_commit_record(j

Re: Monthly md check == hung machine; how do I debug?

On Tuesday February 5, [EMAIL PROTECTED] wrote: > > I was able to solve the problem, however, like so: > > 132c133 > < # CONFIG_PREEMPT_NONE is not set > --- > > CONFIG_PREEMPT_NONE=y > 134,135c135,136 > < CONFIG_PREEMPT=y > < CONFIG_PREEMPT_BKL=y > --- > > # CONFIG_PREEMPT is not set > > #

Re: Monthly md check == hung machine; how do I debug?

On Tuesday February 5, [EMAIL PROTECTED] wrote: I was able to solve the problem, however, like so: 132c133 # CONFIG_PREEMPT_NONE is not set --- CONFIG_PREEMPT_NONE=y 134,135c135,136 CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y --- # CONFIG_PREEMPT is not set # CONFIG_PREEMPT_BKL is

Re: [BUG] The kernel thread for md RAID1 could cause a md RAID1 array deadlock

tention from raid1d. So we create a new function 'flush_pending_writes' to give that attention, and call it in freeze_array to be sure that we aren't waiting on raid1d. Thanks to "K.Tanaka" <[EMAIL PROTECTED]> for finding and reporting this problem. Cc: "K.Tanaka"

Re: [BUG] The kernel thread for md RAID1 could cause a md RAID1 array deadlock

a new function 'flush_pending_writes' to give that attention, and call it in freeze_array to be sure that we aren't waiting on raid1d. Thanks to K.Tanaka [EMAIL PROTECTED] for finding and reporting this problem. Cc: K.Tanaka [EMAIL PROTECTED] Signed-off-by: Neil Brown [EMAIL PROTECTED] ### Diffstat

Re: do_md_run returned -22 [Was: 2.6.24-rc8-mm1]

On Thursday January 17, [EMAIL PROTECTED] wrote: > On Thu, 17 Jan 2008 16:23:30 +0100 Jiri Slaby <[EMAIL PROTECTED]> wrote: > > > On 01/17/2008 11:35 AM, Andrew Morton wrote: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/ > > > > still the same md

Re: do_md_run returned -22 [Was: 2.6.24-rc8-mm1]

On Thursday January 17, [EMAIL PROTECTED] wrote: On Thu, 17 Jan 2008 16:23:30 +0100 Jiri Slaby [EMAIL PROTECTED] wrote: On 01/17/2008 11:35 AM, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/ still the same md issue

Re: [patch] VFS: extend /proc/mounts

On Thursday January 17, [EMAIL PROTECTED] wrote: > > On Jan 17 2008 00:43, Karel Zak wrote: > >> > >> Seems like a plain bad idea to me. There will be any number of home-made > >> /proc/mounts parsers and we don't know what they do. > > > > So, let's use /proc/mounts_v2 ;-) > > Was not it

Re: [PATCH 001 of 6] md: Fix an occasional deadlock in raid5

On Tuesday January 15, [EMAIL PROTECTED] wrote: > On Wed, 16 Jan 2008 00:09:31 -0700 "Dan Williams" <[EMAIL PROTECTED]> wrote: > > > > heheh. > > > > > > it's really easy to reproduce the hang without the patch -- i could > > > hang the box in under 20 min on 2.6.22+ w/XFS and raid5 on 7x750GB. >

Re: [PATCH 001 of 6] md: Fix an occasional deadlock in raid5

On Tuesday January 15, [EMAIL PROTECTED] wrote: On Wed, 16 Jan 2008 00:09:31 -0700 Dan Williams [EMAIL PROTECTED] wrote: heheh. it's really easy to reproduce the hang without the patch -- i could hang the box in under 20 min on 2.6.22+ w/XFS and raid5 on 7x750GB. i'll try with

Re: [patch] VFS: extend /proc/mounts

On Thursday January 17, [EMAIL PROTECTED] wrote: On Jan 17 2008 00:43, Karel Zak wrote: Seems like a plain bad idea to me. There will be any number of home-made /proc/mounts parsers and we don't know what they do. So, let's use /proc/mounts_v2 ;-) Was not it like don't use /proc

Re: [PATCH 002 of 6] md: Fix use-after-free bug when dropping an rdev from an md array.

ev->mddev before the drop, and we are safe... Comments? NeilBrown Signed-off-by: Neil Brown <[EMAIL PROTECTED]> ### Diffstat output ./drivers/md/md.c | 35 ++- 1 file changed, 26 insertions(+), 9 deletions(-) diff .prev/drivers/md/md.c ./drivers/md/md.c

Re: [PATCH 002 of 6] md: Fix use-after-free bug when dropping an rdev from an md array.

On Monday January 14, [EMAIL PROTECTED] wrote: > On Mon, Jan 14, 2008 at 02:21:45PM +1100, Neil Brown wrote: > > > Maybe it isn't there any more > > > > Once upon a time, when I > >echo remove > /sys/block/mdX/md/dev-YYY/state > > Egads. And j

Re: [PATCH 002 of 6] md: Fix use-after-free bug when dropping an rdev from an md array.

On Monday January 14, [EMAIL PROTECTED] wrote: > On Mon, Jan 14, 2008 at 12:45:31PM +1100, NeilBrown wrote: > > > > Due to possible deadlock issues we need to use a schedule work to > > kobject_del an 'rdev' object from a different thread. > > > > A recent change means that kobject_add no longer

Re: Top 10 kernel oopses for the week ending January 5th, 2008

On Thursday January 10, [EMAIL PROTECTED] wrote: > On Thu, Jan 10, 2008 at 03:13:48PM +1100, Neil Brown wrote: > > > What guarantees that it doesn't happen before we get to callback? AFAICS, > > > nothing whatsoever... > > > > Yes, that's bad isn't it :-) &

Re: [PATCH 3/5] NLM: Have lockd call try_to_freeze

On Sunday January 13, [EMAIL PROTECTED] wrote: > On Thu, 10 Jan 2008 13:01:34 -0500 > Jeff Layton <[EMAIL PROTECTED]> wrote: > > > lockd makes itself freezable, but never calls try_to_freeze(). Have it > > call try_to_freeze() within the main loop. > > > > Signed-off-by: Jeff Layton <[EMAIL

Re: [PATCH 3/5] NLM: Have lockd call try_to_freeze

On Sunday January 13, [EMAIL PROTECTED] wrote: On Thu, 10 Jan 2008 13:01:34 -0500 Jeff Layton [EMAIL PROTECTED] wrote: lockd makes itself freezable, but never calls try_to_freeze(). Have it call try_to_freeze() within the main loop. Signed-off-by: Jeff Layton [EMAIL PROTECTED] ---

Re: Top 10 kernel oopses for the week ending January 5th, 2008

On Thursday January 10, [EMAIL PROTECTED] wrote: On Thu, Jan 10, 2008 at 03:13:48PM +1100, Neil Brown wrote: What guarantees that it doesn't happen before we get to callback? AFAICS, nothing whatsoever... Yes, that's bad isn't it :-) I think I should be using

Re: [PATCH 002 of 6] md: Fix use-after-free bug when dropping an rdev from an md array.

On Monday January 14, [EMAIL PROTECTED] wrote: On Mon, Jan 14, 2008 at 12:45:31PM +1100, NeilBrown wrote: Due to possible deadlock issues we need to use a schedule work to kobject_del an 'rdev' object from a different thread. A recent change means that kobject_add no longer gets a

  1   2   3   4   5   6   7   8   9   10   >