on Sean's suggestion.
>
> Signed-off-by: Christian Brauner
>
> Changes in v2:
> - further simplify helpers
> - Link to v1:
> https://lore.kernel.org/r/20230713-vfs-eventfd-signal-v1-0-7fda6c5d2...@kernel.org
Only oddity I spotted was the kerneldoc, which someone else already
broug
rigger was in no way related to where the actual bug was.
I ran this on the vm I have access to, and it survived 2x500 iterations.
Happy to call that good:
Tested-by: Jens Axboe
--
Jens Axboe
ck:sed-opal: SED Opal keystore
commit: 96ff37ceb203426b1bcebbae42399686110b0130
[2/3] block: sed-opal: keystore access for SED Opal keys
commit: 5dd339722f5f612f349b068e8da6d6710fd0e460
[3/3] powerpc/pseries: PLPKS SED Opal keystore support
commit: ec8cf230ceccfcc2bd29990c2902be168a92dee4
Best regards,
--
Jens Axboe
On 10/17/23 9:09 AM, Greg Joyce wrote:
>
> Hi Jens,
>
> I've addressed all the comments/issues on v7 of the patchset and
> haven't received any feedback on v8. Is there anything else that you'd
> like to see before this can be included?
Let's give it another shot!
--
Jens Axboe
"), I see the following crash when
> booting some distribution configurations, such as OpenSUSE's [1] (the
> rootfs is available at [2] if necessary):
I'll drop the series for now - I didn't push out the main branch just
yet as I don't publish the block next tree until at least at -rc2 time,
so it's just in a private branch for now.
--
Jens Axboe
.
>
> PowerPC/pseries versions of these functions provide read/write access
> to SED Opal keys in the PLPKS keystore.
>
> The SED block driver has been modified to read the SED Opal
> keystore to populate a key in the SED Opal keyring. Changes to the
> SED Opal key will be written to the SED Opal keystore.
Applied for 6.7, thanks.
--
Jens Axboe
ing patches for the next release before that
happens. I'll try to remember to pick this one up for 6.7.
--
Jens Axboe
OPAL_DISCOVERY
commit: 9fb10726ecc5145550180aec4fd0adf0a7b1d634
[2/3] block: sed-opal: Implement IOC_OPAL_REVERT_LSP
commit: 5c82efc1aee8eb0919aa67a0d2559de5a326bd7c
[3/3] block: sed-opal: keyring support for SED keys
commit: 3bfeb61256643281ac4be5b8a57e9d9da3db4335
Best regards,
--
Jens Axboe
why you'd rebase to an old kernel rather than a 6.4-rc at
least?
Please resend one that is current.
--
Jens Axboe
On 3/28/23 6:51?AM, Michael Ellerman wrote:
> Jens Axboe writes:
>>>> Can the queueing cause the creation of an IO thread (if one does not
>>>> exist, or all blocked?)
>>>
>>> Yep
>>>
>>> Since writing this email, I've gone through
On 3/28/23 5:32?AM, Michael Ellerman wrote:
> Jens Axboe writes:
>> Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
>> from my (arguably very short) checking is not commonly done for other
>> archs. This is fine, except when PF_IO_WORKER's have been cr
mingly
fixes the issue too. This does not mean that each worker will process
work on the CPU on which it was queued, just that each worker will
remain on whatever CPU it originally got created on.
Puzzling...
Note that it is indeed quite possible that this isn't a ppc issue at
all, just shows on ppc. It could be page cache related, or it could even
be a bug in mariadb itself.
--
Jens Axboe
On 3/27/23 7:54?AM, Michael Ellerman wrote:
> "Nicholas Piggin" writes:
>> On Mon Mar 27, 2023 at 8:15 AM AEST, Jens Axboe wrote:
>>> Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
>>> from my (arguably very short) checking is
On 3/27/23 12:36?AM, Nicholas Piggin wrote:
> On Mon Mar 27, 2023 at 8:15 AM AEST, Jens Axboe wrote:
>> Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
>> from my (arguably very short) checking is not commonly done for other
>> archs. This is fine, excep
On 3/26/23 10:22?PM, Nicholas Piggin wrote:
> On Sat Mar 25, 2023 at 11:20 AM AEST, Jens Axboe wrote:
>> On 3/24/23 7:15?PM, Jens Axboe wrote:
>>>> Are there any CONFIG options I'd need to trip this?
>>>
>>> I don't think you need any special CONFIG options
re,
so just pick -EINVAL.
Signed-off-by: Jens Axboe
diff --git a/arch/powerpc/kernel/ptrace/ptrace-view.c
b/arch/powerpc/kernel/ptrace/ptrace-view.c
index 2087a785f05f..80b699dd0d7f 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-view.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-view.c
@@ -290,6
On 3/24/23 6:42?PM, Michael Ellerman wrote:
> Jens Axboe writes:
>> Hi,
>
> Hi Jens,
>
> Thanks for the report.
>
>> I got a report sent to me from mariadb, in where 5.10.158 works fine and
>> 5.10.162 is broken. And in fact, current 6.3-rc also fails the
On 3/24/23 6:15 PM, Michael Ellerman wrote:
> Jens Axboe writes:
>> On 3/24/23 1:27?AM, Christophe Leroy wrote:
>>> Le 23/03/2023 ? 19:54, Jens Axboe a ?crit :
>>>> I got a report sent to me from mariadb, in where 5.10.158 works fine and
>>>> 5.10.162 i
On 3/24/23 1:27?AM, Christophe Leroy wrote:
> Hi,
>
> Le 23/03/2023 ? 19:54, Jens Axboe a ?crit :
>> Hi,
>>
>> I got a report sent to me from mariadb, in where 5.10.158 works fine and
>> 5.10.162 is broken. And in fact, current 6.3-rc also fails the test
>&g
, and it still falls flat on its
face with the offload to an IO thread.
I must clearly be missing something here, which is why I'm emailing the
powerpc Gods for help :-)
--
Jens Axboe
re only used by bio_split_to_limits.
>
>
Applied, thanks!
[1/1] ps3vram: remove bio splitting
commit: 2192a93eb4ac63eeb37ec5ec5cfa0db92ded5e3c
Best regards,
--
Jens Axboe
cpy with unused retval to strscpy
commit: e55e1b4831563e5766f88fa821f5bfac0d6c298c
Best regards,
--
Jens Axboe
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
dd 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
56cd23e33
[11/13] ps3vram: add error handling support for add_disk()
commit: 3c30883acab1d20ecbd3c48dc12b147b51548742
Best regards,
--
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
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
e 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
gt; in all drivers that do not have any caveats in their gendisk and
> request_queue lifetime rules.
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
; 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
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
e equivalent transformation and stop asking for block
> layer bounce buffering.
Applied, thanks.
--
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
a 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
finitely 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
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
t;> [c000163679e0] [c0080040791c]
>>>>> xfs_file_buffered_aio_write+0x314/0x5e0 [xfs]
>>>>> [c00016367a90] [c000006d74bc] 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 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 28, 20
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
e 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
On 10/29/20 6:48 PM, Michael Ellerman wrote:
> Jens Axboe writes:
>> Wire up TIF_NOTIFY_SIGNAL handling for powerpc.
>>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Signed-off-by: Jens Axboe
>> ---
>>
>> 5.11 has support queued up for TIF_NOTIFY_SIGNAL,
Wire up TIF_NOTIFY_SIGNAL handling for powerpc.
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Jens Axboe
---
5.11 has support queued up for TIF_NOTIFY_SIGNAL, see this posting
for details:
https://lore.kernel.org/io-uring/20201026203230.386348-1-ax...@kernel.dk/
As part of that work, I'm
On 10/26/20 6:05 PM, Al Viro wrote:
> On Mon, Oct 26, 2020 at 05:56:11PM -0600, Jens Axboe wrote:
>> On 10/26/20 4:55 PM, Kyle Huey wrote:
>>> A test program from the rr[0] test suite, vm_readv_writev[1], no
>>> longer works on 5.10-rc1 when compiled as a 32 bit binary a
r, false);
+ iov_r = iovec_from_user(rvec, riovcnt, UIO_FASTIOV, iovstack_r,
+ in_compat_syscall());
if (IS_ERR(iov_r)) {
rc = PTR_ERR(iov_r);
goto free_iov_l;
--
Jens Axboe
he
> path to issue to blk-mq, removing the need for the direct_make_request
> bypass.
Thanks, I'll try this again.
--
Jens Axboe
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
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 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_
he
> 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
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
On 11/29/19 10:07 AM, Pavel Begunkov wrote:
On 29/11/2019 20:16, Jens Axboe wrote:
On 11/29/19 8:14 AM, Christophe Leroy wrote:
Reverting commit 311ae9e159d8 ("io_uring: fix dead-hung for non-iter
fixed rw") clears the failure.
Most likely an #include is missing.
Huh weird how
On 11/29/19 8:14 AM, Christophe Leroy wrote:
Le 29/11/2019 à 17:04, Jens Axboe a écrit :
On 11/29/19 6:53 AM, Christophe Leroy wrote:
CC fs/io_uring.o
fs/io_uring.c: In function ‘loop_rw_iter’:
fs/io_uring.c:1628:21: error: implicit declaration of function ‘kmap’
[-Werror=implicit
ring.c b/fs/io_uring.c
index 2c2e8c25da01..745eb005fefe 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -69,6 +69,7 @@
#include
#include
#include
+#include
#define CREATE_TRACE_POINTS
#include
--
Jens Axboe
user_pages() to pin_user_pages().
>
> Reviewed-by: Jan Kara
> Signed-off-by: John Hubbard
You dropped my reviewed-by now... Given the file, you'd probably want
to keep that.
--
Jens Axboe
On 10/30/19 4:49 PM, John Hubbard wrote:
> Convert fs/io_uring to use the new pin_user_pages() call, which sets
> FOLL_PIN. Setting FOLL_PIN is now required for code that requires
> tracking of pinned pages, and therefore for any code that calls
> put_user_page().
Reviewed-by
s/block/ps3vram.c: In function ‘ps3vram_probe’:
> drivers/block/ps3vram.c:770:23: warning: format ‘%lu’ expects argument
> of type ‘long unsigned int’, but argument 4 has type ‘sector_t {aka long long
> unsigned int}’ [-Wformat=]
>
> Fix this by using "%llu" instead.
Applied, thanks.
--
Jens Axboe
On 4/3/19 9:49 AM, Will Deacon wrote:
> On Wed, Apr 03, 2019 at 09:39:52AM -0600, Jens Axboe wrote:
>> On 4/3/19 9:19 AM, Will Deacon wrote:
>>> On Wed, Apr 03, 2019 at 07:49:26AM -0600, Jens Axboe wrote:
>>>> On 4/3/19 5:11 AM, Will Deacon wrote:
>>
On 4/3/19 9:19 AM, Will Deacon wrote:
> Hi Jens,
>
> On Wed, Apr 03, 2019 at 07:49:26AM -0600, Jens Axboe wrote:
>> On 4/3/19 5:11 AM, Will Deacon wrote:
>>> will@autoplooker:~/liburing/test$ ./io_uring_register
>>> RELIMIT_MEMLOCK: 67108864 (67108864)
>>&
odules linked in:
> [ 35.485311] CPU: 113 PID: 3973 Comm: io_uring_regist Not tainted
> 5.1.0-rc3-00012-g40b114779944 #1
> [ 35.486712] Hardware name: linux,dummy-virt (DT)
> [ 35.487450] pstate: 2045 (nzCv daif +PAN -UAO)
> [ 35.488228] pc : link_pwq+0x10/0x60
> [ 35.488794] lr : apply_wqattrs_commit+0xe0/0x118
> [ 35.489550] sp : 17e2bbc0
Huh, this looks odd, it's crashing inside the wq setup.
--
Jens Axboe
request_irq() error path. Move the memset() to fix this bug.
>
> BTW, the request_irq() failure for the left mediabay floppy (fd1) is not
> a regression. I don't know why it happens. The right media bay floppy
> (fd0) works fine however.
Applied, thanks.
--
Jens Axboe
ethod.
Applied, thanks.
--
Jens Axboe
On 12/30/18 10:44 PM, Finn Thain wrote:
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Finn Thain
Applied, thanks.
--
Jens Axboe
-off-by: Anshuman Khandual
>
> For the 'ixgbe' driver changes.
>
> Acked-by: Jeff Kirsher
Lost the original, but for mtip32xx:
Acked-by: Jens Axboe
--
Jens Axboe
sn't boot any more, bisect points at one of:
>>>
>>> cef6f55a9fb4 Mike Snitzer dm table: require that request-based DM
>>> be layered on blk-mq devices
>>> 953923c09fe8 Mike Snitzer dm: rename DM_TYPE_MQ_REQUEST_BASED to
>>> DM_TYPE_REQU
w them out.
>
> A short status yields the following _outdated_ 00-INDEX files, first
> counter is files listed in 00-INDEX but missing in the directory, last
> is files present but not listed in 00-INDEX.
For the block related bits:
Reviewed-by: Jens Axboe
--
Jens Axboe
mempool_free_slab, (void *) kc);
}
diff --git a/mm/mempool.c b/mm/mempool.c
index b54f2c20e5e0..060f44acd0df 100644
--- a/mm/mempool.c
+++ b/mm/mempool.c
@@ -508,7 +508,9 @@ EXPORT_SYMBOL(mempool_alloc_slab);
void mempool_free_slab(void *element, void *pool_data)
{
struct kmem_cache *mem = pool_data;
- kmem_cache_free(mem, element);
+
+ if (!WARN_ON(!mem))
+ kmem_cache_free(mem, element);
}
EXPORT_SYMBOL(mempool_free_slab);
--
Jens Axboe
On 6/19/18 5:35 PM, Michael Ellerman wrote:
> Jens Axboe writes:
>> On 6/19/18 1:29 AM, Michael Ellerman wrote:
>>> Jens Axboe writes:
>>>> On 6/18/18 1:33 AM, Michael Ellerman wrote:
>>>>> Tejun Heo writes:
>>>>> ...
>>>&
On 6/19/18 1:29 AM, Michael Ellerman wrote:
> Jens Axboe writes:
>> On 6/18/18 1:33 AM, Michael Ellerman wrote:
>>> Tejun Heo writes:
>>> ...
>>>> Jens Axboe (10):
>>>> libata: introduce notion of separate hardware tags
>>&g
On 6/19/18 1:29 AM, Michael Ellerman wrote:
> Jens Axboe writes:
>> On 6/18/18 1:33 AM, Michael Ellerman wrote:
>>> Tejun Heo writes:
>>> ...
>>>> Jens Axboe (10):
>>>> libata: introduce notion of separate hardware tags
>>&g
On 6/18/18 1:33 AM, Michael Ellerman wrote:
> Tejun Heo writes:
> ...
>> Jens Axboe (10):
>> libata: introduce notion of separate hardware tags
>> libata: convert core and drivers to ->hw_tag usage
>> libata: bump ->qc_active t
On 6/7/18 8:45 AM, Jens Axboe wrote:
> On 6/7/18 4:37 AM, vrbagal1 wrote:
>> On 2018-06-07 13:12, Bart Van Assche wrote:
>>> On Thu, 2018-06-07 at 12:56 +0530, Venkat Rao B wrote:
>>>> On Thursday 07 June 2018 12:46 PM, Bart Van Assche wrote:
>>>>> On T
dm driver is involved. An
>> important fix
>> for the dm driver went upstream recently, namely d37753540568 ("dm: Use
>> kzalloc
>> for all structs with embedded biosets/mempools"). Can you double check
>> whether
>> that commit it present in your tree?
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
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 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 running x
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 08/08/2017 04:16 AM, Michael Ellerman wrote:
> Geoff Levand <ge...@infradead.org> 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
On 08/01/2017 12:55 AM, Michael Ellerman wrote:
> Jens Axboe <ax...@kernel.dk> 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 th
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 one b
On 07/28/2017 12:19 AM, Michael Ellerman wrote:
> Jens Axboe <ax...@kernel.dk> 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
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?
>>
>>
>> diff --
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?
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index f6097b89d5d3..78740ebf966c 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -
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 like th
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':
>&g
r
> 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 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
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
>>>> 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
by put_disk(). Add that call where
> needed.
Applied, thanks.
--
Jens Axboe
ease test this to ensure this still fixes your problem?
>
> This patch fixes the failure,
>
> Tested-by: Chandan Rajendra <chan...@linux.vnet.ibm.com>
>
I've updated the patch, thanks guys.
--
Jens Axboe
m
> description and reproducer.
>
> Fixes: 20ce44d545844
> Signed-off-by: Jeff Moyer <jmo...@redhat.com>
>
> ---
> 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
ts to compute the
> number of blocks to be cleaned.
Thanks, added for 4.10.
--
Jens Axboe
> 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 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
fore that, so I hit this twice today.
Update to the tree as-of yesterday (or today) and it should work.
25364a9e54fb8296 doesn't include the latest block fixes that were sent
in yesterday, that should fix it. You need commit a88d32af18b8 or newer.
--
Jens Axboe
lready, so how is the above
making it any different? In general, NOMERGE being set or not should not
make a difference. It's only a hint that we need not check further if we
should be merging on this request, since we already tried it once, found
we'd exceed various limits, then set NOMERGE
On 11/25/2015 12:10 PM, Hannes Reinecke wrote:
On 11/25/2015 06:56 PM, Jens Axboe wrote:
On 11/25/2015 02:04 AM, Hannes Reinecke wrote:
On 11/20/2015 04:28 PM, Ewan Milne wrote:
On Fri, 2015-11-20 at 15:55 +0100, Hannes Reinecke wrote:
Can't we have a joint effort here?
I've been spending
of
unrelated changes for 3 patches. If you are targeting the next release
and don't depend on existing block changes, then your base should be
4.0. If you are dependent on changes in the block tree, the block tree
should be your base.
--
Jens Axboe
regarding it.
Please apply, thanks.
Applied to for-4.2/drivers, thanks.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
1 - 100 of 153 matches
Mail list logo
