autofs4: fix 32-bit userspace vs 64-bit kernel communications
PATCH 1/1 autofs4: fix 32-bit userspace vs 64-bit kernel communications
From: Konstantin Khlebnikov <[email protected]>
The struct autofs_v5_packet has only one difference between 32-bit and 64-bit versions - on 64-bit gcc aligns its size and it is 4 bytes larger that it is on 32-bit kernel. This confuses 32-bit user-space daemon, when talking to 64-bit kernel.
This is very critical for containerized setups, when containers with <different>-bit tolls are used.
---
fs/autofs4/waitq.c +8 -0
@@ -132,6 +132,14 @@ static void autofs4_notify_daemon(struct autofs_sb_info *sbi,struct autofs_v5_packet *packet = &pkt.v5_pkt.v5_packet; pktsz =sizeof (*packet); +#if defined(CONFIG_X86_64 ) && defined(CONFIG_IA32_EMULATION ) +/* +* On x86_64 autofs_v5_packet struct is padded with 4 bytes +* which breaks 32-bit autofs daemon. +*/ +if (test_thread_flag (TIF_IA32 )) + pktsz -=4 ; +#endif packet->wait_queue_token = wq->wait_queue_token; packet->len = wq->len;
Ian Kent
maintainerQuoted 6 lines · Pavel Emelyanov
From: Konstantin Khlebnikov <[email protected]>
The struct
autofs_v5_packethas only one difference between 32-bit and 64-bit versions - on 64-bit gcc aligns its size and it is 4 bytes larger that it is on 32-bit kernel. This confuses 32-bit user-space daemon, when talking to 64-bit kernel.
No, I don't think that's quite right.
As far as I know this issue arises when a user space program, compiled as a 32-bit application is executed within 64-bit user space.
Quoted 3 lines
This is very critical for containerized setups, when containers with <different>-bit tolls are used.
Have you tested different situations with this change? Will this affect the existing check and adjustment the version 5 automount daemon does now?
Quoted 26 lines
Signed-off-by Konstantin Khlebnikov <[email protected]>Acked-by Pavel Emelyanov <[email protected]>---
fs/autofs4/waitq.c +8
-0@@ -132,6 +132,14 @@ static void autofs4_notify_daemon(struct autofs_sb_info *sbi,struct autofs_v5_packet *packet = &pkt.v5_pkt.v5_packet; pktsz =sizeof (*packet); +#if defined(CONFIG_X86_64 ) && defined(CONFIG_IA32_EMULATION ) +/* +* On x86_64 autofs_v5_packet struct is padded with 4 bytes +* which breaks 32-bit autofs daemon. +*/ +if (test_thread_flag (TIF_IA32 )) + pktsz -=4 ; +#endif packet->wait_queue_token = wq->wait_queue_token; packet->len = wq->len;
Quoted 8 lines · Ian Kent
Quoted 6 lines · Pavel Emelyanov
From: Konstantin Khlebnikov <[email protected]>
The struct
autofs_v5_packethas only one difference between 32-bit and 64-bit versions - on 64-bit gcc aligns its size and it is 4 bytes larger that it is on 32-bit kernel. This confuses 32-bit user-space daemon, when talking to 64-bit kernel.
Quoted 4 lines
No, I don't think that's quite right.
As far as I know this issue arises when a user space program, compiled as a 32-bit application is executed within 64-bit user space.
What program do mean here? The problem arises right on the kernel-daemon boundary - the latter refuses to accept the message with larger length. No other software required.
Quoted 6 lines
Quoted 2 lines
This is very critical for containerized setups, when containers with <different>-bit tolls are used.
Have you tested different situations with this change? Will this affect the existing check and adjustment the version 5 automount daemon does now?
64-bit daemons *still* work OK and 32-bit *start* to after this fix :)
Quoted 32 lines
Quoted 15 lines
Signed-off-by Konstantin Khlebnikov <[email protected]>Acked-by Pavel Emelyanov <[email protected]>---
fs/autofs4/waitq.c +1
-0@@ -132,6 +132,14 @@ static void autofs4_notify_daemon(struct autofs_sb_info *sbi,struct autofs_v5_packet *packet = &pkt.v5_pkt.v5_packet; pktsz =sizeof (*packet); +#if defined(CONFIG_X86_64 ) && defined(CONFIG_IA32_EMULATION )fs/autofs4/waitq.c static void autofs4_notify_daemon(struct autofs_sb_info *sbi, · line 145
Quoted 10 lines
fs/autofs4/waitq.c +7
-0+/* +* On x86_64 autofs_v5_packet struct is padded with 4 bytes +* which breaks 32-bit autofs daemon. +*/ +if (test_thread_flag (TIF_IA32 )) + pktsz -=4 ; +#endif packet->wait_queue_token = wq->wait_queue_token; packet->len = wq->len;--
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/
Ian Kent
maintainerQuoted 9 lines · Pavel Emelyanov
Quoted 8 lines · Ian Kent
Quoted 6 lines · Pavel Emelyanov
From: Konstantin Khlebnikov <[email protected]>
The struct
autofs_v5_packethas only one difference between 32-bit and 64-bit versions - on 64-bit gcc aligns its size and it is 4 bytes larger that it is on 32-bit kernel. This confuses 32-bit user-space daemon, when talking to 64-bit kernel.
Quoted 8 lines
Quoted 4 lines
No, I don't think that's quite right.
As far as I know this issue arises when a user space program, compiled as a 32-bit application is executed within 64-bit user space.
What program do mean here? The problem arises right on the kernel-daemon boundary - the latter refuses to accept the message with larger length. No other software required.
Any program that is compiled to use the autofs4 module with the version 5 communication protocol. As far as I know only autofs version 5 uses this at the moment.
This isn't a problem for a 32-bit daemon running within a 32-bit user space environment or a 64-bit daemon running within a 64-bit user space environment.
Quoted 9 lines
Quoted 7 lines
Quoted 3 lines
This is very critical for containerized setups, when containers with <different>-bit tolls are used.
Have you tested different situations with this change? Will this affect the existing check and adjustment the version 5 automount daemon does now?
64-bit daemons *still* work OK and 32-bit *start* to after this fix :)
My point is that I think this change may adversely affect existing compiled user space applications and I want know if I'm right.
I acknowledge that the struct padding is a problem and I am aware of it but it is potentially a big problem to just change the kernel structure size.
Does the test_thread_flag(TIF_IA32) macro only return true for a 32-bit user-space process running within a 64-bit user space environment (perhaps I can do away with the check in the autofs daemon, perhaps it doesn't quite work correctly)?
Quoted 34 lines
Quoted 33 lines
Quoted 16 lines
Signed-off-by Konstantin Khlebnikov <[email protected]>Acked-by Pavel Emelyanov <[email protected]>---
fs/autofs4/waitq.c +1
-0@@ -132,6 +132,14 @@ static void autofs4_notify_daemon(struct autofs_sb_info *sbi,struct autofs_v5_packet *packet = &pkt.v5_pkt.v5_packet; pktsz =sizeof (*packet); +#if defined(CONFIG_X86_64 ) && defined(CONFIG_IA32_EMULATION )fs/autofs4/waitq.c static void autofs4_notify_daemon(struct autofs_sb_info *sbi, · line 145
Quoted 10 lines
fs/autofs4/waitq.c +7
-0+/* +* On x86_64 autofs_v5_packet struct is padded with 4 bytes +* which breaks 32-bit autofs daemon. +*/ +if (test_thread_flag (TIF_IA32 )) + pktsz -=4 ; +#endif packet->wait_queue_token = wq->wait_queue_token; packet->len = wq->len;--
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/
Ian Kent
maintainerQuoted 39 lines · Pavel Emelyanov
Quoted 8 lines · Ian Kent
Quoted 6 lines · Pavel Emelyanov
From: Konstantin Khlebnikov <[email protected]>
The struct
autofs_v5_packethas only one difference between 32-bit and 64-bit versions - on 64-bit gcc aligns its size and it is 4 bytes larger that it is on 32-bit kernel. This confuses 32-bit user-space daemon, when talking to 64-bit kernel.Quoted 4 lines
No, I don't think that's quite right.
As far as I know this issue arises when a user space program, compiled as a 32-bit application is executed within 64-bit user space.
What program do mean here? The problem arises right on the kernel-daemon boundary - the latter refuses to accept the message with larger length. No other software required.
Quoted 6 lines
Quoted 2 lines
This is very critical for containerized setups, when containers with <different>-bit tolls are used.
Have you tested different situations with this change? Will this affect the existing check and adjustment the version 5 automount daemon does now?
64-bit daemons *still* work OK and 32-bit *start* to after this fix :)
Quoted 12 lines
Quoted 12 lines
Signed-off-by Konstantin Khlebnikov <[email protected]>Acked-by Pavel Emelyanov <[email protected]>---
fs/autofs4/waitq.c +0
-0@@ -132,6 +132,14 @@ static void autofs4_notify_daemon(struct autofs_sb_info *sbi,struct autofs_v5_packet *packet = &pkt.v5_pkt.v5_packet;
Quoted 2 lines
Quoted 2 lines
fs/autofs4/waitq.c static void autofs4_notify_daemon(struct autofs_sb_info *sbi, · line 135
Quoted 2 lines
fs/autofs4/waitq.c +1
-0pktsz =sizeof (*packet); +#if defined(CONFIG_X86_64 ) && defined(CONFIG_IA32_EMULATION )
Oh .. so maybe the answer to my question is yes?
What about other arches offer 32-bit within a 64-bit environment (has this been the case on sparc64 at some point)?
What about the compiler padding on these?
Don't get me wrong, I'm not against fixing this, in fact I'd like to, but I'm concerned it may end up a bit of a can of worms.
Quoted 19 lines
Quoted 18 lines
fs/autofs4/waitq.c static void autofs4_notify_daemon(struct autofs_sb_info *sbi, · line 145
Quoted 11 lines
fs/autofs4/waitq.c +7
-0+/* +* On x86_64 autofs_v5_packet struct is padded with 4 bytes +* which breaks 32-bit autofs daemon. +*/ +if (test_thread_flag (TIF_IA32 )) + pktsz -=4 ; +#endif packet->wait_queue_token = wq->wait_queue_token; packet->len = wq->len;--
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/
Quoted 4 lines
Does the
test_thread_flag(TIF_IA32)macro only return true for a 32-bit user-space process running within a 64-bit user space environment (perhaps I can do away with the check in the autofs daemon, perhaps it doesn't quite work correctly)?
Hm... If we fix it in the user level that would also be OK, I suppose...
Quoted 1 line
Oh .. so maybe the answer to my question is yes?
It is - we check *only* for the process, that is to receive the packet.
Quoted 3 lines
What about other arches offer 32-bit within a 64-bit environment (has this been the case on sparc64 at some point)?
What about the compiler padding on these?
We have no technical ability to check this. First I wanted to get your opinion about this particular fix for x86 machines.
As far as sparc(64) and other 32-to-64 are concerned - I can start talking to their users/maintainers to check.
Quoted 2 lines
Don't get me wrong, I'm not against fixing this, in fact I'd like to, but I'm concerned it may end up a bit of a can of worms.
Ian Kent
maintainerQuoted 5 lines · Pavel Emelyanov
Quoted 4 lines
Does the
test_thread_flag(TIF_IA32)macro only return true for a 32-bit user-space process running within a 64-bit user space environment (perhaps I can do away with the check in the autofs daemon, perhaps it doesn't quite work correctly)?
Quoted 7 lines
Hm... If we fix it in the user level that would also be OK, I suppose...
Quoted 1 line
Oh .. so maybe the answer to my question is yes?
It is - we check *only* for the process, that is to receive the packet.
Right, since the send is done in user context.
Quoted 10 lines
Quoted 4 lines
What about other arches offer 32-bit within a 64-bit environment (has this been the case on sparc64 at some point)?
What about the compiler padding on these?We have no technical ability to check this. First I wanted to get your opinion about this particular fix for x86 machines.
As far as sparc(64) and other 32-to-64 are concerned - I can start talking to their users/maintainers to check.
I investigated only x86_64 and sparc64 but that was a quite a while ago now. My sparc machine doesn't even have a Linux install atm.
If we can find a general and consistent solution I'm happy to remove the check from the daemon and cope with the bit of pain it might cause.
Quoted 3 lines
Quoted 3 lines
Don't get me wrong, I'm not against fixing this, in fact I'd like to, but I'm concerned it may end up a bit of a can of worms.
Quoted 3 lines · Ian Kent
What about other arches offer 32-bit within a 64-bit environment (has this been the case on sparc64 at some point)?
What about the compiler padding on these?
Both ppc64 and sparc64 commonly have 32-bit userspaces. But 64-bit and mixed 32/64-bit userspaces are of course possible.
Ian Kent
maintainerQuoted 7 lines · Mikael Pettersson
Quoted 3 lines · Ian Kent
What about other arches offer 32-bit within a 64-bit environment (has this been the case on sparc64 at some point)?
What about the compiler padding on these?Both ppc64 and sparc64 commonly have 32-bit userspaces. But 64-bit and mixed 32/64-bit userspaces are of course possible.
I believe that both these archs have the same alignment characteristics a x86_64. Can anyone confirm that?
Ian