Re: [PATCH rebased] kbuild: rpm-pkg: Fix build with non-default MODLIB

[Jan Engelhardt]

On Friday 2023-11-10 18:44, Michal Suchánek wrote:
>> It's a complicated mumble-jumble. Prior art exists as in:
>> 
>>  /opt/vendorThing/bin/...
>>  /usr/X11R6/lib/libXi.so.6 [host binary]
>>  /usr/x86_64-w64-mingw32/bin/as [host binary]
>>  /usr/x86_64-w64-mingw32/sys-root/mingw/bin/as.exe [foreign binary]
>>  /usr/platform/SUNW,Ultra-2/lib/libprtdiag_psr.so.1 [looks foreign]
>> 
>> The use of suffix-based naming must have been established sometime
>> near the end of the 90s or the start of 2000s as the first biarch
>> Linux distros emerged. Probably in gcc or glibc sources one will find
>> the root of where the use of suffix identifiers like /usr/lib64
>> started. Leaves the question open "why".
>
>That's pretty clear: to be able to install libraries for multiple
>architectures at the same time.

Well, what I tried to express or imply was something like:

“ we could (should?) have used /usr//lib rather than
  /usr/lib all along, because at some point, there *will* be
  someone who wants to provide not only arch-different libraries, but *also*
  arch-different binaries (for whatever reason).

Re: [PATCH kmod v5 5/5] libkmod, depmod, modprobe: Make directory for kernel modules configurable

[Jan Engelhardt]

On Tuesday 2023-10-17 19:50, Lucas De Marchi wrote:
>> +AC_ARG_WITH([module_directory],
>> +AS_HELP_STRING([--with-module-directory=DIR], [directory in which to
>> look for kernel modules - typically '/lib/modules' or
>> '${prefix}/lib/modules']),
>> +[], [with_module_directory=/lib/modules])
>> +AC_SUBST([module_directory], [$with_module_directory])
>
> we will probably have "fun" results if we accept a relative path here.

$ ./configure --prefix=/usr --bindir=../bin
configure: error: expected an absolute directory name for --bindir: ../bin

While such check does not exist for --with-module-directory, everyone
has likely been well-trained not to use relative paths. Even if, say,
cmake/meson *could* do it, it just would have never occurred to me to
actually *utilize* it, because it is just too ambiguous and
potentially dangerous.

Just think of all the fun you could have with LD_LIBRARY_PATH=".."

Re: [PATCH rebased] kbuild: rpm-pkg: Fix build with non-default MODLIB

[Jan Engelhardt]

On Tuesday 2023-10-17 17:10, Michal Suchánek wrote:
>
>> In my system (Ubuntu), I see the directory paths
>> 
>> /usr/aarch64-linux-gnu/lib/
>> /usr/i686-linux-gnu/lib/
>> /usr/x86_64-linux-gnu/lib/
>> 
>> If there were such a crazy distro that supports multiple kernel arches
>> within a single image, modules might be installed:
>> /usr/x86_64-linux-gnu/lib/module//
>
>For me it's /usr/lib/i386-linux-gnu/.
>
>Did they change the scheme at some point?

It's a complicated mumble-jumble. Prior art exists as in:

 /opt/vendorThing/bin/...
 /usr/X11R6/lib/libXi.so.6 [host binary]
 /usr/x86_64-w64-mingw32/bin/as [host binary]
 /usr/x86_64-w64-mingw32/sys-root/mingw/bin/as.exe [foreign binary]
 /usr/platform/SUNW,Ultra-2/lib/libprtdiag_psr.so.1 [looks foreign]

The use of suffix-based naming must have been established sometime
near the end of the 90s or the start of 2000s as the first biarch
Linux distros emerged. Probably in gcc or glibc sources one will find
the root of where the use of suffix identifiers like /usr/lib64
started. Leaves the question open "why".

Re: [PATCH rebased] kbuild: rpm-pkg: Fix build with non-default MODLIB

[Jan Engelhardt]

On Monday 2023-10-09 17:14, Masahiro Yamada wrote:
>
>Let me add more context to my question.
>
>I am interested in the timing when
>'pkg-config --print-variables kmod | grep module_directory'
>is executed.
>
>1.  Build a SRPM on machine A
>2.  Copy the SRPM from machine A to machine B
>3.  Run rpmbuild on machine B to build the SRPM into a RPM
>4.  Copy the RPM from machine B to machine C
>5.  Install the RPM to machine C

In over 20 years of Linux distros existing, the one thing that
everyone has learned is that installing foreign RPM packages (or any
other format) is probably not going to work for one reason or
another. Different package names in Require: lines (just think of the
switch from modutils to kmod), different ABIs..

The overwhelming amount of package production that is going on these
days targets distro(A) == distro(B) == distro(C).


Yeah, the kernel package is kinda special because the files in it
are freestanding executables, but still..

Re: k10temp: ZEN3 readings are broken

[Jan Engelhardt]

On Tuesday 2020-12-22 04:58, Guenter Roeck wrote:
>On 12/21/20 5:45 PM, Gabriel C wrote:
>> Hello Guenter,
>> 
>> while trying to add ZEN3 support for zenpower out of tree modules, I find out
>> the in-kernel k10temp driver is broken with ZEN3 ( and partially ZEN2 even ).
>
>[...] since I do not have time to actively maintain
>the driver, since each chip variant seems to use different addresses and 
>scales,
>and since the information about voltages and currents is unpublished by AMD,
>I'll remove support for voltage/current readings from the upstream driver.

I support that decision.

/proc/cpuinfo::AMD Ryzen 7 3700X 8-Core Processor, fam 23 model 113 step 0

A synthetic load (perl -e '1 while 1') x 16 shows:
Adapter: PCI adapter
Vcore:+1.28 V
Vsoc: +1.02 V
Tctl: +94.8°C
Tdie: +94.8°C
Tccd1:+94.8°C
Icore:   +76.00 A
Isoc: +6.75 A

A BOINC workload on average:
k10temp-pci-00c3
Adapter: PCI adapter
Vcore:+1.17 V  
Vsoc: +1.02 V  
Tctl: +94.9°C  
Tdie: +94.9°C  
Tccd1:+95.0°C  
Icore:   +88.00 A  
Isoc: +8.00 A  

The BOINC workload, when it momentarily spikes:
Adapter: PCI adapter
Vcore:+1.32 V  
Vsoc: +1.02 V  
Tctl: +94.1°C  
Tdie: +94.1°C  
Tccd1:+96.0°C  
Icore:   +105.00 A  
Isoc: +7.75 A  

For a processor sold as a 65 W part, observing reported sensors as 
88 A x 1.17 V + 8 A x 1.02 V = 111.12 W just can't be. We are off by a 
factor of about 2.

Re: [PATCH v1 01/13] sparc32: Drop sun4m/sun4d support from head_32.S

[Jan Engelhardt]

On Friday 2020-12-18 19:43, Sam Ravnborg wrote:
> notsup:
>-  .asciz  "Sparc-Linux sun4/sun4c or MMU-less not supported\n\n"
>-  .align 4
>-
>-sun4e_notsup:
>-.asciz  "Sparc-Linux sun4e support does not exist\n\n"
>+  .asciz  "Sparc-Linux sun4* or MMU-less not supported\n\n"
>   .align 4

The asterisk may lead to a moment of bewilderment; sun4u/sun4v are still 
supported.

Re: remaining flexible-array conversions

[Jan Engelhardt]

On Friday 2020-04-24 14:15, Jason Gunthorpe wrote:
>> ./usr/include/rdma/ib_user_verbs.h:436:34: warning: field 'base' with
>> variable sized type 'struct ib_uverbs_create_cq_resp' not at the end of
>> a struct or class is a GNU extension
>> [-Wgnu-variable-sized-type-not-at-end]
>> struct ib_uverbs_create_cq_resp base;
>> ^
>> I presume this is part of the point of the conversion since you mention
>> a compiler warning when the flexible member is not at the end of a
>> struct. How should they be fixed? That should probably happen before the
>> patch gets merged.
>
>The flexible member IS at the end of the struct and is often intended
>to cover the memory in the enclosing struct.

There is no guarantee for the presence of such a struct.

In the case of the RDMA headers, even if we assume best conditions --
a block of malloc(sizeof(struct ib_uverbs_create_cq_resp) +
sizeof(u64)*N) and not some struct -- it smells a lot like undefined
behavior, because ib_uverbs_create_cq_resp::driver_data accesses data
as u64 while ib_uverbs_ex_create_cq_resp::comp_mask and friends are
u32.

There has got to be some aliasing rule in C that causes RDMA's
purported use-case to be UB.

Re: [PATCH 04/26] net: add a new sockptr_t type

[Jan Engelhardt]

On Thursday 2020-07-23 08:08, Christoph Hellwig wrote:
>+typedef struct {
>+  union {
>+  void*kernel;
>+  void __user *user;
>+  };
>+  boolis_kernel : 1;
>+} sockptr_t;
>+
>+static inline bool sockptr_is_null(sockptr_t sockptr)
>+{
>+  return !sockptr.user && !sockptr.kernel;
>+}

"""If the member used to access the contents of a union is not the same as the
member last used to store a value, the object representation of the value that
was stored is reinterpreted as an object representation of the new type (this
is known as type punning). If the size of the new type is larger than the size
of the last-written type, the contents of the excess bytes are unspecified (and
may be a trap representation)"""

As I am not too versed with the consequences of trap representations, I will
just point out that a future revision of the C standard may introduce (proposal
N2362) stronger C++-like requirements; as for union, that would imply a simple:

"""It's undefined behavior to read from the member of the union that wasn't
most recently written.""" [cppreference.com]


So, in the spirit of copy_from/to_sockptr, the is_null function should read

{
return sockptr.is_kernel ? !sockptr.user : !sockptr.kernel;
}

Re: Good idea to rename files in include/uapi/ ?

[Jan Engelhardt]

On Monday 2020-06-15 01:34, Alexander A. Klimov wrote:
>> 
>> A header file rename is no problem. We even have dummy headers
> Hmm.. if I understand all of you correctly, David, Stefano, Pablo and Al say
> like no, not a good idea, but only you, Jan, say like should be no problem.
>
> Jan, do you have anything like commit messages in mainline or public emails
> from maintainers confirming your opinion?

I had already given the commit with the (email) message:

>> Just look at xt_MARK.h, all it does is include xt_mark.h. Cf.
>> 28b949885f80efb87d7cebdcf879c99db12c37bd .

Re: [PATCH] linux++, this: rename "struct notifier_block *this"

[Jan Engelhardt]

On Friday 2020-06-19 09:46, Christoph Hellwig wrote:

>On Fri, Jun 19, 2020 at 12:06:45AM +0300, Alexey Dobriyan wrote:
>> Rename
>>  struct notifier_block *this
>> to
>>  struct notifier_block *nb
>> 
>> "nb" is arguably a better name for notifier block.
>
>But not enough better to cause tons of pointless churn.  Feel free
>to use better naming in new code you write or do significant changes
>to, but stop these pointless renames.

Well, judging from the mention of "linux++" in the subject, I figure 
this is the old discussion of someone trying to make Linux code, or 
parts thereof, work in a C++ environment. Since the patch does not just 
touch headers but .c files, I deduce that there seems to be a project 
trying to build Linux, or a subset thereof, as a C++ program for the fun 
of it. UML could come to mind.

Is it a hot potato? Definitely. But so was IPv6 NAT, and now we have it 
anyway.

Re: Good idea to rename files in include/uapi/ ?

[Jan Engelhardt]

On Sunday 2020-06-14 22:19, David Howells wrote:
>Alexander A. Klimov  wrote:
>
>> *Is it a good idea to rename files in include/uapi/ ?*
>
>Very likely not.  If programs out there are going to be built on a
>case-sensitive filesystem (which happens all the time), they're going to break
>if you rename the headers.  We're kind of stuck with them.

Netfilter has precedent for removing old headers, e.g.
7200135bc1e61f1437dc326ae2ef2f310c50b4eb's ipt_ULOG.h.

Even if kernels would not remove such headers, the iptables userspace
code wants to be buildable with all kinds of kernels, including past
releases, which do not have modern headers like xt_l2tp.h.

The mantra for userspace programs is therefore "copy the headers" —
because you never know what /usr/include/linux you get. iptables and
iproute2 are two example codebases that employ this. And when headers
do get copied, header removals from the kernel side are no longer a
big deal either.

A header file rename is no problem. We even have dummy headers
already because of this... or related changes. Just look at
xt_MARK.h, all it does is include xt_mark.h. Cf.
28b949885f80efb87d7cebdcf879c99db12c37bd .

The boilerplate for xt_*h is quite high thanks to the miniscule
splitting of headers. Does not feel right in this day and age.

Re: [RFC PATCH 0/4] DirectX on Linux

[Jan Engelhardt]

On Tuesday 2020-05-19 22:36, Sasha Levin wrote:
>
>> - Why DX12 on linux? Looking at this feels like classic divide and
>
> There is a single usecase for this: WSL2 developer who wants to run
> machine learning on his GPU. The developer is working on his laptop,
> which is running Windows and that laptop has a single GPU that Windows
> is using.

It does not feel right conceptually. If the target is a Windows API
(DX12/ML), why bother with Linux environments? Make it a Windows executable,
thereby skipping the WSL translation layer and passthrough.

Re: [PATCH] netfilter: fix make target xt_TCPMSS.o error.

[Jan Engelhardt]

On Wednesday 2020-05-06 08:50, Huang Qijun wrote:

>When compiling netfilter, there will be an error
>"No rule to make target 'net/netfilter/xt_TCPMSS.o'",
>because the xt_TCPMSS.c in the makefile is uppercase,
>and the file name of the source file (xt_tcpmss.c) is lowercase.

>-obj-$(CONFIG_NETFILTER_XT_TARGET_TCPMSS) += xt_TCPMSS.o
>+obj-$(CONFIG_NETFILTER_XT_TARGET_TCPMSS) += xt_tcpmss.o

Uhm, no:

11:07 a4:../net/netfilter » ls -l xt_*[Mm][Ss]*.c
-rw-r--r-- 1 jengelh users 8948 Feb 27 09:30 xt_TCPMSS.c
-rw-r--r-- 1 jengelh users 2459 Feb 27 09:30 xt_tcpmss.c

Re: [PATCH v9 00/13] arch/resctrl: AMD QoS support

[Jan Engelhardt]

On Nov 21 2018 20:28:23, Moger, Babu wrote:
>
>This series adds support for AMD64 architectural extensions for 
>Platform Quality of Service.

The term "QoS" is already used for net/sched/. It will be bad naming to 
have QoS - and then an AMD QoS / Platform QoS as well. Preexisting, 
decade-old howtos may speak of enabling "QoS", and with the ambiguity, 
the unsuspecting kernel builder apprentice may enable the wrong thing in 
his config.

So either the QoS from networking gets correspondingly renamed ("packet 
QoS"?.. or something), or else AMD QoS should be changed.

Re: [PATCH 04/11] UAPI: bcache: Fix use of embedded flexible array

[Jan Engelhardt]

On Tuesday 2018-10-09 17:41, David Howells wrote:

>Jan Engelhardt  wrote:
>
>> """it [the array size expression] shall be a converted constant expression of
>> type std::size_t and its value shall be greater than zero."""
>> —http://eel.is/c++draft/dcl.array
>
>Interesting.  You're not actually quoting the full sentence:
>
>   If the constant-expression is present, it shall be a converted
>   constant expression of type std​::​size_­t and its value shall be
>   greater than zero.
>
>This suggests that:
>
>   __u64 ptr[]
>
>is actually valid

I think that kind of validity only goes for this kind of standalone 
decl:

extern int myints[];

but not for []-inside-struct.

Re: [PATCH 04/11] UAPI: bcache: Fix use of embedded flexible array

[Jan Engelhardt]

On Tuesday 2018-10-09 17:41, David Howells wrote:

>Jan Engelhardt  wrote:
>
>> """it [the array size expression] shall be a converted constant expression of
>> type std::size_t and its value shall be greater than zero."""
>> —http://eel.is/c++draft/dcl.array
>
>Interesting.  You're not actually quoting the full sentence:
>
>   If the constant-expression is present, it shall be a converted
>   constant expression of type std​::​size_­t and its value shall be
>   greater than zero.
>
>This suggests that:
>
>   __u64 ptr[]
>
>is actually valid

I think that kind of validity only goes for this kind of standalone 
decl:

extern int myints[];

but not for []-inside-struct.

Re: [PATCH 04/11] UAPI: bcache: Fix use of embedded flexible array

[Jan Engelhardt]

On Wed, 05 Sep 2018 16:55:03 +0100, David Howells wrote:
>
>The bkey struct defined by bcache is embedded in the jset struct. However,
>this is illegal in C++ as there's a "flexible array" at the end of the struct.
>Change this to be a 0-length struct instead.
>
>-  __u64   ptr[];
>+  __u64   ptr[0];

As per the C++ standard, it is _also_ illegal to declare an array of size zero.

"""it [the array size expression] shall be a converted constant expression of
type std::size_t and its value shall be greater than zero."""
—http://eel.is/c++draft/dcl.array

That makes both "__u64 ptr[]" and "__u64 ptr[0]" *implementation-specific
extensions*.


3rd party tooling (concerns both C and C++):

Coverity Scan (IIRC) treats "__u64 ptr[0]" as an array of "definitely-zero"
size. Writing to any element will outright flag an out-of-bounds violation.
That is sensible, since only "ptr[]" was standardized.


Conclusion:

So please, do never use __u64 ptr[0].

Re: [PATCH 04/11] UAPI: bcache: Fix use of embedded flexible array

[Jan Engelhardt]

On Wed, 05 Sep 2018 16:55:03 +0100, David Howells wrote:
>
>The bkey struct defined by bcache is embedded in the jset struct. However,
>this is illegal in C++ as there's a "flexible array" at the end of the struct.
>Change this to be a 0-length struct instead.
>
>-  __u64   ptr[];
>+  __u64   ptr[0];

As per the C++ standard, it is _also_ illegal to declare an array of size zero.

"""it [the array size expression] shall be a converted constant expression of
type std::size_t and its value shall be greater than zero."""
—http://eel.is/c++draft/dcl.array

That makes both "__u64 ptr[]" and "__u64 ptr[0]" *implementation-specific
extensions*.


3rd party tooling (concerns both C and C++):

Coverity Scan (IIRC) treats "__u64 ptr[0]" as an array of "definitely-zero"
size. Writing to any element will outright flag an out-of-bounds violation.
That is sensible, since only "ptr[]" was standardized.


Conclusion:

So please, do never use __u64 ptr[0].

Re: [netfilter-core] kernel panic: Out of memory and no killable processes... (2)

[Jan Engelhardt]

On Monday 2018-01-29 17:57, Florian Westphal wrote:
>> > > vmalloc() once became killable by commit 5d17a73a2ebeb8d1 ("vmalloc: back
>> > > off when the current task is killed") but then became unkillable by 
>> > > commit
>> > > b8c8a338f75e052d ("Revert "vmalloc: back off when the current task is
>> > > killed""). Therefore, we can't handle this problem from MM side.
>> > > Please consider adding some limit from networking side.
>> > 
>> > I don't know what "some limit" would be.  I would prefer if there was
>> > a way to supress OOM Killer in first place so we can just -ENOMEM user.
>> 
>> Just supressing OOM kill is a bad idea. We still leave a way to allocate
>> arbitrary large buffer in kernel.

At the very least, mm could limit that kind of "arbitrary". If the machine has
x GB (swap included) and the admin tries to make the kernel allocate space for
an x GB ruleset, no way is it going to be satisfiable _even with OOM_.

>I think we should try to allocate whatever amount of memory is needed
>for the given xtables ruleset, given that is what admin requested us to do.

Re: [netfilter-core] kernel panic: Out of memory and no killable processes... (2)

[Jan Engelhardt]

On Monday 2018-01-29 17:57, Florian Westphal wrote:
>> > > vmalloc() once became killable by commit 5d17a73a2ebeb8d1 ("vmalloc: back
>> > > off when the current task is killed") but then became unkillable by 
>> > > commit
>> > > b8c8a338f75e052d ("Revert "vmalloc: back off when the current task is
>> > > killed""). Therefore, we can't handle this problem from MM side.
>> > > Please consider adding some limit from networking side.
>> > 
>> > I don't know what "some limit" would be.  I would prefer if there was
>> > a way to supress OOM Killer in first place so we can just -ENOMEM user.
>> 
>> Just supressing OOM kill is a bad idea. We still leave a way to allocate
>> arbitrary large buffer in kernel.

At the very least, mm could limit that kind of "arbitrary". If the machine has
x GB (swap included) and the admin tries to make the kernel allocate space for
an x GB ruleset, no way is it going to be satisfiable _even with OOM_.

>I think we should try to allocate whatever amount of memory is needed
>for the given xtables ruleset, given that is what admin requested us to do.

Re: [PATCH] net: netfilter: Replace explicit NULL comparisons

[Jan Engelhardt]

On Sunday 2017-04-09 05:42, Arushi Singhal wrote:
>On Sun, Apr 9, 2017 at 1:44 AM, Pablo Neira Ayuso <pa...@netfilter.org> wrote:
>  On Sat, Apr 08, 2017 at 08:21:56PM +0200, Jan Engelhardt wrote:
>  > On Saturday 2017-04-08 19:21, Arushi Singhal wrote:
>  >
>  > >Replace explicit NULL comparison with ! operator to simplify code.
>  >
>  > I still wouldn't do this, for the same reason as before. Comparing to
>  > NULL explicitly more or less gave an extra guarantee that the other
>  > operand was also a pointer.
>
>  Arushi, where does it say in the coding style that this is prefered? 
>
>This is reported by checkpatch.pl script.

checkpatch has been controversial at times, like when people took the 80
character limit way too literally. Changing pointer comparisons looks like
another thing that is better left ignored.

Re: [PATCH] net: netfilter: Replace explicit NULL comparisons

[Jan Engelhardt]

On Sunday 2017-04-09 05:42, Arushi Singhal wrote:
>On Sun, Apr 9, 2017 at 1:44 AM, Pablo Neira Ayuso  wrote:
>  On Sat, Apr 08, 2017 at 08:21:56PM +0200, Jan Engelhardt wrote:
>  > On Saturday 2017-04-08 19:21, Arushi Singhal wrote:
>  >
>  > >Replace explicit NULL comparison with ! operator to simplify code.
>  >
>  > I still wouldn't do this, for the same reason as before. Comparing to
>  > NULL explicitly more or less gave an extra guarantee that the other
>  > operand was also a pointer.
>
>  Arushi, where does it say in the coding style that this is prefered? 
>
>This is reported by checkpatch.pl script.

checkpatch has been controversial at times, like when people took the 80
character limit way too literally. Changing pointer comparisons looks like
another thing that is better left ignored.

Re: [PATCH] net: netfilter: Replace explicit NULL comparisons

[Jan Engelhardt]

On Saturday 2017-04-08 19:21, Arushi Singhal wrote:

>Replace explicit NULL comparison with ! operator to simplify code.

I still wouldn't do this, for the same reason as before. Comparing to 
NULL explicitly more or less gave an extra guarantee that the other 
operand was also a pointer.

Re: [PATCH] net: netfilter: Replace explicit NULL comparisons

[Jan Engelhardt]

On Saturday 2017-04-08 19:21, Arushi Singhal wrote:

>Replace explicit NULL comparison with ! operator to simplify code.

I still wouldn't do this, for the same reason as before. Comparing to 
NULL explicitly more or less gave an extra guarantee that the other 
operand was also a pointer.

Re: [PATCH v2] netfilter: Clean up tests if NULL returned on failure

[Jan Engelhardt]

On Wednesday 2017-03-29 11:15, SIMRAN SINGHAL wrote:
>>   dest = kzalloc(sizeof(struct ip_vs_dest), GFP_KERNEL);
>>-  if (dest == NULL)
>>+  if (!dest)
>>   return -ENOMEM;
>
>But, according to me we should prefer !var over ( var ==NULL ) according to the
>coding style

Where does it say that?

Re: [PATCH v2] netfilter: Clean up tests if NULL returned on failure

[Jan Engelhardt]

On Wednesday 2017-03-29 11:15, SIMRAN SINGHAL wrote:
>>   dest = kzalloc(sizeof(struct ip_vs_dest), GFP_KERNEL);
>>-  if (dest == NULL)
>>+  if (!dest)
>>   return -ENOMEM;
>
>But, according to me we should prefer !var over ( var ==NULL ) according to the
>coding style

Where does it say that?

Re: [PATCH v2] netfilter: Clean up tests if NULL returned on failure

[Jan Engelhardt]

On Tuesday 2017-03-28 18:23, SIMRAN SINGHAL wrote:
>On Tue, Mar 28, 2017 at 7:24 PM, Jan Engelhardt <jeng...@inai.de> wrote:
>> On Tuesday 2017-03-28 15:13, simran singhal wrote:
>>
>>>Some functions like kmalloc/kzalloc return NULL on failure. When NULL
>>>represents failure, !x is commonly used.
>>>
>>>@@ -910,7 +910,7 @@ ip_vs_new_dest(struct ip_vs_service *svc, struct 
>>>ip_vs_dest_user_kern *udest,
>>>   }
>>>
>>>   dest = kzalloc(sizeof(struct ip_vs_dest), GFP_KERNEL);
>>>-  if (dest == NULL)
>>>+  if (!dest)
>>>   return -ENOMEM;
>>
>> This kind of transformation however is not cleanup anymore, it's really
>> bikeshedding and should be avoided. There are pro and cons for both
>> variants, and there is not really an overwhelming number of arguments
>> for either variant to justify the change.
>
>Sorry, but I didn't get what you are trying to convey. And particularly pros 
>and
>cons of both variants.

The ==NULL/!=NULL part sort of ensures that the left side is a pointer, which
is lost when just using the variable and have it implicitly convert to bool.

Re: [PATCH v2] netfilter: Clean up tests if NULL returned on failure

[Jan Engelhardt]

On Tuesday 2017-03-28 18:23, SIMRAN SINGHAL wrote:
>On Tue, Mar 28, 2017 at 7:24 PM, Jan Engelhardt  wrote:
>> On Tuesday 2017-03-28 15:13, simran singhal wrote:
>>
>>>Some functions like kmalloc/kzalloc return NULL on failure. When NULL
>>>represents failure, !x is commonly used.
>>>
>>>@@ -910,7 +910,7 @@ ip_vs_new_dest(struct ip_vs_service *svc, struct 
>>>ip_vs_dest_user_kern *udest,
>>>   }
>>>
>>>   dest = kzalloc(sizeof(struct ip_vs_dest), GFP_KERNEL);
>>>-  if (dest == NULL)
>>>+  if (!dest)
>>>   return -ENOMEM;
>>
>> This kind of transformation however is not cleanup anymore, it's really
>> bikeshedding and should be avoided. There are pro and cons for both
>> variants, and there is not really an overwhelming number of arguments
>> for either variant to justify the change.
>
>Sorry, but I didn't get what you are trying to convey. And particularly pros 
>and
>cons of both variants.

The ==NULL/!=NULL part sort of ensures that the left side is a pointer, which
is lost when just using the variable and have it implicitly convert to bool.

Re: [PATCH v2] netfilter: Clean up tests if NULL returned on failure

[Jan Engelhardt]

On Tuesday 2017-03-28 15:13, simran singhal wrote:

>Some functions like kmalloc/kzalloc return NULL on failure. When NULL
>represents failure, !x is commonly used.
>
>@@ -910,7 +910,7 @@ ip_vs_new_dest(struct ip_vs_service *svc, struct 
>ip_vs_dest_user_kern *udest,
>   }
> 
>   dest = kzalloc(sizeof(struct ip_vs_dest), GFP_KERNEL);
>-  if (dest == NULL)
>+  if (!dest)
>   return -ENOMEM;

This kind of transformation however is not cleanup anymore, it's really 
bikeshedding and should be avoided. There are pro and cons for both 
variants, and there is not really an overwhelming number of arguments 
for either variant to justify the change.

Re: [PATCH] netfilter: ipset: Use max macro instead of ternary operator

[Jan Engelhardt]

On Tuesday 2017-03-28 15:32, simran singhal wrote:

>This patch replaces ternary operator with macro max as it shorter and
>thus increases code readability.
>
>-  return (ret < 0 ? 0 : ret);
>+  return max(0, ret);

While the two are functionally equivalent, "max" conveys a meaning of 
"upper bound" (think ceil(3)), i.e. a _count of something_, but the 
function still returns a logical "error or bool".

Such a change may be usable in an IOCCC or a codegolf contest,
but it destroys rather than improves readability IMHO.

Re: [PATCH v2] netfilter: Clean up tests if NULL returned on failure

[Jan Engelhardt]

On Tuesday 2017-03-28 15:13, simran singhal wrote:

>Some functions like kmalloc/kzalloc return NULL on failure. When NULL
>represents failure, !x is commonly used.
>
>@@ -910,7 +910,7 @@ ip_vs_new_dest(struct ip_vs_service *svc, struct 
>ip_vs_dest_user_kern *udest,
>   }
> 
>   dest = kzalloc(sizeof(struct ip_vs_dest), GFP_KERNEL);
>-  if (dest == NULL)
>+  if (!dest)
>   return -ENOMEM;

This kind of transformation however is not cleanup anymore, it's really 
bikeshedding and should be avoided. There are pro and cons for both 
variants, and there is not really an overwhelming number of arguments 
for either variant to justify the change.

Re: [PATCH] netfilter: ipset: Use max macro instead of ternary operator

[Jan Engelhardt]

On Tuesday 2017-03-28 15:32, simran singhal wrote:

>This patch replaces ternary operator with macro max as it shorter and
>thus increases code readability.
>
>-  return (ret < 0 ? 0 : ret);
>+  return max(0, ret);

While the two are functionally equivalent, "max" conveys a meaning of 
"upper bound" (think ceil(3)), i.e. a _count of something_, but the 
function still returns a logical "error or bool".

Such a change may be usable in an IOCCC or a codegolf contest,
but it destroys rather than improves readability IMHO.

Re: [PATCH] net: Remove unnecessary cast on void pointer

[Jan Engelhardt]

On Tuesday 2017-03-28 14:50, simran singhal wrote:

>The following Coccinelle script was used to detect this:
>@r@
>expression x;
>void* e;
>type T;
>identifier f;
>@@
>(
>  *((T *)e)
>|
>  ((T *)x)[...]
>|
>  ((T*)x)->f
>|
>
>- (T*)
>  e
>)
>
>Signed-off-by: simran singhal 
>---
> net/bridge/netfilter/ebtables.c |  2 +-
> net/ipv4/netfilter/arp_tables.c | 20 
> net/ipv4/netfilter/ip_tables.c  | 20 
> net/ipv6/netfilter/ip6_tables.c | 20 
> net/netfilter/ipset/ip_set_bitmap_gen.h |  4 ++--
> net/netfilter/ipset/ip_set_core.c   |  2 +-
> net/netfilter/nf_conntrack_proto.c  |  2 +-
> net/netfilter/nft_set_hash.c|  2 +-
> net/netfilter/xt_hashlimit.c| 10 +-
> 9 files changed, 35 insertions(+), 47 deletions(-)
>
>diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
>index 79b6991..bdc629e 100644
>--- a/net/bridge/netfilter/ebtables.c
>+++ b/net/bridge/netfilter/ebtables.c
>@@ -1713,7 +1713,7 @@ static int compat_copy_entry_to_user(struct ebt_entry 
>*e, void __user **dstptr,
>   if (*size < sizeof(*ce))
>   return -EINVAL;
> 
>-  ce = (struct ebt_entry __user *)*dstptr;
>+  ce = *dstptr;
>   if (copy_to_user(ce, e, sizeof(*ce)))
>   return -EFAULT;
> 
>diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c
>index 6241a81..f046c12 100644
>--- a/net/ipv4/netfilter/arp_tables.c
>+++ b/net/ipv4/netfilter/arp_tables.c
>@@ -310,7 +310,7 @@ static int mark_source_chains(const struct xt_table_info 
>*newinfo,
>   for (hook = 0; hook < NF_ARP_NUMHOOKS; hook++) {
>   unsigned int pos = newinfo->hook_entry[hook];
>   struct arpt_entry *e
>-  = (struct arpt_entry *)(entry0 + pos);
>+  = (entry0 + pos);

At this point you can also drop the now-unnecessary parentheses in all 
the lines you changed.

Re: [PATCH] net: Remove unnecessary cast on void pointer

[Jan Engelhardt]

On Tuesday 2017-03-28 14:50, simran singhal wrote:

>The following Coccinelle script was used to detect this:
>@r@
>expression x;
>void* e;
>type T;
>identifier f;
>@@
>(
>  *((T *)e)
>|
>  ((T *)x)[...]
>|
>  ((T*)x)->f
>|
>
>- (T*)
>  e
>)
>
>Signed-off-by: simran singhal 
>---
> net/bridge/netfilter/ebtables.c |  2 +-
> net/ipv4/netfilter/arp_tables.c | 20 
> net/ipv4/netfilter/ip_tables.c  | 20 
> net/ipv6/netfilter/ip6_tables.c | 20 
> net/netfilter/ipset/ip_set_bitmap_gen.h |  4 ++--
> net/netfilter/ipset/ip_set_core.c   |  2 +-
> net/netfilter/nf_conntrack_proto.c  |  2 +-
> net/netfilter/nft_set_hash.c|  2 +-
> net/netfilter/xt_hashlimit.c| 10 +-
> 9 files changed, 35 insertions(+), 47 deletions(-)
>
>diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
>index 79b6991..bdc629e 100644
>--- a/net/bridge/netfilter/ebtables.c
>+++ b/net/bridge/netfilter/ebtables.c
>@@ -1713,7 +1713,7 @@ static int compat_copy_entry_to_user(struct ebt_entry 
>*e, void __user **dstptr,
>   if (*size < sizeof(*ce))
>   return -EINVAL;
> 
>-  ce = (struct ebt_entry __user *)*dstptr;
>+  ce = *dstptr;
>   if (copy_to_user(ce, e, sizeof(*ce)))
>   return -EFAULT;
> 
>diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c
>index 6241a81..f046c12 100644
>--- a/net/ipv4/netfilter/arp_tables.c
>+++ b/net/ipv4/netfilter/arp_tables.c
>@@ -310,7 +310,7 @@ static int mark_source_chains(const struct xt_table_info 
>*newinfo,
>   for (hook = 0; hook < NF_ARP_NUMHOOKS; hook++) {
>   unsigned int pos = newinfo->hook_entry[hook];
>   struct arpt_entry *e
>-  = (struct arpt_entry *)(entry0 + pos);
>+  = (entry0 + pos);

At this point you can also drop the now-unnecessary parentheses in all 
the lines you changed.

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Jan Engelhardt]

On Monday 2017-01-23 18:26, Borislav Petkov wrote:

>On Mon, Jan 23, 2017 at 09:21:03AM -0800, Christoph Hellwig wrote:
>> Or keep the exported version as-is and never changed it, and use
>> a different copy for the kernel itself.
>
>I guess we'll have to do that if something in userspace has put its
>sticky fingers on that file and cannot be fixed. Which I hardly doubt
>but we can't break that damn userspace.

The importance of uapi headers presence is a bit overrated.

If you look at, for example, iptables (and further projects in that 
area), copies of uapi headers have been made (and this process is likely 
to continue) because it could be compiled on a variety of vintage 
systems that do not have all required #defines yet.

Similarly, it may be built on a variety of _modern_ systems whose 
kernels no longer have a particular thing (e.g. ipt_SAME), so it also 
ships copies of those headers.

So if some userspace component depends on that particular msr header (which,
unlike ipt_SAME, was not intended for export), is it not reasonable to expect
them to make a copy if and when they need it?

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

[Jan Engelhardt]

On Monday 2017-01-23 18:26, Borislav Petkov wrote:

>On Mon, Jan 23, 2017 at 09:21:03AM -0800, Christoph Hellwig wrote:
>> Or keep the exported version as-is and never changed it, and use
>> a different copy for the kernel itself.
>
>I guess we'll have to do that if something in userspace has put its
>sticky fingers on that file and cannot be fixed. Which I hardly doubt
>but we can't break that damn userspace.

The importance of uapi headers presence is a bit overrated.

If you look at, for example, iptables (and further projects in that 
area), copies of uapi headers have been made (and this process is likely 
to continue) because it could be compiled on a variety of vintage 
systems that do not have all required #defines yet.

Similarly, it may be built on a variety of _modern_ systems whose 
kernels no longer have a particular thing (e.g. ipt_SAME), so it also 
ships copies of those headers.

So if some userspace component depends on that particular msr header (which,
unlike ipt_SAME, was not intended for export), is it not reasonable to expect
them to make a copy if and when they need it?

Re: [PATCH v2 7/7] uapi: export all headers under uapi directories

[Jan Engelhardt]

On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote:

>Le 09/01/2017 à 13:56, Christoph Hellwig a écrit :
>> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
>>> Regularly, when a new header is created in include/uapi/, the developer
>>> forgets to add it in the corresponding Kbuild file. This error is usually
>>> detected after the release is out.
>>>
>>> In fact, all headers under uapi directories should be exported, thus it's
>>> useless to have an exhaustive list.
>>>
>>> After this patch, the following files, which were not exported, are now
>>> exported (with make headers_install_all):
>> 
>> ... snip ...
>> 
>>> linux/genwqe/.install
>>> linux/genwqe/..install.cmd
>>> linux/cifs/.install
>>> linux/cifs/..install.cmd
>> 
>> I'm pretty sure these should not be exported!
>> 
>Those files are created in every directory:
>$ find usr/include/ -name '\.\.install.cmd' | wc -l
>71

That still does not mean they should be exported.

Anything but headers (and directories as a skeleton structure) is maximally 
suspicious.

Re: [PATCH v2 7/7] uapi: export all headers under uapi directories

[Jan Engelhardt]

On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote:

>Le 09/01/2017 à 13:56, Christoph Hellwig a écrit :
>> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
>>> Regularly, when a new header is created in include/uapi/, the developer
>>> forgets to add it in the corresponding Kbuild file. This error is usually
>>> detected after the release is out.
>>>
>>> In fact, all headers under uapi directories should be exported, thus it's
>>> useless to have an exhaustive list.
>>>
>>> After this patch, the following files, which were not exported, are now
>>> exported (with make headers_install_all):
>> 
>> ... snip ...
>> 
>>> linux/genwqe/.install
>>> linux/genwqe/..install.cmd
>>> linux/cifs/.install
>>> linux/cifs/..install.cmd
>> 
>> I'm pretty sure these should not be exported!
>> 
>Those files are created in every directory:
>$ find usr/include/ -name '\.\.install.cmd' | wc -l
>71

That still does not mean they should be exported.

Anything but headers (and directories as a skeleton structure) is maximally 
suspicious.

Re: [PATCH 1116/1285] Replace numeric parameter like 0444 with macro

[Jan Engelhardt]

On Tuesday 2016-08-02 14:17, Baole Ni wrote:

>I find that the developers often just specified the numeric value
>when calling a macro which is defined with a parameter for access permission.
>As we know, these numeric value for access permission have had the 
>corresponding macro,
>and that using macro can improve the robustness and readability of the code,
>thus, I suggest replacing the numeric parameter with the macro.
>
> static int ip_vs_conn_tab_bits = CONFIG_IP_VS_TAB_BITS;
>-module_param_named(conn_tab_bits, ip_vs_conn_tab_bits, int, 0444);
>+module_param_named(conn_tab_bits, ip_vs_conn_tab_bits, int, S_IRUSR | S_IRGRP 
>| S_IROTH);

We have S_IRUGO for this.

Re: [PATCH 1116/1285] Replace numeric parameter like 0444 with macro

[Jan Engelhardt]

On Tuesday 2016-08-02 14:17, Baole Ni wrote:

>I find that the developers often just specified the numeric value
>when calling a macro which is defined with a parameter for access permission.
>As we know, these numeric value for access permission have had the 
>corresponding macro,
>and that using macro can improve the robustness and readability of the code,
>thus, I suggest replacing the numeric parameter with the macro.
>
> static int ip_vs_conn_tab_bits = CONFIG_IP_VS_TAB_BITS;
>-module_param_named(conn_tab_bits, ip_vs_conn_tab_bits, int, 0444);
>+module_param_named(conn_tab_bits, ip_vs_conn_tab_bits, int, S_IRUSR | S_IRGRP 
>| S_IROTH);

We have S_IRUGO for this.

RE: [PATCH 9/9] netfilter: implement xt_cgroup cgroup2 path match

[Jan Engelhardt]

On Monday 2015-11-23 18:35, David Laight wrote:
>From: Florian Westphal
>> Sent: 21 November 2015 16:56
>> > +struct xt_cgroup_info_v1 {
>> > +  charpath[PATH_MAX];
>> > +  __u32   classid;
>> > +
>> > +  /* kernel internal data */
>> > +  void*priv __attribute__((aligned(8)));
>> > +};
>> 
>> Ahem.  Am I reading this right? This struct is > 4k in size?
>> If so -- Ugh.  Does sizeof(path) really have to be PATH_MAX?
>
>I've not looked at the use, but could you put 'char path[];'
>as the last member an require any allocations to be long enough
>to contain the actual path?

Oh, smart :)  Yeah, ebt_among does something like that.
(.matchsize = -1, hint)

Except that the "priv" pointer seems to be ruining the fun here -
kernel vars have to be last, which collides with the requirements
for []-type members.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 9/9] netfilter: implement xt_cgroup cgroup2 path match

[Jan Engelhardt]

On Monday 2015-11-23 18:35, David Laight wrote:
>From: Florian Westphal
>> Sent: 21 November 2015 16:56
>> > +struct xt_cgroup_info_v1 {
>> > +  charpath[PATH_MAX];
>> > +  __u32   classid;
>> > +
>> > +  /* kernel internal data */
>> > +  void*priv __attribute__((aligned(8)));
>> > +};
>> 
>> Ahem.  Am I reading this right? This struct is > 4k in size?
>> If so -- Ugh.  Does sizeof(path) really have to be PATH_MAX?
>
>I've not looked at the use, but could you put 'char path[];'
>as the last member an require any allocations to be long enough
>to contain the actual path?

Oh, smart :)  Yeah, ebt_among does something like that.
(.matchsize = -1, hint)

Except that the "priv" pointer seems to be ruining the fun here -
kernel vars have to be last, which collides with the requirements
for []-type members.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 9/9] netfilter: implement xt_cgroup cgroup2 path match

[Jan Engelhardt]

On Saturday 2015-11-21 19:54, Florian Westphal wrote:
>
>The only other question I have is wheter PATH_MAX might be a possible
>ABI breaker in future.  It would have to be guaranteed that this is the
>same size forever, else you'd get strange errors on rule insertion if
>the sizes of the kernel and userspace version differs.
>
The same goes for IFNAMSIZ. But, so far, nobody changed it in the kernel,
even though there are voices that 15 characters + '\0' were a tight choice.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 9/9] netfilter: implement xt_cgroup cgroup2 path match

[Jan Engelhardt]

On Saturday 2015-11-21 19:54, Florian Westphal wrote:
>
>The only other question I have is wheter PATH_MAX might be a possible
>ABI breaker in future.  It would have to be guaranteed that this is the
>same size forever, else you'd get strange errors on rule insertion if
>the sizes of the kernel and userspace version differs.
>
The same goes for IFNAMSIZ. But, so far, nobody changed it in the kernel,
even though there are voices that 15 characters + '\0' were a tight choice.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH iptables] libxt_cgroup2: add support for cgroup2 path matching

[Jan Engelhardt]

On Tuesday 2015-11-17 20:42, Tejun Heo wrote:
>+static void cgroup2_save(const void *ip, const struct xt_entry_match *match)
>+{
>+  const struct xt_cgroup2_info *info = (void *)match->data;
>+
>+  printf("%s --path %s", info->invert ? " !" : "", info->path);
>+}

Can cgroup path names contain anything fancy, like spaces, backslashes, etc.?
If so, xtables_save_string() will be needed here.

>+static struct xtables_match cgroup2_match = {
>+  .family = NFPROTO_UNSPEC,
>+  .name   = "cgroup2",
>+  .version= XTABLES_VERSION,
>+  .size   = XT_ALIGN(sizeof(struct xt_cgroup2_info)),
>+  .userspacesize  = XT_ALIGN(sizeof(struct xt_cgroup2_info)),

userspacesize must not include xt_cgroup2_info.priv.
Change to offsetof(...), cf. other .c modules which do this.


>+++ b/extensions/libxt_cgroup2.man
>@@ -0,0 +1,24 @@
>+.TP
>+[\fB!\fP] \fB\-\-path\fP \fIpath\fP
>+Match cgroup2 membership.
>+
>+Each socket is associated with the v2 cgroup of the creating process.
>+This matches packets coming from or going to all sockets in the
>+sub-hierarchy of the specified path.  The path should be relative to
>+the root of the cgroup2 hierarchy.  Can be used in the OUTPUT and
>+INPUT chains to assign particular firewall policies for aggregated
>+processes on the system. This allows for more fine-grained firewall
>+policies that only match for a subset of the system's processes.
>+
>+\fBIMPORTANT\fP: when being used in the INPUT chain, the cgroup2
>+matcher is currently only of limited functionality, meaning it
>+will only match on packets that are processed for local sockets
>+through early socket demuxing. Therefore, general usage on the
>+INPUT chain is disadviced unless the implications are well

is disadviced (sic)  -> is not advised
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] netfilter: implement xt_cgroup2 match

[Jan Engelhardt]

On Tuesday 2015-11-17 20:40, Tejun Heo wrote:
>@@ -0,0 +1,14 @@
>+#ifndef _XT_CGROUP2_H
>+#define _XT_CGROUP2_H
>+
>+#include 
>+
>+struct xt_cgroup2_info {
>+  charpath[PATH_MAX];
>+  __u8invert;

Should  be included? (For PATH_MAX)

>+  /* kernel internal data */
>+  void*priv;
>+};

void *priv __attribute__((aligned(8)));

>+static bool cgroup2_mt(const struct sk_buff *skb, struct xt_action_param *par)
>+{
>+  const struct xt_cgroup2_info *info = par->matchinfo;
>+  struct cgroup *ancestor = info->priv;

There is no modification planned on the cgroup, so this too can be const struct
cgroup * if-and-when cgroup_is_descendant is made to take const ptrs as well.

>+  if (!skb->sk || !sk_fullsock(skb->sk))
>+  return false;
>+
>+  return cgroup_is_descendant(skb->sk->sk_cgroup, ancestor) ^ 
>info->invert;
>+}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] cgroup: record ancestor IDs and reimplement cgroup_is_descendant() using it

[Jan Engelhardt]

On Tuesday 2015-11-17 20:40, Tejun Heo wrote:
>+static inline bool cgroup_is_descendant(struct cgroup *cgrp,
>+  struct cgroup *ancestor)

(const struct group *cgrp, const struct group *ancestor)

>+{
>+  if (cgrp->root != ancestor->root || cgrp->level < ancestor->level)
>+  return false;
>+  return cgrp->ancestor_ids[ancestor->level] == ancestor->id;
>+}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] kernfs: implement kernfs_walk_and_get()

[Jan Engelhardt]

On Tuesday 2015-11-17 22:20, David Miller wrote:
>> +static char path_buf[PATH_MAX]; /* protected by kernfs_mutex */
>> +int len = strlen(path);
> ...
>> +if (len >= PATH_MAX)
>> +return NULL;
>> +
>> +memcpy(path_buf, path, len + 1);
>
>   static char path_buf[PATH_MAX]; /* protected by kernfs_mutex */
>   int len = strlcpy(path_buf, path, PATH_MAX);
> ...
>   if (len >= PATH_MAX)
>   return NULL;

if (len < 0 || len >= PATH_MAX)

strlcpy returns a size_t, which, when coerced into an int, could lead to
negative numbers. In that sense, "size_t len" probably seems like an even
better bet yet.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] kernfs: implement kernfs_walk_and_get()

[Jan Engelhardt]

On Tuesday 2015-11-17 22:20, David Miller wrote:
>> +static char path_buf[PATH_MAX]; /* protected by kernfs_mutex */
>> +int len = strlen(path);
> ...
>> +if (len >= PATH_MAX)
>> +return NULL;
>> +
>> +memcpy(path_buf, path, len + 1);
>
>   static char path_buf[PATH_MAX]; /* protected by kernfs_mutex */
>   int len = strlcpy(path_buf, path, PATH_MAX);
> ...
>   if (len >= PATH_MAX)
>   return NULL;

if (len < 0 || len >= PATH_MAX)

strlcpy returns a size_t, which, when coerced into an int, could lead to
negative numbers. In that sense, "size_t len" probably seems like an even
better bet yet.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH iptables] libxt_cgroup2: add support for cgroup2 path matching

[Jan Engelhardt]

On Tuesday 2015-11-17 20:42, Tejun Heo wrote:
>+static void cgroup2_save(const void *ip, const struct xt_entry_match *match)
>+{
>+  const struct xt_cgroup2_info *info = (void *)match->data;
>+
>+  printf("%s --path %s", info->invert ? " !" : "", info->path);
>+}

Can cgroup path names contain anything fancy, like spaces, backslashes, etc.?
If so, xtables_save_string() will be needed here.

>+static struct xtables_match cgroup2_match = {
>+  .family = NFPROTO_UNSPEC,
>+  .name   = "cgroup2",
>+  .version= XTABLES_VERSION,
>+  .size   = XT_ALIGN(sizeof(struct xt_cgroup2_info)),
>+  .userspacesize  = XT_ALIGN(sizeof(struct xt_cgroup2_info)),

userspacesize must not include xt_cgroup2_info.priv.
Change to offsetof(...), cf. other .c modules which do this.


>+++ b/extensions/libxt_cgroup2.man
>@@ -0,0 +1,24 @@
>+.TP
>+[\fB!\fP] \fB\-\-path\fP \fIpath\fP
>+Match cgroup2 membership.
>+
>+Each socket is associated with the v2 cgroup of the creating process.
>+This matches packets coming from or going to all sockets in the
>+sub-hierarchy of the specified path.  The path should be relative to
>+the root of the cgroup2 hierarchy.  Can be used in the OUTPUT and
>+INPUT chains to assign particular firewall policies for aggregated
>+processes on the system. This allows for more fine-grained firewall
>+policies that only match for a subset of the system's processes.
>+
>+\fBIMPORTANT\fP: when being used in the INPUT chain, the cgroup2
>+matcher is currently only of limited functionality, meaning it
>+will only match on packets that are processed for local sockets
>+through early socket demuxing. Therefore, general usage on the
>+INPUT chain is disadviced unless the implications are well

is disadviced (sic)  -> is not advised
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] netfilter: implement xt_cgroup2 match

[Jan Engelhardt]

On Tuesday 2015-11-17 20:40, Tejun Heo wrote:
>@@ -0,0 +1,14 @@
>+#ifndef _XT_CGROUP2_H
>+#define _XT_CGROUP2_H
>+
>+#include 
>+
>+struct xt_cgroup2_info {
>+  charpath[PATH_MAX];
>+  __u8invert;

Should  be included? (For PATH_MAX)

>+  /* kernel internal data */
>+  void*priv;
>+};

void *priv __attribute__((aligned(8)));

>+static bool cgroup2_mt(const struct sk_buff *skb, struct xt_action_param *par)
>+{
>+  const struct xt_cgroup2_info *info = par->matchinfo;
>+  struct cgroup *ancestor = info->priv;

There is no modification planned on the cgroup, so this too can be const struct
cgroup * if-and-when cgroup_is_descendant is made to take const ptrs as well.

>+  if (!skb->sk || !sk_fullsock(skb->sk))
>+  return false;
>+
>+  return cgroup_is_descendant(skb->sk->sk_cgroup, ancestor) ^ 
>info->invert;
>+}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] cgroup: record ancestor IDs and reimplement cgroup_is_descendant() using it

[Jan Engelhardt]

On Tuesday 2015-11-17 20:40, Tejun Heo wrote:
>+static inline bool cgroup_is_descendant(struct cgroup *cgrp,
>+  struct cgroup *ancestor)

(const struct group *cgrp, const struct group *ancestor)

>+{
>+  if (cgrp->root != ancestor->root || cgrp->level < ancestor->level)
>+  return false;
>+  return cgrp->ancestor_ids[ancestor->level] == ancestor->id;
>+}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Retain all bits of the exit(2) status value

[Jan Engelhardt]

I was made aware of a suggested change to POSIX's exit function.
Current issue 7:
 http://pubs.opengroup.org/onlinepubs/9699919799/functions/exit.html
Proposed change:
 http://austingroupbugs.net/view.php?id=594#c1317
In summary:
 from "the least significant 8 bits (that is, status & 0377)"
 to "the full value shall be available from waitid()"

Now, Linux currently does a & 0xff in kernel/exit.c in the exit and 
exit_group syscalls. I would expect that the proposed change requires a 
new system call, and if so, what should its name be?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Retain all bits of the exit(2) status value

[Jan Engelhardt]

I was made aware of a suggested change to POSIX's exit function.
Current issue 7:
 http://pubs.opengroup.org/onlinepubs/9699919799/functions/exit.html
Proposed change:
 http://austingroupbugs.net/view.php?id=594#c1317
In summary:
 from the least significant 8 bits (that is, status  0377)
 to the full value shall be available from waitid()

Now, Linux currently does a  0xff in kernel/exit.c in the exit and 
exit_group syscalls. I would expect that the proposed change requires a 
new system call, and if so, what should its name be?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] kernel random segmentation fault?

[Jan Engelhardt]

On Wednesday 2015-05-06 05:46, long.wanglong wrote:
>
>int main(int argc, char** argv)
>{
>rlim.rlim_cur=20 MB;
>rlim.rlim_max=20 MB;
>ret = setrlimit(RLIMIT_AS, );
>[...]
>char tmp[20 MB];
>for (i = 0; i < 20 MB; i++)
>tmp[i]=1;

if tmp already takes 20 MB, where will the remainder of the program find
space if you only allow for 20 MB? This is bound to fail under normal
considerations.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] kernel random segmentation fault?

[Jan Engelhardt]

On Wednesday 2015-05-06 05:46, long.wanglong wrote:

int main(int argc, char** argv)
{
rlim.rlim_cur=20 MB;
rlim.rlim_max=20 MB;
ret = setrlimit(RLIMIT_AS, rlim);
[...]
char tmp[20 MB];
for (i = 0; i  20 MB; i++)
tmp[i]=1;

if tmp already takes 20 MB, where will the remainder of the program find
space if you only allow for 20 MB? This is bound to fail under normal
considerations.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL deref around blkmq in v4.0-rc1–rc7

[Jan Engelhardt]

On Saturday 2015-04-11 19:46, Linus Torvalds wrote:

>On Thu, Apr 9, 2015 at 5:07 PM, Linus Torvalds
> wrote:
>> On Thu, Apr 9, 2015 at 3:29 PM, Jan Engelhardt  wrote:
>>>
>>> Yes, this seems to solve it for me.
>>
>> Can you humor me, and try that patch on top of a few different kernel
>> versions that you had trouble with.
>
>Jan? I'm inclined to commit the patch for 4.0 even though it is late
>(it's not like it can hurt), but since you seem to be the only one
>seeing this issue, I'd really like you to double-check it..

Yeah, just commit. I'm currently "stuck" in the weekend.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL deref around blkmq in v4.0-rc1–rc7

[Jan Engelhardt]

On Saturday 2015-04-11 19:46, Linus Torvalds wrote:

On Thu, Apr 9, 2015 at 5:07 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Thu, Apr 9, 2015 at 3:29 PM, Jan Engelhardt jeng...@inai.de wrote:

 Yes, this seems to solve it for me.

 Can you humor me, and try that patch on top of a few different kernel
 versions that you had trouble with.

Jan? I'm inclined to commit the patch for 4.0 even though it is late
(it's not like it can hurt), but since you seem to be the only one
seeing this issue, I'd really like you to double-check it..

Yeah, just commit. I'm currently stuck in the weekend.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL deref around blkmq in v4.0-rc1–rc7

[Jan Engelhardt]

On Thursday 2015-04-09 19:38, Linus Torvalds wrote:
>>
>> I reran bisect just to be sure.
>> It now shows v4.0-rc1~9 is bad, v4.0-rc1~9^1 is ok, and v4.0-rc~9^2 is
>> ok too. So this means that the combination of the both ~9 childs work
>> badly together.
>
>Ok, that's just _odd_.
>[...]
>So I get the feeling that the oops you are seeing is likely not
>consistent, and may depend on allocation patterns or similar.

It's fairly consistent (reproducible?). Only 1 in 15 or so (have not kept track
really) attempts does it not die.

With frame pointers:
BUG: unable to handle kernel paging request at 1000
IP: [] scsi_init_cmd_errh+0x2a/0x62
PGD 0 
Oops: 0002 [#1] SMP 
Modules linked in: xfs crc32c_generic libcrc32c dm_crypt xts gf128mul 
algif_skcipher af_alg sd_mod mptsas scsi_transport_sas mptscsih mptbase dm_mod 
sg ipv6
CPU: 0 PID: 403 Comm: kworker/u2:1 Not tainted 4.0.0-rc7+ #55
Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
task: 88007b686f60 ti: 88007bcb4000 task.ti: 88007bcb4000
RIP: 0010:[]  [] 
scsi_init_cmd_errh+0x2a/0x62
RSP: 0018:88007bcb77a8  EFLAGS: 00010246
RAX:  RBX: 88007bf8d800 RCX: 0018
RDX: 88007bf7ab70 RSI:  RDI: 1000
RBP: 88007bcb77a8 R08: 88007beb9c40 R09: 
R10:  R11: ea0001fe17c0 R12: 88007bf7ab70
R13:  R14: 88007bf8d800 R15: 88007bf7aa00
FS:  () GS:88007fc0() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 1000 CR3: 7cb0d000 CR4: 07f0
Stack:
 88007bcb7818 81286d59 88007b686f60 88007bc24000
 88007bf7ab78 88007bf8d968 88007be56c00 88007bc24000
 88007cbfb400 88007bcb7850 88007be56c08 88007bf7aa00
Call Trace:
 [] scsi_queue_rq+0x2e8/0x3d2
 [] __blk_mq_run_hw_queue+0x19b/0x2a2
 [] ? blk_mq_merge_queue_io+0x75/0x147
 [] ? __xfs_get_blocks+0x2f9/0x2f9 [xfs]
 [] blk_mq_run_hw_queue+0x4f/0x99
 [] blk_sq_make_request+0x163/0x170
 [] generic_make_request+0x97/0xd6
 [] submit_bio+0x10d/0x12c
 [] ? __lru_cache_add+0x1e/0x3f
 [] mpage_bio_submit+0x25/0x2c
 [] mpage_readpages+0xf8/0x10c
 [] ? __xfs_get_blocks+0x2f9/0x2f9 [xfs]
 [] xfs_vm_readpages+0x18/0x1a [xfs]
 [] __do_page_cache_readahead+0x137/0x1d3
 [] ondemand_readahead+0x20a/0x21b
 [] page_cache_sync_readahead+0x38/0x3a
 [] generic_file_read_iter+0x191/0x4fb
 [] ? xfs_ilock+0x32/0x5d [xfs]
 [] xfs_file_read_iter+0x1c2/0x213 [xfs]
 [] new_sync_read+0x74/0x98
 [] __vfs_read+0x14/0x3b
 [] vfs_read+0x74/0xc1
 [] kernel_read+0x3c/0x4a
 [] prepare_binprm+0x117/0x11f
 [] do_execveat_common.isra.31+0x3b2/0x5d8
 [] do_execve+0x27/0x29
 [] call_usermodehelper+0x10a/0x138
 [] ? call_usermodehelper+0x49/0x49
 [] ret_from_fork+0x58/0x90
 [] ? call_usermodehelper+0x49/0x49
Code: c3 55 48 89 fa 48 c7 87 b0 00 00 00 00 00 00 00 c7 87 f4 00 00 00 00 00 
00 00 48 8b bf 10 01 00 00 31 c0 b9 18 00 00 00 48 89 e5  ab 66 83 ba cc 00 
00 00 00 75 2a 48 8b 8a d8 00 00 00 8a 01 
RIP  [] scsi_init_cmd_errh+0x2a/0x62
 RSP 
CR2: 1000
---[ end trace fbec0fe487830b1d ]---



>and %rdi is 0x1000. It seems to be simply
>
> memset(cmd->sense_buffer, 0, SCSI_SENSE_BUFFERSIZE);
>
>where 'cmd->sense_buffer' has some insane value ("PAGE_SIZE" or just a
>flipped bit, or whatever)

Having been observed on two isolated different systems, I don't
think so much that it would be a broken HW-induced bitflip.

Oh yeah, if anybody likes, I can hand out the virtualbox image.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL deref around blkmq in v4.0-rc1–rc7

[Jan Engelhardt]

On Thursday 2015-04-09 19:38, Linus Torvalds wrote:

 I reran bisect just to be sure.
 It now shows v4.0-rc1~9 is bad, v4.0-rc1~9^1 is ok, and v4.0-rc~9^2 is
 ok too. So this means that the combination of the both ~9 childs work
 badly together.

Ok, that's just _odd_.
[...]
So I get the feeling that the oops you are seeing is likely not
consistent, and may depend on allocation patterns or similar.

It's fairly consistent (reproducible?). Only 1 in 15 or so (have not kept track
really) attempts does it not die.

With frame pointers:
BUG: unable to handle kernel paging request at 1000
IP: [812853c9] scsi_init_cmd_errh+0x2a/0x62
PGD 0 
Oops: 0002 [#1] SMP 
Modules linked in: xfs crc32c_generic libcrc32c dm_crypt xts gf128mul 
algif_skcipher af_alg sd_mod mptsas scsi_transport_sas mptscsih mptbase dm_mod 
sg ipv6
CPU: 0 PID: 403 Comm: kworker/u2:1 Not tainted 4.0.0-rc7+ #55
Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
task: 88007b686f60 ti: 88007bcb4000 task.ti: 88007bcb4000
RIP: 0010:[812853c9]  [812853c9] 
scsi_init_cmd_errh+0x2a/0x62
RSP: 0018:88007bcb77a8  EFLAGS: 00010246
RAX:  RBX: 88007bf8d800 RCX: 0018
RDX: 88007bf7ab70 RSI:  RDI: 1000
RBP: 88007bcb77a8 R08: 88007beb9c40 R09: 
R10:  R11: ea0001fe17c0 R12: 88007bf7ab70
R13:  R14: 88007bf8d800 R15: 88007bf7aa00
FS:  () GS:88007fc0() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 1000 CR3: 7cb0d000 CR4: 07f0
Stack:
 88007bcb7818 81286d59 88007b686f60 88007bc24000
 88007bf7ab78 88007bf8d968 88007be56c00 88007bc24000
 88007cbfb400 88007bcb7850 88007be56c08 88007bf7aa00
Call Trace:
 [81286d59] scsi_queue_rq+0x2e8/0x3d2
 [8119e64d] __blk_mq_run_hw_queue+0x19b/0x2a2
 [8119e901] ? blk_mq_merge_queue_io+0x75/0x147
 [a00fa34a] ? __xfs_get_blocks+0x2f9/0x2f9 [xfs]
 [8119edeb] blk_mq_run_hw_queue+0x4f/0x99
 [8119fab9] blk_sq_make_request+0x163/0x170
 [81196a8b] generic_make_request+0x97/0xd6
 [81196bd7] submit_bio+0x10d/0x12c
 [810d5e15] ? __lru_cache_add+0x1e/0x3f
 [81142af5] mpage_bio_submit+0x25/0x2c
 [8114387d] mpage_readpages+0xf8/0x10c
 [a00fa34a] ? __xfs_get_blocks+0x2f9/0x2f9 [xfs]
 [a00f9c45] xfs_vm_readpages+0x18/0x1a [xfs]
 [810d4e5c] __do_page_cache_readahead+0x137/0x1d3
 [810d5102] ondemand_readahead+0x20a/0x21b
 [810d5262] page_cache_sync_readahead+0x38/0x3a
 [810cd1c5] generic_file_read_iter+0x191/0x4fb
 [a010b2cf] ? xfs_ilock+0x32/0x5d [xfs]
 [a01023c2] xfs_file_read_iter+0x1c2/0x213 [xfs]
 [81118e63] new_sync_read+0x74/0x98
 [81119aef] __vfs_read+0x14/0x3b
 [81119b8a] vfs_read+0x74/0xc1
 [8111d977] kernel_read+0x3c/0x4a
 [8111dbd2] prepare_binprm+0x117/0x11f
 [8111f10d] do_execveat_common.isra.31+0x3b2/0x5d8
 [8111f35a] do_execve+0x27/0x29
 [81050e07] call_usermodehelper+0x10a/0x138
 [81050cfd] ? call_usermodehelper+0x49/0x49
 [8133b3d8] ret_from_fork+0x58/0x90
 [81050cfd] ? call_usermodehelper+0x49/0x49
Code: c3 55 48 89 fa 48 c7 87 b0 00 00 00 00 00 00 00 c7 87 f4 00 00 00 00 00 
00 00 48 8b bf 10 01 00 00 31 c0 b9 18 00 00 00 48 89 e5 f3 ab 66 83 ba cc 00 
00 00 00 75 2a 48 8b 8a d8 00 00 00 8a 01 
RIP  [812853c9] scsi_init_cmd_errh+0x2a/0x62
 RSP 88007bcb77a8
CR2: 1000
---[ end trace fbec0fe487830b1d ]---



and %rdi is 0x1000. It seems to be simply

 memset(cmd-sense_buffer, 0, SCSI_SENSE_BUFFERSIZE);

where 'cmd-sense_buffer' has some insane value (PAGE_SIZE or just a
flipped bit, or whatever)

Having been observed on two isolated different systems, I don't
think so much that it would be a broken HW-induced bitflip.

Oh yeah, if anybody likes, I can hand out the virtualbox image.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL deref around xfs in v4.0-rc1–rc7

[Jan Engelhardt]

On Wednesday 2015-04-08 15:41, Jan Engelhardt wrote:

>Starting somewhere around v4.0-rc1 and persisting through commit 
>v4.0-rc7, there is a new NULL deference apparently happening in 
>conjunction with xfs. This inhibits this machine's booting,
>as xfs is used for the root filesystem.
>
>First bisection points at first-bad commit v4.0-rc1~8, and since that is 
>a merge commit, I'll be investigating some more hand-chosen commits (and 
>then people to Cc) as we speak.

I reran bisect just to be sure.
It now shows v4.0-rc1~9 is bad, v4.0-rc1~9^1 is ok, and v4.0-rc~9^2 is 
ok too. So this means that the combination of the both ~9 childs work
badly together.


# good: [2bfedd1d9f470506d98cb5662ced381c38225968] Merge branch 'for-linus' of 
git://git.kernel.dk/linux-block
git bisect good 2bfedd1d9f470506d98cb5662ced381c38225968
# bad: [cd50b70ccd5c87794ec28bfb87b7fba9961eb0ae] Merge tag 
'pm+acpi-3.20-rc1-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad cd50b70ccd5c87794ec28bfb87b7fba9961eb0ae
# good: [9d0de5a63a4a22abfd2bd70694a610d18350cf87] Merge branches 'acpi-ec', 
'acpi-soc', 'acpi-video' and 'acpi-resources'
git bisect good 9d0de5a63a4a22abfd2bd70694a610d18350cf87
# good: [67fadaa2768716209ee19a8b8bf05bc3ac399445] cpufreq: s3c: remove last 
use of resume_clocks callback
git bisect good 67fadaa2768716209ee19a8b8bf05bc3ac399445
# good: [70734a786acfd1998e47d40df19cba5c29469bdf] cpuidle: powernv: Avoid 
endianness conversions while parsing DT
git bisect good 70734a786acfd1998e47d40df19cba5c29469bdf
# good: [3466b547e37b988723dc93465b7cb06b4b1f731f] Merge branches 'pnp', 
'pm-cpuidle' and 'pm-cpufreq'
git bisect good 3466b547e37b988723dc93465b7cb06b4b1f731f
# first bad commit: [cd50b70ccd5c87794ec28bfb87b7fba9961eb0ae] Merge tag 
'pm+acpi-3.20-rc1-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
# good: [2bfedd1d9f470506d98cb5662ced381c38225968] Merge branch 'for-linus' of 
git://git.kernel.dk/linux-block
git bisect good 2bfedd1d9f470506d98cb5662ced381c38225968
# bad: [cd50b70ccd5c87794ec28bfb87b7fba9961eb0ae] Merge tag 
'pm+acpi-3.20-rc1-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad cd50b70ccd5c87794ec28bfb87b7fba9961eb0ae
# good: [9d0de5a63a4a22abfd2bd70694a610d18350cf87] Merge branches 'acpi-ec', 
'acpi-soc', 'acpi-video' and 'acpi-resources'
git bisect good 9d0de5a63a4a22abfd2bd70694a610d18350cf87
# good: [67fadaa2768716209ee19a8b8bf05bc3ac399445] cpufreq: s3c: remove last 
use of resume_clocks callback
git bisect good 67fadaa2768716209ee19a8b8bf05bc3ac399445
# good: [70734a786acfd1998e47d40df19cba5c29469bdf] cpuidle: powernv: Avoid 
endianness conversions while parsing DT
git bisect good 70734a786acfd1998e47d40df19cba5c29469bdf
# good: [3466b547e37b988723dc93465b7cb06b4b1f731f] Merge branches 'pnp', 
'pm-cpuidle' and 'pm-cpufreq'
git bisect good 3466b547e37b988723dc93465b7cb06b4b1f731f
# first bad commit: [cd50b70ccd5c87794ec28bfb87b7fba9961eb0ae] Merge tag 
'pm+acpi-3.20-rc1-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm



 BUG: unable to handle kernel paging request at 1000
 IP: [] scsi_init_cmd_errh+0x26/0x5d
 PGD 0 
 Oops: 0002 [#1] SMP 
 Modules linked in: xfs crc32c_generic libcrc32c dm_crypt xts gf128mul 
algif_skcipher af_alg sd_mod mptsas scsi_transport_sas mptscsih mptbase dm_mod 
sg ipv6
 CPU: 0 PID: 406 Comm: kworker/u2:0 Not tainted 3.19.0+ #53
 Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
 task: 88007bf73c60 ti: 88007cb2 task.ti: 88007cb2
 RIP: 0010:[]  [] 
scsi_init_cmd_errh+0x26/0x5d
 RSP: 0018:88007cb23870  EFLAGS: 00010246
 RAX:  RBX: 88007bfa6800 RCX: 0018
 RDX: 88007bfec970 RSI:  RDI: 1000
 RBP: 88007bfec970 R08: 88007be345c0 R09: 00fa
 R10: 0001 R11: ea0001ec8c40 R12: 
 R13: 88007bfa6800 R14: 88007bc04000 R15: 88007bfec800
 FS:  () GS:88007fc0() knlGS:
 CS:  0010 DS:  ES:  CR0: 8005003b
 CR2: 1000 CR3: 7bc9b000 CR4: 07f0
 Stack:
  8126b67a 88007bf73c60 88007bc04000 88007bf13400
  88007bfa6968 88007bfec978 88007fc18e48 88007bfb4f20
  88007cb23900 88007bf13408  
 Call Trace:
  [] ? scsi_queue_rq+0x2e5/0x3d3
  [] ? __blk_mq_run_hw_queue+0x19a/0x29f
  [] ? blk_mq_alloc_request+0xbc/0x102
  [] ? __xfs_get_blocks+0x321/0x321 [xfs]
  [] ? blk_mq_run_hw_queue+0x4a/0x93
  [] ? blk_sq_make_request+0x166/0x171
  [] ? generic_make_request+0x8f/0xcc
  [] ? submit_bio+0x103/0x121
  [] ? get_page+0x9/0x25
  [] ? __lru_cache_add+0x1a/0x3a
  [] ? mpage_bio_submit+0x1f/0x25
  [] ? mpage_readpages+0xe2/0xf6
  [] ? __xfs_get_blocks+0x321/0x321 [xfs]
  [] ? alloc_pages_current+0xad/0xca
  [] ? __do_pa

NULL deref around xfs in v4.0-rc1–rc7

[Jan Engelhardt]

Starting somewhere around v4.0-rc1 and persisting through commit 
v4.0-rc7, there is a new NULL deference apparently happening in 
conjunction with xfs. This inhibits this machine's booting,
as xfs is used for the root filesystem.

First bisection points at first-bad commit v4.0-rc1~8, and since that is 
a merge commit, I'll be investigating some more hand-chosen commits (and 
then people to Cc) as we speak.


Boot log of v4.0-rc1~8:

 Fusion MPT base driver 3.04.20
 Copyright (c) 1999-2008 LSI Corporation
 Fusion MPT SAS Host driver 3.04.20
 mptbase: ioc0: Initiating bringup
 ioc0: LSISAS1068 A0: Capabilities={Initiator}
 scsi host0: ioc0: LSISAS1068 A0, FwRev=h, Ports=8, MaxQ=256, IRQ=22
 mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 1, phy 1, sas_addr 
0x1060504030201a0
 scsi 0:0:0:0: Direct-Access VBOX HARDDISK 1.0  PQ: 0 ANSI: 5
 scsi 0:0:0:0: Attached scsi generic sg0 type 0
 mptbase: ioc1: Initiating bringup
 ioc1: LSISAS1068 A0: Capabilities={Initiator}
 scsi host1: ioc1: LSISAS1068 A0, FwRev=h, Ports=8, MaxQ=256, IRQ=17
 mptsas: ioc1: attaching ssp device: fw_channel 0, fw_id 0, phy 0, sas_addr 
0x60504030201a0
 scsi 1:0:0:0: Direct-Access VBOX HARDDISK 1.0  PQ: 0 ANSI: 5
 scsi 1:0:0:0: Attached scsi generic sg1 type 0
 sd 0:0:0:0: [sda] 12582912 512-byte logical blocks: (6.44 GB/6.00 GiB)
 sd 1:0:0:0: [sdb] 16777216 512-byte logical blocks: (8.58 GB/8.00 GiB)
 sd 0:0:0:0: [sda] Write Protect is off
 sd 0:0:0:0: [sda] Incomplete mode parameter data
 sd 0:0:0:0: [sda] Assuming drive cache: write through
 sd 1:0:0:0: [sdb] Write Protect is off
 sd 1:0:0:0: [sdb] Incomplete mode parameter data
 sd 1:0:0:0: [sdb] Assuming drive cache: write through
  sda: sda1 sda2
 sd 0:0:0:0: [sda] Attached SCSI disk
  sdb: sdb1 sdb2
 sd 1:0:0:0: [sdb] Attached SCSI disk
 audit: type=1130 audit(1428456646.877:11): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=systemd-vconsole-setup comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Please enter passphrase for disk HARDDISK (sfroot)! 
 NET: Registered protocol family 38
 audit_printk_skb: 3 callbacks suppressed
 audit: type=1130 audit(1428456653.677:13): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=systemd-cryptsetup@sfroot comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
 audit: type=1130 audit(1428456653.941:14): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=dracut-initqueue comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
 audit: type=1130 audit(1428456654.369:15): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=systemd-fsck@dev-mapper-sfroot comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
 SGI XFS with ACLs, security attributes, realtime, no debug enabled
 XFS (dm-0): Mounting V5 Filesystem
 XFS (dm-0): Ending clean mount
 audit: type=1130 audit(1428456654.705:16): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=initrd-parse-etc comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
 audit: type=1131 audit(1428456654.761:17): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=initrd-parse-etc comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
 audit: type=1130 audit(1428456655.077:18): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=dracut-pre-pivot comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
 audit: type=1130 audit(1428456655.157:19): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=systemd-ask-password-console comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
 audit: type=1131 audit(1428456655.417:20): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=systemd-ask-password-console comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
 audit: type=1130 audit(1428456655.437:21): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=initrd-cleanup comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
 audit: type=1131 audit(1428456655.453:22): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=initrd-cleanup comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
 systemd-journald[155]: Received SIGTERM from PID 1 (systemd).
 BUG: unable to handle kernel paging request at 1000
 IP: [] scsi_init_cmd_errh+0x26/0x5d
 PGD 0 
 Oops: 0002 [#1] SMP 
 Modules linked in: xfs crc32c_generic libcrc32c dm_crypt xts gf128mul 
algif_skcipher af_alg sd_mod mptsas scsi_transport_sas mptscsih mptbase dm_mod 
sg ipv6
 CPU: 0 PID: 447 Comm: systemd-cgroups Not tainted 4.0.0-rc1 #21
 Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
 task: 88007acceeb0 ti: 88007bcc task.ti: 88007bcc
 RIP: 

NULL deref around xfs in v4.0-rc1–rc7

[Jan Engelhardt]

Starting somewhere around v4.0-rc1 and persisting through commit 
v4.0-rc7, there is a new NULL deference apparently happening in 
conjunction with xfs. This inhibits this machine's booting,
as xfs is used for the root filesystem.

First bisection points at first-bad commit v4.0-rc1~8, and since that is 
a merge commit, I'll be investigating some more hand-chosen commits (and 
then people to Cc) as we speak.


Boot log of v4.0-rc1~8:

 Fusion MPT base driver 3.04.20
 Copyright (c) 1999-2008 LSI Corporation
 Fusion MPT SAS Host driver 3.04.20
 mptbase: ioc0: Initiating bringup
 ioc0: LSISAS1068 A0: Capabilities={Initiator}
 scsi host0: ioc0: LSISAS1068 A0, FwRev=h, Ports=8, MaxQ=256, IRQ=22
 mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 1, phy 1, sas_addr 
0x1060504030201a0
 scsi 0:0:0:0: Direct-Access VBOX HARDDISK 1.0  PQ: 0 ANSI: 5
 scsi 0:0:0:0: Attached scsi generic sg0 type 0
 mptbase: ioc1: Initiating bringup
 ioc1: LSISAS1068 A0: Capabilities={Initiator}
 scsi host1: ioc1: LSISAS1068 A0, FwRev=h, Ports=8, MaxQ=256, IRQ=17
 mptsas: ioc1: attaching ssp device: fw_channel 0, fw_id 0, phy 0, sas_addr 
0x60504030201a0
 scsi 1:0:0:0: Direct-Access VBOX HARDDISK 1.0  PQ: 0 ANSI: 5
 scsi 1:0:0:0: Attached scsi generic sg1 type 0
 sd 0:0:0:0: [sda] 12582912 512-byte logical blocks: (6.44 GB/6.00 GiB)
 sd 1:0:0:0: [sdb] 16777216 512-byte logical blocks: (8.58 GB/8.00 GiB)
 sd 0:0:0:0: [sda] Write Protect is off
 sd 0:0:0:0: [sda] Incomplete mode parameter data
 sd 0:0:0:0: [sda] Assuming drive cache: write through
 sd 1:0:0:0: [sdb] Write Protect is off
 sd 1:0:0:0: [sdb] Incomplete mode parameter data
 sd 1:0:0:0: [sdb] Assuming drive cache: write through
  sda: sda1 sda2
 sd 0:0:0:0: [sda] Attached SCSI disk
  sdb: sdb1 sdb2
 sd 1:0:0:0: [sdb] Attached SCSI disk
 audit: type=1130 audit(1428456646.877:11): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=systemd-vconsole-setup comm=systemd 
exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=success'
Please enter passphrase for disk HARDDISK (sfroot)! 
 NET: Registered protocol family 38
 audit_printk_skb: 3 callbacks suppressed
 audit: type=1130 audit(1428456653.677:13): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=systemd-cryptsetup@sfroot comm=systemd 
exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=success'
 audit: type=1130 audit(1428456653.941:14): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=dracut-initqueue comm=systemd 
exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=success'
 audit: type=1130 audit(1428456654.369:15): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=systemd-fsck@dev-mapper-sfroot comm=systemd 
exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=success'
 SGI XFS with ACLs, security attributes, realtime, no debug enabled
 XFS (dm-0): Mounting V5 Filesystem
 XFS (dm-0): Ending clean mount
 audit: type=1130 audit(1428456654.705:16): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=initrd-parse-etc comm=systemd 
exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=success'
 audit: type=1131 audit(1428456654.761:17): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=initrd-parse-etc comm=systemd 
exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=success'
 audit: type=1130 audit(1428456655.077:18): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=dracut-pre-pivot comm=systemd 
exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=success'
 audit: type=1130 audit(1428456655.157:19): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=systemd-ask-password-console comm=systemd 
exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=success'
 audit: type=1131 audit(1428456655.417:20): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=systemd-ask-password-console comm=systemd 
exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=success'
 audit: type=1130 audit(1428456655.437:21): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=initrd-cleanup comm=systemd 
exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=success'
 audit: type=1131 audit(1428456655.453:22): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=initrd-cleanup comm=systemd 
exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=success'
 systemd-journald[155]: Received SIGTERM from PID 1 (systemd).
 BUG: unable to handle kernel paging request at 1000
 IP: [812718d0] scsi_init_cmd_errh+0x26/0x5d
 PGD 0 
 Oops: 0002 [#1] SMP 
 Modules linked in: xfs crc32c_generic libcrc32c dm_crypt xts gf128mul 
algif_skcipher af_alg sd_mod mptsas scsi_transport_sas mptscsih mptbase dm_mod 
sg ipv6
 CPU: 0 PID: 447 Comm: systemd-cgroups Not tainted 4.0.0-rc1 #21
 Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
 task: 88007acceeb0 ti: 88007bcc task.ti: 88007bcc
 RIP: 0010:[812718d0]  

Re: NULL deref around xfs in v4.0-rc1–rc7

[Jan Engelhardt]

On Wednesday 2015-04-08 15:41, Jan Engelhardt wrote:

Starting somewhere around v4.0-rc1 and persisting through commit 
v4.0-rc7, there is a new NULL deference apparently happening in 
conjunction with xfs. This inhibits this machine's booting,
as xfs is used for the root filesystem.

First bisection points at first-bad commit v4.0-rc1~8, and since that is 
a merge commit, I'll be investigating some more hand-chosen commits (and 
then people to Cc) as we speak.

I reran bisect just to be sure.
It now shows v4.0-rc1~9 is bad, v4.0-rc1~9^1 is ok, and v4.0-rc~9^2 is 
ok too. So this means that the combination of the both ~9 childs work
badly together.


# good: [2bfedd1d9f470506d98cb5662ced381c38225968] Merge branch 'for-linus' of 
git://git.kernel.dk/linux-block
git bisect good 2bfedd1d9f470506d98cb5662ced381c38225968
# bad: [cd50b70ccd5c87794ec28bfb87b7fba9961eb0ae] Merge tag 
'pm+acpi-3.20-rc1-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad cd50b70ccd5c87794ec28bfb87b7fba9961eb0ae
# good: [9d0de5a63a4a22abfd2bd70694a610d18350cf87] Merge branches 'acpi-ec', 
'acpi-soc', 'acpi-video' and 'acpi-resources'
git bisect good 9d0de5a63a4a22abfd2bd70694a610d18350cf87
# good: [67fadaa2768716209ee19a8b8bf05bc3ac399445] cpufreq: s3c: remove last 
use of resume_clocks callback
git bisect good 67fadaa2768716209ee19a8b8bf05bc3ac399445
# good: [70734a786acfd1998e47d40df19cba5c29469bdf] cpuidle: powernv: Avoid 
endianness conversions while parsing DT
git bisect good 70734a786acfd1998e47d40df19cba5c29469bdf
# good: [3466b547e37b988723dc93465b7cb06b4b1f731f] Merge branches 'pnp', 
'pm-cpuidle' and 'pm-cpufreq'
git bisect good 3466b547e37b988723dc93465b7cb06b4b1f731f
# first bad commit: [cd50b70ccd5c87794ec28bfb87b7fba9961eb0ae] Merge tag 
'pm+acpi-3.20-rc1-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
# good: [2bfedd1d9f470506d98cb5662ced381c38225968] Merge branch 'for-linus' of 
git://git.kernel.dk/linux-block
git bisect good 2bfedd1d9f470506d98cb5662ced381c38225968
# bad: [cd50b70ccd5c87794ec28bfb87b7fba9961eb0ae] Merge tag 
'pm+acpi-3.20-rc1-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad cd50b70ccd5c87794ec28bfb87b7fba9961eb0ae
# good: [9d0de5a63a4a22abfd2bd70694a610d18350cf87] Merge branches 'acpi-ec', 
'acpi-soc', 'acpi-video' and 'acpi-resources'
git bisect good 9d0de5a63a4a22abfd2bd70694a610d18350cf87
# good: [67fadaa2768716209ee19a8b8bf05bc3ac399445] cpufreq: s3c: remove last 
use of resume_clocks callback
git bisect good 67fadaa2768716209ee19a8b8bf05bc3ac399445
# good: [70734a786acfd1998e47d40df19cba5c29469bdf] cpuidle: powernv: Avoid 
endianness conversions while parsing DT
git bisect good 70734a786acfd1998e47d40df19cba5c29469bdf
# good: [3466b547e37b988723dc93465b7cb06b4b1f731f] Merge branches 'pnp', 
'pm-cpuidle' and 'pm-cpufreq'
git bisect good 3466b547e37b988723dc93465b7cb06b4b1f731f
# first bad commit: [cd50b70ccd5c87794ec28bfb87b7fba9961eb0ae] Merge tag 
'pm+acpi-3.20-rc1-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm



 BUG: unable to handle kernel paging request at 1000
 IP: [81269d9e] scsi_init_cmd_errh+0x26/0x5d
 PGD 0 
 Oops: 0002 [#1] SMP 
 Modules linked in: xfs crc32c_generic libcrc32c dm_crypt xts gf128mul 
algif_skcipher af_alg sd_mod mptsas scsi_transport_sas mptscsih mptbase dm_mod 
sg ipv6
 CPU: 0 PID: 406 Comm: kworker/u2:0 Not tainted 3.19.0+ #53
 Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
 task: 88007bf73c60 ti: 88007cb2 task.ti: 88007cb2
 RIP: 0010:[81269d9e]  [81269d9e] 
scsi_init_cmd_errh+0x26/0x5d
 RSP: 0018:88007cb23870  EFLAGS: 00010246
 RAX:  RBX: 88007bfa6800 RCX: 0018
 RDX: 88007bfec970 RSI:  RDI: 1000
 RBP: 88007bfec970 R08: 88007be345c0 R09: 00fa
 R10: 0001 R11: ea0001ec8c40 R12: 
 R13: 88007bfa6800 R14: 88007bc04000 R15: 88007bfec800
 FS:  () GS:88007fc0() knlGS:
 CS:  0010 DS:  ES:  CR0: 8005003b
 CR2: 1000 CR3: 7bc9b000 CR4: 07f0
 Stack:
  8126b67a 88007bf73c60 88007bc04000 88007bf13400
  88007bfa6968 88007bfec978 88007fc18e48 88007bfb4f20
  88007cb23900 88007bf13408  
 Call Trace:
  [8126b67a] ? scsi_queue_rq+0x2e5/0x3d3
  [8118d840] ? __blk_mq_run_hw_queue+0x19a/0x29f
  [8118da01] ? blk_mq_alloc_request+0xbc/0x102
  [a00f974b] ? __xfs_get_blocks+0x321/0x321 [xfs]
  [8118df89] ? blk_mq_run_hw_queue+0x4a/0x93
  [8118ec07] ? blk_sq_make_request+0x166/0x171
  [8118639b] ? generic_make_request+0x8f/0xcc
  [811864db] ? submit_bio+0x103/0x121
  [810cc0ae] ? get_page+0x9/0x25
  [810cc49f

Re: [PATCH 43/45] include/uapi/linux/netfilter_bridge.h: include if.h

[Jan Engelhardt]

On Tuesday 2015-02-17 00:05, Mikko Rapeli wrote:

>Fixes userspace compilation errors like:
>
>error: field ‘in’ has incomplete type
>struct in_addr in;
> 
>+#include 

Patch 36/45 included linux/in.h instead of linux/if.h for addressing "in has 
incomplete
type". Should this be used here too?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 43/45] include/uapi/linux/netfilter_bridge.h: include if.h

[Jan Engelhardt]

On Tuesday 2015-02-17 00:05, Mikko Rapeli wrote:

Fixes userspace compilation errors like:

error: field ‘in’ has incomplete type
struct in_addr in;
 
+#include linux/if.h

Patch 36/45 included linux/in.h instead of linux/if.h for addressing in has 
incomplete
type. Should this be used here too?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] x_tables: Use also dev->ifalias for interface matching

[Jan Engelhardt]

On Monday 2015-01-12 17:04, Eric Dumazet wrote:
>
>iptables should have used ifindex [for interface matching],
>it[']s sad we allowed the substring match in first place.

How would you solve interface name wildcards with ifindices?
(They come in handy if you have something like lots of tun+/veth+
interfaces from openvpn/lxc.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] x_tables: Use also dev-ifalias for interface matching

[Jan Engelhardt]

On Monday 2015-01-12 17:04, Eric Dumazet wrote:

iptables should have used ifindex [for interface matching],
it[']s sad we allowed the substring match in first place.

How would you solve interface name wildcards with ifindices?
(They come in handy if you have something like lots of tun+/veth+
interfaces from openvpn/lxc.)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] x_tables: Factor out 16bit aligment ifname_compare()

[Jan Engelhardt]

On Sunday 2015-01-11 22:30, Richard Weinberger wrote:
 Perhaps this would be better as bool ifname_compare
>
>Anyway, I agree with Linus wrt. bool.
>https://lkml.org/lkml/2013/8/31/138

Had the function return "bool", it would have been obvious enough
what to do with its return type. A return type of "int" might have
hinted towards negative-is-error (in general) or strcmpish values
(functions doing string compare work).

Now that it returns "unsigned long", one is pressed to look at the 
function body (not bad per se, but it is a hump) for the return 
value's semantics.

Linus says bool is dangerous to the unsuspecting user — but so is
"volatile", microwave ovens, etc. If the kernel really cared for
entry-level coders, it would be written in something like MISRA C.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Bug at 3.19-rc3:mm/rmap.c:399

[Jan Engelhardt]

Preliminary report that Linux kernel 3.19-rc3 
[eb74926920cfa756087a82e0b081df837177cb95] gives a bug dump. When 
exiting JOSM (running on openjdk-1.7), the java process would sometimes 
get shot down. Last known good was v3.18.1.

I probably need to turn on some debuginfo… unless you 
beat me to bisecting it.


[x86_64]
[30585.603446] [ cut here ]
[30585.603469] kernel BUG at mm/rmap.c:399!
[30585.603483] invalid opcode:  [#1] PREEMPT SMP 
[30585.603502] Modules linked in: ctr ccm af_packet ip6t_REJECT 
nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipt_REJECT 
xt_tcpudp xt_owner xt_multiport xt_conntrack iptable_filter ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 
nf_nat nf_conntrack xt_mark iptable_mangle ip_tables x_tables sch_fq_codel ext4 
mbcache jbd2 cdc_acm hid_generic usbhid hid arc4 snd_hda_codec_realtek 
snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_controller 
snd_hda_codec snd_hwdep iwlmvm snd_pcm_oss snd_pcm mac80211 i915 snd_seq 
snd_seq_device i2c_algo_bit snd_timer drm_kms_helper x86_pkg_temp_thermal 
thinkpad_acpi intel_powerclamp e1000e iwlwifi snd_mixer_oss coretemp drm pcspkr 
xhci_pci i2c_i801 joydev nvram xhci_hcd ptp serio_raw intel_gtt cfg80211
[30585.603799]  i2c_core lpc_ich rtsx_pci snd pps_core agpgart thermal mfd_core 
shpchp tpm_tis soundcore wmi processor video tpm battery led_class thermal_sys 
ac button intel_smartconnect hwmon binfmt_misc efivarfs dm_crypt algif_skcipher 
af_alg crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel 
aesni_intel glue_helper lrw ablk_helper cryptd ehci_pci ehci_hcd usbcore 
usb_common xts gf128mul aes_x86_64 dm_mod sg tcp_veno sony_laptop rfkill
[30585.603969] CPU: 2 PID: 12778 Comm: java Not tainted 3.19.0-rc3+ #16
[30585.603991] Hardware name: LENOVO 20AL00C6GE/20AL00C6GE, BIOS GIET67WW (2.17 
) 01/08/2014
[30585.604019] task: 8800d3955190 ti: 8801d2a8 task.ti: 
8801d2a8
[30585.604044] RIP: 0010:[]  [] 
unlink_anon_vmas+0xe9/0x140
[30585.604076] RSP: 0018:8801d2a83b88  EFLAGS: 00010286
[30585.604094] RAX: 8801ed517f50 RBX: 8801ed517f40 RCX: 8801ed517f60
[30585.604118] RDX: 0001 RSI:  RDI: 8800d3aa96e0
[30585.604141] RBP: 8801d2a83bc8 R08: 7f523d7be000 R09: ea0007b545c0
[30585.604165] R10: 000d R11: 00015b80 R12: 8800b10d49c0
[30585.604188] R13: 8800d3aa96e0 R14: 8800d3aa96e0 R15: 8801ed517f40
[30585.604212] FS:  () GS:88021e28() 
knlGS:
[30585.604238] CS:  0010 DS:  ES:  CR0: 80050033
[30585.604257] CR2: 7f524b9fa400 CR3: 02a13000 CR4: 001407e0
[30585.604285] DR0:  DR1:  DR2: 
[30585.604323] DR3:  DR6: fffe0ff0 DR7: 0400
[30585.604356] Stack:
[30585.604364]  88021390e900 8800b10d49d0 8801d2a83bc8 
8800b10d4958
[30585.604391]  8800b10d4958  7f51fd224000 
8800b10d4228
[30585.604419]  8801d2a83c18 810e7e65  
8801d2a83c28
[30585.604446] Call Trace:
[30585.604459]  [] free_pgtables+0x64/0x9d
[30585.604478]  [] exit_mmap+0x78/0x111
[30585.604498]  [] ? _raw_spin_unlock_irqrestore+0xe/0x22
[30585.604522]  [] mmput+0x56/0xed
[30585.604539]  [] do_exit+0x383/0x8cf
[30585.604558]  [] ? __dequeue_signal+0x1a/0x113
[30585.604578]  [] do_group_exit+0x3f/0x95
[30585.604597]  [] get_signal+0x469/0x49c
[30585.604617]  [] do_signal+0x23/0x691
[30585.604635]  [] ? path_put+0x1a/0x1e
[30585.604653]  [] do_notify_resume+0x27/0x5c
[30585.604673]  [] int_signal+0x12/0x17
[30585.604690] Code: 7e 08 e8 62 f4 f7 ff 49 8b 44 24 78 4c 8b 20 48 8d 58 f0 
49 83 ec 10 48 8d 43 10 48 39 45 c8 74 52 48 8b 7b 08 83 7f 34 00 74 02 <0f> 0b 
e8 d7 fd ff ff 48 8b 43 18 48 8b 53 10 48 89 df 48 89 42 
[30585.604805] RIP  [] unlink_anon_vmas+0xe9/0x140
[30585.604826]  RSP 
[30585.613469] ---[ end trace 7bc74b6fe917230a ]---
[30585.613471] Fixing recursive fault but reboot is needed!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Bug at 3.19-rc3:mm/rmap.c:399

[Jan Engelhardt]

Preliminary report that Linux kernel 3.19-rc3 
[eb74926920cfa756087a82e0b081df837177cb95] gives a bug dump. When 
exiting JOSM (running on openjdk-1.7), the java process would sometimes 
get shot down. Last known good was v3.18.1.

I probably need to turn on some debuginfo… unless you 
beat me to bisecting it.


[x86_64]
[30585.603446] [ cut here ]
[30585.603469] kernel BUG at mm/rmap.c:399!
[30585.603483] invalid opcode:  [#1] PREEMPT SMP 
[30585.603502] Modules linked in: ctr ccm af_packet ip6t_REJECT 
nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipt_REJECT 
xt_tcpudp xt_owner xt_multiport xt_conntrack iptable_filter ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 
nf_nat nf_conntrack xt_mark iptable_mangle ip_tables x_tables sch_fq_codel ext4 
mbcache jbd2 cdc_acm hid_generic usbhid hid arc4 snd_hda_codec_realtek 
snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_controller 
snd_hda_codec snd_hwdep iwlmvm snd_pcm_oss snd_pcm mac80211 i915 snd_seq 
snd_seq_device i2c_algo_bit snd_timer drm_kms_helper x86_pkg_temp_thermal 
thinkpad_acpi intel_powerclamp e1000e iwlwifi snd_mixer_oss coretemp drm pcspkr 
xhci_pci i2c_i801 joydev nvram xhci_hcd ptp serio_raw intel_gtt cfg80211
[30585.603799]  i2c_core lpc_ich rtsx_pci snd pps_core agpgart thermal mfd_core 
shpchp tpm_tis soundcore wmi processor video tpm battery led_class thermal_sys 
ac button intel_smartconnect hwmon binfmt_misc efivarfs dm_crypt algif_skcipher 
af_alg crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel 
aesni_intel glue_helper lrw ablk_helper cryptd ehci_pci ehci_hcd usbcore 
usb_common xts gf128mul aes_x86_64 dm_mod sg tcp_veno sony_laptop rfkill
[30585.603969] CPU: 2 PID: 12778 Comm: java Not tainted 3.19.0-rc3+ #16
[30585.603991] Hardware name: LENOVO 20AL00C6GE/20AL00C6GE, BIOS GIET67WW (2.17 
) 01/08/2014
[30585.604019] task: 8800d3955190 ti: 8801d2a8 task.ti: 
8801d2a8
[30585.604044] RIP: 0010:[810f2af7]  [810f2af7] 
unlink_anon_vmas+0xe9/0x140
[30585.604076] RSP: 0018:8801d2a83b88  EFLAGS: 00010286
[30585.604094] RAX: 8801ed517f50 RBX: 8801ed517f40 RCX: 8801ed517f60
[30585.604118] RDX: 0001 RSI:  RDI: 8800d3aa96e0
[30585.604141] RBP: 8801d2a83bc8 R08: 7f523d7be000 R09: ea0007b545c0
[30585.604165] R10: 000d R11: 00015b80 R12: 8800b10d49c0
[30585.604188] R13: 8800d3aa96e0 R14: 8800d3aa96e0 R15: 8801ed517f40
[30585.604212] FS:  () GS:88021e28() 
knlGS:
[30585.604238] CS:  0010 DS:  ES:  CR0: 80050033
[30585.604257] CR2: 7f524b9fa400 CR3: 02a13000 CR4: 001407e0
[30585.604285] DR0:  DR1:  DR2: 
[30585.604323] DR3:  DR6: fffe0ff0 DR7: 0400
[30585.604356] Stack:
[30585.604364]  88021390e900 8800b10d49d0 8801d2a83bc8 
8800b10d4958
[30585.604391]  8800b10d4958  7f51fd224000 
8800b10d4228
[30585.604419]  8801d2a83c18 810e7e65  
8801d2a83c28
[30585.604446] Call Trace:
[30585.604459]  [810e7e65] free_pgtables+0x64/0x9d
[30585.604478]  [810eea35] exit_mmap+0x78/0x111
[30585.604498]  [814078b5] ? _raw_spin_unlock_irqrestore+0xe/0x22
[30585.604522]  [8104381d] mmput+0x56/0xed
[30585.604539]  [81047c8c] do_exit+0x383/0x8cf
[30585.604558]  [8104ded8] ? __dequeue_signal+0x1a/0x113
[30585.604578]  [81048244] do_group_exit+0x3f/0x95
[30585.604597]  [8105050b] get_signal+0x469/0x49c
[30585.604617]  [810023b4] do_signal+0x23/0x691
[30585.604635]  [8111c2a4] ? path_put+0x1a/0x1e
[30585.604653]  [81002a49] do_notify_resume+0x27/0x5c
[30585.604673]  [814081cf] int_signal+0x12/0x17
[30585.604690] Code: 7e 08 e8 62 f4 f7 ff 49 8b 44 24 78 4c 8b 20 48 8d 58 f0 
49 83 ec 10 48 8d 43 10 48 39 45 c8 74 52 48 8b 7b 08 83 7f 34 00 74 02 0f 0b 
e8 d7 fd ff ff 48 8b 43 18 48 8b 53 10 48 89 df 48 89 42 
[30585.604805] RIP  [810f2af7] unlink_anon_vmas+0xe9/0x140
[30585.604826]  RSP 8801d2a83b88
[30585.613469] ---[ end trace 7bc74b6fe917230a ]---
[30585.613471] Fixing recursive fault but reboot is needed!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] x_tables: Factor out 16bit aligment ifname_compare()

[Jan Engelhardt]

On Sunday 2015-01-11 22:30, Richard Weinberger wrote:
 Perhaps this would be better as bool ifname_compare

Anyway, I agree with Linus wrt. bool.
https://lkml.org/lkml/2013/8/31/138

Had the function return bool, it would have been obvious enough
what to do with its return type. A return type of int might have
hinted towards negative-is-error (in general) or strcmpish values
(functions doing string compare work).

Now that it returns unsigned long, one is pressed to look at the 
function body (not bad per se, but it is a hump) for the return 
value's semantics.

Linus says bool is dangerous to the unsuspecting user — but so is
volatile, microwave ovens, etc. If the kernel really cared for
entry-level coders, it would be written in something like MISRA C.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/1] module: Make wait module's refcount to zero procedure as async

[Jan Engelhardt]

On Monday 2013-09-16 05:47, Rusty Russell wrote:
>
>Here's what I've got in my pending-rebases tree.
>
>@@ -842,6 +818,11 @@ SYSCALL_DEFINE2(delete_module, const char __user *, 
>name_user,
>   return -EFAULT;
>   name[MODULE_NAME_LEN-1] = '\0';
> 
>+  if (!(flags & O_NONBLOCK)) {
>+  printk(KERN_WARNING
>+ "waiting module removal not supported: please upgrade");
>+  }
>+

This patch has come to my attention via the opensuse lists, where
a poster reported about this new user-visible message (it appears
in dmesg!) and rightfully asked: upgrade what component?

It's probably the userspace module loading utility, but it _really_
should say so. There's good room to read that message - a few months
into the future - as "upgrade your kernel" instead ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/1] module: Make wait module's refcount to zero procedure as async

[Jan Engelhardt]

On Monday 2013-09-16 05:47, Rusty Russell wrote:

Here's what I've got in my pending-rebases tree.

@@ -842,6 +818,11 @@ SYSCALL_DEFINE2(delete_module, const char __user *, 
name_user,
   return -EFAULT;
   name[MODULE_NAME_LEN-1] = '\0';
 
+  if (!(flags  O_NONBLOCK)) {
+  printk(KERN_WARNING
+ waiting module removal not supported: please upgrade);
+  }
+

This patch has come to my attention via the opensuse lists, where
a poster reported about this new user-visible message (it appears
in dmesg!) and rightfully asked: upgrade what component?

It's probably the userspace module loading utility, but it _really_
should say so. There's good room to read that message - a few months
into the future - as upgrade your kernel instead ;)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915: pipe state still does not match

[Jan Engelhardt]

On Friday 2013-11-29 11:48, Chris Wilson wrote:
>> What I could collect so far:
>
>Thanks, I broke the handling of cropped XvImages along the fast paths.
>It should be fixed by:
>
>commit fd007d9d465b9b3ddbbaf769931ec921a6f5ecb8
>Author: Chris Wilson 
>Date:   Thu Nov 28 21:13:33 2013 +
>
>sna/video: Correct handling of cropped images along packed fast path

I didn't manage to crash X within an hour, so that's commit is looking 
good.

The kernel error message for i915 pipe state however still appears -
namely, whenever the X server is terminating, including "reasonably
proper" terminations induced with sending SIGTERM to the X process.
Could it be that the i915 module does not handle sudden shutdowns
(which however can occur at any time) of the /dev/dri/cardN file
descriptor well enough?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915: pipe state still does not match

[Jan Engelhardt]

On Friday 2013-11-29 11:48, Chris Wilson wrote:
 What I could collect so far:

Thanks, I broke the handling of cropped XvImages along the fast paths.
It should be fixed by:

commit fd007d9d465b9b3ddbbaf769931ec921a6f5ecb8
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Thu Nov 28 21:13:33 2013 +

sna/video: Correct handling of cropped images along packed fast path

I didn't manage to crash X within an hour, so that's commit is looking 
good.

The kernel error message for i915 pipe state however still appears -
namely, whenever the X server is terminating, including reasonably
proper terminations induced with sending SIGTERM to the X process.
Could it be that the i915 module does not handle sudden shutdowns
(which however can occur at any time) of the /dev/dri/cardN file
descriptor well enough?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

i915: pipe state still does not match

[Jan Engelhardt]

Greetings.


Despite the i915/drm fixes added in v3.11.8, the X server still 
terminates due to some pipe state bug in 3.11.9.

I have a fb setup to span two crtcs in below's configuration,
and the kernel problem is easily triggerable for me by moving
an Xv window (such as by using mplayer) forth and back
between the two crtc.
The problem did not exist in 3.9.9.

> xrandr
Screen 0: minimum 320 x 200, current 1280 x 1624, maximum 32767 x 32767
LVDS1 connected primary 1024x600+0+1024 (normal left inverted right x axis y 
axis) 220mm x 129mm
   1024x600   60.0*+
   800x60060.3 56.2  
   640x48059.9  
VGA1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 
301mm
   1280x1024  60.0*+   75.0 72.0  
   1152x864   75.0  
   1024x768   75.1 70.1 60.0  
   832x62474.6  
   800x60072.2 75.0 60.3  
   640x48075.0 72.8 66.7 60.0  
   720x40070.1  
   640x35070.1  
VIRTUAL1 disconnected (normal left inverted right x axis y axis)



[drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.flags 
(expected 4, found 0)
[ cut here ]
WARNING: CPU: 1 PID: 714 at 
/home/abuild/rpmbuild/BUILD/kernel-desktop-3.11.9~jng20/linux-3.11/drivers/gpu/drm/i915/intel_display.c:8329
 check_crtc_state+0x637/0x6a5 [i915]()
pipe state doesn't match!
Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter 
ip6_tables ipt_REJECT xt_tcpudp xt_owner xt_multiport xt_conntrack 
iptable_filter af_packet ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 
cpufreq_conservative nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_mark 
iptable_mangle ip_tables x_tables snd_hda_codec_realtek uvcvideo videobuf2_core 
snd_hda_intel snd_hda_codec snd_hwdep videodev snd_pcm_oss snd_pcm 
videobuf2_vmalloc iTCO_wdt jme gpio_ich coretemp snd_seq snd_timer pcspkr 
jmb38x_ms videobuf2_memops iTCO_vendor_support sdhci_pci lpc_ich memstick 
i2c_i801 snd_seq_device mii sdhci joydev mfd_core snd_mixer_oss led_class 
mmc_core serio_raw ata_generic acpi_cpufreq battery snd mperf ac shpchp 
soundcore snd_page_alloc sg tcp_veno sony_laptop rfkill autofs4
 btrfs raid6_pq zlib_deflate xor libcrc32c sha256_generic cbc hid_generic 
usbhid hid uhci_hcd ata_piix i915 drm_kms_helper ehci_pci ehci_hcd drm usbcore 
usb_common i2c_algo_bit i2c_core video intel_agp intel_gtt agpgart button 
processor thermal_sys hwmon scsi_dh_emc scsi_dh_alua scsi_dh_rdac scsi_dh_hp_sw 
scsi_dh dm_snapshot dm_mirror dm_region_hash dm_log dm_crypt dm_mod xts 
gf128mul aes_x86_64
CPU: 1 PID: 714 Comm: X Tainted: GW3.11.9-jng20-desktop #1
Hardware name: Sony Corporation VPCM11M1E/VAIO, BIOS R0090Z4 01/23/2010
  8141925d 88003b5d1788 8103ba85
 a01a689b 880037462000 88003b5d17d8 88003b5d1800
 8800374626d0 8103bae1 a01e97bb 0018
Call Trace:
 [] dump_trace+0x8c/0x296
 [] show_stack_log_lvl+0x13e/0x14d
 [] show_stack+0x2f/0x31
 [] dump_stack+0x50/0x89
 [] warn_slowpath_common+0x74/0x89
 [] warn_slowpath_fmt+0x47/0x49
 [] check_crtc_state+0x637/0x6a5 [i915]
 [] intel_modeset_check_state+0x37e/0x604 [i915]
 [] intel_set_mode+0x1b/0x22 [i915]
 [] intel_crtc_set_config+0x612/0x789 [i915]
 [] drm_mode_set_config_internal+0x44/0xac [drm]
 [] drm_fb_helper_set_par+0x55/0x98 [drm_kms_helper]
 [] fb_set_var+0x250/0x33b
 [] fbcon_blank+0x75/0x1c0
 [] do_unblank_screen+0xca/0x136
 [] vt_ioctl+0x4d5/0xf28
 [] tty_ioctl+0x910/0x976
 [] vfs_ioctl+0x1b/0x28
 [] do_vfs_ioctl+0x32d/0x3e8
 [] SyS_ioctl+0x4e/0x7e
 [] system_call_fastpath+0x1a/0x1f
 [<7fe31322a1e7>] 0x7fe31322a1e6
---[ end trace 36d598c7e5fa5f63 ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

i915: pipe state still does not match

[Jan Engelhardt]

Greetings.


Despite the i915/drm fixes added in v3.11.8, the X server still 
terminates due to some pipe state bug in 3.11.9.

I have a fb setup to span two crtcs in below's configuration,
and the kernel problem is easily triggerable for me by moving
an Xv window (such as by using mplayer) forth and back
between the two crtc.
The problem did not exist in 3.9.9.

 xrandr
Screen 0: minimum 320 x 200, current 1280 x 1624, maximum 32767 x 32767
LVDS1 connected primary 1024x600+0+1024 (normal left inverted right x axis y 
axis) 220mm x 129mm
   1024x600   60.0*+
   800x60060.3 56.2  
   640x48059.9  
VGA1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 
301mm
   1280x1024  60.0*+   75.0 72.0  
   1152x864   75.0  
   1024x768   75.1 70.1 60.0  
   832x62474.6  
   800x60072.2 75.0 60.3  
   640x48075.0 72.8 66.7 60.0  
   720x40070.1  
   640x35070.1  
VIRTUAL1 disconnected (normal left inverted right x axis y axis)



[drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.flags 
(expected 4, found 0)
[ cut here ]
WARNING: CPU: 1 PID: 714 at 
/home/abuild/rpmbuild/BUILD/kernel-desktop-3.11.9~jng20/linux-3.11/drivers/gpu/drm/i915/intel_display.c:8329
 check_crtc_state+0x637/0x6a5 [i915]()
pipe state doesn't match!
Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter 
ip6_tables ipt_REJECT xt_tcpudp xt_owner xt_multiport xt_conntrack 
iptable_filter af_packet ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 
cpufreq_conservative nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_mark 
iptable_mangle ip_tables x_tables snd_hda_codec_realtek uvcvideo videobuf2_core 
snd_hda_intel snd_hda_codec snd_hwdep videodev snd_pcm_oss snd_pcm 
videobuf2_vmalloc iTCO_wdt jme gpio_ich coretemp snd_seq snd_timer pcspkr 
jmb38x_ms videobuf2_memops iTCO_vendor_support sdhci_pci lpc_ich memstick 
i2c_i801 snd_seq_device mii sdhci joydev mfd_core snd_mixer_oss led_class 
mmc_core serio_raw ata_generic acpi_cpufreq battery snd mperf ac shpchp 
soundcore snd_page_alloc sg tcp_veno sony_laptop rfkill autofs4
 btrfs raid6_pq zlib_deflate xor libcrc32c sha256_generic cbc hid_generic 
usbhid hid uhci_hcd ata_piix i915 drm_kms_helper ehci_pci ehci_hcd drm usbcore 
usb_common i2c_algo_bit i2c_core video intel_agp intel_gtt agpgart button 
processor thermal_sys hwmon scsi_dh_emc scsi_dh_alua scsi_dh_rdac scsi_dh_hp_sw 
scsi_dh dm_snapshot dm_mirror dm_region_hash dm_log dm_crypt dm_mod xts 
gf128mul aes_x86_64
CPU: 1 PID: 714 Comm: X Tainted: GW3.11.9-jng20-desktop #1
Hardware name: Sony Corporation VPCM11M1E/VAIO, BIOS R0090Z4 01/23/2010
  8141925d 88003b5d1788 8103ba85
 a01a689b 880037462000 88003b5d17d8 88003b5d1800
 8800374626d0 8103bae1 a01e97bb 0018
Call Trace:
 [810040d1] dump_trace+0x8c/0x296
 [81004419] show_stack_log_lvl+0x13e/0x14d
 [81005307] show_stack+0x2f/0x31
 [8141925d] dump_stack+0x50/0x89
 [8103ba85] warn_slowpath_common+0x74/0x89
 [8103bae1] warn_slowpath_fmt+0x47/0x49
 [a01a689b] check_crtc_state+0x637/0x6a5 [i915]
 [a01af812] intel_modeset_check_state+0x37e/0x604 [i915]
 [a01afaeb] intel_set_mode+0x1b/0x22 [i915]
 [a01b01e1] intel_crtc_set_config+0x612/0x789 [i915]
 [a00e56ab] drm_mode_set_config_internal+0x44/0xac [drm]
 [a014fea9] drm_fb_helper_set_par+0x55/0x98 [drm_kms_helper]
 [812583eb] fb_set_var+0x250/0x33b
 [812613a2] fbcon_blank+0x75/0x1c0
 [812c5b50] do_unblank_screen+0xca/0x136
 [812be1dc] vt_ioctl+0x4d5/0xf28
 [812b63db] tty_ioctl+0x910/0x976
 [8113461b] vfs_ioctl+0x1b/0x28
 [81134d37] do_vfs_ioctl+0x32d/0x3e8
 [81134e40] SyS_ioctl+0x4e/0x7e
 [814232ad] system_call_fastpath+0x1a/0x1f
 [7fe31322a1e7] 0x7fe31322a1e6
---[ end trace 36d598c7e5fa5f63 ]---
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.12 released .. and 4.0 plans?

[Jan Engelhardt]

On Monday 2013-11-04 01:10, Linus Torvalds wrote:
>
>Onto a totally different topic: we're getting to release numbers where
>I have to take off my socks to count that high again. I'm ok with
>3. [...] [4.0 "ok, after 3.19 (or whatever),"]

What would you do when the major number becomes such an unpleasant
highteen number? (That will be in ~64 years if you wrap after x.19.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.12 released .. and 4.0 plans?

[Jan Engelhardt]

On Monday 2013-11-04 01:10, Linus Torvalds wrote:

Onto a totally different topic: we're getting to release numbers where
I have to take off my socks to count that high again. I'm ok with
3.low teens [...] [4.0 ok, after 3.19 (or whatever),]

What would you do when the major number becomes such an unpleasant
highteen number? (That will be in ~64 years if you wrap after x.19.)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 11/12] netfilter: Remove extern from function prototypes

[Jan Engelhardt]

On Monday 2013-09-23 20:37, Joe Perches wrote:

>There are a mix of function prototypes with and without extern
>in the kernel sources.  Standardize on not using extern for
>function prototypes.
>
>Function prototypes don't need to be written with extern.
>extern is assumed by the compiler.  Its use is as unnecessary as
>using auto to declare automatic/local variables in a block.

Or you could just extern all functions for consistency with variables.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 11/12] netfilter: Remove extern from function prototypes

[Jan Engelhardt]

On Monday 2013-09-23 20:37, Joe Perches wrote:

There are a mix of function prototypes with and without extern
in the kernel sources.  Standardize on not using extern for
function prototypes.

Function prototypes don't need to be written with extern.
extern is assumed by the compiler.  Its use is as unnecessary as
using auto to declare automatic/local variables in a block.

Or you could just extern all functions for consistency with variables.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Introducing libgadget 0.0.1

[Jan Engelhardt]

On Wednesday 2013-09-04 19:25, Matt Porter wrote:

>With the move to configfs for creation of arbitrary USB composite gadgets,
>I found myself wanting a simple C library to configure and parse gadgets
>in a system. It has no other dependencies other than libc itself.
>
>It can be found at:
>
>   git://git.linaro.org/people/mporter/libgadget.git

Hm but there is already a libgadget (and not just one) if you query a 
particular search engine entitled Google :}

>$ mkdir /config
>$ mount -t configfs none /config

Do your tools support input of a different location?
(systemd mounts configfs at /sys/kernel/config.)

>$ gadget-acm-ecm
>$ show-gadgets
>ID 1d6b:0104 'g1'
>[...]

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Introducing libgadget 0.0.1

[Jan Engelhardt]

On Wednesday 2013-09-04 19:25, Matt Porter wrote:

With the move to configfs for creation of arbitrary USB composite gadgets,
I found myself wanting a simple C library to configure and parse gadgets
in a system. It has no other dependencies other than libc itself.

It can be found at:

   git://git.linaro.org/people/mporter/libgadget.git

Hm but there is already a libgadget (and not just one) if you query a 
particular search engine entitled Google :}

$ mkdir /config
$ mount -t configfs none /config

Do your tools support input of a different location?
(systemd mounts configfs at /sys/kernel/config.)

$ gadget-acm-ecm
$ show-gadgets
ID 1d6b:0104 'g1'
[...]

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

fixdep ought to be compiled with -D_FILE_OFFSET_BITS

[Jan Engelhardt]

Because fixdep is compiled without -D_FILE_OFFSET_BITS=64,
a 32-bit fixdep (in a chroot build root, for example) may fail to run
on a 64-bit host system if any file has an inode larger than 2^32,
which can easily happen (in my case, on xfs):


[ares07:~/rpmbuild/BUILD/kernel-pae-3.10.9~jng20/linux-obj]
$ make silentoldconfig -C $PWD/../linux-3.10 O=$PWD V=1

make: Entering directory 
`/home/abuild/rpmbuild/BUILD/kernel-pae-3.10.9~jng20/linux-3.10'
make -C /home/abuild/rpmbuild/BUILD/kernel-pae-3.10.9~jng20/linux-obj \
KBUILD_SRC=/home/abuild/rpmbuild/BUILD/kernel-pae-3.10.9~jng20/linux-3.10 \
KBUILD_EXTMOD="" -f 
/home/abuild/rpmbuild/BUILD/kernel-pae-3.10.9~jng20/linux-3.10/Makefile \
silentoldconfig
make -f 
/home/abuild/rpmbuild/BUILD/kernel-pae-3.10.9~jng20/linux-3.10/scripts/Makefile.build
 obj=scripts/basic
  gcc -Wp,-MD,scripts/basic/.fixdep.d -Iscripts/basic -Wall 
-Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -o 
scripts/basic/fixdep 
/home/abuild/rpmbuild/BUILD/kernel-pae-3.10.9~jng20/linux-3.10/scripts/basic/fixdep.c
  
fixdep: error fstat'ing depfile: scripts/basic/.fixdep.d: Value too large for 
defined data type
make[2]: *** [scripts/basic/fixdep] Error 2
make[1]: *** [scripts_basic] Error 2
make: *** [sub-make] Error 2
make: Leaving directory 
`/home/abuild/rpmbuild/BUILD/kernel-pae-3.10.9~jng20/linux-3.10'
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

fixdep ought to be compiled with -D_FILE_OFFSET_BITS

[Jan Engelhardt]

Because fixdep is compiled without -D_FILE_OFFSET_BITS=64,
a 32-bit fixdep (in a chroot build root, for example) may fail to run
on a 64-bit host system if any file has an inode larger than 2^32,
which can easily happen (in my case, on xfs):


[ares07:~/rpmbuild/BUILD/kernel-pae-3.10.9~jng20/linux-obj]
$ make silentoldconfig -C $PWD/../linux-3.10 O=$PWD V=1

make: Entering directory 
`/home/abuild/rpmbuild/BUILD/kernel-pae-3.10.9~jng20/linux-3.10'
make -C /home/abuild/rpmbuild/BUILD/kernel-pae-3.10.9~jng20/linux-obj \
KBUILD_SRC=/home/abuild/rpmbuild/BUILD/kernel-pae-3.10.9~jng20/linux-3.10 \
KBUILD_EXTMOD= -f 
/home/abuild/rpmbuild/BUILD/kernel-pae-3.10.9~jng20/linux-3.10/Makefile \
silentoldconfig
make -f 
/home/abuild/rpmbuild/BUILD/kernel-pae-3.10.9~jng20/linux-3.10/scripts/Makefile.build
 obj=scripts/basic
  gcc -Wp,-MD,scripts/basic/.fixdep.d -Iscripts/basic -Wall 
-Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -o 
scripts/basic/fixdep 
/home/abuild/rpmbuild/BUILD/kernel-pae-3.10.9~jng20/linux-3.10/scripts/basic/fixdep.c
  
fixdep: error fstat'ing depfile: scripts/basic/.fixdep.d: Value too large for 
defined data type
make[2]: *** [scripts/basic/fixdep] Error 2
make[1]: *** [scripts_basic] Error 2
make: *** [sub-make] Error 2
make: Leaving directory 
`/home/abuild/rpmbuild/BUILD/kernel-pae-3.10.9~jng20/linux-3.10'
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Potentially missing "else"

[Jan Engelhardt]

The following changes since commit 48a409644199d5efff6d966cd72ccc7f5a06c2a5:

  shell-completion: Make options accept '=' as last char (2013-08-02 12:07:39 
-0300)

are available in the git repository at:

  git://git.inai.de/kmod master

for you to fetch changes up to e4523541e7f26457cf7078d5f30e091d1b24e3a9:

  depmod: add missing "else" clause (2013-08-07 23:50:51 +0200)

--------
Jan Engelhardt (1):
  depmod: add missing "else" clause

 libkmod/libkmod-config.c | 2 +-
 tools/depmod.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] depmod: add missing "else" clause

[Jan Engelhardt]

It occurred to an openSUSE user that our mkinitrd would throw a
warning when used with kmod:

libkmod: conf_files_list: unsupported file mode /dev/null: 0x21b6

Grepping for the error message revealed that there might be a missing
"else" keyword here, since it is unusual to put an "if" directly after
closing brace.
---
 libkmod/libkmod-config.c | 2 +-
 tools/depmod.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libkmod/libkmod-config.c b/libkmod/libkmod-config.c
index 201c349..cb4cf61 100644
--- a/libkmod/libkmod-config.c
+++ b/libkmod/libkmod-config.c
@@ -833,7 +833,7 @@ static int conf_files_list(struct kmod_ctx *ctx, struct 
kmod_list **list,
if (S_ISREG(st.st_mode)) {
conf_files_insert_sorted(ctx, list, path, NULL);
return 0;
-   } if (!S_ISDIR(st.st_mode)) {
+   } else if (!S_ISDIR(st.st_mode)) {
ERR(ctx, "unsupported file mode %s: %#x\n",
path, st.st_mode);
return -EINVAL;
diff --git a/tools/depmod.c b/tools/depmod.c
index 4a02631..985cf3a 100644
--- a/tools/depmod.c
+++ b/tools/depmod.c
@@ -848,7 +848,7 @@ static int cfg_files_list(struct cfg_file ***p_files, 
size_t *p_n_files,
if (S_ISREG(st.st_mode)) {
cfg_files_insert_sorted(p_files, p_n_files, path, NULL);
return 0;
-   } if (!S_ISDIR(st.st_mode)) {
+   } else if (!S_ISDIR(st.st_mode)) {
ERR("unsupported file mode %s: %#x\n", path, st.st_mode);
return -EINVAL;
}
-- 
1.8.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Potentially missing else

[Jan Engelhardt]

The following changes since commit 48a409644199d5efff6d966cd72ccc7f5a06c2a5:

  shell-completion: Make options accept '=' as last char (2013-08-02 12:07:39 
-0300)

are available in the git repository at:

  git://git.inai.de/kmod master

for you to fetch changes up to e4523541e7f26457cf7078d5f30e091d1b24e3a9:

  depmod: add missing else clause (2013-08-07 23:50:51 +0200)


Jan Engelhardt (1):
  depmod: add missing else clause

 libkmod/libkmod-config.c | 2 +-
 tools/depmod.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] depmod: add missing else clause

[Jan Engelhardt]

It occurred to an openSUSE user that our mkinitrd would throw a
warning when used with kmod:

libkmod: conf_files_list: unsupported file mode /dev/null: 0x21b6

Grepping for the error message revealed that there might be a missing
else keyword here, since it is unusual to put an if directly after
closing brace.
---
 libkmod/libkmod-config.c | 2 +-
 tools/depmod.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libkmod/libkmod-config.c b/libkmod/libkmod-config.c
index 201c349..cb4cf61 100644
--- a/libkmod/libkmod-config.c
+++ b/libkmod/libkmod-config.c
@@ -833,7 +833,7 @@ static int conf_files_list(struct kmod_ctx *ctx, struct 
kmod_list **list,
if (S_ISREG(st.st_mode)) {
conf_files_insert_sorted(ctx, list, path, NULL);
return 0;
-   } if (!S_ISDIR(st.st_mode)) {
+   } else if (!S_ISDIR(st.st_mode)) {
ERR(ctx, unsupported file mode %s: %#x\n,
path, st.st_mode);
return -EINVAL;
diff --git a/tools/depmod.c b/tools/depmod.c
index 4a02631..985cf3a 100644
--- a/tools/depmod.c
+++ b/tools/depmod.c
@@ -848,7 +848,7 @@ static int cfg_files_list(struct cfg_file ***p_files, 
size_t *p_n_files,
if (S_ISREG(st.st_mode)) {
cfg_files_insert_sorted(p_files, p_n_files, path, NULL);
return 0;
-   } if (!S_ISDIR(st.st_mode)) {
+   } else if (!S_ISDIR(st.st_mode)) {
ERR(unsupported file mode %s: %#x\n, path, st.st_mode);
return -EINVAL;
}
-- 
1.8.2

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Read I/O starvation with writeback RAID controller

[Jan Engelhardt]

On Friday 2013-02-22 20:28, Martin Svec wrote:
>
> Yes, I've already tried the ROW scheduler. It helped for some low iodepths
> depending on quantum settings but generally didn't solve the problem. I think
> the key issue is that none of the schedulers can throttle I/O according to 
> e.g.
> average request roundtrip time. Shaohua Li is right here:
> https://lkml.org/lkml/2012/12/11/598 -- as long as there's free room in
> device's queue they blindly dispatch requests to it.
>
> Which is exactly what I see in deadline scheduler fifo queues: There're no 
> read
> requests to be scheduled between writes because all readers are starving. So
> the scheduler keeps dispatching writes using all the remaining capacity of
> device queue. Which in turn worses the read starvation. Bigger queue depth and
> bigger writeback cache means higher chance for read starvation even from a
> single writer.

Sounds just like the bufferbloat problem in networking.
Waiting for codel for the block layer  :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Announce] Checkpoint-restore tool v0.4

[Jan Engelhardt]

On Wednesday 2013-02-20 12:18, Pavel Emelyanov wrote:
>
>As was planned, the v0.4 of C/R tools is out, right after the Linux v3.8.
>
>The most valuable thing in this release, is that all the kernel patches
>we had are now merged, and thus what crtools-v0.4 can do will work on
>the upstream kernel (properly configured)!

I have trouble compiling that.


$ + make -j10 'CFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 
-fstack-protector -funwind-tables -fasynchronous-unwind-tables -g' V=1
gcc -M -MT arch/x86/crtools.d -MT arch/x86/crtools.o -fmessage-length=0 -O2 
-Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -g   arch/x86/crtools.c -o arch/x86/crtools.d
arch/x86/crtools.c:5:21: fatal error: asm/fpu.h: No such file or directory

fpu.h does not exist in /usr/include, nor does it exist in $linux/arch/x86/
or $linux/include. Apparently it does exist in crtools, but there are no
more flags pointing to crtools/include/. Which probably means you should
place mandatory CFLAGS not in CFLAGS, but your own variable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Announce] Checkpoint-restore tool v0.4

[Jan Engelhardt]

On Wednesday 2013-02-20 12:18, Pavel Emelyanov wrote:

As was planned, the v0.4 of C/R tools is out, right after the Linux v3.8.

The most valuable thing in this release, is that all the kernel patches
we had are now merged, and thus what crtools-v0.4 can do will work on
the upstream kernel (properly configured)!

I have trouble compiling that.


$ + make -j10 'CFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 
-fstack-protector -funwind-tables -fasynchronous-unwind-tables -g' V=1
gcc -M -MT arch/x86/crtools.d -MT arch/x86/crtools.o -fmessage-length=0 -O2 
-Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -g   arch/x86/crtools.c -o arch/x86/crtools.d
arch/x86/crtools.c:5:21: fatal error: asm/fpu.h: No such file or directory

fpu.h does not exist in /usr/include, nor does it exist in $linux/arch/x86/
or $linux/include. Apparently it does exist in crtools, but there are no
more flags pointing to crtools/include/. Which probably means you should
place mandatory CFLAGS not in CFLAGS, but your own variable.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Read I/O starvation with writeback RAID controller

[Jan Engelhardt]

On Friday 2013-02-22 20:28, Martin Svec wrote:

 Yes, I've already tried the ROW scheduler. It helped for some low iodepths
 depending on quantum settings but generally didn't solve the problem. I think
 the key issue is that none of the schedulers can throttle I/O according to 
 e.g.
 average request roundtrip time. Shaohua Li is right here:
 https://lkml.org/lkml/2012/12/11/598 -- as long as there's free room in
 device's queue they blindly dispatch requests to it.

 Which is exactly what I see in deadline scheduler fifo queues: There're no 
 read
 requests to be scheduled between writes because all readers are starving. So
 the scheduler keeps dispatching writes using all the remaining capacity of
 device queue. Which in turn worses the read starvation. Bigger queue depth and
 bigger writeback cache means higher chance for read starvation even from a
 single writer.

Sounds just like the bufferbloat problem in networking.
Waiting for codel for the block layer  :)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kconfig-frontends-3.8.0.0 release

[Jan Engelhardt]

On Wednesday 2013-02-20 00:21, Yann E. MORIN wrote:
>> This seems to install
>>  /usr/bin/diff[...]
>
>By default, the binaries should all ne prefixed with 'kconfig-' to avoid
>such name-clashing (as root, in a fresh debootstrap of squeeze here):

Aha. Seems I hit a peculiarity in rpmbuild. Problem solved, nothing to see. :)

$ grep -A5 -e '^%configure' /usr/lib/rpm/macros
%configure \
  CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \
  CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \
  FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \
  %{_configure} --host=%{_host} --build=%{_build} \\\
--program-prefix=%{?_program_prefix} \\\
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kconfig-frontends-3.8.0.0 release

[Jan Engelhardt]

On Tuesday 2013-02-19 23:14, Yann E. MORIN wrote:
>I'm pleased to announce the release of kconfig-frontends 3.8.0.0!
>Go download it there:
>
> http://ymorin.is-a-geek.org/download/kconfig-frontends/kconfig-frontends-3.8.0.0.tar.xz
>
> http://ymorin.is-a-geek.org/download/kconfig-frontends/kconfig-frontends-3.8.0.0.tar.bz2

This seems to install

/usr/bin/conf   
/usr/bin/diff   
/usr/bin/gettext
/usr/bin/merge
/usr/bin/tweak

Which conflicts quite hard with various preexisting system packages.

$ rpm -qf /usr/bin/diff
diffutils-3.2-2.1.2.x86_64
$ rpm -qf /usr/bin/gettext
gettext-runtime-0.18.1.1-15.2.2.x86_64
$ rpm -qf /usr/bin/merge
rcs-5.8-1011.1.2.x86_64

You need to give your binaries better names -- or a separate path
(like /usr/libexec/kconfig-frontends/{conf,diff,gettext,...} by
way of  pkglibexec_PROGRAMS = conf diff gettext...)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kconfig-frontends-3.8.0.0 release

[Jan Engelhardt]

On Tuesday 2013-02-19 23:14, Yann E. MORIN wrote:
I'm pleased to announce the release of kconfig-frontends 3.8.0.0!
Go download it there:

 http://ymorin.is-a-geek.org/download/kconfig-frontends/kconfig-frontends-3.8.0.0.tar.xz

 http://ymorin.is-a-geek.org/download/kconfig-frontends/kconfig-frontends-3.8.0.0.tar.bz2

This seems to install

/usr/bin/conf   
/usr/bin/diff   
/usr/bin/gettext
/usr/bin/merge
/usr/bin/tweak

Which conflicts quite hard with various preexisting system packages.

$ rpm -qf /usr/bin/diff
diffutils-3.2-2.1.2.x86_64
$ rpm -qf /usr/bin/gettext
gettext-runtime-0.18.1.1-15.2.2.x86_64
$ rpm -qf /usr/bin/merge
rcs-5.8-1011.1.2.x86_64

You need to give your binaries better names -- or a separate path
(like /usr/libexec/kconfig-frontends/{conf,diff,gettext,...} by
way of  pkglibexec_PROGRAMS = conf diff gettext...)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kconfig-frontends-3.8.0.0 release

[Jan Engelhardt]

On Wednesday 2013-02-20 00:21, Yann E. MORIN wrote:
 This seems to install
  /usr/bin/diff[...]

By default, the binaries should all ne prefixed with 'kconfig-' to avoid
such name-clashing (as root, in a fresh debootstrap of squeeze here):

Aha. Seems I hit a peculiarity in rpmbuild. Problem solved, nothing to see. :)

$ grep -A5 -e '^%configure' /usr/lib/rpm/macros
%configure \
  CFLAGS=${CFLAGS:-%optflags} ; export CFLAGS ; \
  CXXFLAGS=${CXXFLAGS:-%optflags} ; export CXXFLAGS ; \
  FFLAGS=${FFLAGS:-%optflags} ; export FFLAGS ; \
  %{_configure} --host=%{_host} --build=%{_build} \\\
--program-prefix=%{?_program_prefix} \\\
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IPsec AH use of ahash

[Jan Engelhardt]

On Sunday 2013-01-20 14:54, Tom St Denis wrote:
>> 
>> > You should really try running checkpatch.pl over code that's
>> > already in the kernel before you call out new contributors on it.
>> >
>> > How is this supposed to not be adversarial when I can't even use
>> > the Kernel source itself as a reference?
>> 
>> In case of the kernel the chicken and egg problem can be answered
>> without any questions, most source existed before checkpatch.pl
>> (evolved
>> to the current state).
>
>We clearly have different interpretations of the word "maintainer"
>then... If they're not maintaining the code then are they really the
>maintainers of it?

Maintainers maintain code. From own experience - I too have some
projects that are *only* "maintained" - that includes maintaining the
status quo, keeping it compiling and taking patches that require no
more than 5 minutes to think about.

To support users, especially ones with fire-and-forget submissions,
an "integrator" (for the lack of a better word for cleaning guy)
or "developer" to take up their posting is required.
But it often lacks one or more.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IPsec AH use of ahash

[Jan Engelhardt]

On Sunday 2013-01-20 14:54, Tom St Denis wrote:
 
  You should really try running checkpatch.pl over code that's
  already in the kernel before you call out new contributors on it.
 
  How is this supposed to not be adversarial when I can't even use
  the Kernel source itself as a reference?
 
 In case of the kernel the chicken and egg problem can be answered
 without any questions, most source existed before checkpatch.pl
 (evolved
 to the current state).

We clearly have different interpretations of the word maintainer
then... If they're not maintaining the code then are they really the
maintainers of it?

Maintainers maintain code. From own experience - I too have some
projects that are *only* maintained - that includes maintaining the
status quo, keeping it compiling and taking patches that require no
more than 5 minutes to think about.

To support users, especially ones with fire-and-forget submissions,
an integrator (for the lack of a better word for cleaning guy)
or developer to take up their posting is required.
But it often lacks one or more.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/