add wifi6 8852be driver

hc

2024-12-19 9370bb92b2d16684ee45cf24e879c93c509162da

 kernel/fs/notify/fanotify/fanotify_user.c
..
..
@@ -1090,8 +1090,11 @@
1090
1090
 	return 0;
1091
1091
 }
1092
1092
 
1093
-static int fanotify_events_supported(struct path *path, __u64 mask)
1093
+static int fanotify_events_supported(struct path *path, __u64 mask,
1094
+				     unsigned int flags)
1094
1095
 {
1096
+	unsigned int mark_type = flags & FANOTIFY_MARK_TYPE_BITS;
1097
+
1095
1098
 	/*
1096
1099
 	 * Some filesystems such as 'proc' acquire unusual locks when opening
1097
1100
 	 * files. For them fanotify permission events have high chances of
..
..
@@ -1103,6 +1106,21 @@
1103
1106
 	if (mask & FANOTIFY_PERM_EVENTS &&
1104
1107
 	    path->mnt->mnt_sb->s_type->fs_flags & FS_DISALLOW_NOTIFY_PERM)
1105
1108
 		return -EINVAL;
1109
+
1110
+	/*
1111
+	 * mount and sb marks are not allowed on kernel internal pseudo fs,
1112
+	 * like pipe_mnt, because that would subscribe to events on all the
1113
+	 * anonynous pipes in the system.
1114
+	 *
1115
+	 * SB_NOUSER covers all of the internal pseudo fs whose objects are not
1116
+	 * exposed to user's mount namespace, but there are other SB_KERNMOUNT
1117
+	 * fs, like nsfs, debugfs, for which the value of allowing sb and mount
1118
+	 * mark is questionable. For now we leave them alone.
1119
+	 */
1120
+	if (mark_type != FAN_MARK_INODE &&
1121
+	    path->mnt->mnt_sb->s_flags & SB_NOUSER)
1122
+		return -EINVAL;
1123
+
1106
1124
 	return 0;
1107
1125
 }
1108
1126
 
..
..
@@ -1218,7 +1236,7 @@
1218
1236
 		goto fput_and_out;
1219
1237
 
1220
1238
 	if (flags & FAN_MARK_ADD) {
1221
-		ret = fanotify_events_supported(&path, mask);
1239
+		ret = fanotify_events_supported(&path, mask, flags);
1222
1240
 		if (ret)
1223
1241
 			goto path_put_and_out;
1224
1242
 	}