linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Logan Gunthorpe <logang@deltatee.com>
To: Allen Hubbe <Allen.Hubbe@dell.com>,
	linux-ntb@googlegroups.com, linux-kernel@vger.kernel.org
Cc: "'Jon Mason'" <jdmason@kudzu.us>
Subject: Re: [PATCH 2/2] ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans()
Date: Mon, 11 Dec 2017 10:14:48 -0700	[thread overview]
Message-ID: <d06cf74e-125c-6281-9361-22bac3468251@deltatee.com> (raw)
In-Reply-To: <000201d37290$81605eb0$84211c10$@dell.com>



On 11/12/17 07:58 AM, Allen Hubbe wrote:
> !IS_ALIGNED(addr, BIT_ULL(xlate_pos))
> 

Ok, yes, that's much better. I'll change it. Thanks.

>> +		/*
>> +		 * In certain circumstances we can get a buffer that is
>> +		 * not aligned to its size. (Most of the time
>> +		 * dma_alloc_coherent ensures this). This can happen when
>> +		 * using large buffers allocated by the CMA
>> +		 * (see CMA_CONFIG_ALIGNMENT)
>> +		 */
>> +		dev_err(&sndev->stdev->dev,
>> +			"ERROR: Memory window address is not aligned to it's size!\n");
> 
> This would be the only ntb hw driver that prints an error in this situation.  The ntb_mw_get_align() should provide enough information to client drivers to determine the alignment requirements before calling ntb_mw_set_trans().  IMO no need to print here, but let's see what others say.


mw_get_align doesn't communicate the fact that the buffer has to be 
aligned by its size. It may also be that all hardware does not have this 
restriction (ie. if the hardware adds to the base address instead of 
just replacing the lower bits).

There is definitely a need to print this error somewhere as I hit this 
case and it caused very weird behavior. It was a huge pain to debug. 
Also, it's a security issue and huge bug if we end up mapping the memory 
we didn't think we were mapping. I don't think it's a good idea for us 
to require clients to check this as that requires a number of checks and 
a client author may forget to add it to their driver. I'd maybe go with 
a check in ntb_mw_set_trans before calling the driver, but that only 
makes sense if all hardware has the same requirement.

Logan

  reply	other threads:[~2017-12-11 17:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-09  0:02 [PATCH 1/2] ntb_transport: Fix bug with max_mw_size parameter Logan Gunthorpe
2017-12-09  0:02 ` [PATCH 2/2] ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans() Logan Gunthorpe
2017-12-11 14:58   ` Allen Hubbe
2017-12-11 17:14     ` Logan Gunthorpe [this message]
2017-12-11 19:17       ` Allen Hubbe
2017-12-11 19:28         ` Logan Gunthorpe
2017-12-11 20:06           ` Allen Hubbe
2017-12-11 20:38             ` Logan Gunthorpe
2017-12-11 14:55 ` [PATCH 1/2] ntb_transport: Fix bug with max_mw_size parameter Allen Hubbe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d06cf74e-125c-6281-9361-22bac3468251@deltatee.com \
    --to=logang@deltatee.com \
    --cc=Allen.Hubbe@dell.com \
    --cc=jdmason@kudzu.us \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ntb@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).