Re: [PATCH 00/18] use ARRAY_SIZE macro

[J. Bruce Fields]

On Mon, Oct 02, 2017 at 09:33:12PM -0400, Jérémy Lefaure wrote:
> On Mon, 2 Oct 2017 15:22:24 -0400
> bfie...@fieldses.org (J. Bruce Fields) wrote:
> 
> > Mainly I'd just like to know which you're asking for.  Do you want me to
> > apply this, or to ACK it so someone else can?  If it's sent as a series
> > I tend to assume the latter.
> > 
> > But in this case I'm assuming it's the former, so I'll pick up the nfsd
> > one
> Could you to apply the NFSD patch ("nfsd: use ARRAY_SIZE") with the
> Reviewed-by: Jeff Layton <jlay...@redhat.com>) tag please ?
> 
> This patch is an individual patch and it should not have been sent in a
> series (sorry about that).

Applying for 4.15, thanks.--b.

Re: [PATCH 00/18] use ARRAY_SIZE macro

[J. Bruce Fields]

On Mon, Oct 02, 2017 at 07:35:54AM +0200, Greg KH wrote:
> On Sun, Oct 01, 2017 at 08:52:20PM -0400, Jérémy Lefaure wrote:
> > On Mon, 2 Oct 2017 09:01:31 +1100
> > "Tobin C. Harding"  wrote:
> > 
> > > > In order to reduce the size of the To: and Cc: lines, each patch of the
> > > > series is sent only to the maintainers and lists concerned by the patch.
> > > > This cover letter is sent to every list concerned by this series.  
> > > 
> > > Why don't you just send individual patches for each subsystem? I'm not a 
> > > maintainer but I don't see
> > > how any one person is going to be able to apply this whole series, it is 
> > > making it hard for
> > > maintainers if they have to pick patches out from among the series (if 
> > > indeed any will bother
> > > doing that).
> > Yeah, maybe it would have been better to send individual patches.
> > 
> > From my point of view it's a series because the patches are related (I
> > did a git format-patch from my local branch). But for the maintainers
> > point of view, they are individual patches.
> 
> And the maintainers view is what matters here, if you wish to get your
> patches reviewed and accepted...

Mainly I'd just like to know which you're asking for.  Do you want me to
apply this, or to ACK it so someone else can?  If it's sent as a series
I tend to assume the latter.

But in this case I'm assuming it's the former, so I'll pick up the nfsd
one

--b.

Re: [PATCH 05/18] nfsd: Check private request size before submitting a SCSI request

[J . Bruce Fields]

ACK as far as I'm concerned.--b.

On Fri, May 19, 2017 at 11:30:03AM -0700, Bart Van Assche wrote:
> Since using scsi_req() is only allowed against request queues for which
> struct scsi_request is the first member of their private request
> data, refuse to register block layer queues for which the private
> data is smaller than struct scsi_request.
> 
> References: commit 82ed4db499b8 ("block: split scsi_request out of struct 
> request")
> Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com>
> Cc: J. Bruce Fields <bfie...@fieldses.org>
> Cc: Jeff Layton <jlay...@poochiereds.net>
> Cc: Jens Axboe <ax...@fb.com>
> Cc: Christoph Hellwig <h...@lst.de>
> Cc: Omar Sandoval <osan...@fb.com>
> Cc: Hannes Reinecke <h...@suse.com>
> Cc: linux-...@vger.kernel.org
> Cc: linux-bl...@vger.kernel.org
> ---
>  fs/nfsd/blocklayout.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/fs/nfsd/blocklayout.c b/fs/nfsd/blocklayout.c
> index fb5213afc854..90d1df31491b 100644
> --- a/fs/nfsd/blocklayout.c
> +++ b/fs/nfsd/blocklayout.c
> @@ -219,6 +219,9 @@ static int nfsd4_scsi_identify_device(struct block_device 
> *bdev,
>   u8 *buf, *d, type, assoc;
>   int error;
>  
> + if (WARN_ON_ONCE(blk_queue_cmd_size(q) < sizeof(struct scsi_request)))
> + return -EINVAL;
> +
>   buf = kzalloc(bufflen, GFP_KERNEL);
>   if (!buf)
>   return -ENOMEM;
> -- 
> 2.12.2

Re: [PATCH RFC 1/3] vfs: add copy_file_range syscall and vfs helper

[J. Bruce Fields]

On Tue, Apr 14, 2015 at 11:22:41AM -0700, Zach Brown wrote:
 On Tue, Apr 14, 2015 at 02:19:11PM -0400, J. Bruce Fields wrote:
  On Tue, Apr 14, 2015 at 01:16:13PM -0400, Anna Schumaker wrote:
   On 04/14/2015 12:53 PM, Christoph Hellwig wrote:
On Sat, Apr 11, 2015 at 09:04:02AM -0400, Jeff Layton wrote:
Yuck! How the heck do you clean up the mess if that happens? I
guess you're just stuck redoing the copy with normal READ/WRITE?
   
Maybe we need to have the interface return a hard error in that
case and not try to give back any sort of offset?

The NFSv4.2 COPY interface is a train wreck.  At least for Linux I'd
expect us to simply ignore it and only implement my new CLONE
operation with sane semantics.  That is unless someone can show some
real life use case for the inter server copy, in which case we'll
have to deal with that mess.  But getting that one right at the VFS
level will be a nightmare anyway.

Make this a vote from me to not support partial copies and just
return and error in that case.
   
   Agreed.  Looking at the v4.2 spec, COPY does take ca_consecutive and a
   ca_synchronous flags that let the client state if the copy should be
   done consecutively or synchronously.  I expected to always set
   consecutive to true for the Linux client.
  
  That's supposed to mean results are well-defined in the partial-copy
  case, but I think Christoph's suggesting eliminating the partial-copy
  case entirely?
  
  Which would be fine with me.
  
  It might actually have been me advocating for partial copies.  But that
  was only because a partial-copy-handling-loop seemed simpler to me than
  progress callbacks if we were going to support long-running copies.
  
  I'm happy enough not to have it at all.
 
 Ah, OK, that's great news.
 
 I thought at one point we were worried about very long running RPCs on
 the server.  Are we not worried about that now?
 
 Is the client expected to cut the work up into arbitrarily managable
 chunks?  Is the server expected to fail COPY/CLONE requests that it
 thinks would take way too long?  Something else?

Christoph is proposing a CLONE rpc that's required to be atomic:


https://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-35#section-15.13
The CLONE operation is atomic, that is either all changes or no
changes are seen by the client or other clients.

So that couldn't be really long-running (or the server is nuts).

So that'd mean Anna would rip out the server-side copy loop and we'd
initially just support btrfs or whatever.

I mean the server-side copy loop may also be useful but I'm all for
wiring up the obvious case first.

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

Re: [PATCH RFC 1/3] vfs: add copy_file_range syscall and vfs helper

[J. Bruce Fields]

On Tue, Apr 14, 2015 at 01:16:13PM -0400, Anna Schumaker wrote:
 On 04/14/2015 12:53 PM, Christoph Hellwig wrote:
  On Sat, Apr 11, 2015 at 09:04:02AM -0400, Jeff Layton wrote:
  Yuck! How the heck do you clean up the mess if that happens? I
  guess you're just stuck redoing the copy with normal READ/WRITE?
 
  Maybe we need to have the interface return a hard error in that
  case and not try to give back any sort of offset?
  
  The NFSv4.2 COPY interface is a train wreck.  At least for Linux I'd
  expect us to simply ignore it and only implement my new CLONE
  operation with sane semantics.  That is unless someone can show some
  real life use case for the inter server copy, in which case we'll
  have to deal with that mess.  But getting that one right at the VFS
  level will be a nightmare anyway.
  
  Make this a vote from me to not support partial copies and just
  return and error in that case.
 
 Agreed.  Looking at the v4.2 spec, COPY does take ca_consecutive and a
 ca_synchronous flags that let the client state if the copy should be
 done consecutively or synchronously.  I expected to always set
 consecutive to true for the Linux client.

That's supposed to mean results are well-defined in the partial-copy
case, but I think Christoph's suggesting eliminating the partial-copy
case entirely?

Which would be fine with me.

It might actually have been me advocating for partial copies.  But that
was only because a partial-copy-handling-loop seemed simpler to me than
progress callbacks if we were going to support long-running copies.

I'm happy enough not to have it at all.

--b.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi 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] osd: Boaz Harrosh - change of email

[J. Bruce Fields]

On Tue, Oct 21, 2014 at 11:04:12PM +0200, James Bottomley wrote:
 On Tue, 2014-10-21 at 17:05 +0300, Boaz Harrosh wrote:
  Hi Sir Linus
  
  A small administrative stuff, was on vacation and the old email bounced on 
  me.
  I was hoping to still make the 3 weeks merge window, but it was 2 weeks at 
  the
  end.
  Your call if to make this wait for next window. Needless to say that it is
  ZERO risk, just change of email.
  
  Based on commit [bfe01a5b] Linux 3.17
  
  3 patches available in the git repository at:
  
git://git.open-osd.org/linux-open-osd.git for-linus
  
  for you to fetch changes up to 1fa3a002b2546c42c343c77c144871285896ced5:
  
Boaz Harrosh - fix email in Documentation (2014-10-19 20:36:36 +0300)
  
  
  Boaz Harrosh (3):
MAINTAINERS: Change Boaz Harrosh's email
Boaz Harrosh - Fix broken email address
Boaz Harrosh - fix email in Documentation
  
   Documentation/scsi/osd.txt  | 3 +--
   MAINTAINERS | 2 +-
   drivers/scsi/osd/Kbuild | 2 +-
   drivers/scsi/osd/Kconfig| 2 +-
   drivers/scsi/osd/osd_debug.h| 2 +-
   drivers/scsi/osd/osd_initiator.c| 4 ++--
   drivers/scsi/osd/osd_uld.c  | 4 ++--
   fs/exofs/Kbuild | 2 +-
   fs/exofs/common.h   | 2 +-
   fs/exofs/dir.c  | 2 +-
   fs/exofs/exofs.h| 2 +-
   fs/exofs/file.c | 2 +-
   fs/exofs/inode.c| 2 +-
   fs/exofs/namei.c| 2 +-
   fs/exofs/ore.c  | 4 ++--
   fs/exofs/ore_raid.c | 2 +-
   fs/exofs/ore_raid.h | 2 +-
   fs/exofs/super.c| 2 +-
   fs/exofs/symlink.c  | 2 +-
   fs/exofs/sys.c  | 2 +-
   fs/nfs/objlayout/objio_osd.c| 2 +-
   fs/nfs/objlayout/objlayout.c| 2 +-
   fs/nfs/objlayout/objlayout.h| 2 +-
   fs/nfs/objlayout/pnfs_osd_xdr_cli.c | 2 +-
   include/linux/pnfs_osd_xdr.h| 2 +-
   include/scsi/osd_initiator.h| 2 +-
   include/scsi/osd_ore.h  | 2 +-
   include/scsi/osd_protocol.h | 4 ++--
   include/scsi/osd_sec.h  | 2 +-
   include/scsi/osd_sense.h| 2 +-
   include/scsi/osd_types.h| 2 +-
   31 files changed, 35 insertions(+), 36 deletions(-)
 
 This is a bit of an unnecessary massive churn.  No one expects the
 author named in the file to stay up to date, especially because the
 @domain.com usually credits the company who paid for the code, so it's
 left in as a kind of mark of respect for them.  I'm not saying it
 applies in your case, just that it creates the common expectation of
 in-file authors needing to be traced through the MAINTAINERS file.
 
 Could you not just update the MAINTAINERS file only, like everyone else?

I guess there's also .mailmap, though it doesn't look like that's being
used much.

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

Re: [LSF/MM TOPIC][ATTEND] protection information and userspace

[J. Bruce Fields]

On Thu, Feb 07, 2013 at 09:36:39AM -0800, Joel Becker wrote:
 Dear LSF committee,
   I'd like to explicitly request attendance for this discussion
 :-)

http://marc.info/?l=linux-fsdevelm=135894412908342w=2

Also, the way I compile the list of requests is from thread
heads ...  that means don't send your attendee request as a
reply to something else either otherwise it might get missed.

--b.

 
 Joel
 
 On Thu, Feb 07, 2013 at 09:27:35AM -0800, Zach Brown wrote:
  On Thu, Feb 07, 2013 at 11:19:59AM -0500, Jeff Moyer wrote:
   Boaz Harrosh bharr...@panasas.com writes:

For aio we just need to add additional fields to an existing structure.

So yeah, I'd be interested in that discussion as well.
   
   Sure, it's easy to start there, but then you eventually end up having to
   add a non-aio interface as well.  Let's not take the latter off the
   table.
  
  I agree that a sync variant should't be ignored, but needing a sync
  interface with PI arguments also shouldn't get in the way of adding
  support to the aio+dio path.  Simply because it's what people use :/.
  
   I'm not sure how that's directly related to aio, but ok.  If we're going
   to rewrite the aio code, I think Zach's acall would be a good start, at
   least on the API front:
 http://lwn.net/Articles/316806/
  
  Yeah, I'm happy to chat about this stuff if people are interested.  I
  think I'd do things differently today than what was done in that aged
  acall prototype.
  
  - z
  --
  To unsubscribe from this list: send the line unsubscribe linux-scsi in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 -- 
 
 You can get more with a kind word and a gun than you can with
  a kind word alone.
  - Al Capone
 
   http://www.jlbec.org/
   jl...@evilplan.org
 --
 To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Integration of SCST in the mainstream Linux kernel

[J. Bruce Fields]

On Mon, Feb 04, 2008 at 11:44:31AM -0800, Linus Torvalds wrote:
...
 Pure user-space solutions work, but tend to eventually be turned into 
 kernel-space if they are simple enough and really do have throughput and 
 latency considerations (eg nfsd), and aren't quite complex and crazy 
 enough to have a large impedance-matching problem even for basic IO stuff 
 (eg samba).
...
 So just going by what has happened in the past, I'd assume that iSCSI 
 would eventually turn into connecting/authentication in user space with 
 data transfers in kernel space. But only if it really does end up 
 mattering enough. We had a totally user-space NFS daemon for a long time, 
 and it was perfectly fine until people really started caring.

I'd assumed the move was primarily because of the difficulty of getting
correct semantics on a shared filesystem--if you're content with
NFS-only access to your filesystem, then you can probably do everything
in userspace, but once you start worrying about getting stable
filehandles, consistent file locking, etc., from a real disk filesystem
with local users, then you require much closer cooperation from the
kernel.

And I seem to recall being told that sort of thing was the motivation
more than performance, but I wasn't there (and I haven't seen
performance comparisons).

--b.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html