Re: [PATCH v3 00/18] new kAPI for FS_IOC_[GS]ETFLAGS/FS_IOC_FS[GS]ETXATTR

Hi Miklos... While you were sending out v3, I was running xfstests on v2... no orangefs problems with your changes. -Mike On Thu, Mar 25, 2021 at 3:38 PM Miklos Szeredi wrote: > > Thanks for the feedback, I think all comments are addressed. Seems > "fileattr" has won a small majority of

Re: [PATCH 03/33] mm: Implement readahead_control pageset expansion

readahead_expand "tomorrow", but it fits into my plan to get Orangefs the extra pages it needs without me having open-coded page cache code in orangefs_readpage. -Mike On Wed, Feb 17, 2021 at 10:42 AM David Howells wrote: > > Mike Marshall wrote: > > > I plan to try

Re: [PATCH 03/33] mm: Implement readahead_control pageset expansion

I plan to try and use readahead_expand in Orangefs... -Mike On Tue, Feb 16, 2021 at 8:28 AM Matthew Wilcox wrote: > > On Tue, Feb 16, 2021 at 11:32:15AM +0100, Christoph Hellwig wrote: > > On Mon, Feb 15, 2021 at 03:44:52PM +, David Howells wrote: > > > Provide a function,

Re: [PATCH] orangefs: remove redundant assignment to variable ret

Hi Colin... thanks for the patch, I have applied it to the orangefs for-next tree... -Mike On Sun, May 24, 2020 at 6:48 PM Colin King wrote: > > From: Colin Ian King > > The variable ret is being initialized with a value that is > never read and it is being updated later with a new value. The

Re: [PATCH v2] orangefs: convert get_user_pages() --> pin_user_pages()

gt; [2] "Explicit pinning of user-space pages": > > https://lwn.net/Articles/807108/ > > > > Cc: Mike Marshall > > Cc: Martin Brandenburg > > Cc: de...@lists.orangefs.org > > Cc: linux-fsde...@vger.kernel.org > > Signed-off-by: John Hubbard

Re: [PATCH 08/10] orangefs: use attach/detach_page_private

s. > > Cc: Mike Marshall > Cc: Martin Brandenburg > Cc: de...@lists.orangefs.org > Signed-off-by: Guoqing Jiang > --- > No change since RFC V3. > > RFC V2 -> RFC V3 > 1. rename clear_page_private to detach_page_private. > > RFC -> RFC V2 > 1. change the n

Re: [PATCH] orangefs: Add octal zero prefix

Thanks for catching this, I added this patch on top of Linux 5.3-rc6 and ran xfstests on orangefs with no regressions. Acked-by: Mike Marshall -Mike On Tue, Aug 13, 2019 at 6:54 AM Artur Świgoń wrote: > > This patch adds a missing zero to mode 755 specification required to >

Re: [PATCH] orangefs: remove redundant assignment to variable buffer_index

o how to download a source tarball and install from that. -Mike On Tue, May 21, 2019 at 11:04 AM Dan Carpenter wrote: > > On Thu, May 16, 2019 at 12:06:31PM -0400, Mike Marshall wrote: > > Hi Colin... > > > > Thanks for the patch. Before I initialized buffer_index, Dan William

Re: [PATCH] orangefs: remove redundant assignment to variable buffer_index

Hi Colin... Thanks for the patch. Before I initialized buffer_index, Dan Williams sent in a warning that a particular error path could try to use ibuffer_index uninitialized. I could induce the problem he described with one of the xfstests resulting in a crashed kernel. I will try to refactor the

Re: linux-next: manual merge of the vfs tree with the orangefs tree

Hi Stephen... I noticed the conflict too when I added Al's patch series to the orangefs tree we have on next. I understood Linus to say he'd fix the conflict the way you did during the merge window. I guess that means you'll have to keep fixing it on next until then... I hate causing trouble, let

Re: [RFC PATCH 60/62] orangefs: make use of ->free_inode()

Thanks :-) -Mike On Mon, Apr 22, 2019 at 7:10 PM Al Viro wrote: > > On Mon, Apr 22, 2019 at 02:56:57PM -0700, Linus Torvalds wrote: > > On Mon, Apr 22, 2019 at 2:14 PM Mike Marshall wrote: > > > > > > I applied your "new inode method: ->free_inode()&qu

Re: [RFC PATCH 60/62] orangefs: make use of ->free_inode()

etty much a no-op now, so I guess we'll get rid of it... Acked-by: Mike Marshall Thanks... -Mike [root@vm1 linux]# git diff HEAD^ fs/orangefs/super.c diff --git a/fs/orangefs/super.c b/fs/orangefs/super.c index 8fa30c13b7ed..f82ac9373443 100644 --- a/fs/orangefs/super.c +++ b/fs/orangefs/supe

Re: [RESEND PATCH 3/7] mm/gup: Change GUP fast to use flags rather than a write 'bool'

Hi Ira Martin and I looked at your patch and agree that it doesn't change functionality for Orangefs. Reviewed-by: Mike Marshall On Wed, Feb 20, 2019 at 12:32 AM wrote: > > From: Ira Weiny > > To facilitate additional options to get_user_pages_fast() change the > singular

Re: [PATCH 00/19] [V2] orangefs: page cache

I still hit writepages_callback not private! on xfstests generic/127... -Mike On Sun, Oct 7, 2018 at 7:27 PM Martin Brandenburg wrote: > > V2... see https://marc.info/?l=linux-fsdevel=153721507330730=2 > > One important change is the following, without which an unaligned write > may end up

Re: [PATCH 00/19] [V2] orangefs: page cache

I still hit writepages_callback not private! on xfstests generic/127... -Mike On Sun, Oct 7, 2018 at 7:27 PM Martin Brandenburg wrote: > > V2... see https://marc.info/?l=linux-fsdevel=153721507330730=2 > > One important change is the following, without which an unaligned write > may end up

Re: [PATCH] orangefs: rate limit the client not running info message

Thanks... I've applied your patch to 4.19-rc2 and run it through xfstests. It is in my linux-next tree now. I put that in there because I'm really just an old system administrator, and I would always be happy when I could tail dmesg and see some hint at why something wasn't doing as I expected.

Re: [PATCH] orangefs: rate limit the client not running info message

Thanks... I've applied your patch to 4.19-rc2 and run it through xfstests. It is in my linux-next tree now. I put that in there because I'm really just an old system administrator, and I would always be happy when I could tail dmesg and see some hint at why something wasn't doing as I expected.

Re: [PATCH] orangefs: Adding new return type vm_fault_t

Yes, I'd be happy to send it in at the 4.19 merge window... -Mike On Wed, Jul 11, 2018 at 1:56 AM, Souptick Joarder wrote: > On Wed, Jul 11, 2018 at 1:13 AM, Mike Marshall wrote: >> Hi... >> >> I applied this patch to 4.18.0-rc4. It applied cleanly and there's no >&

Re: [PATCH] orangefs: Adding new return type vm_fault_t

Yes, I'd be happy to send it in at the 4.19 merge window... -Mike On Wed, Jul 11, 2018 at 1:56 AM, Souptick Joarder wrote: > On Wed, Jul 11, 2018 at 1:13 AM, Mike Marshall wrote: >> Hi... >> >> I applied this patch to 4.18.0-rc4. It applied cleanly and there's no >&

Re: [PATCH] orangefs: Adding new return type vm_fault_t

Hi... I applied this patch to 4.18.0-rc4. It applied cleanly and there's no xfstests regressions. Sorry if I held you up any... You can add: Tested-By: Mike Marshall -Mike On Fri, Jul 6, 2018 at 10:05 AM, Mike Marshall wrote: > Souptick Joarder: Any comment for this patch? > &g

Re: [PATCH] orangefs: Adding new return type vm_fault_t

Hi... I applied this patch to 4.18.0-rc4. It applied cleanly and there's no xfstests regressions. Sorry if I held you up any... You can add: Tested-By: Mike Marshall -Mike On Fri, Jul 6, 2018 at 10:05 AM, Mike Marshall wrote: > Souptick Joarder: Any comment for this patch? > &g

Re: [PATCH] orangefs: Adding new return type vm_fault_t

Souptick Joarder: Any comment for this patch? Thanks for sending it ... I have it in my stack, but I haven't studied it, or xfstested it yet, so no useful comments yet... -Mike On Fri, Jul 6, 2018 at 2:44 AM, Souptick Joarder wrote: > On Fri, Jun 29, 2018 at 12:12 AM, Souptick Joarder >

Re: [PATCH] orangefs: Adding new return type vm_fault_t

Souptick Joarder: Any comment for this patch? Thanks for sending it ... I have it in my stack, but I haven't studied it, or xfstested it yet, so no useful comments yet... -Mike On Fri, Jul 6, 2018 at 2:44 AM, Souptick Joarder wrote: > On Fri, Jun 29, 2018 at 12:12 AM, Souptick Joarder >

Re: [PATCH 4.13 001/109] orangefs: Dont clear SGID when inheriting ACLs

CLs. That > prevents SGID bit clearing and the mode has been properly set by > posix_acl_create() anyway. > > Fixes: 073931017b49d9458aa351605b43a7e34598caef > CC: sta...@vger.kernel.org > CC: Mike Marshall <hub...@omnibond.com> > CC: pvfs2-develop...@beowulf-under

Re: [PATCH 4.13 001/109] orangefs: Dont clear SGID when inheriting ACLs

as been properly set by > posix_acl_create() anyway. > > Fixes: 073931017b49d9458aa351605b43a7e34598caef > CC: sta...@vger.kernel.org > CC: Mike Marshall > CC: pvfs2-develop...@beowulf-underground.org > Signed-off-by: Jan Kara > Signed-off-by: Mike Marshal

Re: [PATCH v3 05/20] orangefs: don't call filemap_write_and_wait from fsync

I've been running it here... Acked-by: Mike Marshall <hub...@omnibond.com> On Mon, Apr 24, 2017 at 11:23 AM, Christoph Hellwig <h...@infradead.org> wrote: > Looks fine, > > Reviewed-by: Christoph Hellwig <h...@lst.de>

Re: [PATCH v3 05/20] orangefs: don't call filemap_write_and_wait from fsync

I've been running it here... Acked-by: Mike Marshall On Mon, Apr 24, 2017 at 11:23 AM, Christoph Hellwig wrote: > Looks fine, > > Reviewed-by: Christoph Hellwig

Re: [PATCH] orangefs: free superblock when mount fails

ACK. I tried to mount orangefs with a nonsense option and got: [96967.205842] [96967.206439] [ BUG: lock held when returning to user space! ] [96967.207046] 4.10.0-8-g554ce8b #2 Not tainted [96967.207531]

Re: [PATCH] orangefs: free superblock when mount fails

ACK. I tried to mount orangefs with a nonsense option and got: [96967.205842] [96967.206439] [ BUG: lock held when returning to user space! ] [96967.207046] 4.10.0-8-g554ce8b #2 Not tainted [96967.207531]

Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing

This is a reply to a thread from back in Nov 2016... Linus> The thing is, with function tracing, you *can* get the return value Linus> and arguments. Sure, you'll probably need to write eBPF and just Linus> attach it to that fentry call point, and yes, if something is inlined Linus> you're just

Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing

This is a reply to a thread from back in Nov 2016... Linus> The thing is, with function tracing, you *can* get the return value Linus> and arguments. Sure, you'll probably need to write eBPF and just Linus> attach it to that fentry call point, and yes, if something is inlined Linus> you're just

Re: [RFC][PATCH 07/10] orangefs: Use RCU for destroy_inode

edhat.com> wrote: > Mike Marshall <hub...@omnibond.com> wrote: > >> Using the git log, I searched back to where it seems to me call_rcu was >> added, a giant patch from 2005 by David Howells which includes tons of >> source and a large amount of documentation. > &

Re: [RFC][PATCH 07/10] orangefs: Use RCU for destroy_inode

Hi... sorry if I got the attribution wrong... the commit I studied was: commit 76d8aeabfeb1c42641a81c44280177b9a08670d8 Author: David Howells Date: Thu Jun 23 22:00:49 2005 -0700 It was huge ... -Mike On Mon, Feb 27, 2017 at 3:44 AM, David Howells wrote: > Mike Marshall wr

Re: [RFC][PATCH 07/10] orangefs: Use RCU for destroy_inode

from rcu-walk when d_revalidate returns ECHILD (which it does right away). -Mike On Sat, Feb 25, 2017 at 3:31 PM, Mike Marshall <hub...@omnibond.com> wrote: > After looking through the code and seeing how some other filesystems > use call_rcu, it seems that call_rcu has to do with

Re: [RFC][PATCH 07/10] orangefs: Use RCU for destroy_inode

from rcu-walk when d_revalidate returns ECHILD (which it does right away). -Mike On Sat, Feb 25, 2017 at 3:31 PM, Mike Marshall wrote: > After looking through the code and seeing how some other filesystems > use call_rcu, it seems that call_rcu has to do with consistency and > waiting

Re: [RFC][PATCH 07/10] orangefs: Use RCU for destroy_inode

of stuff... Is that a "close enough" description of the error that is being fixed here? -Mike On Fri, Feb 24, 2017 at 6:00 PM, Mike Marshall <hub...@omnibond.com> wrote: > Thanks Al... I was going to try and evaluate that patch next > week, now all I have to do is test it ... >

Re: [RFC][PATCH 07/10] orangefs: Use RCU for destroy_inode

of stuff... Is that a "close enough" description of the error that is being fixed here? -Mike On Fri, Feb 24, 2017 at 6:00 PM, Mike Marshall wrote: > Thanks Al... I was going to try and evaluate that patch next > week, now all I have to do is test it ... > > -Mike > > On

Re: [RFC][PATCH 07/10] orangefs: Use RCU for destroy_inode

Thanks Al... I was going to try and evaluate that patch next week, now all I have to do is test it ... -Mike On Fri, Feb 24, 2017 at 3:52 PM, Al Viro wrote: > That, AFAICS, fixes a real bug. Applied, and it needs Cc:stable as well. > > >> Signed-off-by: Peter Zijlstra

Re: [RFC][PATCH 07/10] orangefs: Use RCU for destroy_inode

Thanks Al... I was going to try and evaluate that patch next week, now all I have to do is test it ... -Mike On Fri, Feb 24, 2017 at 3:52 PM, Al Viro wrote: > That, AFAICS, fixes a real bug. Applied, and it needs Cc:stable as well. > > >> Signed-off-by: Peter Zijlstra (Intel) >> --- >>

Re: [patch] orangefs: cleanup orangefs_debugfs_new_client_string()

Hi Dan... Your patch applies, and compiles, and works. Thanks! 1) Al Viro tried to get me to fix all the places where I returned wrong error codes before we went upstream, I guess I slipped some by him ... 2) Some system administrators have admonished me because of a place where I put

Re: [patch] orangefs: cleanup orangefs_debugfs_new_client_string()

Hi Dan... Your patch applies, and compiles, and works. Thanks! 1) Al Viro tried to get me to fix all the places where I returned wrong error codes before we went upstream, I guess I slipped some by him ... 2) Some system administrators have admonished me because of a place where I put

Re: [PATCH] orangefs: Axe some dead code

al intent on posting to this thread was to let christophe.jail...@wanadoo.fr know that I saw and appreciate his review and the good patch he supplied. -Mike On Mon, Nov 28, 2016 at 6:07 AM, Dan Carpenter <dan.carpen...@oracle.com> wrote: > On Sat, Nov 26, 2016 at 08:51:57AM -0500, Mike

Re: [PATCH] orangefs: Axe some dead code

al intent on posting to this thread was to let christophe.jail...@wanadoo.fr know that I saw and appreciate his review and the good patch he supplied. -Mike On Mon, Nov 28, 2016 at 6:07 AM, Dan Carpenter wrote: > On Sat, Nov 26, 2016 at 08:51:57AM -0500, Mike Marshall wrote: >> I think I

Re: [PATCH] orangefs: Axe some dead code

M, Dan Carpenter <dan.carpen...@oracle.com> wrote: > On Fri, Nov 25, 2016 at 06:09:39PM -0500, Mike Marshall wrote: >> We're on rc7 now. Linus said in LWN that there might be a rc8 this time. >> I'll try to get this pulled in 4.9-rc8 I hope, or sometime in 4.10... >> it

Re: [PATCH] orangefs: Axe some dead code

M, Dan Carpenter wrote: > On Fri, Nov 25, 2016 at 06:09:39PM -0500, Mike Marshall wrote: >> We're on rc7 now. Linus said in LWN that there might be a rc8 this time. >> I'll try to get this pulled in 4.9-rc8 I hope, or sometime in 4.10... >> it is just a >> few lines of co

Re: [PATCH] orangefs: Axe some dead code

<dan.carpen...@oracle.com> wrote: > On Thu, Nov 24, 2016 at 07:31:11AM -0500, Mike Marshall wrote: >> This seems like a good and proper patch to me, and simple too. >> But like all changes, it needs tested. While I was testing it, I >> discovered a regression in the associated use

Re: [PATCH] orangefs: Axe some dead code

: > On Thu, Nov 24, 2016 at 07:31:11AM -0500, Mike Marshall wrote: >> This seems like a good and proper patch to me, and simple too. >> But like all changes, it needs tested. While I was testing it, I >> discovered a regression in the associated userspace code. I >

Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing

> We do have filesystem code that is just disgusting. As an example: > fs/afs/ tends to have these crazy "_enter()/_exit()" macros in every > single function. Hmmm... we have "gossip" statements in Orangefs which can be triggered with a debugfs knob... lots of functions have a gossip statement at

Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing

> We do have filesystem code that is just disgusting. As an example: > fs/afs/ tends to have these crazy "_enter()/_exit()" macros in every > single function. Hmmm... we have "gossip" statements in Orangefs which can be triggered with a debugfs knob... lots of functions have a gossip statement at

Re: [PATCH] orangefs: Axe some dead code

This seems like a good and proper patch to me, and simple too. But like all changes, it needs tested. While I was testing it, I discovered a regression in the associated userspace code. I "bisected" (we use SVN for the userspace part of Orangefs) down to the commit that caused the regression, and

Re: [PATCH] orangefs: Axe some dead code

This seems like a good and proper patch to me, and simple too. But like all changes, it needs tested. While I was testing it, I discovered a regression in the associated userspace code. I "bisected" (we use SVN for the userspace part of Orangefs) down to the commit that caused the regression, and

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

, Nikolaus Rath <nikol...@rath.org> wrote: > On Nov 11 2016, Mike Marshall <hub...@omnibond.com> wrote: >> On Fri, Nov 11, 2016 at 11:28 AM, Nikolaus Rath <nikol...@rath.org> wrote: >>> On Nov 11 2016, Miklos Szeredi <mszer...@redhat.com> wrote: >>&

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

, Nikolaus Rath wrote: > On Nov 11 2016, Mike Marshall wrote: >> On Fri, Nov 11, 2016 at 11:28 AM, Nikolaus Rath wrote: >>> On Nov 11 2016, Miklos Szeredi wrote: >>>> On Fri, Nov 11, 2016 at 5:57 AM, Nikolaus Rath wrote: >>>>> On Nov 11 2016, Miklo

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

I try to choose error codes from the appropriate man page when vfs calls into Orangefs with whatever_operations.action... there's probably better ways, like reading the vfs code and seeing what it expects ... -Mike On Fri, Nov 11, 2016 at 11:28 AM, Nikolaus Rath wrote: > On

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

I try to choose error codes from the appropriate man page when vfs calls into Orangefs with whatever_operations.action... there's probably better ways, like reading the vfs code and seeing what it expects ... -Mike On Fri, Nov 11, 2016 at 11:28 AM, Nikolaus Rath wrote: > On Nov 11 2016, Miklos

Re: [RFC] writev() semantics with invalid iovec in the middle

If you squeeze out every byte won't you still have a short write? And the written data wouldn't be cut at the bad place, but it would have a weird hole or discontinuity there. -Mike On Wed, Sep 14, 2016 at 5:34 PM, Al Viro wrote: > Right now writev() with

Re: [RFC] writev() semantics with invalid iovec in the middle

If you squeeze out every byte won't you still have a short write? And the written data wouldn't be cut at the bad place, but it would have a weird hole or discontinuity there. -Mike On Wed, Sep 14, 2016 at 5:34 PM, Al Viro wrote: > Right now writev() with 3-iovec array that has unmapped

Re: [PATCH 4/7] fs: make remaining filesystems use .rename2

I looked at this in today's linux-next and ran a few renames through... Acked-by:: Mike Marshall <hub...@omnibond.com> On Tue, Aug 23, 2016 at 10:47 AM, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Tue, Aug 23, 2016 at 04:05:29PM +0200, Miklos Szeredi wrote: >

Re: [PATCH 4/7] fs: make remaining filesystems use .rename2

I looked at this in today's linux-next and ran a few renames through... Acked-by:: Mike Marshall On Tue, Aug 23, 2016 at 10:47 AM, Greg Kroah-Hartman wrote: > On Tue, Aug 23, 2016 at 04:05:29PM +0200, Miklos Szeredi wrote: >> This is trivial to do: >> >> - add flags a

Re: problem with 731c7d3, "main drm pull request for 4.8"

c M include On Fri, Aug 5, 2016 at 5:13 AM, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > On Thu, Aug 04, 2016 at 02:08:46PM -0400, Mike Marshall wrote: >> [1.291797] [drm] Initialized drm 1.1.0 20060810 >> [1.352761] [TTM] Zone kernel: Available graphics memory: 50

Re: problem with 731c7d3, "main drm pull request for 4.8"

04 e654349841a764813d619343df5c2deda93148bf 83fdb89bb101b2f8b22c001f9cc8cd47cbad097a M drivers :04 04 bfd0ebacfefef860a715434678f4606fd94deb08 cc108eafc28a85299aacb9895f9a1a50e0fa78fc M include On Fri, Aug 5, 2016 at 5:13 AM, Chris Wilson wrote: > On Thu, Aug 04, 2016 at 02:08:46PM -0

problem with 731c7d3, "main drm pull request for 4.8"

Hi... I've noticed the last couple of days that I can't boot Linus' tree of the day on my VM... I was moving backwards a day at a time to find one that would boot so I could bisect, when I landed on 731c7d3, Dave Airlie's "main drm pull request for 4.8" and saw "I'm down with a cold at the

problem with 731c7d3, "main drm pull request for 4.8"

Hi... I've noticed the last couple of days that I can't boot Linus' tree of the day on my VM... I was moving backwards a day at a time to find one that would boot so I could bisect, when I landed on 731c7d3, Dave Airlie's "main drm pull request for 4.8" and saw "I'm down with a cold at the

Re: [PATCH -next] orangefs: use vzalloc() instead of vmalloc()/memset(0)

@perches.com> wrote: > On Wed, 2016-07-06 at 14:00 -0400, Mike Marshall wrote: >> Hi Joe... > > Hi Mike. > >> I looked around at other code to see how they were using vzalloc... >> even if it is just the caller of the function that uses vzalloc, most >> fs's t

Re: [PATCH -next] orangefs: use vzalloc() instead of vmalloc()/memset(0)

> On Wed, 2016-07-06 at 14:00 -0400, Mike Marshall wrote: >> Hi Joe... > > Hi Mike. > >> I looked around at other code to see how they were using vzalloc... >> even if it is just the caller of the function that uses vzalloc, most >> fs's that use vzalloc print an e

Re: [PATCH -next] orangefs: use vzalloc() instead of vmalloc()/memset(0)

with the gossip statements... -Mike On Wed, Jul 6, 2016 at 1:49 PM, Joe Perches <j...@perches.com> wrote: > On Wed, 2016-07-06 at 13:28 -0400, Mike Marshall wrote: >> Wei... >> >> I have applied your patch and tested it, it seems good. >> >> The gossip statement s

Re: [PATCH -next] orangefs: use vzalloc() instead of vmalloc()/memset(0)

with the gossip statements... -Mike On Wed, Jul 6, 2016 at 1:49 PM, Joe Perches wrote: > On Wed, 2016-07-06 at 13:28 -0400, Mike Marshall wrote: >> Wei... >> >> I have applied your patch and tested it, it seems good. >> >> The gossip statement still references vmalloc, I us

Re: [PATCH -next] orangefs: use vzalloc() instead of vmalloc()/memset(0)

Wei... I have applied your patch and tested it, it seems good. The gossip statement still references vmalloc, I used "git commit --amend" to fix that for my test. I'll do the same when I push to kernel.org too, if you're OK with that, unless you want to fix it yourself and resend the patch...

Re: [PATCH -next] orangefs: use vzalloc() instead of vmalloc()/memset(0)

Wei... I have applied your patch and tested it, it seems good. The gossip statement still references vmalloc, I used "git commit --amend" to fix that for my test. I'll do the same when I push to kernel.org too, if you're OK with that, unless you want to fix it yourself and resend the patch...

Re: [PATCH] orangefs: fix namespace handling

Your suggestions make sense to me, especially after looking at how other filesystems use init_user_ns... As far as kicking us out of the Kernel, good grief, I hope not, it was hard getting into the kernel! -Mike On Sat, Jun 25, 2016 at 12:29 AM, Eric W. Biederman wrote:

Re: [PATCH] orangefs: fix namespace handling

Your suggestions make sense to me, especially after looking at how other filesystems use init_user_ns... As far as kicking us out of the Kernel, good grief, I hope not, it was hard getting into the kernel! -Mike On Sat, Jun 25, 2016 at 12:29 AM, Eric W. Biederman wrote: > Jann Horn writes: >

Re: [RFC PATCH v2] ACPICA / Hardware: Fix old register check in acpi_hw_get_access_bit_width()

Hi Lv... I was dead in the water before this patch, qemu-kvm would crash right away, now everything seems to work great again, thanks! From my perspective this fixes the c3bc26d problem. Acked-by: Mike Marshall <hub...@omnibond.com> -Mike On Tue, May 31, 2016 at 3:13 AM, Zheng, Lv

Re: [RFC PATCH v2] ACPICA / Hardware: Fix old register check in acpi_hw_get_access_bit_width()

Hi Lv... I was dead in the water before this patch, qemu-kvm would crash right away, now everything seems to work great again, thanks! From my perspective this fixes the c3bc26d problem. Acked-by: Mike Marshall -Mike On Tue, May 31, 2016 at 3:13 AM, Zheng, Lv wrote: > Hi, Boris and M

[GIT PULL] Orangefs: cleanups and a strncpy vulnerability fix

nerability. Joe Perches (1): orangefs: Add KERN_ to gossip_ macros Martin Brandenburg (3): orangefs: clean up truncate ctime and mtime setting orangefs: strncpy -> strscpy orangefs: remove unused variable Mik

[GIT PULL] Orangefs: cleanups and a strncpy vulnerability fix

nerability. Joe Perches (1): orangefs: Add KERN_ to gossip_ macros Martin Brandenburg (3): orangefs: clean up truncate ctime and mtime setting orangefs: strncpy -> strscpy orangefs: remove unused variable Mik

Re: [PATCH 2/3] orangefs: strncpy -> strlcpy

It looks like strscpy went in last October... there are no users of it yet. I was just about to send in a pull request that includes Martin's strncpy->strlcpy patch when I saw Andy's comment. Linus said when he pulled strscpy: > So I'm pulling the strscpy() support because it *is* a better

Re: [PATCH 2/3] orangefs: strncpy -> strlcpy

It looks like strscpy went in last October... there are no users of it yet. I was just about to send in a pull request that includes Martin's strncpy->strlcpy patch when I saw Andy's comment. Linus said when he pulled strscpy: > So I'm pulling the strscpy() support because it *is* a better

Re: [git pull] orangefs bugfixes for rc2

It will be easy for him to get me to sign it when I get home from the LF Summit. I am, more slowly than Martin, working on another pull request for you, mostly with some stuff from the linux-next robots. I'll guess I should base my pull request on rc2 since that will have Martin's patches in

Re: [git pull] orangefs bugfixes for rc2

It will be easy for him to get me to sign it when I get home from the LF Summit. I am, more slowly than Martin, working on another pull request for you, mostly with some stuff from the linux-next robots. I'll guess I should base my pull request on rc2 since that will have Martin's patches in

Re: [git pull] orangefs bugfixes for rc2

sorry to follow up my own post... perhaps we should point our pull requests at Al and base them on one of Al's trees? I'm sure all this should be easy, we're just clumsy 'cause we're new... -Mike On Thu, Mar 31, 2016 at 5:01 PM, Mike Marshall <hub...@omnibond.com> wrote: > Hi everyone..

Re: [git pull] orangefs bugfixes for rc2

sorry to follow up my own post... perhaps we should point our pull requests at Al and base them on one of Al's trees? I'm sure all this should be easy, we're just clumsy 'cause we're new... -Mike On Thu, Mar 31, 2016 at 5:01 PM, Mike Marshall wrote: > Hi everyone... > > I'm at

Re: [git pull] orangefs bugfixes for rc2

Hi everyone... I'm at the Linux Foundation meeting at Tahoe, I've been asking around some, I know we need to do things differently now that we are upstream... there's several things in my mailbox besides what Martin has done that need to go up... I think we need, during the rc period, to post

Re: [git pull] orangefs bugfixes for rc2

Hi everyone... I'm at the Linux Foundation meeting at Tahoe, I've been asking around some, I know we need to do things differently now that we are upstream... there's several things in my mailbox besides what Martin has done that need to go up... I think we need, during the rc period, to post

Re: [PATCH] OrangeFS: constify export_operations structures

I checked with Stephen Rothwell too, and he agrees with y'all that there should be a Orangefs stanza in the MAINTAINERS file... it will be there next time I push to kernel.org... Thanks! -Mike On Mon, Jan 4, 2016 at 1:45 PM, Dan Carpenter wrote: > On Mon, Jan 04, 2016 at 11:18:00AM -0500, M

Re: [PATCH] OrangeFS: constify export_operations structures

04, 2016 at 11:18:00AM -0500, Mike Marshall wrote: >> Hi Julia... thanks for the patch... I've applied it to my github repo, >> so it will be in the next push to kernel.org. >> >> Orangefs is still out-of-tree (only temporarily I hope ;-) so I guess I >> d

Re: [PATCH] OrangeFS: constify export_operations structures

Hi Julia... thanks for the patch... I've applied it to my github repo, so it will be in the next push to kernel.org. Orangefs is still out-of-tree (only temporarily I hope ;-) so I guess I don't belong in the MAINTAINERS file yet... -Mike On Fri, Jan 1, 2016 at 4:01 AM, Julia Lawall wrote: >

Re: [PATCH] OrangeFS: constify export_operations structures

Hi Julia... thanks for the patch... I've applied it to my github repo, so it will be in the next push to kernel.org. Orangefs is still out-of-tree (only temporarily I hope ;-) so I guess I don't belong in the MAINTAINERS file yet... -Mike On Fri, Jan 1, 2016 at 4:01 AM, Julia Lawall

Re: linux-next: build failure after merge of the vfs tree

> Said that, there is an unpleasant bug in that area - link_target of a live > inode can be overwritten, right under the pathname resolution walking the > old contents of that thing Figuring that out is on the list. This week I've been working on cleaning up orangefs_devreq_writev, and Martin

Re: linux-next: build failure after merge of the vfs tree

> Said that, there is an unpleasant bug in that area - link_target of a live > inode can be overwritten, right under the pathname resolution walking the > old contents of that thing Figuring that out is on the list. This week I've been working on cleaning up orangefs_devreq_writev, and Martin

Re: linux-next: build failure after merge of the vfs tree

Hi all... I'm having a chicken-and-egg moment here... I think "posix acls: Remove duplicate xattr name definitions" got into linux-next after Linus committed Linux 4.4-rc4. Unless I merge my for-next with Linus' tree at the current (arbitrary) point, I need to wait until I can merge with rc5

Re: linux-next: build failure after merge of the vfs tree

Hi all... I'm having a chicken-and-egg moment here... I think "posix acls: Remove duplicate xattr name definitions" got into linux-next after Linus committed Linux 4.4-rc4. Unless I merge my for-next with Linus' tree at the current (arbitrary) point, I need to wait until I can merge with rc5

Re: fs: out of bounds on stack in iov_iter_advance

ct buffer_index_array during update. * readdir_index_array - a five (PVFS2_READDIR_DEFAULT_DESC_COUNT) element int array used to indicate which of the readdir block's chunks are available to use. * readdir_index_lock - a spinlock to protect readdir_index_array during update. On Wed, Nov 11, 2015 at 11:36

Re: fs: out of bounds on stack in iov_iter_advance

I'm the Orangefs guy... If the orangefs warnings that people see because of what's in linux-next is annoying, I could focus on quieting them down... We've been focusing on code review and documentation ever since our last big exchange with Al and Linus... -Mike On Wed, Nov 11, 2015 at 5:28 AM,

Re: fs: out of bounds on stack in iov_iter_advance

6 AM, Al Viro <v...@zeniv.linux.org.uk> wrote: > On Wed, Nov 11, 2015 at 11:25:17AM -0500, Mike Marshall wrote: >> I'm the Orangefs guy... >> >> If the orangefs warnings that people see because of what's in >> linux-next is annoying, I could focus on quiet

Re: fs: out of bounds on stack in iov_iter_advance

I'm the Orangefs guy... If the orangefs warnings that people see because of what's in linux-next is annoying, I could focus on quieting them down... We've been focusing on code review and documentation ever since our last big exchange with Al and Linus... -Mike On Wed, Nov 11, 2015 at 5:28 AM,

Re: [linux-next:master 2506/4558] fs/orangefs/pvfs2-sysfs.c:753:5: sparse: symbol 'sysfs_service_op_show' was not declared. Should it be static?

I have fixed most of the sparse complaints and posted the patch. I use "git send-email" and have tried to tie the addendums to the original patch set with the message-id in "In-Reply-To:" and "References:" message headers... if "fold the followup patch" means something different, please let me

Re: [linux-next:master 2506/4558] fs/orangefs/pvfs2-sysfs.c:753:5: sparse: symbol 'sysfs_service_op_show' was not declared. Should it be static?

I have fixed most of the sparse complaints and posted the patch. I use git send-email and have tried to tie the addendums to the original patch set with the message-id in In-Reply-To: and References: message headers... if fold the followup patch means something different, please let me know g...

Re: [PATCH v3 00/13] locks: saner method for managing file locks

(filp, fl, NULL); return rc; } -Mike On Mon, Feb 2, 2015 at 3:42 PM, Jeff Layton wrote: > On Mon, 2 Feb 2015 15:29:33 -0500 > Mike Marshall wrote: > >> I applied Jeff's patch to my orangefs-3.19-rc5 tree. Orangefs >> doesn't yet support the lock callout for file_opera

Re: [PATCH v3 00/13] locks: saner method for managing file locks

(filp, fl, NULL); return rc; } -Mike On Mon, Feb 2, 2015 at 3:42 PM, Jeff Layton jeff.lay...@primarydata.com wrote: On Mon, 2 Feb 2015 15:29:33 -0500 Mike Marshall hub...@omnibond.com wrote: I applied Jeff's patch to my orangefs-3.19-rc5 tree. Orangefs doesn't yet support the lock

Re: [PATCH v3 00/13] locks: saner method for managing file locks

I applied Jeff's patch to my orangefs-3.19-rc5 tree. Orangefs doesn't yet support the lock callout for file_operations, but we have been experimenting with some ideas that would allow Orangefs to honor locks in our distributed environment: basically posix locks for each kernel client plus meta

  1   2   >