On Fri, 2017-04-21 at 12:55 +0900, damien.lem...@wdc.com wrote:
> [ ... ]
> +static int validate_hardware_zone_model(struct dm_table *table,
> + struct queue_limits *limits)
> +{
> + [ ... ]
> + unsigned int i = 0;
> + [ ... ]
> + while (i < num_t
On Fri, 2017-04-21 at 12:55 +0900, damien.lem...@wdc.com wrote:
> +static void dmz_shrink_mblock_cache(struct dmz_target *dmz, bool idle)
> +{
> + struct dmz_mblock *mblk;
> + unsigned int nr_mblks;
> +
> + if (!dmz->max_nr_mblks)
> + return;
> +
> + if (idle)
On Fri, 2017-04-28 at 16:23 -0400, Mike Snitzer wrote:
> On Thu, Apr 27 2017 at 2:33am -0400, h...@lst.de wrote:
> > On Wed, Apr 26, 2017 at 06:41:27PM +, Bart Van Assche wrote:
> > > On Wed, 2017-04-26 at 09:40 +0200, Christoph Hellwig wrote:
> > > > this series has some prep patches for my
On Thu, Apr 27 2017 at 2:33am -0400,
h...@lst.de wrote:
> On Wed, Apr 26, 2017 at 06:41:27PM +, Bart Van Assche wrote:
> > On Wed, 2017-04-26 at 09:40 +0200, Christoph Hellwig wrote:
> > > this series has some prep patches for my work to have proper, type
> > > checked block errors codes. O
On Fri, Apr 28, 2017 at 10:53:45AM -0600, Logan Gunthorpe wrote:
>
>
> On 28/04/17 12:30 AM, Herbert Xu wrote:
> > You are right. Indeed the existing code looks buggy as they
> > don't take sg->offset into account when doing the kmap. Could
> > you send me some patches that fix these problems f
On Thu, Apr 27, 2017 at 09:45:57AM -0600, Logan Gunthorpe wrote:
>
>
> On 26/04/17 09:56 PM, Herbert Xu wrote:
> > On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote:
> >> Very straightforward conversion to the new function in the caam driver
> >> and shash library.
> >>
> >> Signed-
On 04/28/2017 07:05 AM, NeilBrown wrote:
>
> When an array is created the content is not initialized,
> so it could have remnants of an old filesystem or md array
> etc on it.
> udev will see this and might try to activate it, which is almost
> certainly not what is wanted.
>
> So create a mechan
On 04/28/2017 05:55 AM, NeilBrown wrote:
> On Wed, Apr 26 2017, Peter Rajnoha wrote:
>
>> On 04/20/2017 11:35 PM, NeilBrown wrote:
>>> If we wanted an more permanent udev rule, we would need to record the
>>> devices that should be ignored in the filesystem somewhere else.
>>> Maybe in /run/mdadm.
When calling a dm ioctl that doesn't process any data
(IOCTL_FLAGS_NO_PARAMS), the contents of the data field in
struct dm_ioctl are left initialized. Current code is
incorrectly extending the size of data copied back to user,
causing the contents of kernel stack to be leaked to user.
Fix by only c
On Thu, Apr 27, 2017 at 05:03:45PM -0600, Logan Gunthorpe wrote:
>
>
> On 27/04/17 04:11 PM, Jason Gunthorpe wrote:
> > On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote:
> > Well, that is in the current form, with more users it would make sense
> > to optimize for the single page c
On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote:
> On 27/04/17 02:53 PM, Jason Gunthorpe wrote:
> > blkfront is one of the drivers I looked at, and it appears to only be
> > memcpying with the bvec_data pointer, so I wonder why it does not use
> > sg_copy_X_buffer instead..
>
> But
On 27/04/17 04:11 PM, Jason Gunthorpe wrote:
> On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote:
> Well, that is in the current form, with more users it would make sense
> to optimize for the single page case, eg by providing the existing
> call, providing a faster single-page-only
On 26/04/17 01:37 AM, Roger Pau Monné wrote:
> On Tue, Apr 25, 2017 at 12:21:02PM -0600, Logan Gunthorpe wrote:
>> Straightforward conversion to the new helper, except due to the lack
>> of error path, we have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in
>> certain cases in the future.
>>
>> S
On 27/04/17 02:53 PM, Jason Gunthorpe wrote:
> blkfront is one of the drivers I looked at, and it appears to only be
> memcpying with the bvec_data pointer, so I wonder why it does not use
> sg_copy_X_buffer instead..
Yes, sort of...
But you'd potentially end up calling sg_copy_to_buffer multip
On Thu, Apr 27, 2017 at 02:19:24PM -0600, Logan Gunthorpe wrote:
>
>
> On 26/04/17 01:37 AM, Roger Pau Monné wrote:
> > On Tue, Apr 25, 2017 at 12:21:02PM -0600, Logan Gunthorpe wrote:
> >> Straightforward conversion to the new helper, except due to the lack
> >> of error path, we have to use SG_
On 27/04/17 05:20 PM, Jason Gunthorpe wrote:
> It seems the most robust: test for iomem, and jump to a slow path
> copy, otherwise inline the kmap and memcpy
>
> Every place doing memcpy from sgl will need that pattern to be
> correct.
Ok, sounds like a good place to start to me. I'll see what
> So at the moment, we're leaning towards just:
>
> param->data_size = offsetof(struct dm_ioctl, data)
This works, it allows functions processing the ioctl to override if
needed and is cleaner
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On 26/04/17 01:44 AM, Christoph Hellwig wrote:
> I think we'll at least need a draft of those to make sense of these
> patches. Otherwise they just look very clumsy.
Ok, what follows is a draft patch attempting to show where I'm thinking
of going with this. Obviously it will not compile because
18 matches
Mail list logo
