On Wed, Nov 19 2008, Stephen Rothwell wrote:
> Hi Jens,
>
> On Wed, 19 Nov 2008 10:16:28 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote:
> >
> > Strange, so it gets stuck on the timer lock, very weird. You don't
> > happen to have output showing tha
00f9f0c] .sys_read+0x4c/0x8c
> [c00040ef7e30] [c00084d4] syscall_exit+0x0/0x40
>
> This was on a Power5 partition. I am attempting to reproduce the problem.
>
> Any clues?
Strange, so it gets stuck on the timer lock, very weird. You don&
On Thu, Nov 20 2008, Stephen Rothwell wrote:
> Hi Jens,
>
> On Wed, 19 Nov 2008 11:58:33 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote:
> >
> > ;-) I'm aware of that, I meant the 'timer' data argument. But you are
> > right, it's probably q-&g
On Wed, Nov 19 2008, Stephen Rothwell wrote:
> Hi Jens,
>
> On Wed, 19 Nov 2008 10:43:00 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, Nov 19 2008, Stephen Rothwell wrote:
> > >
> > > Unable to handle kernel paging request for data at
On Thu, Nov 20 2008, Stephen Rothwell wrote:
> Hi Jens,
>
> On Wed, 19 Nov 2008 14:34:09 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote:
> >
> > Are you removing devices or modules? We have a bug there it seems, does
> > this help?
>
> This is early in boot (w
r dropped the virtual merge feature
> (b8b3e16cfe6435d961f6aaebcfd52a1ff2a988c5). BIO_VMERGE_BOUNDARY
> definition is meaningless now (For POWER, BIO_VMERGE_BOUNDARY has been
> meaningless for a long time since POWER disables the virtual merge
> feature).
>
> Signed-off-by: FUJITA Tomonori
Series device drivers"
>
> config VIODASD
> tristate "iSeries Virtual I/O disk support"
> + depends on BLOCK
> help
> If you are running on an iSeries system and you want to use
> v
On Wed, Jan 14 2009, Stephen Rothwell wrote:
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/block/ps3disk.c | 18 +-
> 1 files changed, 9 insertions(+), 9 deletions(-)
>
> Jens, if its OK by you, this could go in via the PowerPC tree.
Of co
patches so
> > Paul
> > can take them, too?
>
> Ping block/SCSI/misc maintainers?
I have no objections to the block bits, however I feel uneasy merging
the full patchset unless patch #1 has been acked by the platform person.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Tue, Jul 10 2007, Paul Mackerras wrote:
> Jens Axboe writes:
>
> > I have no objections to the block bits, however I feel uneasy merging
> > the full patchset unless patch #1 has been acked by the platform person.
>
> I have the first 3 patches in my queue, so
way this is supposed
> to be done is to do a
>
> flush_kernel_dcache_page(kaddr)
>
> before doing the kunmap.
>
> Otherwise it looks OK from the SCSI point of view.
Well, even worse is that fact that it's using KM_USER0 from interrupt
context.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Fri, Jul 13 2007, Geert Uytterhoeven wrote:
> On Fri, 13 Jul 2007, Jens Axboe wrote:
> > On Fri, Jul 13 2007, James Bottomley wrote:
> > > On Wed, 2007-07-04 at 15:22 +0200, Geert Uytterhoeven wrote:
> > > > + kaddr = kma
arch/parisc/kernel/cache.c
> arch/parisc/kernel/pacache.S
> include/asm-parisc/cacheflush.h
> include/linux/highmem.h
Not many drivers fiddle around with stuff like this, it's usually hidden
behind the dma api or in helpers.
--
Jens Axboe
would be more
appropriate, the backing could be page cache pages.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> On Mon, 16 Jul 2007, Jens Axboe wrote:
> > On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> > > On Fri, 13 Jul 2007, Geert Uytterhoeven wrote:
> > > > Ah, that explains it. flush_dcache_page() is used in some drivers.
On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> On Mon, 16 Jul 2007, Geert Uytterhoeven wrote:
> > On Mon, 16 Jul 2007, Jens Axboe wrote:
> > > On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> > > > On Fri, 13 Jul 2007, Geert Uytterhoeven wrote:
> > > >
On Mon, Jul 16 2007, James Bottomley wrote:
> On Mon, 2007-07-16 at 14:16 +0200, Jens Axboe wrote:
> > On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> > > On Fri, 13 Jul 2007, Geert Uytterhoeven wrote:
> > > > Ah, that explains it. flush_dcache_page() is used in som
. Is that true (or a bug?)?
>
> If it's OK, I'll fold this patch into the main ps3disk patch.
The bug is in your code - you iterate the bio segments, but always
reference the current one. Which of course makes no sense, you may as
well just kill the loop in that case, the code wou
een a need for it.
Geert uses it as debug code here, but the fact is that the number of
bios in a request is a pretty pointless number. It doesn't tell you
anything. There's no 1:1 mapping between bios and segments (or anything
else for that matter), so the exercise is purely pointless.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
nd the above just doesn't.
> >
> > Sigh.
>
> Do you prefer
>
> static inline struct ps3rom_private *ps3rom_priv_get(struct ps3_storage_device
> *dev)
> {
> return dev->sbd.core.driver_data;
> }
>
> static inline void ps3rom_priv_set(s
t;>>>> iomap_file_buffered_write+0xa0/0x120
>>>>> [c000163679e0] [c0080040791c]
>>>>> xfs_file_buffered_aio_write+0x314/0x5e0 [xfs]
>>>>> [c00016367a90] [c06d74bc] io_write+0x10c/0x460
>>>>> [c00016367bb0] [c06d80e4] io_issue_sqe+0x8d4/0x1200
>>>>> [c00016367c70] [c06d8ad0] io_wq_submit_work+0xc0/0x250
>>>>> [c00016367cb0] [c06e2578]
>>>>> io_worker_handle_work+0x498/0x800
>>>>> [c00016367d40] [c06e2cdc] io_wqe_worker+0x3fc/0x4f0
>>>>> [c00016367da0] [c01cb0a4] kthread+0x1c4/0x1d0
>>>>> [c00016367e10] [c000dbf0]
>>>>> ret_from_kernel_thread+0x5c/0x6c
>>>>>
>>>>> The kernel consider thread AMR value for kernel thread to be
>>>>> AMR_KUAP_BLOCKED. Hence access to userspace is denied. This
>>>>> of course not correct and we should allow userspace access after
>>>>> kthread_use_mm(). To be precise, kthread_use_mm() should inherit the
>>>>> AMR value of the operating address space. But, the AMR value is
>>>>> thread-specific and we inherit the address space and not thread
>>>>> access restrictions. Because of this ignore AMR value when accessing
>>>>> userspace via kernel thread.
>>>>>
>>>>> Signed-off-by: Aneesh Kumar K.V
>>>>> ---
>>>>> Changes from v1:
>>>>> * Address review feedback from Nick
>>>>>
>>>>> arch/powerpc/include/asm/book3s/64/kup.h | 8 +++-
>>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/powerpc/include/asm/book3s/64/kup.h
>>>>> b/arch/powerpc/include/asm/book3s/64/kup.h
>>>>> index f50f72e535aa..95f4df99249e 100644
>>>>> --- a/arch/powerpc/include/asm/book3s/64/kup.h
>>>>> +++ b/arch/powerpc/include/asm/book3s/64/kup.h
>>>>> @@ -384,7 +384,13 @@ static __always_inline void
>>>>> allow_user_access(void __user *to, const void __user
>>>>> // This is written so we can resolve to a single case at build
>>>>> time
>>>>> BUILD_BUG_ON(!__builtin_constant_p(dir));
>>>>> -if (mmu_has_feature(MMU_FTR_PKEY))
>>>>> +/*
>>>>> + * if it is a kthread that did kthread_use_mm() don't
>>>>> + * use current_thread_amr().
>>>>
>>>> According to include/linux/sched.h, PF_KTHREAD means /* I am a kernel
>>>> thread */
>>>> It doesn't seem to be related to kthread_use_mm()
>>>
>>> That should be a sufficient check here. if we did reach here without
>>> calling kthread_user_mm, we will crash on access because we don't have
>>> a mm attached to the current process. a kernel thread with
>>> kthread_use_mm has
>>
>> Ok but then the comment doesn't match the check.
>
>
> I was trying to be explict in the comment that we expect the thread to
> have done kthread_use_mm().
>
>>
>> And also the comment in current_thread_amr() is then misleading.
>>
>> Why not do the current->flags & PF_KTHREAD check in current_thread_amr()
>> and return 0 in that case instead of BLOCKED ?
>
> In my view currrent_thread_amr() is more generic and we want to be
> explicit there that a kernel thread AMR is KUAP_BLOCKED. Only when we
> call allow user access, we relax the AMR value.
Just following up on this, as I'd hate to have 5.11 released with this
bug in it for powerpc. It'll obviously also affect other cases of a
kernel thread faulting after having done kthread_use_mm(), though I'm
not sure how widespread that is. In any case, it'll leave io_uring
mostly broken on powerpc if this isn't patched for release.
--
Jens Axboe
On 2/4/21 10:01 AM, Aneesh Kumar K.V wrote:
> On 2/4/21 10:23 PM, Jens Axboe wrote:
>> On 2/1/21 11:30 PM, Aneesh Kumar K.V wrote:
>>> On 2/2/21 11:50 AM, Christophe Leroy wrote:
>>>>
>>>>
>>>> Le 02/02/2021 à 07:16, Aneesh Kumar K.V a éc
definitely about
dma_regs, not dev, and you swapped the condition (failing on dma_regs
being set, not NULL).
I'd just leave this one alone, drivers/ide/ should be going away soon.
--
Jens Axboe
long time that's why remove it.
>
> Is there a reason this patch was never merged? can the driver be
> removed? I ran into this as a potential tasklet user that can be
> replaced/removed.
I'd be happy to merge it for 5.13.
--
Jens Axboe
On 3/23/21 10:25 AM, Michal Simek wrote:
>
>
> On 3/23/21 5:23 PM, Jens Axboe wrote:
>> On 3/22/21 6:04 PM, Davidlohr Bueso wrote:
>>> Hi,
>>>
>>> On Mon, 09 Nov 2020, Michal Simek wrote:
>>>
>>>> Sysace IP is no longer used on Xi
e equivalent transformation and stop asking for block
> layer bounce buffering.
Applied, thanks.
--
Jens Axboe
b2b78 7c7d1b78 7cfc3b78 a1440048 2c2a
>> 4082008c a13f004a
>> [1.861328][T1] 7c095040 40810110 e93f0008 811f0028
>> e9290050 812903d8 7d3e4850
>> [1.863000][T1] ---[ end trace c49ca2d91ee47d7f ]---
>> [1.879456][T1]
>> [2.880941][T1] Kernel panic - not syncing: Attempted to kill init!
>> exitcode=0x000b
>>
>> I don't know what caused this, but it is some change since Friday.
>>
>> I have left it like this.
>
> Bisections leads to commit
>
> 42fb54fbc707 ("bio: limit bio max size")
>
> from the block tree. Reverting that commit on top of today's
> linux-next allows to the boot to work again.
The patch has been dropped, thanks Stephen.
--
Jens Axboe
; for cleanup/free them when a driver is unloaded or a device is removed.
>
> Together this removes the need to treat the gendisk and request_queue
> as separate entities for bio based drivers.
Applied, thanks.
--
Jens Axboe
00022cbbab0] [c08b39c8] release_nodes+0x2f8/0x3e0
> [c00022cbbb60] [c08ac440]
> device_release_driver_internal+0x190/0x2b0
> [c00022cbbba0] [c000008a8450] unbind_store+0x130/0x170
Applied, thanks.
--
Jens Axboe
gt; in all drivers that do not have any caveats in their gendisk and
> request_queue lifetime rules.
Applied, thanks.
--
Jens Axboe
On 9/27/21 4:01 PM, Luis Chamberlain wrote:
> This is the fourth batch of add_disk() error handling driver
> conversions. This set along with the entire 7 set of driver conversions
> can be found on my 20210927-for-axboe-add-disk-error-handling branch
> [0].
Applied 1-2, 6, 8-9, thank
d749f76040f782f0618656cd23e33
[11/13] ps3vram: add error handling support for add_disk()
commit: 3c30883acab1d20ecbd3c48dc12b147b51548742
Best regards,
--
Jens Axboe
; mtd/ubi/block: add error handling support for add_disk()
>
> [...]
Applied, thanks!
[01/13] block/brd: add error handling support for add_disk()
commit: e1528830bd4ebf435d91c154e309e6e028336210
Best regards,
--
Jens Axboe
the last few patches to add __must_check for the final
>> add_disk() error handling changes.
>
> True, I don't think I can get it nuked in time, so you can add my
> Reviewed-by for this one.
Luis, I lost track of the nv* patches from this discussion. If you want
them in 5.16 and they are reviewed, please do resend and I'll pick them
up for the middle-of-merge-window push.
--
Jens Axboe
we agree that the user access is valid?
We should be able to copy to/from user space, and including faults, if
that's been done and the new mm assigned. Because it really should be.
If SMAP was a problem on x86, we would have seen it long ago.
I'm assuming this may be breakage related to the recent uaccess changes
related to set_fs and friends? Or maybe recent changes on the powerpc
side?
Zorro, did 5.10 work?
--
Jens Axboe
, if
>>> that's been done and the new mm assigned. Because it really should be.
>>> If SMAP was a problem on x86, we would have seen it long ago.
>>>
>>> I'm assuming this may be breakage related to the recent uaccess changes
>>> related to set_fs and friends? Or maybe recent changes on the powerpc
>>> side?
>>>
>>> Zorro, did 5.10 work?
>>
>> Would be interesting to know.
>
> Sure Nick and Jens, which 5.10 rc? version do you want to know ? Or any git
> commit(be the HEAD) in 5.10 phase?
I forget which versions had what series of this, but 5.10 final - and if
that fails, then 5.9 final. IIRC, 5.9 was pre any of these changes, and
5.10 definitely has them.
--
Jens Axboe
On 1/28/21 6:52 AM, Zorro Lang wrote:
> On Wed, Jan 27, 2021 at 08:06:37PM -0700, Jens Axboe wrote:
>> On 1/27/21 8:13 PM, Zorro Lang wrote:
>>> On Thu, Jan 28, 2021 at 10:18:07AM +1000, Nicholas Piggin wrote:
>>>> Excerpts from Jens Axboe's message of January 2
e on down the IO was purely bio based, not buffer_heads.
Anyway, totally agree that it should just die, it's not that
interesting or useful anymore.
--
Jens Axboe
> path to issue to blk-mq, removing the need for the direct_make_request
> bypass.
Looks good to me, and it's a nice cleanup as well. Applied.
--
Jens Axboe
On 6/30/20 7:57 AM, Jens Axboe wrote:
> On 6/29/20 1:39 PM, Christoph Hellwig wrote:
>> Hi Jens,
>>
>> this series moves the make_request_fn method into block_device_operations
>> with the much more descriptive ->submit_bio name. It then also gives
>> generic_
On 6/30/20 12:19 PM, Christoph Hellwig wrote:
> On Tue, Jun 30, 2020 at 09:43:31AM -0600, Jens Axboe wrote:
>> On 6/30/20 7:57 AM, Jens Axboe wrote:
>>> On 6/29/20 1:39 PM, Christoph Hellwig wrote:
>>>> Hi Jens,
>>>>
>>>> this series moves t
On 6/30/20 12:21 PM, Jens Axboe wrote:
> On 6/30/20 12:19 PM, Christoph Hellwig wrote:
>> On Tue, Jun 30, 2020 at 09:43:31AM -0600, Jens Axboe wrote:
>>> On 6/30/20 7:57 AM, Jens Axboe wrote:
>>>> On 6/29/20 1:39 PM, Christoph Hellwig wrote:
>>>>&g
> path to issue to blk-mq, removing the need for the direct_make_request
> bypass.
Thanks, I'll try this again.
--
Jens Axboe
te that the ps3disk has a minir conflict with the
> flush_kernel_dcache_page removal in linux-next through the -mm tree.
> I had hoped that change would go into 5.14, but it seems like it is
> being held for 5.15.
Applied for 5.15, thanks.
--
Jens Axboe
n
> HAVE_IDE in all those arch-specific Kconfig files.
>
> The issue was identified with ./scripts/checkkconfigsymbols.py.
Thanks, let's queue this for 5.14 to avoid any future conflicts with
it.
--
Jens Axboe
by put_disk(). Add that call where
> needed.
Applied, thanks.
--
Jens Axboe
>>>> Hi,
>>>>
>>>> Today's mainline (4.11.0-rc1) booted with warnings on Power7 LPAR.
>>>>
>>>> Issue is not reproducible all the time.
Is that still the case with -git as of yesterday? Check that you
have this merge:
34bbce9e344b47e8871273409632f525973afad4
in your tree.
--
Jens Axboe
On 05/05/2017 12:25 AM, Abdul Haleem wrote:
> Hi,
>
> 4.11.0 Linus mainline booted with Warnings on PowerPC.
>
> We did not see this on next-20170407 but on next-20170410 and later.
Have you tried current Linus -git? Both of the -next versions you list
are rather old.
--
Jens Axboe
On 05/08/2017 01:13 AM, Abdul Haleem wrote:
> On Fri, 2017-05-05 at 08:02 -0600, Jens Axboe wrote:
>> On 05/05/2017 12:25 AM, Abdul Haleem wrote:
>>> Hi,
>>>
>>> 4.11.0 Linus mainline booted with Warnings on PowerPC.
>>>
>>> We did not se
fetch anything larger
> than "unsigned long" i.e. 32 bits on 32 bit powerpc.
>
> This has been discussed before (and, I think, a fix attempted).
Gah, thanks for letting me know. I'll test your patch and queue it
up to fix this issue.
--
Jens Axboe
On 06/28/2017 06:43 AM, Jens Axboe wrote:
> On 06/28/2017 02:04 AM, Stephen Rothwell wrote:
>> Hi Jens,
>>
>> After merging the block tree, today's linux-next build (powerpc
>> allnoconfig) failed like this:
>>
>> fs/fcntl.o: In function `do_fcntl'
On 06/28/2017 08:01 AM, Jens Axboe wrote:
> On 06/28/2017 06:43 AM, Jens Axboe wrote:
>> On 06/28/2017 02:04 AM, Stephen Rothwell wrote:
>>> Hi Jens,
>>>
>>> After merging the block tree, today's linux-next build (powerpc
>>> allnoconfig) failed li
;fs: Add helper to clean bdev aliases under a bh and use it")
> ce98321bf7d2 ("fs: Remove unmap_underlying_metadata")
>
> Backing these patches out fixes the issue.
Fix is going out today, I see Chandan already pointed you at it. For the
other reporter, it's not an LE vs BE thing, it's a fs blocksize < page
size problem.
--
Jens Axboe
uest to Linus.
>
> Jens, could you expedite a pull request to Linus? This is affecting
> ext4 on 1k block file systems on x86/x86_64, so this is not a ppc-only
> regression.
Yes, it'll go out this morning.
--
Jens Axboe
to compute the
> number of blocks to be cleaned.
Thanks, added for 4.10.
--
Jens Axboe
roblem
> description and reproducer.
>
> Fixes: 20ce44d545844
> Signed-off-by: Jeff Moyer
>
> ---
> Chandan, can you please test this to ensure this still fixes your problem?
Please, that would be great. And if so, then let's fold the two.
--
Jens Axboe
fixes your problem?
>
> This patch fixes the failure,
>
> Tested-by: Chandan Rajendra
>
I've updated the patch, thanks guys.
--
Jens Axboe
On 5/9/18 7:59 AM, Christoph Hellwig wrote:
> Hi all,
>
> this series converts a few random block drivers to be highmem safe,
> in preparation of eventually getting rid of the block layer bounce
> buffering support.
Series looks good to me.
--
Jens Axboe
On 5/9/18 7:59 AM, Christoph Hellwig wrote:
> Hi all,
>
> this series converts a few random block drivers to be highmem safe,
> in preparation of eventually getting rid of the block layer bounce
> buffering support.
Applied, thanks.
--
Jens Axboe
c 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -497,7 +497,7 @@ static void scsi_run_queue(struct request_queue *q)
scsi_starved_list_run(sdev->host);
if (q->mq_ops)
- blk_mq_run_hw_queues(q, false);
+ blk_mq_run_hw_queues(q, true);
else
blk_run_queue(q);
}
--
Jens Axboe
--
Jens Axboe
On 07/27/2017 08:47 AM, Bart Van Assche wrote:
> On Thu, 2017-07-27 at 08:02 -0600, Jens Axboe wrote:
>> The bug looks like SCSI running the queue inline from IRQ
>> context, that's not a good idea. Can you confirm the below works for
>> you?
>>
>>
>> di
On 07/28/2017 12:19 AM, Michael Ellerman wrote:
> Jens Axboe writes:
>> On 07/27/2017 08:47 AM, Bart Van Assche wrote:
>>> On Thu, 2017-07-27 at 08:02 -0600, Jens Axboe wrote:
>>>> The bug looks like SCSI running the queue inline from IRQ
>&g
On 07/28/2017 09:13 AM, Bart Van Assche wrote:
> On Fri, 2017-07-28 at 08:25 -0600, Jens Axboe wrote:
>> On 07/28/2017 12:19 AM, Michael Ellerman wrote:
>>> OK, so the resolution is "fix it in IPR" ?
>>
>> I'll leave that to the SCSI crew. But at least
On 08/01/2017 12:55 AM, Michael Ellerman wrote:
> Jens Axboe writes:
> ...
>>
>> Can you try the below fix? Should be more palatable than the previous
>> one. Brian, maybe you can take a look at the IRQ issue mentioned above?
>
> Given the patch from Brian fixed the
On 08/08/2017 04:16 AM, Michael Ellerman wrote:
> Geoff Levand writes:
>
>> Hi Michael,
>>
>> A few very minor updates for PS3. Please apply.
>
> Jens do you want to take the block ones, or should I just take the lot?
Up to you, I'm fine either way.
--
Jens Axboe
a problematic workload - which
> may be triggered by a fuzzer.
If it's expected, why don't we kill the WARN_ON_ONCE()? I get it all
the time running xfstests as well.
--
Jens Axboe
On 09/18/2017 09:43 AM, Al Viro wrote:
> On Mon, Sep 18, 2017 at 05:39:47PM +0200, Christoph Hellwig wrote:
>> On Mon, Sep 18, 2017 at 09:28:55AM -0600, Jens Axboe wrote:
>>> If it's expected, why don't we kill the WARN_ON_ONCE()? I get it all
>>> the time
am
> not seeing, let's wait.
It's in that same file:
blk_ioc_init()
the cache itself never goes away, as the ioc code is not unloadable. So
I think the change there should be fine.
--
Jens Axboe
e pci_p2pdma flag to queue_limits
commit: 9c1e42e3c876c66796eda23e79836a4d92613a61
[25/26] block: move the skip_tagset_quiesce flag to queue_limits
commit: 8c8f5c85b20d0a7dc0ab9b2a17318130d69ceb5a
[26/26] block: move the bounce flag into the features field
commit: 339d3948c07b4aa2
On 6/19/24 8:18 AM, Jens Axboe wrote:
>
> On Mon, 17 Jun 2024 08:04:27 +0200, Christoph Hellwig wrote:
>> this is the third and last major series to convert settings to
>> queue_limits for this merge window. After a bunch of prep patches to
>> get various drivers in
ree_rcu for simple kmem_cache_free callback
commit: 7a9b197adbafa9d6d1a79a0633607b78b1adef82
Best regards,
--
Jens Axboe
s set
commit: c2398e6d5f16e15598d3a37e17107fea477e3f91
Best regards,
--
Jens Axboe
op = str_read_write(read);
> }
> if (status) {
> dev_dbg(&dev->sbd.core, "%s:%u: %s failed 0x%llx\n", __func__,
If you're doing this, why not kill off the useless 'read' variable as
well?
--
Jens Axboe
101 - 173 of 173 matches
Mail list logo
