On 12/02/18 17:31, Mike Rapoport wrote:
[...]
> Seems that kernel-doc does not consider () as a valid match for the
> identifier :)
>
> Can you please check with the below patch?
yes, it works now, than you!
--
igor
On 12/02/18 17:31, Mike Rapoport wrote:
[...]
> Seems that kernel-doc does not consider () as a valid match for the
> identifier :)
>
> Can you please check with the below patch?
yes, it works now, than you!
--
igor
On Mon, Feb 12, 2018 at 03:41:57PM +0200, Igor Stoppa wrote:
>
>
> On 12/02/18 14:53, Mike Rapoport wrote:
> > 'scripts/kernel-doc -v -none
>
> That has a quite interesting behavior.
>
> I run it on genalloc.c while I am in the process of adding the brackets
> to the function names in the
On Mon, Feb 12, 2018 at 03:41:57PM +0200, Igor Stoppa wrote:
>
>
> On 12/02/18 14:53, Mike Rapoport wrote:
> > 'scripts/kernel-doc -v -none
>
> That has a quite interesting behavior.
>
> I run it on genalloc.c while I am in the process of adding the brackets
> to the function names in the
On 12/02/18 14:53, Mike Rapoport wrote:
> 'scripts/kernel-doc -v -none
That has a quite interesting behavior.
I run it on genalloc.c while I am in the process of adding the brackets
to the function names in the kernel-doc description.
The brackets confuse the script and it fails to output
On 12/02/18 14:53, Mike Rapoport wrote:
> 'scripts/kernel-doc -v -none
That has a quite interesting behavior.
I run it on genalloc.c while I am in the process of adding the brackets
to the function names in the kernel-doc description.
The brackets confuse the script and it fails to output
On Mon, Feb 12, 2018 at 01:43:11PM +0200, Mike Rapoport wrote:
> On Mon, Feb 12, 2018 at 01:26:28PM +0200, Igor Stoppa wrote:
> > On 11/02/18 14:37, Mike Rapoport wrote:
> > > On Sun, Feb 11, 2018 at 05:19:18AM +0200, Igor Stoppa wrote:
> >
> > >> + * Return: 0 if the object does not belong to
On Mon, Feb 12, 2018 at 01:43:11PM +0200, Mike Rapoport wrote:
> On Mon, Feb 12, 2018 at 01:26:28PM +0200, Igor Stoppa wrote:
> > On 11/02/18 14:37, Mike Rapoport wrote:
> > > On Sun, Feb 11, 2018 at 05:19:18AM +0200, Igor Stoppa wrote:
> >
> > >> + * Return: 0 if the object does not belong to
On Mon, Feb 12, 2018 at 01:26:28PM +0200, Igor Stoppa wrote:
> On 11/02/18 14:37, Mike Rapoport wrote:
> > On Sun, Feb 11, 2018 at 05:19:18AM +0200, Igor Stoppa wrote:
>
> >> + * Return: 0 if the object does not belong to pmalloc, 1 if it belongs to
> >> + * pmalloc, -1 if it partially overlaps
On Mon, Feb 12, 2018 at 01:26:28PM +0200, Igor Stoppa wrote:
> On 11/02/18 14:37, Mike Rapoport wrote:
> > On Sun, Feb 11, 2018 at 05:19:18AM +0200, Igor Stoppa wrote:
>
> >> + * Return: 0 if the object does not belong to pmalloc, 1 if it belongs to
> >> + * pmalloc, -1 if it partially overlaps
On 11/02/18 14:37, Mike Rapoport wrote:
> On Sun, Feb 11, 2018 at 05:19:18AM +0200, Igor Stoppa wrote:
>> + * Return: 0 if the object does not belong to pmalloc, 1 if it belongs to
>> + * pmalloc, -1 if it partially overlaps pmalloc meory, but incorectly.
>
> typo:
On 11/02/18 14:37, Mike Rapoport wrote:
> On Sun, Feb 11, 2018 at 05:19:18AM +0200, Igor Stoppa wrote:
>> + * Return: 0 if the object does not belong to pmalloc, 1 if it belongs to
>> + * pmalloc, -1 if it partially overlaps pmalloc meory, but incorectly.
>
> typo:
On Sun, Feb 11, 2018 at 05:19:18AM +0200, Igor Stoppa wrote:
> The MMU available in many systems running Linux can often provide R/O
> protection to the memory pages it handles.
>
> However, the MMU-based protection works efficiently only when said pages
> contain exclusively data that will not
On Sun, Feb 11, 2018 at 05:19:18AM +0200, Igor Stoppa wrote:
> The MMU available in many systems running Linux can often provide R/O
> protection to the memory pages it handles.
>
> However, the MMU-based protection works efficiently only when said pages
> contain exclusively data that will not
On 05/02/18 00:06, Randy Dunlap wrote:
> On 02/04/2018 08:47 AM, Igor Stoppa wrote:
[...]
>> + * pmalloc_create_pool - create a new protectable memory pool -
>
> Drop trailing " -".
yes
>> + * @name: the name of the pool, must be unique
>
> Is that enforced? Will return NULL if @name is
On 05/02/18 00:06, Randy Dunlap wrote:
> On 02/04/2018 08:47 AM, Igor Stoppa wrote:
[...]
>> + * pmalloc_create_pool - create a new protectable memory pool -
>
> Drop trailing " -".
yes
>> + * @name: the name of the pool, must be unique
>
> Is that enforced? Will return NULL if @name is
Hi Igor,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on kees/for-next/pstore]
[also build test ERROR on v4.15]
[cannot apply to linus/master mmotm/master next-20180207]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
Hi Igor,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on kees/for-next/pstore]
[also build test ERROR on v4.15]
[cannot apply to linus/master mmotm/master next-20180207]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
Hi Igor,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on kees/for-next/pstore]
[also build test ERROR on v4.15]
[cannot apply to linus/master mmotm/master next-20180206]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
Hi Igor,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on kees/for-next/pstore]
[also build test ERROR on v4.15]
[cannot apply to linus/master mmotm/master next-20180206]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
On 02/04/2018 08:47 AM, Igor Stoppa wrote:
> The MMU available in many systems running Linux can often provide R/O
> protection to the memory pages it handles.
>
> However, the MMU-based protection works efficiently only when said pages
> contain exclusively data that will not need further
On 02/04/2018 08:47 AM, Igor Stoppa wrote:
> The MMU available in many systems running Linux can often provide R/O
> protection to the memory pages it handles.
>
> However, the MMU-based protection works efficiently only when said pages
> contain exclusively data that will not need further
Hi Igor,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.15]
[cannot apply to next-20180201]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Igor,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.15]
[cannot apply to next-20180201]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Igor,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.15]
[cannot apply to next-20180201]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Igor,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.15]
[cannot apply to next-20180201]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
On 24/01/18 19:56, Igor Stoppa wrote:
[...]
> +bool pmalloc_prealloc(struct gen_pool *pool, size_t size)
> +{
[...]
> +abort:
> + vfree(chunk);
this should be vfree_atomic()
[...]
> +void *pmalloc(struct gen_pool *pool, size_t size, gfp_t gfp)
> +{
[...]
> +free:
> + vfree(chunk);
On 24/01/18 19:56, Igor Stoppa wrote:
[...]
> +bool pmalloc_prealloc(struct gen_pool *pool, size_t size)
> +{
[...]
> +abort:
> + vfree(chunk);
this should be vfree_atomic()
[...]
> +void *pmalloc(struct gen_pool *pool, size_t size, gfp_t gfp)
> +{
[...]
> +free:
> + vfree(chunk);
28 matches
Mail list logo
