On Thu, Aug 25, 2022 at 09:44:22AM +0200, Martin Wilck wrote:
> On Wed, 2022-08-24 at 19:02 +0200, Martin Wilck wrote:
> > On Wed, 2022-08-24 at 11:16 -0500, Benjamin Marzinski wrote:
> > > On Wed, Aug 24, 2022 at 09:07:56AM +0200, Martin Wilck wrote:
> > > > On Tue, 2022-08-23 at 15:48 -0500,
On 8/23/22 05:18, Pankaj Raghav wrote:
Use the bdev_offset_from_zone_start() helper function to calculate
the offset from zone start instead of using power of 2 based
calculation.
Reviewed-by: Bart Van Assche
--
dm-devel mailing list
dm-devel@redhat.com
On 8/23/22 05:18, Pankaj Raghav wrote:
From: Luis Chamberlain
dm-zoned relies on the assumption that the zone size is a
power-of-2(po2) and the zone capacity is same as the zone size.
Ensure only po2 devices can be used as dm-zoned target until a native
support for zoned devices with non-po2
On 8/23/22 05:18, Pankaj Raghav wrote:
Convert the power-of-2(po2) based calculation with zone size to be generic
in null_zone_no with optimization for po2 zone sizes.
The nr_zones calculation in null_init_zoned_dev has been replaced with a
division without special handling for po2 zone sizes
On 8/23/22 05:18, Pankaj Raghav wrote:
Remove the condition which disallows non-power_of_2 zone size ZNS drive
to be updated and use generic method to calculate number of zones
instead of relying on log and shift based calculation on zone size.
The power_of_2 calculation has been replaced
On 8/23/22 05:18, Pankaj Raghav wrote:
Define bdev_is_zoned(), bdev_zone_sectors() and bdev_get_queue() earlier
in the blkdev.h include file. Simplify bdev_is_zoned() by removing the
superfluous NULL check for request queue while we are at it.
This commit has no functional change, and it is a
> 2022年8月25日 21:49，Zdenek Kabelac 写道：
>
> Dne 25. 08. 22 v 15:32 Mikulas Patocka napsal(a):
>>
>> On Thu, 25 Aug 2022, Zdenek Kabelac wrote:
>>
>>> Since reproducing this issue is rather 'trival' - since creation of simple
>>> linear DM device and reloading it with 'self-reference' table
Dne 25. 08. 22 v 15:32 Mikulas Patocka napsal(a):
On Thu, 25 Aug 2022, Zdenek Kabelac wrote:
Since reproducing this issue is rather 'trival' - since creation of simple
linear DM device and reloading it with 'self-reference' table line is easy I'd
advocate for some simplistic check on kernel
On Thu, 25 Aug 2022, Zdenek Kabelac wrote:
> Since reproducing this issue is rather 'trival' - since creation of simple
> linear DM device and reloading it with 'self-reference' table line is easy
> I'd
> advocate for some simplistic check on kernel side - as such 'crash' can't be
> even
Dne 24. 08. 22 v 21:42 Mikulas Patocka napsal(a):
On Thu, 25 Aug 2022, Coly Li wrote:
Hi folks,
Recently I received a bug report from Intel developers (big thanks), the
kernel panic is caused by a kernel stack overflow and it seems from a
recursive dm-table reload.
Here is the simplified
On Wed, Aug 24, 2022 at 05:15:28PM -0700, Damien Le Moal wrote:
On 2022/08/24 16:43, Bart Van Assche wrote:
On 5/22/22 15:01, Adam Manzanares wrote:
Zoned Storage Devices (SMR HDDs and ZNS SSDs) have demonstrated that they can
improve storage capacity, throughput, and latency over conventional
On Wed, Aug 24, 2022 at 3:21 PM Chang S. Bae wrote:
>
> On 8/23/2022 8:49 AM, Evan Green wrote:
> > On Wed, Jan 12, 2022 at 1:21 PM Chang S. Bae
> > wrote:
> >>
>
> >> +
> >> +static void __init load_keylocker(void)
> >
> > I am late to this party by 6 months, but:
> > load_keylocker() cannot
On 8/24/2022 3:52 PM, Evan Green wrote:
Whatever we ended up landing in the ChromeOS tree (which I think was
v4 of this series) actively hit this bug in hibernation, which is how
I found it. I couldn't get a full backtrace because the backtracing
code tripped over itself as well for some
On 8/23/2022 8:49 AM, Evan Green wrote:
On Wed, Jan 12, 2022 at 1:21 PM Chang S. Bae wrote:
+
+static void __init load_keylocker(void)
I am late to this party by 6 months, but:
load_keylocker() cannot be __init, as it gets called during SMP core onlining.
Yeah, it looks like the case
14 matches
Mail list logo
