2015-11-29 18:33 GMT-03:00 Paul Mackerras :
> On Sun, Nov 29, 2015 at 05:14:03PM -0300, Geyslan Gregório Bem wrote:
>> Hello,
>>
>> I have found a possible out of bounds reading in
>> arch/powerpc/kvm/book3s_64_mmu.c (kvmppc_mmu_book3s_64_xlate
>> function). pte
Hello,
I have found a possible out of bounds reading in
arch/powerpc/kvm/book3s_64_mmu.c (kvmppc_mmu_book3s_64_xlate
function). pteg[] array could be accessed twice using the i variable
after the for iteration. What happens is that in the last iteration
the i index is incremented to 16, checked
Hello,
I'm doing some static analysis and stumbled in this function
static void bitvector_process(struct seq_file *m, u64 vector)
{
int i,j;
static const char *units[]={ "", "K", "M", "G", "T" };
for (i=0, j=0; i < 64; i++ , j=i/10) {
if (vector & 0x1)
Hello,
I have found a possible out of bounds reading in
arch/powerpc/kvm/book3s_64_mmu.c (kvmppc_mmu_book3s_64_xlate
function). pteg[] array could be accessed twice using the i variable
after the for iteration. What happens is that in the last iteration
the i index is incremented to 16, checked
2015-11-29 18:33 GMT-03:00 Paul Mackerras <pau...@ozlabs.org>:
> On Sun, Nov 29, 2015 at 05:14:03PM -0300, Geyslan Gregório Bem wrote:
>> Hello,
>>
>> I have found a possible out of bounds reading in
>> arch/powerpc/kvm/book3s_64_mmu.c (kvmppc_mmu_book3s_64_xlate
Hello,
I'm doing some static analysis and stumbled in this function
static void bitvector_process(struct seq_file *m, u64 vector)
{
int i,j;
static const char *units[]={ "", "K", "M", "G", "T" };
for (i=0, j=0; i < 64; i++ , j=i/10) {
if (vector & 0x1)
Valdis,
2014-04-19 15:33 GMT-03:00 :
> On Sat, 19 Apr 2014 13:37:27 -0300, Geyslan Gregório Bem said:
>
>> Maintainers, is there some chance to fix it or a.out is really doomed?
>
> Is there an actual use case for a.out on a modern kernel?
Maybe retrocompatibility.
Pavel,
Thank you.
Maintainers, is there some chance to fix it or a.out is really doomed?
2014-04-19 13:15 GMT-03:00 Pavel Machek :
> Hi!
>
>> I was researching about old binary formats and did some tests.
>> Meantime, I was able to run sucessfully only the QMAGIC format.
>> Nonetheless, the
Pavel,
Thank you.
Maintainers, is there some chance to fix it or a.out is really doomed?
2014-04-19 13:15 GMT-03:00 Pavel Machek pa...@ucw.cz:
Hi!
I was researching about old binary formats and did some tests.
Meantime, I was able to run sucessfully only the QMAGIC format.
Nonetheless,
Valdis,
2014-04-19 15:33 GMT-03:00 valdis.kletni...@vt.edu:
On Sat, 19 Apr 2014 13:37:27 -0300, Geyslan Gregório Bem said:
Maintainers, is there some chance to fix it or a.out is really doomed?
Is there an actual use case for a.out on a modern kernel?
Maybe retrocompatibility.
In other
Sirs,
I was researching about old binary formats and did some tests.
Meantime, I was able to run sucessfully only the QMAGIC format.
Nonetheless, the OMAGIC, NMAGIC and ZMAGIC didn't work anymore.
The test occurred using old slackware binaries and some new, the
latter compiled by me, using
Sirs,
I was researching about old binary formats and did some tests.
Meantime, I was able to run sucessfully only the QMAGIC format.
Nonetheless, the OMAGIC, NMAGIC and ZMAGIC didn't work anymore.
The test occurred using old slackware binaries and some new, the
latter compiled by me, using
2013/11/22 Phillip Lougher :
> On 22/11/13 21:50, Geyslan Gregório Bem wrote:
>>
>> Coverity caught double free possibility (CID 1130962).
>>
>> I can patch this, but I have to know if is correct to free comp_opts
>> in the function squashfs_decompres
2013/11/22 Richard Weinberger :
> On Fri, Nov 22, 2013 at 10:50 PM, Geyslan Gregório Bem
> wrote:
>> Coverity caught double free possibility (CID 1130962).
>
> Just wondering, where can one find/verify such CIDs?
>
> --
> Thanks,
> //richard
Anyone can sign
Coverity caught double free possibility (CID 1130962).
I can patch this, but I have to know if is correct to free comp_opts
in the function squashfs_decompressor_create() or it had to be done in
the caller. My bet is the caller.
128void *squashfs_decompressor_setup(struct super_block *sb,
2013/11/21 Geyslan Gregório Bem :
> 2013/11/20 Al Viro :
>> On Wed, Nov 20, 2013 at 09:34:31PM -0300, Geyslan G. Bem wrote:
>>> The member 'e_ehsize' that holds the ELF header size is compared
>>> with the elfhdr struct size. If not equal, goes out.
>>>
2013/11/21 Geyslan Gregório Bem geys...@gmail.com:
2013/11/20 Al Viro v...@zeniv.linux.org.uk:
On Wed, Nov 20, 2013 at 09:34:31PM -0300, Geyslan G. Bem wrote:
The member 'e_ehsize' that holds the ELF header size is compared
with the elfhdr struct size. If not equal, goes out.
If 'e_phoff
Coverity caught double free possibility (CID 1130962).
I can patch this, but I have to know if is correct to free comp_opts
in the function squashfs_decompressor_create() or it had to be done in
the caller. My bet is the caller.
128void *squashfs_decompressor_setup(struct super_block *sb,
2013/11/22 Richard Weinberger richard.weinber...@gmail.com:
On Fri, Nov 22, 2013 at 10:50 PM, Geyslan Gregório Bem
geys...@gmail.com wrote:
Coverity caught double free possibility (CID 1130962).
Just wondering, where can one find/verify such CIDs?
--
Thanks,
//richard
Anyone can sign
2013/11/22 Phillip Lougher phil...@lougher.demon.co.uk:
On 22/11/13 21:50, Geyslan Gregório Bem wrote:
Coverity caught double free possibility (CID 1130962).
I can patch this, but I have to know if is correct to free comp_opts
in the function squashfs_decompressor_create() or it had
2013/11/20 Al Viro :
> On Wed, Nov 20, 2013 at 09:34:31PM -0300, Geyslan G. Bem wrote:
>> The member 'e_ehsize' that holds the ELF header size is compared
>> with the elfhdr struct size. If not equal, goes out.
>> If 'e_phoff' holds 0 the object has no program header table, so
>> goes out.
>>
2013/11/20 Al Viro v...@zeniv.linux.org.uk:
On Wed, Nov 20, 2013 at 09:34:31PM -0300, Geyslan G. Bem wrote:
The member 'e_ehsize' that holds the ELF header size is compared
with the elfhdr struct size. If not equal, goes out.
If 'e_phoff' holds 0 the object has no program header table, so
2013/11/20 Geyslan G. Bem :
> The member 'e_ehsize' that holds the ELF header size is compared
> with the elfhdr struct size. If not equal, goes out.
> If 'e_phoff' holds 0 the object has no program header table, so
> goes out.
>
> Increasing the binary consistency reduces the use of malformed
2013/11/20 Geyslan G. Bem geys...@gmail.com:
The member 'e_ehsize' that holds the ELF header size is compared
with the elfhdr struct size. If not equal, goes out.
If 'e_phoff' holds 0 the object has no program header table, so
goes out.
Increasing the binary consistency reduces the use of
This patch add the specification "System V Application Binary Interface"
reference to header comment.
Signed-off-by: Geyslan G. Bem
---
fs/binfmt_elf.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 571a423..18938f9 100644
---
This patch add the specification System V Application Binary Interface
reference to header comment.
Signed-off-by: Geyslan G. Bem geys...@gmail.com
---
fs/binfmt_elf.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index
2013/11/18 Geyslan Gregório Bem :
> 2013/11/18 James Bottomley :
>> On Mon, 2013-11-18 at 14:18 -0200, Geyslan Gregório Bem wrote:
>>> 2013/11/18 James Bottomley :
>>> > On Sun, 2013-11-17 at 23:12 -0200, Geyslan Gregório Bem wrote:
>>> >> 2013/11/17
2013/11/18 James Bottomley :
> On Mon, 2013-11-18 at 14:18 -0200, Geyslan Gregório Bem wrote:
>> 2013/11/18 James Bottomley :
>> > On Sun, 2013-11-17 at 23:12 -0200, Geyslan Gregório Bem wrote:
>> >> 2013/11/17 James Bottomley :
>> >> > On Sun, 2013-11-
2013/11/18 James Bottomley :
> On Sun, 2013-11-17 at 23:12 -0200, Geyslan Gregório Bem wrote:
>> 2013/11/17 James Bottomley :
>> > On Sun, 2013-11-17 at 19:09 -0200, Geyslan Gregório Bem wrote:
>> >> 2013/11/17 James Bottomley :
>> >> > On Sun, 20
2013/11/18 Caizhiyong :
> From: Cai Zhiyong
> Date: Mon, 18 Nov 2013 20:21:49 +0800
> Subject: [PATCH] regmap: Fix 'ret' would return an uninitialized value
>
> This patch give a warning when calling regmap_register_patch with
> parameter num_regs <= 0.
>
> When the num_regs parameter is zero and
2013/11/18 Caizhiyong caizhiy...@hisilicon.com:
From: Cai Zhiyong caizhiy...@huawei.com
Date: Mon, 18 Nov 2013 20:21:49 +0800
Subject: [PATCH] regmap: Fix 'ret' would return an uninitialized value
This patch give a warning when calling regmap_register_patch with
parameter num_regs = 0.
2013/11/18 James Bottomley james.bottom...@hansenpartnership.com:
On Sun, 2013-11-17 at 23:12 -0200, Geyslan Gregório Bem wrote:
2013/11/17 James Bottomley james.bottom...@hansenpartnership.com:
On Sun, 2013-11-17 at 19:09 -0200, Geyslan Gregório Bem wrote:
2013/11/17 James Bottomley
2013/11/18 James Bottomley james.bottom...@hansenpartnership.com:
On Mon, 2013-11-18 at 14:18 -0200, Geyslan Gregório Bem wrote:
2013/11/18 James Bottomley james.bottom...@hansenpartnership.com:
On Sun, 2013-11-17 at 23:12 -0200, Geyslan Gregório Bem wrote:
2013/11/17 James Bottomley
2013/11/18 Geyslan Gregório Bem geys...@gmail.com:
2013/11/18 James Bottomley james.bottom...@hansenpartnership.com:
On Mon, 2013-11-18 at 14:18 -0200, Geyslan Gregório Bem wrote:
2013/11/18 James Bottomley james.bottom...@hansenpartnership.com:
On Sun, 2013-11-17 at 23:12 -0200, Geyslan
2013/11/17 James Bottomley :
> On Sun, 2013-11-17 at 19:09 -0200, Geyslan Gregório Bem wrote:
>> 2013/11/17 James Bottomley :
>> > On Sun, 2013-11-17 at 15:51 -0300, Geyslan G. Bem wrote:
>> >> This patch fix memory leakage in
2013/11/17 James Bottomley :
> On Sun, 2013-11-17 at 15:51 -0300, Geyslan G. Bem wrote:
>> This patch fix memory leakage in cases 'ISCSI_NET_PARAM_VLAN_ID' and
>> 'ISCSI_NET_PARAM_VLAN_PRIORITY' and refactors code 'going out' when
>> necessary.
>
> You pointlessly renamed a variable, which makes
Hello Benjamin,
In file 'windfarm_pm121'.c:
If this branch is true:
if (param == NULL) {
printk(KERN_WARNING "pm121: %s fan config not found "
" for this machine model\n",
loop_names[loop_id]);
goto fail;
}
control that is NULL will suffer
Hello Benjamin,
In file 'windfarm_pm121'.c:
If this branch is true:
if (param == NULL) {
printk(KERN_WARNING pm121: %s fan config not found
for this machine model\n,
loop_names[loop_id]);
goto fail;
}
control that is NULL will suffer a
2013/11/17 James Bottomley james.bottom...@hansenpartnership.com:
On Sun, 2013-11-17 at 15:51 -0300, Geyslan G. Bem wrote:
This patch fix memory leakage in cases 'ISCSI_NET_PARAM_VLAN_ID' and
'ISCSI_NET_PARAM_VLAN_PRIORITY' and refactors code 'going out' when
necessary.
You pointlessly
2013/11/17 James Bottomley james.bottom...@hansenpartnership.com:
On Sun, 2013-11-17 at 19:09 -0200, Geyslan Gregório Bem wrote:
2013/11/17 James Bottomley james.bottom...@hansenpartnership.com:
On Sun, 2013-11-17 at 15:51 -0300, Geyslan G. Bem wrote:
This patch fix memory leakage in cases
Hi guys,
In the function msgin_qtag() [line 2632], this dereference was intentional?
static struct ScsiReqBlk *msgin_qtag(struct AdapterCtlBlk *acb,
struct DeviceCtlBlk *dcb, u8 tag)
{
struct ScsiReqBlk *srb = NULL;
struct ScsiReqBlk *i;
dprintkdbg(DBG_0, "msgin_qtag: (0x%p)
2013/11/15 Mark Brown :
> On Fri, Nov 15, 2013 at 01:52:19PM -0200, Geyslan Gregório Bem wrote:
>
>> + if (WARN_ONCE(num_regs <= 0, "number of registers [%d] must be
>> major than 0", num_regs))
>> + return 0;
>
> "must be more th
2013/11/15 Levente Kurusa :
> 2013-11-15 14:00 keltezéssel, Geyslan Gregório Bem írta:
>> 2013/11/15 Caizhiyong :
>>> From: Cai Zhiyong
>>> Date: Mon, 11 Nov 2013 19:26:14 +0800
>>> Subject: [PATCH] regmap: Fix 'ret' would return an uninitialized value
&g
2013/11/15 Caizhiyong :
> From: Cai Zhiyong
> Date: Mon, 11 Nov 2013 19:26:14 +0800
> Subject: [PATCH] regmap: Fix 'ret' would return an uninitialized value
>
> This patch give a warning when calling regmap_register_patch with
> parameter num_regs <= 0.
>
> When the num_regs parameter is zero and
2013/11/15 Caizhiyong caizhiy...@hisilicon.com:
From: Cai Zhiyong caizhiy...@huawei.com
Date: Mon, 11 Nov 2013 19:26:14 +0800
Subject: [PATCH] regmap: Fix 'ret' would return an uninitialized value
This patch give a warning when calling regmap_register_patch with
parameter num_regs = 0.
2013/11/15 Levente Kurusa le...@linux.com:
2013-11-15 14:00 keltezéssel, Geyslan Gregório Bem írta:
2013/11/15 Caizhiyong caizhiy...@hisilicon.com:
From: Cai Zhiyong caizhiy...@huawei.com
Date: Mon, 11 Nov 2013 19:26:14 +0800
Subject: [PATCH] regmap: Fix 'ret' would return an uninitialized
2013/11/15 Mark Brown broo...@kernel.org:
On Fri, Nov 15, 2013 at 01:52:19PM -0200, Geyslan Gregório Bem wrote:
+ if (WARN_ONCE(num_regs = 0, number of registers [%d] must be
major than 0, num_regs))
+ return 0;
must be more than but yes.
Tks. Sorry for my poor english
Hi guys,
In the function msgin_qtag() [line 2632], this dereference was intentional?
static struct ScsiReqBlk *msgin_qtag(struct AdapterCtlBlk *acb,
struct DeviceCtlBlk *dcb, u8 tag)
{
struct ScsiReqBlk *srb = NULL;
struct ScsiReqBlk *i;
dprintkdbg(DBG_0, msgin_qtag: (0x%p)
2013/11/14 Geyslan G. Bem :
> If 'hsr_get_node_data()' returns error, going directly to 'fail' label
> doesn't free the memory pointed by 'skb_out'.
>
> Signed-off-by: Geyslan G. Bem
> ---
> net/hsr/hsr_netlink.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
2013/11/14 Tyler Hicks :
> On 2013-11-14 17:58:40, Geyslan Gregório Bem wrote:
>> 2013/11/14 Tyler Hicks :
>> > On 2013-11-14 15:42:14, Geyslan G. Bem wrote:
>> >> If the condition 'ecryptfs_file_to_private(file)' takes false branch
>> >> lower_file is
2013/11/14 Tyler Hicks :
> On 2013-11-14 15:42:14, Geyslan G. Bem wrote:
>> If the condition 'ecryptfs_file_to_private(file)' takes false branch
>> lower_file is dereferenced when NULL.
>>
>> Caught by Coverity: CIDs 1128834 and 1128833.
>>
>> Signed-off-by: Geyslan G. Bem
>> ---
>
> Hello -
2013/11/14 Tyler Hicks tyhi...@canonical.com:
On 2013-11-14 15:42:14, Geyslan G. Bem wrote:
If the condition 'ecryptfs_file_to_private(file)' takes false branch
lower_file is dereferenced when NULL.
Caught by Coverity: CIDs 1128834 and 1128833.
Signed-off-by: Geyslan G. Bem
2013/11/14 Tyler Hicks tyhi...@canonical.com:
On 2013-11-14 17:58:40, Geyslan Gregório Bem wrote:
2013/11/14 Tyler Hicks tyhi...@canonical.com:
On 2013-11-14 15:42:14, Geyslan G. Bem wrote:
If the condition 'ecryptfs_file_to_private(file)' takes false branch
lower_file is dereferenced when
2013/11/14 Geyslan G. Bem geys...@gmail.com:
If 'hsr_get_node_data()' returns error, going directly to 'fail' label
doesn't free the memory pointed by 'skb_out'.
Signed-off-by: Geyslan G. Bem geys...@gmail.com
---
net/hsr/hsr_netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
2013/11/12 Steven Whitehouse :
> Hi,
>
> On Tue, 2013-11-12 at 12:53 -0200, Geyslan Gregório Bem wrote:
>> Hello,
>>
>> Coverity detected in 'fs/gfs2/glock.c' a possible dereference after
>> null check. Maybe a positive one.
>>
>> There is a initial
Hello,
Coverity detected in 'fs/gfs2/glock.c' a possible dereference after
null check. Maybe a positive one.
There is a initial check for possible 'gl' NULL. After that 'gl' is
dereferenced in the looping check by __lockref_is_dead().
What do you think?
1875static int
2013/11/12 Peter Zijlstra :
> On Tue, Nov 12, 2013 at 12:19:13PM -0200, Geyslan Gregório Bem wrote:
>
> Cc: kernel...@googlegroups.com
>
> Don't cross-post to lists that don't allow public posts, and very much
> don't cross-post to lists that bounce in incomprehensible gibberish
2013/11/12 Måns Rullgård :
> Geyslan Gregório Bem writes:
>
>> Hi,
>>
>> Coverity detected in 'arch/x86/kernel/cpu/perf_event_intel_uncore.c' a
>> possible reliance on integer endianness. Is that a positive one?
>
> No, x86 is always little endian.
>
&g
Hi,
Coverity detected in 'arch/x86/kernel/cpu/perf_event_intel_uncore.c' a
possible reliance on integer endianness. Is that a positive one?
static u64 ivt_uncore_irp_read_counter(struct intel_uncore_box *box,
struct perf_event *event)
1369{
1370struct pci_dev *pdev = box->pci_dev;
1371
Hi,
Coverity detected in 'arch/x86/kernel/cpu/perf_event_intel_uncore.c' a
possible reliance on integer endianness. Is that a positive one?
static u64 ivt_uncore_irp_read_counter(struct intel_uncore_box *box,
struct perf_event *event)
1369{
1370struct pci_dev *pdev = box-pci_dev;
1371
2013/11/12 Måns Rullgård m...@mansr.com:
Geyslan Gregório Bem geys...@gmail.com writes:
Hi,
Coverity detected in 'arch/x86/kernel/cpu/perf_event_intel_uncore.c' a
possible reliance on integer endianness. Is that a positive one?
No, x86 is always little endian.
static u64
2013/11/12 Peter Zijlstra pet...@infradead.org:
On Tue, Nov 12, 2013 at 12:19:13PM -0200, Geyslan Gregório Bem wrote:
Cc: kernel...@googlegroups.com
Don't cross-post to lists that don't allow public posts, and very much
don't cross-post to lists that bounce in incomprehensible gibberish
Hello,
Coverity detected in 'fs/gfs2/glock.c' a possible dereference after
null check. Maybe a positive one.
There is a initial check for possible 'gl' NULL. After that 'gl' is
dereferenced in the looping check by __lockref_is_dead().
What do you think?
1875static int
2013/11/12 Steven Whitehouse swhit...@redhat.com:
Hi,
On Tue, 2013-11-12 at 12:53 -0200, Geyslan Gregório Bem wrote:
Hello,
Coverity detected in 'fs/gfs2/glock.c' a possible dereference after
null check. Maybe a positive one.
There is a initial check for possible 'gl' NULL. After that 'gl
2013/11/6 Steven Rostedt :
> On Wed, 6 Nov 2013 16:02:51 -0300
> "Geyslan G. Bem" wrote:
>
>> In 'system_tr_open()':
>> Fix possible 'dir' assignment after freeing it.
>
> I'll take this patch, but I'm going to reword the subject and the
> change log. The assignment of dir to filp->private_data
2013/11/6 Steven Rostedt :
> Sorry for the late review, I was busy getting ready for kernel summit
> and then traveling too much.
>
No problem.
>
> On Fri, 18 Oct 2013 17:59:42 -0300
> "Geyslan G. Bem" wrote:
>
>> In 'system_tr_open()':
>> Fix possible 'dir' assignment after freeing it.
>>
>> In
2013/11/6 Steven Rostedt rost...@goodmis.org:
Sorry for the late review, I was busy getting ready for kernel summit
and then traveling too much.
No problem.
On Fri, 18 Oct 2013 17:59:42 -0300
Geyslan G. Bem geys...@gmail.com wrote:
In 'system_tr_open()':
Fix possible 'dir' assignment
2013/11/6 Steven Rostedt rost...@goodmis.org:
On Wed, 6 Nov 2013 16:02:51 -0300
Geyslan G. Bem geys...@gmail.com wrote:
In 'system_tr_open()':
Fix possible 'dir' assignment after freeing it.
I'll take this patch, but I'm going to reword the subject and the
change log. The assignment of
2013/10/31 Ben Myers :
> Hey Geyslan,
>
> On Wed, Oct 30, 2013 at 03:08:12PM -0500, Eric Sandeen wrote:
>> On 10/23/13 3:34 PM, Ben Myers wrote:
>>
>> > xfs: fix possible NULL dereference in xlog_verify_iclog
>> >
>> > In xlog_verify_iclog a debug check of the incore log buffers prints an
>> >
2013/10/31 Ben Myers b...@sgi.com:
Hey Geyslan,
On Wed, Oct 30, 2013 at 03:08:12PM -0500, Eric Sandeen wrote:
On 10/23/13 3:34 PM, Ben Myers wrote:
xfs: fix possible NULL dereference in xlog_verify_iclog
In xlog_verify_iclog a debug check of the incore log buffers prints an
error if
2013/10/30 Matt Fleming :
> On Wed, 30 Oct, at 10:44:16AM, Geyslan Gregório Bem wrote:
>> Do you want that I undo that? I aggre that the variable use only
>> reduces the line code.
>
> Yes please.
>
> --
> Matt Fleming, Intel Open Source Technology Cen
2013/10/30 Matt Fleming :
> On Mon, 14 Oct, at 03:37:17PM, Geyslan G. Bem wrote:
>> This reorganization:
>>
>> Adds 'attrsize' variable to make the code cleaner and more
>> understandable, replacing all 'sizeof(attributes)'.
>>
>> Removes 'bytes' prior assignment due this new approach.
>>
>> Uses
2013/10/30 Matt Fleming m...@console-pimps.org:
On Mon, 14 Oct, at 03:37:17PM, Geyslan G. Bem wrote:
This reorganization:
Adds 'attrsize' variable to make the code cleaner and more
understandable, replacing all 'sizeof(attributes)'.
Removes 'bytes' prior assignment due this new approach.
2013/10/30 Matt Fleming m...@console-pimps.org:
On Wed, 30 Oct, at 10:44:16AM, Geyslan Gregório Bem wrote:
Do you want that I undo that? I aggre that the variable use only
reduces the line code.
Yes please.
--
Matt Fleming, Intel Open Source Technology Center
Done:
[PATCH v2] efivarfs
2013/10/28 Geyslan Gregório Bem :
> 2013/10/28 Geyslan Gregório Bem
>>
>> 2013/10/27 Eric Van Hensbergen
>>>
>>> Looks like the right approach. The one other optional thing I mentioned
>>> was support for passing NULL for rdev and not trying to pa
2013/10/28 Geyslan Gregório Bem geys...@gmail.com:
2013/10/28 Geyslan Gregório Bem geys...@gmail.com
2013/10/27 Eric Van Hensbergen eri...@gmail.com
Looks like the right approach. The one other optional thing I mentioned
was support for passing NULL for rdev and not trying to parse
2013/10/28 Geyslan Gregório Bem
>
> 2013/10/27 Eric Van Hensbergen
>>
>> Looks like the right approach. The one other optional thing I mentioned was
>> support for passing NULL for rdev and not trying to parse the device info
>> when rdev == NULL. Its a very sl
2013/10/28 Geyslan Gregório Bem geys...@gmail.com
2013/10/27 Eric Van Hensbergen eri...@gmail.com
Looks like the right approach. The one other optional thing I mentioned was
support for passing NULL for rdev and not trying to parse the device info
when rdev == NULL. Its a very slight
2013/10/23 Ben Myers :
> Hey Geyslan,
>
> On Wed, Oct 23, 2013 at 08:58:51AM -0200, Geyslan Gregório Bem wrote:
>> - Regarding the "possible new patch" subject, I humbly pass the ball to you.
>>
>> Thank you for the attention.
>
> Thank you for
2013/10/22 Eric Sandeen :
> On 10/22/13 4:03 PM, Dave Chinner wrote:
>> On Tue, Oct 22, 2013 at 03:49:01PM -0500, Eric Sandeen wrote:
>>> On 10/22/13 3:39 PM, Dave Chinner wrote:
>>>> On Tue, Oct 22, 2013 at 08:12:51AM -0200, Geyslan Gregório Bem wrote:
2013/10/22 Eric Sandeen sand...@sandeen.net:
On 10/22/13 4:03 PM, Dave Chinner wrote:
On Tue, Oct 22, 2013 at 03:49:01PM -0500, Eric Sandeen wrote:
On 10/22/13 3:39 PM, Dave Chinner wrote:
On Tue, Oct 22, 2013 at 08:12:51AM -0200, Geyslan Gregório Bem wrote:
2013/10/21 Dave Chinner da
2013/10/23 Ben Myers b...@sgi.com:
Hey Geyslan,
On Wed, Oct 23, 2013 at 08:58:51AM -0200, Geyslan Gregório Bem wrote:
- Regarding the possible new patch subject, I humbly pass the ball to you.
Thank you for the attention.
Thank you for the patch. I would really prefer to commit
2013/10/21 Geyslan Gregório Bem :
> 2013/10/21 Geyslan Gregório Bem :
>> 2013/10/20 Eric Van Hensbergen :
>>> Please resubmit a clean patch which includes the check of sscanf for exactly
>>> the correct number of arguments and handles errors properly in other cases.
>
2013/10/21 Dirk Brandewie :
>
>
> On Monday, October 21, 2013, Rafael J. Wysocki wrote:
>>
>> On Monday, October 21, 2013 03:43:51 PM Dirk Brandewie wrote:
>> > On 10/21/2013 03:47 PM, Rafael J. Wysocki wrote:
>> > > On Monday, October 21, 2013 08:56:22 AM Dirk Brandewie wrote:
>> > >> On
2013/10/21 Dave Chinner :
> On Mon, Oct 21, 2013 at 07:00:59PM -0500, Eric Sandeen wrote:
>> On 10/21/13 6:56 PM, Dave Chinner wrote:
>> > On Mon, Oct 21, 2013 at 06:18:49PM -0500, Ben Myers wrote:
>> >> Hey,
>> >>
>> >> On Mon, Oct 21, 2013 at 06:12:18PM -0500, Eric Sandeen wrote:
>> >>> On
2013/10/21 Dave Chinner da...@fromorbit.com:
On Mon, Oct 21, 2013 at 07:00:59PM -0500, Eric Sandeen wrote:
On 10/21/13 6:56 PM, Dave Chinner wrote:
On Mon, Oct 21, 2013 at 06:18:49PM -0500, Ben Myers wrote:
Hey,
On Mon, Oct 21, 2013 at 06:12:18PM -0500, Eric Sandeen wrote:
On 10/21/13
2013/10/21 Dirk Brandewie dirk.brande...@gmail.com:
On Monday, October 21, 2013, Rafael J. Wysocki wrote:
On Monday, October 21, 2013 03:43:51 PM Dirk Brandewie wrote:
On 10/21/2013 03:47 PM, Rafael J. Wysocki wrote:
On Monday, October 21, 2013 08:56:22 AM Dirk Brandewie wrote:
On
2013/10/21 Geyslan Gregório Bem geys...@gmail.com:
2013/10/21 Geyslan Gregório Bem geys...@gmail.com:
2013/10/20 Eric Van Hensbergen eri...@gmail.com:
Please resubmit a clean patch which includes the check of sscanf for exactly
the correct number of arguments and handles errors properly
2013/10/21 Geyslan Gregório Bem :
> 2013/10/20 Eric Van Hensbergen :
>> Please resubmit a clean patch which includes the check of sscanf for exactly
>> the correct number of arguments and handles errors properly in other cases.
>> That last bit may be a bit problematic sin
2013/10/21 Geyslan G. Bem :
> In case of error in the p9_client_write, the function v9fs_fid_xattr_set
> should return its negative value, what was never being done.
>
> In case of success it only retuned 0. Now it returns the 'offset'
> variable (write_count total).
>
> Signed-off-by: Geyslan G.
2013/10/21 Geyslan Gregório Bem :
> At first, thanks for reply.
>
> 2013/10/20 Eric Van Hensbergen :
>> On Sat, Sep 28, 2013 at 6:32 PM, Geyslan G. Bem wrote:
>>>
>>> In case of error in the p9_client_write, the function v9fs_fid_xattr_set
>>> should
2013/10/21 Geyslan Gregório Bem :
> 2013/10/20 Eric Van Hensbergen :
>> I reckon we should probably just get rid of name if its not being used. I
>> doubt the indirection is going to hurt anything here.
>>
>> -eric
>>
>
> Eric, you're right. O
your patch.
>
Eric, I would like to try with your guidance.
> For the other patches, anyone you didn't see a response from me on today is
> being pulled into my for-next queue. Thanks for the cleanups.
>
> -eric
Thanks for accept them.
>
>
>
>
> On Mon, Oct 7, 20
2013/10/20 Eric Van Hensbergen :
> I reckon we should probably just get rid of name if its not being used. I
> doubt the indirection is going to hurt anything here.
>
> -eric
>
Eric, you're right. Once that there's not assignment to name, the
cycles are the same.
I'll get rid of name var.
At first, thanks for reply.
2013/10/20 Eric Van Hensbergen :
> On Sat, Sep 28, 2013 at 6:32 PM, Geyslan G. Bem wrote:
>>
>> In case of error in the p9_client_write, the function v9fs_fid_xattr_set
>> should return its negative value, what was never being done.
>>
>> Signed-off-by: Geyslan G. Bem
At first, thanks for reply.
2013/10/20 Eric Van Hensbergen eri...@gmail.com:
On Sat, Sep 28, 2013 at 6:32 PM, Geyslan G. Bem geys...@gmail.com wrote:
In case of error in the p9_client_write, the function v9fs_fid_xattr_set
should return its negative value, what was never being done.
2013/10/20 Eric Van Hensbergen eri...@gmail.com:
I reckon we should probably just get rid of name if its not being used. I
doubt the indirection is going to hurt anything here.
-eric
Eric, you're right. Once that there's not assignment to name, the
cycles are the same.
I'll get rid of
.
For the other patches, anyone you didn't see a response from me on today is
being pulled into my for-next queue. Thanks for the cleanups.
-eric
Thanks for accept them.
On Mon, Oct 7, 2013 at 7:18 PM, Geyslan Gregório Bem geys...@gmail.com
wrote:
Joe,
Nice, I'll wait their reply
2013/10/21 Geyslan Gregório Bem geys...@gmail.com:
2013/10/20 Eric Van Hensbergen eri...@gmail.com:
I reckon we should probably just get rid of name if its not being used. I
doubt the indirection is going to hurt anything here.
-eric
Eric, you're right. Once that there's
2013/10/21 Geyslan Gregório Bem geys...@gmail.com:
At first, thanks for reply.
2013/10/20 Eric Van Hensbergen eri...@gmail.com:
On Sat, Sep 28, 2013 at 6:32 PM, Geyslan G. Bem geys...@gmail.com wrote:
In case of error in the p9_client_write, the function v9fs_fid_xattr_set
should return its
1 - 100 of 190 matches
Mail list logo
