Hi Al,
On Wed, 11 Nov 2015 16:33:39 + Al Viro wrote:
>
> On Wed, Nov 11, 2015 at 10:19:48AM +, Al Viro wrote:
>
> > I'll cook the minimal fixup for API change after I get some sleep and
> > send it your way, unless somebody gets there first...
>
> This should do it - switches ->ioctl(
> BTW, could you put the current state of the docs someplace public?
The documentation will eventually end up in
Documentation/filesystems/orangefs.txt.
This part about the creation of the shared memory between userspace and
the kernel module seems complete and accurate to me so far. This "bufma
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 quieting them down...
See the fixup just posted in this thread.
> We've been focusing on code revi
On Wed, Nov 11, 2015 at 10:19:48AM +, Al Viro wrote:
> I'll cook the minimal fixup for API change after I get some sleep and
> send it your way, unless somebody gets there first...
This should do it - switches ->ioctl() to pvfs2_inode_[gs]etxattr() and
converts xattr_handler ->[gs]et() to new
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,
Hi Al,
On Wed, 11 Nov 2015 10:19:48 + Al Viro wrote:
>
> On Wed, Nov 11, 2015 at 07:16:36PM +1100, Stephen Rothwell wrote:
> >
> > So could you please remove the 4.5 stuff from your for-next branch
> > until after the merge window closes.
>
> Done.
Thanks.
> > Also, I noticed these new
On Wed, Nov 11, 2015 at 07:16:36PM +1100, Stephen Rothwell wrote:
> Hi Al,
>
> On Wed, 11 Nov 2015 07:43:30 + Al Viro wrote:
> >
> > dax_io fix isn't there, neither is overlayfs magic.h patch - both are
> > already in other trees. I would like to get xattr series in as well,
> > but that's a
Hi Al,
On Wed, 11 Nov 2015 07:43:30 + Al Viro wrote:
>
> dax_io fix isn't there, neither is overlayfs magic.h patch - both are
> already in other trees. I would like to get xattr series in as well,
> but that's a separate pull request, if you'd accept them in this window in
> the first place
On Tue, Nov 10, 2015 at 08:36:48PM -0800, Linus Torvalds wrote:
> On Tue, Nov 10, 2015 at 7:30 PM, Al Viro wrote:
> >
> > Linus, what would be your preference wrt that stuff?
>
> If you can just create a branch with the stuff that is obvious and
> clearly worth it (ie stuff that would basically b
On Tue, Nov 10, 2015 at 7:30 PM, Al Viro wrote:
>
> Linus, what would be your preference wrt that stuff?
If you can just create a branch with the stuff that is obvious and
clearly worth it (ie stuff that would basically be stable material
anyway), I'll just merge it. Assuming it's all done in so
On Wed, Nov 11, 2015 at 02:56:47AM +, Al Viro wrote:
> s/developed/rebased/, actually, but... point taken. Mea culpa, and what
> to do with those patches is for you to decide; some of those are simply
> -stable fodder and probably ought to go one-by-one at any point you would
> consider conven
On 11/10/2015 09:31 PM, Linus Torvalds wrote:
> although I don't think I saw a confirmation that that was what Sasha
> actually hit (but Sasha had narrowed it down to DAX, so it looks
> possible/likely)
Yup, that indeed fixed the problem I was seeing.
Thanks,
Sasha
--
To unsubscribe from this lis
On 11/10/2015 08:06 PM, Al Viro wrote:
On Tue, Nov 10, 2015 at 07:44:14PM -0700, Jens Axboe wrote:
Queued up. Unless Al objects, it'll be part of the 'for-linus' pull
later this week.
Reported-by: Sasha Levin
Cc: sta...@vger.kernel.org # 4.0+
probably ought to be there...
Agree, done.
-
On Tue, Nov 10, 2015 at 07:44:14PM -0700, Jens Axboe wrote:
> Queued up. Unless Al objects, it'll be part of the 'for-linus' pull
> later this week.
Reported-by: Sasha Levin
Cc: sta...@vger.kernel.org # 4.0+
probably ought to be there...
--
To unsubscribe from this list: send the line "unsubscr
On Tue, Nov 10, 2015 at 06:21:47PM -0800, Linus Torvalds wrote:
> Al, looking at the most recent linux-next, most of the vfs commits
> there seem to be committed in the last day or two. I'm getting the
> feeling that that is all 4.5 material by now.
>
> Should I just take the iov patch as-is, sin
On 11/10/2015 07:41 PM, Jens Axboe wrote:
On 11/10/2015 07:40 PM, Jens Axboe wrote:
On 11/10/2015 07:31 PM, Linus Torvalds wrote:
On Tue, Nov 10, 2015 at 6:25 PM, Jens Axboe wrote:
On Tue, Nov 10 2015, Linus Torvalds wrote:
Al, ping?
On Thu, Nov 5, 2015 at 7:38 PM, Linus Torvalds
wrote:
O
On 11/10/2015 07:40 PM, Jens Axboe wrote:
On 11/10/2015 07:31 PM, Linus Torvalds wrote:
On Tue, Nov 10, 2015 at 6:25 PM, Jens Axboe wrote:
On Tue, Nov 10 2015, Linus Torvalds wrote:
Al, ping?
On Thu, Nov 5, 2015 at 7:38 PM, Linus Torvalds
wrote:
On Thu, Nov 5, 2015 at 6:19 PM, Al Viro
wro
On 11/10/2015 07:31 PM, Linus Torvalds wrote:
On Tue, Nov 10, 2015 at 6:25 PM, Jens Axboe wrote:
On Tue, Nov 10 2015, Linus Torvalds wrote:
Al, ping?
On Thu, Nov 5, 2015 at 7:38 PM, Linus Torvalds
wrote:
On Thu, Nov 5, 2015 at 6:19 PM, Al Viro wrote:
How are we going to handle that one?
On Tue, Nov 10, 2015 at 6:25 PM, Jens Axboe wrote:
> On Tue, Nov 10 2015, Linus Torvalds wrote:
>> Al, ping?
>>
>> On Thu, Nov 5, 2015 at 7:38 PM, Linus Torvalds
>> wrote:
>> > On Thu, Nov 5, 2015 at 6:19 PM, Al Viro wrote:
>> >>
>> >> How are we going to handle that one? I can put it into main
On Tue, Nov 10 2015, Linus Torvalds wrote:
> Al, ping?
>
> On Thu, Nov 5, 2015 at 7:38 PM, Linus Torvalds
> wrote:
> > On Thu, Nov 5, 2015 at 6:19 PM, Al Viro wrote:
> >>
> >> How are we going to handle that one? I can put it into mainline pull
> >> request via vfs.git, with Cc: stable, but if
Al, ping?
On Thu, Nov 5, 2015 at 7:38 PM, Linus Torvalds
wrote:
> On Thu, Nov 5, 2015 at 6:19 PM, Al Viro wrote:
>>
>> How are we going to handle that one? I can put it into mainline pull
>> request via vfs.git, with Cc: stable, but if e.g. Jens prefers to take it
>> via the block tree, I'll be
On 11/05/2015 08:38 PM, Linus Torvalds wrote:
On Thu, Nov 5, 2015 at 6:19 PM, Al Viro wrote:
How are we going to handle that one? I can put it into mainline pull
request via vfs.git, with Cc: stable, but if e.g. Jens prefers to take it
via the block tree, I'll be glad to leave it for him to d
On Thu, Nov 5, 2015 at 6:19 PM, Al Viro wrote:
>
> How are we going to handle that one? I can put it into mainline pull
> request via vfs.git, with Cc: stable, but if e.g. Jens prefers to take it
> via the block tree, I'll be glad to leave it for him to deal with.
Put it in the vfs tree (I'm hop
On Fri, Nov 06, 2015 at 01:34:02AM +, Al Viro wrote:
> Could you try to reproduce it with this:
>
> dax_io(): don't let non-error value escape via retval instead of EFAULT
>
> Signed-off-by: Al Viro
> ---
> diff --git a/fs/dax.c b/fs/dax.c
> index a86d3cc..7b653e9 100644
> --- a/fs/dax.c
>
On Wed, Sep 30, 2015 at 05:30:17PM -0400, Sasha Levin wrote:
> > So I've traced this all the way back to dax_io(). I can trigger this with:
> >
> > diff --git a/fs/dax.c b/fs/dax.c
> > index 93bf2f9..2cdb8a5 100644
> > --- a/fs/dax.c
> > +++ b/fs/dax.c
> > @@ -178,6 +178,7 @@ static ssize_t dax_i
On 10/18/2015 12:17 AM, Ross Zwisler wrote:
> I'll try and find time to look at this issue this week. Sasha, do you have a
> more targeted reproducer, or is still just the trinity fuzzer?
Nope, I haven't looked at it much beyond looking into dax_io().
Thanks,
Sasha
--
To unsubscribe from this l
On Sat, Oct 17, 2015 at 03:22:19PM -0400, Sasha Levin wrote:
> On 09/30/2015 05:30 PM, Sasha Levin wrote:
> > On 09/17/2015 10:24 PM, Sasha Levin wrote:
> >> On 08/19/2015 01:46 AM, Al Viro wrote:
> or mapping->a_ops->direct_IO() returned more
> > than 'count'.
> >>> Was there DAX involv
On 09/30/2015 05:30 PM, Sasha Levin wrote:
> On 09/17/2015 10:24 PM, Sasha Levin wrote:
>> On 08/19/2015 01:46 AM, Al Viro wrote:
or mapping->a_ops->direct_IO() returned more
> than 'count'.
>>> Was there DAX involved? ->direct_IO() in there is blkdev_direct_IO(),
>>> which takes rath
On 09/17/2015 10:24 PM, Sasha Levin wrote:
> On 08/19/2015 01:46 AM, Al Viro wrote:
>>> or mapping->a_ops->direct_IO() returned more
than 'count'.
>> Was there DAX involved? ->direct_IO() in there is blkdev_direct_IO(),
>> which takes rather different paths in those cases...
>>
>
> So I
On 08/19/2015 01:46 AM, Al Viro wrote:
>> or mapping->a_ops->direct_IO() returned more
>> > than 'count'.
> Was there DAX involved? ->direct_IO() in there is blkdev_direct_IO(),
> which takes rather different paths in those cases...
>
So I've traced this all the way back to dax_io(). I can
On 08/19/2015 01:46 AM, Al Viro wrote:
> On Mon, Aug 17, 2015 at 12:18:12PM +0300, Andrey Ryabinin wrote:
>
>> This bug is similar to recently found bug in 9p:
>> http://thread.gmane.org/gmane.linux.kernel/1931799/focus=1936542
>
> Ow. For those who'd missed that fun: the bug in question had tu
On Mon, Aug 17, 2015 at 12:18:12PM +0300, Andrey Ryabinin wrote:
> This bug is similar to recently found bug in 9p:
> http://thread.gmane.org/gmane.linux.kernel/1931799/focus=1936542
Ow. For those who'd missed that fun: the bug in question had turned out to
be caused by improper reuse of reques
On 08/15/2015 11:13 PM, Chuck Ebbert wrote:
> On Wed, 12 Aug 2015 10:13:24 -0400
> Sasha Levin wrote:
>
>> While fuzzing with trinity inside a KVM tools guest running -next I've
>> stumbled on the following:
>>
>> [64092.216447]
>> =
On Wed, 12 Aug 2015 10:13:24 -0400
Sasha Levin wrote:
> While fuzzing with trinity inside a KVM tools guest running -next I've
> stumbled on the following:
>
> [64092.216447]
> ==
> [64092.217840] BUG: KASan: out of bounds on stac
Hi all,
While fuzzing with trinity inside a KVM tools guest running -next I've stumbled
on the following:
[64092.216447]
==
[64092.217840] BUG: KASan: out of bounds on stack in
iov_iter_advance+0x3b7/0x480 at addr 88040506fd48
35 matches
Mail list logo
