Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When ISO-TP Socket is not bound the call to write sets errno EADDRNOTAVAIL #349

Closed
derek-will opened this issue Mar 9, 2022 · 6 comments

Comments

@derek-will
Copy link

derek-will commented Mar 9, 2022

When a CAN_ISOTP socket is not bound, then a call to write sets errno EADDRNOTAVAIL.

I would expect EADDRNOTAVAIL to be returned when passing in nonsense address information into bind which according to the source code it does.

Is there a rationale for this errno on write when the socket is not bound?

@derek-will derek-will changed the title When ISO-TP Socket is not bound call to write sets errno EADDRNOTAVAIL and not EBADF When ISO-TP Socket is not bound the call to write sets errno EADDRNOTAVAIL and not EBADF Mar 10, 2022
@derek-will derek-will changed the title When ISO-TP Socket is not bound the call to write sets errno EADDRNOTAVAIL and not EBADF When ISO-TP Socket is not bound the call to write sets errno EADDRNOTAVAIL Mar 10, 2022
@derek-will
Copy link
Author

derek-will commented Mar 10, 2022

After doing some thinking and experimenting, for UDP sockets one would get EDESTADDRREQ if a write is attempted without a connect. However, CAN_ISOTP has no support for connect and so therefore EADDRNOTAVAIL is the next best thing. The whole "Cannot assign requested address" comment just threw me as unexpected and it is typically an errno associated with bind. Something like EBADF would adhere to the manpage for write and "File descriptor in bad state" would sort of make sense.

On the other end, when trying to do a read on a UDP socket without calling bind first then the call will block indefinitely. CAN_ISOTP exhibits the same behavior. It is sort of undesirable. Now this is likely outside the scope of SocketCAN, but it would be nice if the sockets API would return an error and set an appropriate errno in such a state, but it appears that this is not the case. I am always a big fan of "fail early" and it seems like the sockets API does not do this in this case.

@hartkopp
Copy link
Member

On the other end, when trying to do a read on a UDP socket without calling bind first then the call will block indefinitely. CAN_ISOTP exhibits the same behavior. It is sort of undesirable. Now this is likely outside the scope of SocketCAN, but it would be nice if the sockets API would return an error and set an appropriate errno in such a state, but it appears that this is not the case. I am always a big fan of "fail early" and it seems like the sockets API does not do this in this case.

Oh, that's an interesting idea.
If I understand you correctly you suggest to return EADDRNOTAVAIL when reading from an unbound isotp socket?

@derek-will
Copy link
Author

Oh, that's an interesting idea.
If I understand you correctly you suggest to return EADDRNOTAVAIL when reading from an unbound isotp socket?

Thanks for filtering through those thoughts. :-)

Yes, I think it would be best if when someone attempts to read from an unbound ISO-TP socket that they get rejected and the appropriate errno is set. I do not think there is a case or there ever would be one where an application developer would need to read from an unbound ISO-TP socket.

For example, with the J2534 API a call to PassThruReadMsgs will return ERR_NO_FLOW_CONTROL on a ISO15765 channel without a filter set.

If reads on unbound sockets will never succeed, then rejecting the call to read, recv, etc. and setting an appropriate errno will assist the application developer in tracing errors in their code. I think EADDRNOTAVAIL is a sensible choice.

@hartkopp
Copy link
Member

I think EADDRNOTAVAIL is a sensible choice.

I would like to add a Suggested-by: tag, when creating a patch for it, if you are fine to send me an email address that would show up in the Linux kernel then. Unfortunately a GitHub account name does not make it through the checkpatch script ;-)

@derek-will
Copy link
Author

Hi Oliver, I emailed you my email address. What a strange statement. :-)

ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Mar 17, 2022
When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
@hartkopp
Copy link
Member

Hi Derek,

your suggestion is now in the upstream process and will show up in Linux 5.18 (and the stable kernels):
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=30ffd5332e06

Many thanks,
Oliver

hartkopp added a commit to hartkopp/can-isotp that referenced this issue Mar 17, 2022
Upstream commit https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=30ffd5332e06

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 2, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this issue Apr 6, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this issue Apr 6, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this issue Apr 6, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this issue Apr 6, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 6, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 6, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 6, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 6, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 6, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 6, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 6, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 6, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 6, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 7, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 7, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
github-actions bot pushed a commit to sirdarckcat/linux-1 that referenced this issue Apr 8, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
woodsts pushed a commit to woodsts/linux-stable that referenced this issue Apr 8, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 8, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
woodsts pushed a commit to woodsts/linux-stable that referenced this issue Apr 8, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this issue Apr 8, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-block that referenced this issue Apr 8, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
woodsts pushed a commit to woodsts/linux-stable that referenced this issue Apr 8, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
psndna88 pushed a commit to psndna88/AGNi-xanmod_x86-64 that referenced this issue Apr 15, 2022
[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
AlexGhiti pushed a commit to AlexGhiti/riscv-linux that referenced this issue Apr 28, 2022
BugLink: https://bugs.launchpad.net/bugs/1968984

[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Andrea Righi <[email protected]>
tuxedo-bot pushed a commit to tuxedocomputers/linux that referenced this issue May 2, 2022
BugLink: https://bugs.launchpad.net/bugs/1969110

[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
(cherry picked from commit 05e4e7d9bbb3cbdc1eeb65ddf439f28edfdf38c2)
Signed-off-by: Paolo Pisati <[email protected]>
tuxedo-bot pushed a commit to tuxedocomputers/linux that referenced this issue May 9, 2022
BugLink: https://bugs.launchpad.net/bugs/1969110

[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
(cherry picked from commit 05e4e7d9bbb3cbdc1eeb65ddf439f28edfdf38c2)
Signed-off-by: Paolo Pisati <[email protected]>
tuxedo-bot pushed a commit to tuxedocomputers/linux that referenced this issue May 22, 2022
BugLink: https://bugs.launchpad.net/bugs/1969110

[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
(cherry picked from commit 05e4e7d9bbb3cbdc1eeb65ddf439f28edfdf38c2)
Signed-off-by: Paolo Pisati <[email protected]>
it-is-a-robot pushed a commit to openeuler-mirror/kernel that referenced this issue Jul 13, 2022
stable inclusion
from stable-v5.10.110
commit f402c498651993de361f349ac0cedb9f8622319f
bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f402c498651993de361f349ac0cedb9f8622319f

--------------------------------

[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Yu Liao <[email protected]>
Reviewed-by: Wei Li <[email protected]>
Signed-off-by: Zheng Zengkai <[email protected]>
it-is-a-robot pushed a commit to openeuler-mirror/kernel that referenced this issue Jul 13, 2022
stable inclusion
from stable-v5.10.110
commit f402c498651993de361f349ac0cedb9f8622319f
bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f402c498651993de361f349ac0cedb9f8622319f

--------------------------------

[ Upstream commit 30ffd53 ]

When reading from an unbound can-isotp socket the syscall blocked
indefinitely. As unbound sockets (without given CAN address information)
do not make sense anyway we directly return -EADDRNOTAVAIL on read()
analogue to the known behavior from sendmsg().

Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol")
Link: linux-can/can-utils#349
Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Derek Will <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Yu Liao <[email protected]>
Reviewed-by: Wei Li <[email protected]>
Signed-off-by: Zheng Zengkai <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants