* [PATCH 1/2] drm/i915: set O_LARGEFILE in __create_shmem()
@ 2025-08-11 9:30 陈涛涛 Taotao Chen
2025-08-11 9:31 ` [PATCH 2/2] drm/i915: Fix incorrect error handling in shmem_pwrite() 陈涛涛 Taotao Chen
` (3 more replies)
0 siblings, 4 replies; 10+ messages in thread
From: 陈涛涛 Taotao Chen @ 2025-08-11 9:30 UTC (permalink / raw)
To: jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
rodrigo.vivi@intel.com, tursulin@ursulin.net, airlied@gmail.com,
simona@ffwll.ch
Cc: oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
brauner@kernel.org, oliver.sang@intel.com,
陈涛涛 Taotao Chen
From: Taotao Chen <chentaotao@didiglobal.com>
Without O_LARGEFILE, file->f_op->write_iter calls
generic_write_check_limits(), which enforces a 2GB (MAX_NON_LFS) limit,
causing -EFBIG on large writes.
In shmem_pwrite(), this error is later masked as -EIO due to the error
handling order, leading to igt failures like gen9_exec_parse(bb-large).
Set O_LARGEFILE in __create_shmem() to prevent -EFBIG on large writes.
Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202508081029.343192ec-lkp@intel.com
Fixes: 048832a3f400 ("drm/i915: Refactor shmem_pwrite() to use kiocb and write_iter")
Signed-off-by: Taotao Chen <chentaotao@didiglobal.com>
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index e3d188455f67..2b53aad915f5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -514,6 +514,11 @@ static int __create_shmem(struct drm_i915_private *i915,
if (IS_ERR(filp))
return PTR_ERR(filp);
+ /*
+ * Prevent -EFBIG by allowing large writes beyond MAX_NON_LFS on shmem
+ * objects by setting O_LARGEFILE.
+ */
+ filp->f_flags |= O_LARGEFILE;
obj->filp = filp;
return 0;
}
--
2.34.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH 2/2] drm/i915: Fix incorrect error handling in shmem_pwrite()
2025-08-11 9:30 [PATCH 1/2] drm/i915: set O_LARGEFILE in __create_shmem() 陈涛涛 Taotao Chen
@ 2025-08-11 9:31 ` 陈涛涛 Taotao Chen
2025-08-12 14:06 ` Rodrigo Vivi
2025-08-20 17:10 ` Andi Shyti
2025-08-11 10:21 ` ✗ LGCI.VerificationFailed: failure for series starting with [1/2] " Patchwork
` (2 subsequent siblings)
3 siblings, 2 replies; 10+ messages in thread
From: 陈涛涛 Taotao Chen @ 2025-08-11 9:31 UTC (permalink / raw)
To: jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
rodrigo.vivi@intel.com, tursulin@ursulin.net, airlied@gmail.com,
simona@ffwll.ch
Cc: oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
brauner@kernel.org, oliver.sang@intel.com,
陈涛涛 Taotao Chen
From: Taotao Chen <chentaotao@didiglobal.com>
shmem_pwrite() currently checks for short writes before negative error
codes, which can overwrite real errors (e.g., -EFBIG) with -EIO.
Reorder the checks to return negative errors first, then handle short
writes.
Fixes: 048832a3f400 ("drm/i915: Refactor shmem_pwrite() to use kiocb and write_iter")
Signed-off-by: Taotao Chen <chentaotao@didiglobal.com>
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 2b53aad915f5..702532eef207 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -441,12 +441,12 @@ shmem_pwrite(struct drm_i915_gem_object *obj,
written = file->f_op->write_iter(&kiocb, &iter);
BUG_ON(written == -EIOCBQUEUED);
- if (written != size)
- return -EIO;
-
if (written < 0)
return written;
+ if (written != size)
+ return -EIO;
+
return 0;
}
--
2.34.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* ✗ LGCI.VerificationFailed: failure for series starting with [1/2] drm/i915: set O_LARGEFILE in __create_shmem()
2025-08-11 9:30 [PATCH 1/2] drm/i915: set O_LARGEFILE in __create_shmem() 陈涛涛 Taotao Chen
2025-08-11 9:31 ` [PATCH 2/2] drm/i915: Fix incorrect error handling in shmem_pwrite() 陈涛涛 Taotao Chen
@ 2025-08-11 10:21 ` Patchwork
2025-08-12 14:03 ` [PATCH 1/2] " Rodrigo Vivi
2025-08-20 21:31 ` Andi Shyti
3 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2025-08-11 10:21 UTC (permalink / raw)
To: 陈涛涛 Taotao Chen; +Cc: intel-gfx
== Series Details ==
Series: series starting with [1/2] drm/i915: set O_LARGEFILE in __create_shmem()
URL : https://patchwork.freedesktop.org/series/152763/
State : failure
== Summary ==
Address 'chentaotao@didiglobal.com' is not on the allowlist, which prevents CI from being triggered for this patch.
If you want Intel GFX CI to accept this address, please contact the script maintainers at i915-ci-infra@lists.freedesktop.org.
Exception occurred during validation, bailing out!
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] drm/i915: set O_LARGEFILE in __create_shmem()
2025-08-11 9:30 [PATCH 1/2] drm/i915: set O_LARGEFILE in __create_shmem() 陈涛涛 Taotao Chen
2025-08-11 9:31 ` [PATCH 2/2] drm/i915: Fix incorrect error handling in shmem_pwrite() 陈涛涛 Taotao Chen
2025-08-11 10:21 ` ✗ LGCI.VerificationFailed: failure for series starting with [1/2] " Patchwork
@ 2025-08-12 14:03 ` Rodrigo Vivi
2025-08-20 21:31 ` Andi Shyti
3 siblings, 0 replies; 10+ messages in thread
From: Rodrigo Vivi @ 2025-08-12 14:03 UTC (permalink / raw)
To: 陈涛涛 Taotao Chen, Matthew Auld
Cc: jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
tursulin@ursulin.net, airlied@gmail.com, simona@ffwll.ch,
oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
brauner@kernel.org, oliver.sang@intel.com
On Mon, Aug 11, 2025 at 09:30:55AM +0000, 陈涛涛 Taotao Chen wrote:
> From: Taotao Chen <chentaotao@didiglobal.com>
>
> Without O_LARGEFILE, file->f_op->write_iter calls
> generic_write_check_limits(), which enforces a 2GB (MAX_NON_LFS) limit,
> causing -EFBIG on large writes.
>
> In shmem_pwrite(), this error is later masked as -EIO due to the error
> handling order, leading to igt failures like gen9_exec_parse(bb-large).
>
> Set O_LARGEFILE in __create_shmem() to prevent -EFBIG on large writes.
>
> Reported-by: kernel test robot <oliver.sang@intel.com>
> Closes: https://lore.kernel.org/oe-lkp/202508081029.343192ec-lkp@intel.com
> Fixes: 048832a3f400 ("drm/i915: Refactor shmem_pwrite() to use kiocb and write_iter")
> Signed-off-by: Taotao Chen <chentaotao@didiglobal.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> index e3d188455f67..2b53aad915f5 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> @@ -514,6 +514,11 @@ static int __create_shmem(struct drm_i915_private *i915,
> if (IS_ERR(filp))
> return PTR_ERR(filp);
>
> + /*
> + * Prevent -EFBIG by allowing large writes beyond MAX_NON_LFS on shmem
> + * objects by setting O_LARGEFILE.
> + */
> + filp->f_flags |= O_LARGEFILE;
honest question, is it safe to set this here unconditionally?
Cc: Matthew Auld <matthew.auld@intel.com>
> obj->filp = filp;
> return 0;
> }
> --
> 2.34.1
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] drm/i915: Fix incorrect error handling in shmem_pwrite()
2025-08-11 9:31 ` [PATCH 2/2] drm/i915: Fix incorrect error handling in shmem_pwrite() 陈涛涛 Taotao Chen
@ 2025-08-12 14:06 ` Rodrigo Vivi
2025-08-20 17:03 ` Andi Shyti
2025-08-20 17:10 ` Andi Shyti
1 sibling, 1 reply; 10+ messages in thread
From: Rodrigo Vivi @ 2025-08-12 14:06 UTC (permalink / raw)
To: 陈涛涛 Taotao Chen
Cc: jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
tursulin@ursulin.net, airlied@gmail.com, simona@ffwll.ch,
oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
brauner@kernel.org, oliver.sang@intel.com
On Mon, Aug 11, 2025 at 09:31:00AM +0000, 陈涛涛 Taotao Chen wrote:
> From: Taotao Chen <chentaotao@didiglobal.com>
>
> shmem_pwrite() currently checks for short writes before negative error
> codes, which can overwrite real errors (e.g., -EFBIG) with -EIO.
> Reorder the checks to return negative errors first, then handle short
> writes.
>
> Fixes: 048832a3f400 ("drm/i915: Refactor shmem_pwrite() to use kiocb and write_iter")
> Signed-off-by: Taotao Chen <chentaotao@didiglobal.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> index 2b53aad915f5..702532eef207 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> @@ -441,12 +441,12 @@ shmem_pwrite(struct drm_i915_gem_object *obj,
> written = file->f_op->write_iter(&kiocb, &iter);
> BUG_ON(written == -EIOCBQUEUED);
>
> - if (written != size)
> - return -EIO;
> -
> if (written < 0)
> return written;
>
> + if (written != size)
> + return -EIO;
That's awkward...
I mean, you are right that we cannot overwrite what is returned from the
write_iter function. But perhaps this != check here should be before?
Or it at least deserves a comment in the code telling what's the intent
here. why != size is -EIO... but it was already written :/
> +
> return 0;
> }
>
> --
> 2.34.1
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] drm/i915: Fix incorrect error handling in shmem_pwrite()
2025-08-12 14:06 ` Rodrigo Vivi
@ 2025-08-20 17:03 ` Andi Shyti
0 siblings, 0 replies; 10+ messages in thread
From: Andi Shyti @ 2025-08-20 17:03 UTC (permalink / raw)
To: Rodrigo Vivi
Cc: 陈涛涛 Taotao Chen, jani.nikula@linux.intel.com,
joonas.lahtinen@linux.intel.com, tursulin@ursulin.net,
airlied@gmail.com, simona@ffwll.ch, oe-lkp@lists.linux.dev,
lkp@intel.com, linux-kernel@vger.kernel.org,
intel-gfx@lists.freedesktop.org, brauner@kernel.org,
oliver.sang@intel.com
Hi Rodrigo,
...
> > @@ -441,12 +441,12 @@ shmem_pwrite(struct drm_i915_gem_object *obj,
> > written = file->f_op->write_iter(&kiocb, &iter);
> > BUG_ON(written == -EIOCBQUEUED);
> >
> > - if (written != size)
> > - return -EIO;
> > -
> > if (written < 0)
> > return written;
> >
> > + if (written != size)
> > + return -EIO;
>
> That's awkward...
>
> I mean, you are right that we cannot overwrite what is returned from the
> write_iter function. But perhaps this != check here should be before?
>
> Or it at least deserves a comment in the code telling what's the intent
> here. why != size is -EIO... but it was already written :/
The check (written < 0) is completely useless after (written !=
size), so that I think the patch is correct.
Andi
> > +
> > return 0;
> > }
> >
> > --
> > 2.34.1
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] drm/i915: Fix incorrect error handling in shmem_pwrite()
2025-08-11 9:31 ` [PATCH 2/2] drm/i915: Fix incorrect error handling in shmem_pwrite() 陈涛涛 Taotao Chen
2025-08-12 14:06 ` Rodrigo Vivi
@ 2025-08-20 17:10 ` Andi Shyti
2025-08-21 3:21 ` [PATCH 1/2] drm/i915: set O_LARGEFILE in __create_shmem() 陈涛涛 Taotao Chen
1 sibling, 1 reply; 10+ messages in thread
From: Andi Shyti @ 2025-08-20 17:10 UTC (permalink / raw)
To: 陈涛涛 Taotao Chen
Cc: jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
rodrigo.vivi@intel.com, tursulin@ursulin.net, airlied@gmail.com,
simona@ffwll.ch, oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
brauner@kernel.org, oliver.sang@intel.com
Hi Taotao,
On Mon, Aug 11, 2025 at 09:31:00AM +0000, 陈涛涛 Taotao Chen wrote:
> From: Taotao Chen <chentaotao@didiglobal.com>
>
> shmem_pwrite() currently checks for short writes before negative error
> codes, which can overwrite real errors (e.g., -EFBIG) with -EIO.
> Reorder the checks to return negative errors first, then handle short
> writes.
>
> Fixes: 048832a3f400 ("drm/i915: Refactor shmem_pwrite() to use kiocb and write_iter")
I don't think we need the Fixes: tag here, in any case we return
an error and -EIO is somehow correct.
With the Fixes removed:
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Andi
> Signed-off-by: Taotao Chen <chentaotao@didiglobal.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> index 2b53aad915f5..702532eef207 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> @@ -441,12 +441,12 @@ shmem_pwrite(struct drm_i915_gem_object *obj,
> written = file->f_op->write_iter(&kiocb, &iter);
> BUG_ON(written == -EIOCBQUEUED);
>
> - if (written != size)
> - return -EIO;
> -
> if (written < 0)
> return written;
>
> + if (written != size)
> + return -EIO;
> +
> return 0;
> }
>
> --
> 2.34.1
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] drm/i915: set O_LARGEFILE in __create_shmem()
2025-08-11 9:30 [PATCH 1/2] drm/i915: set O_LARGEFILE in __create_shmem() 陈涛涛 Taotao Chen
` (2 preceding siblings ...)
2025-08-12 14:03 ` [PATCH 1/2] " Rodrigo Vivi
@ 2025-08-20 21:31 ` Andi Shyti
3 siblings, 0 replies; 10+ messages in thread
From: Andi Shyti @ 2025-08-20 21:31 UTC (permalink / raw)
To: 陈涛涛 Taotao Chen
Cc: jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
rodrigo.vivi@intel.com, tursulin@ursulin.net, airlied@gmail.com,
simona@ffwll.ch, oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
brauner@kernel.org, oliver.sang@intel.com
Hi Taotao,
> Reported-by: kernel test robot <oliver.sang@intel.com>
> Closes: https://lore.kernel.org/oe-lkp/202508081029.343192ec-lkp@intel.com
...
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> index e3d188455f67..2b53aad915f5 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> @@ -514,6 +514,11 @@ static int __create_shmem(struct drm_i915_private *i915,
> if (IS_ERR(filp))
> return PTR_ERR(filp);
>
> + /*
> + * Prevent -EFBIG by allowing large writes beyond MAX_NON_LFS on shmem
> + * objects by setting O_LARGEFILE.
> + */
> + filp->f_flags |= O_LARGEFILE;
I don't have anything against this, but is it really fixing the
issue? I thought that O_LARGEFILE is ignored in 64 bit machines,
while here the failure is happening in 64 bit machines.
Besides, where do you see in the LKP logs the -EFBIG error
message?
Andi
> obj->filp = filp;
> return 0;
> }
> --
> 2.34.1
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] drm/i915: set O_LARGEFILE in __create_shmem()
2025-08-20 17:10 ` Andi Shyti
@ 2025-08-21 3:21 ` 陈涛涛 Taotao Chen
2025-08-21 12:12 ` Andi Shyti
0 siblings, 1 reply; 10+ messages in thread
From: 陈涛涛 Taotao Chen @ 2025-08-21 3:21 UTC (permalink / raw)
To: andi.shyti@kernel.org, rodrigo.vivi@intel.com
Cc: airlied@gmail.com, brauner@kernel.org,
陈涛涛 Taotao Chen,
intel-gfx@lists.freedesktop.org, jani.nikula@linux.intel.com,
joonas.lahtinen@linux.intel.com, linux-kernel@vger.kernel.org,
lkp@intel.com, oe-lkp@lists.linux.dev, oliver.sang@intel.com,
simona@ffwll.ch, tursulin@ursulin.net
From: Taotao Chen <chentaotao@didiglobal.com>
Hi Andi,
> Hi Taotao,
>
>> Reported-by: kernel test robot <oliver.sang@intel.com>
>> Closes: https://lore.kernel.org/oe-lkp/202508081029.343192ec-lkp@intel.com
>
> ...
>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> index e3d188455f67..2b53aad915f5 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> @@ -514,6 +514,11 @@ static int __create_shmem(struct drm_i915_private *i915,
>> if (IS_ERR(filp))
>> return PTR_ERR(filp);
>>
>> + /*
>> + * Prevent -EFBIG by allowing large writes beyond MAX_NON_LFS on shmem
>> + * objects by setting O_LARGEFILE.
>> + */
>> + filp->f_flags |= O_LARGEFILE;
>
> I don't have anything against this, but is it really fixing the
> issue? I thought that O_LARGEFILE is ignored in 64 bit machines,
> while here the failure is happening in 64 bit machines.
As mentioned in the commit body, without O_LARGEFILE, file->f_op->write_iter
calls generic_write_check_limits(), which enforces the 2GB (MAX_NON_LFS) limit
and causes -EFBIG on large writes.
On 64-bit systems O_LARGEFILE is still set when opening files (e.g. via open()),
so we also need to set it here for shmem objects created inside the kernel.
However, on older 32-bit systems, setting O_LARGEFILE unconditionally may be risky.
Previously I did not check this, but to reduce the risk a safer approach is to wrap
it in a check, for example:
+ if (force_o_largefile())
+ filp->f_flags |= O_LARGEFILE;
>
> Besides, where do you see in the LKP logs the -EFBIG error
> message?
>
Due to the previous return order in shmem_pwrite(), this -EFBIG was being overwritten
by -EIO on short writes. This issue will be fixed in PATCH 2/2.
Taotao
> Andi
>
>> obj->filp = filp;
>> return 0;
>> }
>> --
>> 2.34.1
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] drm/i915: set O_LARGEFILE in __create_shmem()
2025-08-21 3:21 ` [PATCH 1/2] drm/i915: set O_LARGEFILE in __create_shmem() 陈涛涛 Taotao Chen
@ 2025-08-21 12:12 ` Andi Shyti
0 siblings, 0 replies; 10+ messages in thread
From: Andi Shyti @ 2025-08-21 12:12 UTC (permalink / raw)
To: 陈涛涛 Taotao Chen
Cc: rodrigo.vivi@intel.com, airlied@gmail.com, brauner@kernel.org,
intel-gfx@lists.freedesktop.org, jani.nikula@linux.intel.com,
joonas.lahtinen@linux.intel.com, linux-kernel@vger.kernel.org,
lkp@intel.com, oe-lkp@lists.linux.dev, oliver.sang@intel.com,
simona@ffwll.ch, tursulin@ursulin.net
Hi Taotao,
...
> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> >> index e3d188455f67..2b53aad915f5 100644
> >> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> >> @@ -514,6 +514,11 @@ static int __create_shmem(struct drm_i915_private *i915,
> >> if (IS_ERR(filp))
> >> return PTR_ERR(filp);
> >>
> >> + /*
> >> + * Prevent -EFBIG by allowing large writes beyond MAX_NON_LFS on shmem
> >> + * objects by setting O_LARGEFILE.
> >> + */
> >> + filp->f_flags |= O_LARGEFILE;
> >
> > I don't have anything against this, but is it really fixing the
> > issue? I thought that O_LARGEFILE is ignored in 64 bit machines,
> > while here the failure is happening in 64 bit machines.
>
> As mentioned in the commit body, without O_LARGEFILE, file->f_op->write_iter
> calls generic_write_check_limits(), which enforces the 2GB (MAX_NON_LFS) limit
> and causes -EFBIG on large writes.
>
> On 64-bit systems O_LARGEFILE is still set when opening files (e.g. via open()),
> so we also need to set it here for shmem objects created inside the kernel.
>
> However, on older 32-bit systems, setting O_LARGEFILE unconditionally may be risky.
> Previously I did not check this, but to reduce the risk a safer approach is to wrap
> it in a check, for example:
>
> + if (force_o_largefile())
> + filp->f_flags |= O_LARGEFILE;
Ack!
> > Besides, where do you see in the LKP logs the -EFBIG error
> > message?
> >
>
> Due to the previous return order in shmem_pwrite(), this -EFBIG was being overwritten
> by -EIO on short writes. This issue will be fixed in PATCH 2/2.
Yes, correct :-)
Thanks,
Andi
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2025-08-21 12:12 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-11 9:30 [PATCH 1/2] drm/i915: set O_LARGEFILE in __create_shmem() 陈涛涛 Taotao Chen
2025-08-11 9:31 ` [PATCH 2/2] drm/i915: Fix incorrect error handling in shmem_pwrite() 陈涛涛 Taotao Chen
2025-08-12 14:06 ` Rodrigo Vivi
2025-08-20 17:03 ` Andi Shyti
2025-08-20 17:10 ` Andi Shyti
2025-08-21 3:21 ` [PATCH 1/2] drm/i915: set O_LARGEFILE in __create_shmem() 陈涛涛 Taotao Chen
2025-08-21 12:12 ` Andi Shyti
2025-08-11 10:21 ` ✗ LGCI.VerificationFailed: failure for series starting with [1/2] " Patchwork
2025-08-12 14:03 ` [PATCH 1/2] " Rodrigo Vivi
2025-08-20 21:31 ` Andi Shyti
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).