-Wbitwise-conditional-parentheses in kernel/resource.c #1159
Assignees
Labels
-Wbitwise-conditional-parentheses
[BUG] linux-next
This is an issue only seen in linux-next
[FIXED][LINUX] development cycle
This bug was only present and fixed in a -next or -rc cycle
Comments
nathanchance
added
[PATCH] Submitted
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Sep 23, 2020
…djustable
Clang warns:
kernel/resource.c:1281:53: warning: operator '?:' has lower precedence
than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '|'
expression to silence this warning
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '?:'
expression to evaluate it first
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
^
( )
1 warning generated.
Add the parentheses as it was clearly intended for the ternary condition
to be evaluated first.
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 5fd23bd ("kernel/resource: make release_mem_region_adjustable() never fail")
Link: ClangBuiltLinux#1159
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Stephen Rothwell <[email protected]>
|
Fixed (SHA won't be stable): https://git.kernel.org/next/linux-next/c/231fa8fb1ac8294dd1f89dce96ad3f2370223113 |
nathanchance
added
[FIXED][LINUX] development cycle
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Sep 25, 2020
…djustable
Clang warns:
kernel/resource.c:1281:53: warning: operator '?:' has lower precedence
than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '|'
expression to silence this warning
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '?:'
expression to evaluate it first
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
^
( )
1 warning generated.
Add the parentheses as it was clearly intended for the ternary condition
to be evaluated first.
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 5fd23bd ("kernel/resource: make release_mem_region_adjustable() never fail")
Link: ClangBuiltLinux#1159
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Stephen Rothwell <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Sep 28, 2020
…djustable
Clang warns:
kernel/resource.c:1281:53: warning: operator '?:' has lower precedence
than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '|'
expression to silence this warning
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '?:'
expression to evaluate it first
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
^
( )
1 warning generated.
Add the parentheses as it was clearly intended for the ternary condition
to be evaluated first.
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 5fd23bd ("kernel/resource: make release_mem_region_adjustable() never fail")
Link: ClangBuiltLinux#1159
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Stephen Rothwell <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Sep 30, 2020
…djustable
Clang warns:
kernel/resource.c:1281:53: warning: operator '?:' has lower precedence
than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '|'
expression to silence this warning
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '?:'
expression to evaluate it first
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
^
( )
1 warning generated.
Add the parentheses as it was clearly intended for the ternary condition
to be evaluated first.
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 5fd23bd ("kernel/resource: make release_mem_region_adjustable() never fail")
Link: ClangBuiltLinux#1159
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Stephen Rothwell <[email protected]>
x-y-z
pushed a commit
to x-y-z/linux-1gb-thp
that referenced
this issue
Sep 30, 2020
…djustable
Clang warns:
kernel/resource.c:1281:53: warning: operator '?:' has lower precedence
than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '|'
expression to silence this warning
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '?:'
expression to evaluate it first
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
^
( )
1 warning generated.
Add the parentheses as it was clearly intended for the ternary condition
to be evaluated first.
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 5fd23bd0d739 ("kernel/resource: make release_mem_region_adjustable() never fail")
Link: ClangBuiltLinux/linux#1159
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
x-y-z
pushed a commit
to x-y-z/linux-1gb-thp
that referenced
this issue
Sep 30, 2020
…djustable
Clang warns:
kernel/resource.c:1281:53: warning: operator '?:' has lower precedence
than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '|'
expression to silence this warning
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '?:'
expression to evaluate it first
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
^
( )
1 warning generated.
Add the parentheses as it was clearly intended for the ternary condition
to be evaluated first.
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 5fd23bd0d739 ("kernel/resource: make release_mem_region_adjustable() never fail")
Link: ClangBuiltLinux/linux#1159
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Oct 1, 2020
…djustable
Clang warns:
kernel/resource.c:1281:53: warning: operator '?:' has lower precedence
than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '|'
expression to silence this warning
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '?:'
expression to evaluate it first
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
^
( )
1 warning generated.
Add the parentheses as it was clearly intended for the ternary condition
to be evaluated first.
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 5fd23bd ("kernel/resource: make release_mem_region_adjustable() never fail")
Link: ClangBuiltLinux#1159
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Stephen Rothwell <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Oct 6, 2020
…djustable
Clang warns:
kernel/resource.c:1281:53: warning: operator '?:' has lower precedence
than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '|'
expression to silence this warning
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '?:'
expression to evaluate it first
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
^
( )
1 warning generated.
Add the parentheses as it was clearly intended for the ternary condition
to be evaluated first.
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 5fd23bd ("kernel/resource: make release_mem_region_adjustable() never fail")
Link: ClangBuiltLinux#1159
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Stephen Rothwell <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Oct 7, 2020
…djustable
Clang warns:
kernel/resource.c:1281:53: warning: operator '?:' has lower precedence
than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '|'
expression to silence this warning
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '?:'
expression to evaluate it first
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
^
( )
1 warning generated.
Add the parentheses as it was clearly intended for the ternary condition
to be evaluated first.
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 5fd23bd ("kernel/resource: make release_mem_region_adjustable() never fail")
Link: ClangBuiltLinux#1159
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Stephen Rothwell <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Oct 8, 2020
…djustable
Clang warns:
kernel/resource.c:1281:53: warning: operator '?:' has lower precedence
than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '|'
expression to silence this warning
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '?:'
expression to evaluate it first
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
^
( )
1 warning generated.
Add the parentheses as it was clearly intended for the ternary condition
to be evaluated first.
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 5fd23bd ("kernel/resource: make release_mem_region_adjustable() never fail")
Link: ClangBuiltLinux#1159
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Stephen Rothwell <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Oct 12, 2020
…djustable
Clang warns:
kernel/resource.c:1281:53: warning: operator '?:' has lower precedence
than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '|'
expression to silence this warning
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '?:'
expression to evaluate it first
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
^
( )
1 warning generated.
Add the parentheses as it was clearly intended for the ternary condition
to be evaluated first.
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 5fd23bd ("kernel/resource: make release_mem_region_adjustable() never fail")
Link: ClangBuiltLinux#1159
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Stephen Rothwell <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Oct 15, 2020
…djustable
Clang warns:
kernel/resource.c:1281:53: warning: operator '?:' has lower precedence
than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '|'
expression to silence this warning
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
~~~~~~~~~~~~~~~~~~~~~~~~~ ^
kernel/resource.c:1281:53: note: place parentheses around the '?:'
expression to evaluate it first
new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
^
( )
1 warning generated.
Add the parentheses as it was clearly intended for the ternary condition
to be evaluated first.
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 5fd23bd ("kernel/resource: make release_mem_region_adjustable() never fail")
Link: ClangBuiltLinux#1159
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Stephen Rothwell <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Oct 16, 2020
Patch series "selective merging of system ram resources", v4. Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where possible. Resources are effectively stored in a list-based tree. Having a lot of resources not only wastes memory, it also makes traversing that tree more expensive, and makes /proc/iomem explode in size (e.g., requiring kexec-tools to manually merge resources when creating a kdump header. The current kexec-tools resource count limit does not allow for more than ~100GB of memory with a memory block size of 128MB on x86-64). Let's allow to selectively merge system ram resources by specifying a new flag for add_memory*(). Patch #5 contains a /proc/iomem example. Only tested with virtio-mem. This patch (of 8): Let's make sure splitting a resource on memory hotunplug will never fail. This will become more relevant once we merge selected System RAM resources - then, we'll trigger that case more often on memory hotunplug. In general, this function is already unlikely to fail. When we remove memory, we free up quite a lot of metadata (memmap, page tables, memory block device, etc.). The only reason it could really fail would be when injecting allocation errors. All other error cases inside release_mem_region_adjustable() seem to be sanity checks if the function would be abused in different context - let's add WARN_ON_ONCE() in these cases so we can catch them. [[email protected]: fix use of ternary condition in release_mem_region_adjustable] Link: https://lkml.kernel.org/r/[email protected] Link: ClangBuiltLinux#1159 Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: David Hildenbrand <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Dan Williams <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Kees Cook <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Pankaj Gupta <[email protected]> Cc: Baoquan He <[email protected]> Cc: Wei Yang <[email protected]> Cc: Anton Blanchard <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Cc: Boris Ostrovsky <[email protected]> Cc: Christian Borntraeger <[email protected]> Cc: Dave Jiang <[email protected]> Cc: Eric Biederman <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Haiyang Zhang <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Jason Wang <[email protected]> Cc: Juergen Gross <[email protected]> Cc: Julien Grall <[email protected]> Cc: "K. Y. Srinivasan" <[email protected]> Cc: Len Brown <[email protected]> Cc: Leonardo Bras <[email protected]> Cc: Libor Pechacek <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: "Michael S. Tsirkin" <[email protected]> Cc: Nathan Lynch <[email protected]> Cc: "Oliver O'Halloran" <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Pingfan Liu <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Roger Pau Monn <[email protected]> Cc: Stefano Stabellini <[email protected]> Cc: Stephen Hemminger <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vasily Gorbik <[email protected]> Cc: Vishal Verma <[email protected]> Cc: Wei Liu <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
torvalds
pushed a commit
to torvalds/linux
that referenced
this issue
Oct 16, 2020
Patch series "selective merging of system ram resources", v4. Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where possible. Resources are effectively stored in a list-based tree. Having a lot of resources not only wastes memory, it also makes traversing that tree more expensive, and makes /proc/iomem explode in size (e.g., requiring kexec-tools to manually merge resources when creating a kdump header. The current kexec-tools resource count limit does not allow for more than ~100GB of memory with a memory block size of 128MB on x86-64). Let's allow to selectively merge system ram resources by specifying a new flag for add_memory*(). Patch #5 contains a /proc/iomem example. Only tested with virtio-mem. This patch (of 8): Let's make sure splitting a resource on memory hotunplug will never fail. This will become more relevant once we merge selected System RAM resources - then, we'll trigger that case more often on memory hotunplug. In general, this function is already unlikely to fail. When we remove memory, we free up quite a lot of metadata (memmap, page tables, memory block device, etc.). The only reason it could really fail would be when injecting allocation errors. All other error cases inside release_mem_region_adjustable() seem to be sanity checks if the function would be abused in different context - let's add WARN_ON_ONCE() in these cases so we can catch them. [[email protected]: fix use of ternary condition in release_mem_region_adjustable] Link: https://lkml.kernel.org/r/[email protected] Link: ClangBuiltLinux#1159 Signed-off-by: David Hildenbrand <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Dan Williams <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Kees Cook <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Pankaj Gupta <[email protected]> Cc: Baoquan He <[email protected]> Cc: Wei Yang <[email protected]> Cc: Anton Blanchard <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Cc: Boris Ostrovsky <[email protected]> Cc: Christian Borntraeger <[email protected]> Cc: Dave Jiang <[email protected]> Cc: Eric Biederman <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Haiyang Zhang <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Jason Wang <[email protected]> Cc: Juergen Gross <[email protected]> Cc: Julien Grall <[email protected]> Cc: "K. Y. Srinivasan" <[email protected]> Cc: Len Brown <[email protected]> Cc: Leonardo Bras <[email protected]> Cc: Libor Pechacek <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: "Michael S. Tsirkin" <[email protected]> Cc: Nathan Lynch <[email protected]> Cc: "Oliver O'Halloran" <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Pingfan Liu <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Roger Pau Monn <[email protected]> Cc: Stefano Stabellini <[email protected]> Cc: Stephen Hemminger <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vasily Gorbik <[email protected]> Cc: Vishal Verma <[email protected]> Cc: Wei Liu <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Patch submitted: https://lore.kernel.org/r/[email protected]
The text was updated successfully, but these errors were encountered: