| Message ID | 20220825161511.94922-1-sj@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | xen-blk{front,back}: Advertise feature-persistent as user requested | expand |
On 25.08.22 18:15, SeongJae Park wrote: > Commit e94c6101e151 ("xen-blkback: Apply 'feature_persistent' parameter > when connect") made blkback to advertise its support of the persistent > grants feature only if the user sets the 'feature_persistent' parameter > of the driver and the frontend advertised its support of the feature. > However, following commit 402c43ea6b34 ("xen-blkfront: Apply > 'feature_persistent' parameter when connect") made the blkfront to work > in the same way. That is, blkfront also advertises its support of the > persistent grants feature only if the user sets the 'feature_persistent' > parameter of the driver and the backend advertised its support of the > feature. > > Hence blkback and blkfront will never advertise their support of the > feature but wait until the other advertises the support, even though > users set the 'feature_persistent' parameters of the drivers. As a > result, the persistent grants feature is disabled always regardless of > the 'feature_persistent' values[1]. > > The problem comes from the misuse of the semantic of the advertisement > of the feature. The advertisement of the feature should means only > availability of the feature not the decision for using the feature. > However, current behavior is working in the wrong way. > > This patchset fixes the issue by making both blkback and blkfront > advertise their support of the feature as user requested via > 'feature_persistent' parameter regardless of the otherend's support of > the feature. > > [1] https://lore.kernel.org/xen-devel/bd818aba-4857-bc07-dc8a-e9b2f8c5f7cd@suse.com/ > > SeongJae Park (2): > xen-blkback: Advertise feature-persistent as user requested > xen-blkfront: Advertise feature-persistent as user requested > > drivers/block/xen-blkback/common.h | 3 +++ > drivers/block/xen-blkback/xenbus.c | 6 ++++-- > drivers/block/xen-blkfront.c | 8 ++++++-- > 3 files changed, 13 insertions(+), 4 deletions(-) > For the series: Reviewed-by: Juergen Gross <jgross@suse.com> Juergen
Commit e94c6101e151 ("xen-blkback: Apply 'feature_persistent' parameter when connect") made blkback to advertise its support of the persistent grants feature only if the user sets the 'feature_persistent' parameter of the driver and the frontend advertised its support of the feature. However, following commit 402c43ea6b34 ("xen-blkfront: Apply 'feature_persistent' parameter when connect") made the blkfront to work in the same way. That is, blkfront also advertises its support of the persistent grants feature only if the user sets the 'feature_persistent' parameter of the driver and the backend advertised its support of the feature. Hence blkback and blkfront will never advertise their support of the feature but wait until the other advertises the support, even though users set the 'feature_persistent' parameters of the drivers. As a result, the persistent grants feature is disabled always regardless of the 'feature_persistent' values[1]. The problem comes from the misuse of the semantic of the advertisement of the feature. The advertisement of the feature should means only availability of the feature not the decision for using the feature. However, current behavior is working in the wrong way. This patchset fixes the issue by making both blkback and blkfront advertise their support of the feature as user requested via 'feature_persistent' parameter regardless of the otherend's support of the feature. [1] https://lore.kernel.org/xen-devel/bd818aba-4857-bc07-dc8a-e9b2f8c5f7cd@suse.com/ SeongJae Park (2): xen-blkback: Advertise feature-persistent as user requested xen-blkfront: Advertise feature-persistent as user requested drivers/block/xen-blkback/common.h | 3 +++ drivers/block/xen-blkback/xenbus.c | 6 ++++-- drivers/block/xen-blkfront.c | 8 ++++++-- 3 files changed, 13 insertions(+), 4 deletions(-)