rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a005-20200507
i386 randconfig-a004-20200507
i386 randconfig-a001-20200507
i386 randconfig
On Wed, Apr 08, 2020 at 09:00:30PM +0200, Arnd Bergmann wrote:
> The suspend/resume functions have no callers depending on
> configuration, so they must be marked __maybe_unused to
> avoid these harmless warnings:
>
> drivers/memory/tegra/tegra186.c:1578:12: error: 'tegra186_mc_resume' defined
>
On 5/5/20 3:49 PM, Thomas Gleixner wrote:
Convert #DF to IDTENTRY_DF
- Implement the C entry point with DEFINE_IDTENTRY_DF
- Emit the ASM stub with DECLARE_IDTENTRY_DF on 64bit
- Remove the ASM idtentry in 64bit
- Adjust the 32bit shim code
- Fixup the XEN/PV code
- Remove
Hi Konrad.
On Wed, May 06, 2020 at 11:09:54PM +0200, Konrad Dybcio wrote:
> changes since v3:
> - fix dt-bindings issue
>
> changes since v2:
> - fix Kconfig indentation
>
> changes since v1:
> - make `backlight_properties props` constant
> - a couple of line breaks
> - change name and
Kees Cook writes:
> On Wed, May 06, 2020 at 09:57:10AM -0500, Eric W. Biederman wrote:
>> Kees Cook writes:
>>
>> > On Tue, May 05, 2020 at 02:45:33PM -0500, Eric W. Biederman wrote:
>> >>
>> >> The current idiom for the callers is:
>> >>
>> >> flush_old_exec(bprm);
>> >>
From: Zheng Zengkai
Date: Thu, 7 May 2020 16:03:26 +0800
> Fix sparse warnings:
>
> drivers/net/phy/mdio-bcm-iproc.c:182:5: warning:
> symbol 'iproc_mdio_resume' was not declared. Should it be static?
>
> Reported-by: Hulk Robot
> Signed-off-by: Zheng Zengkai
Applied.
Hi,
On 5/7/20 12:27 PM, Andy Shevchenko wrote:
On Thu, May 7, 2020 at 4:26 PM Jeremy Linton wrote:
On 5/5/20 8:29 AM, Calvin Johnson wrote:
+ if (sscanf(cp, "ethernet-phy-id%4x.%4x",
+, ) == 2) {
+ *phy_id = ((upper & 0x) << 16) |
On Thu, May 07, 2020 at 05:28:36PM +0530, Bharat Kumar Gogada wrote:
> - Add support for Versal CPM as Root Port.
> - The Versal ACAP devices include CCIX-PCIe Module (CPM). The integrated
> block for CPM along with the integrated bridge can function
> as PCIe Root Port.
> - Bridge error and
Non functional fix, set Kb to b, to avoid any misundertanding.
Signed-off-by: Angelo Dureghello
---
drivers/w1/slaves/w1_ds2430.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/w1/slaves/w1_ds2430.c b/drivers/w1/slaves/w1_ds2430.c
index 6fb0563fb2ae..75bb8a88620b
On Wed, Mar 25, 2020 at 04:54:55PM +0800, WeiXiong Liao wrote:
> [PATCH v3]:
> 1. patch 1~10: a lot of improvements according to Kees Cook
>
>including rename module, typo, reorder, rewrite document, bugs
> and so on.
> 2. patch 11: rename funtions of
On Thu, May 07, 2020 at 02:21:52PM -0500, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced
On Tue, 14 Apr 2020 12:25:12 +0200, =?UTF-8?q?Pali=20Roh=C3=A1r?= wrote:
> Error code is stored in rp->reset_gpio and not in err variable.
>
> Signed-off-by: Pali Rohár
> ---
> drivers/pci/controller/pci-tegra.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Acked-by: Rob
On Thu, 07 May 2020 12:06:56 -0700
Joe Perches wrote:
> People describe changes as a "fix" all the time for stuff
> that isn't an actual fix for a logic defect but is instead
> an update to a particular style preference.
>
> Then the "fix" word causes the patch to be rather uselessly
> applied
rm69299.o
>
> Signed-off-by: Randy Dunlap
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> Cc: dri-de...@lists.freedesktop.org
Thanks.
Added Fixes: tag and applied to drm-misc-next.
Sam
> ---
> drivers/gpu/drm/panel/panel-visionox-rm69299.c |1 +
> 1 file changed
On Thu, May 07, 2020 at 01:53:34PM -0500, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced
Applied. Thanks!
Alex
On Thu, May 7, 2020 at 11:27 AM Chen Zhou wrote:
>
> Remove duplicate headers which are included twice.
>
> Signed-off-by: Chen Zhou
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
Ashok,
"Raj, Ashok" writes:
>
> I think i got mixed up with logical apic id and logical cpu :-(
Stuff happens.
> -0 [000] d.h.44.376659: msi_set_affinity: quirk[1]
> new vector allocated, new apic = 2 vector = 33 this apic = 0
> -0 [000] d.h.44.376684:
On Thu, May 7, 2020 at 9:35 AM ChenTao wrote:
>
> Fix the following warning:
>
> 'en' is uint32_t and can never be negative.
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/hw_hpd.c:132:10: warning:
> comparison of unsigned expression < 0 is always false [-Wtype-limits]
> if ((en <
On 5/7/2020 11:34, Divya Indi wrote:
> This patch fixes commit -
> commit 3ebd2fd0d011 ("IB/sa: Put netlink request into the request list before
> sending")'
>
> Above commit adds the query to the request list before ib_nl_snd_msg.
>
> However, if there is a delay in sending out the request
On 2020/05/07 21:29, Al Viro wrote:
> Again, resolving the descriptor more than once in course of syscall
> is almost always a serious bug;
.. and that is what Linux currently does for those three operation,
and yes, it's buggy. The generic preparation code looks up the fd,
but later in the
Applied thanks!
Alex
On Thu, May 7, 2020 at 9:35 AM Jason Yan wrote:
>
> Fix the following coccicheck warning:
>
> drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c:3216:16-22:
> Unneeded variable: "result". Return "DC_OK" on line 3229
>
> Signed-off-by: Jason Yan
> ---
>
> On Fri, May 01, 2020 at 12:06:15AM +0200, Ansuel Smith wrote:
> > It is now supported the editing of Tx De-Emphasis, Tx Swing and
> > Rx equalization params on ipq8064. Document this new optional params.
> >
> > Signed-off-by: Ansuel Smith
> > ---
> > .../devicetree/bindings/pci/qcom,pcie.txt
On Thu, May 07, 2020 at 12:49:15PM -0400, Nathaniel McCallum wrote:
> On Thu, May 7, 2020 at 1:03 AM Haitao Huang
> wrote:
> >
> > On Wed, 06 May 2020 17:14:22 -0500, Sean Christopherson
> > wrote:
> >
> > > On Wed, May 06, 2020 at 05:42:42PM -0400, Nathaniel McCallum wrote:
> > >> Tested on
On Mon, Mar 23, 2020 at 06:40:54PM +0900, Kunihiko Hayashi wrote:
> Add driver for the Socionext UniPhier Pro5 SoC endpoint controller.
> This controller is based on the DesignWare PCIe core.
>
> Signed-off-by: Kunihiko Hayashi
> ---
> MAINTAINERS | 2 +-
>
On Thu 16 Apr 11:38 PDT 2020, Rishabh Bhatnagar wrote:
$subject says that this patch makes coredump configurable, but this
patch simply moves the rproc_coredump() to its own file.
I think this is the right thing to do and should be done as verbatim as
possible (i.e. just make sure it still
On May 7, 2020 8:09:35 AM PDT, David Laight wrote:
>From: Brian Gerst
>> Sent: 07 May 2020 14:32
>...
>> I think the bug this worked around was that the compiler didn't
>detect
>> that CONST_MASK(nr) was also constant and doesn't need to be put into
>> a register. The question is does that bug
On Thu, May 7, 2020 at 5:22 AM Christian König wrote:
>
> Am 07.05.20 um 11:13 schrieb Bernard Zhao:
> > There is DEVICE_ATTR mechanism in separate attribute define.
> > So this change is to use attr array, also use
> > sysfs_create_files in init function & sysfs_remove_files in
> > fini
On May 7, 2020 6:32:24 AM PDT, Brian Gerst wrote:
>On Thu, May 7, 2020 at 3:02 AM wrote:
>>
>> On May 6, 2020 11:18:09 PM PDT, Brian Gerst
>wrote:
>> >On Tue, May 5, 2020 at 1:47 PM Nick Desaulniers
>> > wrote:
>> >>
>> >> From: Sedat Dilek
>> >>
>> >> It turns out that if your config tickles
On Thu, May 07, 2020 at 01:53:47PM -0500, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced
Hi,
On Thu, May 07, 2020 at 01:16:17PM +0800, ChenTao wrote:
> Fix the following warning:
>
> 'mode' and 'library' are u32, they are never be negative,
> DRV260X_LRA_MODE and DRV260X_LIB_EMPTY are 0x00, the comparison
> is always false.
The fact that the symbolic names resolve to 0 is just a
On May 7, 2020 4:34:22 AM PDT, Peter Zijlstra wrote:
>On Tue, May 05, 2020 at 11:07:24AM -0700, h...@zytor.com wrote:
>> On May 5, 2020 10:44:22 AM PDT, Nick Desaulniers
> wrote:
>
>> >@@ -54,7 +54,7 @@ arch_set_bit(long nr, volatile unsigned long
>*addr)
>> >if (__builtin_constant_p(nr)) {
On 07.05.2020 11:23, Xiaoliang Yang wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
Hi Allan,
Hi Vladimir,
On 06.05.2020 13:53, Vladimir Oltean wrote:
[snip]
>At the moment, the driver does not support more than 1 action. We might
>need
On Thu, May 07, 2020 at 01:05:23PM -0600, Jens Axboe wrote:
> On 5/7/20 1:01 PM, Al Viro wrote:
> > On Thu, May 07, 2020 at 08:57:25PM +0200, Max Kellermann wrote:
> >> If an operation's flag `needs_file` is set, the function
> >> io_req_set_file() calls io_file_get() to obtain a `struct file*`.
>
On Thu, May 07, 2020 at 07:50:10AM -0400, Paolo Bonzini wrote:
> diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
> index 1a547e3ac0e5..9a2a62e5afeb 100644
> --- a/arch/x86/kvm/svm/nested.c
> +++ b/arch/x86/kvm/svm/nested.c
> @@ -633,10 +633,18 @@ static int
On Wed, May 06, 2020 at 10:09:07PM +0200, Christophe JAILLET wrote:
> The call to 'tegra_bpmp_get()' must be balanced by a call to
> 'tegra_bpmp_put()' in case of error, as already done in the remove
> function.
>
> Add an error handling path and corresponding goto.
>
> Fixes: 52d15dd23f0b
On 5/7/2020 12:50 PM, Gustavo A. R. Silva wrote:
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
On Thu, 7 May 2020 at 20:33, Lenny Szubowicz wrote:
>
> In allocate_e820(), call the EFI get_memory_map() service directly
> instead of indirectly via efi_get_memory_map(). This avoids allocation
> of a buffer and return of the full EFI memory map, which is not needed
> here and would otherwise
On Thu, May 07, 2020 at 07:46:44PM +0200, Pavel Machek wrote:
> Hi!
>
> > +struct ec_input_response {
> > + u8 reserved;
> > + u8 msg_counter:2;
> > + u8 count:2;
> > + u8 type:4;
> > + u8 data[3];
> > +} __packed;
>
> Bitfields, and relying on them being in the right place for
>
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
On Wed, May 6, 2020 at 11:18 PM Brian Gerst wrote:
>
> I think a better fix would be to make CONST_MASK() return a u8 value
> rather than have to cast on every use.
>
> Also I question the need for the "q" constraint. It was added in
> commit 437a0a54 as a workaround for GCC 3.4.4. Now that the
The modem remote processor has two modes of access to the DDR, a direct
mode and through a SMMU which requires direct mapping. The configuration
of the modem SIDs is handled in TrustZone. On platforms where TrustZone
is absent this needs to be explicitly done from kernel. Add compatibles
for modem
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
On Thu, May 7, 2020 at 7:00 AM Brian Gerst wrote:
>
> This change will make sparse happy and allow these cleanups:
> #define CONST_MASK(nr) ((u8)1 << ((nr) & 7))
yep, this is more elegant, IMO. Will send a v3 later with this
change. Looking at the uses of CONST_MASK, I noticed
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
On Wed, 6 May 2020 15:38:16 -0400
Peter Xu wrote:
> If this is going to be added... I am thinking whether it should be easier to
> add another value for unprivileged_userfaultfd, rather than a new sysctl.
> E.g.:
>
> "0": unprivileged userfaultfd forbidden
> "1": unprivileged userfaultfd
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
When a command gets added to a transaction for the AP->command
channel we set the DMA address of its scatterlist entry, but not
its DMA length. Fix this bug.
Signed-off-by: Alex Elder
---
drivers/net/ipa/gsi_trans.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
One part of recovering from a modem crash is performing a "tag
sequence" of several IPA immediate commands, to clear the hardware
pipeline. The sequence ends with a data transfer request on the
command endpoint (which is not otherwise done). Unfortunately,
attempting to do the data transfer led
The first patch in this series fixes a bug where the size of a data
transfer request was never set, meaning it was 0. The consequence
of this was that such a transfer request would never complete if
attempted, and led to a hung task timeout.
This data transfer is required for cleaning up IPA
On Thu, May 07, 2020 at 01:09:51PM +0200, Thomas Bogendoerfer wrote:
> On Wed, May 06, 2020 at 08:42:29PM +0300, sergey.se...@baikalelectronics.ru
> wrote:
> > From: Serge Semin
> >
> > Indeed according to the P5600/P6000 manual the MAAR pair register
> > address field either takes [12:31] bits
On 2020/05/07 21:05, Jens Axboe wrote:
> On 5/7/20 1:01 PM, Al Viro wrote:
> > On Thu, May 07, 2020 at 08:57:25PM +0200, Max Kellermann wrote:
> >> If an operation's flag `needs_file` is set, the function
> >> io_req_set_file() calls io_file_get() to obtain a `struct file*`.
> >>
> >> This fails
On Thu, May 07, 2020 at 02:31:02PM -0400, Johannes Weiner wrote:
> On Thu, May 07, 2020 at 10:09:03AM -0700, Paul E. McKenney wrote:
> > On Thu, May 07, 2020 at 01:00:06PM -0400, Johannes Weiner wrote:
> > > On Wed, May 06, 2020 at 05:55:35PM -0700, Andrew Morton wrote:
> > > > On Wed, 6 May 2020
On Thu, 2020-05-07 at 14:45 -0400, Steven Rostedt wrote:
> On Thu, 07 May 2020 10:55:33 -0700
> Joe Perches wrote:
>
> > > If anything, we can teach people to try to understand their fixes, to see
> > > if something is really a fix or not. Blindly accepting changes like this,
> > > is no
> This patch fixes commit -
> commit 3ebd2fd0d011 ("IB/sa: Put netlink request into the request list
> before sending")'
>
> Above commit adds the query to the request list before ib_nl_snd_msg.
>
> However, if there is a delay in sending out the request (For
> eg: Delay due to low memory
On 5/7/20 1:01 PM, Al Viro wrote:
> On Thu, May 07, 2020 at 08:57:25PM +0200, Max Kellermann wrote:
>> If an operation's flag `needs_file` is set, the function
>> io_req_set_file() calls io_file_get() to obtain a `struct file*`.
>>
>> This fails for `O_PATH` file descriptors, because those have no
On 2020/05/07 21:01, Al Viro wrote:
> On Thu, May 07, 2020 at 08:57:25PM +0200, Max Kellermann wrote:
> > If an operation's flag `needs_file` is set, the function
> > io_req_set_file() calls io_file_get() to obtain a `struct file*`.
> >
> > This fails for `O_PATH` file descriptors, because those
On 5/7/20 12:56 PM, Gustavo A. R. Silva wrote:
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
On Thu, May 07, 2020 at 08:57:25PM +0200, Max Kellermann wrote:
> If an operation's flag `needs_file` is set, the function
> io_req_set_file() calls io_file_get() to obtain a `struct file*`.
>
> This fails for `O_PATH` file descriptors, because those have no
> `struct file*`
O_PATH descriptors
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
On 2020/05/07 20:58, Jens Axboe wrote:
> Do you happen to have a liburing test addition for this as well?
No, I'll write one tomorrow. GitHub PR or email preferred?
Max
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
501 - 600 of 1840 matches
Mail list logo
