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

2018-10-09 Thread 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

2018-10-02 Thread 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)

2018-01-29 Thread 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

2017-04-09 Thread 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

2017-04-08 Thread 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

2017-03-29 Thread 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

2017-03-29 Thread 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

2017-03-28 Thread 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

2017-03-28 Thread 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

2017-03-28 Thread 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

2017-01-23 Thread 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

2017-01-12 Thread 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

2016-08-02 Thread 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

2015-11-23 Thread 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

2015-11-21 Thread 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 2/5] kernfs: implement kernfs_walk_and_get()

2015-11-17 Thread 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

2015-11-17 Thread 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

2015-11-17 Thread 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

2015-11-17 Thread 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

2015-07-09 Thread 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?

2015-05-06 Thread 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

2015-04-11 Thread 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

2015-04-09 Thread 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/


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

2015-04-08 Thread 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

2015-04-08 Thread 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

2015-02-16 Thread 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

2015-01-12 Thread 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/


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

2015-01-11 Thread 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()

2015-01-11 Thread 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

2014-01-25 Thread 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

2013-11-30 Thread 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

2013-11-27 Thread 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?

2013-11-04 Thread 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

2013-09-28 Thread 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

2013-09-11 Thread 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

2013-08-29 Thread 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

2013-08-07 Thread 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

2013-08-07 Thread 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: [Announce] Checkpoint-restore tool v0.4

2013-02-22 Thread 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

2013-02-22 Thread 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

2013-02-19 Thread 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

2013-02-19 Thread 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

2013-01-30 Thread 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: Redefinition of struct in6_addr in netinet/in.h and linux/in6.h

2013-01-17 Thread Jan Engelhardt
On Thursday 2013-01-17 03:05, David Miller wrote:

From: Carlos O'Donell car...@systemhalted.org
Date: Wed, 16 Jan 2013 20:58:47 -0500

 So I just went down the rabbit hole, and the further I get the
 closer I get to having two exact copies of the same definitions
 in both glibc and the kernel and using whichever one was included
 first.
 
 Is anyone opposed to that kind of solution?

Sounds interesting, please share :-)

iptables has the same issue, and solved it its way. 
(uapi/)linux/netfilter.h is used to get at things like union 
nf_inet_addr. This union contains struct in6_addr. There is no include 
for in6_addr in netfilter.h itself. This may break the standalone 
compilation test, but at least allows for specifying the 
environment-specific header for in6_addr in the C file:

a. userspace: #include netinet/in.h before linux/netfilter.h
b. kernel parts: #include linux/in6.h before linux/netfilter.h
--
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.6.0-0 released

2013-01-13 Thread Jan Engelhardt

On Sunday 2013-01-13 19:59, Yann E. MORIN wrote:
 printf Running libtoolize...\n
 libtoolize --copy --force
 printf Running aclocal...\n
 aclocal -Wall --force
 
 Not again. autoreconf has existed for so long, why are people still 
 hand-coding the boilerplate?

(Note: this is my very first completely autotools-based package.)
First, I have to admit that I looked at how other packages do it, and
I mimicked what they do, rather than invent my own.

Ok, sensible. Yes, a lot of other packages make bad examples :(
Let's hope for them to be still alive and updated when automake 1.14
is out - it will remove and flag out some terribly old remnants.

Second, I know of autoreconf, but it does not work for 'foreign' packages
(ie. packages that do not have the NEWS and Changelog files, for example):

[--SNIP--]
Makefile.am: required file `./NEWS' not found  
   
   
Makefile.am: required file `./ChangeLog' not found 
   
   
[--SNIP--]

I do not have a need for such files in this package. So, it is a 'foreign'
package, and must be handled as such by automake.

How does one autoreconf a 'foreign' package?

Surely, just that:
AM_INIT_AUTOMAKE([foreign])

  By default, do not build with -Wall, unless the user asks for it
 
 There normally is no excuse for not using -Wall by default,
 save for trying to compile it with msvc.

Sorry, did you mean: -Wall should be the default ?

Indeed.

Yes, I was thinking of building with -Wall by default once the packaging
would be a bit more stable. Now seems like a good time to add this.


 AC_HEADER_STDC
 AC_HEADER_STDBOOL
 AC_CHECK_HEADERS([ fcntl.h limits.h locale.h ])
 AC_CHECK_HEADERS([ stdlib.h string.h sys/time.h unistd.h ])
 AC_TYPE_SIZE_T
 AC_FUNC_MALLOC
 AC_FUNC_REALLOC
 AC_FUNC_ALLOCA
 AC_CHECK_FUNCS([ bzero memmove memset ])
 AC_CHECK_FUNCS([ strcasecmp strchr strcspn strdup strncasecmp strpbrk 
 strrchr
 strspn strtol ])
 AC_CHECK_FUNCS([ gettimeofday mkdir regcomp setlocale uname ])
 
 All of this seems pointless because you never use the results
 (HAVE_FCNTL_H, HAVE_LIMITS_H, etc.)

Right. This is the output of autoscan.

I find that program quite useless..

As I see it, the only action we could take is to bail out if any is missing.
Is this what you meant?

You could do that, though I would simply direct users to read the compiler
error message. That enhances (hopefully) both their knowledge on compiling,
and reduces the walltime configure runs.

If I understood right, kconfig-frontends is supposed to run on non-Linux too,
and I have yet to see a modern platform that's missing any of the stdc
functions like malloc and strchr.
--
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.6.0-0 released

2013-01-12 Thread Jan Engelhardt

On Saturday 2012-10-06 17:55, Yann E. MORIN wrote:

Hello All!

I'm pleased to announce the release of kconfig-frontends 3.6.0-0!
Go download it there:

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

Please stick to a single separator, i.e. 3.6.0.0. The dash is already
used by distributions to mark same-source releases.


And the repository can be browsed or hg-cloned from:
  http://ymorin.is-a-geek.org/hg/kconfig-frontends

Ugh, hg. There goes any chance for contributions.


bootstrap.sh
printf Running libtoolize...\n
libtoolize --copy --force
printf Running aclocal...\n
aclocal -Wall --force

Not again. autoreconf has existed for so long, why are people still 
hand-coding the boilerplate?


configure.ac
 By default, do not build with -Wall, unless the user asks for it

There normally is no excuse for not using -Wall by default,
save for trying to compile it with msvc.


AC_HEADER_STDC
AC_HEADER_STDBOOL
AC_CHECK_HEADERS([ fcntl.h limits.h locale.h ])
AC_CHECK_HEADERS([ stdlib.h string.h sys/time.h unistd.h ])
AC_TYPE_SIZE_T
AC_FUNC_MALLOC
AC_FUNC_REALLOC
AC_FUNC_ALLOCA
AC_CHECK_FUNCS([ bzero memmove memset ])
AC_CHECK_FUNCS([ strcasecmp strchr strcspn strdup strncasecmp strpbrk strrchr
strspn strtol ])
AC_CHECK_FUNCS([ gettimeofday mkdir regcomp setlocale uname ])

All of this seems pointless because you never use the results
(HAVE_FCNTL_H, HAVE_LIMITS_H, etc.)


ncurses has the ncurses{w,}{6,5}-config scripts that ought to be called
to determine the locations.
--
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] vfs: update atimes over one day in the past or future

2012-12-25 Thread Jan Engelhardt

On Tuesday 2012-12-18 22:14, Dave Chinner wrote:

  CC: sta...@vger.kernel.org
  ---
  fs/inode.c | 7 ---
  1 ??? 4 ???(+)? 3 ???(-)
  
  There's something wrong with the character encoding you are using...
 
 Chinese locale, but probably doesn't matter since text below --- isn't in 
 the commit anyway?

Yup, but it doesn't inspire confidence that the patch is going to be
clean when multiple encodings appear in the one message...

Multiple encodings are not much of a problem. Lack of specifying them,
as happened with that attachment, is.

That's another reason why inline patches work better, because the
main message part has the encoding set most of the time :)
--
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] make CONFIG_EXPERIMENTAL invisible and default

2012-12-15 Thread Jan Engelhardt

On Wednesday 2012-10-03 18:17, Greg Kroah-Hartman wrote:
 
 OK, I will bite...  How should I flag an option that is initially only
 intended for those willing to take some level of risk?

In the text say You really don't want to enable this option, use at
your own risk!  Or something like that :)

You know that won't not work, just like everybody is encouraged
to upgrade for -stable. It needs to say All users must disable this!
--
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 starvation by sync writes

2012-12-11 Thread Jan Engelhardt

On Monday 2012-12-10 23:12, Jan Kara wrote:

  I was looking into IO starvation problems where streaming sync writes (in
my case from kjournald but DIO would look the same) starve reads. This is
because reads happen in small chunks and until a request completes we don't
start reading further (reader reads lots of small files) while writers have
plenty of big requests to submit. Both processes end up fighting for IO
requests and writer writes nr_batching 512 KB requests while reader reads
just one 4 KB request or so.[...]
Simple reproducer is:

echo 3 /proc/sys/vm/drop_caches
dd if=/dev/zero of=/tmp/f bs=1M count=1 
sleep 30
time cat /etc/* 21 /dev/null
killall dd
rm /tmp/f

  The question is how can we fix this?

The ROW scheduler attempts to address it up by prioritizing reads,
and it works out for me.

 (Mail info.)
 Date: Tue, 11 Dec 2012 14:41:18
 From: Tanya Brokhman tlin...@codeaurora.org
 Subject: [PATCH v4 0/2] ROW scheduling Algorithm
--
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 7/7] fs, notify: Add procfs fdinfo helper v6

2012-12-09 Thread Jan Engelhardt

On Saturday 2012-11-17 00:56, Andrew Morton wrote:
  | pos:  0
  | flags:0200
  | inotify wd:3 ino: 9e7e
  | inotify wd:2 ino: a111
  | inotify wd:1 ino:6b149[...]

This is a lousy output format.  It's sort-of like a sensible set of
name-value tuples: name:value name:value name:value but

c) inotify-wd is secretly printed in decimal while everything else
   is in hex.

What happens if we do something like the below (which will require a
changelog update)?

@@ -59,7 +59,7 @@ static int show_mark_fhandle(struct seq_
   f.handle.handle_type = ret;
   f.handle.handle_bytes = size * sizeof(u32);
 
-  ret = seq_printf(m, fhandle-bytes: %8x fhandle-type: %8x f_handle: ,
+  ret = seq_printf(m, fhandle-bytes:%x fhandle-type:%x f_handle:,
f.handle.handle_bytes, f.handle.handle_type);

Why don't we actually make sure to print a 0x prefix when it's hex
and 0 on octal? Then it should be clear what base these lines are in.
(That would also be a good idea for the rest of procfs files, but I
reckon they cannot be easily changed.)
--
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/


percpu section failure with Gold linker

2012-11-23 Thread Jan Engelhardt
Hi,


when compiling a kernel with the gold linker (3.7.0-rc6 26d29d06ea0204, 
gcc-4.7 and binutils-2.23 in my case), certain pcpu symbols are 
seemingly errneously copied over from .o files to .ko files, leading to 
a hard warning during depmod:

gold$ make -j8 LD=gold HOSTLD=gold
gold$ make modules_install INSTALL_MOD_PATH=/tmp/foo
[...]
WARNING: /tmp/foo/lib/modules/3.7.0-rc6-jng6-default+
/kernel/net/rds/rds_tcp.ko needs unknown symbol
__pcpu_scope_rds_tcp_stats

This happens with many modules using percpu; looking at things with nm 
reveals:

gold/net/ipv6$ nm ipv6.o | grep __pcpu_
 D __pcpu_unique_ipv6_cookie_scratch
gold/net/ipv6$ nm ipv6.ko | grep __pcpu_
 U __pcpu_unique_ipv6_cookie_scratch

On the other hand, in a linux tree built with the original ld (ld.bfd), 
things look like:

bfd$ make -j8
[...]
bfd/net/ipv6$ nm ipv6.o | grep pcpu
 D __pcpu_unique_ipv6_cookie_scratch
bfd/net/ipv6$ nm ipv6.ko | grep pcpu
(no result)
--
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: RFE: tty color features

2012-09-25 Thread Jan Engelhardt
On Tuesday 2012-09-25 08:01, Dave Yost wrote:

It would be nice to be able to specify fg/bg colors at the tty level, 
so that echoed characters can be colorized.

The tty layer does not know what $TERM is used, so it cannot reliably 
produce any codes. But you can edit GNU screen because it has that 
knowledge and the fds.

--
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: Question on /proc/cpuinfo

2012-09-23 Thread Jan Engelhardt

On Friday 2012-09-14 14:30, Cong Wang wrote:
 On 09/14/2012 07:18 AM, JA Magallón wrote:
 Hi...

 Probably it is a stupid question, but... I wan to count the number of
 processors, cores and threads on a linux system. I do it by reading
 /proc/cpuinfo.

 Probably lscpu(1) is better for you, on my laptop it outputs:

Programmatically (for scripts), you want to count the number
of /sys/devices/system/cpu/cpu[0-9]*. Grepping around output
meant for humans (cpuinfo, lscpu) is always a bad idea.
--
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 00/13] overlay filesystem: request for inclusion (v15)

2012-09-23 Thread Jan Engelhardt

On Thursday 2012-09-20 22:48, Miklos Szeredi wrote:

 Miklos, how do you think about this?
 http://marc.info/?l=linux-kernelm=123938533724484w=2
 Do you think UnionMount is totally gone?

Unionmount provides almost the same functionality as overlayfs.  The big
difference between the two is that unionmounts resides 100% in the VFS
while 95% of overlayfs is plain filesystem code.  I think that's the
biggest advantage: filesystem code is easier to maintain, has less
impact on core complexity, etc.

The big advantage is actually that the unioned view is in a separate
namespace (vfsmount).

Aufs provides much better filesystem semantics than either unionmounts
or overlayfs.  But that does come at a price:

aufs:   98 files changed, 29893 insertions(+), 7 deletions(-)
overlayfs:  22 files changed, 2981 insertions(+), 10 deletions(-)

In two years time when sufficient user requests have come in,
overlayfs is likely to have wrong as much.
--
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: Drop support to compressed modules?

2012-09-23 Thread Jan Engelhardt

On Friday 2012-09-21 23:41, Lucas De Marchi wrote:

While fixing a bug in kmod related to using compressed modules (that
already existed in module-init-tools) we stopped to think about these
questions. Dave made a couple of benchmarks and performance wise it's
better to use uncompressed modules than modules with gz or xz
compression. However the benchmark was done in only 1 computer. I do
expect people with slow storage to have different numbers though. Does
anyone have these numbers?

What benchmark should be run?
--
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 2/2] block: Adding ROW scheduling algorithm

2012-09-20 Thread Jan Engelhardt

On Wednesday 2012-09-19 07:29, Jan Engelhardt wrote:
On Monday 2012-08-06 18:35, Jeff Moyer wrote:
Tatyana Brokhman writes:

 This patch adds the implementation of a new scheduling algorithm - ROW.
 The policy of this algorithm is to prioritize READ requests over WRITE
 as much as possible without starving the WRITE requests.

Perhaps you could start off by describing the workload, and describing
why the existing I/O schedulers do not perform well.

There seems to a bug with ROW. After about 43 hours of continued
operation, programs (./configure was what I ran at the time this
happened) first become slow, then got stuck in D state within a
minute. Ctrl-C/Z worked at first, soon not, then these messages
appeared in dmesg.

[319952.630605] row: forced dispatching is broken (nr_sorted=17), please report
this
[319952.631174] row: forced dispatching is broken (nr_sorted=17), please report
this
--
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 2/2] block: Adding ROW scheduling algorithm

2012-09-18 Thread Jan Engelhardt

On Monday 2012-08-06 18:35, Jeff Moyer wrote:
Tatyana Brokhman writes:

 This patch adds the implementation of a new scheduling algorithm - ROW.
 The policy of this algorithm is to prioritize READ requests over WRITE
 as much as possible without starving the WRITE requests.

Perhaps you could start off by describing the workload, and describing
why the existing I/O schedulers do not perform well.

My setup is a 1 GB RAM Atom N450 netbook, combined with the use of
dm-crypt for the 5400 rpm disk, which limits the effective write
throughput to somewhere around 20–26 MB/s. Now try this:

  ddrescue /dev/zero ~/bluntfile (or)

  (remote)# nullfile
  (remote)# truncate -s 10G nullfile
  (local)# rsync -HPavz remote:nullfile .

The transfer rates of ddrescue/rsync first show 50–60 MB/s. Wait
until writeout is forced - which is after ~700–800 MB in my case when
all buffers are full. The transfer rates then drop to the
aforementioned 20–26 MB/s.

In the so-loaded system, try to start an xterm (preferably by the use
of a shortcut, or starting one from another xterm). The wait time for
the shell prompt to appear is then the measure for interactivity,
with lower being better.

I have casually observed that ROW has 1/4th of the wait time in this
heavy disk write scenario (around 5 s) for the shell to start up than
with CFQ (20–21 s). Casual meaning I had a clock with 1.0 s
granularity beside me and ran this for like 3 times for each
scheduler, averaging it out.
--
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] kmod 10

2012-09-16 Thread Jan Engelhardt

On Thursday 2012-09-06 21:37, Lucas De Marchi wrote:

kmod 10 is out:

ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-10.tar.xz
ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-10.tar.sign

make check fails here with glibc-2.15, gcc-4.7, x86_64,
due to what seems to be duplicated symbols(?):


+ make check V=1
Making check in .
make --no-print-directory testsuite/uname.la testsuite/path.la 
testsuite/init_module.la testsuite/delete_module.la testsuite/libtestsuite.la 
testsuite/test-init testsuite/test-testsuite testsuite/test-loaded 
testsuite/test-modinfo testsuite/test-alias testsuite/test-new-module 
testsuite/test-modprobe testsuite/test-blacklist testsuite/test-dependencies
depbase=`echo testsuite/uname.lo | sed 's|[^/]*$|.deps/|;s|\.lo$||'`;\
/bin/sh ./libtool  --tag=CC   --mode=compile gcc -std=gnu99 -std=gnu99 
-DHAVE_CONFIG_H -I.  -include ./config.h -I./libkmod -DROOTPREFIX=\\ 
-DSYSCONFDIR=\/etc\ -DLIBEXECDIR=\/usr/lib\ -I/usr/local/include
-pipe -DANOTHER_BRICK_IN_THE -Wall -W -Wextra -Wno-inline -Wvla -Wundef 
-Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs 
-Wformat-nonliteral -Wold-style-definition -Wpointer-arith -Winit-self 
-Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes 
-Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn 
-Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long 
-Wno-overlength-strings -Wno-unused-parameter -Wno-missing-field-initializers 
-Wno-unused-result -Wnested-externs -Wchar-subscripts -Wtype-limits 
-Wuninitialized -fno-common -fdiagnostics-show-option -fvisibility=hidden 
-ffunction-sections -fdata-sections -fomit-frame-pointer -fmessage-length=0 -O2 
-Wall -D_FORTIFY_SOURCE=2 -
 fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -MT 
testsuite/uname.lo -MD -MP -MF $depbase.Tpo -c -o testsuite/uname.lo 
testsuite/uname.c \
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  gcc -std=gnu99 -std=gnu99 -DHAVE_CONFIG_H -I. -include 
./config.h -I./libkmod -DROOTPREFIX=\\ -DSYSCONFDIR=\/etc\ 
-DLIBEXECDIR=\/usr/lib\ -I/usr/local/include -pipe -DANOTHER_BRICK_IN_THE 
-Wall -W -Wextra -Wno-inline -Wvla -Wundef -Wformat=2 -Wlogical-op 
-Wsign-compare -Wformat-security -Wmissing-include-dirs -Wformat-nonliteral 
-Wold-style-definition -Wpointer-arith -Winit-self 
-Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes 
-Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn 
-Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long 
-Wno-overlength-strings -Wno-unused-parameter -Wno-missing-field-initializers 
-Wno-unused-result -Wnested-externs -Wchar-subscripts -Wtype-limits 
-Wuninitialized -fno-common -fdiagnostics-show-option -fvisibility=hidden 
-ffunction-sections -fdata-sections -fomit-frame-pointer -fmessage-length=0 -O2 
-Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fa
 synchronous-unwind-tables -g -MT testsuite/uname.lo -MD -MP -MF 
testsuite/.deps/uname.Tpo -c testsuite/uname.c  -fPIC -DPIC -o 
testsuite/.libs/uname.o
cc1: warning: /usr/local/include: No such file or directory [enabled by default]
/bin/sh ./libtool  --tag=CC   --mode=link gcc -std=gnu99 -std=gnu99 -pipe 
-DANOTHER_BRICK_IN_THE -Wall -W -Wextra -Wno-inline -Wvla -Wundef -Wformat=2 
-Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs 
-Wformat-nonliteral -Wold-style-definition -Wpointer-arith -Winit-self 
-Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes 
-Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn 
-Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long 
-Wno-overlength-strings -Wno-unused-parameter -Wno-missing-field-initializers 
-Wno-unused-result -Wnested-externs -Wchar-subscripts -Wtype-limits 
-Wuninitialized -fno-common -fdiagnostics-show-option -fvisibility=hidden 
-ffunction-sections -fdata-sections -fomit-frame-pointer -fmessage-length=0 -O2 
-Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -g avoid-version -module -shared -export-dynamic 
-rpath /nowhere -ldl  -o testsuite/uname.
 la  testsuite/uname.lo  
libtool: link: gcc -std=gnu99 -shared  -fPIC -DPIC  testsuite/.libs/uname.o   
-ldl  -O2   -Wl,-soname -Wl,uname.so.0 -o testsuite/.libs/uname.so.0.0.0
libtool: link: (cd testsuite/.libs  rm -f uname.so.0  ln -s 
uname.so.0.0.0 uname.so.0)
libtool: link: (cd testsuite/.libs  rm -f uname.so  ln -s 
uname.so.0.0.0 uname.so)
libtool: link: ( cd testsuite/.libs  rm -f uname.la  ln -s 
../uname.la uname.la )
depbase=`echo testsuite/path.lo | sed 's|[^/]*$|.deps/|;s|\.lo$||'`;\
/bin/sh ./libtool  --tag=CC   --mode=compile gcc -std=gnu99 -std=gnu99 
-DHAVE_CONFIG_H -I.  -include ./config.h -I./libkmod -DROOTPREFIX=\\ 
-DSYSCONFDIR=\/etc\ -DLIBEXECDIR=\/usr/lib\ -I/usr/local/include
-pipe -DANOTHER_BRICK_IN_THE -Wall -W -Wextra -Wno-inline -Wvla -Wundef 
-Wformat=2 

Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer

2012-09-14 Thread Jan Engelhardt

On Friday 2012-09-14 11:17, Bernd Petrovitsch wrote:
Shouldn't that have been
  snip 
#define base10len(i) ((const int[]){1,3,5,8,10,13,15,17,20}[sizeof(i)])
  snip 
Yeah.

A pure KR-C version would use a string:
#define base10len(i) \0x1\0x3\0x5\0x8\0x0A\0x0D\0x0F\0x11\0x14[sizeof(i)]
(if I converted them properly into hexadecimal)
The syntax is \x01\x03\x05...

and that gives a char
which is happily promoted to whatever one needs in that place.

So just convert it; there are no less than two ways to do so
 ((const unsigned char *)\x01\x03...)[sizeof(i)]
 (boatfloating_t)(\x01\x03...[sizeof(i)])
--
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] strings: helper for maximum decimal encoding of an unsigned integer

2012-09-14 Thread Jan Engelhardt

On Friday 2012-09-14 14:30, Jim Rees wrote in an odd quote style
(the  are mine):

Bernd Petrovitsch wrote:

  A pure KR-C version would use a string:
    snip 
  #define base10len(i) \0x1\0x3\0x5\0x8\0x0A\0x0D\0x0F\0x11\0x14[sizeof(i)]
    snip 
  (if I converted them properly into hexadecimal) and that gives a char
  which is happily promoted to whatever one needs in that place.

1. That may give you a signed char on some architectures, which is not what
you want (although it doesn't matter since the values are all  128)

Convert.

2. If you put this in a .h, you'll get multiple copies of the array

The gcc compiler is smart enough to optimize that away. A string
literal is known at compile-time and immutable by definition.
sizeof(i) is a compile-time constant, also by definition. Therefore,
any foo[bar] is resolvable at compile time. Even gcc -O0 knows that.

That makes it possible to write
  char f[base10len(whatever)];
without depending on C99 VLAs.

Pure KR:

base10.h:
extern unsigned char base10len_vals[];
#define base10len(i) (base10len_vals[sizeof(i)])

base10.c:
unsigned char base10len_vals[] = {1,3,5,8,10,13,15,17,20};

But I still like my way better.

Your way does not function as originally desired.

 * base10len(i) no longer expands to a compile-time constant

 * you will definitely have a variable base10len_vals in your
   objects, so you waste a read operation whenever it is used.
--
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] strings: helper for maximum decimal encoding of an unsigned integer

2012-09-14 Thread Jan Engelhardt
On Friday 2012-09-14 15:46, Jim Rees wrote:

Jan Engelhardt wrote:

  A pure KR-C version would use a string:
  #define base10len(i) \0x1\0x3\0x5\0x8\0x0A\0x0D\0x0F\0x11\0x14[sizeof(i)]
  (if I converted them properly into hexadecimal)
  The syntax is \x01\x03\x05...

KR doesn't have the \x escape, only \0 (octal).

People recommend KR only for the introductory reading, not for its 
actuality.
--
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] strings: helper for maximum decimal encoding of an unsigned integer

2012-09-10 Thread Jan Engelhardt
On Tuesday 2012-08-21 23:29, J. Bruce Fields wrote:

I've seen a couple examples recently where we've gotten this wrong.
Maybe something like this would help?  Is there some better way?
(Approximation due to Jim Rees).

+/*
+ * length of the decimal representation of an unsigned integer.  Just an
+ * approximation, but it's right for types of size 1 to 36 bytes:
+ */
+#define base10len(i) (sizeof(i) * 24 / 10 + 1)


gcc provides... interesting features at times.

/* for unsigned is */
#define base10len(i) ((const int[]){1,3,5,8,10,13,15,17,20}[i])

But enumerating it (using your ULONG_MAX_STR proposal) should be 
sufficient, since there is only a limited number of types that get e.g. 
sprintf'ed into a buffer.


Something else tho, it seems some don't know that sizeof() is already 
1, and an extra \0 is often unneeded, like in:

arch/um/drivers/net_user.c:  char addr_buf[sizeof(255.255.255.255\0)];
--
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-user-chroot 2012.2

2012-09-09 Thread Jan Engelhardt

On Monday 2012-08-13 20:10, Andy Lutomirski wrote:

One of these days, I intend to resurrect my unprivileged chroot kernel
patches.  My current thought is to add a new syscall weak_chroot,
which should have these properties:
[...]
3. Can't be used to break out of chroot jail.

The interface might be:

weak_chroot_at(int fd, const char *path, int flags)
[...]
I'm somewhat tempted to add a flag to weak_chroot_at to break out of
weak_root jail to prevent people from thinking that it's a security
feature.  I'm not sure about that, though.

An at variant of chroot would seem to be even more open than the
current name-based variant of chroot.

fd1 = open(/, O_DIRECTORY);
fd2 = open(/home/whatever, O_DIRECTORY);
weak_chroot_at(fd2, ., 0)
weak_chroot_at(fd1, ., 0)



--
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] Add mach-specific includes

2012-09-09 Thread Jan Engelhardt

On Friday 2012-08-31 15:45, Michal Marek wrote:
  # Build header package
  (cd $srctree; find . -name Makefile\* -o -name Kconfig\* -o -name \*.pl  
 $objtree/debian/hdrsrcfiles)
  (cd $srctree; find arch/$SRCARCH/include include scripts -type f  
 $objtree/debian/hdrsrcfiles)
 +if echo arch/$SRCARCH/mach-*/include | grep q -v '*'; then

This should probably be grep -q, but it's quite ugly anyway.

Use of -q should probably be preferred to /dev/null,
because with the latter, you will still pay the price
of printf.
--
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 07/13] overlay: overlay filesystem documentation

2012-09-09 Thread Jan Engelhardt

On Wednesday 2012-08-15 17:48, Miklos Szeredi wrote:
[...]
+This is most obvious from the 'st_dev' field returned by stat(2).
+
+While directories will report an st_dev from the overlay-filesystem,
+all non-directory objects will report an st_dev from the lower or
+upper filesystem that is providing the object.

That would seem to render `rsync --one-filesystem` unusable?
(or similar options in other tools)


--
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/2] brd: RAM block module is called 'brd'

2012-09-09 Thread Jan Engelhardt

On Tuesday 2012-08-21 17:10, Paul Bolle wrote:

2) modinfo rd doesn't work. Apparently one needs to feed modinfo the
actual module name and not an alias. Is that by design?

I would say so, because you can call

modprobe --resolve-alias rd

to figure out the actual module to any given string. If this
modprobe call returns nothing, you know you found the terminal name.
--
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: Which disk is ata4?

2012-08-30 Thread Jan Engelhardt
On Thursday 2012-08-30 17:22, Borislav Petkov wrote:

On Thu, Aug 30, 2012 at 08:17:13AM -0700, Andy Lutomirski wrote:
 $ dmesg |grep ST3000DM001-9YN166
 [1.064910] ata5.00: ATA-8: ST3000DM001-9YN166, CC4B, max UDMA/133
 [1.064926] ata3.00: ATA-8: ST3000DM001-9YN166, CC4B, max UDMA/133
 [1.064986] ata2.00: ATA-8: ST3000DM001-9YN166, CC4B, max UDMA/133
 [1.065012] ata4.00: ATA-8: ST3000DM001-9YN166, CC4B, max UDMA/133
 [1.235753] ata7.00: ATA-8: ST3000DM001-9YN166, CC4B, max UDMA/133
 [1.727000] ata8.00: ATA-8: ST3000DM001-9YN166, CC4B, max UDMA/133

Shouldn't the SATA ports have actually numbers on the motherboard. And
if so, ata4 should be the 4th port in the nomenclature... Then it is
only about following the cable :).

That is not reliable, especially when extra PCI cards come into play.
--
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: Which disk is ata4?

2012-08-30 Thread Jan Engelhardt
On Thursday 2012-08-30 06:38, Andy Lutomirski wrote:

One of my disks went out to lunch for a while.  Logs below.

[784786.047673] ata4.00: exception Emask 0x10 SAct 0x7800 SErr 0x0
action 0x6 frozen

Which one is it?  The only useful thing in /sys/class/ata_port/ata4 is
the device symlink, which points at
/sys/devices/pci:00/:00:1f.2/ata4.

For example, ata2 here:

$ cd /sys/devices
$ find . -name ata2
./pci:00/:00:1f.2/ata2
./pci:00/:00:1f.2/ata2/ata_port/ata2
$ cd ./pci:00/:00:1f.2/ata2
$ ls -dl host*/targ*
drwxr-xr-x 4 root root 0 Aug 30 18:09 host1/target1:0:0
$ lsscsi
[0:0:0:0]diskATA  ST3000DM001-9YN1 CC4C  /dev/sda 
[1:0:0:0]diskATA  ST3000DM001-9YN1 CC4C  /dev/sdb 
# sdparm -i /dev/sdb
/dev/sdb: ATA   ST3000DM001-9YN1  CC4C
Device identification VPD page:
  Addressed logical unit:
designator type: vendor specific [0x0],  code set: ASCII
  vendor specific: Z1F0KR3H
designator type: T10 vendor identification,  code set: ASCII
  vendor id: ATA 
  vendor specific: ST3000DM001-9YN166
 Z1F0KR3H
designator type: NAA,  code set: Binary
  0x5000c500408f772f

This tells me everything to replace a disk.
1. sdparm -C stop /dev/sdb
2. Removing Z1F0KR3H from the chassis.
3. Put new disk in..
(4. Profit.)
--
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: Which disk is ata4?

2012-08-30 Thread Jan Engelhardt
On Thursday 2012-08-30 18:57, Andy Lutomirski wrote:

On Thu, Aug 30, 2012 at 9:14 AM, Jan Engelhardt jeng...@inai.de wrote:
 On Thursday 2012-08-30 06:38, Andy Lutomirski wrote:

One of my disks went out to lunch for a while.  Logs below.

[784786.047673] ata4.00: exception Emask 0x10 SAct 0x7800 SErr 0x0
action 0x6 frozen

Which one is it?  The only useful thing in /sys/class/ata_port/ata4 is
the device symlink, which points at
/sys/devices/pci:00/:00:1f.2/ata4.

 For example, ata2 here:

 $ cd /sys/devices
 $ find . -name ata2
 ./pci:00/:00:1f.2/ata2
 ./pci:00/:00:1f.2/ata2/ata_port/ata2
 $ cd ./pci:00/:00:1f.2/ata2
 $ ls -dl host*/targ*
 drwxr-xr-x 4 root root 0 Aug 30 18:09 host1/target1:0:0

Aha!  This works on 3.5 but not on 3.2.

3.4.x here..
--
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 v3 2/9] rbtree: add __rb_change_child() helper function

2012-08-23 Thread Jan Engelhardt

On Tuesday 2012-08-21 00:17, Andrew Morton wrote:

If we have carefully made a decision to inline a function, we should
(now) use __always_inline.
If we have carefully made a decision to not inline a function, we
should use noinline.

If we don't care, we should omit all such markings.
This leaves no place for inline?

The current use of inline is to shut up the compiler, otherwise gcc
would emit a warning about function declared but not used.
--
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] fs: Introducing Lanyard Filesystem

2012-08-22 Thread Jan Engelhardt
On Sunday 2012-08-19 15:34, Dan Luedtke wrote:

I analyzed about 600k file stored on various removable storage devices. 
80 volunteers sent in data about their devices, generated by a program 
(windows) and scripts (linux, bsd, osx) I wrote for that purpose. The 
data shows that people use more complex filesystems as soon as they are 
confronted with problems (mostly the 4GB limit). After that they have 
problems getting their data accessed by other systems. I derived from 
that, that we need a filesystem that is so simple that even unpopular 
operating systems can implement it without having their business plan 
explode.

Those unpopular OSes do not care about *any other* filesystem at all. 

The only way to get a filesystem accepted is by making an ISO standard
out of it - or something in that direction - *and* use it thoroughly
in products, like UDF. Even then, support for new revisions of UDF
has been rather slow-coming.
--
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] fs: Preserve error code in get_empty_filp()

2012-08-21 Thread Jan Engelhardt

On Wednesday 2012-08-01 20:19, anatol.pomo...@gmail.com wrote:
Allocating a file structure in function get_empty_filp() might fail because
of several reasons:
 - not enough memory for file structures
 - operation is not allowed
 - user is over its limit

Currently the function returns NULL in all cases and we loose the exact
reason of the error. All callers of get_empty_filp() assume that the function
can fail with ENFILE only.

Return error through pointer. Change all callers to preserve this error code.

   percpu_counter_inc(nr_files);
   f-f_cred = get_cred(cred);
-  if (security_file_alloc(f))
+  if (security_file_alloc(f)) {
+  error = -EPERM;
   goto fail_sec;
+  }

You are not preserving the error code from security_file_alloc here.

In particular, apparmoar/lsm.c: file_alloc_security can return -ENOMEM,
for example.
--
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] scripts/patch-kernel fix

2012-08-17 Thread Jan Engelhardt

On Thursday 2012-07-26 12:10, Michal Marek wrote:
On 19.7.2012 23:49, Daniel Wisehart wrote:
 diff --git a/scripts/patch-kernel b/scripts/patch-kernel
 index d000ea3..a7672eb 100755
 --- a/scripts/patch-kernel
 +++ b/scripts/patch-kernel
 @@ -226,7 +226,7 @@ fi
  
  # This all assumes a 2.6.x[.y] kernel tree.
  # Don't allow backwards/reverse patching.
 -if [ $STOPSUBLEVEL -lt $SUBLEVEL ]; then
 +if [ $STOPSUBLEVEL0 -lt $SUBLEVEL0 ]; then

Hi Daniel,

While this is correct, it is not obvious at first sight why you need to
multiply the numbers by 10. Or at least it was not obvious to me :).

Word has it some really old shells nobody would use to compile Linux on
interpret  not as an empty argument, but as a non-existing argument,
turning if [  !=  ] into essentially if [ != ].

Doing x10 avoids the uncertainity whether shells might attempt to
interpret it as octal or not.
So far the interpretation..

Could you use the more common idiom 0$NUMBER? The shell interprets the
numbers as decimal, so it's works fine.

Wonder what POSIX says about that.
--
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: RAID extremely slow

2012-08-17 Thread Jan Engelhardt

On Thursday 2012-07-26 03:00, Phil Turmel wrote:
 I used atop to show the transfer speeds to each drive. Here's a
 screenshot:
 http://img402.imageshack.us/img402/6484/screenshotfrom201207251.png

[ The output of lsdrv [1] might be useful here, along with
mdadm -D /dev/md0 and mdadm -E /dev/[b-j] ]
[1] http://github.com/pturmel/lsdrv

lsdrv? Shows a bunch, but for this, using standard tools
like lsscsi  lsblk seems sufficient :)
--
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 v5 8/8] Added /proc/net/sco via bt_procfs_init()

2012-08-15 Thread Jan Engelhardt
On Thursday 2012-07-26 06:24, Gustavo Padovan wrote:

Hi Masatake,

* Masatake YAMATO yam...@redhat.com [2012-07-26 01:30:12 +0900]:

 Added /proc/net/sco via bt_procfs_init().
 
 Signed-off-by: Masatake YAMATO yam...@redhat.com
 ---
  net/bluetooth/sco.c |9 +
  1 file changed, 9 insertions(+)

All 8 patches have been applied to bluetooth-next. Thanks.

It may have been raised before, but: should not the info be exported 
over netlink rather than the oldfashioned and overabused procfs?
--
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: [vmw_vmci 11/11] Apply the header code to make VMCI build

2012-08-15 Thread Jan Engelhardt

On Thursday 2012-08-02 22:22, Sam Ravnborg wrote:
 On Friday 2012-07-27 12:34, Sam Ravnborg wrote:
  +#ifndef _VMCI_COMMONINT_H_
  +#define _VMCI_COMMONINT_H_
  +
  +#include linux/printk.h
  +#include linux/vmw_vmci_defs.h
 
 Use inverse chrismas tree here.
 Longer include lines first, and soret alphabetically when
 lines are of the same length.
 
 So that's where unreadable include lists come from.
 Depth-first lexicographically-sorted is a lot less hassle,
 especially when it comes to merging patches that each
 add one different include.
This is applied in many parts of the kernels and has some benefits:
- easy to spot duplicates
- clash is less likely when two commit adds includes

Sorting already addresses the two, the christmas thing (for
files in a single dir) seems like adding no extra value.


The kernel types are u32 not uint32_t - these types belongs in user-space.
Found the following somewhere on the net:

|  - the kernel should not depend on, or pollute user-space naming.
|YOU MUST NOT USE uint32_t when that may not be defined, and
|user-space rules for when it is defined are arcane and totally
|arbitrary.

I can see the reasoning for header files, but it seems
irrelevant for code, in particular .c files, that never
practically get exposed to userspace.
--
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] add blockconsole version 1.1

2012-08-14 Thread Jan Engelhardt

On Wednesday 2012-07-18 20:53, Jörn Engel wrote:

 With the include added, it builds fine. Then I took an usb stick and I
 did:
 
 $ ./mkblockconsole /dev/sdc
 
 reboot

You can also run hdparm -z dev instead.

We have too many ways of doing some things.
util-linux conveniently has `blockdev --rereadpt /dev/sdc`.
--
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] scripts/package/builddeb: upgrade to current practices

2012-08-14 Thread Jan Engelhardt

On Tuesday 2012-07-17 21:46, Martin-Éric Racine wrote:
 @@ -188,17 +188,17 @@ This is a packacked upstream version of the Linux 
 kernel.
  The sources may be found at most Linux ftp sites, including:
  ftp://ftp.kernel.org/pub/linux/kernel

 -Copyright: 1991 - 2009 Linus Torvalds and others.
 +Copyright: 1991-2012 Linus Torvalds and others.

 -The git repository for mainline kernel development is at:
 -git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
 +The GIT repository for mainline kernel development is at:
 +git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

 I personally like to spell it as Git. ;-)

That works for me too. Actually, what's the official spelling for it?

The acronymic usage of GIT to mean Global Information Tracker has
not caught on. Therefore most likely Git; like Linux, a noun, a
name.

--
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] MPILIB: Provide count_leading/trailing_zeros() based on arch functions

2012-08-10 Thread Jan Engelhardt

On Saturday 2012-07-21 02:46, David Miller wrote:
 Arnd Bergmann a...@arndb.de wrote:
 
 I don't generally like to put stuff into asm-generic when it's unlikely
 to be overridden by architectures. It would really belong into
 include/linux, but then again we have all the other bitops in asm-generic
 as well, so whatever...
 
 Some arches (such as Sparc, I think) have count-leading-zero instructions.

Yes, newer sparc64 chips have leading-zero-detect, and I was pretty
sure that powerpc had something similar.  It's called count-leading-
zeros or something like that.

And gcc has a __builtin_clz.
--
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: Regression - /proc/kmsg does not (always) block for 1-byte reads

2012-08-10 Thread Jan Engelhardt

On Saturday 2012-07-07 23:19, Kay Sievers wrote:
On Fri, Jul 6, 2012 at 10:30 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
 Kay, this needs to be fixed.

 Suggested fix: just use the 'seq_printf()' interfaces, which do the
 proper buffering, and allow any size reads of various packetized data.

I'll have a look.

 Of course, I'd also suggest that whoever was the genius who thought it
 was a good idea to read things ONE F*CKING BYTE AT A TIME with system
 calls for each byte should be retroactively aborted. Who the f*ck does
 idiotic things like that? How did they noty die as babies, considering
 that they were likely too stupid to find a tit to suck on?

Maybe the bs=1 in the dd call stands for bullshit. :)

It seems people need to be taught to use ddrescue, stringently.
Having to calculate appropriate values for bs= and count= when
you just want to transfer bytes is already a crime, not to mention
the problem when you have a prime number of bytes to transfer.
--
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: Inconsistent kallsyms data error

2012-08-09 Thread Jan Engelhardt

On Saturday 2012-07-07 23:40, Michal Marek wrote:
index cd9c6c6..4629038 100644
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -210,8 +210,8 @@ if [ -n ${CONFIG_KALLSYMS} ]; then
   mksysmap ${kallsyms_vmlinux} .tmp_System.map
 
   if ! cmp -s System.map .tmp_System.map; then
-  echo Inconsistent kallsyms data
-  echo echo Try make KALLSYMS_EXTRA_PASS=1 as a workaround
+  echo 2 Inconsistent kallsyms data
+  echo 2 echo Try make KALLSYMS_EXTRA_PASS=1 as a workaround

Hm why is there echo twice in that one line? Seems like an oversight..
--
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] fat: Refactor shortname parsing

2012-08-03 Thread Jan Engelhardt
On Tuesday 2012-07-03 13:14, Steven J. Magnani wrote:

Nearly identical shortname parsing is performed in fat_search_long()
and __fat_readdir(). Extract this code into a function that may be
called by both.

v2: Attempt to clarify difference between vfat and msdos parsing.
Remove decision-making from fat_tolower() for clarity.

Signed-off-by: Steven J. Magnani st...@digidescorp.com
---
diff -uprN linux-3.5-rc4/fs/fat/dir.c new/fs/fat/dir.c
--- linux-3.5-rc4/fs/fat/dir.c 2012-06-29 11:20:12.766348728 -0500
+++ new/fs/fat/dir.c   2012-07-03 06:10:36.066283411 -0500
@@ -35,6 +35,11 @@
 #define FAT_MAX_UNI_CHARS ((MSDOS_SLOTS - 1) * 13 + 1)
 #define FAT_MAX_UNI_SIZE  (FAT_MAX_UNI_CHARS * sizeof(wchar_t))
 
+static inline unsigned char fat_tolower(unsigned char c)
+{
+  return ((c = 'A')  (c = 'Z')) ? c+32 : c;
+}
+

The kernel already has a tolower() function, can that not be used?

--
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] fat: Refactor shortname parsing

2012-08-03 Thread Jan Engelhardt

On Friday 2012-08-03 17:06, OGAWA Hirofumi wrote:
+static inline unsigned char fat_tolower(unsigned char c)
+{
+return ((c = 'A')  (c = 'Z')) ? c+32 : c;
+}
+

 The kernel already has a tolower() function, can that not be used?

tolower() is not exactly same, right? e.g. tolower(0xc0). Otherwise,
tolower() is fine.

Yes, but you can still

return (c = 'A'  c = 'Z') ? tolower(c) : 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: [vmw_vmci 11/11] Apply the header code to make VMCI build

2012-08-02 Thread Jan Engelhardt

On Friday 2012-07-27 12:34, Sam Ravnborg wrote:
 +#ifndef _VMCI_COMMONINT_H_
 +#define _VMCI_COMMONINT_H_
 +
 +#include linux/printk.h
 +#include linux/vmw_vmci_defs.h

Use inverse chrismas tree here.
Longer include lines first, and soret alphabetically when
lines are of the same length.

So that's where unreadable include lists come from.
Depth-first lexicographically-sorted is a lot less hassle,
especially when it comes to merging patches that each
add one different include.

 +/*
 + * Utilility function that checks whether two entities are allowed
 + * to interact. If one of them is restricted, the other one must
 + * be trusted.
 + */
 +static inline bool vmci_deny_interaction(uint32_t partOne,
 + uint32_t partTwo)

The kernel types are u32 not uint32_t - these types belongs in user-space.

Not really. uint32_t is the C99 type for a 32-bit quantity, and I see
absolutely zero reason not to use standardized things. The only
exception are header files visible to user space where __u32 should
be used for (obscure) reasons of avoiding naming clashes.

(Obscure because uint32_t is always supposed to be 32 bits.)

--
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] netconsole.txt: nc needs -p to specify the listening port

2012-08-02 Thread Jan Engelhardt

On Friday 2012-07-27 08:35, Dirk Gouders wrote:
diff --git a/Documentation/networking/netconsole.txt 
b/Documentation/networking/netconsole.txt
index 8d02207..ffe30a7 100644
--- a/Documentation/networking/netconsole.txt
+++ b/Documentation/networking/netconsole.txt
@@ -52,7 +52,7 @@ initialized and attempts to bring up the supplied dev at the 
supplied
 address.
 
 The remote host can run either 'netcat -u -l -p port',
-'nc -l -u port' or syslogd.
+'nc -l -u -p port' or syslogd.

While at it, could you add

  socat udp-recv:port -

since netcat is _really_ archaic ;-)

--
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: awful kconfig help texts.

2012-08-01 Thread Jan Engelhardt

On Wednesday 2012-08-01 09:43, Thierry Reding wrote:
  
  PWM Support (PWM) [N/y/?] (NEW) ?
  
  CONFIG_PWM:
  This enables PWM support through the generic PWM framework.
 
 Oh, there's one more enlightening sentence in the help:
 
 You only need to enable this, if you also want to enable one or more of
 the PWM drivers below.
 
 Got it? :-)
 Thierry, can you guys please fix this?

Hehe, those aren't very descriptive, that's true. I was going to go over
the documentation anyway, so I'll make a note to revise the Kconfig help
texts as well.

Also, instead of
bool PWM Support
this should be
menuconfig PWM support

so that you can disable the whole submenu at once.
--
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 00/36] AArch64 Linux kernel port

2012-07-09 Thread Jan Engelhardt

On Sunday 2012-07-08 12:18, Catalin Marinas wrote:

On the good side, alphabetically it's before arch/alpha, so easier to
grep.

And during `ls -l`, it'll happily scroll off the screen into oblivion :)
--
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 00/36] AArch64 Linux kernel port

2012-07-08 Thread Jan Engelhardt
On Sunday 2012-07-08 07:05, Henrique de Moraes Holschuh wrote:

I agree the name sucks, and I'd much prefer to just call it arm64 as
well. The main advantage of the aarch64 name is that it's the same
as the identifier in the elf triplet, [...] to identify the
architecture, [...] the rpm and dpkg architecture names, and [...]
the uname syscall.

Any hindrance changing the specs? There is not even arm64 hardware - or
aarch64, for that matter - out there yet according to the initial post,
so I doubt there is anything in userspace yet.

There is, in gnu config (the autoconf config.sub/config.guess stuff), and
maybe some of the gnu toolchain?

I did wonder why the awkward aarch64 identifier instead of something like
arm64 which has also the benefit of good marketing by carrying the ARM name
in the arch name, but since it was not my place to ask about it and ARM had
already submitted aarch64 to gnu upstream...

Well maybe ARM just wants to render itself unimportant. Fine by me, but 
the shareholders might think differently ;-)
--
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 00/36] AArch64 Linux kernel port

2012-07-08 Thread Jan Engelhardt

On Sunday 2012-07-08 09:54, Jon Masters wrote:

FWIW I actually really like the aarch64 name (but you know that already
:) ). I think it clearly spells out that this is not just a 64-bit
extension to the existing 32-bit ARM Architecture, it is a new (inspired
by ARM) architecture.

IA64 also has a arch inside, and look where it took them.
(The contemporary platform winner came to be x86_64 instead
of what Intel had hoped back then.)
--
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 00/36] AArch64 Linux kernel port

2012-07-07 Thread Jan Engelhardt

On Saturday 2012-07-07 05:53, Olof Johansson wrote:

 ARM introduced AArch64 as part of the ARMv8 architecture

With the risk of bikeshedding here, but I find the name awkward. How
about just naming the arch port arm64 instead? It's considerably more
descriptive in the context of the kernel.  For reference, we didn't
name ppc64, nor powerpc, after what the IBM/power.org marketing people
were currently calling the architecture at the time either.

But then again, we went with the clumsy x86_64 instead of the
well-credited amd64. :)

(What was the name IBM used to call their hardware at that time?)
--
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 00/36] AArch64 Linux kernel port

2012-07-07 Thread Jan Engelhardt

On Saturday 2012-07-07 21:27, Arnd Bergmann wrote:
On Saturday 07 July 2012, Olof Johansson wrote:

  ARM introduced AArch64 as part of the ARMv8 architecture
 
 With the risk of bikeshedding here, but I find the name awkward. How
 about just naming the arch port arm64 instead?

I agree the name sucks, and I'd much prefer to just call it arm64 as
well. The main advantage of the aarch64 name is that it's the same
as the identifier in the elf triplet, [...] to identify the
architecture, [...] the rpm and dpkg architecture names, and [...]
the uname syscall.

Any hindrance changing the specs? There is not even arm64 hardware - or
aarch64, for that matter - out there yet according to the initial post,
so I doubt there is anything in userspace 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: Tabs, spaces, indent and 80 character lines

2008-02-25 Thread Jan Engelhardt

On Feb 25 2008 23:13, Richard Knutsson wrote:
 Miles Bader wrote:
 Why do people even respond to these trolls...?
   
 Obviously, this must to have been discussed before, with a clear conclusion.

It has been discussed before, at http://lkml.org/lkml/2007/11/12/19 .

What is really frustrating is that some of the people which _do_ 
enforce one style of the two (tabs-only or tabs-spaces) have only
indirectly voiced their preferred style, as in
http://lkml.org/lkml/2008/1/19/67 .

Often it was just (1)checkpatch flagged your spaces, hence they are 
wrong instead of (2)in my tree, I only take tabs-only patches.


Now back to coding, oh and don't forget send a patch for CodingStyle 
since a mail without one is often taken even less seriously.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


lockdep warnings in ipv6

2008-02-24 Thread Jan Engelhardt
Hi,


when doing IPv6 (ping6, ssh otherhost, etc.), lockdep spews a warning in 
2.6.25-rc2 on the target. CONFIG_..._FRAME_POINTER is off,

CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
# CONFIG_FRAME_POINTER is not set

so I am not sure if the stack trace is worth something, is it?

[  449.168320] ===
[  449.168637] [ INFO: possible circular locking dependency detected ]
[  449.168851] 2.6.25-rc2 #67
[  449.168951] ---
[  449.169078] swapper/0 is trying to acquire lock:
[  449.169315]  (tbl-lock){-+-+}, at: [c023d5a3] 
neigh_lookup+0x43/0xb0
[  449.170147] 
[  449.170150] but task is already holding lock:
[  449.170309]  (n-lock){-+-+}, at: [c023f975] 
neigh_timer_handler+0x15/0x2a0
[  449.170512] 
[  449.170514] which lock already depends on the new lock.
[  449.170516] 
[  449.170736] 
[  449.170738] the existing dependency chain (in reverse order) is:
[  449.170926] 
[  449.170927] - #1 (n-lock){-+-+}:
[  449.171188][c0132266] add_lock_to_list+0x46/0xc0
[  449.171509][c0134c48] __lock_acquire+0xb48/0xf90
[  449.171678][c023dcda] neigh_periodic_timer+0x7a/0x170
[  449.171849][c01350ef] lock_acquire+0x5f/0x80
[  449.172007][c023dcda] neigh_periodic_timer+0x7a/0x170
[  449.172173][c029b239] _write_lock+0x29/0x40
[  449.172342][c023dcda] neigh_periodic_timer+0x7a/0x170
[  449.172508][c023dcda] neigh_periodic_timer+0x7a/0x170
[  449.172670][c011dd5f] run_timer_softirq+0x15f/0x1c0
[  449.172984][c023dc60] neigh_periodic_timer+0x0/0x170
[  449.173180][c023dc60] neigh_periodic_timer+0x0/0x170
[  449.173349][c011a182] __do_softirq+0x52/0xb0
[  449.173516][c011a225] do_softirq+0x45/0x50
[  449.173675][c011a665] irq_exit+0x55/0x70
[  449.173831][c0104e83] do_IRQ+0x43/0x90
[  449.173987][c0103214] common_interrupt+0x24/0x40
[  449.174147][c010321e] common_interrupt+0x2e/0x40
[  449.174308][] 0x
[  449.174767] 
[  449.174769] - #0 (tbl-lock){-+-+}:
[  449.174939][c01324f0] print_circular_bug_entry+0x40/0x50
[  449.175108][c0134a71] __lock_acquire+0x971/0xf90
[  449.175268][c013425e] __lock_acquire+0x15e/0xf90
[  449.175468][c0133c16] trace_hardirqs_on+0x66/0x110
[  449.175633][c01350ef] lock_acquire+0x5f/0x80
[  449.175793][c023d5a3] neigh_lookup+0x43/0xb0
[  449.175973][c029b2fe] _read_lock_bh+0x2e/0x40
[  449.176139][c023d5a3] neigh_lookup+0x43/0xb0
[  449.176303][c023d5a3] neigh_lookup+0x43/0xb0
[  449.177821][c8a74a8c] ndisc_dst_alloc+0x13c/0x1a0 [ipv6]
[  449.177821][c8a74950] ndisc_dst_alloc+0x0/0x1a0 [ipv6]
[  449.177821][c8a78575] __ndisc_send+0x95/0x4e0 [ipv6]
[  449.177821][c8a67410] ip6_output+0x0/0xb00 [ipv6]
[  449.177821][c8a79467] ndisc_send_ns+0x67/0xa0 [ipv6]
[  449.177821][c8a6eeb0] ipv6_chk_addr+0xa0/0xb0 [ipv6]
[  449.177821][c8a7a4ef] ndisc_solicit+0x9f/0x1b0 [ipv6]
[  449.177821][c0133af8] mark_held_locks+0x38/0x70
[  449.177821][c029b665] _spin_unlock_irqrestore+0x45/0x60
[  449.177821][c0133c16] trace_hardirqs_on+0x66/0x110
[  449.177821][c023fab5] neigh_timer_handler+0x155/0x2a0
[  449.177821][c011dd5f] run_timer_softirq+0x15f/0x1c0
[  449.177821][c023f960] neigh_timer_handler+0x0/0x2a0
[  449.177821][c023f960] neigh_timer_handler+0x0/0x2a0
[  449.177821][c011a182] __do_softirq+0x52/0xb0
[  449.177821][c011a225] do_softirq+0x45/0x50
[  449.177821][c011a665] irq_exit+0x55/0x70
[  449.177821][c0104e83] do_IRQ+0x43/0x90
[  449.177821][c0103214] common_interrupt+0x24/0x40
[  449.177821][c010321e] common_interrupt+0x2e/0x40
[  449.177821][c0101ace] default_idle+0x5e/0x90
[  449.177821][c0101a70] default_idle+0x0/0x90
[  449.177821][c0101910] cpu_idle+0x30/0x80
[  449.177821][] 0x
[  449.177821] 
[  449.177821] other info that might help us debug this:
[  449.177821] 
[  449.177821] 1 lock held by swapper/0:
[  449.177821]  #0:  (n-lock){-+-+}, at: [c023f975] 
neigh_timer_handler+0x15/0x2a0
[  449.177821] 
[  449.177821] stack backtrace:
[  449.177821] Pid: 0, comm: swapper Not tainted 2.6.25-rc2 #67
[  449.177821]  [c0132d72] print_circular_bug_tail+0x72/0x80
[  449.177821]  [c0134a71] __lock_acquire+0x971/0xf90
[  449.177821]  [c013425e] __lock_acquire+0x15e/0xf90
[  449.177821]  [c0133c16] trace_hardirqs_on+0x66/0x110
[  449.177821]  [c01350ef] lock_acquire+0x5f/0x80
[  449.177821]  [c023d5a3] neigh_lookup+0x43/0xb0
[  449.177821]  [c029b2fe] _read_lock_bh+0x2e/0x40
[  449.177821]  [c023d5a3] neigh_lookup+0x43/0xb0
[  449.177821]  [c023d5a3] neigh_lookup+0x43/0xb0
[  449.177821]  [c8a74a8c] ndisc_dst_alloc+0x13c/0x1a0 [ipv6]
[  449.177821]  [c8a74950] 

Re: Merging of completely unreviewed drivers

2008-02-23 Thread Jan Engelhardt
On Feb 21 2008 22:37, Ray Lee wrote:
On Thu, Feb 21, 2008 at 7:13 PM, Linus Torvalds
[EMAIL PROTECTED] wrote:
  So I'd be happier with warnings about deep indentation (but how do you
  count it? Will people then try to fake things out by using 4-space indents
  and then deep indentations will look like just a couple of tabs?)

I suspect that 90% of the cases that people really care about would
get caught successfully just by counting brace depth.

ie, by looking at { { {} {} {{{}{}}} } } I bet you can tell me which
section should have been pulled out into a separate routine.

Not only that. By clever branch factoring, you can possibly get yourself
rid of lots of deep levels. As in:

static void blah(void)
{
if (foo) {
bar;
bar2;
} else {
if (this) {
that;
that2;
} else {
bad day;
bad day2;
}
}
}

xfrmd:

static void blah(void)
{
if (foo) {
bar;
bar2;
return;
}
if (this) {
that;
that2;
return;
}
/* yay, got rid of two levels of indent! */
good day;
good day2;
}

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


Re: Question about your git habits

2008-02-22 Thread Jan Engelhardt

On Feb 22 2008 18:37, Chase Venters wrote:

I've been making myself more familiar with git lately and I'm curious what 
habits others have adopted. (I know there are a few documents in circulation 
that deal with using git to work on the kernel but I don't think this has 
been specifically covered).

My question is: If you're working on multiple things at once,

Impossible; Humans only have one core with only seven registers --
according to CodingStyle chapter 6 paragraph 4.

do you tend to clone the entire repository repeatedly into a series
of separate working directories

Too time consuming on consumer drives with projects the size of Linux.

and do your work there, then pull
that work (possibly comprising a series of temporary commits) back
into a separate local master respository with --squash, either into
master or into a branch containing the new feature?

No, just commit the current unfinished work to a new branch and deal
with it later (cherry-pick, rebase, reset --soft, commit --amend -i,
you name it). Or if all else fails, use git-stash.

You do not have to push these temporary branches at all, so it is
much nicer than svn. (Once all the work is done and cleanly in
master, you can kill off all branches without having a record
of their previous existence.)

Or perhaps you create a temporary topical branch for each thing you
are working on, and commit arbitrary changes then checkout another
branch when you need to change gears, finally --squashing the
intermediate commits when a particular piece of work is done?

if I don't collect arbitrary changes, I don't need squashing
(see reset --soft/amend above)

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


[announce] Xtables, Xtables-addons 1.5.1 and Writing Xtables Modules

2008-02-21 Thread Jan Engelhardt
Hello everyone,


I have released “Xtables” 1.5.1, which is a package of my ongoing
iptables development¹ that I did lately. Patrick McHardy was not
available last week to merge patches due to higher powers, so I
branched off the iptables subversion trunk into git since quilting on
top of svn was not so fun.

Xtables, that is the goal sought, will merge and unify arptables and 
ebtables² as becomes possible.

What will now become of the iptables and xtables packages? Xtables
clearly is more recent than the latest iptables svn, but I would
not want to do Xtables as a continuous parallel fork to iptables³.
Maybe merge⁴ or declare it the new official thing -- who knows.

Additionally, “Xtables-addons” 1.5.1 was released, which is supposed
to supersede patch-o-matic(-ng). As with POM, this package contains
not-so-officially-approved extensions. But different from POM is that
it does not (and will not) contain any patches that would require
patching the kernel. Just extensions that can be compiled and then
run instantly.

Furthermore, I would like to make aware of “Writing your own Xtables
module” document, which describes the code needed to get started with
your own xtables modules. It is based upon Nicolas's earlier Writing
your own iptables module
 . . . . . . . http://jengelh.hopto.org/documents/Writing_Xtables.pdf

URLs:
tarballs . . . http://dev.computergmbh.de/files/xtables/
gitweb . . . . http://dev.computergmbh.de/gitweb.cgi?p=xtables
 . . . . . . . http://dev.computergmbh.de/gitweb.cgi?p=xtables-addons
gitclone . . . git://dev.computergmbh.de/xtables
 . . . . . . . git://dev.computergmbh.de/xtables-addons

SRPM for reference how to build it in an automatic environment
 . . . . . . . http://ftp.gwdg.de/pub/linux/misc/suser-jengelh/SRPMS/
RPMs (SUSE). . http://ftp.gwdg.de/pub/linux/misc/suser-jengelh/SUSE-10.3/



¹It is supposed to be stable.
²FAQ: On a source base. User-visible commands like ip6tables remain.
³Read: merging forth and back between iptables-svn and xtables-git =
not good.
⁴There were talks about moving the iptables subversion repository to
git, but I could not wait for you guys, sorry ;-)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Xtables, Xtables-addons 1.5.1

2008-02-21 Thread Jan Engelhardt

On Feb 21 2008 20:49, Patrick McHardy wrote:
 Jan Engelhardt wrote:
 I have released “Xtables” 1.5.1, which is a package of my ongoing
 iptables development¹ that I did lately. Patrick McHardy was not
 available last week to merge patches due to higher powers, so I
 branched off the iptables subversion trunk into git since quilting on
 top of svn was not so fun.

 I'm back to full power, so feel free to post patches :)

Please pull from git://dev.c... — oh dang!

What have become of the idea of gitifying the netfilter svn?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: adapter, what's in a name

2008-02-20 Thread Jan Engelhardt

On Feb 19 2008 18:16, Karl Dahlke wrote:

I completely understand your point about the word adapter.
It is highly overloaded, to the point that it is almost meaningless.
How about accessibility?
Drivers and modules designed to make linux more accessible
could be placed in drivers/accessibility in the source tree.
It's just a suggestion.
If there is a better word for this concept, please let me know.

Yes, that does not sound bad. It is a common term in the redmond os,
and I think I even saw it in the kde control center last time I used
that.

And I finally understand what you are trying to say about /proc.
Processes, and perhaps memory and raid by extension,

RAID is in /sys/block/md*/md  ;-)

but not everything under the planet.
Would it be better for accessibility drivers to create files through sysfs, 
e.g.
/sys/accessibility/jupiter/synth
Naturally the jupiter subtree would appear when that module was loaded,
and disappear when it was removed.

Naturally, just like it would in procfs.

One person said, essentially,
We'll worry about this when the first such driver comes along.
But that's a chicken egg problem, isn't it?

To a given extent yes, because procfs code is somewhat different
from sysfs is somewhat different from a character-based device.
(Maybe you also want to have both a device and a sysfs file, like md.)

Let's set it up now, so things have a place to be.
Besides, speakup has been around for a long long time,
and jupiter almost as long.
These have both been converted to use the new notifiers,
along with pcclicks (sounds accompanying console output),
halfqwerty (one handed typing), and others.

(Mentioning halfqwerty reminds me of Sony's 13-key Thumb Phrase IM.)

Many of these will not need any virtual files, but some will,
and they need a place to be.
Beyond this, the software should exist somewhere, someday, in the source tree.
Not every driver under the sun, but some of them,
that have proved their merit, and meet the high standard of Linux coding, etc.
Mac comes bundled with an internal screen reader,
and windows has had an accessibility section for a long time, why not linux?

What accessibility functions does Windows have that Linux (in
general, things are usually implemented only in X or KDE) does not?

This is the best operating system in so many ways;
let's not be behind when it comes to accessibility.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: vfat32 Free Cluster Count Update

2008-02-20 Thread Jan Engelhardt

On Feb 19 2008 19:23, OGAWA Hirofumi wrote:

This problem was introduced by it ignores a free cluster count (not
usefree). If we was not using usefree option, FAT doesn't trust the
free cluster count anymore.

So, it doesn't update until re-count.  Um.. yes, it's a bit
problem. Ah.. it can fix we can trust now-flag or something.

I'll dig it more, later. And for right now, please run df command, it
will fix free cluster count.

Ah, _that's_ why the first invocation `df` command after a fresh boot
always takes so long!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: very poor ext3 write performance on big filesystems?

2008-02-20 Thread Jan Engelhardt

On Feb 18 2008 10:35, Theodore Tso wrote:
On Mon, Feb 18, 2008 at 04:57:25PM +0100, Andi Kleen wrote:
  Use cp
  or a tar pipeline to move the files.
 
 Are you sure cp handles hardlinks correctly? I know tar does,
 but I have my doubts about cp.

I *think* GNU cp does the right thing with --preserve=links.  I'm not
100% sure, though --- like you, probably, I always use tar for moving
or copying directory hierarchies.

But GNU tar does not handle acls and xattrs. So back to rsync/cp/mv.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


  1   2   3   4   5   6   7   8   9   10   >