On Wed, 2018-04-11 at 11:52 +0200, Petr Mladek wrote:
> On Tue 2018-04-10 14:41:55, Andy Shevchenko wrote:
> > On Mon, 2018-04-09 at 15:50 +0200, Petr Mladek wrote:
> > > On Sat 2018-04-07 17:26:40, Andy Shevchenko wrote:
> > I think about 1-7 and 9 that can go as is before your changes.
> > And
On Wed, 2018-04-11 at 11:52 +0200, Petr Mladek wrote:
> On Tue 2018-04-10 14:41:55, Andy Shevchenko wrote:
> > On Mon, 2018-04-09 at 15:50 +0200, Petr Mladek wrote:
> > > On Sat 2018-04-07 17:26:40, Andy Shevchenko wrote:
> > I think about 1-7 and 9 that can go as is before your changes.
> > And
On Tue 2018-04-10 14:41:55, Andy Shevchenko wrote:
> On Mon, 2018-04-09 at 15:50 +0200, Petr Mladek wrote:
> > On Sat 2018-04-07 17:26:40, Andy Shevchenko wrote:
> > > On Wed, 2018-04-04 at 10:58 +0200, Petr Mladek wrote:
>
> > > This change collides with my patch series. Can you elaborate what
>
On Tue 2018-04-10 14:41:55, Andy Shevchenko wrote:
> On Mon, 2018-04-09 at 15:50 +0200, Petr Mladek wrote:
> > On Sat 2018-04-07 17:26:40, Andy Shevchenko wrote:
> > > On Wed, 2018-04-04 at 10:58 +0200, Petr Mladek wrote:
>
> > > This change collides with my patch series. Can you elaborate what
>
On Mon, 2018-04-09 at 15:50 +0200, Petr Mladek wrote:
> On Sat 2018-04-07 17:26:40, Andy Shevchenko wrote:
> > On Wed, 2018-04-04 at 10:58 +0200, Petr Mladek wrote:
> > This change collides with my patch series. Can you elaborate what
> > your
> > thoughts are about my patches? Are you going
On Mon, 2018-04-09 at 15:50 +0200, Petr Mladek wrote:
> On Sat 2018-04-07 17:26:40, Andy Shevchenko wrote:
> > On Wed, 2018-04-04 at 10:58 +0200, Petr Mladek wrote:
> > This change collides with my patch series. Can you elaborate what
> > your
> > thoughts are about my patches? Are you going
On Sat 2018-04-07 17:26:40, Andy Shevchenko wrote:
> On Wed, 2018-04-04 at 10:58 +0200, Petr Mladek wrote:
> > There are few printk formats that make sense only with two or more
> > specifiers. Also some specifiers make sense only when a kernel feature
> > is enabled.
> >
> > The handling of
On Sat 2018-04-07 17:26:40, Andy Shevchenko wrote:
> On Wed, 2018-04-04 at 10:58 +0200, Petr Mladek wrote:
> > There are few printk formats that make sense only with two or more
> > specifiers. Also some specifiers make sense only when a kernel feature
> > is enabled.
> >
> > The handling of
On Fri 2018-04-06 07:27:19, Joe Perches wrote:
> On Fri, 2018-04-06 at 15:17 +0200, Rasmus Villemoes wrote:
> > On 2018-04-06 13:43, Petr Mladek wrote:
> > > On Thu 2018-04-05 16:55:35, Joe Perches wrote:
> > > > On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote:
> > > > > On Thu, 2018-04-05 at
On Fri 2018-04-06 07:27:19, Joe Perches wrote:
> On Fri, 2018-04-06 at 15:17 +0200, Rasmus Villemoes wrote:
> > On 2018-04-06 13:43, Petr Mladek wrote:
> > > On Thu 2018-04-05 16:55:35, Joe Perches wrote:
> > > > On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote:
> > > > > On Thu, 2018-04-05 at
On Wed, 2018-04-04 at 10:58 +0200, Petr Mladek wrote:
> There are few printk formats that make sense only with two or more
> specifiers. Also some specifiers make sense only when a kernel feature
> is enabled.
>
> The handling of unknown specifiers is strange, inconsistent, and
> even leaking the
On Wed, 2018-04-04 at 10:58 +0200, Petr Mladek wrote:
> There are few printk formats that make sense only with two or more
> specifiers. Also some specifiers make sense only when a kernel feature
> is enabled.
>
> The handling of unknown specifiers is strange, inconsistent, and
> even leaking the
On Fri, 2018-04-06 at 15:17 +0200, Rasmus Villemoes wrote:
> On 2018-04-06 13:43, Petr Mladek wrote:
> > On Thu 2018-04-05 16:55:35, Joe Perches wrote:
> > > On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote:
> > > > On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote:
> > > > > Even just
On Fri, 2018-04-06 at 15:17 +0200, Rasmus Villemoes wrote:
> On 2018-04-06 13:43, Petr Mladek wrote:
> > On Thu 2018-04-05 16:55:35, Joe Perches wrote:
> > > On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote:
> > > > On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote:
> > > > > Even just
On (04/06/18 18:00), Joe Perches wrote:
[..]
> This finds the current two bad uses in addition to
> the existing similar message for string concatenation
> without a space char between concatenated fragments.
>
> For example:
>
> WARNING: break quoted strings at a space character
> #3550: FILE:
On (04/06/18 18:00), Joe Perches wrote:
[..]
> This finds the current two bad uses in addition to
> the existing similar message for string concatenation
> without a space char between concatenated fragments.
>
> For example:
>
> WARNING: break quoted strings at a space character
> #3550: FILE:
On Sat, 2018-04-07 at 09:33 +0900, Sergey Senozhatsky wrote:
> Hi Joe,
>
> On (04/06/18 16:59), Joe Perches wrote:
> > >
> > > Can we tweak checkpatch to catch such things?
> >
> > Not really, no.
> >
> > Adding regex logic for this is tricky at best
> > and probably not worth the effort
On Sat, 2018-04-07 at 09:33 +0900, Sergey Senozhatsky wrote:
> Hi Joe,
>
> On (04/06/18 16:59), Joe Perches wrote:
> > >
> > > Can we tweak checkpatch to catch such things?
> >
> > Not really, no.
> >
> > Adding regex logic for this is tricky at best
> > and probably not worth the effort
Hi Joe,
On (04/06/18 16:59), Joe Perches wrote:
> >
> > Can we tweak checkpatch to catch such things?
>
> Not really, no.
>
> Adding regex logic for this is tricky at best
> and probably not worth the effort because of
> the various bits of patch contexts aren't
> necessarily visible.
Agreed.
Hi Joe,
On (04/06/18 16:59), Joe Perches wrote:
> >
> > Can we tweak checkpatch to catch such things?
>
> Not really, no.
>
> Adding regex logic for this is tricky at best
> and probably not worth the effort because of
> the various bits of patch contexts aren't
> necessarily visible.
Agreed.
On Sat, 2018-04-07 at 08:52 +0900, Sergey Senozhatsky wrote:
> On (04/05/18 16:55), Joe Perches wrote:
> > On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote:
> > > On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote:
> > > > Even just git grep -1 -E '%p"$' finds %pt and %po
> > > > which
On Sat, 2018-04-07 at 08:52 +0900, Sergey Senozhatsky wrote:
> On (04/05/18 16:55), Joe Perches wrote:
> > On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote:
> > > On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote:
> > > > Even just git grep -1 -E '%p"$' finds %pt and %po
> > > > which
On (04/05/18 16:55), Joe Perches wrote:
> On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote:
> > On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote:
> > > Even just git grep -1 -E '%p"$' finds %pt and %po
> > > which should get fixed before somebody claims those extensions.
> >
> >
On (04/05/18 16:55), Joe Perches wrote:
> On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote:
> > On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote:
> > > Even just git grep -1 -E '%p"$' finds %pt and %po
> > > which should get fixed before somebody claims those extensions.
> >
> >
On Fri, 2018-04-06 at 15:17 +0200, Rasmus Villemoes wrote:
> On 2018-04-06 13:43, Petr Mladek wrote:
> > On Thu 2018-04-05 16:55:35, Joe Perches wrote:
> > > On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote:
> > > > On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote:
> > > > > Even just
On Fri, 2018-04-06 at 15:17 +0200, Rasmus Villemoes wrote:
> On 2018-04-06 13:43, Petr Mladek wrote:
> > On Thu 2018-04-05 16:55:35, Joe Perches wrote:
> > > On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote:
> > > > On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote:
> > > > > Even just
On 2018-04-06 13:43, Petr Mladek wrote:
> On Thu 2018-04-05 16:55:35, Joe Perches wrote:
>> On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote:
>>> On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote:
Even just git grep -1 -E '%p"$' finds %pt and %po
which should get fixed before
On 2018-04-06 13:43, Petr Mladek wrote:
> On Thu 2018-04-05 16:55:35, Joe Perches wrote:
>> On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote:
>>> On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote:
Even just git grep -1 -E '%p"$' finds %pt and %po
which should get fixed before
On Thu 2018-04-05 16:55:35, Joe Perches wrote:
> On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote:
> > On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote:
> > > Even just git grep -1 -E '%p"$' finds %pt and %po
> > > which should get fixed before somebody claims those extensions.
> >
>
On Thu 2018-04-05 16:55:35, Joe Perches wrote:
> On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote:
> > On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote:
> > > Even just git grep -1 -E '%p"$' finds %pt and %po
> > > which should get fixed before somebody claims those extensions.
> >
>
On Thu 2018-04-05 16:25:41, Rasmus Villemoes wrote:
> On 2018-04-04 10:58, Petr Mladek wrote:
> > There are few printk formats that make sense only with two or more
> > specifiers. Also some specifiers make sense only when a kernel feature
> > is enabled.
> >
> > The handling of unknown
On Thu 2018-04-05 16:25:41, Rasmus Villemoes wrote:
> On 2018-04-04 10:58, Petr Mladek wrote:
> > There are few printk formats that make sense only with two or more
> > specifiers. Also some specifiers make sense only when a kernel feature
> > is enabled.
> >
> > The handling of unknown
On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote:
> On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote:
> > Even just git grep -1 -E '%p"$' finds %pt and %po
> > which should get fixed before somebody claims those extensions.
>
> Neither %pt nor %po is used in a vsprintf
> in the
On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote:
> On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote:
> > Even just git grep -1 -E '%p"$' finds %pt and %po
> > which should get fixed before somebody claims those extensions.
>
> Neither %pt nor %po is used in a vsprintf
> in the
On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote:
> Even just git grep -1 -E '%p"$' finds %pt and %po
> which should get fixed before somebody claims those extensions.
Neither %pt nor %po is used in a vsprintf
in the kernel.
On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote:
> Even just git grep -1 -E '%p"$' finds %pt and %po
> which should get fixed before somebody claims those extensions.
Neither %pt nor %po is used in a vsprintf
in the kernel.
On 2018-04-04 10:58, Petr Mladek wrote:
> There are few printk formats that make sense only with two or more
> specifiers. Also some specifiers make sense only when a kernel feature
> is enabled.
>
> The handling of unknown specifiers is strange, inconsistent, and
> even leaking the address. For
On 2018-04-04 10:58, Petr Mladek wrote:
> There are few printk formats that make sense only with two or more
> specifiers. Also some specifiers make sense only when a kernel feature
> is enabled.
>
> The handling of unknown specifiers is strange, inconsistent, and
> even leaking the address. For
There are few printk formats that make sense only with two or more
specifiers. Also some specifiers make sense only when a kernel feature
is enabled.
The handling of unknown specifiers is strange, inconsistent, and
even leaking the address. For example, netdev_bits() prints the
non-hashed pointer
There are few printk formats that make sense only with two or more
specifiers. Also some specifiers make sense only when a kernel feature
is enabled.
The handling of unknown specifiers is strange, inconsistent, and
even leaking the address. For example, netdev_bits() prints the
non-hashed pointer
40 matches
Mail list logo
