s390: vfio-ccw: push down unsupported IDA check
Subsystems (4)
Halil Pasic
reviewerPATCH 1/1 s390: vfio-ccw: push down unsupported IDA check
There is at least one relevant control program (CP) that don't set the IDA flags in the ORB as we would like them, but never uses any IDA. So instead of saying -EOPNOTSUPP when observing an ORB such that a channel program specified by it could be a not supported one, let us say -EOPNOTSUPP only if the channel program is a not supported one.
Of course, the real solution would be doing proper translation for all IDA. This is possible, but given the current code not straight forward.
---
QEMU counterpart comming soon.
--- drivers/s390/cio/vfio_ccw_cp.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-)
drivers/s390/cio/vfio_ccw_cp.c +16 -3
@@ -365,6 +365,9 @@ static void cp_unpin_free(struct channel_program *cp)* This is the chain length not considering any TICs. * You need to do a new round for each TIC target. * +* The program is also validated for absence of not yet supported +* indirect data addressing scenarios. +* * Returns: the length of the ccw chain or -errno. */ static int ccwchain_calc_length (u64 iova,struct channel_program *cp)
@@ -391,6 +394,14 @@ static int ccwchain_calc_length(u64 iova, struct channel_program *cp) do { cnt++; + /* + * 2k byte block IDAWs (fmt1 or fmt2) are not yet supported. + * There are however CPs that don't use IDA at all, and can + * benefit from not failing until failure is eminent. + */ + if ((!cp->orb.cmd.c64 || cp->orb.cmd.i2k) && ccw_is_idal(ccw)) + return -EOPNOTSUPP; + if ((!ccw_is_chain(ccw)) && (!ccw_is_tic(ccw))) break;
@@ -656,10 +667,8 @@ int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb)/* * XXX: * Only support prefetch enable mode now. -* Only support 64bit addressing idal. -* Only support 4k IDAW. */ -if (!orb->cmd.pfch || !orb->cmd.c64 || orb->cmd.i2k) +if (!orb->cmd.pfch)return -EOPNOTSUPP ;INIT_LIST_HEAD (&cp->ccwchain_list);
@@ -688,6 +697,10 @@ int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb) ret =ccwchain_loop_tic (chain, cp);if (ret)cp_unpin_free (cp); +/* It is safe to force: if not set but idals used +* ccwchain_calc_length returns an error. +*/ + cp->orb.cmd.c64 =1 ;return ret; }
Signature · 1 line
2.16.3
Quoted 1 line · On Wed, 9 May 2018 19:36:47 +0200 Halil Pasic <[email protected]> wrote:
There is at least one relevant control program (CP) that don't set the
I'd prefer not to talk about 'control program' here, as it is not a term commonly used in Linux. Call it 'guest'?
Also, s/don't/doesn't/
Quoted 7 lines
IDA flags in the ORB as we would like them, but never uses any IDA. So instead of saying
-EOPNOTSUPPwhen observing an ORB such that a channel program specified by it could be a not supported one, let us say-EOPNOTSUPPonly if the channel program is a not supported one.Of course, the real solution would be doing proper translation for all IDA. This is possible, but given the current code not straight forward.
I agree, this seems useful for now, but we really need to support the different ida flags to be fully architecture compliant.
Quoted 25 lines
Signed-off-by Halil Pasic <[email protected]>Tested-by Jason J. Herne <[email protected]>---
QEMU counterpart comming soon.
--- drivers/s390/cio/vfio_ccw_cp.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-)drivers/s390/cio/vfio_ccw_cp.c +3
-0@@ -365,6 +365,9 @@ static void cp_unpin_free(struct channel_program *cp)* This is the chain length not considering any TICs. * You need to do a new round for each TIC target. * +* The program is also validated for absence of not yet supported +* indirect data addressing scenarios. +* * Returns: the length of the ccw chain or -errno. */ static int ccwchain_calc_length (u64 iova,struct channel_program *cp)
drivers/s390/cio/vfio_ccw_cp.c static int ccwchain_calc_length(u64 iova, struct channel_program *cp) · line 400
Quoted 7 lines
drivers/s390/cio/vfio_ccw_cp.c +4
-0@@ -391,6 +394,14 @@ static int ccwchain_calc_length(u64 iova, struct channel_program *cp) do { cnt++; + /* + * 2k byte block IDAWs (fmt1 or fmt2) are not yet supported. + * There are however CPs that don't use IDA at all, and can + * benefit from not failing until failure is eminent.
The second sentence is confusing (What is 'CP' referring to here? 'Control program' or struct channel_program?)
What about:
"As we don't want to fail direct addressing even if the orb specified one of the unsupported formats, we defer checking for IDAWs in unsupported formats to here."
Quoted 20 lines
drivers/s390/cio/vfio_ccw_cp.c +5
-3+*/ +if ((!cp->orb.cmd.c64 || cp->orb.cmd.i2k) &&ccw_is_idal (ccw)) +return -EOPNOTSUPP ; +if ((!ccw_is_chain (ccw)) && (!ccw_is_tic (ccw)))break ;@@ -656,10 +667,8 @@ int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb)/* * XXX: * Only support prefetch enable mode now. -* Only support 64bit addressing idal. -* Only support 4k IDAW. */ -if (!orb->cmd.pfch || !orb->cmd.c64 || orb->cmd.i2k) +if (!orb->cmd.pfch)return -EOPNOTSUPP ;INIT_LIST_HEAD (&cp->ccwchain_list);
drivers/s390/cio/vfio_ccw_cp.c int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb) · line 701
Quoted 5 lines
drivers/s390/cio/vfio_ccw_cp.c +2
-0@@ -688,6 +697,10 @@ int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb) ret =ccwchain_loop_tic (chain, cp);if (ret)cp_unpin_free (cp); +/* It is safe to force: if not set but idals used +* ccwchain_calc_length returns an error.
s/returns/already returned/ ?
drivers/s390/cio/vfio_ccw_cp.c int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb) · line 706
Quoted 5 lines
drivers/s390/cio/vfio_ccw_cp.c +2
-0+*/ + cp->orb.cmd.c64 =1 ;return ret; }
The patch looks sane, I have only issues with the description/comments.
Halil Pasic
reviewerQuoted 11 lines · Cornelia Huck
Quoted 1 line · On Wed, 9 May 2018 19:36:47 +0200 Halil Pasic <[email protected]> wrote:
There is at least one relevant control program (CP) that don't set the
I'd prefer not to talk about 'control program' here, as it is not a term commonly used in Linux. Call it 'guest'?
Also, s/don't/doesn't/
I will use guest instead.
Quoted 11 lines
Quoted 7 lines
IDA flags in the ORB as we would like them, but never uses any IDA. So instead of saying
-EOPNOTSUPPwhen observing an ORB such that a channel program specified by it could be a not supported one, let us say-EOPNOTSUPPonly if the channel program is a not supported one.Of course, the real solution would be doing proper translation for all IDA. This is possible, but given the current code not straight forward.
I agree, this seems useful for now, but we really need to support the different ida flags to be fully architecture compliant.
I think this support is deeply buried in Dong Jia's backlog. FWIW I'm unaware of any (relevant) exploiter (guest) for the old IDA. Thus testing could also prove challenging, that is require extra test code. So given the estimated pain/gain ratio I don't see this coming soon.
With my QEMU changes related to this patch we will also get the full IDA support as soon as the kernel is there.
Quoted 28 lines
Quoted 28 lines
Signed-off-by Halil Pasic <[email protected]>Tested-by Jason J. Herne <[email protected]>---
QEMU counterpart comming soon.
--- drivers/s390/cio/vfio_ccw_cp.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-)drivers/s390/cio/vfio_ccw_cp.c +3
-0@@ -365,6 +365,9 @@ static void cp_unpin_free(struct channel_program *cp)* This is the chain length not considering any TICs. * You need to do a new round for each TIC target. * +* The program is also validated for absence of not yet supported +* indirect data addressing scenarios. +* * Returns: the length of the ccw chain or -errno. */ static int ccwchain_calc_length (u64 iova,struct channel_program *cp)@@ -391,6 +394,14 @@ static int ccwchain_calc_length(u64 iova, struct channel_program *cp) do { cnt++;
Quoted 7 lines
drivers/s390/cio/vfio_ccw_cp.c static int ccwchain_calc_length(u64 iova, struct channel_program *cp) · line 400
Quoted 4 lines
drivers/s390/cio/vfio_ccw_cp.c +4
-0+/* +* 2k byte block IDAWs (fmt1 or fmt2) are not yet supported. +* There are however CPs that don't use IDA at all, and can +* benefit from not failing until failure is eminent. The second sentence is confusing (What is 'CP' referring to here? 'Control program' or struct
channel_program?)
Control program. I was under impression that in mainframe context CP mostly stands for control program.
Quoted 6 lines
What about:
"As we don't want to fail direct addressing even if the orb specified one of the unsupported formats, we defer checking for IDAWs in unsupported formats to here."
Was the second sentence only confusing because of CP? I'm not perfectly satisfied with your version either:
* 'fail direct addressing even if the orb specified one of the unsupported formats' I wanted to say: 'hey it does not matter what format for IDA the orb implies if the channel program does not use any IDA at all'. That could be paraphrased as channel programs using direct addressing exclusively. But failing the direct addressing does not fit for me.
* 'defer' is IMHO trivial from the perspective that we used to fence the unsupported scenarios earlier (by just looking at the orb). But if one just reads the new code defer does not make much sense to me.
But no strong opinions here. If you think your version is the way to go I will just take it.
Quoted 19 lines
Quoted 19 lines
drivers/s390/cio/vfio_ccw_cp.c +5
-3+*/ +if ((!cp->orb.cmd.c64 || cp->orb.cmd.i2k) &&ccw_is_idal (ccw)) +return -EOPNOTSUPP ; +if ((!ccw_is_chain (ccw)) && (!ccw_is_tic (ccw)))break ;@@ -656,10 +667,8 @@ int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb)/* * XXX: * Only support prefetch enable mode now. -* Only support 64bit addressing idal. -* Only support 4k IDAW. */ -if (!orb->cmd.pfch || !orb->cmd.c64 || orb->cmd.i2k) +if (!orb->cmd.pfch)return -EOPNOTSUPP ;
Quoted 10 lines
drivers/s390/cio/vfio_ccw_cp.c int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb) · line 701
Quoted 7 lines
drivers/s390/cio/vfio_ccw_cp.c +2
-0INIT_LIST_HEAD (&cp->ccwchain_list);@@ -688,6 +697,10 @@ int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb) ret =ccwchain_loop_tic (chain, cp);if (ret)cp_unpin_free (cp); +/* It is safe to force: if not set but idals used +* ccwchain_calc_length returns an error. s/returns/already returned/ ?
Yes we can do that. I think returns is also grammatical. Present simple can be used for expressing something that is always true.
Quoted 8 lines
drivers/s390/cio/vfio_ccw_cp.c int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb) · line 706
Quoted 5 lines
drivers/s390/cio/vfio_ccw_cp.c +2
-0+*/ + cp->orb.cmd.c64 =1 ;return ret; }The patch looks sane, I have only issues with the description/comments.
Thanks for having a look. Please give me short feedback about the one open point and I will respin with the requested changes.
Regards,
Halil
Quoted 27 lines · On Mon, 14 May 2018 15:37:17 +0200 Halil Pasic <[email protected]> wrote:
Quoted 11 lines · Cornelia Huck
Quoted 1 line · On Wed, 9 May 2018 19:36:47 +0200 Halil Pasic <[email protected]> wrote:
There is at least one relevant control program (CP) that don't set the
I'd prefer not to talk about 'control program' here, as it is not a term commonly used in Linux. Call it 'guest'?
Also, s/don't/doesn't/
I will use guest instead.
Quoted 11 lines
Quoted 7 lines
IDA flags in the ORB as we would like them, but never uses any IDA. So instead of saying
-EOPNOTSUPPwhen observing an ORB such that a channel program specified by it could be a not supported one, let us say-EOPNOTSUPPonly if the channel program is a not supported one.Of course, the real solution would be doing proper translation for all IDA. This is possible, but given the current code not straight forward.
I agree, this seems useful for now, but we really need to support the different ida flags to be fully architecture compliant.
Quoted 5 lines
I think this support is deeply buried in Dong Jia's backlog. FWIW I'm unaware of any (relevant) exploiter (guest) for the old IDA. Thus testing could also prove challenging, that is require extra test code. So given the estimated pain/gain ratio I don't see this coming soon.
Yes, the only practical outcome from implementing this is that we can claim architecture compliance. Would be good if we could do that, but as long as there are more pressing issues around...
Quoted 3 lines
With my QEMU changes related to this patch we will also get the full IDA support as soon as the kernel is there.
Nod.
Quoted 37 lines
Quoted 29 lines
Quoted 29 lines
Signed-off-by Halil Pasic <[email protected]>Tested-by Jason J. Herne <[email protected]>---
QEMU counterpart comming soon.
--- drivers/s390/cio/vfio_ccw_cp.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-)drivers/s390/cio/vfio_ccw_cp.c +3
-0@@ -365,6 +365,9 @@ static void cp_unpin_free(struct channel_program *cp)* This is the chain length not considering any TICs. * You need to do a new round for each TIC target. * +* The program is also validated for absence of not yet supported +* indirect data addressing scenarios. +* * Returns: the length of the ccw chain or -errno. */ static int ccwchain_calc_length (u64 iova,struct channel_program *cp)@@ -391,6 +394,14 @@ static int ccwchain_calc_length(u64 iova, struct channel_program *cp) do { cnt++;Quoted 7 lines
drivers/s390/cio/vfio_ccw_cp.c static int ccwchain_calc_length(u64 iova, struct channel_program *cp) · line 400
Quoted 4 lines
drivers/s390/cio/vfio_ccw_cp.c +4
-0+/* +* 2k byte block IDAWs (fmt1 or fmt2) are not yet supported. +* There are however CPs that don't use IDA at all, and can +* benefit from not failing until failure is eminent. The second sentence is confusing (What is 'CP' referring to here? 'Control program' or struct
channel_program?)
Quoted 2 lines
Control program. I was under impression that in mainframe context CP mostly stands for control program.
Yes, but it is very confusing as there is also a variable named 'cp' in this function.
Quoted 8 lines
Quoted 7 lines
What about:
"As we don't want to fail direct addressing even if the orb specified one of the unsupported formats, we defer checking for IDAWs in unsupported formats to here."
Quoted 7 lines
Was the second sentence only confusing because of CP? I'm not perfectly satisfied with your version either:
* 'fail direct addressing even if the orb specified one of the unsupported formats' I wanted to say: 'hey it does not matter what format for IDA the orb implies if the channel program does not use any IDA at all'. That could be paraphrased as channel programs using direct addressing exclusively. But failing the direct addressing does not fit for me.
But that's effectively what happens now, no? We reject the orb out of hand due to unsupported flags that do not have any relevance for the channel program in that case.
Or maybe 'channel programs using direct addressing only'?
Quoted 3 lines
* 'defer' is IMHO trivial from the perspective that we used to fence the unsupported scenarios earlier (by just looking at the orb). But if one just reads the new code defer does not make much sense to me.
I think it still makes sense if you look at how the functions are called.
Quoted 3 lines
But no strong opinions here. If you think your version is the way to go I will just take it.
I certainly don't want to dictate things :)
Quoted 31 lines
Quoted 20 lines
Quoted 20 lines
drivers/s390/cio/vfio_ccw_cp.c +5
-3+*/ +if ((!cp->orb.cmd.c64 || cp->orb.cmd.i2k) &&ccw_is_idal (ccw)) +return -EOPNOTSUPP ; +if ((!ccw_is_chain (ccw)) && (!ccw_is_tic (ccw)))break ;@@ -656,10 +667,8 @@ int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb)/* * XXX: * Only support prefetch enable mode now. -* Only support 64bit addressing idal. -* Only support 4k IDAW. */ -if (!orb->cmd.pfch || !orb->cmd.c64 || orb->cmd.i2k) +if (!orb->cmd.pfch)return -EOPNOTSUPP ;Quoted 10 lines
drivers/s390/cio/vfio_ccw_cp.c int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb) · line 701
Quoted 7 lines
drivers/s390/cio/vfio_ccw_cp.c +2
-0INIT_LIST_HEAD (&cp->ccwchain_list);@@ -688,6 +697,10 @@ int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb) ret =ccwchain_loop_tic (chain, cp);if (ret)cp_unpin_free (cp); +/* It is safe to force: if not set but idals used +* ccwchain_calc_length returns an error. s/returns/already returned/ ?
Quoted 2 lines
Yes we can do that. I think returns is also grammatical. Present simple can be used for expressing something that is always true.
I think it makes it clearer that we already checked earlier in the call sequence.
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
drivers/s390/cio/vfio_ccw_cp.c +2
-0+*/ + cp->orb.cmd.c64 =1 ;
Quoted 8 lines
Quoted 5 lines
drivers/s390/cio/vfio_ccw_cp.c int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb) · line 706
Quoted 2 lines
drivers/s390/cio/vfio_ccw_cp.c +0
-0return ret; }The patch looks sane, I have only issues with the description/comments.
Thanks for having a look. Please give me short feedback about the one open point and I will respin with the requested changes.
Does anybody else have feedback?
Halil Pasic
reviewerQuoted 7 lines · Cornelia Huck
Quoted 4 lines · On Mon, 14 May 2018 15:37:17 +0200 Halil Pasic <[email protected]> wrote:
Quoted 3 lines · Cornelia Huck
On Wed, 9 May 2018 19:36:47 +0200
Halil Pasic <[email protected]> wrote:
[..]
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
drivers/s390/cio/vfio_ccw_cp.c static int ccwchain_calc_length(u64 iova, struct channel_program *cp) · line 400
Quoted 4 lines
drivers/s390/cio/vfio_ccw_cp.c +4
-0+/* +* 2k byte block IDAWs (fmt1 or fmt2) are not yet supported. +* There are however CPs that don't use IDA at all, and can +* benefit from not failing until failure is eminent. The second sentence is confusing (What is 'CP' referring to here? 'Control program' or struct
channel_program?)
Quoted 6 lines
Quoted 2 lines
Control program. I was under impression that in mainframe context CP mostly stands for control program.
Yes, but it is very confusing as there is also a variable named 'cp' in this function.
Right. I was coming from the PoP side of things. But I do agree.
Quoted 16 lines
Quoted 8 lines
Quoted 7 lines
What about:
"As we don't want to fail direct addressing even if the orb specified one of the unsupported formats, we defer checking for IDAWs in unsupported formats to here."
Quoted 7 lines
Was the second sentence only confusing because of CP? I'm not perfectly satisfied with your version either:
* 'fail direct addressing even if the orb specified one of the unsupported formats' I wanted to say: 'hey it does not matter what format for IDA the orb implies if the channel program does not use any IDA at all'. That could be paraphrased as channel programs using direct addressing exclusively. But failing the direct addressing does not fit for me.
Quoted 3 lines
But that's effectively what happens now, no? We reject the orb out of hand due to unsupported flags that do not have any relevance for the channel program in that case.
Yes, that's what happens now, except that we make the whole channel program fail, and not the direct addressing. But the comment should describe what happens with the patch applied.
Quoted 7 lines
Or maybe 'channel programs using direct addressing only'?
Quoted 3 lines
* 'defer' is IMHO trivial from the perspective that we used to fence the unsupported scenarios earlier (by just looking at the orb). But if one just reads the new code defer does not make much sense to me.
Quoted 9 lines
I think it still makes sense if you look at how the functions are called.
Quoted 3 lines
But no strong opinions here. If you think your version is the way to go I will just take it.
I certainly don't want to dictate things :)
No problem. I'm aware of my limitations when it comes to producing readable text. In particular, my judgment about well readable or not is not trustworthy. So your input is highly appreciated. I will take your version, unless there is development.
Quoted 31 lines
Quoted 31 lines
Quoted 30 lines
Quoted 22 lines
drivers/s390/cio/vfio_ccw_cp.c +5
-3+*/ +if ((!cp->orb.cmd.c64 || cp->orb.cmd.i2k) &&ccw_is_idal (ccw)) +return -EOPNOTSUPP ; +if ((!ccw_is_chain (ccw)) && (!ccw_is_tic (ccw)))break ;@@ -656,10 +667,8 @@ int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb)/* * XXX: * Only support prefetch enable mode now. -* Only support 64bit addressing idal. -* Only support 4k IDAW. */ -if (!orb->cmd.pfch || !orb->cmd.c64 || orb->cmd.i2k) +if (!orb->cmd.pfch)return -EOPNOTSUPP ;INIT_LIST_HEAD (&cp->ccwchain_list);drivers/s390/cio/vfio_ccw_cp.c int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb) · line 701
Quoted 5 lines
drivers/s390/cio/vfio_ccw_cp.c +2
-0@@ -688,6 +697,10 @@ int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb) ret =ccwchain_loop_tic (chain, cp);if (ret)cp_unpin_free (cp); +/* It is safe to force: if not set but idals used +* ccwchain_calc_length returns an error. s/returns/already returned/ ?
Quoted 6 lines
Quoted 2 lines
Yes we can do that. I think returns is also grammatical. Present simple can be used for expressing something that is always true.
I think it makes it clearer that we already checked earlier in the call sequence.
Will do.
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
drivers/s390/cio/vfio_ccw_cp.c int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb) · line 706
Quoted 6 lines
drivers/s390/cio/vfio_ccw_cp.c +2
-0+*/ + cp->orb.cmd.c64 =1 ;return ret; }The patch looks sane, I have only issues with the description/comments.
Quoted 5 lines
Quoted 2 lines
Thanks for having a look. Please give me short feedback about the one open point and I will respin with the requested changes.
Does anybody else have feedback?
Will wait a day or so. Dong Jia and Jason have already seen the patch, and they only complained about the text. Since that spin was mainly for the tested-by tags, and I stated that any substantial discussion should happen upstream, I ignored those complaints.
So yes I will wait a bit so everybody can chime in.
Regards,
Halil
Quoted 27 lines · On Mon, 14 May 2018 16:44:29 +0200 Halil Pasic <[email protected]> wrote:
Quoted 26 lines · Cornelia Huck
Quoted 22 lines · On Mon, 14 May 2018 15:37:17 +0200 Halil Pasic <[email protected]> wrote:
Quoted 10 lines · Cornelia Huck
drivers/s390/cio/vfio_ccw_cp.c static int ccwchain_calc_length(u64 iova, struct channel_program *cp) · line 400
Quoted 4 lines · On Wed, 9 May 2018 19:36:47 +0200 Halil Pasic <[email protected]> wrote:
drivers/s390/cio/vfio_ccw_cp.c +4
-0+/* +* 2k byte block IDAWs (fmt1 or fmt2) are not yet supported. +* There are however CPs that don't use IDA at all, and can +* benefit from not failing until failure is eminent. What about:
Quoted 3 lines
"As we don't want to fail direct addressing even if the orb specified one of the unsupported formats, we defer checking for IDAWs in unsupported formats to here."
Was the second sentence only confusing because of CP? I'm not perfectly satisfied with your version either:
* 'fail direct addressing even if the orb specified one of the unsupported formats' I wanted to say: 'hey it does not matter what format for IDA the orb implies if the channel program does not use any IDA at all'. That could be paraphrased as channel programs using direct addressing exclusively. But failing the direct addressing does not fit for me.
Quoted 7 lines
Quoted 3 lines
But that's effectively what happens now, no? We reject the orb out of hand due to unsupported flags that do not have any relevance for the channel program in that case.
Yes, that's what happens now, except that we make the whole channel program fail, and not the direct addressing. But the comment should describe what happens with the patch applied.
Even more, it should describe _why_ it is done that way (the reason being "we don't want to fail..."). That's where I've been coming from.
Quoted 9 lines
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
The patch looks sane, I have only issues with the description/comments.
Thanks for having a look. Please give me short feedback about the one open point and I will respin with the requested changes.
Does anybody else have feedback?
Quoted 6 lines
Will wait a day or so. Dong Jia and Jason have already seen the patch, and they only complained about the text. Since that spin was mainly for the tested-by tags, and I stated that any substantial discussion should happen upstream, I ignored those complaints.
So yes I will wait a bit so everybody can chime in.
Sounds good.