From: subashab@codeaurora.org
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org,
netdev-owner@vger.kernel.org
Subject: Re: [RFC] Handle error writing UINT_MAX to u32 fields
Date: Tue, 14 Jun 2016 14:36:41 -0600 [thread overview]
Message-ID: <191b6c778e6e0ccf3c60e23cee724d8f@codeaurora.org> (raw)
In-Reply-To: <363ac4f6f7e1a8b905af567667a1559a@codeaurora.org>
On 2016-06-12 20:30, subashab@codeaurora.org wrote:
>> The suggested change would extend the usable range of positive numbers
>> by one bit only. As many systems are 64 bit this does not seem forward
>> looking.
>>
>> I would prefer to have a routine that can handle 64 bit integers with
>> limits (let's call it proc_doint64vec_minmax) which uses fields extra1
>> and extra2 of ctl_table as min and max.
>>
>> Then set xfrm_table[].extra1 = 0 and xfrm_table[].extra2 = UINT_MAX if
>> you need a result in the u32 range.
>>
>
> Thanks Heinrich. Do you think we can use proc_doulongvec_minmax for
> this?
Actually proc_doulongvec_minmax does not work here.
I would expect similar problems due to casting if we use u64
(proc_doint64vec_minmax) here.
static int __do_proc_doulongvec_minmax(void *data, struct ctl_table
*table, int write,
{
unsigned long *i, *min, *max;
int vleft, first = 1, err = 0;
i = (unsigned long *) data; //This cast is causing to read beyond the
size of data (u32)
min = (unsigned long *) table->extra1;
max = (unsigned long *) table->extra2;
vleft = table->maxlen / sizeof(unsigned long); //vleft is 0 because
maxlen is sizeof(u32) which is lesser than sizeof(unsigned long) on
x86_64.
next prev parent reply other threads:[~2016-06-14 20:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-10 2:40 [RFC] Handle error writing UINT_MAX to u32 fields Subash Abhinov Kasiviswanathan
2016-06-10 6:28 ` Heinrich Schuchardt
2016-06-13 2:30 ` subashab
2016-06-14 20:36 ` subashab [this message]
2016-06-10 6:37 ` Heinrich Schuchardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=191b6c778e6e0ccf3c60e23cee724d8f@codeaurora.org \
--to=subashab@codeaurora.org \
--cc=eric.dumazet@gmail.com \
--cc=netdev-owner@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.