On Tue, Jun 06, 2023 at 09:39:25AM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> ---
$ git grep cdrom_release
Documentation/cdrom/cdrom-standard.rst: cdrom_release, /*
release */
Documentation/cdrom/cdrom-standard.rst:the door, should be left over to the
On 6/26/23 00:53, Christoph Hellwig wrote:
On Fri, Jun 23, 2023 at 05:08:59PM -0700, Guenter Roeck wrote:
Hi,
On Wed, May 31, 2023 at 02:55:19PM +0200, Christoph Hellwig wrote:
Instead of declaring root_device_name as a global variable pass it as an
argument to the functions using it.
Signed
Hi,
On Wed, May 31, 2023 at 02:55:19PM +0200, Christoph Hellwig wrote:
> Instead of declaring root_device_name as a global variable pass it as an
> argument to the functions using it.
>
> Signed-off-by: Christoph Hellwig
This patch results in the following build error when trying to build
On 6/22/23 07:40, Christoph Hellwig wrote:
On Thu, Jun 22, 2023 at 06:54:41AM -0700, Guenter Roeck wrote:
On 6/21/23 23:00, Christoph Hellwig wrote:
Hi Guenter,
can you try this patch?
diff --git a/block/early-lookup.c b/block/early-lookup.c
index a5be3c68ed079c..66e4514d671179 100644
On 6/21/23 23:00, Christoph Hellwig wrote:
Hi Guenter,
can you try this patch?
diff --git a/block/early-lookup.c b/block/early-lookup.c
index a5be3c68ed079c..66e4514d671179 100644
--- a/block/early-lookup.c
+++ b/block/early-lookup.c
@@ -174,7 +174,7 @@ static int __init
On 6/21/23 20:51, Christoph Hellwig wrote:
On Wed, Jun 21, 2023 at 02:07:13PM -0700, Guenter Roeck wrote:
On Tue, May 23, 2023 at 09:45:25AM +0200, Christoph Hellwig wrote:
Instead of only clearing root_wait in devt_from_partuuid when the UUID
format was invalid, do that in parse_root_device
Hi,
On Tue, May 23, 2023 at 09:45:25AM +0200, Christoph Hellwig wrote:
> Instead of only clearing root_wait in devt_from_partuuid when the UUID
> format was invalid, do that in parse_root_device for all strings that
> failed to parse.
>
> Signed-off-by: Christoph Hellwig
In linux-next, almost
On Thu, Jul 07, 2022 at 10:08:33AM +0200, Greg KH wrote:
[ ... ]
> >
> > Unverified Error/Warning (likely false positive, please contact us if
> > interested):
> >
> > arch/x86/events/core.c:2114 init_hw_perf_events() warn: missing error code
> > 'err'
> > drivers/android/binder.c:1481:19-23:
On 6/15/22 13:02, Mike Snitzer wrote:
On Wed, Jun 15 2022 at 1:50P -0400,
Guenter Roeck wrote:
On 6/15/22 08:29, Mike Snitzer wrote:
On Wed, Jun 15 2022 at 10:36P -0400,
Guenter Roeck wrote:
On Mon, Jun 13, 2022 at 11:13:21AM +0200, Greg KH wrote:
On Fri, Jun 10, 2022 at 11:11:00AM
On Wed, Jun 15, 2022 at 04:02:36PM -0400, Mike Snitzer wrote:
> On Wed, Jun 15 2022 at 1:50P -0400,
> Guenter Roeck wrote:
>
> > On 6/15/22 08:29, Mike Snitzer wrote:
> > > On Wed, Jun 15 2022 at 10:36P -0400,
> > > Guenter Roeck wrote:
> > >
> &
On Wed, Jun 15, 2022 at 04:02:36PM -0400, Mike Snitzer wrote:
[ ... ]
>
> OK, well this is pretty easy to fix in general. If there are slight
> differences across older trees they are easily resolved. Fact that
> stable@ couldn't cope with backporting 9c37de297f65 is.. what it is.
>
> But this
On 6/15/22 08:29, Mike Snitzer wrote:
On Wed, Jun 15 2022 at 10:36P -0400,
Guenter Roeck wrote:
On Mon, Jun 13, 2022 at 11:13:21AM +0200, Greg KH wrote:
On Fri, Jun 10, 2022 at 11:11:00AM -0400, Mike Snitzer wrote:
On Fri, Jun 10 2022 at 1:15P -0400,
Greg KH wrote:
On Fri, Jun 10, 2022
On Mon, Jun 13, 2022 at 11:13:21AM +0200, Greg KH wrote:
> On Fri, Jun 10, 2022 at 11:11:00AM -0400, Mike Snitzer wrote:
> > On Fri, Jun 10 2022 at 1:15P -0400,
> > Greg KH wrote:
> >
> > > On Fri, Jun 10, 2022 at 04:22:00AM +, Oleksandr Tymoshenko wrote:
> > > > I believe this commit
gfp = mapping_gfp_constraint(page->mapping, GFP_KERNEL);
> + gfp |= __GFP_NORETRY | __GFP_NOWARN;
> }
>
> if (page_has_buffers(page))
That fixes the problem for me.
Tested-by: Guenter Roeck
Guenter
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Mon, Jan 24, 2022 at 10:10:49AM +0100, Christoph Hellwig wrote:
> open code mpage_alloc in it's two callers and simplify the results
> because of the context:
>
> - __mpage_writepage always passes GFP_NOFS and can thus always sleep and
> will never get a NULL return from bio_alloc at all.
}
There is nothing that this protects against except for slightly reducing
the window when new opens can appear just before calling del_gendisk.
Signed-off-by: Christoph Hellwig
A cautious
Tested-by: Guenter Roeck
Cautious because -next is a bit broken right now and I can not run a complete
On Mon, Aug 16, 2021 at 09:21:58AM +0200, Christoph Hellwig wrote:
> On Sun, Aug 15, 2021 at 07:27:37AM -0700, Guenter Roeck wrote:
> > [ 14.467748][T1] Possible unsafe locking scenario:
> > [ 14.467748][T1]
> > [ 14.467928][T1]CPU0
On Mon, Aug 16, 2021 at 09:21:58AM +0200, Christoph Hellwig wrote:
> On Sun, Aug 15, 2021 at 07:27:37AM -0700, Guenter Roeck wrote:
> > [ 14.467748][T1] Possible unsafe locking scenario:
> > [ 14.467748][T1]
> > [ 14.467928][T1]CPU0
On 8/15/21 12:07 AM, Christoph Hellwig wrote:
On Sat, Aug 14, 2021 at 02:13:09PM -0700, Guenter Roeck wrote:
On Wed, Aug 04, 2021 at 11:41:43AM +0200, Christoph Hellwig wrote:
device mapper needs to register holders before it is ready to do I/O.
Currently it does so by registering the disk
On Wed, Aug 04, 2021 at 11:41:43AM +0200, Christoph Hellwig wrote:
> device mapper needs to register holders before it is ready to do I/O.
> Currently it does so by registering the disk early, which can leave
> the disk and queue in a weird half state where the queue is registered
> with the disk,
lock() that the thread holds. You want to
> pass GFP_NOWAIT instead of GFP_NOIO to alloc_buffer() when holding a
> mutex that can be contended by a concurrent slab shrinker (if
> count_objects didn't use a trylock, this pattern would trivially
> deadlock).
>
> Suggested-by: David Rientj
21 matches
Mail list logo
